Die Kommentierung endet in 0 Tagen, 7 Stunden und 4 Minuten.

noch nicht bewertet

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: 2

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.