ISiK, MIO, MII and HL7 DE: four German FHIR families that are not one API
A product-team map of ISiK (hospital interface), MIO (KBV ePA objects), MII Kerndatensatz and HL7 DE Basisprofile — plus the gematik INA statement that Germany stays on FHIR R4 until a national calendar exists.
Ala Ben Aicha
Direct answer
ISiK is the mandatory German hospital FHIR interface. MIO, MII Kerndatensatz and HL7 DE Basisprofile are different products. gematik INA states German national specs stay on FHIR R4 until a coordinated calendar exists.
Four names, four buyers
German FHIR conversations collapse four programmes into “the German profile”. They do not share a CapabilityStatement, a legal mandate, or a package id. Implement the family the contract names.
| Family | Owner / home | Canonical / package | What it is | What it is not |
|---|---|---|---|---|
| ISiK (Informationstechnische Systeme im Krankenhaus) | gematik; Fachportal ISiK; Simplifier ISiK Stufe 5 | https://gematik.de/fhir/isik/; package family de.gematik.isik. Stufe 5 published 1 July 2025 |
Mandatory hospital FHIR REST interface under §373 SGB V: Basis (Patient, Encounter, Condition, Procedure, Coverage, …) plus modules (medication, documents/MHD, appointments, vitals, …) | Not an ePA MIO, not a university research dataset, not a CE certificate from this article |
| MIO (Medizinische Informationsobjekte) | KBV / mio42; mio.kbv.de | MIO project IGs on mio.kbv.de (example: structured objects such as the dental bonus booklet) | Structured FHIR objects for the ePA (electronic patient record) used in ambulatory / record-sharing workflows | Not ISiK. A hospital ISiK Patient is not a MIO Composition |
| MII Kerndatensatz | Medizininformatik-Initiative; KDS Basis 2026.0.0 | Package de.medizininformatikinitiative.kerndatensatz.base#2026.0.0 on FHIR R4 |
Research core dataset for Data Integration Centres: Person, Fall, Diagnose, Prozedur, Labor, Medikation, … | Not a hospital production interface. Overlapping resource types, different profiles |
| HL7 DE Basisprofile | HL7 Deutschland; Basis DE | de.basisprofil.r4 (INA lists the Basisprofile as the national foundation; Simplifier current sequence includes 1.6.0) |
National base for identifiers, address, and terminology that ISiK, MIO and MII all build on | Not itself the ISiK or MIO conformance target |
Primary sources: gematik ISiK pages, INA “Verwendung von FHIR in Deutschland”, INA Top 20 IGs.
The identifier: Versicherten-ID / KVNR
Country-specific identifier for German Patient resources is the Krankenversichertennummer (KVNR), the GKV Versicherten-ID. HL7 DE and downstream profiles use:
http://fhir.de/sid/gkv/kvid-10
That is a 10-character identifier with DE Base invariants. It is not an IHI, not an NHS number, and not an MRN. PKV and hospital-internal patient numbers are additional slices — ISiK Basis defines how they appear on ISiK Patient. Do not publish a real KVNR in examples; keep the system URL and a dummy value in fixtures.
IHE MHD shows up in ISiK document modules. That does not make a German hospital an XDS affinity domain. For MHD/XDS patterns in European communities, see the IHE profiles article.
gematik INA: no automatic R4 → R5 step
In January 2024 the leading German specification bodies — including mio42, KBV, HL7 Deutschland, gematik, MII, RKI, GKV-Spitzenverband, the Interop Council and the national coordination office — published a joint statement on INA:
- Nationally relevant German FHIR specifications are on FHIR 4.0.1 (HL7 DE Basis, KBV including eAU/eRezept, MIO ecosystem, ISiK, MII Kerndatensatz, DEMIS, and others).
- A migration from R4 to R5 is not required from those actors’ point of view.
- A move to a new FHIR release should happen only when there is a coordinated calendar covering all nationally relevant FHIR specifications.
- New projects should continue to use 4.0.1 until that calendar exists.
- If an R5 element is needed, use preadoption, not a unilateral server upgrade.
INA’s 2026 FHIR R6 roundtable does not cancel that R5 statement. As of the September 2026 INA text, organisations are open to discussing a future R6 path once a stable R6 is predictable; they are not running a national R5 cutover. Do not bid “we will deliver ISiK on R5” unless the written ISiK package you must pass is R5 — today it is not.
What to implement first
- If the buyer is a hospital KIS / subsystem under §373 SGB V: ISiK Basis (and the modules named in the contract), FHIR R4, KVNR + hospital Patient identifier, CapabilityStatement that instantiates the ISiK canonicals. gematik confirmation is a separate procedure; this article is not that procedure.
- If the buyer is an ePA / vendor of structured objects: the named MIO IG, not ISiK Basis.
- If the buyer is a university DIZ / research: MII KDS 2026 modules, including the research Patient / pseudonym profiles, not ISiK.
- Always depend on HL7 DE Basis for identifier and address patterns so the three families can share Patient identity at the edge.
The HL7 FHIR R4 integration guide is the generic REST primer. ISiK search parameters and German terminology (ICD-10-GM, OPS, KBV keys) override generic R4 examples.
What this is not
This article is not an ISiK confirmation, not a gematik certificate, not a KBV MIO approval, and not legal advice. I do not perform gematik Bestätigungsverfahren. Implementing ISiK profiles in a lab does not authorise you to claim ISiK-certified software. English is used here because I do not write German-language specifications; the binding text is the German IG. Nothing here is clinical advice.
Related reading
For R4 mapping work against ISiK or DE Base, use HL7 FHIR integration.