nicht die aktuellste Version der Spezifikation

ISiK Stufe 2 - Basismodul

Urheber: gematik GmbH
Version: 2.0.0
Veröffentlichungsdatum: 08.04.2022
Schlagworte: Festlegung der gematik  // ISiK  // Primärsystem  // eHealth
Bewertungen der gematik: 1
Kommentare: 1

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/IsiK Veröffentlichung auf Simplifier

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, 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: Rudi Kallenberg
    Organisation: Doctolib GmbH
    06.05.2022

    Hallo,

    Folgendes Feedback möchte ich aus Sicht eines eines Patientenportal Herstellers zur ISiK Basis R2 Spezifikation geben. Die Punkte sind im Kontext mit der Terminplanung zu verstehen (siehe Feedback zur Terminplanung).

     

    [Basis/Terminplanung] Feedback ISiKKontaktGesundheitseinrichtung

    simplifier.net/isik/isikkontaktgesundheitseinrichtung 


    Encounter.Appointment Element

    • Notwendige Referenz auf einen Appointment. Aktuell kann die Verknüpfung Appointment zu Encounter in einer HL7 SIU übermittelt werden. Falls eine Verknüpfung im System existiert, sollte diese Appointment Referenz jetzt in den Encounter wandern.
    • Must support Flag für das Appointment Element im Encounter?

    Ansonsten ist es nicht möglich die Encounter/Appointment Beziehung an ein anderes System zu übermitteln. Diese Beziehung ist jedoch wichtig, wenn Daten, die im Termin-Kontext gesammlet wurden, im Fall-Kontext and das KIS übertragen werden sollen.

     

    [Basis/Terminplanung] Feedback ISiKPatient

    simplifier.net/guide/implementierungsleitfadenisik-basismodul/ImplementationGuide-markdown-Datenobjekte-Datenobjekte-Patient;

     

    Vorläufige Patienten werden zu echten Patienten

    • Die Anlage von externen/vorläufigen Patienten ist nur im IG für die Terminplanung zu finden. Der Vollständigkeit wegen, sollte es jedoch auch im Basis IG erwähnt werden.
    • Die Anlage von Patienten-Ressourcen steht als KANN, ist im Kontext der Terminplanung jedoch eine MUSS Anforderung.
    • Wenn ein vorläufiger Patient im KIS aufgenommen wird, entsteht ein echter Patient daraus, welcher im KIS oft in anderes Business Objekt ist. Wie ermittelt man als Client die Verknüpfung zwischen dem ehemals vorläufigen Patient und dem echten Patient? Link-Element?
    • Wenn ein vorläufiger Patient per POST angelegt wird, wird dieser nach meinem Verständnis auch mit die PID aus dem Client-System angelegt.
      • Wenn bei der Aufnahme ein echter Patient aus dem vorl. Pat. gemacht wird, muss die PID aus dem Client-System mit in den echten Patienten übernommen werden, damit die Identifier-Liste vollständig ist. Idealerweise wird auch die vorläufige ID mit in den echten Patienten übernommen, falls für den echten Patienten eine neue ID vergeben wird.
      • Alternativ müssen vorläufige und echter Patient jeweils mit dem Link-Element verbunden sein, damit der Client die zu verwendende PIDs ermitteln kann.
    • Ich denke, dass der Prozess "Anlage des Vorläufigen Patienten und die Umwandlung in einen echten Patienten" genau beschrieben sein muss (Handling der IDs, Links zwischen Ressourcen), damit der Patienten-Context erhalten bleibt.

    Patientenzusammenführung (ADT A40 Event)

    Wie ermittelt man als Client eine Patientenzusammenführung im KIS? Das Link-Element hat kein MUST-Support Flag.

     


    [Basis/Terminplanung] Feedback ISiKBinary

    gematik.de/fhir/ISiK/v2/StructureDefinition/ISiKBinary


    Motivation:

    Binary-Ressourcen werden von Attachment-Elementen in DocumentReference-Ressourcen verlinkt und damit in den Kontext anderer FHIR-Ressourcen (z.B. Patient und Encounter) gestellt.

    • Hier muss im Basis IG ergänzt werden, dass die Binary-Ressource auch durch die Communication-Ressource referenziert wird. Dadurch müssen KIS dann auch in der Lage sein Binarys von anderen System abzuholen (z.B. Patientenportal).
    • Ich finde es problematisch, dass für den Use-Case des Nachrichten- und Binary-Austauschs das Client/Server Verhältnis umgekehrt wird. (Trigger liegen nicht mehr in der Hand des eigentlichen Clients, Authentifizierung muss immer in beide Richtung implementiert werden.)

     

     

    Mit freundlichen Grüßen

    Rudi Kallenberg

Entscheidung der gematik

10.06.2022

Die bis zum 10.05.2022 eingegangenen Kommentare wurden einer Analyse durch die gematik unterzogen.

Die eingereichten Verbesserungsvorschläge und gegebenen Hinweise werden in die weiteren Arbeiten der Spezifikation einfließen. Die konkrete Auflösung der eingereichten Kommentare ist auf dieser Seite mit veröffentlicht.

Der vorliegende Bewertungsentwurf bleibt unverändert und die beantragte Festlegung wird mit dem Attribut „interoperabel mit den gematik-Spezifikationen/ Interoperabilitätsfestlegungen“ in vesta aufgenommen.