Moderne Patient:innenabrechnung und Datenkommunikation on FHIR (MOPED)
0.1.0 - ci-build
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
| Draft as of 2024-11-04 |
<OperationDefinition xmlns="http://hl7.org/fhir">
<id value="MOPED.Patient.Aufnehmen"/>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml"><p class="res-header-id"><b>Generated Narrative: OperationDefinition MOPED.Patient.Aufnehmen</b></p><a name="MOPED.Patient.Aufnehmen"> </a><a name="hcMOPED.Patient.Aufnehmen"> </a><a name="MOPED.Patient.Aufnehmen-en-US"> </a><p>URL: [base]/Encounter/$aufnehmen</p><h3>Parameters</h3><table class="grid"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Scope</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>falldaten</td><td/><td>1..1</td><td><a href="http://hl7.org/fhir/R5/resource.html">Resource</a> (<a href="StructureDefinition-MOPEDAufnahmeBundle.html" title="http://example.org/StructureDefinition/MOPEDAufnahmeBundle">MOPED Aufnahme Bundle</a>)</td><td/><td><div><p>Der <em>falldaten</em> Parameter beinhält die nötigen Elemente um die Details zum Fall zu beschreiben die bei Patientenaufnahme bekannt sind, inklusive Patient, Encounter und Coverage.</p>
</div></td></tr><tr><td>IN</td><td>vdasid</td><td/><td>0..1</td><td><a href="http://hl7.org/fhir/R5/datatypes.html#string">string</a></td><td/><td><div><p>Der <em>vdasid</em> Parameter wird mitgegeben, um die Coverages die im <em>falldaten</em> 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.</p>
</div></td></tr><tr><td>IN</td><td>freigeben</td><td/><td>1..1</td><td><a href="http://hl7.org/fhir/R5/datatypes.html#boolean">boolean</a></td><td/><td><div><p>Mit Hilfe des <em>freigeben</em> Parameters wird angegeben, ob es sich bei der Patienten-Aufnahme um vollständige Daten handelt und somit eine Validierung erfolgen soll (<em>freigeben</em> = <em>true</em>), oder ob lediglich unvollständige Daten zwischengespeichert werden (<em>freigeben</em> = <em>false</em>).</p>
</div></td></tr><tr><td>IN</td><td>verdachtArbeitsSchuelerunfall</td><td/><td>0..1</td><td><a href="http://hl7.org/fhir/R5/datatypes.html#code">code</a></td><td><a href="ValueSet-moped-VerdachtArbeitsSchuelerunfall-valueset.html">Verdacht auf Arbeits- oder Schuelerunfall</a> (Required)</td><td><div><p>Mit Hilfe des <em>verdachtArbeitsSchuelerunfall</em> 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.</p>
</div></td></tr><tr><td>IN</td><td>verdachtFremdverschulden</td><td/><td>0..1</td><td><a href="http://hl7.org/fhir/R5/datatypes.html#boolean">boolean</a></td><td/><td><div><p>Mit Hilfe des <em>verdachtFremdverschulden</em> 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.</p>
</div></td></tr><tr><td>IN</td><td>anwesenheitsart</td><td/><td>0..1</td><td><a href="http://hl7.org/fhir/R5/datatypes.html#code">code</a></td><td><a href="ValueSet-moped-Anwesenheitsart-valueset.html">Anwesenheitsart</a> (Required)</td><td><div><p>Der <em>anwesenheitsart</em> Parameter definiert in welcher art der Pateint anwesend ist.</p>
</div></td></tr><tr><td>IN</td><td>funktionscode</td><td/><td>1..1</td><td><a href="http://hl7.org/fhir/R5/datatypes.html#string">string</a></td><td/><td><div><p>Der <em>funktionscode</em> Parameter definiert auf welchen Funktionscode die Neuaufnahme stattfindet.</p>
</div></td></tr><tr><td>IN</td><td>funktionssubcode</td><td/><td>1..1</td><td><a href="http://hl7.org/fhir/R5/datatypes.html#string">string</a></td><td/><td><div><p>Der <em>funktionssubcode</em> Parameter definiert auf welchen Funktionssubcode die Neuaufnahme stattfindet.</p>
</div></td></tr><tr><td>OUT</td><td>return</td><td/><td>1..1</td><td><a href="http://hl7.org/fhir/R5/resource.html">Resource</a> (<a href="http://hl7.org/fhir/R5/operationoutcome.html" title="http://hl7.org/fhir/StructureDefinition/OperationOutcome">OperationOutcome</a>)</td><td/><td><div><p>Der <em>return</em> Parameter gibt Auskunft über den Erfolg der Operation. Wenn der <em>modus</em> Parameter auf 'freigeben' gesetzt war, ist die Operation erfolgreich, wenn die Daten validiert wurden und abgespeichert werden konnten. Wenn der <em>modus</em> Parameter auf <em>zwischenspeichern</em> 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.</p>
</div></td></tr></table><div><p>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 <em>freigeben</em>. Ü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.)</p>
</div></div>
</text>
<url
value="http://example.org/OperationDefinition/MOPED.Patient.Aufnehmen"/>
<version value="0.1.0"/>
<name value="MOPED_Patient_Aufnehmen"/>
<title value="MOPED Patient $aufnehmen (POC)"/>
<status value="draft"/>
<kind value="operation"/>
<date value="2024-11-04T12:12:39+00:00"/>
<publisher value="Example Publisher"/>
<contact>
<name value="Example Publisher"/>
<telecom>
<system value="url"/>
<value value="http://example.org/example-publisher"/>
</telecom>
</contact>
<description
value="Die $aufnehmen Operation wird aufgerufen, wenn ein(e) Patient*in in das Krankenhaus aufgenommen wird."/>
<purpose
value="**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#anwesenheitsart* = *$aufnehmen#anwesenheitsart*
* *$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."/>
<affectsState value="true"/>
<code value="aufnehmen"/>
<comment
value="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.)"/>
<base value="http://hl7.org/fhir/OperationDefinition/Patient-aufnehmen"/>
<resource value="Encounter"/>
<system value="false"/>
<type value="true"/>
<instance value="false"/>
<parameter>
<name value="falldaten"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation
value="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."/>
<type value="Resource"/>
<targetProfile
value="http://example.org/StructureDefinition/MOPEDAufnahmeBundle"/>
</parameter>
<parameter>
<name value="vdasid"/>
<use value="in"/>
<min value="0"/>
<max value="1"/>
<documentation
value="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."/>
<type value="string"/>
</parameter>
<parameter>
<name value="freigeben"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation
value="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*)."/>
<type value="boolean"/>
</parameter>
<parameter>
<name value="verdachtArbeitsSchuelerunfall"/>
<use value="in"/>
<min value="0"/>
<max value="1"/>
<documentation
value="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."/>
<type value="code"/>
<binding>
<strength value="required"/>
<valueSet value="moped-VerdachtArbeitsSchuelerunfall-valueset"/>
</binding>
</parameter>
<parameter>
<name value="verdachtFremdverschulden"/>
<use value="in"/>
<min value="0"/>
<max value="1"/>
<documentation
value="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."/>
<type value="boolean"/>
</parameter>
<parameter>
<name value="anwesenheitsart"/>
<use value="in"/>
<min value="0"/>
<max value="1"/>
<documentation
value="Der *anwesenheitsart* Parameter definiert in welcher art der Pateint anwesend ist."/>
<type value="code"/>
<binding>
<strength value="required"/>
<valueSet value="moped-Anwesenheitsart-valueset"/>
</binding>
</parameter>
<parameter>
<name value="funktionscode"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation
value="Der *funktionscode* Parameter definiert auf welchen Funktionscode die Neuaufnahme stattfindet."/>
<type value="string"/>
</parameter>
<parameter>
<name value="funktionssubcode"/>
<use value="in"/>
<min value="1"/>
<max value="1"/>
<documentation
value="Der *funktionssubcode* Parameter definiert auf welchen Funktionssubcode die Neuaufnahme stattfindet."/>
<type value="string"/>
</parameter>
<parameter>
<name value="return"/>
<use value="out"/>
<min value="1"/>
<max value="1"/>
<documentation
value="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."/>
<type value="Resource"/>
<targetProfile
value="http://hl7.org/fhir/StructureDefinition/OperationOutcome"/>
</parameter>
</OperationDefinition>