nicht die aktuellste Version der Spezifikation

ISiK Stufe 2 - Terminplanung

Urheber: gematik GmbH
Version: 2.0.0
Veröffentlichungsdatum: 08.04.2022
Referenzen:
Ist Vorgänger von: Interoperabler Datenaustausch durch Informationssysteme im Krankenhaus (ISiK) - Modul Terminplanung (2.0.0 Ballotierung)
Schlagworte: Festlegung der gematik  // ISiK  // Primärsystem  // 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.

Die Vereinbarung von Terminen für Behandlungsleistungen repräsentiert oftmals für PatientInnen oder für sie zuständige LeistungserbringerInnen den Einstieg in den Versorgungsablauf im Krankenhaus. Die Terminplanung argiert somit als kritische Schnittstelle zwischen diversen Akteueren im Gesundheitswesen, inkl. der zu behandelnden Personen. Informationen zu notwendigen und/oder gewünschten Behandlungen, Verfügbarkeiten der involvierten Personen und abrechnungsreleveante Details zur Krankenversicherung müssen potenziell ausgetauscht werden um einen optimierten Ablauf des Aufenthaltes im Krankenhaus zu ermöglichen.

Das Krankenhauszukunftsgesetz (KHZG) hebt die zentrale Rolle der Terminvereinbarung hervor in dem in den dazugehörigen Fördertatbeständen Vorgaben für die Terminplanung im digitalen Aufnahmemanagement bzw. für die Terminplanung mittels Patientenportalen gemacht werden (vgl. §19 Abs. 1 Satz 1 Nr. 2 KHSFV bzw. §21 Abs. 2 KHSFV).

Angelehnt an diese Vorgaben soll mittels ISiK die Grundlage geschaffen werden, um die beschriebenen oder ähnliche Use Cases durchzuführen und die fachlich-inhaltlichen Informationen in einer interoperablen Art und Weise auszutauschen. ISiK versteht sich somit als Schnittstellenbeschreibung, um eine einheitliche API zu dokumentieren, durch die ein Termin vereinbart und verwaltet werden kann. Das vorliegende ISiK-Modul bietet somit explizit KEIN umfassendes Datenmodell für die krankenhausinterne Ressourcenplannung. Hingegen werden durch ISiK Minimalvorgaben für bestätigungsrelevante Systeme spezifiziert, auf die komplexere Workflows ausgestaltet werden können.

Durch ISiK Terminplanung sollen folgende Möglichkeiten eröffnet werden:

  • Abruf von Abbildungen von verfügbaren teil- und voll- stationären Behandlungsleistungen durch ein Krankenhaus
  • Abfrage von verfügbaren Terminen
  • Buchungsmanagement von verfügbaren Terminen
  • Benachrichtigungen bei Terminänderungen
  • Anlage eines neues Patienten im terminführenden System (Übermittelung Patient/Versicherungsinformationen)

Links zum Standard

https://simplifier.net/spec-isik-terminplanung Veröffentlichung in Simplifier

Downloads

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 Terminplanung Spezifikation geben. Weiteres Feedback ist auch zur ISiK Basis Spezifikation veröffentlicht, bezieht sich aber auch auf die Terminplanung.


    [Terminplanung] Feedback ISiKTerminblock

    simplifier.net/spec-isik-terminplanung/isikterminblock 


    Motivation

    • Im Informationsmodell sind die Slots jedoch als die verbindende Ressource zwischen Appointment und Schedule notwendig
    • Ist der Slot nicht auch das FHIR Objekt, welche Verfügbarkeiten abbildet. Kann man das mit in die Motivation aufnehmen

    Generelle umsetzbarkeit der Spezifikation

    Die Herausforderung mit den Slots ist, dass diese bei uns im Kontext der Verfügbarkeitsabfrage Runtime Objekte sind, welche nicht persistiert werden und in Abhängigkeit der des Besuchsgrund (serviceType) in der Länge variieren. Eine Lösungsidee dafür könnte jedoch in der Business Logik abgebildet werden:

    • Temporäres Persistieren der Slots (im Status "free") im Kontext der Suche nach einem Verfügbaren Slot für einen bestimmten Besuchsgrund
    • Temporär persistierte Slots (Verfügbarkeiten) werden nach eine Zeit wieder gelöscht und es muss eine erneute Verfügbarkeitsabfrage durchgeführt werden, um die aktuellen freien Slots zu bekommen. Gelöschte temporäre Slots können dementsprechend nicht in einem Termin referenziert werden.
    • In diesem Kontext ist auch die Suche nach temporär persistieren Slots basierend auf der ID nicht wirklich abbildbar.

    Weitere Punkte zu den Slots

    • Wenn nach verfügbaren Slots gesucht werden soll, wie weit in die Zukunft sollen diese verfügbare Slots generiert werden? Ist es für den Client möglich Slots in einem bestimmten Planungshorizont/Zeitfenster abzufragen?
    • Die Interaktion mit Chaining ist nicht bei den Slots gelistet (nur bei den Operations): GET example.org/fhir/Slot=https://example.org/fhir/CodeSystem/Behandlungsleistung|CT

     

     


    [Terminplanung] Feedback ISiKMedizinischeBehandlungseinheit

    simplifier.net/spec-isik-terminplanung/isikmedizinischebehandlungseinheit 

    Bei den Interaktionen 3 bis 5 steht GET/schedule. Sieht mir nach einem Copy-Paste Fehler aus und sollte wahrscheinlich HealthcareService sein.

     

     


    [Terminplanung] Feedback ISiKTermin

    simplifier.net/guide/isik-terminplanung/ImplementationGuide-markdown-Datenobjekte-ISiKTerminAppointment

    Das definierte ValueSet für den Appointment.Status schränkt die abbildbaren Use-Cases ein.

    • Wenn Client und Server eine Warteschlange über den Appointment.status abbilden wollen, wird das vollständige Codesystem gebraucht.
    • Durch das Required binding auf IsikTerminStatus Valueset wird das verhindert. Könnte man das Binding auf extensible setzen?

     

     


    [Terminplanung] Feedback ISiKKalender

    simplifier.net/spec-isik-terminplanung/isikkalender   

    Kann ich so nachvollziehen und ist wahrscheinlich auch so umsetzbar.

     

     

    [Terminplanung] Feedback Nachrichtenaustausch

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


    Motivation

    Ich verstehe die Motivation nicht: Die Communication-Ressource dient als Datenobjekt für den Austausch von Nachrichten zwischen einer LeistunserbringerIn und einer PatientIn.

    • Bedeutet das, dass der Kommunikationsverlauf zwischen einem Leistungserbringer und einem Patient (einzelne Nachrichten, Chat-Verlauf, Datei-Austausch) mit einem anderen System ausgetauscht werden kann? z.B. für die Archivierung
    • Oder bedeutet das, dass die eigentlich Kommunikation zwischen einem Client des Leistungserbringers und eines Clients des Patienten auf Communication-Ressourcen basieren soll?
    • Was ist mit Nachrichten, die zwischen Leistungserbringern ausgetauscht werden? z.B. Kommunikation zwischen Leistungserbringern für die Organisation eines stationären Aufenthalts. In der Spezifikation des ISiKTermins wir auf das appointment.comment Element verwiesen. Dieses Element ist jedoch nur einfach vorhanden, hat nur ein String und Attachments werden nicht unterstützt.

    Ich gehe davon aus, dass manche meiner nachfolgenden Fragen durch eine klare Motivation beantwortet werden können.

     

    Richtung der Nachrichten

    Wie erkennt man die in der Communication-Ressource die Richtung der gesendeten Nachricht?

    • Patient → LE
    • LE → Patient

    Sollte evtl. das Sender Element ein MUST-Support Flag bekommen?

     

    Reihenfolge der Nachrichten

    Wenn ein Chat-Verlauf mit vielen Nachrichten an einem Termin hängt, wie wird die Reihenfolge der Nachrichten aus der Communication-Ressource ermittelt? Oder soll der Nachrichtenverlauf als ein String in einer einzigen Communication-Resource übermittelt werden? Ich glaube hier muss der IG präziser werden, damit das sinnvoll umsetzbar wird.

     

    Operationen auf der Resource

    Die beschriebenen Interaktionen enthalten Copy-Paste Fehler von der Slot-Ressource.


    Client/Server Verhältnis umgekehrt

    Es wurden nur die READ Operation für die Communication-Ressource definiert. Falls Kommunikation im Patienten-Professional-Portal zwischen Patient und LE stattfindet, müsste das KIS (in diesem Fall als Client) die Nachrichten von Patientenportal (in diesem Fall der Server) abholen. Gleiches gilt für die Binary-Ressource.

    In anderen Use-Cases (z.B Dokumentaustausch) agiert das KIS jedoch nur als Server.

    • Die Übermittlung der Communication-Ressource liegt somit nicht mehr in der Hand des eigentlichen Clients (Termin-Requester), welcher die Termine übermittelt hat. Müssen Systeme (Termin-Repository) die Communication-Resource abfragen, falls in einem übermittelten Termine ein Communication-Referenz enthalten ist?
    • Was passiert, wenn die Kommunikation erst nach der initialen Terminübermittlung stattfindet? Muss das System, welches den Termin initial übermittelt hat ein Update auf die Appointment-Ressource mit der Communication-Referenz schicken? Bei einem Chat, würde das u.U. sehr viele Termin-Updates erzeugen.
    • Wenn eine Communication-Ressource aktualisiert wird, wie wird das KIS über diese Änderung benachrichtigt? Polling durch das KIS?


    E2EE Verschlüsselung nicht mehr umsetzbar

    Wenn Kommunikation zwischen zwei Partnern E2EE verschlüsselt sind, liegen Clear-Text Nachrichten nur jeweils im Kommunikations-Client beim Anwender vor. Eine Übertragung Patientenportal/KIS würde eine Server-seitige Entschlüsselung der Daten erforderlich machen, wodurch keine E2EE Verschlüsselung mehr gegeben ist. 

     

     

    [Terminplanung] Feedback definierte Interaktionen/Operationen

    simplifier.net/guide/isik-terminplanung/ImplementationGuide-markdown-UebergreifendeFestlegungen-Interaktionen


    Sequenzdiagramme

    Ist es möglich auf den Pfeilen der Sequenzdiagramme die REST Interaktionen (Operationen: simplifier.net/guide/isik-terminplanung/ImplementationGuide-markdown-Datenobjekte-Operations) mit anzugeben? Insbesondere beim Buchen, Aktualisieren, Verschieben und Absagen eines Termins wird es für Implementierer leichter dem IG zu folgen.


    2. Verfügbare Behandlungsleistungen abrufen

    Als Einstiegspunkt in die Terminvereinbarung können durch den Termin Requester alle verfügbaren Behandlungsleistungen (HealthcareServices) abgerufen werden, für die das Termin Repository Informationen zu notwendigen Ressourcen (Räume, Personen, Geräte, etc.) bereitstellt.

    • Der HealthcareService ist eine Med. Behandlungseinheit. Wird hier nicht eigentlich das Code System mit allen verfügbaren Behandlungsleistungen (ServiceTypes) abgerufen?
    • Wie konkret stellt das Repository Informationen zu den benötigten Ressourcen für einen Besuchsgrund zur Verfügung? Nach meinem Verständnis ist der HealthcareService ein virtueller Akteur in einem Schedule und Termin.
    • Nach meinem Verständnis des IGs enthält nur der Schedule Informationen darüber, welche Ressourcen (Akteure) für die Durchführung eines ServiceTypes notwendig sind.
    •  

    5. Termin buchen

    Im Sequenzdiagramm gibt es die technische Eingangsbestätigung für den Termin am Repository und im Verlauf dann eine fachliche Bestätigung/Absage durch das Termin Repository.

    Ich nehme an, dass die optionale fachliche Absage/Bestätigung durch den Termin Requestor gepollt werden muss bzw. per Push über ein Update informiert wird. (Analog Aktualisierung/Absage durch das Repository, wie in den Operationen beschrieben.)

    • Der Pfeil im Sequenzdiagramm sollte dann vom Requester zum Repository zeigen für das Abholen

    Falls Appoitnment.Slot einen Slot refernziert, muss der Slot durch den Server auf den Status busy geändet werden.

     

    6. und 7. Termin verschieben bzw. Absagen durch das Repository

    Falls Termine im Termin Repository abgesagt bzw. verschoben werden, ist der Trigger am Repository.

    Im aktuellen IG gibt es einen Pfeil vom Repo zum Requester für die Verschiebung/Absage, dadurch entsteht ein Client/Server Verhältnis in beide Richtung. Entsprechend muss die Operation zum Buchen/Verschieben/Absagen sowohl vom "Client" (Requester) als auch dem "Server" (Repository) implementiert werden, inklusive der Authentifizierung.

    Das widerspricht sich ein bisschen mit der Beschreibung bei den Operationen, wo Pollen und Subscriptions für Aktualisierung/Absage erwähnt sind. In der aktuelle Spezifikation verstehe ich die $book Operation auch so, dass diese eigentlich nur in eine Richtung (Requester -> Repo) anwendbar ist.

    • Ist es gedacht die PATCH + $book Operationen auch in die andere Richtung anzuwenden, wenn ein Termin im Repo verschoben wird?
    • Oder sind die Verschiebungen/Absagen im Repository durch den Requester zu pollen? Dadurch würde ein “sauberes” Client/Server Verhältnis erhalten bleiben.

    Ich glaube die Interaktionen zum Verschieben (PATCH + $book) und zur Absage (PATCH) eines Termin werden klarer, wenn im IG jeweils vollständige Beispiele dafür angegeben sind. Für die Verschiebung eine Beispiel-Sequenz, da es ein zweistufiger Prozess ist.


    8. Terminzusatzinformationen aktualisieren

    Wenn Zusatzinformationen im Repo aktualisiert werden, muss der Trigger im Sequenzdiagramm auch dort stehen. Ich nehme an der Requester soll in diesem Use Case dann die Änderungen pollen bzw. über einen Subscription Mechanismus informiert werden, damit die Änderungen abgerufen werden können, wie bei den Operationen beschrieben.


    Anlage einer Patienten Ressource

    Laut IG ist es vorgesehen zunächst einen Patienten per POST anzulegen und dann einen Termin für diesen Patienten zu buchen.

    • Aus Sicherheitsgründen ist bei uns die Patienten-Basis für jeden Kunden getrennt und wenn der Kunde das wünscht, ist die Patienten-Basis auch für jeden Kalender eine andere. Somit kann Stand heute eine Patienten-Ressource nur angelegt werden, wenn man den Kontext (den Termin) kennt.
      • Auf Basis welcher Attribute in der POST Operation für eine vorläufige Patienten-Ressource kann das Quellsystem/Organisation eineindeutig ermittelt werden?
    • Wenn ein Termin Repository einen vorläufigen Patient z.B. wegen internen Regeln ablehnt (löschen oder auf inaktiv setzen), dann muss auch der Termin, der auf diesen Patienten referenziert abgelehnt werden.
    • Ist es möglich ein vollständiges Beispiel für die Anlage eines vorläufigen Patienten und die Umwandlung in einen echten Patienten mit in den IG aufzunehmen? 

     

    Mit freundlichen Grüßen

    Rudi Kallenberg

  • Name: Michael Sauer
    Organisation: Universitätsklinikum Freiburg
    06.05.2022

    Mir scheint, dass es im aktuellen IL Datenobjekte gibt, die durch die Interaktionen gar nicht verwendet werden (ISiKNachricht und ISiKBinary).

    Schwierig fand ich, dass im Zip-File die Bilder nicht richtig verlinkt waren, so dass man sich die zugehörigen Interaktionsdiagramme mühsam heraus suchen musste.

    Was mir fehlt ist die AppointmentResponse. Für Absagen durch den Patienten ist diese Ressource aus unserer Sicht immanent wichtig. Damit können nämlich auch Informationen zum Grund der Absage übermittelt werden, die entscheidend für die Neuplanung sind. Die Absage eines Termins durch den Patienten hat bei nicht trivialen Terminen zudem intern eine Kette weiterer Terminänderungen zur Folge (z.B. die Buchung des OPs, die Buchung eines Intensivbetts/Aufwachraumbett u.v.m), so dass das Update des participant-Status oder gar des Terminstatus wie in "Aktualisierung / Absage eines Termins" beschrieben zu kurz greift.

    Generell fällt es schwer, mir anhand des Implementierungsleitfadens vorzustellen, wie das so in einem Realworld-Szenario umgesetzt werden kann.

    Viele Grüße
    Michael Sauer

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.