Postman-Spiel SV-KH

[alackerbauer]

Beim Team-JF am Freitag werden initial in einer kurzen Präsentation die beiden Testfälle erklärt.

Anschließend teilen sich die JF Teilnehmer vor Ort in 4 Gruppen die jeweils einen Akteur der Testfälle representieren: ÖGK OÖ, ÖGK Wien, Herz-Jesu Krankenhaus, Krankenhaus Ried

Die 4 Gruppen sitzen in 4 Ecken und jeweils ein Mitglied vom Standards-Team wird mit einem Postman-Client die relevanten Requests für diesen Akteur durchführen. Dabei hängen je zwei Teams von einander ab, die ÖGK OÖ erhält beispielsweise erst einen Request zum Bearbeiten, sobald die Gruppe des KH Ried den Patienten aufgenommen hat und die Versichertenanspruchsklärung abgesendet hat.

Es soll sichtbar werden, dass wir über den Moped-Server kommunizieren können, welche Daten wie eingemeldet werden können und abgefragt werden können und ob alles was man benötigt auch vorhanden ist.

[alackerbauer]

5 collections:

• [x] Wipe Datebase + Stammdaten befüllen --> vorab vorbereitet und ausgeführt von Anna
• [x] KH Herz Jesu Wien --> vor Ort ausgeführt von Anja
• [x] KH Barmherzige Schwestern Ried (OÖ) --> vor Ort ausgeführt von Anna
• [x] SV ÖGK Wien --> vor Ort ausgeführt von Emmanuel
• [x] SV ÖGK OÖ --> vor Ort ausgeführt von Alexandra

eine präsentation für Intro:

• [x] powerpoint präsentation
• [x] textuelle Beschreibung der Request / des Ablaufes

[alackerbauer]

ich habe für Testfall 1 eine derzeit noch kombinierte Collection für KH und SV erstellt. Die Requests sind schon so angepasst, dass fancy Queries verwendet werden um nirgends mit FHIR IDs arbeiten zu müssen. Eine Ausnahme ist bei Übersendung der CoverageEligibilityResponse, die ganz bewusst auf einen Request mit bestimmter generierter ID antworten sollte.

in weiterer Folge werde ich diese Collection noch aufteilen auf eine extra KH und SV Collection und die gleichen Änderungen für die Testfall-2 Collection nachziehen.

[alackerbauer]

TBD: sobald CoverageEligibilityRequest Insurer Such-Parameter von der PineIT eingespielt wurde, diesen im Request der SV berücksichtigen.

[alackerbauer]

@1anja1 bitte vorab kurz checken ob deine collection so passt.

man muss davon ausgehen, dass vorab noch die reset collection ausgeführt wurde.

Wichtige Punkte:

• zuerst kann sich der KH Akteur mit seinen eigenen Stammdaten vertraut machen und einsehen, dass derzeit 0 Encounter von ihm in Moped vorhanden sind.
• danach wird die Patienten-Aufnahme durchgeführt. Der Request-Body besteht dabei aus zahlreichen Parametern sowie einem zusammengesetzten Aufnahme-Bundle mit den wichtigsten Informationen. Man darf auch ruhig erwähnen, dass dieser Request mit Abstand der Umfangreichste und komplexeste ist. Das Aufnahme-Bundle beinhält den Encounter (Aufnahmedatum, Zugangsart, Aufnahmediagnose), Details zum Patienten (der imaginär bereits vorher mit dem ZPI abgeglichen wurde) sowie Details zur Coverage (die aus einer imaginär vorangegangenen VDAS-Abfrage kommt).
• Danach folgen zahlreiche GET Requests um zu sehen, was dabei am Server passiert ist:
  • Ein Encounter wurde angelegt und die nötigen Referenzen zu anderen Ressourcen inkl. Stammdaten wurden am Server realisiert. Man kann hier durchaus erwähnen, wie beim Einspielen im Request-Body lediglich logische Referenzen (beispielsweise Organization?identifier=urn:ietf:rfc:3986|urn:oid:1.3.6.1.4.1.36124.5.914) verwendet wurden, diese aber am Server mit den jeweiligen Stammdaten gematched wurden und nun als FHIR Referenzen vorliegen.
  • Ein TransferEncounter wurde angelegt, der zum Encounter gehört und einer bestimmten Abteilung (Funktionscode) zugewiesen ist. Die Altersgruppe (55) und ob es sich um ein Neugeborenes handelt, wurde berechnet und gespeichert.
  • weitere Ressourcen (Patient, Coverage, Account) wurden am Server abgespeichert
• Nun kann die Versichertenanspruchs-Klärung durchgeführt werden. Nachdem bereits alles am Server liegt, reicht hierfür, wie im Request-Body zu sehen, die Aufnahme-Zahl sowie der zuständige Versicherer.
• in einem nächsten Schritt kann immer wieder der Status der Response abgefragt werden. Dabei wird in einer Query geschaut, ob eine Response zurückkommt. Diese Abfrage wird mehrmals ein leeres Bundle zurückliefern, nämlich genau so lange, bis die zuständige SV eine CoverageEligibilityResponse eingespielt hat. Sobald dies der Fall ist, liefert das Response-Bundle 1 zurück. Hier wurde auch der Filter _elements verwendet und veranschaulicht, so dass initial nur der outcome sichtbar ist. Wird dieser Filter mittels Postman-Häkchen deaktiviert, sieht man alle Details der Response-Ressource die sich der SV-Client einfallen hat lassen.
• Als nächstes kann optional eine Leistung erfasst werden. Dies würde aber im echten Prozess vermutlich nach der Entlassung geschehen, sobald der Arztbrief fertiggestellt ist und ist hier nur als experimentell anzusehen
• Am Ende kommt die Entlassung. Auch hierfür werden nicht viele Parameter benötigt. Nach der Entlassung kann man noch einmal den Encounter und TransferEncounter ansehen. Diese sollten nun mit einem End-Datum versehen worden sein.

[alackerbauer]

Wichtige Punkte:

• zuerst kann sich der SV Akteur mit den Stammdaten vertraut machen. Es gibt nämlich während die KH Akteure die Patienten-Aufnahme durchführen und die Versichertenanspruchs-Klärung einspielen kaum etwas anderes zu sehen. Als Beispiel-Request habe ich hier einen eingefügt, der mittels dem Identifier 11 der dort allen bekannt ist, die Details zur FHIR Organization ÖGK Wien liefert.
• in weiterer Folge kann immer wieder der GET Request ausgeführt werden, um zu sehen, ob es nun schon eine Anfrage (einen CoverageEligibilityRequest) gibt. Solange das Bundle 0 zurückgibt, hat das KH noch keine Anfrage gestellt. Sollte das Krankenhaus in Ried (gerichtet an ÖGK OÖ) schneller sein als das Krankenhaus Wien, wird dieser CoverageEligibilityRequest trotzdem der ÖGK Wien nicht angezeigt, da in der vorbereiteten Abfrage bereits nach dem Such-Parameter insurer gefiltert wird und somit nur die für die ÖGK Wien relevanten Requests ausgeliefert werden
• irgendwann liefert das Bundle 1 zurück, nämlich genau dann, sobald das KH die Anfrage eingespielt hat
• nun muss eine Antwort (CoverageEligibilityResponse) erstellt werden. Dafür wurde ein Postman-Request zum Einspielen einer CoverageEligibilityResponse vorbereitet. Es können beliebige, gültige Werte für den VAE Status, die Kostenbeitragsbefreiung, sowie für die Vortageanzahl gewählt werden. Wichtig ist, dass man sich die ID des CoverageEligibilityRequests vom Schritt davor kopiert und diesen in das TBD Feld im Request-Body einfügt. Damit wird die Verlinkung einer Antwort auf eine ganz bestimmte Anfrage sichergestellt.
• sobald die Response eingespielt ist, liefert der gleiche Request, der vorhin mehrmals ausgeführt wurde um zu sehen, ob es Arbeit gibt, keinen offenen CoverageEligibilityRequest mehr zurück. Dies ist durch eine fancy Query ermöglicht (siehe _has:CoverageEligibilityResponse:request:status:not=active) die beschreibt, dass nur CoverageEligibilityRequests retourniert werden für die es noch keine entsprechend verlinkte Antwort mit dem Status active gibt.

@alexandradenk deine Collection bereite ich noch morgen im Zug vor, die wird 1:1 gleich aussehen, außer dass statt 11 die Nummer 14 der Identifier der ÖGK OÖ sein wird und sich die identifier des Patienten / der Aufnahmezahl ändern. Der Ablauf, sowie der Ressourcen-Inhalt und das Design der Queries ist völlig ident.

[alackerbauer]

• Jour-Fixe Test 2 ÖGK OÖ.postman_collection.json --> Alexandra
• Jour-Fixe Test 2 Ried.postman_collection.json --> Anna
• Reset-Und-Stammdaten.postman_collection.json --> Anna (vorab)
• Jour-Fixe Test 1 Herz-Jesu-KH.postman_collection.json --> Anja
• Jour-Fixe Test 1 ÖGK Wien.postman_collection.json --> Emmanuel

[alackerbauer]

testfälle.pptx