MOPED feat. VDAS-on-FHIR 2025

Acknowledgement

The given structure of this track is mainly based on HL7 International's Connectathon Patient Track definition.

Short Description

In diesem Track werden verschiedene Funktionalitäten erprobt. Zum einen wird eine Testversion der VDAS-Abfrage bereitgestellt, die den Zugriff auf Versichertendaten mittels FHIR-Standards ermöglicht. Zum anderen wird eine Proof-of-Concept-Implementierung des Projekts MOPED getestet, das die Abrechnung und Datenmeldungen von Krankenanstalten an Sozialversicherungsträger, Landesgesundheitsfonds und Bund harmonisieren soll.

Long Description

In diesem Track erkunden die Teilnehmer*innen die Nutzung von FHIR zur Abfrage und Verarbeitung von Gesundheitsdaten in unterschiedlichen Schwierigkeitsgraden. Der Fokus liegt dabei auf zwei zentralen Anwendungsfällen: der VDAS-Abfrage von Versichertendaten und dem MOPED-Prozess zur Abrechnung und Meldung von Behandlungsdaten.

Die fünf Level bieten eine schrittweise Heranführung an die Thematik – von grundlegenden Abfragen bis hin zu komplexen End-to-End-Szenarien und experimentellen Prozessvarianten. Die Teilnehmenden arbeiten mit gängigen REST-Tools wie Postman oder Insomnia sowie Entwicklungsumgebungen wie Visual Studio Code zur Verarbeitung von JSON-Dateien.

Ziele des Tracks:

  • Erprobung der VDAS-Abfrage zur Abfrage von Versichertendaten.

  • Testing der MOPED-Proof-of-Concept-Implementierung zur Harmonisierung von Abrechnung und Meldung im Gesundheitswesen.

  • Simulation komplexer Prozessvarianten und Erhebung von Erkenntnissen für zukünftige Weiterentwicklungen.

Type

Experimental

Submitting Work Group/
Project/
Accelerator/
Affiliate/
Implementer Group  

HL7 Austria / TC FHIR / AG MOPED

Track Lead(s)

Anja Schwab 🛵

Anna Lin 🛵

Dragana Zemen 🪪

Track Lead Email(s)

tc-fhir@hl7.at

Related Tracks

HL7 AT FHIR Core IG Track (weil viele Moped- und VDAS-Ressourcen darauf basieren)

FHIR Version

FHIR R5

Specification(s) this track uses
Artifacts of focus

Folgende Operations sowie sämtliche Input- und Output-Ressourcen bzw. Profile:

VDAS Artifacts 🪪 :

Moped Artifacts 🛵 :

Date / Time

Monday March 03, 09:00am-16:30pm CET

Test Servers

Die VDAS-Funktionalität 🪪 wird für den Hackathon zu Test-Zwecken temporär und in eingeschränkter Funktionalität auf folgendem Test-Server zur Verfügung gestellt:

Die MOPED-Funktionalität 🛵 (Benutzer, Rechte, Operationen) ist derzeit ausschließlich auf dem Testserver der pineIT GmbH verfügbar.

Expected participants

Level 1 (FHIR Anfänger - Lesen von Stammdaten):

  • Voraussetzungen: Es sind keine Vorkenntnisse in FHIR oder den dazugehörigen CRUD-Requests erforderlich.

  • Inhalte: Abfragen von Stammdaten (Organization Ressourcen von Krankenanstalten und Sozialversicherungsträgern)

  • Software-Tools: Es sind Interaktionen sowohl mit dem Browser als auch mit REST-Tools wie Postman oder Insomnia möglich.

Level 2 (Leicht Fortgeschrittene - VDAS Abfrage 🪪):

  • Voraussetzungen: Erste grundlegende Abfragen von FHIR-Ressourcen sowie das Lesen und Verstehen der Antworten sind Voraussetzung. Diese Erfahrungen können im Rahmen des Hackathons im Level 1 oder mithilfe des Tracks HL7 AT FHIR Core IG erworben werden, falls sie nicht bereits vorhanden sind – manche Teilnehmer werden diese Kenntnisse bereits mitbringen.

  • Inhalte: Lesen und Anwenden von Implementation-Guides, Erstellen einer VDAS-Abfrage sowie das Lesen der VDAS-Antwort.

  • Software-Tools: Software-Tools: Interaktionen mit REST-Tools wie Postman oder Insomnia sind möglich. Zur Unterstützung stehen vorbereitete Beispiele als Postman-Collection zur Verfügung.

Level 3 (Fortgeschrittene - VDAS 🪪 trifft Moped 🛵):

  • Voraussetzungen: Erste grundlegende Abfragen von FHIR-Ressourcen sowie das Lesen und Verstehen der Antworten sind Voraussetzung. Diese Erfahrungen können im Rahmen des Hackathons im Level 1 oder mithilfe des Tracks HL7 AT FHIR Core IG erworben werden, falls sie nicht bereits vorhanden sind – manche Teilnehmer werden diese Kenntnisse bereits mitbringen.

  • Inhalte: Lesen und Anwenden von Implementation-Guides, Erstellen einer VDAS-Abfrage sowie die Umwandlung der Ergebnisse in den für die Initiierung des Datensatzes in MOPED erforderlichen Input.

  • Software-Tools: Interaktionen mit REST-Tools wie Postman oder Insomnia sind möglich. Zur Unterstützung stehen vorbereitete Beispiele als Postman-Collection zur Verfügung. Für die Umwandlung der VDAS-Ressourcen in MOPED-Input empfiehlt es sich, Visual Studio Code oder eine andere Entwicklungsumgebung mit Unterstützung für JSON-Dateien installiert zu haben.

Level 4 (Fortgeschrittene - der vollständige Prozess von Anfang 🪪 bis Ende 🛵) :

  • Voraussetzungen: Interaktionen mit FHIR-Ressourcen (Abfragen, Ausführen von Operations) sowie das Lesen und Verstehen der Antworten sind Voraussetzung.

  • Inhalte: Durchführung der gesamten Patient Journeys (von VDAS über Aufnahme, Kostenübernahme und Abrechnung bis zur Meldung an den Bund) gemäß Sunshine-Case wie in dieser Gesamtübersicht beschrieben: Hackathon Gesamtübersicht (Moped)

  • Software-Tools: Interaktionen mit REST-Tools wie Postman oder Insomnia sind möglich. Zur Unterstützung stehen vorbereitete Beispiele als Postman-Collection zur Verfügung. Für die Umwandlung der VDAS-Ressourcen in MOPED-Input empfiehlt es sich, Visual Studio Code oder eine andere Entwicklungsumgebung mit Unterstützung für JSON-Dateien installiert zu haben.

Level 5 (Fortgeschrittene - experimentelle Abweichungen vom Sunshine-Case 🛵)

  • Voraussetzungen: Interaktionen mit FHIR-Ressourcen sowie Verständnis für den Moped-Prozess im Sunshine-Case sind Voraussetzung.

  • Inhalte: Experimentelle Durchführung leichter Abweichungen vom Sunshine-Case (Dazu gehören mehrfach geänderte Erfassungen von Diagnosen und Leistungen, Korrekturaufforderungen durch den LGF sowie Ablehnungen seitens der SV.) Dieses Level liegt außerhalb des Umfangs der bereitgestellten Implementierung auf dem Testserver und dient in erster Linie der Sammlung von Erfahrungen und der Erkundung möglicher Szenarien.

  • Software-Tools: Interaktionen mit REST-Tools wie Postman oder Insomnia sind möglich. Für die Erstellung experimenteller Test-Ressourcen empfiehlt es sich, Visual Studio Code oder eine andere Entwicklungsumgebung mit Unterstützung für JSON-Dateien installiert zu haben.

Track Details

System Roles

FHIR Client

Die Client-Akteure repräsentieren die Rollen von Krankenanstalten, Sozialversicherungen, Landesgesundheitsfonds und dem Bund: Akteure von Moped

Sie rufen über verschiedene Operationen unterschiedliche Daten ab (z. B. die VDAS-Anfrage oder die Kostenübernahme-Anfrage) und übermitteln gleichzeitig die erforderlichen Daten für den Aufbau des MOPED-Datensatzes mittels weiterer Operationen.

Lesende Zugriffe auf FHIR-Ressourcen, die auf dem Server gespeichert sind, können über standardkonforme GET-Abfragen und Queries mit entsprechenden Filtern durchgeführt werden.

FHIR Server

Es wird davon ausgegangen, dass ausschließlich die aufgeführten Testserver die erforderliche Funktionalität oder deren Teilbereiche serverseitig implementieren. Für die grundlegende schreibende Funktionalität sind mehrere FHIR-Operationen erforderlich, die mit hinterlegter Business-Logik versehen sind, um die Datenkonsistenz sicherzustellen.

Scenarios

Level 1 - Wer ist mit am Start: Die Stammdaten im Überblick

(a) Lesen einer bestimmten Organization 🏢

  • Aktion: Der FHIR-Client (Browser oder REST-Tool) ruft eine bereits bekannte Organization-Ressource anhand ihrer ID ab.

  • Voraussetzung: Authentifizierung mit einem beliebigen Benutzer. Auf dem Server existiert eine FHIR-Organization-Ressource, deren ID bekannt ist.

  • Erfolgskriterium: Die HTTP-Response liefert die Ressource entweder im JSON- oder XML-Format. Im Browser wird ggf. eine gerenderte Ansicht angezeigt, die die Stammdaten der Organisation (Name, Adresse etc.) widerspiegelt.

  • Bonus-Punkte: Die Art der Organisation wird erkannt: Handelt es sich um eine Krankenanstalt, eine Abteilung oder einen Sozialversicherungsträger? Wie kann dies unabhängig von der jeweiligen ID identifiziert werden? Bei einer Abteilung wird die zugehörige Krankenanstalt erkannt. Zusätzlich kann die Adresse dieser Krankenanstalt angegeben werden.

  • Beispiel-IDs für die Abfrage: OrganizationHerzJesuKrankenhaus oder AbteilungKHRied1 oder oegk-wien

(b) Abfragen aller am Server liegenden Organizations 🏢 🏢 🏛️ 🏢 🏢 🏢🏛️

  • Aktion: Der FHIR-Client (Browser oder REST-Tool) fragt alle auf dem MOPED-Server gespeicherten Organization-Ressourcen ab.

  • Voraussetzung: Authentifizierung mit einem beliebigen Benutzer. Es existiert mindestens eine Organization-Ressource auf dem Server.

  • Erfolgskriterium: Die HTTP-Response liefert die Ressourcen entweder im JSON- oder XML-Format. Im Browser wird ggf. eine gerenderte Ansicht angezeigt. Der Ressourcen-Typ ist ein Bundle, das alle abgefragten Einträge enthält.

  • Bonus-Punkte: Wie viele Einträge sind im Bundle gemäß dem Element total angegeben? Wie viele Einträge sind tatsächlich im Bundle enthalten? Falls die Anzahl abweicht: Warum könnte das in der Form sinnvoll sein? Wie lassen sich die restlichen Einträge abrufen?

(c) Gefilterte Abfrage von bestimmten Organizations 🏛️ 🏛️

  • Aktion: Der FHIR-Client (Browser oder REST-Tool) fragt alle auf dem MOPED-Server gespeicherten Organization-Ressourcen ab.

  • Voraussetzung: Authentifizierung mit einem beliebigen Benutzer. Es existiert mindestens eine Organization-Ressource auf dem Server.

  • Erfolgskriterium: Die HTTP-Response liefert die Ressourcen entweder im JSON- oder XML-Format. Im Browser wird ggf. eine gerenderte Ansicht angezeigt. Der Ressourcen-Typ ist ein Bundle, das nur die Organization enthält, die dem Filter-Kriterium in der Query ensprechen.

  • Unterstützte Suchparameter für die Organization-Ressource: Organization Such-Parameter

  • Bonus-Punkte: Wie frage ich alle Krankenhaus-Abteilungen ab, die einer bestimmten Krankenanstalt zugeordnet sind?

Level 2 - VDAS: Die Roadmap der Ansprüche 🪪

  • VDAS: Es gibt zwei verschiedene Abläufe für die Versichertendatenabfrage:

    • Versichertendaten aktuell abfragen

    • Versichertendaten per Stichtag abfragen

    Beide Abläufe (und auch die verwendeten Funktionen) sind einander sehr ähnlich. Es werden tagesaktuelle bzw. stichtagsbezogene Versichertendaten eines Patienten retourniert, gemeinsam mit den Daten des Patienten, im Falles der abgeleiteten Ansprüche ebenfalls die Daten des Hauptversicherten, sowie die Organisationsdaten des Versicherungsträgers. Die Ansprüche werden in Form eines Bundles vom Type Searchset retourniert.

  • Detailbeschreibung der Abläufe: Der Akteur fragt die Versichertendaten eines Patienten vom VDAS-Service ab. Dazu werden die Abfragekriterien über die Schnittstelle an das VDAS-Service übergeben. Der Vertragspartner identifiziert den Patienten mittels e-card (Cardtoken) oder Sozialversicherungsnummer.

    Jede Abfrage ist dabei mit einem Cardtoken (e-card bzw. o-card) zu versorgen.

    Sofern der Patient im e-card System bekannt ist, werden immer die Personendaten des Patienten zurückgeliefert, anderenfalls wird eine Fehlermeldung ausgegeben.

    Das System liefert den Sozialversicherungsträger (SVT), bei dem der Patient versichert ist, falls die Abfragekriterien erfüllt sind; andernfalls wird eine Hinweismeldung ausgegeben.

    In Abhängigkeit der Berechtigungen des abfragenenden Vertragspartners werden bei Mehrfachversicherungen folgende Ansprüche retourniert:

    • Vertragspartner besitzt nur das Recht “VDAS.CORE” – Nur im Falle von mehrfach ASVG bzw. bei abgeleiteten Ansprüchen (wenn sie bei ASVG Versicherungsträgern oder beim selben Sonderversicherungsträger bestehen) werden mehrere Ansprüche zur Auswahl retourniert.

    • Vertragspartner besitzt auch das Recht “VDAS.ANSPRUCH_HISTORISCH” – Im Falle einer Mehrfachversicherung (eigene oder abgeleitete) werden unabhängig der Versicherungsträger alle Ansprüche retourniert.

  • VDAS Demo Test-Szenarien: Siehe Tabelle unten.

  • Postman Collection:

Level 3 - Von der Roadmap zur Fahrt: Start in den MOPED-Prozess 🪪 🛵

Level 4 - Die perfekte Tour: Sunshine-Case ohne Umwege 🪪 🛵

  • Partnersuche: Die vorbereiteten Patient Journeys erfordern die Beteiligung mehrerer Rollen/Akteure (KH, SV, LGF und ggf. Bund), die jeweils von unterschiedlichen Notebooks aus eigene Anfragen stellen. Alternativ können die Anfragen auch innerhalb verschiedener Postman-Collections auf einem einzigen Notebook getestet werden.

  • Fallauswahl: Aus einer Liste vordefinierter Patient Journeys (siehe separate Tabelle ganz unten) muss eine passende Journey ausgewählt werden. Jede Patient-Journey darf nur von einem Team ausgewählt werden, um sicherzustellen, dass sich die Teams bei den vorgefertigten Anfragen nicht überschneiden.

  • Benutzer-Login: Jede Rolle wird im Kontext eines bestimmten Falls durch spezifische Benutzer repräsentiert (z. B. Herz-Jesu Krankenhaus Wien, Krankenhaus Ried, ÖGK). Je nach Fall sind für die Rollen unterschiedliche vordefinierte Benutzer hinterlegt.

  • Durchführung der gesamten Patient Journeys lt. Ablauf in der Hackathon Gesamtübersicht (Moped) und der passenden Nummerierung in der jeweiligen Postman Collection. Die Requests reichen von VDAS über die Aufnahme, Kostenübernahme und Abrechnung bis zur Meldung an den Bund.

  • Postman Collection: https://github.com/HL7Austria/ELGA-MOPED-R5/tree/Hackathon-2025/postman

Level 5 - Der Offroad-Modus: Abseits der Standardroute Erfahrungen sammeln 🛵

  • Experimentelle Durchführung leichter Abweichungen vom Sunshine-Case

  • Dazu gehören Aufnahmen die sich noch in Arbeit befinden, mehrfach geänderte Erfassungen von Diagnosen und Leistungen, Korrekturaufforderungen durch den LGF sowie Ablehnungen seitens der SV. Dieses Level liegt außerhalb des Umfangs der bereitgestellten Implementierung auf dem Testserver und dient in erster Linie der Sammlung von Erfahrungen und der Erkundung möglicher Szenarien.

  • Es können auch weitere Fragestellungen je nach Hintergrund und Wünsche der Teilnehmer*innen diskutiert werden.

Grafik VDAS Gesamtübersicht & Konvertierung zu Moped 🪪

Diese grafische Gesamtübersicht zeigt die verfügbaren Ressourcen und Profile, die verschiedenen Rollen zu bestimmten Zeitpunkten zur Verfügung stehen: Hackathon Gesamtübersicht (Moped) 🛵

Beschreibung LKF: LKF Dokumentation 🛵

Mapping LKF: Mapping: LKF <-> Moped 🛵

Beschreibung KaOrg: KaOrg Dokumentation 🛵

Mapping KaOrg: Mapping: KaOrg <-> Moped 🛵

Security and Privacy considerations

Do not submit personal data (in particular, social insurance numbers and the like). Development and Test clusters require authentication, but are not encrypted and hardened like a production instance would be - use only the provided pseudo certificates.

VDAS Demo Test-Szenarien:

Versicherungsnummer

Patient

Kommentar/Fehlermeldung

Ansprüche

3333310334

user 111051 with id 137 is missing right VDAS.CORE (CL-A0005)

1701210443

Session Timeout (reason: Activity timeout) (ZS-10001)

1238180261

Der Dialog wurde mit einer GUI Session initiiert

0708071285

Die SV-Nummer 0708071285 existiert nicht oder ist nicht mehr gültig. (ZS-05011)

1898081199

Die SV-Nummer der verwendeten e-card stimmt nicht mit der angegebenen SV-Nummer überein. (ZS-00167)

1701210443

Erwin Fürnkranz

Ein Eigenanspruch

ÖGK-N (12)

2315140681

Paco de Lußia

Ein Eigenanspruch

ÖGK-W (11)

7080712852

Andreas Hartmann

Der Patient hat keinen gültigen KV-Anspruch. (ZS-05003)

3479311284

Maria von Brandenburg

Zwei abgeleitete Ansprüche. Abgeleitet von der VSNR 9537290280 Maria-Theresia Kunigunde Habsburg-Lothringen

BVAEB-Eisenbahn Bergbau (05)

BVAEB-Oeffentl. Bedienstete(07)

2315140680

Georgina Borromäus Schwarz-Zwettler

Zwei Eigenansprüche

ÖGK-W (11)
ÖGK-B (13)

3333310334

Horst Müller

Es liegt eine Mehrfachversicherung vor - KVT muss erfasst werden. (ZS-05005)

4567049209

Marianne Mayer

Der Patient ist (zum Abfragedatum) bereits als verstorben gemeldet. (ZS-05015)

xxxxxxxxx (jede weitere SV-Nummer)

Die SV-Nummer xxxxxxxxx existiert nicht oder ist nicht mehr gültig. (ZS-05011)

Patient Journeys:

Patient Journey Nr.

Aufnahmezahl

Patient

KH

SV (SVT-Code)

Leistungen und Diagnosen

1

1024000028

Paco de Lußia (2315140681)

Herz Jesus Krankenhaus (K914)

ÖGK-W (11)

0x verlegen, 1x erfassen (1 Procedure, 1 Condition)

2

324200063

Georgina Borromäus Schwarz-Zwettler (2315140680)

Krankenhaus der Barmherzigen Schwestern vom Hl. Vinzenz von Paul Ried (K427)

ÖGK-W (11)

4x verlegen; 1x erfassen (2 Procedure, 2 Condition)

3

1025000015

Paco de Lußia (2315140681)

Herz Jesus Krankenhaus (K914)

ÖGK-W (11)

0v verlegen, 1x erfassen (2 Procedure, 1 Condition)

4

1025000016

Paco de Lußia (2315140681)

Herz Jesus Krankenhaus (K914)

ÖGK-W (11)

1x verlegen, 1x erfassen (2 Procedure, 2 Condition)

5

1025000014

Maria von Brandenburg (mitversichert) (3479311284)

Herz Jesus Krankenhaus (K914)

BVAEB-Oeffentl. Bedienstete (07)

0x verlegen, 1x erfassen (1 Procedure, 2 Condition)

6

1025000020

Maria von Brandenburg (mitversichert) (3479311284)

Herz Jesus Krankenhaus (K914)

BVAEB-Oeffentl. Bedienstete (07)

0x verlegen, 1x erfassen (2 Procedure, 2 Condition)

7

325000045

Georgina Borromäus Schwarz-Zwettler (2315140680)

Krankenhaus der Barmherzigen Schwestern vom Hl. Vinzenz von Paul Ried (K427)

ÖGK-W (11)

0x verlegen, 1x erfassen (2 Procedure, 1 Condition)

8

325000046

Georgina Borromäus Schwarz-Zwettler (2315140680)

Krankenhaus der Barmherzigen Schwestern vom Hl. Vinzenz von Paul Ried (K427)

ÖGK-W (11)

1x verlegen, 1x erfassen (1 Procedure, 2 Condition)

Verfügbare Abteilungen:

Krankenanstaltennummer 

Funktionscode 

Interne Kostenstellenbezeichnung 

K914

131180

Schlaflabor (Interne)

K914

111111

Innere Medizin - allgemein

K914

112111

Chirurgie

K914

112311

Orthopädie I

K914

127181

Intensivbetreuung (Anästhesiologie und Intensivmed

K914

131136

Akutgeriatrie/ Remobilisation (Interne)

K914

161111

Innere Medizin - allgemein

K914

161136

Akutgeriatrie/ Remobilisation (Interne)

K914

162311

Orthopädie und orthopädische Chirurgie - allgemein

K914

167111

Anästhesiologie und Intensivmedizin - allgemein

K914

169111

Interdisziplinärer Bereich - allgemein

K914

169195

OP (interdisziplinär)

K914

171152

Elektrodiagnostik (Interne)

K914

177211

Radiologie - allgemein

K914

178211

Medizinische und Chemische Labordiagnostik - allge

K914

187811

Physikalische Medizin und Allgemeine Rehabilitatio

K914

201212

Kindergaerten

K914

201614

Personalwohnungen - Sonstige

K914

202211

Vorsteuer

K914

202511

FLAF-Ausgleich für Abschaffung Selbstträgerschaft

K914

311311

Kueche - allgemein

K914

311412

Medikamentendepot

K914

321212

Gebaeude

K914

321511

Materialverwaltung - allgemein

K914

321611

Waescheversorgung - allgemein

K914

331111

Anstaltsleitung - allgemein

K427

111111

Innere Medizin – allgemein

K427

112111

Chirurgie – allgemein

K427

127181

Intensivbetreuung (Anästhesiologie und Intensivmed

K427

136336

Akutgeriatrie/Remobilisation (Neurologie)

K427

177251

Röntgendiagnostik/Computertomogr.