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
Official URL: https://elga.moped.at/OperationDefinition/MOPED.VAERequest.Anfragen | Version: 0.1.0 | |||
Draft as of 2025-02-26 | Responsible: ELGA GmbH | Computable Name: MOPED_VAERequest_Anfragen |
Die Versichertenanspruchserklärung $anfragen Operation wird aufgerufen, um die Versichertenanspruchserklärung-Anfrage an die SV anzustoßen. Diese Operation ist irrelevant für Selbstzahler (das ist wichtig für künftige weiterentwicklung - wenn im Account auf eine Coverage-Ressource für Selbstzahler referenziert wird, darf die Operation $anfragen nicht ausgeführt werden).
Legende: durchgestrichen heißt, dass es für den IG zwar bedacht wird, für den ersten POC jedoch nicht relevant ist.
Wer ruft diese Operation in welchem Zusammenhang auf?
Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen. Die Versichertenanspruchserklärung $anfragen Operation wird aufgerufen, um die Versichertenanspruchserklärung-Anfrage an die SV anzustoßen. Diese Operation ist irrelevant für Selbstzahler (das ist wichtig für künftige weiterentwicklung - wenn im Account auf eine Coverage-Ressource für Selbstzahler referenziert wird, darf die Operation $anfragen nicht ausgeführt werden).
Voraussetzungen für den Aufruf
Aufnahme freigegeben
Detaillierte Business-Logik
Validierung / Fehlerbehandlung
Weitere Hinweise
Annahmen an das BeS
system
des Parameters aufnahmezahl
dem GDA entspricht, der die Operation aufruft. Somit ist sichergestellt, dass nur Kostenübernahmen für eigene Fälle angefragt werden können.Generated Narrative: OperationDefinition MOPED.VAERequest.Anfragen
URL: [base]/Account/$anfragen
Use | Name | Scope | Cardinality | Type | Binding | Documentation |
IN | aufnahmezahl | 1..1 | Identifier | Der aufnahmezahl Parameter beinhaltet den eindeutigen Identifizierer für den relevanten Fall. | ||
IN | versicherer | 1..1 | Identifier | Der versicherer Parameter beinhaltet den eindeutigen Identifizierer für den Versicherer an dem der VAERequest gerichtet ist. | ||
IN | verlaengerungstage | 0..1 | unsignedInt | Der verlaengerungstage beschreibt, um wie viele Verlängerungstage angefragt wird. | ||
IN | sonderklasse | 0..1 | code | Sonderklasse ValueSet (Required) | Der sonderklasse codiert, ob der Aufenthalt in der Allgemeine Gebührenklasse oder Sonderklasse stattfindet, da es bei speziellen Versicherungsträgern dafür Optionen gibt. | |
IN | verdachtArbeitsSchuelerunfall | 0..1 | code | Verdacht auf Arbeits- oder Schuelerunfall ValueSet (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. | |
IN | verdachtFremdverschulden | 0..1 | boolean | 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. | ||
OUT | return | 1..1 | Resource (OperationOutcome) | Der return Parameter gibt Auskunft über den Erfolg der Operation. |
TBD: Ist hier evtl. eine Transaction die bessere Lösung? Bei dieser Operation findet keine Status-Änderung statt. Lediglich auf die Precondition des Workflow-Status müsste geachtet werden.