AG ENDS 2

1 Allgemeines

Die derzeit verwendete Fassung des Normdatensatzes ist bereits mehr als 25 Jahre alt[1]. In dieser Zeit haben sich die Anforderungen deutlich gewandelt und die verfügbaren Technologien mehrfach überholt. Wir nehmen die organisatorischen und gesetzlichen Anforderungen an den Normdatensatz zum Anlass, eine Neugestaltung anzustreben und möchten einen offenen Gestaltungsprozess etablieren. Am 06.06.2018 und in weiterer Folge im Herbst 2018 werden dazu Workshops abgehalten, zu denen wir herzlich einladen wollen. Details dazu untenstehend.

1.1 Aktuelles Datenmodell

Der Stand der aktuellen Modellierung kann unter den folgenden Links abgerufen werden:

• Dataset: https://art-decor.org/art-decor/decor-datasets--exnds-?id=&effectiveDate=&conceptId=&conceptEffectiveDate=
• tabellarische Übersicht: https://art-decor.org/decor/services/RetrieveDataSet?id=2.16.840.1.113883.2.16.777.4.1.1&language=de-DE&effectiveDate=2017-06-03T00:00:00&format=html&hidecolumns=3456bcdefghijklmnop

Kommentare bitte an ends@technikum-wien.at

1.2 Projektteam

Das Projektteam für die Weiterentwicklung:

• Österreichische Ärztekammer
  • VP Dr. Dietmar Bayer
  • DI Michael Nöhammer
  • Mag. Jürgen Schwaiger
• FH Technikum
  • Prof. DI Dr. Stefan Sauermann
  • Matthias Frohner
  • Nikolaus Krondraf
• HL7 Austria
  • Dr. Stefan Sabutsch

1.3 Newsletter

Falls Sie regelmäßig weitere Informationen über diese Projekt erhalten möchten, melden Sie sich bitte bei unserem Newsletter „Export-Normdatensatz (ENDS 2.0)“ an.

Wir freuen uns auf Ihre Mitarbeit!

1.4 Meeting 1 (6. Juni 2018)

Wir stellen die bisherigen Arbeiten am Normdatensatz und die elektronischen Tools zur Weiterentwicklung vor. Die Arbeiten an der Datenmodellierung sollen aufgenommen, evtl. unterstützende Softwareprodukte identifiziert werden. Der Arbeitsplan und die weiteren Termine werden koordiniert. Die durch die Teilnehmer eingebrachten Rückmeldungen werden analysiert und entsprechend in die bestehende Modellierung des Datasets übernommen.

Dataset https://art-decor.org/art-decor/decor-datasets--exnds-?id=&effectiveDate=&conceptId=&conceptEffectiveDate=

Abstimmungsverfahren "Wechselschnittstelle Deutschland" http://wiki.hl7.de/index.php?title=Abstimmungsank%C3%BCndigung_20170414b

1.5 Meeting 2 (5. September 2018)

Eine Anmeldung ist erforderlich: Wenn Sie am Meeting teilnehmen möchten, melden Sie sich an unter ENDS Workshop 2

1.5.1 Agenda

• Rekapitulation der Ergebnisse des ersten Workshops
• Review der erhaltenen Rückmeldungen
  • Ergänzung um Datensätze klinischer Fächer: Pädiatrie, HNO, Radiologie
  • Erweiterung der bestehenden Modellierung durch noch fehlende Datensätze
• Definition des Datenmodells ENDS 2.0 (Patientendaten, administrative Daten, ...)
• Gewünschte Toos zur Generierung / Auswertung
• Weitere Vorgehensweise - Roadmap

1.6 Ergebnisse

• Eröffnung durch DI Nöhammer
• Datenmodell: Sauermann

1.6.1 Datenmodell

Link zur aktuellen Übersicht des Datenmodells

Der Fokus des Projekts liegt auf Arzt-Praxissystemen. Eine vollständige Abdeckung aller Fächer, die in der Bundeskurie niedergelassene Ärzte vertreten sind, wird angestrebt, sie wird stufenweise erreicht werden. Software von Pflege- und Krankenanstalten wird momentan noch nicht betrachtet, kann aber später mit einbezogen werden.

Wenn in der Arztpraxis mehrere IT Systeme im Einsatz sind (z.B. auch ein EKG-System) müssten entweder die Daten aus der weiteren Software vollständig im Arztpraxis-System vorliegen ODER das weitere System die Daten nach der Definition im Normdatensatz exportieren.

Sofern ein System auf die Daten eines anderen verweist, muss das verweisende System im exportierten Datensatz Informationen bereitstellen, die es ermöglichen, die Verweise korrekt zu interpretieren (zB Metadaten, Patienten_ID).

Notwendige Änderungen:

1. zum Patient muss mindestens eine ID angegeben werden (zB lokale ID, SVNR, EKVK)
2. Administratives Geschlecht ist Kode, nicht Dezimalzahl
3. Geburtsdatum ergänzen
4. Telekom-Daten --> Datentyp Telekom, mehrere möglich, Verwendungsart angeben (Arbeit, Privat...)
5. Kontaktperson --> Mehrere möglich, Granularität kann unterschiedlich sein (wie ELGA, ggf mit eigenen Kontaktdaten). Verwandtschaftsgrad soll mit angegeben werden können. Sowohl codiert als auch Freitext. Hausarzt gehört auch zu den Kontakten
6. Kontaktperson ist nicht Teil des Kontakt, in Hierarchie eins nach draußen
7. Adressen des Patienten: Mehrere möglich, Verwendungsart angeben (Arbeit, Privat...)
8. Kennzeichen --> Körperliche Merkmale
9. Größe & Gewicht, besonder Kenzeichen mit Datum --> mehrfache Werte
10. Versicherungsdaten mehrfach erlauben
11. Polizzennummer statt Mitgliedsnummer?
12. Versicherungsanstalt muss angegeben werden (als Organisation, mindestens ein String)
13. Zusatzversicherung wird nicht benötigt
14. SV-Trägercode muss in Versicherungsdaten ergänz werden (eine zweistellige Zahl)
15. Hauptversicherter muss angegeben werden können (wenn Patient mitversichert ist)
16. Rezeptgebührenbefreiung wird patientenbezogen gespeichert
17. Dauerdiagnosen (unter CAVE) ist ein einfaches Freitextfeld. Veraltet. Nur für Systeme, die ein entsprechendes "Sammelfeld" haben.
18. Welche Codes sind für Diagnose-Art vorgesehen?
19. Diagnosekürzel --> Stammdaten (zuordnung von Kürzel zu Diagnose)
20. Medikation
    1. Dauermedikation ist nur ein Kennzeichen für ein Arzneimittel, kann in einer Liste mit den verordneten Medikamenten verwaltet werdn
    2. Verordnete Arzneimittel wie in ELGA eMedikation abbilden (Selbst / Fremdverschreibung)
21. Allergie -- > Patient Summary Struktur übernehmen
22. Anamnesen wie Ärztlicher Befund
23. Hausarzt verschieben zu den Kontakten (wie ELGA)
24. Zuweiser muss bei Behandlung angegeben werden
25. Bankdaten sind ein Teil der Patientendaten, Datentyp wie ELGA
26. Behandlungsschein bleibt. Bitte Definition im DVB zusenden
27. Offen: Zuordnung der Leistung zur Rechnung.

TODO an alle: Die Felder Behandlung, Behandlungsschein, Rechnung und archivierte Rechnung bitte genau zu analysieren, ob Ihre Bedürfnisse zur Dokumentation der Abrechnungsrelevanten Daten damit ausreichend abgedeckt werden. Wenn nicht, bitte Mail an ends@technikum-wien.at

1.6.2 Technologiediskussion

Soll der Normdatensatz in FHIR implementiert werden?

• FHIR ist noch kein finaler Standard
  • im Herbst 2018 werden möglicherweise nur einige Ressourcen normativ.
  • Viele notwendigen Ressourcen werden noch auf Jahre nicht den Reifegrad erhalten.
• Ist "FHIR" schlanker als CDA?
  • Im Bereich Messaging - ja
  • Was große Dokumente betrifft, erscheint der "Overhead" bei FHIR und CDA vergleichbar.
• Lernkurve
  • Bei vielen Herstellern besteht bereits CDA Know How.
  • Aus ELGA bestehen bereits zahlreiche Informationselemente in CDA
  • FHIR Know How wird zukünftig sicher benötigt werden,
  • Es macht Sinn FHIR zu "lernen", die Frage ist wann.

Den Teilnehmern scheint FHIR keine wesentlichen Vorteile zu bringen Eine CDA-nahe Umsetzung scheint den Teilnehmern vorteilhaft, da diese Technologie bereits aus ELGA bekannt ist und sie noch die nächsten Jahre begleiten wird.

TODO an alle: Bis zum nächten Treffen bitte gegebenenfalls weitere Argumente zur Technologie an ends@technikum-wien.at

1.6.3 Tools?

Was können wir tun um die Umsetzung des ENDS zu erleichtern? Diskussion:

• Beispieldokumente sind notwendig
• Ein Tool zur Erzeugung des ENDS wäre denkbar.
  • Die meisten Hersteller haben bereits Libraries.
  • Der Aufwand das Tool zu verwenden besteht in jedem Fall, es wäre fraglich, ob das Tool wirklich Aufwand erspart.
• Hilfreich wäre ein "Browser" Tool, zur Anzeige des ENDS z.B. durch die PatientInnen.
  • Stylesheet wäre eine Möglichkeit
• Gut wäre ein Tool zur Validierung von exportierten ENDS Dateien.
  • das würde mit der Erstellung des Implementierungsleitfadens zeitnah ebenfalls zu erstellen sein.
• Kommunikationsplattform für die Hersteller
  • Blog / Chat / Forum zur Diskussion
  • Moderiert? mit aktiver Hilfestellung durch Ansprechpersonen für Entwickler
• Ansprechstelle für Anwender
  • Falls beim Export des ENDS Fehler festgestellt werden
  • Hinweis auf Zertifizierung? - Re-Zertifizierung? - Entzug des Zertifikats?

TODO an alle: Bitte weitere Anforderungen / Wünsche / Meinungen zu Tools bis zum nächsten Treffen an ends@technikum-wien.at

1.7 Meeting 3 (24. Oktober 2018)

Eine Anmeldung ist erforderlich: Wenn Sie am Meeting teilnehmen möchten, melden Sie sich an unter ENDS Workshop 3

1.7.2 Inhalte des Datenmodells ENDS 2.0 und Priorisierung

• Welche Inhalte sind unbedingt nötig?
• Was kann man später bearbeiten?

• Die Inhalte des bestehenden ENDS sind für den ENDS 2.0 unbedingt nötig
  • TODO: Sollen die Daten zur Zahnbehandlung in ENDS 2.0 abgebildet werden (wie auch bereits im bestehenden ENDS) ?
    • Zuständig wäre die Österreichische Zahnärztekammer
    • Die Daten sind recht umfangreich

• Was brauchen wir zusätzlich zum ENDS alt?

• Abrechnung
  • im bestehenden ENDS sind die Daten für die Abrechnung vollständig enthalten
    • es fehlen die Daten für die Abrechnung der Hausapotheke - in ENDS 2.0 aufnehmen
  • Abrechnungskürzel des Vertragspartners
    • beim einzelnen Abrechnungssatz
    • die verwendete Codeliste bei den Stammdaten
  • Abechnungsdatensatz laut DVB ist ungeeignet für die Beauskunftung

• Vertragspartner / Ordinationsspezifische Stammdaten z.B.
  • Lokale Codierungen
  • MitarbeiterInnen
  • welche Leistung ist wie zu verrechnen (Wahlärzte)
  • Registrierkassen Information
    • JSON Format ist genormt und vorgegeben durch die Gesetzgebung - darauf verweisen
  • im ENDS 2.0 einbauen

• Nachvollziehbarkeit
  • Nötig z.B. für Gruppenpraxen, Vertretungen, ?
  • Die bestehenden gesetzlichen Grundlagen verlangen vollständige Nachvollziehbarkeit
  • Wer hat wann was eingetragen / getan?
    • wesentlich ist, wer eingetragen hat. Auf diese Einträge muss vertraut werden.
  • Änderungshistorie
    • vollständige Nachvollziehbarkeit aller Änderungen
    • die letzte Änderung
    • für jeden geänderten Beistrich,
    • auch wenn es zunächst nicht aussenwirksam ist und/oder kommuniziert wird
  • Soll im ENDS 2.0 enthalten sein

• ABS, EKOS, KSE, VUneu, AUM Daten, DMP, BKF aus eCard Services in ENDS 2.0 aufzunehmen
  • EKOS enthält Daten zu Verordnungen, die bei der Dokumentation der Leistung verwendet werden können.
  • TODO: Die Anzahl der verordneten Leitungen bei den Therapie Verordnungsdaten ergänzen.

• Daten der "Klinischen Fächer" die durch ELGA Implementierungsleitfäden noch nicht erfasst sind, sind nicht im Detail in den ENDS 2.0 aufzunehmen

• Termine
  • unter den "Stammdaten" verspeichern.
  • die in der Praxis geplanten / stattgefundenen Termine sollen exportiert / importiert werden.
  • Personen, Räume sollen dabei mitgespeichert werden
  • ical Format wäre hilfreich?
  • Physikalische Institute haben erweiterte, detailliertere Anforderungen zu Terminen.

1.7.3 Technologieentscheidung

Aktuelle Lage FHIR: Die Publikation von FHIR 4.0 muss in den Re-Ballot und wurde daher in den Jänner 2019 verschoben.

• In der FHIR Community wird an Methoden für die gleichzeitige Verwendung von HL7 CDA und HL7 FHIR gearbeitet. Die Tools sind in Arbeit, genaue Termine sind nicht erkennbar.
• CDA als Methode zur Harmonisierung von Daten ermöglicht auch (soweit derzeit absehbar) Kommunikation mit FHIR
• Wenn man CDA und FHIR Inhalte ineinander überführt, benötigen wir vollautomatische, vollständige, zuverlässige Methoden.
• FHIR ist für kleine Messages effizienter als CDA, für Dokumente ist der Overhead beider Technologien vergleichbar.
• FHIR und CDA werden sich auch weiterhin ergänzen:
  • CDA für Dokumente
  • FHIR für mobile Anwendungen
• FHIR Schnittstellen sind bereits durch viele Hersteller in vielen Produkten umgesetzt.

1.7.4 Weitere Vorgehensweise - Roadmap

• Entwicklung des ENDS 2.0 Leitfadens bis ca Sommer 2019
  • ca drei Workshops
  • dazwischen elektronische Kommunikation
• Implementierung von Software ab Sommer 2019
  • erzeugt weiteres Feeback
• Leitfaden ENDS 2.0 soll final Ende 2019 vorliegen.
• Eine Zertifizierung von Software ist von der ÖÄK erwünscht. Auch die Softwarehersteller legen Wert auf einheitliche Prüfmittel.
• Die Bildschirmdarstellung wird z.B. mit einem Stylesheet, ohne weitere komplizierte Tools, möglich sein
• Ziel ist, dass der Export des ENDS 2.0 aus der Software bei Bedarf "auf Knopfdruck" durch die AnwenderInnen erfolgt.

1.8 Analyse des bisherigen Normdatensatzes

Siehe Export-Normdatensatz 1

1.9 Meeting 4 (25.06.2019)

Eine Anmeldung ist erforderlich: Wenn Sie am Meeting teilnehmen möchten, melden Sie sich an unter ENDS Workshop 4

Agenda:

• Begrüßung und Vorstellung des weiteren Prozesses

1.9.1 Review der bestehenden Anwendungsfälle für den Exportnormdatensatz

• • Archivierung von definierten Daten
    • (Backup wurde als nicht zutreffend gelöscht)
  • Systemwechsel zu einer anderen Arztsoftware
  • Auskunft an PatientInnen (lt. DSGVO, bei Arztwechsel, für weitere Behandler)
• Ergebnisse der Datenerhebung aus Projektphase I (Art-Decor Datasets)
• Walkthrough durch die CDA Spezifikationen, Templates in Art-Decor

1.9.2 Diskussion der Datenformate abseits von CDA welche für den Exportnormdatensatz angewandt werden können

• Anregungen, zu bestätigen/ergänzen:
  • Termine als iCal
    • bestätigt
  • Rechnungen
    • es werden nur patientenbezogene Rechnungen exportiert
    • als "Business Message Standard for Invoicing" von GS1
      • nein, weil nicht in Verwendung
    • https://www.erechnung.gv.at/erb
      • dort auch PEPPOL
    • Rechnungsformat der Sozialversicherungen
      • https://www.elda.at/cdscontent/?contentid=10007.755331&viewmode=content
    • Rechnungsformat des Versicherungsverbandes der Privatversicherungen (VVO)
      • EDIVKA-Datenaustausch: https://www.vvo.at/vvo/vvo.nsf/sysUNID/xDED4A249481F0851C1257D7F00435EBA
    • Registrierkassendaten als DEP
      • bestätigt
    • pdf
      • bestätigt
  • Buchhaltungsdaten
    • Formate der DATEV GmbH, zu klären, ob eine HL7 Norm darauf verweisen kann.

1.9.3 Stammdaten/Config (ordinationsinterne Codelisten, Formulare, etc.) der Software als JSON

• Codelisten
• Formulare
• Lagerstand

Dafür Ausgewählte Technologie: JSON

1.9.4 Container als IHE XDM zum Zusammenführen der einzelnen Artefakte

• IHE ITI-32 Transaktion "Distribute Document Set on Media"
• Diskussion
  • IHE XDM erscheint grundsätzlich geeignet.
  • Es wäre zu klären, wie in einem IHE XDM Gesamtexport einzelne Elemente wie zB Patienten- Datensätze gesucht werden können, und auch mit geringem Aufwand exportiert werden können. Es ist technisch sicherzustellen, dass das auch technisch entsprechend möglich ist.
    • Ein Patientendatenset soll technisch klar gekapselt sein, so daß die daten einfach kopiert werden können
    • Im Patientedatenset soll ein Index enthalten sein, der nur die Daten des betreffenden Patienten enthält.
    • Das Patienten Datenset soll mit der Arztsoftware ID des jeweiligen Patienten benannt sein.
    • Die Patientendaten im Index sollen entsprechend der CDA Allgemeiner Implementierungsleitfaden Stuktur maschinlesbar verspeichert werden.

1.9.5 Offene Fragen

• Sind alle Befunde Attachments? Lt. Datenerhebung gibt es Befunde separat, ist das notwendig?
  • Umgang mit importierten/aufbereiteten Daten (z.B. Verläufen von Laborwerten
  • Umgang mit DB-Tabellen (Texteinträge mit Timestamps, Schlagworten? für z.B. die Tabs von Radiologie, Labor, Medikation)
• Unterschied zwischen Rechnungen und archivierten Rechnungen?
• Frage zu Header-Elementen: unter der Annahme, dass es zwei Ausprägungen des Exportnormdatensatzes gibt (patientenzentriert vs. systemzentriert): welche Header-Elemente können im Systemansatz weggelassen werden?