Moderne Patient:innenabrechnung und Datenkommunikation on FHIR (MOPED)
0.1.0 - ci-build

Moderne Patient:innenabrechnung und Datenkommunikation on FHIR (MOPED) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

OperationDefinition: MOPED Patient $aufnehmen (POC)

Official URL: http://example.org/OperationDefinition/MOPED.Patient.Aufnehmen Version: 0.1.0
Draft as of 2024-10-29 ​ Responsible: Example Publisher Computable Name: MOPED_Patient_Aufnehmen

Die $aufnehmen Operation wird aufgerufen, wenn ein(e) Patient*in in das Krankenhaus aufgenommen wird.

Wer ruft diese Operation in welchem Zusammenhang auf?

Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen. Die $aufnehmen Operation wird aufgerufen, wenn ein(e) Patient*in in das Krankenhaus aufgenommen wird.

Voraussetzungen für den Aufruf

  • Account-Status: n/a (die Ressource Account wird erst mit dieser Operation erstellt)

Detaillierte Business-Logik

  1. Ressourcen der Transaction erstellen: FHIR Transaction ausführen, wie im Operation-Parameter falldaten mitgegeben. Dabei soll geprüft werden, ob bereits ein Patient mit dem jeweiligen identifier (bPK bzw. Sozialversicherungsnummer) vorliegt um Duplikate zu vermeiden. Das gleiche gilt für die anderen Ressourcen im Bundle, und kann technisch mit Hilfe von conditional References im Input-Bundle realisiert werden.
  2. Account anlegen:
    • MOPEDAccount.WorkflowStatus: lt. Beschreibung der Werte-Ausprägungen des freigeben Parameter (siehe Hinweis 1)
    • MOPEDAccount.VerdachtArbeitsSchuelerunfall lt. Operation-Parameter
    • MOPEDAccount.VerdachtFremdverschulden lt. Operation-Parameter
    • MOPEDAccount.subject mit der gleichen Referenz befüllen wie MOPEDEncounter.subjec
    • MOPEDAccount.owner mit der gleichen Referenz befüllen wie MOPEDEncounter.serviceProvider
    • MOPEDAccount.VDASID lt. Operation-Parameter vdasid befüllen
    • MOPEDAccount.AnzahlVerlegungen mit Wert '0' befüllen
    • MOPEDAccount.AnzahlBeurlaubungen mit Wert '0' befüllen
    • MOPEDAccount.coverage.coverage mit der Referenz lt. Parameter befüllen und ggf. Hauptversicherter (Patient) anlegen, falls noch nicht am Server.
  3. Account im Encounter referenzieren: Den neuen MOPEDAccount im MOPEDEncounter.account referenzieren
  4. Durchführung der Operation $verlegen für Neufaufnahme:
    • $verlegen#aufnahmezahl = $aufnehmen#aufnahmezahl
    • $verlegen#zeitpunkt = Operation-Parameter falldaten mit dem Pfad Bundle.Encounter.actualPeriod.start
    • $verlegen#funktionscode = $aufnehmen#funktionscode
    • $verlgegen#funktionssubcode = $aufnehmen#funktionssubcode
    • $verlegen#physischeAnwesenheit = $aufnehmen#physischeAnwesenheit
    • $verlegen#neuaufnahme = true
  5. Berechnung der Datensatz-ID:
    • Die Datensatz-ID wird aus der Aufnahmezahl lt. LKF Dokumentation als SHA-256 Hash berechnet und in das entsprechende Identifier-Slice des MOPEDEncounter eingefügt.

Validierung / Fehlerbehandlung

  • Wenn der freigeben-Parameter auf true ist, muss eine Validierung aller Ressourcen im falldaten-Bundle erfolgreich sein, oder die Operation schlägt fehl.
  • Es kann nie mehrere MOPEDEnconuter-Instanzen mit der gleichen Aufnahmezahl geben
  • Der Status MOPEDEncounter.status muss den Wert 'in-progress' haben

Weitere Hinweise

  • Hinweis 1: Die Werte-Ausprägung des freigeben Parameters haben eine Auswirkung auf das Verhalten der Operation:
    • false: Die Patientenaufnahme ist noch nicht vollständig und wird lediglich zwischengespeichert. Hier findet keine Validierung der Encounter Ressource statt. Eine Account-Ressource wird erstellt, die den WorkflowStatus 'Aufnahme in Arbeit' hat und im Encounter referenziert.
    • true: Die Patientenaufnahme ist vollständig und es ist zu erwarten, dass alle nötigen Felder befüllt sind. Schlägt die Validierung der falldaten fehl, kann die Operation nicht erfolgreich durchgeführt werden. Ist die Validierung erfolgreich, wird eine im Encounter referenzierte Account-Ressource erstellt bzw. upgedatet, die den WorkflowStatus 'Aufnahme freigegeben' hat.
  • Hinweis 2: Es ist nicht nötig, bei dieser Operation den GDA-Identifier als Kontext mitzugeben. Auf den GDA wird im falldaten-Bundle als conditional Reference mittels entsprechendem Identifier im MOPEDEncounter verwiesen. Somit wird auch vermieden, dass Duplikate einer GDA-Organization-Ressource am Server angelegt/verwendet werden.
  • Hinweis 3: Im Parameter falldaten wird unter Anderem eine Coverage Ressource mitgegeben. Diese Ressource stammt in der Regel aus einer erfolgreichen VDAS-Abfrage. In Zukunft wird Moped auch andere Optionen unterstützen, wie die Verarbeitung von Daten von Selbstzahlern (wofür ein separates Coverage-Profil angelegt wird), oder die Verarbeitung von Fällen mit privater Krankenversicherung (auch hierfür wird ein separates Coverage-Profil angelegt). Im Ersten Schritt liegt der Fokus auf den Standard-Fall, der als Ausgangsbasis eine erfolgreich abgeschlossene VDAS-Abfrage voraussetzt.

Generated Narrative: OperationDefinition MOPED.Patient.Aufnehmen

URL: [base]/Encounter/$aufnehmen

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INfalldaten1..1Resource (MOPED Aufnahme Bundle)

Der falldaten Parameter beinhält die nötigen Elemente um die Details zum Fall zu beschreiben die bei Patientenaufnahme bekannt sind, inklusive Patient, Encounter und Coverage.

INvdasid0..1string

Der vdasid Parameter wird mitgegeben, um die Coverages die im falldaten Transaction-Bundle angeführt sind, die VDAS-ID zuzuweisen. Weil es je VDAS-Abfrage mehrere Coverages geben kann, ist die VDAS ID derzeit nicht als Identifier in der Coverage hinterlegt und wird separat vom System eingemeldet. Über diesen Parameter wird die VDAS ID dem Moped-Server bekannt gegeben.

INfreigeben1..1boolean

Mit Hilfe des freigeben Parameters wird angegeben, ob es sich bei der Patienten-Aufnahme um vollständige Daten handelt und somit eine Validierung erfolgen soll (freigeben = true), oder ob lediglich unvollständige Daten zwischengespeichert werden (freigeben = false).

INverdachtArbeitsSchuelerunfall0..1codeVerdacht auf Arbeits- oder Schuelerunfall (Required)

Mit Hilfe des verdachtArbeitsSchuelerunfall Parameters wird festgehalten, ob es bei der Patienten-Aufnahme einen Verdacht auf einen Schüler- oder Arbeitsunfall gibt. Wird dieser Parameter mitgegeben, ist im Account das entsprechende Feld zu befüllen.

INverdachtFremdverschulden0..1boolean

Mit Hilfe des verdachtFremdverschulden Parameters wird festgehalten, ob es bei der Patienten-Aufnahme einen Verdacht auf Fremdverschulden gibt. Wird dieser Parameter mitgegeben, ist im Account das entsprechende Feld zu befüllen.

INphysischeAnwesenheit0..1boolean

Der physischeAnwesenheit Parameter definiert ob der Patient physisch anwesend ist oder nicht.

INfunktionscode1..1string

Der funktionscode Parameter definiert auf welchen Funktionscode die Neuaufnahme stattfindet.

INfunktionssubcode1..1string

Der funktionssubcode Parameter definiert auf welchen Funktionssubcode die Neuaufnahme stattfindet.

OUTreturn1..1Resource (OperationOutcome)

Der return Parameter gibt Auskunft über den Erfolg der Operation. Wenn der modus Parameter auf 'freigeben' gesetzt war, ist die Operation erfolgreich, wenn die Daten validiert wurden und abgespeichert werden konnten. Wenn der modus Parameter auf zwischenspeichern gesetzt war, ist für eine erfolgreiche Durchführung der Operation lediglich ein erfolgreiches Speichern vorausgesetzt. Schlägt die Operation fehl, wird eine entsprechende Meldung ausgegeben.

TBD: möchten wir zusätzlich zur GDA-Referenz einen Input-Parameter, der gleich sein muss? Um in einem Extra-Schritt zusätzlich auf Gleichheit mit der Referenz in falldaten.MOPEDEncounter.serviceProvider prüfen zu können?; Frage an Architektur: gibt es Möglichkeiten, einen solchen Input-Parameter (GDA als Kontext) automatisiert auf einem anderen Sicherheits-Level zu befüllen als der Inhalt des Transaction Body?; Check, wo version-specific References nötig sind - ggf. relevant für Account.subject, Account.owner und Account.coverage sobald Modus auf freigeben. Überlegen, für was der Status Aufnahme in Arbeit tatsächlich nützlich ist und wenn dieser wirklich nötig ist, was passiert, wenn diese Operation mehrfach aufgerufen wird (speziell mit POSTen von Coverages, das Anlegen von MOPEDTransfer Encounters via $verlgen ect.)