Die $auffordern Operation wird aufgerufen, wenn eine Abrechnung beantwortet wird und das Krankehaus zu einer Korrektur aufgefordert wird.

Die $freigeben Operation wird aufgerufen, wenn eine Abrechnung beantwortet wird und freigegeben wird.

Die $beantworten Operation wird aufgerufen, wenn eine Versichertenanspruchserklärung beantwortet wird.

Die $abrechnen Operation wird aufgerufen, wenn ein Fall abgerechnet werden sollte.

Die $erfassen Operation wird aufgerufen, wenn eine erbrachte Leistungen und Diagnosen eingemeldet 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. falldaten-Parameter befüllen und ggf. Hauptversicherten 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.

Annahmen an das BeS

• Es wurde vorab geprüft, ob das system des Parameters falldaten.encounter.identifier dem GDA entspricht, der die Operation aufruft. Somit ist sichergestellt, dass nur eigene Fälle aufgenommen werden können.

Wer ruft diese Operation in welchem Zusammenhang auf?

Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen. Die $entlassen Operation wird aufgerufen, wenn ein(e) Patient*in aus dem Krankenhaus entlassen wurde.

Voraussetzungen für den Aufruf

• Account-Status: SV verarbeitet

Detaillierte Business-Logik

1. Suche des MOPEDEncounter: Der MOPEDEncounter mit der jeweiligen aufnahmezahl lt. Operation-Parameter wird gesucht
2. Update des MOPEDEncounters:
   • MOPEDEncounter.actualPeriod.end mit dem zeitpunkt lt. Operation-Parameter befüllen
   • MOPEDEncounter.status mit discharged befüllen
   • MOPEDEncounter.admission.dischargeDisposition mit entlassungsart lt. Operation-Parameter befüllen
3. Suche des letzten MOPEDTransferEncounter: Mit MOPEDTransferEncounter.partOf einer Referenz auf den MOPEDEncounter aus Schritt 1 und den Status in-progress
4. Update des letzten MOPEDTransferEncounter:
   • MOPEDTransferEncounter.status mit completed befüllen gesetzt
   • MOPEDTransferEncounter.actualPeriod.end mit zeitpunkt lt. Operation-Parameter befüllen
5. Erstellung eines leeren MOPEDClaim:
   • MOPEDClaim.status mit draft befüllen
   • MOPEDClaim.patient mit MOPEDAccount.subject befüllen
6. Änderungen im Account:
   • MOPEDAccount.ClaimRef mit der Referenz aus Schritt 4 befüllen
   • MOPEDAccount.WorkflowStatus mit Entlassungs Aviso befüllen, oder, falls der freigeben-Operation-Parameter auf true gesetzt war und die Validierung erfolgreich war, wird MOPEDAccount.WorkflowStatus mit Entlassung vollständig befüllt.
   • MOPEDAccount.TageOhneKostenbeitrag lt. gleichnamigen Opeartion-Parameter befüllen

Validierung / Fehlerbehandlung

• Wenn der freigeben-Parameter auf true ist, muss eine Validierung aller Ressourcen (MOPEDEncounter, Account) erfolgreich sein, oder die Operation schlägt fehl.
• Wenn der freigeben-Parameter auf true ist, muss Information zu den Tagen ohne Kostenbeitrag vorliegen (i.e. der Operation-Parameter TageOhneKostenbeitrag muss befüllt sein)
• Wurden bei der Suche in Schritt 4 mehrere MOPEDTransferEncounter gefunden, liegen inkonsistente Daten vor und die Operation schlägt fehl.

Weitere Hinweise

• Hinweis 1: Wurde der Patient direkt aus der Intensivstation entlassen, so müsste auch eine Abgangsart im MOPEDTransferEncounter gesetzt werden. Dieser Spezialfall wurde noch nicht berücksichtigt.

Annahmen an das BeS

• Es wurde vorab geprüft, ob das system des Parameters aufnahmezahl dem GDA entspricht, der die Operation aufruft. Somit ist sichergestellt, dass nur eigene Fälle entlassen werden können.

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 $verlegen Operation wird aufgerufen, wenn ein(e) Patient*in auf eine andere Station verlegt wird. Auch initial, wenn ein Patient auf eine bestimmte Station aufgenommen wird, wird diese Operation aufgerufen (dies passiert automatisch im Zuge der Operation $aufnehmen).

Voraussetzungen für den Aufruf

• Account-Status: Aufnahme in Arbeit oder Aufnahme freigegeben

Detaillierte Business-Logik

1. Suche des MOPEDEncounter: Der MOPEDEncounter mit der jeweiligen aufnahmezahl lt. Operation-Parameter wird gesucht
2. Neuer Transfer Encounter:
   • Ein neuer MOPEDTransferEncounter wird vorbereitet
   • MOPEDTransferEncounter.partOf referenziert den MOPEDEncounter aus Schritt 1.
   • MOPEDTransferEncounter.actualPeriod.start wird mit dem zeitpunkt lt. Operation-Parameter befüllt.
   • MOPEDTransferEncounter.serviceProvider setzt eine Referenz auf die MOPEDOrganizationAbteilung mit dem jeweiligen funktionscode bzw. funktionssubcode lt. Operation-Parameter.
   • MOPEDTransferEncounter.Neugeborenes wird lt. LKF-Regeln berechnet, anhand des MOPEDEncounter.subject.birthdate aus dem Encounter aus Schritt 1 (für Berechnugns-Details siehe Hinweis 1).
   • MOPEDTransferEncounter.Altersgruppe wird lt. LKF-Regeln berechnet, anhand des MOPEDEncounter.subject.birthdate aus dem Encounter aus Schritt 1 (für Berechnugns-Details siehe Hinweis 2).
   • MOPEDTransferEncounter.PhysischeAnwesenheit wird lt. Operation-Parameter befüllt.
3. Account AnzahlVerlegungen: Die Extension Account.extension.AnzahlVerlegungen im zur Aufnahmezahl gehöhrenden Account wird um 1 erhöht. Dies ist auch so, wenn es sich bei der Verlegung um einen Urlaub handeln sollte (siehe Hinweis 3).
4. Alter Transfer Encounter:
   • Dieser Schritt ist nur relevant, wenn es sich nicht um eine Neufaufnahme (lt. Operation-Parameter) handelt.
   • Suche des alten MOPEDTransferEncounter: Mit MOPEDTransferEncounter.partOf einer Referenz auf den MOPEDEncounter aus Schritt 1 und den Status in-progress
   • 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.
5. Account AnzahlBeurlaubungen:
   • Dieser Schritt ist nur relevant, wenn es sich nicht um eine Neufaufnahme (lt. Operation-Parameter) handelt.
   • War alter MOPEDTransferEncounter aus Schritt 4.2 ein Urlaub (i.e. Funktionscode 10000000)?
   • Wenn ja, dann wird der Counter Account.extension.AnzahlBeurlaubungen um 1 erhöht.

Validierung / Fehlerbehandlung

• Bei Neuaufnahme (lt. Operation-Parameter) muss das Feld AnzahlVerlegungen nach Ausführen der Operation $verlegen den Wert 1 aufweisen und das Feld AnzahlBeurlaubungen den Wert 0.
• Es kann immer nur einen MOPEDTransferEncounter für den jeweiligen Fall geben der partOf eines MOPEDEncounters mit der aufnahmezahl ist und den Status in-progress hat.
• Wenn es sich um eine Neuaufnahme (lt. Operation-Parameter) handelt, kann es keine Abgangsart (Operation-Parameter) geben.

Weitere Hinweise

• Hinweis 1: LKF 4.2.16 Neugeborenes
  • Ja (Alter zum Zugangszeitpunkt auf die Abteilung <28 Tage)
  • Nein (Alter zum Zugangszeitpunkt auf die Abteilung >=28 Tage)
• Hinweis 2: LKF 4.1.9 Altersgruppe bei Entlassung/Kontakt
  • Vollendete Lebensjahre sind ausschlaggebend
  • 0: 0
  • 1-4: 1
  • 5-9: 5
  • 10-14: 10
  • 15-19: 15
  • 20-24: 20
  • … immer weiter so, die untere Grenze des Alters in 5er-Schritten
  • 85-89: 85
  • 90-95: 90
  • 95 und älter: 95
• Hinweis 3: Der Counter für AnzahlVerlegungen wird auch im Falle einer Beurlaubung erhöht, bei der eine reguläre Verlegung-Operation aufgerufen wird.

Annahmen an das BeS

• Es wurde vorab geprüft, ob das system des Parameters aufnahmezahl dem GDA entspricht, der die Operation aufruft. Somit ist sichergestellt, dass nur eigene Fälle verlegt werden können.

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

• Account-Status: : Aufnahme freigegeben

Detaillierte Business-Logik

1. Suche des MOPEDEncounter: Der MOPEDEncounter mit der jeweiligen aufnahmezahl lt. Operation-Parameter wird gesucht
2. Suchen des MOPEDAccounts: Die Referenz des MOPEDEncounter.account aus Schritt 1.
3. Erstellung des MOPEDCoverageEligibilityRequest:
   • a. MOPEDCoverageEligibilityRequest.status mit 'active' befüllen
   • b. MOPEDCoverageEligibilityRequest.purpose mit 'validation' befüllen
   • c. MOPEDCoverageEligibilityRequest.created mit dem aktuellem Zeitpunkt befüllen
   • d. MOPEDCoverageEligibilityRequest.ExtensionDays mit verlaengerungstage lt. Operation-Parameter befüllen
   • e. MOPEDCoverageEligibilityRequest.PremiumClass mit sonderklasse lt. Operation-Parameter befüllen
   • f. MOPEDCoverageEligibilityRequest.patient mit MOPEDAccount.subject befüllen
   • g. MOPEDCoverageEligibilityRequest.insurance.coverage mit MOPEDAccount.coverage.coverage befüllen
   • h. MOPEDCoverageEligibilityRequest.provider mit MOPEDAccount.owner befüllen
   • i. MOPEDCoverageEligibilityRequest.insurer mit einer Referenz auf jene Organization befüllen, deren Organization.identifier dem Identifier versicherer lt. Operation-Parameter entspricht
4. POSTen des neu erstellten CoverageEligibilityRequest
5. Referenz im MOPEDAccount: a. MOPEDAccount.coverageEligibilityRequest mit Hilfe der resultierenden ID aus Schritt 6 referenzieren

Validierung / Fehlerbehandlung

• MOPEDAccount.coverage darf nur eine Versicherung gelistet haben
• CoverageEligibilityRequest.subject muss mit Coverage.beneficiary aus Schritt 3g übereinstimmen
• MOPEDCoverageEligibilityRequest.insurer muss mit Coverage.insurer aus Schritt 3g übereinstimmen
• MOPEDCoverageEligibilityRequest.provider muss gleichzeitig die gleiche Organisation sein, die lt. Token die Operation aufgerufen hat.

Weitere Hinweise

• Hinweis 1: Nach dieser Operation findet lt. Soll-Prozess kein Update des Status MOPEDAccount.workflowStatus statt.

Annahmen an das BeS

• Es wurde vorab geprüft, ob das 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.

MOPED Profil der Person Ressource für den Hauptversicherten

Bundle für die Input-Ressourcen bei Patienten-Aufnahme

• Hinweis 1: Anstelle einer separaten GDA-Organization-Ressource ist angedacht, hier mit einer conditional Reference in der Ressource Encounter mit entsprechendem GDA-identifier zu arbeiten. Somit wird auch vermieden, dass Duplikate einer GDA-Organization-Ressource am Server angelegt/verwendet werden.
• Hinweis 2: Es wird davon ausgegangen, dass der Patient bereits vor der Bundle-Erstellung mit dem ZPI abgeglichen wurde.
• Hinweis 3: Es wird davon ausgegangen, dass vor der Bundle-Erstellung eine VDAS-Abfrage gestellt wurde. Die Coverage-Ressourcen in diesem Transaction-Bundle speichern die Ansprüche aufgrund der VDAS-Abfrage in Moped ein.
• Hinweis 4: In Zukunft wird Moped auch die Datenübermittlung von Selbstzahlern und Privatversicherten unterstützen. Für diese Ansprüche werden separate Coverage-Profile definiert werden und dieses Bundle wird in weiterer Folge unterschiedliche Coverage-Arten unterstützen.
• Hinweis 5: Eine vorangegangene VDAS-Anfrage an die SVC kann mehrere Coverages retournieren. In diesem Fall wählt der Patient/die Patientin direkt bei aufnahme eine Versicherung aus, welche im Zuge der Aufnahme gespeichert wird. Das ist der Grund für die Kardinalität 1..1 der Coverage in diesem Bundle.

MOPED Profil der Encounter Ressource für die Krankenanstaltenaufnahme und Entlassung

MOPED Profil der Encounter Ressource für die Rolle: Bund

MOPED Profil der Encounter Ressource für die Rolle: KH

MOPED Profil der Encounter Ressource für die Rolle: LGF

MOPED Profil der Encounter Ressource für die Rolle: SV

MOPED Profil der Patient Ressource aus der Sicht der Rolle: Bund

MOPED Profil der Patient Ressource aus der Sicht der Rolle: Bund (invariant)

MOPED Profil der Patient Ressource aus der Sicht der Rolle: LGF

MOPED Profil der Patient Ressource aus der Sicht der Rolle: SV

MOPED Profil der Account Ressource für die administrative Fallführung und Abrechnung.

MOPED Profil der Claim Ressource für die Leistungsabrechnungsanfrage.

MOPED Profil der ClaimResponse Ressource für die Leistungsabrechnungsantwort.

MOPED Profil der Condition Ressource für die LDF-Abrechnung

MOPED Profil der CoverageEligibilityRequest Ressource für die Versichertenanspruchserklärung-Anfrage.

MOPED Profil der CoverageEligibilityResponse Ressource für die Versichertenanspruchserklärung-Antwort.

MOPED Profil für Abteilungen innerhalb einer Krankenanstalt.

MOPED Profil der Procedure Ressource für die LDF-Abrechnung

MOPED Profil der Encounter Ressource für die Verlegung innerhalb oder zwischen Krankenanstalten

SVC Profil der Coverage Ressource für Versicherungen. Basierend auf dem Profil "ecardAnspruch": https://www.chipkarte.at/de/vdas-on-fhir/site/StructureDefinition-ecard-anspruch-profile.html

Lukriert die Patient:innen über eine reguläre Gruppe Punkte, so ist in diesem Datenfeld die entsprechende Knotenbezeichnung einzutragen.

Das Abrechnungsquartal ist in der Form Jahr (JJJJ) und Quartal (Q) zu melden.

In Gruppen eingeteilt, wobei vollendete Lebensjahre ausschlaggebend sind.

MOPED Extension für die Anzahl der Sonderleistungen

MOPED Extension für die Anzahl der Beurlaubungen

MOPED Extension für die Anzahl der Verlegungen

MOPED Extension für das Beihilfenaequivalent

Referenz vom Account auf den Claim.

Referenz vom Account auf den CoverageEligibilityRequest.

Fristende - Befristungen sind in folgenden Fällen vorgesehen:

• Bei zeitlichen Beschränkungen aufgrund einer zu erwartenden, nachfolgenden medizini- schen Hauskrankenpflege
• Bei Vorhersehbarkeit des Eintritts einer Asylierung
• Bei unsicherer, versicherungsrechtlicher Entwicklung Bei den ersten beiden Punkten wird von den Krankenversicherungsträgern das Fristende individuell gesetzt. Beim dritten Punkt wird im Regelfall eine generelle Tagesbeschränkung erfolgen, weil die Versichertenanspruchserklärung in die Zukunft gerichtet ist und der Krankenversicherungsträger seine Zuständigkeit von vornherein nur für einen bestimmten Zeitraum annehmen kann (Ausleis- tungssituation gem. § 122 ASVG). Durch die Angabe eines Fristendes wird signalisiert, dass bei einem über das Fristende hinaus dau- ernden Aufenthalt eine Verlängerungsanzeige vorzulegen ist.

MOPED Extension für akzeptierte Errors und Warnings

Hier ist anzugeben, ob der stationäre Aufenthalt/ambulante Besuch gegenüber dem Landesgesundheitsfonds/PRIKRAF abzurechnen ist.

MOPED Extension für den Forderungsbetrag für Ausländerverrechnung oder Regress

Kostenanteilbefreiung für den Patienten, die direkt an den Anspruch geknüpft ist. Kostenanteile sind entweder laut Gesetz vorgegeben (z.B. Rezeptgebühr) oder sie sind in der Satzung des jeweiligen KV-Trägers verankert und werden meistens errechnet (z.B. für Heilbehelfe und Hilfsmittel).

MOPED Extension für die Kostenmeldung. Konstenmeldung für A = Ausländerverrechnung, R = Regressangelegenheiten oder K = Kosteninformation

MOPED Extension für akzeptierte Errors und Warnings

MOPED Extension für den LDF-Punktewert Netto. Ergibt sich durch Punkteanzahl mal Punktewert Forderungsbasis ohne Berücksichtigung eines Patientenanteiles f. Angehörige bzw. eines Beihilfenäquivalentes

MOPED Extension für den LDF-Punktewert Netto

In dieser Extension werden alle möglichen Punkteangaben im LKF zusammengefasst.

VKBEFR – Verpflegskosten-Beitragsbefreiung

Hier ist anzugeben, ob die medizinische Leistung bei der Bepunktung des ambulanten Besuchs/stationären Aufenthalts (Satzart X01) zu berücksichtigen ist.

Ein Patient wird als Neugeborenes bezeichnet, wenn das Alter zum Zugangszeitpunkt auf die Abteilung <28 Tage ist.

MOPED Extension für den Patientenanteil netto: Betrag in €, 2 Nachkommastellen

MOPED Extension für den Patientenanteil für Angehörige (tägl. Satz) netto: Betrag in €, 2 Nachkommastellen

Dieses Datenfeld enthält eine Kennzeichnung als Ergebnis der vom Gesundheitsministerium vorgegebenen Plausibilitätsprüfung.

KLAS – Allgemeine Gebührenklasse/Sonderklasse

MOPED Extension für die LDF Punkte Pauschale

MOPED Extension für die Rechnungsnummer der Krankenanstalt bzw. des Landesgesundheitsfonds

Rezeptgebührenbefreiung für den Patienten, die direkt an den Anspruch geknüpft ist. Der Patient ist von der Entrichtung der Rezeptgebühr befreit. Kostenanteile sind entweder laut Gesetz vorgegeben (z.B. Rezeptgebühr) oder sie sind in der Satzung des jeweiligen KV-Trägers verankert und werden meistens errechnet (z.B. für Heilbehelfe und Hilfsmittel).

MOPED Extension für die Sonderleistungsnummer

Anzahl der Tage, für welche kein Kostenbeitrag seitens der Krankenanstalt eingehoben wurde

MOPED Extension für die Transportart.

MOPED Extension für das Ereignis-/Unfalldatum.

"VAEST - Status der Versichertenanspruchserklärung"

Es handelt sich um eine ID, welche bei der VDAS-Abfrage durch die Krankenanstalt vom e-card System vergeben wird und von der Krankenanstalt in der Aufnahme-/Ereignisanzeige mitgeliefert werden kann. Dadurch kann das Abfrageergebnis eindeutig nachvollzogen werden. Das Ergebnis der VDAS-Abfrage ist im ambulanten Bereich für den Krankenversicherungsträger verbindlich. Eine Ablehnung aus versicherungsrechtlichen Gründen ist nicht möglich, sofern die Ereignisanzeige jenem Träger aus der VDAS-Abfrage (inkl. VDAS-ID) übermittelt wurde. Um eine zwischenstaatliche Verrechnung zu ermöglichen ist bei zwischenstaatlichen Fällen eine Ablehnung zulässig.

MOPED Extension für den Verdacht auf einen Arbeits- oder Schuelerunfall.

MOPED Extension für den Verdacht auf Fremdverschulden

Anzahl der Verlaengerungstage bei Verlängerung

Zur Berechnung des Verpflegskostenbeitrags für Versicherte sowie des Kostenbeitrags für Angehörige ist die Angabe der zu berücksichtigenden Vortage erforderlich. Der Krankenversicherungsträger ist auf Grund der ihm zugänglichen Informationen in der Lage, Vorpflegetage zu berücksichtigen. Berücksichtigt werden alle stationären Aufenthalte eines Patienten innerhalb eines Kalenderjahres. Der höchste Wert, mit welchem das Feld VTAGE befüllt werden kann, ist jener Wert, für welchen maximal ein Verpflegskostenbeitrag pro Kalenderjahr zu entrichten ist. Der Maximale Höchstwert beträgt somit 28 Tage.

MOPED Extension für den Workflowstatus. Dieser beschreibt den Zustand in dem sich der administrative Fall derzeit befindet

MOPED Extension für die Art des Zugangs.

Ob der Patient physisch anwesend war.

ValueSet für die Abgangsart des Patienten

Abrechnungsrelevanz der medizinischen Leistung

ValueSet für die Aufnahmeart des Patienten

Befreiung für den Verpflegskostenbeitrag

ValueSet für die Behandlungsart

ValueSet für die Entlassungsart des Patienten

ValueSet für die Fondsrelevanz

ValueSet für die Art der Kostenmeldung

LKF Abrechnungsgruppe

LKF Abrechnungsknoten

LKF Hauptdiagnosegruppen

Nummer für Sonderleistung

ValueSet für die Klasse (KaOrg)

Status der Versichertenanspruchserklärung

ValueSet für die Transportart des Patienten

ValueSet für die Ursache der Behandlung laut Ka-Org

ValueSet für den Verdacht auf einen Arbeits- oder Schuelerunfall

ValueSet für die Statusoptionen in denen sich ein Fall befinden kann.

ValueSet für die Zugangsart des Patienten (LKF + Ka-Org)