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 Versichertenanspruchserklärung $anfragen (POC)

Official URL: http://example.org/OperationDefinition/MOPED.CoverageEligibilityRequest.Anfragen Version: 0.1.0
Draft as of 2024-10-11 Responsible: Example Publisher Computable Name: MOPED_CoverageEligibilityRequest_Anfragen

Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen.

Voraussetzungen für den Aufruf:

  • Account-Status: 'Aufnahme freigegeben'

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).

  1. Vorbereitung des CoverageEligibilityRequest: Ein CoverageEligibilityRequest mit dem status 'active' und purpose 'validation' und dem created aktuellem Zeitpunkt wird vorbereitet. Die Extension ExtensionDays wird mit dem Operation-Parameter verlaengerungstage befüllt, die Extension PremiumClass mit dem Operation-Parameter sonderklasse.
  2. Suchen des MOPEDAccounts: Über die Referenz der Ressource MOPEDEncounter.account. Dabei handelt es sich um jenen Encounter, der den aufnahmezahl Parameter als identifier gespeichert hat.
  3. Referenzieren des Patienten: Eine Referenz auf den Patienten der als subject im MOPEDAccount geführt ist, wird im CoverageEligibilityRequest.patient Element referenziert
  4. Referenzieren der Coverage: Die gleiche Referenz wie im MOPEDAccount.coverage.coverage wird auch im CoverageEligibilityRequest referenziert. Check erfolgt, ob diese Coverage den gleichen Patienten als beneficiary hat wie das subject des CoverageEligibilityRequest. Außerdem wird geprüft, ob der versicherer an dem der Request gerichtet ist, auch tatsächlich als Coverage.insurer gelistet ist. Sollten im Account mehrere Coverages referenziert sein, so ist nur diejenige mitzusenden, die als Coverage.insurer den versicherer aus dem Operation-Parameter gespeichert hat.
  5. Referenzieren des Providers: Als provider Element wird die Organization referenziert, die als owner im MOPEDAccount referenziert ist.
  6. Einfügen des Versicherers: Als insurer Element wird die Organization referenziert, deren identifier dem Operation-Parameter versicherer entspricht.
  7. POSTen des neu erstellten CoverageEligibilityRequest
  8. Referenzierung des CoverageEligibilityRequest im MOPEDAccount im Element coverageEligibilityRequest.

Generated Narrative: OperationDefinition MOPED.CoverageEligibilityRequest.Anfragen

URL: [base]/Account/$anfragen

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INaufnahmezahl1..1Identifier

Der aufnahmezahl Parameter beinhält den eindeutigen Identifizierer für den relevanten Fall.

INversicherer1..1Identifier

Der versicherer Parameter beinhält den eindeutigen Identifizierer für den Versicherer an dem der CoverageEligibilityRequest gerichtet ist.

INverlaengerungstage0..1unsignedInt

Der verlaengerungstage beschreibt, um wie viele Verlängerungstage angefragt wird.

INsonderklasse0..1codemoped-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.

OUTreturn1..1Resource (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.