Customer portal for medical laboratory
Customer requirement
A digital customer portal will be developed to allow laboratory customers to conduct as many business processes with the laboratory as possible digitally. These include laboratory requests, requests for diagnostic results, courier requests, material orders and the management of internal quality controls. The digitisation of business processes is expected to create a market advantage through more efficient processes and greater customer acceptance. Although a web portal for order entry and return of diagnostic results is already available, it is rarely used. In many practices, laboratory orders are still submitted in analogue form using 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 licence of the previous solution, independent further development is not possible. The new application to be developed must be easy for customers to use. In addition, the application must be able to interact with a number of specialised systems, such as the laboratory and patient information systems, third party laboratories or the CRM.
The challenges
The laboratory consists of several departments, such as clinical chemistry, microbiology or pathology. These departments have individual requirements for materials, analyses, ordering procedures and internal laboratory processes. There are media breaks in the current ordering process, requiring manual intervention. This manual intervention is error-prone and time-consuming. The new customer portal is designed to reduce media breaks and encourage customers to complete business processes as digitally as possible. In addition, customers should be able to order laboratory requirements in a consistent process across laboratory boundaries.
The existing lab infrastructure is complex. It consists of a large number of system components and interfaces. External systems such as patient information systems and external laboratories are also connected. Many specific processes have been implemented over time. These processes need to be analysed and, where possible, harmonised. Some of the technologies and interfaces used are outdated. The lack of modern and open interfaces makes it difficult to connect new customer portals.
Proprietary licences prevent further development of existing components. The dependency on the existing systems and the system manufacturers, who have little interest in cooperating with other suppliers, is a considerable project risk.
Due to the sensitive nature of patient data, data protection plays an important role. Firstly, the interaction between all system components and the storage of data must be secure. All data must be protected against unauthorised access and loss. In particular, security risks have been identified for some patient information systems that need to be interconnected. Specific security mechanisms need to be developed to ensure that these systems can still be securely connected to the new web application.
Approach
The customer's requirements were analysed and captured in the form of user stories. The stories were prioritised together with the customer. The requirements were analysed in collaboration with a number of stakeholders. The existing system components and the IT infrastructure with its processes were analysed and the interaction of the new web application with the existing systems was outlined. An essential part of the work was to analyse and understand the numerous existing processes. In addition, master data had to be prepared in order to make it available to the application and to be able to map the desired logic in the ordering process. The focus was on the user experience in order to provide the customer with as self-explanatory access to the application as 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 organised in sprints. The product owner decided which user story to implement in a sprint. Due to the business critical processes that the web application had to cover, a high level of test coverage was aimed for. Unit tests, integration tests and where necessary E2E tests were written for each new functionality. Each user story was peer reviewed and 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 submitted to the customer for approval. After customer approval, the stories were deployed to production.
Solution
The result is a modern customer portal that efficiently captures laboratory requests and displays diagnostic results in real time. The portal has been designed so that it can be expanded with additional modules such as courier requests, quality management or material ordering.
With the customer portal, laboratory requests can be ordered in a consistent process across laboratory departments. Analyses are added via the search field or from pre-defined 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 is presented with all the information required to take 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 over time (cumulative results). Values below or above a reference value are visually highlighted. If an analysis value falls into a pathological range, the doctor's office or the user is informed accordingly.
The customer portal is also used to manage practices, staff access and practice settings. Practice settings include favourites, the serotheque or the reception system, as well as connections to patient and doctor information systems (PIS/AIS) or label printers.
Technically, the web application consists of 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 for data storage and a Minio cluster for S3 object storage. The applications are deployed as Docker containers and run on a dedicated Kubernetes cluster in Switzerland. Containerisation and the Kubernetes infrastructure ensure modern operation, application scalability and the ability to add new components.
In order to connect the web application to existing peripheral systems, two connector applications were developed, as modern interfaces such as REST were not available. One 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 provides the connection to the label printers via LAN or USB. The Practice Connector is available for Windows, OSX and Linux. New versions are automatically downloaded by the Practice Connector via its update function.
The connectors communicate with the web application via an 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 required formats and their dialects and make them available to the web portal as well as to other peripheral systems.
To accommodate sensitive data, great emphasis was placed on security and reliability. Communication with the web application is encrypted using advanced TLS and cryptographic protocols. The database is encrypted using REST and the results are encrypted with a random key per practice. To allow patient information systems with weak security mechanisms to connect to the new customer portal, a special one-time token interface was developed, which also allows patient information systems with a shared login to securely access individual order entries and reports.
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 testing.