The previous article mapped the German FHIR landscape — gematik, ISiK, MII, and why they overlap without being equivalent. This article goes one level deeper into ISiK specifically: what the legal mandate actually requires, how the certification works, and why passing it once isn't the same as staying conformant.
ISiK — Informationstechnische Systeme im Krankenhaus — is the technical expression of a legal requirement under §373 SGB V. If you build or operate a hospital information system in Germany, there is no path around it. The formal certification process — the Bestätigungsverfahren — is defined and administered by gematik, built on HL7 FHIR R4.
What most teams underestimate: ISiK is not a static certificate. It's an evolving standard with multiple stages, growing module requirements, and a certification process that must be repeated as the standard advances. The first time I pulled up ISiK profiles — in their 2022 form, trying to understand them while mapping clinical documentation forms to FHIR — they already looked different from the previous published set. Three years on, they look different again.
What ISiK requires technically
ISiK defines how hospital information systems must structure and expose data — as FHIR R4 resources, conformant to gematik-defined profiles. Stage 3 covers six modules, including patient demographics and encounters (Basis), appointments and scheduling (Terminplanung), clinical document exchange (Dokumentenaustausch), medication records, and vital signs.
Each module brings its own profile set — StructureDefinitions, ValueSets, CodeSystems, FHIRPath invariants. The Basis module is the foundation: patient resources must carry the right German identifier types, diagnoses must be coded to ICD-10-GM, procedures to OPS. These aren't optional extensions — they're the conformance requirements the Bestätigungsverfahren validates directly.
The stage model — and why it doesn't stop
ISiK is not a one-time hurdle after which things stabilize. It's a multi-stage, ongoing program.
Stage 1 introduced basic interoperability requirements. Stage 2 expanded them. Stage 3 added new modules and tightened existing constraints. Gematik published Stage 4 specifications, but discontinued the stage before it became a mandatory certification requirement — hospitals with a valid Stage 3 confirmation received an extension and were not required to re-certify against Stage 4. Stage 5 is now the next mandatory stage, with binding implementation timelines being established.
A current Stage 3 certification does not cover Stage 5. When Stage 5 becomes mandatory, the certification process must be completed again — against new profiles, new modules, new constraints.
ISiK conformance is not a state you achieve. It's a continuous requirement that grows with the standard.
What happens between stages
This is the part that rarely gets addressed — and where the real operational risk lives.
Between the certification date and the next Bestätigungsverfahren, the underlying ecosystem keeps moving. Gematik publishes patch versions of ISiK profiles. ICD-10-GM releases annually, shifting the exact codes and hierarchies that ISiK's diagnosis binding resolves against. KIS vendors ship routine updates — performance improvements, bug fixes — that may subtly alter FHIR output without anyone noticing.
In all three cases, the system keeps producing FHIR resources. Nobody is watching conformance in the period between certification cycles. The gap accumulates silently.
This is structurally different from the terminology drift described in the previous article about continuous validation. Terminology drift is about external sources changing independently. The ISiK certification gap is about the standard itself evolving — new profile constraints, new gematik patches, new mandatory modules — while the certified system operates unchanged against the previous snapshot.
What the Bestätigungsverfahren doesn't measure
The certification process is a snapshot. It measures what the system produces at the time of the audit — against the profile version current at that time, with the terminology available at that time.
What it doesn't measure:
- Whether the system is still conformant three months after certification
- Whether production data created before certification is valid against current profiles
- Whether a routine KIS update changed the resource output
- Whether terminology dependencies shifted between certification cycles
This is not a criticism of the process. A certification procedure is inherently a snapshot — it cannot be anything else. The gap doesn't come from the procedure; it comes from the period between procedures.
The question nobody asks
When a hospital presents an ISiK Stage 3 certification, it answers: "Could your system produce conformant resources at the time of testing?"
The operationally relevant question is: "Is your system producing conformant resources today — against current profiles, with current terminology, in its current configuration?"
The Bestätigungsverfahren doesn't ask that question. It can only be answered through continuous validation against production data.
For hospitals exchanging ISiK-conformant data with partners — other facilities, research infrastructures, regional care networks — this is not an academic distinction. Downstream systems validate the resources they receive. Conformance gaps become visible there, not in the originating system.
What continuous ISiK validation looks like
The model is the same as for any living standard: conformance must be measured continuously, not only at the certification moment.
In practice, that means running regular validation against production data with pinned profile versions — so runs are comparable and drift is visible — alongside managed terminology snapshots so that ICD-10-GM updates are detectable. After each KIS update, a baseline comparison tells you whether FHIR output changed. And when the next Bestätigungsverfahren cycle begins, you have a documented conformance history rather than a gap of months with no signal.
The Bestätigungsverfahren remains the formal proof of conformance to gematik. Continuous validation is the operational proof to your own organization — and to the partners receiving your data.
Both are necessary. Only one of them is currently standard practice.
ISiK governs the data a hospital exposes. The next article turns to where that data is now legally required to flow: the ePA, mandatory for every German practice, hospital, and pharmacy since October 2025 — and the largest structured-FHIR deployment the country has attempted.