4 Challenges for software vendors while implementing e-prescription in Germany

Issuing and implementing e-prescriptions

An e-prescription in Germany is created as an electronic document in the practice management system (PVS), then it is signed with a qualified electronic signature verified by a medical professional’s certificate on the HBA card.

The signed e-prescription is transmitted in encrypted form to the central system using a secure communication channel (VAU) set up by a physical and certified device (the Connector).

Patients can obtain a printed-out version along with a QR code containing a confidential code which is used to authorize their access to the electronic form of the e-prescription or view the e-prescription in the provided application, where they can also check the availability of selected drugs at designated pharmacies.

The QR code is scanned at the pharmacy to access the prescription data downloaded from the central system. Once the drug is dispensed, a receipt is signed in the central system, which can be used to reimburse the health Insurance fund for the drug.

In a nutshell, this is how e-prescription works, for details and in depth explanation of the whole proces read our previous article. In the following sections we will identify what are the key challenges when it comes to implementing it in a software for medical facilities.

Technological challenges

Electronic prescribing is a major improvement for both doctors and patients themselves. However, from a software provider’s point of view, its implementation is quite the challenge, both in terms of hardware and the software itself. This is because the entire system is decentralized and distributed, which is well illustrated in the figure below.

E-prescription system architecture overview
Source: https://fachportal.gematik.de/fileadmin/Fachportal/Downloadcenter/Implementierungsleitfaeden/gemILF_PS_V2.9.0.pdf

The integration into the Gematik services requires access to physical devices, such as card readers and the connector device, which offers APIs providing security services like authentication and data encryption. Communication between the medical software and the connector is mainly done by using SOAP protocols in the local networks of medical practices or hospitals, which depending on the architecture of the medical system can cause various amounts of problems. For older systems (legacy systems) created in thick-client architecture using outdated programming languages, an automated construction of a SOAP service client or creation of documents in FHIR standard may be impossible. There can also be problems with handling the latest security protocols or performance issues. The solution here might be the gradual migration of parts of the computer systems to newer technologies or the creation of a dedicated integration component, which will be an adapter or intermediary, between telematics infrastructure (TI) services and the medical system. In this model, data exchange between the integration components and the medical system can take place via any interface supported by the system (e.g., files, shared data source, etc.). This solution can also be successful if the medical system is built with a slightly newer technology, such as a web application accessible from a browser.

Separating a dedicated integration component also has the advantage of an independent manufacturing process, making it possible to outsource it to an external company with more experience in the subject. Read also about other advantages of IT-nearshoring approach.

Security and digital signatures

As mentioned earlier, a high level of security for e-prescriptions is one of the prerequisites for its successful implementation, as it helps to negate the natural concerns of patients and doctors about how their sensitive data will be processed. Not surprisingly, this issue affects virtually every element of the system, as well as the way it is used by end users.

The electronic signature, that ensures the authenticity, non-repudiation and verifiability of the e-prescription document, is perhaps the most important element of the security architecture in this case. Its widespread use in the many e-services available on the internet causes doctors and patients to treat it as a guarantee of security and something simple and natural – just like a handwritten signature. However, for this to be the case, the software supporting the signing process must meet, several functional as well as non-functional requirements to shorten and simplify the entire operation as much as possible, while maintaining high security standards. For software providers, it is therefore worth taking the time to carefully design the application screens where the doctor selects the health professional’s card (HBA) that they will use for signing and entering the PIN. The prototyping technique will work perfectly here.

An equally important element of security is the correct implementation of all security mechanisms, such as authentication or encryption of transmitted messages (VAU protocol). Its correctness can be confirmed by using an appropriate testing approach.


Integrating an existing medical system with e-prescribing is a huge challenge for the software vendor, both technologically and organizationally. The saving grace against high costs and delays is a well-organized development process that considers several external elements.

One of the most important factors influencing the success of a product on the market is its quality, which is why companies pay great attention to the testing process. When adapting software for issuing e-prescriptions, existing automated tests and manual test scenarios need to be modified, and manufacturing and testing environments need to be expanded with additional elements. This is process is mainly about integration with connector services, which we can replace with our own mock services, or use the test / staging environments offered by Gematik. Both solutions are sufficient for developers to test the code, as they do not require connection to any physical devices. Nevertheless, in the case of system or acceptance testing, it is pivotal to be able to verify the performance of the system which is connected to hardware and API services as close as possible to the actual environment.

Preparing such an environment and integrating it into an existing testing process can be very expensive and requires a lot of commitment from many people, so it is worth taking advantage of the knowledge and experience of a partner who has this already in place (read how we build automated CI/CD pipeline connected to Gematik RU environment to test e-prescription services).

Product Certification

Medical data is some of the most sensitive personal data making the fear of a leakage one of the main roadblocks for the digitization processes not only in Germany, but also throughout Europe and the world. For this reason, it is important to ensure the highest security standards at every stage of the process. The authors of the e-prescription solution in Germany took this requirement very serious and used several security mechanisms, such as cryptographic cards and encryption protocols, which ensure the confidentiality and integrity of electronic documents. Security software providers also play a critical role, and it is on them to implement the necessary systems. Public institutions involved in the e-prescribing process (Gematik, GKA) are responsible for certifying the solutions. So that, doctors and patients are assured that the applications they use guarantee the required level of security.

From the view of the software vendor, certification of the offered product is quite the challenge. Many of them require specific architectural decisions, such as data storage and the communication between system components. Knowing these at an early stage of work can significantly reduce the cost of software development and significantly accelerate the launch of the finished product. And this is where cooperation in this area with an external partner can bring tangible benefits.


How serious these challenges are, depends on the architecture of the products offered and the technology in which they were developed. Nevertheless, enlisting the help of an experienced partner can bring tangible benefits. That’s why we’ve developed a workflow that allows us to assess and identify the countless risks properly, so that adding e-prescription functionality to an existing system is successful and doesn’t require a huge investment of time and resources and allows for the effective implementation of further eHealth services (e.g., e-PA electronic patient record). Click here and schedule a free consultation so that together we can assess whether our approach works in your project.

Leave a Reply

Your email address will not be published. Required fields are marked *