We would like to quickly introduce the topic of interoperability in DiGA development with a small example:
“Μια DiGA πρέπει να πληροί ορισμένες απαιτήσεις διαλειτουργικότητας.”
Do you understand this sentence? Unless you speak Greek, probably not. You therefore need an English translation. That would be your interoperability requirement for this blog article. If we implement this requirement, the sentence reads as follows:
“A DiGA must meet certain interoperability requirements.”
Just like this blog article, a DiGA must also be compatible with adjacent systems and its data exchange must follow specific rules: structural, syntactic, semantic and organizational interoperability. Find out what these terms are all about here. Read on and get a practical insight into the implementation of interoperability requirements for a DiGA.
Overview
- DiGA interfaces to other systems
- Digital identity/health ID
- Conclusion
DiGA interfaces to other systems
Depending on the intended use and functional scope of a DiGA, it can have interfaces to numerous other systems. For example, a DiGA could read in data from Google Fit or Apple Health, transfer data on a clinical picture to the electronic patient record (ePA), or inform a treating doctor about a patient’s treatment progress. Not every interface has to be designed to be interoperable (e.g. with other apps). There are only legal requirements at three interfaces. These are described in more detail in the following chapter.
Which interfaces must be designed to be interoperable?
If you consider the core task of a DiGA, which is to optimize the quality of care for patients, it is easy to understand where interoperability is particularly important. The DiGAV specifies exactly which interfaces must be designed to be interoperable. You can find out more about DiGAV in this article. Annex 2 to the DiGAV is particularly important for the implementation of the requirements.
Doctors, psychotherapists and the patients themselves are of great importance in ensuring the provision of care.
1. A data export in human-readable, printable format must therefore be made possible.
However, not only people, but also other healthcare systems, such as the ePA, must be able to use the data from the DiGA in a meaningful way.
2. Also a data export in an interoperable format must be enabled. Data is transmitted in accordance with a definition for semantic and syntactic interoperability. The KBV’s MIO DiGA-Tookit is particularly important in order to be able to transfer data to the electronic patient file (ePA) in the future, for example.
DiGAs that rely on data from sensors and other measuring devices, for example, must also create an interoperable interface here to enable hardware manufacturers to connect to the DiGA.
3. Therefore, an interoperable interface to wearables and other medical devices is also mandatory.
Data export in human-readable, printable format
Patients and their healthcare providers must be able to understand and reuse the care-relevant data from a DiGA. For this reason, the DiGAV also requires an option at this interface to provide data in a human-readable, printable format. It is important to note that the data export can be initiated via DiGA itself, but does not have to be carried out by DiGA.
A button that initiates the download of an encrypted data packet, which can later be accessed via a server, is also regarded as a legitimate implementation. An example of a data export in human-readable, printable format would be the creation of a PDF file containing all blood glucose readings from the DiGA and other relevant data.
QuickBird Medical Tip: Provide the relevant data in a compact and comprehensible form. Consider which data is useful in a care scenario in which the DiGA is used. What data is important for patients and doctors and how can it be presented in an understandable way?
Apart from the legal interoperability requirements at this interface, you can gain a significant competitive advantage here. If your DiGA can be easily integrated into the daily routine of doctors and psychotherapists and provides tangible added value, it will also be prescribed more frequently. The more compatible your DiGA is with existing healthcare processes, the better.
Data export in interoperable format (ePA)
Not only people, but also other systems are part of the healthcare system and want to continue using the data from your DiGA. In the future, this will primarily be the electronic patient file (ePA), which must be able to obtain data from the DiGA in an interoperable format. In order to meet the requirements of interoperability in the healthcare sector, it makes sense to agree on uniform standards that are used for data exchange. These standards are defined by standardization organizations and specify the format and semantics of data streams. An adaptation of a standard for a specific country or field of application is called a profile.
For precisely this reason, there are concrete specifications as to which formats are permitted for data export. It is not enough for your DiGA to simply provide certain data, the format is also crucial. As a DiGA manufacturer, you now have to start looking for a suitable data format, but where should you start looking?
Here is a short itinerary with the most important stops:
- First of all, search for a medical information object (MIO) defined by the KBV that matches your use case. The DiGA Toolkit is now available there.
- As long as there is no suitable MIO, you currently have two options:
- You can use another existing open, internationally recognized interface or semantic standard (e.g. HL7 FHIR).
- You can define your own profile using one or more existing open, internationally recognized interfaces or semantic standards. This profile must then be published in a recognized directory (e.g. FHIR Registry) for free use.
Medical Information Objects (MIO) – DiGA Toolkit
An MIO is a data format defined by the KBV for medical information. New MIOs for various types of information are constantly being developed with the major aim of ensuring optimum data exchange between all systems involved in medical care. The interface to the ePA in particular is one of the main reasons for the introduction of MIOs.
The fact that manufacturers use a published interoperability standard is a good thing. At least the form of data exchange is transparent. Of course, it is even better if the selected standard also matches the standard of the ePA or other systems. A direct connection is therefore possible. Defined MIOs should make this possible.
One example of an MIO is the electronic vaccination record. Its structure is precisely defined and stipulates that new vaccination entries must comply with a clear format in order to be integrated into the vaccination record. The MIO defines which information must be included and in which format it must be available.
DiGA Toolkit, which was specially developed to implement the interoperability requirements for DiGA, is of particular interest for DiGA.
What data must be taken into account for interoperable data export?
Theoretically, countless different types of data can be exported from an app. For interoperable data export, however, only data based on the intended use by users must be taken into account (see Section 4 (2) sentence 1 no. 1 DiGAV). More specifically, this concerns the following data:
- Data entered by the users
- Data collected via devices and sensors
- Data on the user and the context of use (if available)
- Information on DiGA and metadata for data export
The following data does not have to be exportable as separate objects:
- Derivations on recorded data that serve exclusively to ensure the safe operation of the DiGA.
- Statistical procedures based on the data, which are only stored to prove the positive supply effect.
Interface to wearables
This interface is not available on all DiGAs and is therefore not relevant for all manufacturers. However, if medical devices or other wearables are involved in the function of the DiGA, interoperable data exchange must also be ensured at this interface. The reason for this is quite simple: it must be left up to the patient to decide which device he or she wants to use. This requires hardware manufacturers to be clear about the data format in which they communicate with the DiGA. This is the only way to develop devices that can also interact with the DiGA.
DiGA manufacturers have the following options for implementing interoperability at this interface:
- Search for an open, documented profile of the ISO/IEEE 11073 standard (Medical Device Communication).
- Search for a health device profile specified by the BluetoothSIG.
- Search the vesta directory for a profile that is registered via ISO/IEEE 11073 or HL7 FHIR.
- Create your own specification and apply for its inclusion in the vesta directory. Use the FHIR Personal Health Device Implementation Guide as a guide.
QuickBird Medical Note: In addition to an interoperable interface, your DiGA may also offer non-interoperable interfaces. This may be the case, for example, if you need to integrate a wearable that does not offer data transmission in a corresponding format. You may maintain the interface to this device, but you must also create an interoperable interface for other devices.
Does a DiGA also have to offer an interoperable interface to devices whose data is read in via Apple Health or Google Fit? No, in this case your DiGA does not have to offer an interoperable interface to the device itself.
Manufacturers of medical aids and implants will also be held accountable for interoperability in the future. Devices and implants that send patient data to a manufacturer’s backend or a third party must offer an interoperable interface for DiGA from 2024. This should make it possible for DiGA to access data from different sources. You can read more about this here: Guide to §374a SVB V – Interoperability for DiGA, aids & implants
At which interfaces is the interoperable design optional?
DiGAs can, but do not have to, offer an interoperable interface to all neighboring systems. For example, a DiGA can obtain data from other apps, such as Apple Health, without having an interoperable interface. Even direct data exchange between DiGA and other medical apps does not necessarily require an interoperable interface. Please refer to the illustration in the chapter “Interfaces from DiGA to other systems”. There you can see which interfaces of your DiGA do not need to be designed to be interoperable.
Digital identity/health ID
From 01/01/2024, a DiGA must offer the authentication of a user with a digital identity (health ID). Even if these requirements do not formally fall under the topic of “interoperability”, they still represent another necessary interface to other systems in the healthcare sector.
We are happy to support you with the implementation. Just get in touch with us!
Conclusion
At first glance, interoperability in DiGA development is an opaque undertaking. If you take a closer look, however, three central points can be derived:
- A person must be able to understand the data of a DiGA (human readable)
- Other systems (in particular the ePA) must be able to understand data from a DiGA
- Manufacturers of sensors and measuring devices need to know the format in which data is exchanged with the DiGA.
When searching for suitable interoperable file formats, the first port of call for you as a manufacturer are the MIOs of the KBV (in particular the DiGA Toolkit).
Do you need a more global overview of interoperability in the healthcare sector? Then read on here.
Any further questions?
As a service provider for the development of DiGA and medical apps, we are very familiar with the current legal requirements for DiGA. We are happy to support you with the implementation of all interoperability requirements (e.g. connection to the ePA). Contact us now for a non-binding consultation:
Phone: +49 (0) 89 54998380
Email: kontakt@quickbirdmedical.com
