FHIR is the de facto standard for new interfaces in German healthcare. Yet there are clear differences between published profiles, legal obligations, and the interfaces actually in use. An overview of who sets the requirements, which of them are binding, and what has reached everyday care. As of October 2026.
What a profile is
The international FHIR standard defines general resources such as Patient, Observation, or MedicationRequest. A profile constrains a resource for a specific purpose: which fields are mandatory, which code systems apply, which German specifics are represented. Profiles can build on each other: a general profile defines the basics, a more specific one constrains it further for a concrete use case. The KBV's e-prescription profiles, for example, build on HL7 Germany's base profiles via the KBV's own base profiles. Profiles are bundled into packages and usually published on Simplifier. An implementation guide (IG) describes which use case the profiles serve and how they fit together.
Who publishes which profiles
- HL7 Germany: the base profiles for identifiers such as KVNR, IKNR, and LANR, German addresses and names, and code systems such as ICD-10-GM and OPS. They are not binding themselves, but form the foundation of almost all other German profiles.
- gematik: ISiK for hospitals, in stage 5 with ten modules ranging from the base module through document exchange, scheduling, and medication to transfers between intensive care and regular wards. Also ISiP for nursing care, the FHIR interfaces of the electronic patient record (ePA) with its Medication Service, the workflow profiles of the e-prescription, and the FHIR directory of the TI-Messenger.
- KBV and mio42: the medical information objects (MIOs) for the ePA, including the vaccination record, maternity record, child health record, dental bonus booklet, patient summary, and care transition form. Also the prescription profiles of the e-prescription and the electronic sick note (eAU).
- German Social Accident Insurance (DGUV): its own base profiles for occupational accidents and diseases, for example for designated accident insurance physicians (Durchgangsärzte), accident events, employers, and accident insurance institutions.
- Medical Informatics Initiative (MII): the core data set for research at university hospitals, with annual releases and modules for person, diagnosis, procedure, lab, medication, and consent, among others.
- RKI and gematik: DEMIS for notifications under the Infection Protection Act, from lab results to bed occupancy.
Most of these profiles build on HL7 Germany's base profiles, but not on the same version. ISiK stage 5 requires version 1.5.4, the current KBV e-prescription profiles still 1.5.2. Release cycles differ too, annual at the MII and in stages for ISiK, and there are transition periods in which old and new versions apply in parallel.
A shared foundation does not make the profiles compatible either. A lab value is subject to different profiles, mandatory fields, and terminology requirements in ISiK and in the MII core data set. Anyone exchanging data between a hospital information system, the ePA, and a research platform has to account for these differences and translate between the profiles.
How a profile becomes binding
Publishing a specification does not automatically make it binding. It usually becomes binding through Section 385 SGB V: the Competence Centre for Interoperability at gematik proposes it, and the Federal Ministry of Health adds it by ordinance to Annex 1 of the interoperability governance ordinance, with a deadline and the affected systems. It currently has four entries:
- The ePA electronic medication list, since 15 January 2025
- The ePA Medication Service for practice, hospital, and pharmacy systems, by 31 December 2026
- ISiK stage 5 for hospital information systems, by 31 May 2027
- The ePA Medication Service for nursing care systems, by 30 September 2027
Three of the four entries concern medication. For ISiK, the ordinance is not the first obligation. Vendors already had to implement and certify earlier stages, stage 2 for example by 1 July 2024. Until now, gematik set those deadlines itself. Stage 5 is the first to go through the ordinance, against the opposition of the German Hospital Federation.
Whether a product meets the requirements is checked in a conformity assessment under Section 387 SGB V. The consequences differ by sector. Medical practices may only bill the Associations of Statutory Health Insurance Physicians using conformity-assessed systems (Section 372). For the systems covered by Section 373, hospitals may only use conformity-assessed products, but a comparably direct link to reimbursement is missing. Some applications have their own legal basis, such as the e-prescription in Section 360 SGB V or DEMIS in the Infection Protection Act.
What is actually in production
Broad production use is mostly limited to applications with an obligation for all parties involved and a simple workflow. According to the ABDA, around 582 million e-prescriptions were redeemed in 2025. The eAU, DEMIS lab notifications, and the ePA medication list are also part of daily operations. The MII core data set is in use at the data integration centres of university hospitals. Through the German Portal for Medical Research Data (FDPG), researchers run feasibility queries against it across sites and request data and biosamples.
Many other profiles look different. Several MIOs are defined but not yet used in structured form in the ePA, and according to gematik there is no fixed timeline. For ISiK, a working group of the Interop Council found in early 2024 that it was hardly used in production environments, although all vendors of relevant systems had been certified. Only one of the surveyed hospitals reported using it. The paper cites, among other reasons, uncertainty over whether hospitals are required to use ISiK and the lack of a business case. According to the authors, the survey is not representative. Electronic prescribing of digital health applications (DiGA) remains voluntary for the time being.
The pattern is clear: a profile on its own changes little. Interoperability only emerges when at least two parties want or need to exchange data. With the e-prescription, practices, the central service, pharmacies, and insurers are all obliged at the same time, and the process only works through the exchange. With ISiK, mainly the providing side has to demonstrate the interface, and nobody is required to call it. The German Hospital Federation itself speaks of a mutually reinforcing weakness of supply and demand.
What comes next
- The European Health Data Space requires cross-border exchange of patient summaries and e-prescriptions from March 2029, and of lab results, discharge reports, and imaging from March 2031. For vendors, the key point is that systems handling electronic health records, including hospital and practice systems, will then need a component for the European exchange format and CE marking. The draft of ISiK stage 6 already aligns individual profiles with European ones. Germany's implementation is set out in the Act on Data and Digital Innovation in Healthcare (GeDIG), with the Bundestag's final reading expected in November.
- To counter the fragmentation, the Competence Centre for Interoperability is working on core profiles as a shared, binding foundation for all German FHIR specifications. The baseline analysis calls, among other things, for aligning release cycles with the implementation deadlines of binding specifications. A governance white paper is open for comment from 19 October to 16 November 2026.
- All specifications of national relevance are based on FHIR R4 today. The major publishers deliberately skipped R5 in 2024. FHIR R6 is seen as the potential next leading version and is expected at the end of 2027 at the earliest. There is no joint migration strategy yet, but new specifications are already to be checked against R6.
A published profile does not by itself create interoperable data exchange. What matters are binding requirements, their implementation in primary systems, and actual use of the interfaces. Anyone planning a FHIR interface today should therefore clarify early which profiles and versions are actually required, and plan the translation between them from the start. How this affects internal data storage is covered in our article on choosing a data model for health data.