MedVertical
Open menu

BlogFHIR in Deutschland

ISiK: Was die Bestätigung abdeckt und wie Teams Änderungen prüfen

ISiK-Anforderungen, formale Bestätigung und eine geprüfte Datenlieferung haben unterschiedliche Geltungsbereiche. Entscheidend ist die Verbindung von Prüfgrundlage, Befunden, Zuständigkeit und Nachprüfung.

Abstrakte Darstellung von ISiK-Anforderungen, FHIR-Prüfungen und dokumentierten Ergebnissen für Krankenhaussoftware
3 Min. LesezeitAktualisiert am
isikfhirgematiksgb-vgermanycompliancehospitals

ISiK definiert Anforderungen an den interoperablen Datenaustausch einschlägiger Krankenhaussoftware. Für ein Implementierungsteam müssen drei Dinge unterscheidbar bleiben: die geltende Anforderung, die formale Bestätigung und die Prüfungen einer ausgewählten Datenlieferung.

Den geltenden Umfang bestimmen

Ausgangspunkt sind die Funktion des Systems, das relevante ISiK-Modul mit seiner Version und der Produktumfang, den das Bestätigungsverfahren abdeckt. Aus dem Etikett ISiK folgen nicht dieselben Pflichten für jede Krankenhausanwendung. Die ISiK-Übersicht der gematik verlinkt die Spezifikationen und das Verfahren.

Datierter Quellenstand: Bei der Prüfung der GIGV am 24. September 2026 war in Anlage 1 unter Nummer 002 der Leitfaden für ISiK Stufe 5, Version 1.0.0, mit seinem Geltungsbereich für Krankenhausinformationssysteme und einer Umsetzungsfrist bis zum 31. Mai 2027 aufgeführt. Für eine konkrete Implementierungsentscheidung sind der Eintrag in der Verordnung und die einschlägigen Übergangsregelungen maßgeblich.

Eine Programmstufe, die Veröffentlichung eines Implementierungsleitfadens und die Version eines installierten FHIR-Pakets bezeichnen zusammenhängende, aber unterschiedliche Dinge. Halten Sie für jede technische Prüfung das genaue Paket und die zugrunde gelegte Anforderung fest.

Verstehen, was die Bestätigung aussagt

Das gematik-Verfahren bezieht sich auf festgelegte Testfälle, einen Funktionsumfang und eine Softwareversion. Die Verfahrensbeschreibung hält an der Verantwortung des Antragstellers für Produktkontrollen und Tests fest, empfiehlt Prüfungen bei aktualisierten Testkatalogen und sieht außerordentliche Überprüfungen bei Zweifeln an der Interoperabilität vor. Verfahrensbeschreibung, Version 2.0.0, Seiten 6 und 9.

Ein gesonderter Bericht über die Validierung von Ressourcen beantwortet daher eine enger gefasste technische Frage zu den darin enthaltenen Daten und Prüfungen. Er ersetzt weder die offizielle Bestätigung noch weist er das gesamte Systemverhalten nach.

Prüfungen an konkreten Änderungen ausrichten

Ein KIS-Release oder eine lokale Mapping-Änderung kann die erzeugten Ressourcen beeinflussen. Ein Profil- oder Terminologie-Update kann dagegen die Bewertungsgrundlage verändern. Das Team muss festhalten, welche dieser Änderungen es untersucht.

Bei einer Änderung an der Quelle wählen Sie die betroffenen Daten aus und wiederholen die vereinbarte Prüfung unter einer vergleichbaren Grundlage. Bei einer Profilmigration bewahren Sie beide Anforderungskontexte auf und erläutern, welche Befunde auf die neue Anforderung zurückgehen.

Wiederkehrende Prüfungen können helfen, den ausgewählten Betriebsumfang zu beobachten. Ihre Ergebnisse bleiben Beobachtungen zu bestimmten Zeitpunkten. Sie garantieren nicht den Zustand sämtlicher Daten zwischen den Läufen.

Befund, Zuständigkeit und Nachprüfung verbinden

Eine brauchbare Übergabe enthält das betroffene Feld, die verletzte Anforderung, die Ressourcenauswahl, den Paket- und Terminologiekontext sowie ein zulässiges Beispiel. Benennen Sie, wer die Ursache untersucht und mit welcher Prüfung die beabsichtigte Korrektur nachgewiesen werden soll.

Betrachten Sie zusammengehörige Befunde gemeinsam, wenn sie auf dieselbe bestätigte Ursache zurückgehen. Nach einer Korrektur prüfen Sie die verbleibenden Befunde und die Vollständigkeit der Folgeauswertung. Eine Aufgabe aus administrativen Gründen zu schließen ist etwas anderes, als das Verschwinden des gemessenen Fehlers nachzuweisen.

Der Qualitätszyklus von Records zeigt diesen Ablauf an einer synthetischen Datenlieferung. Die automatisierte Validierung ist standardmäßig schreibgeschützt; Änderungen an Quelldaten liegen beim zuständigen Team und System. Offizielle Verfahren und der gematik-Referenzvalidator behalten ihre jeweiligen Aufgaben.

Eine konkrete Evaluationsfrage auswählen

Für einen ersten Versuch benötigen Sie eine zulässige Datenauswahl, die erwarteten Paketversionen und eine Entscheidung, die das empfangende Team treffen muss. Vergleichen Sie die Befunde mit Ihrem bisherigen Prüfverfahren und prüfen Sie eine bestätigte Korrektur erneut.

Prüfen Sie die Abdeckung deutscher Profilpakete oder erkunden Sie die öffentliche Demo. Vor einer größeren Evaluation sollten Umfang, Betriebsbedingungen und Abnahmekriterien feststehen.

André Sheydin

Über den Autor

André Sheydin

André ist Gründer von MedVertical und arbeitet in Köln an Produktentwicklung und Design. Seit mehr als 25 Jahren gestaltet er digitale Produkte, Plattformen und Designsysteme, unter anderem im Gesundheitswesen, in der Pharmaindustrie, im Automobilbereich und für SaaS. Sein Schwerpunkt: technische Anforderungen in Produkte übersetzen, die Teams entwickeln und betreiben können.

Der nächste Schritt

Den nächsten Prüfschritt konkret machen.

Profilpakete, Prüfumfang und Betriebsnachweise getrennt betrachten. Der Deutschland-Überblick zeigt, wo Records dabei unterstützt.