ISiK defines requirements for interoperable exchange by relevant hospital software. For an implementation team, three things need to remain distinct: the applicable requirement, the formal confirmation and the checks performed on a selected data delivery.
Determine the applicable scope
Start with the system's function, the relevant ISiK module and version, and the product scope covered by the confirmation procedure. Do not infer the same obligations for every hospital application from the ISiK label alone. The gematik ISiK overview links the specifications and procedure.
Dated reference: The GIGV source review on 24 September 2026 recorded Annex 1, entry 002, for the ISiK Stage 5 guide version 1.0.0 and its hospital-information-system scope, with implementation due on 31 May 2027. Consult the regulation entry and applicable transition information for a specific implementation decision.
A programme stage, an implementation-guide release and an installed FHIR package version describe related but different things. Record the exact package and requirement used by each technical check.
Understand what confirmation establishes
The gematik procedure concerns the specified test cases, functional scope and software version. Its description retains the applicant's responsibility for product controls and tests, recommends checking updated test catalogues, and provides for extraordinary checks where interoperability is in doubt. Procedure version 2.0.0, pages 6 and 9.
A separate resource-validation report therefore answers a narrower technical question about the data and checks it contains. It does not replace the official confirmation or establish all system behavior.
Plan checks around the changes you make
A KIS release or local mapping change can affect generated resources. A profile or terminology update can change the evaluation basis. The team needs to identify which of those changes it is investigating.
For a source change, select the relevant data and repeat the accepted check under a compatible basis. For a profile migration, preserve both requirement contexts and explain which findings follow from the new requirement.
A recurring schedule can help observe the selected operating scope. Its results remain observations at particular times. They do not guarantee the state of all data between runs.
Connect a finding to its owner and follow-up
A useful handover includes the field, violated requirement, resource selection, package and terminology context, and a permitted example. Name the person responsible for investigating the cause and the check that will verify the intended correction.
Review related findings together where they share a confirmed cause. After a correction, inspect the remaining findings and the completeness of the follow-up evaluation. Closing a task for administrative reasons is different from verifying that the measured defect has disappeared.
Records' quality loop demonstrates this workflow on a synthetic delivery. Automated validation is read-only by default; source changes belong to the responsible team and system. Official procedures and the gematik Referenzvalidator retain their respective roles.
Choose one evaluation question
For an initial exercise, bring a permitted data selection, the expected package versions and one decision the receiving team needs to make. Compare the findings with your current checking process and repeat a confirmed correction.
Review German package coverage or explore the public demo. A broader evaluation should specify its scope, operating arrangements and acceptance criteria before it begins.
