Hackathon 2025 #340
Hackathon 2025 #340
Conversation
#338 @alackerbauer bitte die Änderungen für die Abbildung des Hauptversicherten im POC überprüfen - insbesondere die angepasste Operation definition
|
müssen wir hier auch die neuen Updates des Main (wie beispielsweise #338) nachziehen? |
|
Ja müssen wir noch nachziehen bzw. gibt es noch einige weitere Dinge die nachgezogen werden müssen (müssen wir uns im Detail noch ansehen was zusätzlich noch nachgezogen werden muss damit wir nichts übersehen) |
…ng-Test Preauthorization claim modeling test
Englisch -> Deutsch
…heben 354 operations updaten und erheben
| * i. *MopedVAERequest.insurer* mit einer Referenz auf jene Organization befüllen, deren *Organization.identifier* dem Identifier *versicherer* lt. Operation-Parameter entspricht | ||
| * j. *MopedVAERequest.encounter* mit allen gefundenen Encountern aus Schritt 1 und 2 befüllen. | ||
| * k. *MopedVAERequest.supportingInfo[VerdachtFremdverschulden]* lt. Operation-Parameter befüllen | ||
| * l. *MopedVAERequest.accident.VerdachtArbeitsSchuelerunfall* lt. Operation-Parameter befüllen |
There was a problem hiding this comment.
wenn accident befüllt wird muss in accident auch lt. FHIR spec date befüllt werden, als Datum des Unfalls... ich bin mir aber nicht sicher was ich da eintragen muss, habt ihr das bedacht?
There was a problem hiding this comment.
Theoretisch müsstest du dort MopedEncounter.extension[Unfalldatum] einfügen können. Ich bin mir aber nicht sicher ob das in der KaOrg ein Pflichtfeld ist und garantiert immer im Encounter befüllt wird. Ich werde das noch nachprüfen und hier ein update geben.
There was a problem hiding this comment.
Das Feld accident.type wird mit einer Ausprägung von diesem ValueSet befüllt: https://fhir.hl7.at/r5-ELGA-MOPED-Hackathon-2025/ValueSet-moped-VerdachtArbeitsSchuelerunfall-valueset.html
Das heißt, es kann auch mit dem Code 0 (Nein/Unbekannt) befüllt werden. In diesem Fall, gibt es kein sinnvolles Datum, lt. FHIR Spec muss es jedoch trotzdem befüllt werden.
Ich werde das in den nächsten AG Moped Call mitnehmen um zu sehen, ob es bessere Vorschläge gibt, Unfälle abzubilden.
Die derzeitige Lösung wäre analog zum Namen im Patienten-Profil für Bund/LGF, wo wir in mit einer Kardinalität 1..1 umgehen müssen, die wir nicht sinnvoll befüllen können. Die passende Data Absent Reason wäre in diesem Fall not-applicable siehe hier: https://hl7.org/fhir/R5/valueset-data-absent-reason.html.
|
|
||
| * actualPeriod ^short = "Zugangs- und Abgangsdatum" | ||
|
|
||
| * extension contains PhysischeAnwesenheit named PhysischeAnwesenheit 0..1 | ||
| * extension contains Altersgruppe named Altersgruppe 0..1 | ||
| * extension contains Neugeborenes named Neugeborenes 0..1 |
There was a problem hiding this comment.
die extension für Neugeborenes ist hier herausgeflogen, aber in $verlegen noch drin? Ist es gedacht, dass es hier drin sein soll oder nicht?
There was a problem hiding this comment.
Ich sehe, dass auch das extension fsh file für Neugeborenes entfernt wurde
There was a problem hiding this comment.
Wir haben hier eine einzige Extension für die Altersgruppe und Neugeborenes definiert. Die neue Regel zur Befüllung ist hier zu finden: https://fhir.hl7.at/r5-ELGA-MOPED-Hackathon-2025/OperationDefinition-MOPED.Patient.Verlegen.html#:~:text=MopedTransferEncounter.admission.extension%5BAltersgruppe%5D.extension%5BNeugeborenes%5D.value%20wird%20lt.%20LKF%2DRegeln%20berechnet%2C%20anhand%20des%20MopedEncounter.subject.birthdate%20aus%20dem%20Encounter%20aus%20Schritt%201%20(f%C3%BCr%20Berechnugns%2DDetails%20siehe%20Hinweis%201).
Zwei Punkte darüber ist noch die alte Regel zu finden, das haben wir übersehene zu löschen - machen wir gleich.
There was a problem hiding this comment.
mit diesem PR wird die alte, nicht mehr unterstützte Version von Neugeborenes in der Business-Logik Beschreibung von $verlegen gelöscht: https://github.com/HL7Austria/ELGA-MOPED-R5/pull/367/files
| * *MopedTransferEncounter.status* mit `completed` befüllen gesetzt | ||
| * *MopedTransferEncounter.actualPeriod.end* mit *zeitpunkt* lt. Operation-Parameter befüllen | ||
| * Abgangsart vom alten MopedTransferEncounter: *MopedTransferEncounter.admission.dischargeDisposition* wird auf *abgangsart* lt. Operation-Parameter gesetzt. | ||
| * Altersgruppe bei Abgang vom alten MopedTransferEncounter: *MopedTransferEncounter.admission.extension[Altersgruppe].extension[beiAbgang].value* wird lt. LKF-Regeln berechnet, anhand des *MopedEncounter.subject.birthdate* aus dem Encounter aus Schritt 1 (für Berechnugns-Details siehe Hinweis 2 und 3). |
There was a problem hiding this comment.
in der Zeile steht, dass die extension beiAbgang heißt und zum Zeitpunkt der Implementierung stand es auch im Profil so, ihr solltet das wohl dann auch hier nachziehen, wenn es eigentlich beiEntlassung heißt
There was a problem hiding this comment.
Stimmt das haben wir übersehen. Danke für die Info!
| * i. *MopedVAERequest.provider* mit *MopedAccount.owner* befüllen | ||
| * j. *MopedVAERequest.insurer* mit einer Referenz auf jene Organization befüllen, deren *Organization.identifier* dem Identifier *versicherer* lt. Operation-Parameter entspricht | ||
| * k. *MopedVAERequest.encounter* mit allen gefundenen Encountern aus Schritt 1 und 2 befüllen. | ||
| * l. *MopedVAERequest.supportingInfo[VerdachtFremdverschulden]* lt. Operation-Parameter befüllen |
There was a problem hiding this comment.
bei dieser Zeile war mir nicht klar, dass in der valueBoolean in supportingInfo gesetzt werden soll, vielleicht genauer angeben
There was a problem hiding this comment.
Danke für das Feedback! Wäre das eine bessere Variante?
* l. *MopedVAERequest.supportingInfo[VerdachtFremdverschulden].valueBoolean* lt. Operation-Parameter befüllen
- Reicht das als Beschreibung aus? Die anderen Werte des supportingInfo[VerdachtFremdverschulden] Slice sind ja durch das Profil festgelegt
There was a problem hiding this comment.
ja das klingt gut, damit könnte ich schon was anfangen :)
| * ~~Abschließen des alten MOPEDTransferEncounter: *MOPEDTransferEncounter.status* wird auf *completed* gesetzt~~ | ||
| * ~~Endzeitpunkt des alten MOPEDTransferEncounter: *MOPEDTransferEncounter.actualPeriod.end* wird auf den *zeitpunkt* lt. Operation-Parameter gesetzt.~~ | ||
| * ~~Abgangsart vom alten MOPEDTransferEncounter: *MOPEDTransferEncounter.abgangsart* wird auf *abgangsart* lt. Operation-Parameter gesetzt.~~ | ||
| * Ein neuer MopedTransferEncounter wird vorbereitet |
There was a problem hiding this comment.
Vielleicht täusche ich mich, aber ich habe hier nicht gesehen, dass ich den Patienten setzen muss und da er mit einer Kardinalität 0..1 versehen ist, habe ich mich nicht um ihn gekümmert.
There was a problem hiding this comment.
Da hast du recht! - Ich werde nochmal abklären, ob der Patient hier tatsächlich benötigt wird
…emdverschulden detaillierter beschreiben
| * Der Status *MOPEDEncounter.status* muss den Wert 'in-progress' haben | ||
| * Es kann nie mehrere MopedEnconuter-Instanzen mit der gleichen Aufnahmezahl geben. Es muss vorab überprüft werden, ob bereits ein Encounter mit dieser Aufnahmezahl vorliegt und die Operation muss in dem Fall fehlschlagen (siehe Hinweis 5). | ||
| * Der Status *MopedEncounter.status* muss den Wert 'in-progress' haben | ||
| * Der Hauptversicherte lt. MopedAufnahmeBundle[Hauptversicherter] muss gleich sein wie MopedAufnahmeBundle[Coverage].policyHolder |
There was a problem hiding this comment.
Hier ist mir noch aufgefallen: in den Beispieldaten war aber nie ein policyHolder drin, mit dem man das überhaupt validieren könnte. Ich nehme im Moment einfach an das subscriber in Coverage richtig gesetzt ist
nicht mergen