Moderne Patient:innenabrechnung und Datenkommunikation on FHIR (MOPED)
0.1.0 - ci-build

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Behavior: Operation Definitions

These are custom operations that can be supported by and/or invoked by systems conforming to this implementation guide.

MOPED Patient $aufnehmen (POC)

Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen.

Die Patient $aufnehmen Operation wird aufgerufen, wenn ein(e) Patient*in in das Krankenhaus aufgenommen wird.

  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.
  2. Account anlegen:
    • MOPEDAccount.WorkflowStatus: lt. Beschreibung der Werte-Ausprägungen des modus Parameter (siehe unten)
    • 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.coverage.coverage mit der Referenz lt. Parameter befüllen und ggf. Hauptversicherter (Patient) anlegen, falls noch nicht am Server. Hinweis: Eine vorangegangene VDAS-Anfrage an die SVC kann mehrere Coverages retournieren, im Input-Bundle falldaten wären somit mehrere Coverages die bei der Transaction angelegt werden. In diesem Fall sind alle im Account zu referenzieren.
  3. Account im Encounter referenzieren: Den neuen MOPEDAccount im MOPEDEncounter.account referenzieren

Die Werte-Ausprägung des modus Parameters haben eine Auswirkung auf das Verhalten der Operation:

  • zwischenspeichern: 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.
  • freigeben: 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.

  • Note 1: 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.
  • Note 2: 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.
MOPED Patient $beurlauben

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 XXX als Parameter, der Abgangsart YYY und ohne physische Anwesenheit. TBD: finde heraus, welcher Funktionscode und welche Abgangsart konkret für Urlaub stehen.

Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen.

MOPED Patient $entlassen (POC)

Diese Operation wurde noch nicht ausdefiniert - die Kommentare unterhalb dienen lediglich zur Orientierung und müssen noch stark verändert und erweitert werden.

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

Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen.

  1. Der Encounter erhält ein End-Datum (MOPEDEncounter.actualPeriod.end); der MOPEDEncounter.status wird auf discharged gesetzt
  2. Das Element MOPEDEncounter.admission.dischargeDisposition wird mit dem Operation-Parameter entlassungsart befüllt.
  3. Der alte MOPEDTransferEncounter der partOf des MOPEDEncounters mit der jeweiligen Aufnahmezahl war und noch den Status in-progress hat, wird gesucht. Der Status wird auf completed gesetzt und die MOPEDTransferEncounter.actualPeriod.end mit dem zeitpunkt der Entlassung versehen.
  4. Ein MOPEDClaim mit dem Status draft wird erstellt und in MOPEDAccount.claim referenziert.
  5. Änderungen am Account: der MOPEDAccount.WorkflowStatus wird auf Entlassungs Aviso gesetzt, oder, falls der modus-Parameter auf freigeben gesetzt war und die Validierung erfolgreich war, wird MOPEDAccount.WorkflowStatus auf Entlassung vollständig gesetzt. Ebenso im MOPEDAccount im Element TageOhneKostenbeitrag wird der gleichnamige Opeartion-Parameter abgespeichert. Dieser ist verpflichtend zu befüllen, wenn der modus-Parameter auf freigeben gestellt ist.
MOPED Patient $verlegen (POC)

Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen.

Die Patient $verlegen Operation wird aufgerufen, wenn ein(e) Patient*in auf eine andere Station verlegt wird.

  1. Neuer Transfer Encounter: Der MOPEDEncounter mit der jeweiligen Aufnahmezahl wird gesucht, und ein neuer MOPEDTransferEncounter der mit partOf den MOPEDEncounter referenziert wird erstellt. Beim neu erstellten MOPEDTransferEncounter wird der zeitpunkt als MOPEDTransferEncounter.actualPeriod.start eingefügt und als MOPEDTransferEncounter.serviceProvider die Abteilung MOPEDOrganizationAbteilung mit dem jeweiligen funktionscode referenziert.
  2. Alter Transfer Encounter: Der alte MOPEDTransferEncounter der partOf des MOPEDEncounters mit der jeweiligen Aufnahmezahl war und noch den Status in-progress hat, wird gesucht. Der Status wird auf completed gesetzt und die MOPEDTransferEncounter.actualPeriod.end mit dem zeitpunkt der Verlegung versehen. Ebenso wird beim alten Encounter die abgangsart von diesem Funktionscode dokumentiert.
  3. AnzahlBeurlaubungen: Dieser Counter gibt die Wiederaufnahmen nach Urlaub an. Wenn es sich beim alten MOPEDTransferEncounter der gerade auf completed gesetzt wurde um eine Beurlaubung gehandelt hat (i.e. Funktionscode XXX-TBD), dann wird der Counter Account.extension.AnzahlBeurlaubungen um 1 erhöht.
  4. AnzahlVerlegungen: Die Extension Account.extension.AnzahlVerlegungen im zur Aufnahmezahl gehöhrenden Account wird um 1 erhöht.
  5. Validierung: 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.

Note: Der Counter für AnzahlVerlegungen wird auch im Falle einer Beurlaubung erhöht, bei der eine reguläre Verlegung-Operation aufgerufen wird.

MOPED Versichertenanspruchserklärung $anfragen (POC)

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

  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.
Versichertenanspruchserklärung-Anfrage $checkStatus (POC)

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.
Versichertenanspruchserklärung-Anfragen $abholen (POC)

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

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

MOPED Aufnahme Bundle

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

  • Note 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.
  • Note 2: Es wird davon ausgegangen, dass der Patient bereits vor der Bundle-Erstellung mit dem ZPI abgeglichen wurde.
  • Note 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.
  • Note 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.

TBD: wenn es mehrere Coverages gibt, kann es auch mehrere Hauptversicherte geben. Diese müssen aber einer Coverage zugewiesen sein. Check, wie diese Zuordnung erfolgen kann.

MOPEDAccount

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

MOPEDClaim

MOPED Profil der Claim Ressource für die Leistungsabrechnungsanfrage.

MOPEDClaimResponse

MOPED Profil der ClaimResponse Ressource für die Leistungsabrechnungsantwort.

MOPEDCoverageEligibilityRequest

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

MOPEDCoverageEligibilityResponse

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

MOPEDEncounter

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

MOPEDOrganizationAbteilung

MOPED Profil für Abteilungen innerhalb einer Krankenanstalt.

MOPEDTransferEncounter

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

SVCCoverage

MOPED 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

Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide.

Abrechnung - Knoten

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

Abrechnungsquartal der Sozialversicherung

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

Altersgruppe

In Gruppen eingeteilt, wobei vollendete Lebensjahre ausschlaggebend sind.

Anzahl Sonderleistungen

MOPED Extension für die Anzahl der Sonderleistungen

AnzahlBeurlaubungen

MOPED Extension für die Anzahl der Beurlaubungen

AnzahlVerlegungen

MOPED Extension für die Anzahl der Verlegungen

Beihilfenaequivalent

MOPED Extension für das Beihilfenaequivalent

Claim Referenz

Referenz vom Account auf den Claim.

CoverageEligibilityRequest Referenz

Referenz vom Account auf den CoverageEligibilityRequest.

Diagnose - im stationären Aufenthalt erworben

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

EndOfEligibility

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.
Error/Warning

MOPED Extension für akzeptierte Errors und Warnings

Fondsrelevanz

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

Forderungsbetrag für Auslaenderverrechnung oder Regress

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

Kostenanteilbefreit laut Versicherungsanspruch

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

Kostenmeldung für (A/R/K)

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

Kostenstelle

MOPED Extension für akzeptierte Errors und Warnings

LDF-Betrag Netto

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

LDF-Punktewert Netto

MOPED Extension für den LDF-Punktewert Netto

Leistungskomponente/Leistungspunkte

In dieses Datenfeld ist – soweit zutreffend – die Leistungskomponente bzw. sind die Leistungspunkte einzutragen.

MealCostExcemption

VKBEFR – Verpflegskosten-Beitragsbefreiung

Medizinische Leistung - Abrechnungsrelevanz

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

Neugeborenes

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

Patientenanteil Netto

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

Patientenanteil für Angehoerige

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

Plausibilitaetskennzeichen

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

PremiumClass

KLAS – Allgemeine Gebührenklasse/Sonderklasse

Punkte Belagsdauerausreisser unten - Leistungskomponente

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.

Punkte Belagsdauerausreisser unten - Tageskomponente

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.

Punkte LDF Pauschale

MOPED Extension für die LDF Punkte Pauschale

Punkte spezieller Bereiche (tageweise)

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.

Punkte total

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

Rechnungsnummer der Krankenanstalt bzw. des Landesgesundheitsfonds

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

Rezeptgebührenbefreit laut Versicherungsanspruch

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

Sonderleistungsnummer

MOPED Extension für die Sonderleistungsnummer

Tage ohne Einhebung des Kostenbeitrags

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

Tageskomponente/Kontaktpunkte

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

Transportart

MOPED Extension für die Transportart.

Unfalldatum

MOPED Extension für das Ereignis-/Unfalldatum.

VAEStatus

"VAEST - Status der Versichertenanspruchserklärung"

VDAS-ID - VersichertenDatenAbfrageService

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.

Verdacht auf Arbeits- oder Schuelerunfall

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

Verdacht auf Fremdverschulden

MOPED Extension für den Verdacht auf Fremdverschulden

Verlaengerungstage

Anzahl der Verlaengerungstage bei Verlängerung

Vortageanzahl auf Kostenbeitrag

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.

Workflow Status

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

Zugangsart

MOPED Extension für die Art des Zugangs.

Zusatzpunkte Belagsdauerausreißer nach oben

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.

Zusatzpunkte Intensiv

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

Zusatzpunkte Mehrfachleistungen

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.

physische Anwesenheit

Ob der Patient physisch anwesend war.

Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide.

Abgangsart des Patienten

ValueSet für die Abgangsart des Patienten

Abrechnungsrelevanz der medizinischen Leistung

Abrechnungsrelevanz der medizinischen Leistung

Aufnahmeart des Patienten

ValueSet für die Aufnahmeart des Patienten

Behandlungsart

ValueSet für die Behandlungsart

Entlassungsart des Patienten

ValueSet für die Entlassungsart des Patienten

Fondsrelevanz

ValueSet für die Fondsrelevanz

Kostenmeldung für (A/R/K)

ValueSet für die Art der Kostenmeldung

Sonderklasse

ValueSet für die Klasse (KaOrg)

Transportart

ValueSet für die Transportart des Patienten

Ursache für Behandlung

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

Verdacht auf Arbeits- oder Schuelerunfall

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

Workflow Status eines Falls

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

Zugangsart des Patienten

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

Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

I12 Questionnaire für TISS-A-Daten
I12 QuestionnaireResponse für TISS-A-Daten
Krankenhaus der Barmherzigen Schwestern vom Hl. Vinzenz von Paul Ried

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

SAPS3 Questionnaire

A questionnaire for collecting SAPS3 data

Satzart K03 – KA-Statistik (Ressourcen und Inanspruchnahme)

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

Satzart K05 – KA-Statistik (Personal des ärztlichen Dienstes)

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

Test1Account
Test1Condition1
Test1MOPEDCoverageEligibilityRequest1
Test1MOPEDCoverageEligibilityResponse1
Test1MOPEDEncounter
Test1OrganizationAbteilung1
Test1OrganizationHerzJesuKrankenhaus

Organization Ressource für das Herz Jesu-Krankenhaus

Test1OrganizationInsurance1
Test1OrganizationUeberweisendeOrganisation
Test1Patient
Test1SVCCoverage
Test1TransferEncounter1
Test2Account
Test2Condition1
Test2Condition2
Test2MOPEDCoverageEligibilityRequest1
Test2MOPEDCoverageEligibilityResponse1
Test2MOPEDEncounter1
Test2OrganizationAbteilung1
Test2OrganizationAbteilung2
Test2OrganizationAbteilung3
Test2OrganizationAbteilung4
Test2OrganizationAbteilung5
Test2OrganizationInsurance1
Test2OrganizationUeberweisendeOrganisation
Test2Patient
Test2SAPS3QuestionnaireResponse1
Test2SVCCoverage
Test2TransferEncounter1
Test2TransferEncounter2
Test2TransferEncounter3
Test2TransferEncounter4
Test2TransferEncounter5