FHIR in Germany: Navigating ISiK, MII, and EHDS

Germany is one of the most consequential FHIR markets in Europe. Not because the standard is unfamiliar, but because national infrastructure embeds FHIR into legally regulated workflows. Supporting FHIR R4 is the starting point. It is not the finish line.

This piece maps the institutions, laws, profiles, and sector-specific obligations that decide what FHIR adoption actually means in Germany right now. We wrote it for senior decision-makers who are scoping interoperability work for hospitals, ambulatory and pharmacy vendors, digital health applications, and research data platforms.

The institutional landscape

Several coordinated bodies govern Germany's digital health infrastructure. Each shapes a distinct part of the FHIR ecosystem.

gematik GmbH is the national agency for the telematics infrastructure. Its scope covers the electronic patient record (ePA) — Germany's nationwide patient-controlled health record infrastructure — the electronic prescription system (eRezept), the electronic certificate of incapacity for work (eAU), secure healthcare communication services, and the ISiK hospital interoperability framework. gematik publishes technical specifications, with current interoperability specifications typically realized as FHIR implementation guides.

HL7 Deutschland e.V. maintains the German Base Profiles (de.basisprofil.r4). These provide foundational building blocks for national FHIR implementations by constraining international FHIR R4 for use in Germany. The base profiles define reusable patterns for core resources, data-types like identifiers or address structures, and terminology bindings, which are then adopted and extended by the responsible specification organizations such as gematik, KBV, or Medizininformatik-Initiative in their domain-specific implementation guides.

Kassenärztliche Bundesvereinigung (KBV) is the self-governing body of physicians and psychotherapists participating in Germany's statutory health insurance system and defines interoperability requirements for ambulatory care workflows. Its subsidiary Mio42 GmbH develops the Medical Information Objects (Medizinische Informationsobjekte, MIOs): standardized FHIR-based specifications for structured medical documents and patient-centered records, including the vaccination certificate, maternity record, and pediatric examination booklet.

The Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) plays a central role in Germany's digital health and interoperability landscape. Beyond operating the registry for digital health applications (DiGA), BfArM is responsible for national terminology and classification systems, including SNOMED CT, ICD-10-GM, OPS, and LOINC-related infrastructure. It also hosts the Forschungsdatenzentrum Gesundheit (FDZ Gesundheit), the federal infrastructure for secondary use of statutory health insurance data.

The Robert Koch Institute (RKI) runs DEMIS, Germany's national infectious disease reporting system, which relies on FHIR-based interfaces for interoperable public health reporting.

The Medical Informatics Initiative (MII), funded by the Federal Ministry of Education and Research (BMBF), coordinates the Kerndatensatz, a national core dataset for interoperable cross-institutional clinical research. The standard is implemented across the data integration centers of all German university hospitals and defines harmonized FHIR-based data structures organized into multiple domain-specific modules such as diagnoses, laboratory data, medication, consent, and genomics.

The Deutsche Rentenversicherung (DRV) operates rehabilitation reporting flows that lean more on FHIR every year. Across direct care, billing, public health, and research, those institutions are the ones deciding how FHIR applies on the ground.

The EU layer: EHDS

The European Health Data Space (EHDS) Regulation, which entered into force in March 2025, adds a new European interoperability layer on top of Germany's existing national frameworks. German FHIR-based initiatives such as ePA, ISiK, MIOs, and the MII core dataset will increasingly need to align with emerging EU requirements for cross-border exchange, semantic interoperability, and secondary use of health data.

EHDS has two pillars. The primary-use framework enables cross-border access to health data for care delivery and citizen access through MyHealth@EU. The secondary-use framework governs access to health data for research, innovation, public policy, and regulatory purposes through HealthData@EU and a designated Health Data Access Body in each Member State. Beyond interoperability, EHDS also aims to establish a harmonized European framework and single market for electronic health record systems and digital health services.

The technical interoperability foundation is the European Electronic Health Record Exchange Format (EEHRxF), a FHIR-based framework incorporating specifications such as the International Patient Summary (IPS). Regulatory obligations are introduced gradually over a phased implementation timeline:

• March 2027: Deadline for the European Commission to adopt key implementing acts defining the operational and technical details of the EHDS framework.
• March 2029: First priority group (patient summaries, ePrescriptions, eDispensations) must be exchangeable across Member States. Most secondary-use rules also start applying.
• March 2031: Second priority group (medical imaging studies and reports, lab results, hospital discharge reports) follows.

In parallel, EHR systems placed on the EU market will become subject to a new conformity assessment framework under EHDS. In practice, this introduces a regulatory interoperability and compliance regime comparable in spirit to CE marking for medical devices.

For Germany the institutional mapping is already visible. The national EHDS hub is being established jointly by gematik, BfArM, and the DVKA at GKV-Spitzenverband (the Deutsche Verbindungsstelle Krankenversicherung Ausland). gematik is responsible for the telematics-side technical infrastructure required to connect the German ePA ecosystem to European cross-border exchange services.

As EHDS implementation progresses, the ePA increasingly becomes part of a broader European interoperability network rather than a purely national infrastructure. On the secondary-use side, the Forschungsdatenzentrum Gesundheit (FDZ Gesundheit) at BfArM — established under the Gesundheitsdatennutzungsgesetz (GDNG) — is well positioned to support Germany's future Health Data Access Body responsibilities under EHDS.

For implementers, the consequence is dual-layer conformance. German Base Profiles, ISiK, KBV/MIO specifications, ePA, and MII Kerndatensatz all need to be reconciled with EEHRxF and emerging European core profiles. This alignment work is already visible: gematik's KIG, its interoperability coordination group, has identified EHDS compatibility as an explicit objective for the planned new German core profiles. If successful, these profiles could provide a shared national foundation that reduces project-specific mapping work between German and European specifications. In parallel, key national specifications — including gematik's ISiK framework, the MII Kerndatensatz, and KBV/MIO specifications — are increasingly being assessed and aligned with European requirements. For patient-summary scenarios, this also means alignment with IPS-based data models. Some of that mapping is straightforward. MII is already R4-based and comparatively close to international clinical exchange patterns. Other parts will require explicit translation work, particularly German-specific identifiers, address structures, extensions, and national value sets. For EHR and hospital information system vendors, the ability to manage both national and European compliance layers is likely to become an increasingly important factor in product design, certification, and procurement.

The legal framework that turns FHIR into a buying decision

The bodies described above do not operate in a vacuum. Their authority and market impact come from specific legal mandates. The German national layer rests on several key laws.

The Social Code, Book V (SGB V) is the foundation of statutory health insurance, and the source of many digital infrastructure obligations. Two paragraphs are particularly load-bearing:

• §301 SGB V governs structured billing and reporting from hospitals to statutory health insurers.
• §373 SGB V provides the legal basis for ISiK, gematik's mandatory hospital interoperability framework.

The Digital-Gesetz (DigiG), enacted in 2024, accelerated the digitalization of the statutory system. Its most visible consequence: the opt-out model for the electronic patient record. Every statutorily insured person now receives an ePA automatically unless they actively object. The ePA stopped being a technically available option. It became a default channel for clinical data.

The Gesundheitsdatennutzungsgesetz (GDNG), also enacted in 2024, governs the secondary use of health data. It strengthens the legal basis for the Forschungsdatenzentrum Gesundheit (FDZ Gesundheit) at BfArM and creates a regulated path for research, quality assurance, and other secondary uses of health data, including statutory insurance data and, under defined conditions, ePA-derived data.

The Krankenhauszukunftsgesetz (KHZG, Hospital Future Act) was the major funding instrument for hospital digitalization in Germany. Through the Krankenhauszukunftsfonds, it created a €4.3 billion funding framework for hospital digitalization, covering areas such as patient portals, digital documentation, medication management, clinical decision support, information security, and interoperability. Although the main funding period has passed, KHZG continues to shape hospital IT investment through implementation requirements, reporting obligations, and financial deductions for hospitals that fail to provide and use required digital services. On the hospital side, KHZG remains an important implementation and compliance driver for interoperable and FHIR-capable infrastructure.

Consolidated timeline

• January 1, 2024: eRezept becomes mandatory for statutory outpatient prescriptions and pharmacy dispensing.

• 2024: DigiG and GDNG enacted, providing the legal scaffolding for ePA für alle and secondary health data use.

• January 15, 2025: ePA opt-out rollout begins with automatic creation for non-objecting insured persons; nationwide availability for healthcare providers followed on April 29.

• 2025/2026: KHZG digitalization deductions are determined based on required digital services and begin to affect reimbursement for non-compliant hospitals.

• Ongoing: gematik continues to publish successive ISiK stages and module versions.

The profile stack

Most ambiguity in the German FHIR landscape comes from how profiles are layered. The practical question is which profile family applies in which context, and which national constraints take precedence.

The German Base Profiles, maintained by HL7 Deutschland, sit closest to the base specification. They provide reusable national building blocks for resources and data types, including identifiers such as KVNR, BSNR, and LANR, address structures, and terminology bindings. Almost every downstream profile family builds on them.

ISiK profiles, published by gematik, define the mandatory hospital interfaces under §373 SGB V. They build on the German Base Profiles and add hospital-specific constraints for areas such as patient administration, encounters, diagnoses, procedures, and medication.

KBV is central to Germany's statutory outpatient care system and the professional rules around ambulatory prescribing, including the ambulatory workflow context of eRezept. In practice management systems, KBV-related requirements are a dominant conformance family. The technical E-Rezept infrastructure and FHIR-based exchange specifications, however, are defined within the gematik/TI specification landscape.

ePA and eRezept profiles define data flows and APIs within the telematics infrastructure. For eRezept, the profile stack is split: KBV defines the prescription data profiles for the electronic medicinal prescription, while gematik defines the eRezept workflow, TI infrastructure, and FHIR-based exchange specifications. Together, these cover prescription data objects, ePA document and metadata exchange, medication-related data, and other TI-specific services. Related TI applications and artifacts include the electronic medication plan (eMP), the emergency data set (NFD), and the electronic certificate of incapacity for work (eAU), although these should not all be treated as a single profile family.

MIOs, developed by Mio42 on behalf of KBV, are standardized FHIR-based specifications for structured medical documents in the ePA context. They build on German national profiling conventions, including the German Base Profiles, and define patient-centered record content such as vaccination, maternity, dental bonus, and pediatric examination documentation.

The MII Kerndatensatz defines the FHIR profiles used by data integration centers across German university hospitals for research and secondary use. It is a central conformance target for academic clinical research data exchange in Germany.

RKI DEMIS defines the FHIR profiles for infectious disease reporting under the Protection Against Infection Act (Infektionsschutzgesetz, IfSG), enabling standardized electronic reporting to public health authorities.

Sector-by-sector obligations

The table below summarizes how the institutional, legal, and profile layers stack up by sector. It is not exhaustive (most production systems span several rows), but it captures the dominant compliance vector for each kind of buyer.

Hospitals: the KHZG-driven decade

For hospitals, FHIR adoption is shaped less by a single mandate than by overlapping pressures: KHZG-funded digitalization projects, TI/ePA integration, research requirements, vendor roadmaps, and the emerging ISiK conformance framework. KHZG-funded services — including patient portals, electronic medication management, clinical decision support, structured documentation, information security, and interoperability — created a major investment push for structured hospital IT. Not every KHZG requirement maps directly to FHIR or ISiK, but many resulting procurement and integration decisions favor systems that can support structured, interoperable, and increasingly FHIR-capable data flows.

ISiK is structured in successive stages and modules rather than as a single static profile set. It is gematik's FHIR-based specification framework for open and standardized hospital interfaces under §373 SGB V, covering areas such as patient administration, clinical documentation, medication, diagnostics, forms, and other care-related workflows. The exact applicability depends on the relevant ISiK module, software category, and confirmation requirements.

§301 SGB V adds a separate administrative billing and reporting layer. It is not a FHIR mandate, but it shapes hospital data models and integration requirements through standardized billing, department, and payer-facing reporting structures. In practice, hospitals often need to reconcile these administrative structures with ISiK-based clinical interfaces and internal system models.

Hospitals that participate in research carry an additional layer. Their data integration centers typically need to support the MII Kerndatensatz for cross-institutional research and secondary use. Research-side and care-side data flows do not automatically share the same infrastructure or conformance targets, so academic medical centers often end up managing overlapping FHIR responsibilities across care delivery and research.

Ambulatory and pharmacy

For ambulatory physicians, the operative obligations come through participation in Germany's statutory health insurance system. The eRezept mandate, in force since January 2024, requires structured electronic prescription workflows. Its FHIR profile stack is shared across several actors: KBV defines the professional prescription data profiles for ambulatory prescribing, while gematik defines the E-Rezept workflow, TI infrastructure, and FHIR-based exchange specifications. Practice management systems are therefore shaped by KBV requirements, eRezept workflow integration, and gematik/TI conformance.

The ePA adds a second layer. Medication-related ePA services, including the electronic medication plan context, are implemented through FHIR-based specifications and affect how physicians and pharmacists interact with structured medication information. MIOs define standardized FHIR-based document structures for specific ePA use cases. Depending on which MIOs a practice system supports, they can add additional profile requirements beyond eRezept and core ePA integration.

Pharmacies sit at the dispensing endpoint of eRezept. They must support the relevant E-Rezept and TI specifications for retrieving prescriptions, redeeming them, dispensing medication, handling substitution where applicable, and producing the required dispense and billing-related data flows.

DiGA: digital health applications

Digital Health Applications listed by BfArM under §33a SGB V are reimbursed by statutory insurance. They must meet defined interoperability requirements, including machine-readable data export and ePA-related data transfer where applicable. Translation: DiGA vendors need structured export capabilities, increasingly aligned with FHIR-based specifications such as the DiGA/MIO Toolkit, so app-generated data can be reused in the ePA context or by treating providers.

Public health, rehabilitation, and cross-sector care

Infectious disease reporting flows through RKI DEMIS using FHIR profiles for standardized electronic reporting under the Protection Against Infection Act (Infektionsschutzgesetz, IfSG). Healthcare providers and laboratories submitting notifiable conditions have to conform to the relevant DEMIS profiles.

Care doesn't stop at sector boundaries. Transitions between hospitals, ambulatory practices, rehabilitation, and home care require interoperability across systems with different legal, organizational, and technical constraints. Where FHIR is used, shared national profiling conventions such as the German Base Profiles provide a common foundation, but context-specific specifications or extensions are usually still needed.

Research and secondary use

The Medical Informatics Initiative defines the Kerndatensatz, a national core dataset agreed across German university hospitals and implemented through FHIR profiles for cross-institutional research and secondary use. Data integration centers at university medical sites transform and harmonize clinical routine data according to MII specifications and make it available for federated feasibility queries and research data access through the Forschungsdatenportal Gesundheit (FDPG), under the applicable governance and consent frameworks.

The GDNG and the FDZ Gesundheit at BfArM extend the secondary-use model beyond academic medicine into statutory insurance data and, under defined conditions, ePA-derived data. They open structured pathways for research and other public-interest uses of health data. Read MII and GDNG side by side and the direction is clear: FHIR has become a central interoperability substrate for academic medical research in Germany, while secondary-use infrastructure is expanding into the statutory and national health-data domain. For university hospitals and MII-connected research sites, this creates an additional FHIR conformance layer alongside care-side obligations such as ISiK.

Terminology: an underestimated constraint

Terminology binding is one of the most frequent sources of late-stage non-conformance in German FHIR projects. The relevant code systems include:

• ICD-10-GM and OPS, the German modifications of ICD-10 and the procedure classification, maintained by BfArM.

• ATC (anatomical-therapeutic-chemical), and PZN (Pharmazentralnummer) for pharmaceutical classification and product identification.

• LOINC, especially for laboratory results and structured clinical data, including document section coding.

• SNOMED CT, available under Germany's national license since 2021 and administered through BfArM as the national release center; it is increasingly mandatory in MII and other semantically rich profiles.

• ZTS (Zentraler Terminologieserver) which provides FHIR terminology resources used across German implementation guides, including value sets, code systems, ICD-10-GM, OPS, and other terminology artifacts governed or released by national terminology owners such as BfArM.

Pick infrastructure without a serious answer to terminology services (value set expansion, code validation, code translation, version management), and project rework becomes the most reliable forecast in this market.

Cross-cutting compliance: hosting, security, and interconnection

For German health data, the technical conformance question is inseparable from compliance posture. Three constraints recur in nearly every procurement:

• BSI IT-Grundschutz and the BSI C5 (Cloud Computing Compliance Criteria Catalog) attestation, especially for cloud-hosted infrastructure. Under §393 SGB V, cloud services used in healthcare require a C5 attestation or comparable certification.

• EU data processing and hosting expectations, with stricter German-hosting or sovereignty requirements depending on the use case, especially for ePA- or TI-adjacent data flows.

• GDPR (DSGVO), applied in healthcare with sector-specific guidance from the Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) and the state data protection authorities.

Connection to the telematics infrastructure brings extra dependencies: the Konnektor or TI Gateway, eHBA (electronic health professional card), SMC-B (institution card), and the KIM and TI-Messenger families for secure messaging. FHIR systems used in regulated workflows are usually operated alongside, sometimes behind, these components.

What this means for implementation infrastructure

Reading the German landscape side by side, a few structural requirements emerge for the FHIR backend that sits behind any system serving this market. They aren't abstract preferences. They're the failure modes that show up in production when teams underestimate how much of the German market sits inside regulated workflows.

• First-class support for layered profile validation. A hospital system may need to validate similar clinical data against different profile families depending on the workflow — for example ISiK for care-side interfaces and MII for research-side exchange — with the German Base Profiles in the dependency tree. Validation has to be deterministic and performant with hundreds of profiles loaded simultaneously.

• EEHRxF and EHDS interoperability components for dual-layer conformance. EHDS is not only a cross-border exchange requirement. Electronic health record systems placed on the EU market will need to support the European interoperability and logging components required under the EHDS framework. For German implementations, this means that national profile families such as ISiK, ePA, KBV/MIO, and MII must be designed with a path toward EEHRxF and emerging European core profiles. For patient-summary scenarios, this means alignment with the European Patient Summary and its IPS-based data model.

• Profile package management and version pinning. German FHIR profile packages are updated frequently across different specification families. Production systems need to load specific package versions, switch them per tenant or workflow, and reproduce historical validations on demand.

• Native terminology services covering German code systems. ICD-10-GM, OPS, SNOMED CT under the national license, LOINC, ATC, and ZTS-provided terminology resources all need to be queryable, expandable, versioned, and available to the validation pipeline.

• Multi-tenant architecture for vendors operating services across multiple practices, hospitals, or DiGA customer environments under a single operational footprint.

• Compliance-grade hosting in Germany or the EU, with C5 and BSI IT-Grundschutz aligned operational practices.

• Audit logging, consent representation, and SMART on FHIR support, including reproducible access logs, machine-readable consent states, and standards-based third-party app access where applicable.

• A clear path for connecting to and operating alongside telematics infrastructure components when the workflow demands it.

Closing

Germany rewards teams that approach FHIR not merely as a technology layer but as part of the compliance substrate. The institutions, laws, and profile families described here are not separate concerns. They are the same problem, viewed from different angles. The readiness of the underlying infrastructure determines how much of that complexity reaches application teams, and how much of the budget can go into the user-facing work that actually differentiates a product.

At Gefyra, we work directly in the German and European FHIR specification landscape. Our team has contributed to and advised on national specification work including ISiK, further gematik specifications, the German Base Profiles, KBV/Mio42 specifications, and the MII core dataset. We are also deeply involved in the European interoperability context, including implementation guide facilitation and standards coordination through HL7 Europe working groups. That perspective allows us to assess FHIR infrastructure independently of any single vendor stack.

At Health Samurai, we build and operate Aidbox, the FHIR platform behind a number of regulated healthcare workloads in Europe and worldwide. Scoping FHIR infrastructure for the German market, whether for a hospital, a practice-management or pharmacy system vendor, a DiGA, or a research data platform? Get in touch with Health Samurai for Aidbox infrastructure, or with Gefyra for independent specification, profiling, and German/EU interoperability guidance. We're happy to walk through profile coverage, terminology support, hosting options, and reference architectures.