Telematics Infrastructure: 5 Requirements That Software Manufacturers Must Comply with to Stay on the Market

The telematics infrastructure (TI) is a platform/network that provides a basis for the secure exchange of health data in Germany and for the running of healthcare applications, such as electronic patient records and e-prescriptions.

However, a lot of manufacturers of medical software do not know when they have to fulfill which legal and technical requirements in the context of this telematics infrastructure.

1. Summary: telematics infrastructure requirements

Laws lead directly or indirectly (via operators) to requirements that affect manufacturers of medical software:

1. Requirements for legally defined interfaces according to ISiK
   If your device is a “confirmation-relevant system,” it must have an interface that follows, e.g., the ISiK Basic Module specification. More on that later.
2. Requirements for structured data sets for MIOs
   If manufacturers want to write or access data in electronic patient records (ePAs), their products must be able to exchange medical information objects (MIOs).
3. Requirements for “IT systems in healthcare”
   Manufacturers of other IT systems, such as digital health applications (DiGA) and hospital and primary care practice management systems, are no longer free to choose their own interoperability standards. These are now specified by gematik.
4. Requirements for implants and disability aids
   Products that transmit data in the context of implants or as disability aids must also send data to digital health applications via standardized interfaces under certain conditions.
5. Communications standard requirements with regard to KIM and TIM
   Not because of the law but because it is being demanded by customers (hospitals, doctors’ practices), manufacturers should enable communication through TIM and KIM.

c) Principle of patient sovereignty

According to the legislation (SGB), the telematics infrastructure (TI) is intended to act as a data highway to provide patient treatment data to individual service providers. To achieve this, data stores have been and are being set up – initially only for those with statutory health insurance, but by now for most citizens with private health insurance as well.

Even if the data in the TI is not saved by the patient, the principle is, nevertheless, that only the patient may decide who can collect and process which data.

3. Telematics infrastructure terminology

a) Services / applications

An infrastructure is only useful if it supports relevant use cases. The following (value-added) services, which the KBV refers to as “applications,” are among those planned for the telematics infrastructure:

• e-prescription (eRezept): This is intended to allow prescription drugs to be prescribed and dispensed by pharmacies.
• Electronic patient record (ePA): It is hoped that this key element will include data from all healthcare providers (hospitals, doctors, therapists) and encourage (intersectoral) data exchange.
• Electronic certificate of incapacity for work (eAU): This is intended to make yellow slips a thing of the past. Doctors can digitally send these certificates directly to health insurers and employers.
• Emergency data management (NFDM): The data that doctors might need in an emergency will be stored on the electronic medical data card (eGK). Examples of such data include diagnoses and medications.
• Electronic medical treatment plan: All medication data will also be stored on the eGK so that everyone involved can maintain an overview and, e.g., identify any drug interactions or duplicated medications.

A complete overview of the “applications” can be found on the websites of the KEV and gematik.

The availability of these services must be maintained. This is the responsibility of the operators, commercial companies such as ITSG, IBM and RISE, rather than gematik. There have been complaints about availability in the past, and gematik has also reported disruptions.

KIM

gematik also counts the communication services KIM and TIM among the applications.

KIM stands for “communication in medicine” in German. KIM is nothing more than a secure email service over the telematics infrastructure (TI). To provide this service, KIM uses tried and tested protocols such as HTTP, SMTP and POP.

The telematics infrastructure provides a directory service, a sort of address book of possible recipients.

KIM differs from “normal” email in a few aspects:

• All emails are encrypted and signed by the TI.
• The service does not currently support the IMAP protocol. As a result, it is not possible to synchronize emails to multiple devices.
• Only clients connected to the TI can send and receive KIM messages. That currently rules out cell phones.
• Email addresses are allocated centrally by the provider and are linked to the institution.
• The emails are also intended to enable automated exchange between systems. For example, a practice's management system can send a KIM message with an electronic certificate of incapacity for work.

KIM is intended to be used for the exchange of structured and unstructured medical information such as laboratory data, discharge letters (eArztbrief) and eAUs.

TIM

TIM stands for “Telematics Infrastructure Messenger.” It is intended to be a secure and legal alternative to WhatsApp and Co. Its interfaces have been specified by gematik.

TIM is suitable for short and quick exchanges of information: a query about a prescription, a note about a patient, a message to several colleagues (“broadcast”).

The messenger currently only allows the sending of (unstructured) information, specifically text messages, and sound and image transmission. It uses the REST-based Matrix protocol, which will allow two or more users to have a video call in addition to the instant messaging service. Video calls between doctors and patients will be introduced in a later expansion stage.

Unlike KIM, TIM can be used on smartphones.

b) MIO

Overview

Medical information objects (MIOs) are like Lego bricks that can be used to build more complex information structures, such as the electronic patient record. The following MIOs are currently or will be specified:

• Vaccination certificates
• Hospital discharge letters
• Maternity care record
• Abridged patient record
• (Child's) examination booklet
• Dental bonus booklet
• Telemedical monitoring

The KBV has created a page with an overview of MIOs. The specifications and the instructions for the implementation of MIOs in the ePA were created by gematik.

For example, “Immunization” must reference exactly one patient and specify the batch (“lotNumber”) and immunization status (e.g., “completed”).

The batch and vaccination date are MIO elements of the MIO model “electronic vaccination record” (“Immunization”).

A specific vaccination record for a specific patient forms a MIO document (XML format). Unlike the electronic child's examination booklet, the MIO document for the vaccination record does not contain any MIO sub-documents. The set of concrete values for a (sub-)document forms an MIO entry.

c) ISiK

gematik has also created an interface specification for “Information Technology Systems in Hospitals” (ISiK) Level 1. This ISiK specification defines data objects such as patient, encounter and condition on the basis of FHIR profiles.

For this, compliant systems must offer common functionalities, such as:

• Patient search, e.g., using attributes such as name, address and date of birth
• Consulting a patient's diagnoses (with code, date, etc.)
• Finding the current case using a case number (more on this later)

This in turn enables:

• The exchange of data between systems within a hospital (between primary systems, between primary systems and subsystems, and from Level 2 upwards, “even” with apps)
• The integration of external applications into a hospital's systems
• The connection of medical/measuring devices

gematik uses its own profiles and not those of the KBV or Medizininformatik-Initiative. The reason for this is explained at the bottom of this page.

4. Legal requirements

a) Article 355 SGB V: Requirements for the ePA and thus MIOs, among others

The first paragraph of Article 355 SGB V authorizes the KBV to establish interfaces for ePAs (and thus for MIOs), electronic medical treatment plans and the electronic emergency data.

b) Article 371 SGB V: Requirements for systems for the processing of personal data

Article 371 SGB V opens a series of laws with “Requirements for interfaces in information technology systems”. It is not limited to clinical systems and is, in fact, relevant for all systems that process personal data related to care provided by fund doctors (in private practices), in hospitals and by nursing staff.

It requires standardized interfaces that systems can access to prescribe medication as well as for inpatient and clinical “application and database systems” (i.e., practice management and hospital information systems).

c) § 372 SGB V: Practice management system requirements

Like the next article (Article 373) on hospitals, Article 372 SGB V establishes “specifications for open and standardized interfaces for information technology systems in fund doctor and fund dentist care”.

d) Article 373 SGB V: ISiK requirements

Article 373 SGB V forms the legal basis for the ISiK. Its title is “Specifications for open and standardized interfaces for information technology systems in hospitals and in nursing care.”

“Confirmation-relevant systems” currently refers to primary systems in hospitals. The German Hospital Federation may specify additional subsystems.

Further information on confirmation-relevant systems, e.g., on communication servers, can be found in the ISiK Basic Module implementation guide.

e) Article 374a SGB V: Requirements for some disability aids and implants

Article 374a of the Fifth Sozialgesetzbuch is entitled “Integration of open and standardized interfaces in disability aids and implants”. It requires data interfaces to be opened up for some products, including third-party providers (digital health application providers).

This article is not uncontroversial.

f) GIGV

The IOP Governance-Verordnung authorizes gematik to standardize interoperability standards The standards published by its expert panel become mandatory for manufacturers.

Standards have already been defined for the above use cases.

g) KHZG

The Krankenhauszukunftsgesetz (KHZG) is unique in this list for two reasons.

Firstly, it is an act that amends numerous laws, in particular the Krankenhausfinanzierungsgesetz and several books of the Social Code.

Secondly, it is an act that only affects manufacturers indirectly. This is because the act establishes eligibility criteria that define which projects hospitals can receive grant money for. A lot of the eligible projects are aimed at improving digitization:

• Updating of technical/information technology equipment in a hospital's emergency room so that it meets the current state of the art
• Patient portals. These include digital admission management, treatment management, discharge and transfer management
• Digital care and treatment records
• Creation of partially or fully automated clinical decision support systems
• Digital medication management
• Digital service request
• Equipment, systems or procedures based on information technology, communications technology or robotics, and telemedicine networks

Most hospitals have applied for or initiated one or more projects in order to qualify for these grants. However, they can only benefit from the grant money if the systems meet the above legal requirements.

This means manufacturers of medical software will only benefit from the boom in demand if their systems are among those that are eligible for the grants and meet the legal requirements.

5. Unfulfilled wishes

a) Real interoperability

gematik promised interoperability with the TI. But it has also received some criticism:

• The TI only works with an outdated and limited connector.
• There are gaps at the semantic level that have yet to be filled.
• The organizational level is incomplete. Comprehensive workflows and permissions concepts are missing, at least in part. The implementation of IHE XDS is incomplete.
• The unique patient identifier has been replaced by the KVNR, which not all citizens have and which is not unique.
• The (current) focus on practice management and hospital information systems connected via a connector by itself limits interoperability. However, this limitation is known and is being addressed.
• Despite all the efforts to achieve interoperability beyond national borders, the TI remains a German affair that does not create Europe-wide interoperability.

b) Usability

Some of the hurdles to benefiting from the advantages of the TI are high, both for the implementing manufacturers and for users.

Even the much-praised KIM doesn’t have IMAP. How do you explain this to users who feel like they're back in the 1990s where they can only save emails on one client? There is no solution in sight here, partly because of data protection laws standing in the way.

c) IT security

The much-promised secure IT systems have still not been delivered. We all know that any IT system can be hacked. However, in view of the efforts made to protect data and the restrictions that have to be accepted as a result, it is astonishing how often there are embarrassing yawning gaps, as reported by c't or uncovered by the CCC.

The frequency with which TI systems such as connectors and backend systems are not available damages the initiative.

d) Functionality

A lot of use cases are not yet supported, and there are missing functionalities in many places.

So, the statement that the telematics infrastructure makes a case number search possible is only partially correct.

Case numbers are assigned by healthcare providers and their IT systems. In other words, external systems do not know about the cases or their numbers. Therefore, external parties must be able to search for patients directly, but the case numbers cannot and will not be given up, as the cases are important to doctors and (medical) controllers.

As a result, the FHIR profile will be adapted in ISiK 2.

6. Conclusion

a) Progress ...

The noose keeps on getting tighter for manufacturers of medical information systems – at least with regard to interoperability. However, this can also be a good thing because the market has obviously failed to create the conditions requires for digitization: standardized interfaces that are actually used.

Only legal compulsion and financial incentives (KHZG) have generated progress towards the digitization of the healthcare system.

As TI 2.0, at the latest, will (or should) be able to handle structured data, it will become the standard in the German healthcare.

b) … after a decade of embarrassing stasis

It is also “only” digitization and not a digital transformation, let alone a digital revolution. After all, technologies and standards such as REST and email are well-proven. To celebrate that they are now being used in the healthcare sector would arouse pity in other countries.

But it’s no use complaining that a lot of people having been asleep at the wheel for more than a decade or that a lot of protagonists have given an embarrassing image and thus hindered and delayed the introduction of a telematics infrastructure.

Anyone still calling for digitization moratorium in 2021 after Germany has slipped into the bottom ranks in terms of digitization may not be part of the solution but part of the problem.

c) Demands are being placed on manufacturers, but they are being supported

We are where we are. And manufacturers would do well to go beyond simply meeting the legal requirements for interoperability. No one will be able to escape it from 2024 on, at the latest.

They should also play an active role in its further development because they know what the market needs. They are the ones who implement and use the interfaces. It is time to open up the monoliths to subsystems and mobile applications.

The Krankenhauszukunftsgesetz (KHZG) has triggered a gold-rush mood and a digitization boom. However, the act only benefits systems that are compatible with the ePA and that comply with already defined healthcare standards.

This will make it difficult for fast, unplanned and proprietary in-house developments from manufacturers to survive on the (German) market after 2024.

Lastly, we shouldn’t forget that digitization and ensuring interoperability are means to an end, not an end in themselves. The goal is nothing less than ensuring the provision of healthcare.