A digital customer portal is to be developed in which laboratory customers can conduct as many business processes digitally with the laboratory. These include laboratory requests, requests for diagnostic results, courier requests, material orders, and the management of internal quality controls. The digitization of business processes is expected to create a market advantage through more efficient processes and greater customer acceptance. Although a web portal is already available for order entry and the return of diagnostic findings, it is rarely used. In many medical practices, laboratory orders continue to be submitted in analog form via order forms. It is suspected that the application no longer meets customer expectations for a modern and easy-to-use web application. Due to the proprietary license of the previous solution, independent further development is not possible. The new application to be developed must be easy to use by customers. In addition, the application must be able to interact with numerous specialized systems, such as the laboratory and patient information systems, third-party laboratories or the CRM.
The laboratory consists of several divisions, such as clinical chemistry, microbiology or pathology. These departments have individual requirements for materials, analyses, ordering procedures and internal laboratory processes. Media discontinuities exist in the current ordering process, making manual interventions necessary. These manual interventions are error-prone and time-consuming. The new customer portal is intended to reduce media discontinuities and encourage customers to handle business processes as digitally as possible. In addition, customers should be able to order laboratory requirements in a uniform process across laboratory boundaries.
The existing laboratory infrastructure is complex. It consists of a large number of system components and interfaces. External systems such as patient information systems and third-party laboratories are also connected. Over time, numerous specific processes have been implemented. These processes need to be analyzed and, where possible, harmonized. Some of the technologies and interfaces in use are outdated. The lack of modern and open interfaces makes it difficult to connect new customer portals.
Due to the proprietary licenses, further development of the existing components is not possible. The dependence on the already existing systems and the system manufacturers, who have little interest in cooperating with other suppliers, is a considerable project risk.
Because of sensitive patient data, data protection has a major role to play. First of all, the interaction between all system components and also the storage of the data must be secure. All data must be protected against unauthorized access and also against loss. Security risks have been identified in particular for some patient information systems that need to be connected. Specific security mechanisms must be developed to ensure that these systems can be securely connected to the new web application nonetheless.
The customer's requirements have been analyzed and captured in the form of user stories. The stories were prioritized together with the customer. Cooperation with numerous stakeholders was required to analyze the requirements. The already existing system components and the IT infrastructure with its processes were analyzed and the interaction of the new web application with the already existing systems was outlined. An essential part of the work was to analyze and understand the numerous existing processes. In addition, master data had to be prepared to make it available for the application and to be able to map the desired logic in the ordering process. A focus was placed on the user experience in order to provide customers with the most self-explanatory access to the application possible, despite the high level of technical complexity.
The development process was structured in an agile way according to Scrum and the development work was organized in sprints. Thus, the product owner decided which user story should be implemented in a sprint. Due to the business-critical processes that were to be covered by the web application, a high level of test coverage was aimed for. Unit tests, integration tests and, if required, E2E tests were written for each new functionality. Each user story went through a peer review and was then installed on the test system (continuous deployment). At the end of each sprint, the implemented user stories were combined into a release, installed on a PRE-PROD system and provided to the customer for approval. After the customer's approval, stories were deployed to production.
This has resulted in a modern customer portal in which laboratory requests can be recorded efficiently and results of diagnostic findings can be displayed in real time. The portal was designed so that it can be expanded with additional modules, such as courier requests, quality management or material ordering.
With the customer portal, laboratory requisitions can be ordered in a uniform process across laboratory departments. Analyses are added using the search field or from the predefined favourites. Depending on the analyses, further details such as location or time of sampling are requested. Once all the necessary details have been entered, the user receives all the information required for taking the sample, such as the material, the sampling system or further details on preparation or storage.
The analytical results are transmitted to the portal in real time, processed and displayed. The results can be compared with each other over a time axis (so-called cumulative results). Values that are below or above a reference value are highlighted visually. If an analysis value falls into a pathological range, the physician's office or the user is informed accordingly.
The customer portal is also used to manage physician practices, employee access and practice settings. The practice settings include, among others, favorites, the serotheque or the acceptance system and also the connections to patient and physician information systems (PIS/AIS) or the label printers.
Technically, the web application includes a frontend, a backend and two connector applications for connecting older peripheral systems. The frontend is based on Angular and TypeScript. Scala and Akka were used for the backend. A MariaDB Galera cluster is used to store the data, as well as a Minio cluster as S3 object storage. The applications are deployed as Docker containers and run in a dedicated Kubernetes cluster in Switzerland. Containerization and the Kubernetes infrastructure ensure modern operation, scaling of the application, and the ability to expand with new components.
In order to connect the web application to already existing peripheral systems, two connector applications were developed because modern interfaces such as REST were not available. A connector is responsible for connecting the web application to the internal laboratory systems. The second connector (practice connector) connects the various patient information systems to the web application and ensures the connection to the label printers via LAN or USB. The practice connector is available for Windows, OSX and Linux. New versions are automatically retrieved by the practice connector via its update function.
The connectors communicate with the web application via encrypted REST interface. The surrounding systems communicate via file-based interfaces (hl7 or gdt) due to the lack of modern alternatives. The connectors transform the delivered hl7 or gdt files into the desired formats and their dialects and make them available to the web portal as well as to other peripheral systems.
To accommodate sensitive data, great importance was placed on security and reliability. Communication with the web application is encrypted using modern TLS and cryptographic protocols. The database is encrypted at REST and the findings with a random key encrypted per practice. To allow patient information systems with weak security mechanisms to connect to the new customer portal, a specific one-time token interface has been developed, which also allows patient information systems with a shared login to securely access individual order entries and findings.
In addition to security measures such as two-factor authentication, OWASP headers, the use of a web firewall and measures to combat brute force and DDOS attacks, the application has very high test coverage through unit, integration and E2E tests.