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