ELGA e-Diagnose R4 (Draft)
0.1.0 - ci-build

Schreiben

UC-02-Schreiben

Dieses Kapitel beschreibt die Schreiboperationen der e-Diagnose-Fachanwendung. Im Mittelpunkt stehen die Aktualisierung von Listen sowie die Erfassung, Zuordnung, Entfernung, Stornierung und Löschung von Diagnosen, Prozeduren oder Allergien und Intoleranzen.

Sub_UC_eDiag_02_01 - Leere Liste fachlich bestätigen

Dieser Ablauf beschreibt die fachliche Bestätigung einer initialisierten, leeren Liste durch den GDA und die anschließende Speicherung des bestätigten Zustands in der Fachanwendung. Eine leere Liste mit dem Wert emptyReason = nilknown bedeutet, dass für den Patienten derzeit keine Einträge vorliegen. Der Status dokumentiert somit explizit das Fehlen von relevanten Einträgen und ist von einer noch nicht befüllten Liste emptyReason = notstarted zu unterscheiden.

Ablauf

  1. Der GDA führt einen POST $list-read aus.
  2. Die Fachanwendung prüft die angeforderte Liste und stellt fest, dass keine List.entry vorhanden sind.
  3. Ist List.emptyReason = notstarted, handelt es sich um eine initialisierte, aber noch nicht fachlich bestätigte leere Liste.
  4. Die Fachanwendung stellt dem GDA die leere Liste zur Bestätigung bereit.
  5. Der GDA bestätigt, dass für die Person aktuell keine Einträge dokumentiert werden müssen.
  6. Die Fachanwendung setzt daraufhin List.emptyReason = nilknown und liefert die aktualísierte Liste inkl. ETag für Optimistic Locking zurück.
  7. ​Anschließend führt die Fachanwendung einen POST $list-write aus, um den bestätigten Zustand der Liste zu speichern, siehe Sequenzdiagramm List-Read.

Sub_UC_eDiag_02_02 - Liste aktualisieren (List-Write)

​List Write ist eine eigenständige Operation, die ausschließlich im Kontext eines zuvor ausgeführten List-Read erfolgen darf.

Ablauf

  1. Der GDA übermittelt via POST $list-write die aktualisierte Liste als List Bundle inkl. ETag für Optimistic Locking:
    • alle neuen und geänderten und zu entfernenden Ressourcen sind inline im Bundle enthalten,
    • alle unveränderten Ressourcen werden nur referenziert.
  2. Die Fachanwendung prüft anhand des im HTTP-Header übermittelten ETag, ob die vom GDA bearbeitete Listenversion noch der aktuellen Version entspricht.
  3. Stimmen die ETags nicht überein, lehnt die Fachanwendung den Schreibvorgang ab, siehe Abgelehntes Write. Der GDA muss erneut ein $list-read durchführen und seine Änderungen auf Basis der aktuellen Listversion erneut vornehmen.
  4. Ist die Prüfung erfolgreich, validiert die Fachanwendung die neue Liste und stellt sicher, dass keine unzulässigen Zustandsübergänge vorgenommen wurden.
  5. Bei erfolgreicher Validierung:
    • werden die übermittelten Änderungen in die Ressourcen übernommen,
    • und auf Basis der aktualisierten Ressource erstellt die Fachanwendung ein neue Version der Liste als eigene List-Instanz, die als neue Liste persistiert wird.
  6. Der GDA erhält eine Meldung, dass die Liste erfolgreich aktualisiert wurde.

Sequenzdiagramm


Liste aktualisieren ($list-write)GDA 1GDA 1e-Diagnose Fachanwendunge-Diagnose FachanwendungVorbedingung: Nach einem $list-readwurde die Liste bearbeitet.1List.source = aktueller GDA2List.date = aktueller Zeitpunkt3POST /[Condition|Procedure|AllergyIntolerance]/$list-write (List + ETag)4ETag im Header ==ETag der Fachanwendung?alt: ETag stimmt überein?[ja]5Inhalte validieren(keine unzulässigen Zustandsübergänge)alt: Validierung erfolgreich[ja]6Neue Version persistierenNeue Version der Liste als eigene List-Instanz gespeichert.7HTTP 200 OK[nein]8HTTP 4xx Fehler / OperationOutcome[nein]9HTTP 4xx Fehler / OperationOutcome


</g></svg></div>
–>

Sub_UC_eDiag_02_03 - Einträge zur Liste hinzufügen

​Nach dem Erfassen einer neuen medizinischen Ressource Ressource erfassen kann dieser Eintrag in eine Liste aufgenommen werden. Die Fachanwendung kennzeichnet die Ressource anschließend als relevant (meta.tag = relevant).

Ablauf

  1. ​Der GDA legt eine neue (Condition, Procedure oder AllergyIntolerance), siehe Ressource erfassen an oder eine bestehende Ressource, die in die Liste aufgenommen werden soll.
  2. Dafür führt der GDA ein POST $list-read aus und erhält das aktuelle Search-Bundle der ausgewählten List-Ressource.
  3. Der GDA wählt die bestehende Ressource aus und fügt sie als neuen List.entry in die Liste ein.
    • List.entry.flag = new
    • List.entry.item referenziert die bestehende Ressource.
  4. Der GDA führt ein POST $list-write aus und übermittelt die aktualisierte Liste an die Fachanwendung.
  5. Die Fachanwendung kennzeichnet die referenzierte Ressource mit meta.tag = relevant, wodurch ihre Zugehörigkeit zur Liste gekennzeichnet wird.

Sequenzdiagramm

​Bestehende Ressource in eine Liste aufnehmenGDA 1?html-link?e-Diagnose Fachanwendung?html-link?GDA 1e-Diagnose FachanwendungGDA 1e-Diagnose FachanwendungVorbedingung: Im System des GDA 1 liegt einebestehende Ressource (Condition/Procedure/AllergyIntolerance)vor, die in eine Liste aufgenommen werden soll. Diese kann gerade erst erstellt worden sein oderaus der Gesamtansicht abgerufen worden sein.ref$list-readGDA erhält ein Search-Bundle von derFachanwendung und bearbeitet die enthalteneList-Ressource.1Bestehende Ressource auswählen2List.entry hinzufügen- List.entry.flag = new- List.entry.item = Referenz auf bestehende RessourceDie ausgewählte Ressourcewird als neuer Listeneintragaufgenommen.refList-Write3meta.tag = relevant setzenDie Ressource in der Listemit List.entry.flag = new wurdeals relevant gekennzeichnet.

Sub_UC_eDiag_02_04 - Eintrag aus der Liste löschen

Löschen kann nur der Bürger. Die Referenz auf die Ressource wird aus der Liste entfernt (removed). Die referenzierte Ressource bleibt unverändert bestehen. Die Fachanwendung entfernt die Kennzeichnung als relevant (meta.tag = relevant). ToDo: Aus Liste entfernen, Ressource bleibt bestehen, verliert nur Listzugehörigkeit oder Löschen - Ressource wird vollständig entfernt Ausblenden und Löschen? Löscht der Teilnehmer einen Eintrag, muss die Historienversion mitgelöscht werden? Betsehende Referenzen auf gelöschte Ressourcen. Lösche ich C, sage ich such mir alle List-Versionen mit C, und lösch mir alle C. Wie weit greifen, muss ich mich als Bürger durch alle Vorversionen durchklicken. FHIR Spezifikation über Historie - nachlesen, wie die Regel ist! Was bedeutet eine Aktualisierung auf eine historische Version?

Sub_UC_eDiag_02_05 - Reihenfolge der Listeneinträge ändern

Der GDA kann die Reihenfolge der Listeinträge ändern. Die Einträge selbst bleiben dabei unverändert. Evtl. auch in den ELGA Core mitnehmen.

Sub_UC_eDiag_02_06 - Liste löschen

ToDo: fachliche Auswirkungen klären; gesamte List-Ressouce löschen, alle Referenzen - alle enthaltenen Diagnosen?

Fachliche Einzelressourcen repräsentieren die medizinischen Inhalte der e-Diagnose. Hierzu zählen insbesondere Diagnosen (Condition), Prozeduren (Procedure) sowie Allergien und Intoleranzen (AllergyIntolerance). Die nachfolgenden Sub-Use-Cases beschreiben die Erfassung, das Abrufen und die Stornierung dieser Ressourcen. Bestehende Ressourcen werden weder bearbeitet noch gelöscht; fachliche Änderungen erfolgen durch das Anlegen neuer Ressourcen.

Sub_UC_eDiag_02_07 - Ressource erfassen

​Der GDA erfasst neue Diagnosen, Prozeduren sowie Allergien und Intoleranzen über die e-Diagnose Fachanwendung, siehe Transaktionen.

Ablauf

  1. Der GDA wählt den gewünschten Ressourcentyp (Condition, Procedure oder AllergyIntolerance) aus.
  2. Der GDA erstellt eine neue Ressource und erfasst die erforderlichen fachlichen Informationen.
  3. Der GDA führt ein POST auf /Patient/[id]/Condition/, /Patient/[id]/Procedure/ oder /Patient/[id]/AllergyIntolerance/ aus und übermittelt die neue Ressource an die e-Diagnose Fachanwendung.
  4. Die Fachanwendung validiert die übermittelte Ressource.
  5. Ist die Validierung erfolgreich, wird die neue Ressource gespeichert und dem GDA eine erfolgreiche Erstellung mittels HTTP 201 Created bestätigt. Ist die Validierung nicht erfolgreich, wird die Ressource nicht gespeichert. Die Fachanwendung liefert ein OperationOutcome mit den aufgetretenen Validierungsfehlern zurück.

Sequenzdiagramm

Diagnosen, Prozeduren sowie Allergien und Intoleranzen erfassenGDA 1GDA 1e-Diagnose Fachanwendunge-Diagnose Fachanwendung1Neue Ressource erstellen2Fachliche Informationen erfassen3POST /[Condition|Procedure|AllergyIntolerance]4Ressource validierenalt: Ressource valide?[Validierung erfolgreich]5Neue Ressource persistierenNeue Ressource gespeichert.6HTTP 201 Created[Validierung fehlgeschlagen]7OperationOutcome

Sub_UC_eDiag_02_08 - Ressource bearbeiten

Bestehende relevante Listeinträge fachlich bearbeiten TODo: Der GDA kann Einträge in einer Liste fachlich bearbeiten - stimmt nicht mehr? 1. Schritt, ich erstelle eine neue 2 Schritt: Will ich sie verknüpfen, muss ich auf die bestehenden Ressourcen zugreifen mit dem Identifier 123, der muss vom Client zwischengespeichert werden, damit dieser an die FA mitgesendet werden kann.

Ablauf

​Bestehenden Eintrag innerhalb einer Liste fachlich bearbeitenGDA 1GDA 1e-Diagnose Fachanwendunge-Diagnose Fachanwendungref$list-readGDA wählt bestehenden Eintrag(Condition/Procedure/AllergyIntolerance) ausund bearbeitet die Ressource1Bestehenden List.entry auswählen2Referenzierte Ressource (Condition/Procedure/AllergyIntolerance) laden3Fachliche Änderungen durchführenrefDiagnosen, Prozeduren sowie Allergien und Intoleranzen erfassen4Alten Eintrag aus Liste entfernen (List.entry.flag = removed)5Neuen Eintrag zu Liste an passender Stelle hinzufügen (List.entry.flag = new)ref$list-write

Sub_UC_eDiag_02_09 - Ressource löschen

Der ELGA-Teilnehmer kann via ELGA-Portal einzelne oder alle Diagnosen unwiderruflich löschen. Dabei ist es irrelevant, ob eine zu löschende Diagnose als relevant gekennzeichnet ist oder nicht. Die Inhalte der zu löschenden Diagnose werden durch die Fachanwendung entfernt und die Diagnose als "gelöscht" markiert. Sollte die Diagnose in der aktuellen Liste referenziert sein, erstellt die Fachanwendung eine neue Version der Liste ohne die gelöschte Diagnose.

Ablauf

  • ​Um einen Eintrag zu löschen, führt der ELGA-Teilnehmer über das Portal ein $list-read oder ein GET auf die Gesamtmenge der Diagnosen aus (siehe Read/Search von Diagnosen, Prozeduren sowie Allergien und Intoleranzen) und markiert die zu löschenden Einträge.
  • Durch Bestätigung wird die $delete-Operation ausgeführt.
  • Die Fachanwendung bearbeitet die zu löschende Diagnose folgendermaßen:
    • Alle optionalen Felder 0.. werden geleert.
    • Alle verpflichtenden Felder 1.. werden
      • mit der data-absent-reason-Extension und dem Wert unknown versehen
      • im Fall von den folgenden codierten Elementen mit required Bindings auf folgende Werte gesetzt
        • AllergyIntolerance.clinicalStatus = inactive
        • AllergyIntolerance.verificationStatus = unconfirmed
        • Condition.clinicalStatus = inactive
        • Condition.verificationStatus = unconfirmed
        • Procedure.status = completed
  • Die Fachanwendung erstellt eine neue Version der Liste, sollte die zu löschende Diagnose Teil der aktuellen Liste gewesen sein.

overview

Sub_UC_eDiag_02_10 - Ressource stornieren

Der GDA kann einen oder mehrere Diagnosen aufgrund einer falschen Eingabe stornieren. Dabei ist es irrelevant, ob eine zu stornierende Diagnose als relevant gekennzeichnet ist oder nicht.

​Sollte die Diagnose als relevant gekennzeichnet gewesen sein und will sie der GDA nach der Stornierung nicht mehr in der Liste der relevanten Einträge haben, muss die Diagnose aus der Liste der relevanten Einträge entfernt werden (siehe Sub_UC_eDiag_06_05 - Einträge aus einer Liste entfernen).

Ablauf

  • ​Um einen Eintrag zu stornieren, führt der GDA ein $list-read oder ein GET auf die Gesamtmenge der Diagnosen aus (siehe Read/Search von Diagnosen, Prozeduren sowie Allergien und Intoleranzen) und markiert die zu stornierenden Einträge.
  • Durch Bestätigung wird die $storno-Operation ausgeführt.
  • Die Fachanwendung bearbeitet die zu stornierende Diagnose folgendermaßen:
    • AllergyIntolerance.verificationStatus = entered-in-error
    • Condition.verificationStatus = entered-in-error
    • Procedure.status = entered-in-error