aktuellste Version der Spezifikation

Interoperabler Datenaustausch durch Informationssysteme im Krankenhaus (IsiK) - Basismodul

Urheber: gematik GmbH
Version: 1.0.0 CC
Veröffentlichungsdatum: 15.03.2021
Schlagworte: Festlegung der gematik  // Primärsystem  // XML-Schema  // eHealth
Bewertungen der gematik: 1
Kommentare: 3

Beschreibung

Die gematik wurde vom Gesetzgeber beauftragt, im Benehmen mit der Deutschen Krankenhausgesellschaft (DKG) und den maßgeblichen Bundesverbänden der Industrie im Gesundheitswesen, verbindliche Standards für den Austausch von Gesundheitsdaten mit Informationssystemen im Krankenhaus zu erarbeiten. Dieser FHIR ImplementationGuide (IG) beschreibt die für diesen Zweck entwickelten FHIR Profile und das REST-basierte Application Programming Interface (API). Die REST-API wird im Wesentlichen vom FHIR Standard vorgegeben. Dieser Leitfaden konkretisiert die IsiK-relevanten Funktionen der Standard-REST-API und trifft inhaltliche Festlegungen zu den IsiK-relevanten Ressourcen in Form von Ressourcen-Profilen.

Hersteller bestätigungsrelevanter Systeme sollen durch diesen IG in die Lage versetzt werden, eine konforme Implementierung zu erstellen und das Bestätigungsverfahren der gematik erfolgreich zu absolvieren.

Weitere Informationen siehe §373 SGB V.

Dieser Implementierungleitfaden beinhaltet die von der gematik spezifizierten FHIR-Profile. Das umfasst alle im Zusammenhang mit dem isiK-Basismodul benötigten fachlichen Datenstrukturen.        

Links zum Standard

https://simplifier.net/guide/implementierungsleitfadenisik-basismodul/einfuehrung Implementierungsleitfaden 1.0.0 für das "Basismodul"

Bewertungen der gematik

  • Die gematik beabsichtigt diesen Implementierungsleitfaden in vesta aufzunehmen.

    Im Releaseprozess der gematik wurde der vorliegende Implementierungsleitfaden auf Interoperabilität zu gematik Dokumenten sowie zu weiteren, zum Stand 08.06.2020, bereits in vesta enthaltenen Interoperabilitätsfestlegungen geprüft. Aus Sicht der gematik ist der vorliegende Implementierungsleitfaden mit den bereits in vesta eingetragenen Interoperabilitätsfestlegungen interoperabel.

Kommentare

  • Name: Dr. Bettina Lieske
    Organisation: SAP SE
    08.04.2021

    Chaining / Reverse chaining

    Die Anforderung, dass „Für Suchparameter vom Typ 'Reference' MÜSSEN die Festlegungen für Chaining und Reverse Chaining verpflichtend implementiert werden.“ (siehe hier: simplifier.net/guide/ImplementierungsleitfadenIsiK-Basismodul/UebergreifendeFestlegungenSuchparameter ) ist für Systeme, die FHIR nicht nativ implementiert haben, wie es die meisten der bestätigungsrelevanten KIS-Systeme sind, eine sehr aufwändig zu implementierende Funktion, wenn sie in aller Umfänglichkeit umgesetzt werden soll.

    Wir gehen davon aus, dass für die wesentlichen Anwendungsfälle nur eine Untermenge der Chaining / reverse Chaining Funktionalität nötig ist. Deshalb wäre es unserer Meinung nach wünschenswert, diese stärker zu spezifizieren und einzugrenzen und „MUSS“ und „KANN“ Optionen zu definieren.

    Sinnvoll könnte hier folgendes sein:

    • Angabe eines Set von Elementen, über die das Chaining gemacht werden soll
    • Angabe über wie viele Ebenen es implementiert werden soll

     

    Bestätigungsrelevante Systeme
    Es gibt sicherlich viele Formen, wie ein Hersteller die ISiK Compliance erreichen kann. Ein Kommunikationsserver oder eine FHIR Fassade sind wahrscheinlich nur ein paar der Möglichkeiten.

    In unserem Kontext könnte z.B. eine Option sein, dass SAP das SAP Patient Management (IS-H) mit dem nativen IS-H FHIR Framework und generischen Profilen liefert und ein Partner die ISiK-Umsetzung daraus implementiert indem er ein sog. “Content-Paket” mit den dazu notwendigen Konfigurationen und (modifikationsfreien) Erweiterungen anbietet.

    In diesem Zusammenhang erscheint uns der Satz „Die eingesetzte Software des Drittherstellers wird damit zu einem Bestandteil des Primärsystems.“ als problematisch, da daraus die rechtlichen Folgen nicht ersichtlich sind.

    Wir würden uns daher eine Ergänzung vorschlagen, z.B. “Die eingesetzte Software des Drittherstellers wird damit im Kontext der Zertifizierung zu einem Bestandteil des Primärsystems.”

    Um die rechtlichen Bedenken auszuräumen, wäre ein Gespräch mit unserer Rechtsabteilung nötig. Gerne bieten wir auch ein telefonisches Gespräch hierzu an, da es sicherlich auch anderen Herstellern so gehen wird, wenn sie z.B. mit einem Kommunikationsserver arbeiten.

     

    Encounter type
    Wir finden es gut, dass für den Encounter.type zwei unterschiedliche ValueSets zur Kommunikation von verschiedenen Granularitäten (nur Level oder auch Kontaktarten) möglich sind.

    Das ValueSet (https://simplifier.net/packages/de.basisprofil.r4/1.0.0-alpha9/files/342310 ) für die Kontaktart erscheint uns aber auf folgenden Gründen problematisch:

    1. Die vorgeschlagenen Codes im CodeSystem scheinen eine Mischung aus abrechnungsbezogenen Codes (wie teilstationär nach §115a) und abrechnungsunabhängigen Codes (wie Operation oder Konsil) zu sein.
    2. Unserer Meinung nach sollten Kontakte unabhängig von ihrer späteren Abrechnung dokumentiert werden und deshalb sollte das CodeSystem keine abrechnungsbezogenen Codes enthalten.
    3. Es scheint eine Abhängigkeit von Level und Kontaktart zu geben, so scheint zum Beispiel ein Kontakt für die Begleitperson nur auf Einrichtungsebene definiert zu sein.
    4. Die Definition dieser Abhängigkeit ist uns nicht ganz klar:
    • Auf dem Overview-Tag ist das Level zu sehen.
    • Auf dem XML oder JSON Tab findet man keine Repräsentation des Levels mehr.
  • Name: Udo Siefker
    Organisation: SAP SE
    09.04.2021

    Sehr geehrte Damen, sehr geehrte Herren,

     anbei finden Sie meine Kommentare zum IsiK-Basismodul 1.0.0:

     

    - Bzgl. Einfuehrung.html: Menü "Datenobjekte" Eintrag "Kontakt/Fall (Encounter)"

    Ein Fall ist etwas anderes als ein Kontakt, insbesondere ist ein Fall kein FHIR-Encounter. In diesem Sinne sollte der Begriff "Fall" auch nicht implizit mit Kontakt gleichgesetzt werden.

    ---------------------------

     

    - Bzgl. Datenobjekte.html: Diagramm, Box "Kontakt(Fall)"

    s.o. Ein Fall ist kein Kontakt

    ---------------------------

     

    - Bzgl. DatenobjektePatient.html: Patient.identifier[Patientennummer, Versichertennummer_GKV, Versichertennummer_PKV].use

    Die Nutzung des Werte für use widerspricht deren Definition in der FHIR-Spezifikation: build.fhir.org/valueset-identifier-use.html

    - "official": The identifier considered to be most trusted for the identification

    - "usual": The identifier recommended for display

    - "secondary": An identifier that was assigned in secondary use

    In diesem Sinne sind sowohl die Verwendungen in Versichertennummer_GKV und Versichertennummer_PKV beide vom use "secondary" (die von den Versicherungen vergebene 10-stellige Patientennummer ist in der Praxis weder lebenslang gültig noch eindeutig) und der use im Slice Patientennummer sollte "official" sein, da dies innerhalb des KHs eine eindeutige Identifizierung gewährleistet. Ein Slice mit use "usual" könnte für UI-Zwecke natürlich zusätzlich Sinn machen, insbesondere, wenn die Patientennummer z.B. eine GUID ist.

    ---------------------------

     

    - Bzgl. DatenobjektePatient.html: Patient.name

    Die Kardinalität 1..1 macht es unmöglich einen Patient ohne Namen (erst Recht ohne offiziellen Namen) anzulegen. Dies ist aber insbesondere in Notfall-Situationen erforderlich (Patient nicht ansprechbar und ohne Papiere, insbesondere auch in Massen-Notfällen).

    ---------------------------

     

    -Bzgl. DatenobjektePatient.html: Patient.birthDate

    Die Kardinalität 1..1 macht es unmöglich einen Patient ohne Geburtsdatum anzulegen. Dies ist aber insbesondere in Notfall-Situationen erforderlich s.o. Die Extension "Data-Absent-Reason" sollte m.E. nicht als Standardwerkzeug zur Aufweichung von obligatorischen Feldern genutzt werden. In diesem Sinne könnte man auf die Kardinalität 1..1 auch gleich grundsätzlich verzichten. Im Rahmen eines konkreten Anwendungsbezugs (z.B. Isik) soll ein obligatorisches Feld jedoch eine prozessorale Notwendigkeit darstellen, ohne die eine Integration signifikant erschwert wird.

    ---------------------------

     

    -Bzgl. DatenobjekteKontakt.html: Motivation
    In der Überschrift wird wiederum der Kontakt(Encounter) mit einem Fall gleichgesetzt. Ebenso im Text: "Suchen der Encounter-Ressource anhand von Eigenschaften wie ... Fallart oder ...". Die Fallart ist eine Eigenschaft eines Falls, in FHIR also entweder EpisodeOfCare (für einen medizinischen Fall) oder Account (für einen Abrechnungsfall) und eben keine Eigenschaft eines Encounters.

    ---------------------------

     

    -Bzgl. DatenobjekteKontakt.html: Encounter.status

    In der Beschreibung findet sich " Der volle Workflow MUSS unterstützt werden." Was ist mit "volle Workflow" gemeint? Alle Status müssen z.B. bei einem POST auf den Server sinngemäß verarbeitet werden? Beim GET müssen alle Status vom Server in einem UI 1:1 wiedergegeben werden? Insbesondere muss angemerkt werden, dass der Status "onleave" ab R5 entfällt. Es erscheint merkwürdig diesen Status verpflichtend unterstützen zu müssen. Vor allem wenn man den Umsetzungszeitraum von zwei Jahren mit in Betracht zieht, sollte man in der Spezifikation absehbare Änderungen, insbesondere inkompatibler Art, vermeiden.

    ---------------------------

     

    -Bzgl. DatenobjekteKontakt.html: Encounter.serviceProvider

    In der Bedeutung steht: "Falls Details zur durchführenden Organisationeinheit, welche für den Kontakt verantwortlich ist, vorliegen, KÖNNEN diese in einer beliebigen Detailtiefe angegeben werden."
    Der Datentyp zum Element serviceProvider ist Reference(Organization). I.W. bedeutet das, dass man auf eine Resource vom Typ Organization verweisen kann. Man kann also keine Details hier angeben. Des Weiteren ist die Rolle beschrieben als "durchführende" Organisationseinheit. Dies steht im Widerspruch zur FHIR-Spezifikation, wo das Element serviceProvider als "The organization that is primarily responsible for ", also als die verantwortliche Organisation beschrieben ist.

     

    Mit freundlichen Grüßen,
    Udo Siefker.

  • Name: Axel Biernat
    Organisation: Cerner Health Services Deutschland GmbH
    12.04.2021

    Das vom vorgelegten Implementierungsleitfaden ISiK Basisprofile Version 1.0.0 adressierte Thema findet volle Unterstützung. Nach sorgfältiger Prüfung zeigt sich jedoch Nachbesserungsbedarf, bevor die Spezifikation allgemeine Gültigkeit erlangen kann. Im Einzelnen sind diese Punkte unten aufgeführt.

    Konflikte mit anderen gesetzlichen Vorgaben

    DSGVO / GDPR

    Unter Übergreifende Festlegungen à REST-API – Sicherheitsaspekte wird die Unterstützung von http sowie https mit TLS-Verschlüsselung gefordert. Im Sinne der DSGVO ist die Übertragung von personenbezogenen, sensiblen Daten über ein unverschlüsseltes Transportprotokoll wie http nicht angezeigt. Ebenso ist die Benennung bei https mit TLS Verschlüsselung als nicht mehr Stand der Technik zu betrachten. Verschlüsselung nach TLS ist etwa nach Version 1.0 inzwischen als nicht mehr sicher zu betrachten.

    MDR

    Unter Übergreifende Festlegungen à Bestätigungsrelevante Systeme - Kommunikationsserver und Fassaden findet sich die Formulierung „Die eingesetzte Software des Drittherstellers wird damit zu einem Bestandteil des Primärsystems.“. Inzwischen werden Klinische Informationssystem als MDR relevante Softwarelösung betrachtet. Die Cerner Lösung i.s.h.med ist ein Medizinprodukt der Klasse I. Diese Aussage ist kritisch, da indirekt impliziert wird, dass eine von Dritten erstellte Software zu einem Bestandteil eines Medizinprodukts außerhalb des Verantwortungsbereichs des Herstellers werden kann. Dies kann etwa der Fall sein, wenn der Hersteller eines Kommunikationsserver für ein Primärsystem eine Fassadenlösung anbietet.

     

    Kompatibilität

    Im Abschnitt Kompatibilität der gematik-Spezifikation erfolgt die Benennung von IHE-Profilen. Leider zeigt sich an dieser Stelle eine methodischer Unschärfe. Es werden hier IHE Transaktionen mit FHIR-Interaktionen gleichgesetzt. Vgl. „PDQm definiert die Transaktion ITI-78 (Mobile Patient Demographics Query), deren Grundlagen identisch sind mit den in Isik definierten Interaktionen auf dem Datenobjekt "Patient"“. Da IHE Transaktionen das Verhalten von Softwaresystemen auf der Ebene der organisatorischen Interoperabilitätsebene beschreiben, FHIR Interaktionen jedoch auf der strukturellen Ebene liegen sehe ich hier Nachbesserungsbedarf.

     

     FHIR

    Suchparameter Unterstützung für Chaining und Reverse Chaining

    Die Unterstützung von Chaining und Reverse Chaining ist verständlich, geht aber als Muss-Anforderung an ein Primärsystem für die erste Version zu weit. Es ist zu berücksichtigen, dass heute komplexe Zugriffskontrollmechanismen in den Systemen implementiert sind  und die Vielfältigkeit sich aus den ergebenen Suchkombinationen erheblich ist. Es ist zu befürworten, diese Anforderung als KANN anzugeben.

    Datenobjekt Konformitätserklärung

    Bitte um Klarstellung, was die Fragezeichen in Punkt Documents à Consumer bedeuten. Ist dieser Punkt final?

    Datenobjekt Fall (Encounter)

    Hier werden Abrechnungsbezogene Aspekte und der eigentliche Kontakt nicht klar getrennt. Die FHIR Ressource ist ausschließlich auf die Patienteninteraktion mit dem Leistungserbringer bezogen, lässt jedoch die Abrechnung außen vor. Diese klare Trennung sollte hier auch erfolgen und das Datenobjekt entsprechend überarbeitet werden. Die Kommentare von Frau Lieske und Herr Siefker unterstütze ich an dieser Stelle voll.

    Datenobjekt Diagnose (Condition)

    Die obligatorische Unterstützung (Must Support) des Elements onset als auch die Bereitstellung eines zugehörigen Search Parameters ist zu hinterfragen. Im heutigen gesetzlich festgelegten Umfang der Diagnosendokumentation (vgl. §301 SGB V iVm Deutsche Kodierrichtlinien sowie BfArM Anleitung zur Verschlüsselung) ist diese Information nicht verfügbar. Dieses Element sowie der Suchparameter sollten als KANN Anforderung umgesetzt werden.

    Datenobjekt Prozedur (Procedure)

    Die Erfassung einer OPS-kodierten Prozedur bedingt zwingend eine SNOMED CT Kategorie. Heute liegen vom BfArM noch keine Mappings zwischen der Klassifikation OPS und der SNOMED CT Ontologie vor. Erst nach Bereitstellung solch eines Mappings kann die dieses MUSS Kriterium gefordert werden. Ich empfehle eine Benennung als KANN Kriterium.

    Es ist je nach Implementierung in einem Krankenhaus nicht zwingend möglich, bereits geplante Chirurgische Eingriffe bereitzustellen. Ggf. werden diese nicht als Prozedur im Planungsprozess hinterlegt. In diesem Fall kann erst mit Durchführung der OP-Dokumentation eine Prozedur erfolgreich gesucht werden.

     

    Sonstiges

    In der Spezifikation finden sich an mehreren Stellen noch Tippfehler - etwa simplifier.net/guide/ImplementierungsleitfadenIsiK-Basismodul/DatenobjekteProzedur -> „In FHIR werden Prozeduren mit der Proecedure-Ressource repräsentiert.“ – und Links zur Entwicklungsversion von FHIR – etwa simplifier.net/guide/ImplementierungsleitfadenIsiK-Basismodul/UebergreifendeFestlegungenRest -> build.fhir.org/security.html.

     

    Vor der Veröffentlichung bitte ich um die Korrektur der Tippfehler und Verlinkung der finalen FHIR Version 4.0.1.