The previous article described terminology drift — a universal failure mode where FHIR data becomes non-conformant because external code systems change, independent of anything in your stack. That problem affects every FHIR system. But it gets multiplied in markets with multiple parallel FHIR initiatives — and Germany has one of the densest, most overlapping FHIR landscapes in Europe.
When I was mapping a clinical documentation system's forms to FHIR at Uniklinik Cologne, one thing became clear quickly: there is no single "German FHIR standard." There are several. They use the same base technology, they share some terminology bindings, and they partially overlap in what they define. But they are maintained by different bodies, serve different purposes, and have different conformance requirements.
Navigating this as a developer is genuinely hard. And it gets harder when you realize that a large German university hospital may need to satisfy several of these simultaneously — sometimes for the same clinical data and resource families.
This article is a map of the landscape. Not exhaustive — but enough to understand why FHIR validation in Germany is more complex than in most other markets.
gematik: the central authority
gematik is Germany's national digital health agency. It is the authority most directly relevant to hospital IT teams and KIS vendors because it sets the requirements that carry legal force.
gematik is responsible for the Telematikinfrastruktur (TI) — the national healthcare network — and for ISiK, the hospital interoperability standard mandated under §373 SGB V. When a KIS vendor needs to pass a certification, they're going through gematik's Bestätigungsverfahren, the formal confirmation process.
ISiK: the mandate every hospital touches
ISiK — Informationstechnische Systeme im Krankenhaus — is the technical standard that hospital information systems must implement under §373 SGB V.
It defines which FHIR resource types must be supported, what profile constraints apply, and which terminology bindings are required — ICD-10-GM for diagnoses, OPS for procedures, SNOMED CT, LOINC. ISiK is staged: Stage 1, 2, 3 — with Stage 5 already published and its binding implementation timeline being formalized. (Stage 4 was published but discontinued before becoming mandatory; the next article explains why.) Each stage adds modules and tightens requirements. The published implementation guides are available through gematik's ISiK specification repository and rendered implementation guide index.
The Krankenhauszukunftsgesetz (KHZG), Germany's €4.3bn hospital digitalization fund, accelerated ISiK adoption significantly. Hospitals that received KHZG funding invested in new clinical systems, many of which brought ISiK compliance as a core requirement. KHZG didn't define technical standards itself, but it created the financial momentum that made ISiK implementation urgent.
For KIS vendors and hospital IT, ISiK is the primary compliance target. Legally binding, formally certified, profiles published and maintained by gematik.
Adjacent to ISiK, gematik also maintains ISiP — Informationstechnische Systeme in der Pflege. ISiP is not the same implementation track as ISiK, but it shows the same pattern extending into nursing care: FHIR-based interfaces, a formal Bestätigungsverfahren, and another domain where German primary systems need to track profile requirements over time.
MII: a parallel standard for research
The Medizininformatik-Initiative — MII — is a separate program funded by the Federal Ministry of Education and Research (BMBF). Its goal is different: enabling clinical research by making hospital data queryable and comparable across institutions.
The MII has established Data Integration Centers (DIZ) across Germany's university medicine landscape and selected non-university partners. Each DIZ implements the MII core dataset — the Kerndatensatz (KDS) — as FHIR R4 profiles across modules: Person, Fall, Diagnose, Prozedur, Laborbefund, Medikation, Biobank, and Bildgebung.
The KDS itself is versioned and evolving. The MII already publishes a 2026 generation of the KDS base implementation guide, which is exactly why MII conformance cannot be treated as a one-time mapping exercise.
Here is where it gets complicated: the MII profiles cover many of the same resource types as ISiK. Patient demographics. Encounters. Diagnoses. Lab observations.
They are not the same profiles.
The overlap problem — with a concrete example
Take the Patient resource. Both ISiK and MII define profiles for it. ISiK's Patient profile focuses on clinical identification: it requires specific German identifier types — the krankenhausinterne Patientennummer (hospital-internal ID), and provisions for GKV/PKV insurance identifiers as defined by gematik. These are the identifiers a clinical system needs to function operationally.
The MII Person module has different priorities. It includes representations for research data infrastructure, including pseudonymized patient data. In that context, identifiers and links are governed by research, privacy, and federation requirements — not by operational hospital identification alone.
A Patient resource built to satisfy ISiK's clinical identifier requirements may not satisfy MII's research and pseudonymization constraints. A research-optimized MII Person representation may not carry the identifiers ISiK requires for clinical operation. Both can be valid FHIR. Both describe the same clinical reality. They are not interchangeable without transformation.
This is the pattern across the overlapping modules: same resource type, different constraints, different terminology handling, different must-support requirements — maintained by different governance bodies on different release schedules.
A university hospital with a DIZ must satisfy both. The ISiK certification tells gematik the KIS can operate interoperably. The MII implementation tells the research network the data can be used for federated queries. Both are real requirements. Neither waives the other.
DiGA: a note
The Digitale Gesundheitsanwendungen (DiGA) regulation — §139e SGB V — created a prescription pathway for digital health apps reimbursed by statutory insurers. DiGA is not the same compliance track as ISiK or MII, but it matters because German digital health regulation increasingly expresses interoperability expectations through FHIR-based mechanisms and validation checks.
BfArM also publishes FHIR implementation-guide material for data in the DiGA, DiPA, and HIIS directories. For hospital IT teams and KIS vendors, this is currently less directly relevant than ISiK — but worth tracking as patient-facing apps, nursing applications, device directories, and clinical infrastructure become more tightly connected.
What this means for validation
The German FHIR landscape is not a single finish line. It's a multi-track environment where the same clinical data may need to be represented and validated against different profile sets, maintained by different bodies, for different consumers.
This has a direct consequence for validation. It's not enough to validate a Patient resource and declare it conformant. You need to ask: conformant to which profile? For which consumer? At which point in time?
A hospital that validates only for ISiK knows nothing about its MII conformance posture. A DIZ that validates only for MII knows nothing about how its data would fare in an ISiK integration. And both profile ecosystems evolve independently — so a resource or dataset that satisfies both today may satisfy only one of them after the next profile update.
This is the defining feature of the German FHIR validation challenge: multiple real standards, multiple real enforcement bodies, partial overlap, independent evolution. CI validation against a single profile set doesn't capture this. Continuous validation against all relevant profiles does.
The next article goes into the ISiK mandate specifically — what §373 SGB V actually requires, and what the Bestätigungsverfahren snapshot doesn't cover.