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

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.

Die Patient $beurlauben Operation wird aufgerufen, wenn ein(e) Patient*in in das Krankenhaus aufgenommen wurde und während eines laufenden Falles beurlaubt wird. Die Operation $verlegen wird aufgerufen mit dem Funktionscode '10000000' als Parameter, der Abgangsart '1' und ohne physische Anwesenheit.

Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen.

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.

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.

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.

Die Versichertenanspruchserklärung-Anfrage $checkStatus Operation wird aufgerufen, um zu überprüfen, in welchem Status sich die Bearbeitung seitens SV derzeit befindet. Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen.

1. 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.
2. Suchen des Requests: Es geht um jenen Request, der in MOPEDAccount.coverageEligibilityRequest Feld referenziert wurde
3. Suche nach einer CoverageEligibilityResponse die im Feld CoverageEligibilityResponse.request den Request aus Schritt 2 referenziert
   • Sollte es mehrere Responses zu einem Request geben, ist das eine Inkonsistenz die zu einer Fehlermeldung führen soll
   • Gibt es eine Response, so ist zu prüfen in welchem CoverageEligibilityResponse.status die Ressource aufscheint:
   • draft: Draft in Kombination mit dem outcome-Wert queued heißt, dass die SV den jeweiligen Request bereits ausgeliefert bekommen hat, jedoch die Bearbeitung noch nicht begonnen hat. Ein draft-Status in Kombination mit einem anderen outcome-Wert ist ungültig und sollte zu einer Fehlermeldung führen.
   • active: Active in Kombination mit dem outcome-Wert queued bedeutet, dass die SV aktiv gestartet hat, den CoverageEligibilityRequest zu bearbeiten, es jedoch noch kein Resultat gibt. Ist der outcome mit dem Wert completed, error oder partial befüllt, ist die SV mit der Response fertig und eine Meldung kann ausgegeben werden, dass die freigegebene CoverageEligibilityResponse vom Krankenhaus abgeholt werden kann.

Die Operation wird vom Akteur Sozialversicherung (SV) aufgerufen. Die Versichertenanspruchserklärung-Anfragen $abholen Operation wird aufgerufen, um alle noch offenen Versichertenanspruchserklärung-Anfragen, die bisher seitens SV noch nicht bearbeitet wurden, abgeholt werden können.

1. Suche nach relevanten Requests: Alle CoverageEligibilityRequests,
   • die im Feld CoverageEligibilityRequest.insurer die Organization mit Organization.identifier = Operation-Parameter versicherer referenziert haben UND
   • die noch keine gezugehörigen CoverageEligibilityResponse haben (CoverageEligibilityRequest CEReq where not exists CoverageEligibilityResponse with CoverageEligibilityResponse.request = CEReq). Der Status der Resposne ist dabei irrelevant.
2. Zusammenstellen des Return-Bundles: Mit der gleichen Logik wie der _include Suchparameter um die relevanten Ressourcen (Patient, Coverage) direkt mitbekommen zu können.
3. Erstellung eine Draft CoverageEligibilityResponse für jeden der ausgelieferten Requests:
   • mit Feld CoverageEligibilityResponse.status = draft
   • mit Feld CoverageEligibilityResponse.request = Referenz auf jeweiligen Request
   • mit Feld CoverageEligibilityResponse.outcome = queued

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 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 CoverageEligibilityRequest Ressource für die Versichertenanspruchserklärung-Anfrage.

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

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

MOPED Profil für Abteilungen innerhalb einer Krankenanstalt.

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.

MOPED Extension, um anzugeben, ob die Diagnose während des stationären Aufenthalts erworben wurde.

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 dieses Datenfeld ist – soweit zutreffend – die Leistungskomponente bzw. sind die Leistungspunkte einzutragen.

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

In dieses Datenfeld ist – soweit zutreffend – die ermittelte Leistungskomponente für jene Patient:innen einzutragen, deren Belagsdauer des akutstationären Krankenhausaufenthalts unter der im LKF-Modell in der jeweiligen LDF-Pauschale festgelegten Belagsdaueruntergrenze liegt.

In dieses Datenfeld ist – soweit zutreffend – die ermittelte Tageskomponente für jene Patient:innen einzutragen, deren Belagsdauer des akutstationären Krankenhausaufenthalts unter der im LKF-Modell in der jeweiligen LDF-Pauschale festgelegten Belagsdaueruntergrenze liegt.

MOPED Extension für die LDF Punkte Pauschale

In dieses Datenfeld ist – soweit zutreffend – die Summe der tageweise ermittelten Punkte für einen stationären Krankenhausaufenthalt in speziellen Leistungsbereichen (z.B. in den Bereichen der Kinder- und Jugendpsychiatrie, der Akut-Nachbehandlung von neuro- logischen Patient:innen, der medizinischen Geriatrie, der Akutgeriatrie/Remobilisation sowie der palliativmedizinischen Einrichtungen) einzutragen.

In dieses Datenfeld ist die Gesamtsumme der für den stationären Aufenthalt/den ambulanten Besuch ermittelten Punkte einzutragen.

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

In dieses Datenfeld ist – soweit zutreffend – die Tageskomponente bzw. sind die Kontakt- punkte einzutragen.

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.

In dieses Datenfeld ist – soweit zutreffend – die Summe der tageweise ermittelten Zusatz- punkte für jene Patient:innen einzutragen, deren Belagsdauer des akut-stationären Krankenhausaufenthaltes über der im LKF-Modell in der jeweiligen LDF-Pauschale fest- gelegten Belagsdauerobergrenze liegt.

In dieses Datenfeld ist – soweit zutreffend – die Summe der Zusatzpunkte für während des stationären Krankenhausaufenthalts angefallene Tage auf abrechnungsrelevanten Intensiveinheiten einzutragen.

In dieses Datenfeld ist – soweit zutreffend – die Summe der Zusatzpunkte für zusätzliche Leistungen außerhalb des Punktepauschales der zur Abrechnung gelangenden Gruppe einzutragen.

ValueSet für die Abgangsart des Patienten

Abrechnungsrelevanz der medizinischen Leistung

ValueSet für die Altersgruppe des Patienten

ValueSet für die Anwesenheitsart

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

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)

Organization Ressource für das Krankenhaus der Barmherzigen Schwestern vom Hl. Vinzenz von Paul Ried

A questionnaire for collecting SAPS3 data

This questionnaire is used to collect KA-Statistik data for K03 message reporting.

This questionnaire is used to collect KA-Statistik data for K05 message reporting.

Organization Ressource für das Herz Jesu-Krankenhaus