Complex matter

Problem

Our client asked us to assist them in designing and implementing an application to meet radiation protection requirements and ensure quality management in the field of nuclear medical and radiochemical equipment and facilities.

In this way, we jointly designed a product that meets the complex requirements. Within the framework of the "Landesprogramm Wirtschaft" this project was supported by the European Union.

Testing of medical devices

In dealing with various nuclear medical and radiochemical applications, as well as in the operation of a corresponding facility, various measuring instruments are used whose main task is the detection of radioactive radiation. To ensure that the measuring instruments provide correct values, they must be checked regularly. This is usually done by measuring the radiation of a so-called test radiator. This emits radiation that is known in advance, so that there is a known tolerance range for the expected measurement result. In this way, it can be determined whether the instrument is functioning correctly.

Documentation and requirements

The measurements obtained in this way, which qualify the measuring instruments for further use, must be documented, evaluated, made accessible and stored in accordance with the Guideline Radiation Protection in Medicine in accordance with DIN 6855-11 (constancy testing of nuclear medicine measuring systems). In the past, this was done with the help of office documents, paper, e-mail and fax.

Different methods must be used, values recorded, and different data points persisted and provided in the form of electronic reports, depending on the type of device, manufacturer, and measurement method.

Other requirements for compliance with radiation protection regulations

In order to map the complete operation of a nuclear medicine facility, other issues not directly related to the testing of measuring equipment must be addressed. For example, work instructions must be made available to the departments, regulations must be made accessible, approvals must be issued, and incidents during operation must be documented.

Goal identification

Based on the requirements and the corresponding legal situation, an application was to be developed that would enable all legal requirements to be met, from the testing and documentation of measuring instruments to the provision of information and the documentation of incidents in facility operations.

The application required the implementation of two key components: a server-side application for managing clients, users, measurement series, documents, reports, and operations logs, and a mobile tablet application for recording measurement values and viewing instructions, requirements, and notices.

Challenging conditions

The legal requirements as well as the expected conditions in the practices and hospitals resulted in additional requirements for the solution to be designed. For example, automating reporting while taking into account strict authentication of report recipients was a relevant challenge. The fact that the majority of users document measurement results in areas without access to the Internet required the integration of an offline functionality with time-delayed data synchronization.

Technical challenge

The biggest technical hurdle was to understand the physical relationships of the different device types and measurement methods and to transfer them into a homogeneous modeling and implementation. In the process, more than 20 similar but not identical data structures were identified. In order to express the series types and limit value calculations, which are based on radioactive decay on the one hand and on continuity on the other, in a generally valid model, a generic schema was designed whose expressions were enabled to map the required polymorphisms with the aid of single-table inheritance.

Product design

Based on the various requirements, we designed a product that aims at intuitive and understandable usability in order to keep the complexity of the underlying processes as far away from the user as possible. The basic idea was to offer the user only those options that are needed to perform a single task in the respective context. The resulting clarity of the user interface allows the user to accomplish the task at hand in a short time without context switching and with minimal cognitive challenge.

To ensure that the concept can be applied in general, all relevant processes were transferred into user flows from the user's perspective and validated. In this way, we were able to ensure that the basic concept can be derived for all application scenarios.

In order to be able to reduce the interfaces for operating the application as much as possible, we have planned an extremely fine-grained role and rights management. With the help of this, the range of functions - and thus also the options of the interfaces - can be minimally configured for each individual user according to requirements.

In order to define the individual views required on the basis of the planned product features, wireframes were created for the majority of the complex use cases, anticipating future implementation. Based on the wireframes, we created a foundation at an early stage of the product development that allowed us and our client to ensure functional correctness, technical feasibility and optimal usability.

User interface design

Following the design concept, we elaborated the user interfaces of the mobile application and the web application as modular libraries. From design to implementation, we placed great emphasis on creating reusable components that follow an atomic approach. This means that we can fall back on these components when integrating further product features, which leads to the user finding a uniform operating concept and stringent functional principles. In addition, the use of already known, established and tested components is extremely efficient and significantly reduces the error rate.

To accommodate the different device-immanent operating concepts of the tablet and web application, the two component libraries differ significantly. Operation with the help of a pointing device - such as a mouse - has different requirements than operation by touch input. Thus, there is a great deal of agreement in the general product-specific style, but significant differences in the individual UI elements relevant to operation, such as buttons, input or navigation elements.

Tablet application

The tablet application was implemented as a native Android application. The range of functions is tailored so that a user can easily and conveniently document measured values, read process instructions and notes, and write logbook entries with the help of the tablet.

The most relevant use case is the recording of measured values, which is why we paid the greatest attention to this. In order to provide the user with feedback on the plausibility of the measurements, we have integrated the complex calculation logic for determining the reaction thresholds and tolerance limits for individual types of measurement series into both the server-side application and the tablet application. In this way, the user is directly shown whether the values he or she has recorded fall within the expected range.

Server-side application

The server-side application was implemented using our Propeller web application framework. In doing so, we implemented a project-specific UI kit in order to be able to work with a component library here as well, which simplifies the future integration of further product features.

At the API level, RESTful JSON is used as the protocol. We chose JSON web tokens as the authentication method. Statelessness at the protocol level makes it easy to solve some of the issues that arise from offline requests.

API endpoints are routed directly to controller implementations, which perform authorization checks and data plausibility at instantiation. This ensures that unauthorized or invalid accesses are rejected even before controller methods are executed.

A PostgreSQL database is used as persistence system.

The API documentation is provided directly by the framework, including sample requests, which greatly simplifies the development of API clients.

Reporting

The reporting of the measurement series documentation can be configured using the web application in such a way that the relevant measurement series for selected devices and a specific time period are summarized in a report. The report is supplemented by an extract from the logbook for the selected period.

For each report, a non-guessable URL is generated based on UUIDs and assigned an access key. This information can then be passed on to the relevant supervisory authority. The content and preparation of the report data has been fine-tuned to ensure that it is accepted by the authorities.

Testing and distribution

In order to be able to continuously maintain and develop the product without jeopardizing the stability and performance of the existing functionality, test scenarios were designed for all API endpoints and the required tests were defined. In this way, both function and performance can be tested automatically as part of black-box tests. This involves running the test scenarios for an appropriately prepared client and validating the results at the protocol and response level, as well as checking them against performance budgets.

The tests are performed when each new version is transferred to the version control system. Only after passing all test scenarios can the respective version be released to the staging or production environment. Thus, different versions are available at different stages.

All commissioning actions, such as build, testing and stage-based distribution, are configured, versioned and executed within the CI/CD functionality of the version control system.

Next Project