Developing constantly evolving software is quite a challenge. How to deliver new functionality without breaking existing ones and avoid debugging nasty bugs in production? The answer seems to be very easy – you have to test your application’s code very well. Here at NubiSoft, we are always looking forward to using TDD during the development process because it brings a lot of advantages. You can spot bugs in the early phase and prevent them to be deployed to production. Moreover, you can add or change functionalities without getting a heart attack during the deployment of a new version of the software. Finally, well-written tests become a documentation of the code base, helping to understand it better and maintain it in the longer term. Unfortunately, the test coverage is not the only factor always and it’s not that easy when it comes to developing healthcare e-services for Germany.
With one of our customers from Germany, our team was challenged with designing, developing, and providing an application called VOS (Verordnungssoftware) whose primary goal is to deal with e-prescriptions as well as with the treatment plan for patients. Once you get to know how e-prescription works in Germany, you instantly see how many things have to be tested:
- ability to read, produce and manipulate documents based on German FHIR format,
- data transmission between VOS and PVS (Praxisverwaltungssysteme) systems,
- communication correctness between VOS software and third-party hardware devices such as connectors and card terminals,
- integration with external services and capabilities to transmit data to and from Gematik cloud components (Identity Provider FD, e-Rezept FD, etc.).
When it comes to the e-prescription system in Germany, Gematik enables three separated environments: TITUS (test environment), RU (Referenzumgebung, reference environment), and PU (Produktionsumgebung, production environment). From the testing perspective, TITUS and RU look very interesting.
Gematik TITUS vs RU environment
In order to access the test environment, you can buy a license from Gematik for a Titus service, which brings you accessibility to all of the needed components including:
- virtualized connector component provided by Gematik,
- virtualized card terminal component provided by Gematik,
- Gematik TI services (IDP, e-Prescription, etc.) – accessible directly via the Internet connection.
On the other hand, access to the reference environment connection is established through third-party RU access providers. The architecture of the RU environment is similar to TITUS:
- physical or virtual connector device provided by your RU (Referenzumgebung) enabler,
- physical card terminal device supplied by third-party manufacturers,
- Gematik TI services (IDP, e-Prescription) – accessible through RU (Referenzumgebung) provider via VPN connection.
Despite PVS – VOS communication flow, seems like all of the mentioned points can be tested via TITUS service. So why do we have to even bother to use the RU environment? The devil is in the details and the fact that in TITUS service, some of the operations with connector (PIN prompts, signing documents using HBA cards, and so on) are performed in a simulated manner, meaning you can’t test your application behavior in some cases (e.g. wrong PIN entered, timeout occurred during signature). Also, some of the connector capabilities are entirely disabled (comfort signature management, changing a PIN). Finally, connectors and card terminals used on RU (Referenzumgebung) are the same which are used in the PU (Produktionsumgebung) environment by practitioners in their workplaces. Therefore, using the RU (Referenzumgebung) environment is the only way to ensure, that your application is likely to work in the production environment as well.
How to use the Gematik TI Referenzumgebung environment in CI/CD pipeline?
Utilizing reference environment capabilities in the testing process improves your application stability in terms of being consistent with the production environment. However, it also brings some problems, that have to be solved:
- Gematik Services are accessible only through an enabler VPN connection, so you have to use this VPN connection on every machine which should communicate with RU (Referenzumgebung) services.
- Card terminal actions are not simulated anymore, so you have to perform them manually.
Our RU (Referenzumgebung) enabler is not supporting multiple simultaneous VPN connections so we have to share the same VPN connection across all of the devices, CI/CD runners, and deployment nodes.
We solved the first problem by establishing a Multi-Hop VPN connection. Therefore, every machine connected to our Intranet network (e.g. developer’s computer, CI/CD runner, card terminal) is also connected to the RU (Referenzumgebung) environment out of the box. That’s really cool but the second problem remains. How team developers can perform PIN verification when they are not actually having physical access to the terminal? Furthermore, what about PIN verification in the terminal in the automated CI/CD test pipeline? Fortunately, we’ve chosen the right provider for our card terminal device. Using the Cherry ST-1506 card terminal gives you the opportunity to verify the PIN using the terminal’s Remote API interface. Thus, we decided to develop an extra Intranet component responsible for hooking to the terminal API, listening for PIN requests, and performing PIN verification whenever it is needed. Obviously, this component is fully configurable and can be temporarily disabled if you want to perform PIN verification and test your application manually.
Built infrastructure is used by many developers at NubiSoft on a daily basis, helping them and our customers to build fast-growing and rapidly-changing software with desired reliability and stability.