AG ENDS 2: Unterschied zwischen den Versionen

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
[unmarkierte Version][unmarkierte Version]
K (→‎Datenmodell)
(→‎Tabelle Daten / Use Cases)
 
(197 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 4: Zeile 4:
 
Am 06.06.2018 und in weiterer Folge im Herbst 2018 werden dazu Workshops abgehalten, zu denen wir herzlich einladen wollen. Details dazu untenstehend.
 
Am 06.06.2018 und in weiterer Folge im Herbst 2018 werden dazu Workshops abgehalten, zu denen wir herzlich einladen wollen. Details dazu untenstehend.
  
 +
Link zur Wiki Seite des Implementierungsleitfadens für den Exportnormdatensatz [[ILF:ENDS_2]].
 +
 +
==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
  
 
==Projektteam==
 
==Projektteam==
Zeile 57: Zeile 67:
 
Software von Pflege- und Krankenanstalten wird momentan noch nicht betrachtet, kann aber später mit einbezogen 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 EKG-System die Daten nach technischer Möglichkeit (idealerweise im Normdatensatz) exportieren. Dies ist klar in der technischen Spezifikation des ENDS zu dokumentieren.
+
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.  
−
Technisch ist zu klären, wie die Patienteninformation aus den unterschiedlichen Datensätzen (ENDS-konform oder nicht) zusammengeführt werden können (zB Patienten_ID). Das System, das jeweils den Normdatensatz produziert, muss dokumentieren, wie eine Verlinkung in ein anderes System zu interpretieren ist.
+
 
 +
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:'''
 +
# zum Patient muss mindestens eine ID angegeben werden (zB lokale ID, SVNR, EKVK)
 +
# Administratives Geschlecht ist Kode, nicht Dezimalzahl
 +
# Geburtsdatum ergänzen
 +
# Telekom-Daten --> Datentyp Telekom, mehrere möglich, Verwendungsart angeben (Arbeit, Privat...)
 +
# 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
 +
# Kontaktperson ist nicht Teil des Kontakt, in Hierarchie eins nach draußen
 +
# Adressen des Patienten: Mehrere möglich, Verwendungsart angeben (Arbeit, Privat...)
 +
# Kennzeichen --> Körperliche Merkmale
 +
# Größe & Gewicht, besonder Kenzeichen mit Datum --> mehrfache Werte
 +
# Versicherungsdaten mehrfach erlauben
 +
# Polizzennummer statt Mitgliedsnummer?
 +
# Versicherungsanstalt muss angegeben werden (als Organisation, mindestens ein String)
 +
# Zusatzversicherung wird nicht benötigt
 +
# SV-Trägercode muss in Versicherungsdaten ergänz werden (eine zweistellige Zahl)
 +
# Hauptversicherter muss angegeben werden können (wenn Patient mitversichert ist)
 +
# Rezeptgebührenbefreiung wird patientenbezogen gespeichert
 +
# Dauerdiagnosen (unter CAVE) ist ein einfaches Freitextfeld. Veraltet. Nur für Systeme, die ein entsprechendes "Sammelfeld" haben.
 +
# Welche Codes sind für Diagnose-Art vorgesehen?
 +
# Diagnosekürzel --> Stammdaten (zuordnung von Kürzel zu Diagnose)
 +
# Medikation
 +
## Dauermedikation ist nur ein Kennzeichen für ein Arzneimittel, kann in einer Liste mit den verordneten Medikamenten verwaltet werdn
 +
## Verordnete Arzneimittel wie in ELGA eMedikation abbilden (Selbst / Fremdverschreibung)
 +
# Allergie -- > Patient Summary Struktur übernehmen
 +
# Anamnesen wie  [https://art-decor.org/art-decor/decor-datasets--elgabbr-?id=1.2.40.0.34.777.1.1.1&effectiveDate=2017-06-21T00%3A00%3A00&conceptId=1.2.40.0.34.777.1.2.1.45&conceptEffectiveDate=2017-06-10T15%3A27%3A27&language=de-DE Ärztlicher Befund]
 +
# Hausarzt verschieben zu den Kontakten (wie ELGA)
 +
# Zuweiser muss bei Behandlung angegeben werden
 +
# Bankdaten sind ein Teil der Patientendaten, Datentyp wie ELGA
 +
# Behandlungsschein bleibt. Bitte Definition im DVB zusenden
 +
# 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
 +
 
 +
===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
 +
 
 +
===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
  
 
== Meeting 3 (24. Oktober 2018) ==
 
== Meeting 3 (24. Oktober 2018) ==
 
'''Eine Anmeldung ist erforderlich''': Wenn Sie am Meeting teilnehmen möchten, melden Sie sich an unter [https://hl7.at/events/ends-workshop3/ ENDS Workshop 3]
 
'''Eine Anmeldung ist erforderlich''': Wenn Sie am Meeting teilnehmen möchten, melden Sie sich an unter [https://hl7.at/events/ends-workshop3/ ENDS Workshop 3]
  
 +
=== Review der erhaltenen Rückmeldungen ===
  
 +
=== 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.
 +
 +
==== Beschluss: Das in Art Decor vorliegende Datenmodell wird als Grundlage für die Umsetzung des ENDS 2.0 beschlossen.(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) ====
 +
 +
=== 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.
 +
 +
 +
==== Beschluss: Der ENDS 2.0 wird in CDA modelliert. ====
 +
 +
=== 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.
  
 
==Analyse des bisherigen Normdatensatzes==
 
==Analyse des bisherigen Normdatensatzes==
 
Siehe [[ENDS_-_Export-Normdatensatz_2008| Export-Normdatensatz 1]]
 
Siehe [[ENDS_-_Export-Normdatensatz_2008| Export-Normdatensatz 1]]
 +
 +
 +
==Meeting 4 (25.06.2019)==
 +
 +
Eine Anmeldung ist erforderlich: Wenn Sie am Meeting teilnehmen möchten, melden Sie sich an unter [https://hl7.at/events/ends-workshop4/ ENDS Workshop 4]
 +
 +
'''Agenda:'''
 +
 +
* Begrüßung und Vorstellung des weiteren Prozesses
 +
=== 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 ([https://art-decor.org/art-decor/decor-datasets--exnds-?id=&effectiveDate=&conceptId=&conceptEffectiveDate= Art-Decor Datasets])
 +
* Walkthrough durch die CDA Spezifikationen, [https://art-decor.org/art-decor/decor-templates--exnds- Templates in Art-Decor]
 +
=== 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.
 +
** Formulare, Templates
 +
*** zB Antrag für Reha, Zustimmungserklärung, Informed Consent
 +
*** sowohl ausgefüllte Formulare (Scan) als auch nicht ausgefüllte Templates (Textverarbeitungs-Formate)
 +
*** in den jeweils vorhandenen Formaten
 +
 +
=== Stammdaten/Config (ordinationsinterne Codelisten, Formulare, etc.) der Software ===
 +
* Codelisten
 +
* Mappinglisten zwischen externen und internen Codes
 +
* Softwarespezifische Einstellungs-Parameter als JSON
 +
* Tabellen
 +
* Template-Dateien von Formularen (zB Word, pdf, HTML, Excel)
 +
* Lagerstand als JSON
 +
* informative Verweise auf herstellerspezifisch ergänzte Inhalte, die nicht im ENDS spezifiziert sind, zB in der INDEX.HTM oder README.TXT
 +
 +
(überarbeitet am 15.10.2019)
 +
 +
=== Container als IHE XDM zum Zusammenführen der einzelnen Artefakte ===
 +
* [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf 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.
 +
 +
=== Offene Fragen ===
 +
* Sind alle Befunde Attachments? Lt. Datenerhebung gibt es Befunde separat, ist das notwendig?
 +
** In den Datensets tauchen Befunde an zwei Stellen auf:
 +
*** Intern erhobene, selbst erstellte Befunde laufen als "Befunde"
 +
*** Die Befunde in den "Attachments" sind Befunde, die extern erstellt wurden
 +
* Befunddaten maschinenlesbar
 +
** es wird im ENDS Projekt nicht machbar sein, sämtliche medizinischen Daten vollständig so zu spezifizieren, dass sie maschinlesbar exportiert und importiert werden können
 +
** wo im Projektverlauf möglich, werden Daten strukturiert spezifiziert,
 +
*** Allergien
 +
**** Für Medikamenten Unverträglichkeiten: Produkte und Wirkstoffe
 +
*** Implantate, Schrittmacher
 +
*** Seltene Krankheiten
 +
** Falls die exportierende Software Daten tiefer strukturiert als im ENDS spezifiziert:
 +
*** diese Daten werden in ein Freitextfeld exportiert
 +
*** zusätzlich werden Feldnamen, Feldtyp, Feldwert verspeichert
 +
*** Die strukturierten Felder sollen in Konfigurationsdaten aufgelistet und beschrieben werden.
 +
* Umgang mit importierten/aufbereiteten Daten (z.B. Verläufen von Laborwerten) und Umgang mit DB-Tabellen (Texteinträge mit Timestamps, Schlagworten? für z.B. die Tabs von Radiologie, Labor, Medikation)
 +
** werden strukturiert umgesetzt, mit Codierung laut ELGA CDA Leitfäden, oder anderen geeigneten Codierungen, wenn Codierungen fehlen werden sie ergänzt.
 +
* Unterschied zwischen Rechnungen und archivierten Rechnungen?
 +
**durch eRechnung siehe oben geklärt
 +
 +
=== Versionierung ===
 +
Versionsinformation soll sowohl bei den ENDS Spezifikationen aus auch in exportierten Datensätzen vollständig mitgegeben werden. Dabei sind externe Versionierungssysteme (zB ELGA Leitfaden, ELGA Codesets) zu berücksichtigen.
 +
 +
 +
=== Walkthrough durch den aktuellen Stand der ENDS Spezifikationen ===
 +
[https://art-decor.org/art-decor/decor-templates--exnds- Templates in Art-Decor]
 +
 +
Beschluss: Es wird ein Beispiel Export-Datensatz erstellt und im WIKI zur Verfügung gestellt. Damit werden die Unterschiede zum bestehenden Datensatz und dem neuen Format sichtbar.
 +
 +
== Meeting 5: 15.10.2019 ==
 +
15.10.2019, 10-15h, Technikum Wien Academy, Eingang Meldemannstraße 18, 1200 Wien, Raum: B0.04
 +
 +
[https://hl7.at/events/ends-workshop5/ Bitte melden Sie sich hier für den Termin an.]
 +
 +
[https://hl7.at/mailing/?p=subscribe&id=1 Anmeldung für den Newsletter "Export-Normdatensatz (ENDS 2.0)" hier.]
 +
 +
=== Aktueller Stand des Projektes, was ist getan ===
 +
* Status zur '''Verwendung von IHE XDM''', [https://wiki.hl7.at/index.php?title=ILF:ENDS_2 siehe dazu einen Vor - Entwurf des ENDS CDA Implementierungsleitfadens]
 +
** Übersicht über die Elemente
 +
*** zB README.TXT, INDEX.HTML, METADATA.XML
 +
 +
 +
* '''CDA 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
 +
 +
* Vorstellung eines '''Beispiel CDA''' Dokuments zum neuen ENDS
 +
** [https://cloud.technikum-wien.at/s/Ke3CL4ZMGQjdMwC Download als zip Archiv]
 +
 +
=== Diskussion, Beschlüsse ===
 +
* '''Zeichensatz'''
 +
** '''Beschluss: UTF-8''' soll für die Codierung der Inhalte zwingend vorgegeben werden
 +
* '''URLs'''
 +
** '''Beschluss:''' Es ist darauf zu achten, dass URLs in allen in Frage kommenden Betriebssystemen auch funktionieren. Daraus könnten Einschränkungen auf URLs resultieren (zB darf keine Leerzeichen oder Sonderzeichen enthalten)
 +
* '''Übersicht über die exportierten PatientInnen'''
 +
** Eine '''Anforderung''' ist, Exporte zu vielen PatientInnen (zB 90.000) zu erstellen. Wir brauchen daher eine performante Möglichkeit, alle exportierten PatientInnen mit Namen und der ID auf einfache Weise zu erkennen, zB als Liste.
 +
** '''Beschluss:''' INDEX.HTML auf der obersten Ebene enthält ausschließlich PatientInnen Namen und Sozialversicherungsnummer und optionale weitere PatientInnen IDs.
 +
** '''Beschluss:''' INDEX.HTML im jeweiligen Ordner der PatientInnen enthält
 +
** '''ToDo Technikum Wien: IHE hat Anforderungen zu INDEX.HTML.''' Es ist zu prüfen, ob es Widersprüche zu den INDEX.HTML Lösungen gibt, die heute beschlossen wurden.
 +
 +
* '''Export zu anderen Zwecken als der ENDS Use Cases'''
 +
** Der "alte" ENDS wird vielfach als Exportformat für andere Zwecke verwendet. Dabei wird zB auf einfache Weise anonymisiert.
 +
** Der neue ENDS wird um einiges komplizierter. Der Aufwand für die Anonymisierung und weitere Schritte zur Aufbereitung steigt daher beträchtlich.
 +
** Solange ÄrztInnen vom ASW Hersteller versorgt werden, wird der Hersteller in vielen Fällen gesonderte Exporte auch durchführen. Sobald die Betreuung durch den Hersteller wegfällt, wird das schwieriger.
 +
** '''Notiz: Der ÖÄK ist bewusst''' dass etwaige spezifische Export-Anforderungen die durch die ENDS Spezifikation nicht abgedeckt sind (zB Anonymisierung) bei ASW Herstellern oder Archiv-Hostsystemen zu beauftragen sein werden. Die ÖÄK wird die ÄrztInnen darauf hinweisen.
 +
* Nicht Patientenbezogene Stammdaten
 +
** Codelisten
 +
*** '''ToDo Technikum Wien: Geeignete Spezifikation vorschlagen für den Export von Codelisten.''' Vorhandene Spezifikationen vorzugsweise verwenden, siehe vor allem Terminologieserver.
 +
* '''Versionierung'''
 +
** Im exportierten ENDS muss die Version der Spezifikation nach der exportiert wurde erkennbar sein.
 +
** '''ToDo FH Technikum Wien: Ist zu klären.''' Erwünscht maschinenlesbar in den METADATA.XML, zusätzlich auch human lesbar in der README.TXT, für manuelle Nachverarbeitung.
 +
 +
=== Offene Fragen ===
 +
* '''Naming convention'''
 +
** Die Dateinamen im XDM Format ([https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf IHE ITI Vol.1], [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf IHE ITI Vol.2b] und [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI Vol.3] müssen laut der aktuellen IHE Spezifikation der ISO 9660 entsprechen. Diese verlangt Dateinamen nach der 8.3 Konvention (8 Buchstaben Dateiname, 3 Buchstaben Dateierweiterung). Es scheint sinnvoll, hier längere Dateinamen zuzulassen, da zB oft IDs im Dateinamen enthalten sind.
 +
** '''ToDo Technikum Wien: Längere Dateinamen''' als ISO 9660 sind erwünscht. Klären mit HL7 Austria, und evtl change proposal an IHE schicken?
 +
 +
* '''Abbildung von softwarespezifischen Datenstrukturen die nicht im ENDS spezifiziert sind''' 
 +
** Beschluss: klinische Inhalten als eigene Sections im CDA
 +
*** als "nicht im ENDS spezifiziert" markieren
 +
*** es soll möglich sein, weitere herstellerspezifische Entries zu im ENDS spezifizierten Sektionen hinzu zu fügen
 +
*** '''ToDo FH Technikum Wien: CDA Spezifikation vorschlagen''' für Datenstrukturen die nicht im ENDS spezifiziert sind
 +
 +
* '''Gibt es Informationen zu Dateien, die exportiert und importiert werden müssen?'''
 +
** zB Signaturen von Rechnungen, Beschreibungen, Kommentare, Freigabe für einen Termin
 +
** ToDo im nächsten WS: Besteht diese Anforderung?
 +
**
 +
 +
=== Vorschlag für die weitere Vorgangsweise ===
 +
Mit den Treffen heute wurden rein technisch die notwendigen Techniologien (XDM, andere Formate wie iCal, JSON)erarbeitet und auch die meisten Inhalte abgedeckt. Mit dem XML Beispiel steht auch eine vorläufige Grundlage für die Entwicklung von Software zur Verfügung.
 +
 +
* Erste Implementierungen könnten starten
 +
** Kommentare, Fragen, ... bitte an ends@technikum-wien.at
 +
* Implementierungsleitfaden bis Ende Jänner als "near final" fertig stellen
 +
** Feedback hoch willkommen!!!
 +
* ENDS Workshop zur Diskussion
 +
* HL7 Ballot Frühjahr / Sommer 2020
 +
 +
=== Nächstes Treffen ===
 +
* Workshop Ende Februar 2020
 +
** genaue Planung erfolgt im Jänner 2020
 +
 +
* Diskussion der Aufwände bei der Implementierung für einzelne Inhalte
 +
** zB: Export scheint einfacher als Import
 +
** Welche Use Cases haben Priorität?
 +
 +
== Meeting 6: 9.3.2020, ÖÄK, Wien ==
 +
 +
===Tagesordnung===
 +
*Aktueller Stand des Projektes
 +
*Fertigstellung der Spezifikation
 +
*Maßnahmen zur Minimierung des Implementierungsaufwandes
 +
 +
===Aktueller Stand des Projektes===
 +
*Diskussion des Leitfadens und des IHE-XDM Beispieles
 +
 +
===Fertigstellung der Spezifikation===
 +
*Frage: Derzeitiger Stand für XDM (laut Beschluss):
 +
**Pro PatientIn ein Unterverzeichnis
 +
**Darin ein patientenspezifisches INDEX.HTM
 +
***Frage: Welche Metadaten sollen in das INDEX.HTM und in welcher Reihenfolge/Gruppierung sollen die Links zu den Detail-Aufstellungen oder Dateien angegeben werden?
 +
*** Beschlüsse:
 +
**** Patientenverzeichnis: Name, Vorname, Geburtsdatum und Link auf die patientenspezifische Dokumentübersicht INDEX.HTM als Tabellenspalten verpflichtend
 +
**** Patienten Dokumentübersicht: Dokumentart, Datum des Dokuments, Link auf die Datei, Dateiformat als MIME Type (sofern es einen gibt), als Tabellenspalten verpflichtend
 +
***** "Datenbankexport" als erster Tabelleneintrag
 +
**** Bei fehlenden oder ungültigen Angaben wird äquivalent zum allgemeinen ELGA CDA Implementierungsleitfaden vorgegangen (Null Flavour "UNK")
 +
**** Formatierung der INDEX.HTM wird als Empfehlung im Leitfaden beschrieben
 +
**(Systemspezifische) Codelisten sind derzeit in einem allgemeinen XDM-Ordner verspeichert
 +
***Frage: verlangt die DSGVO, dass dem Patienten/der Patientin auch die relevanten Codelisten ausgehändigt werden? z.B. ordinations/systemspezifische Kürzel sind in der PatientInnen-Kartei vermerkt.
 +
*** Vorschlag: Die System / ordinationsspezifischen Codelisten können beim Datenauskunftsersuchen eines Patienten lt. GDPR und beim Arztwechsel in ein eigenes Patientenspezifisches Verzeichnis exportiert werden. Diese Codelisten können auf die Einträge beschränkt werden, die für den jewiligen PatientIn relevant sind. Alternativ sind die Volltext-Beschreibungen der Codes in den Export zu inkludieren, damit Transparenz für PatientIn gegeben ist.
 +
*** Alternativ-Vorschlag: Die System / ordinationsspezifischen Codelisten werden beim Datenauskunftsersuchen eines Patienten lt. GDPR und beim Arztwechsel nicht exportiert. Die Volltext-Beschreibungen der Codes werden zusätzlic zu den Codes in den Export inkludiert, damit Transparenz für PatientIn gegeben ist.
 +
***ToDo Technikum Wien Vorschläge weiter bearbeiten, gemeinsam Lösung finden.
 +
** Beschluss: Datenauskunftsersuchen lt. Art 15 DSGVO und Datenübertragbarkeit lt. Art 20 DSGVO werden im selben Exportvorgang abgebildet. Egal welcher Antrag gestellt wird, bekommen PatientInnen mit einem NDS beide Möglichkeiten.
 +
**Sind die Use-Cases (siehe Tabelle) DSGVO/Arztwechsel/Systemwechsel bzw. Archivierung noch valide? Welche Kardinalität bzw. Konformanz sind für die einzelnen Datentypen notwendig?
 +
**In welcher Bildschirmdarstellung (z.b. PDF, HTML)
 +
*** von CDA (mittels mitgelieferten Stylesheet oder als PDF)?
 +
*** von anderen Dateiformaten, z.B.: .ICS .JSON, als "entsprechend aufbereitetes" human lesbares PDF (z.B. als Tabelle)?
 +
 +
==== Tabelle Daten / Use Cases ====
 +
Daten NDS für einzelne Use Cases. Die in der Tabelle angeführten Daten (Spalte 1) basieren auf der Sammlung der Datasets welche in ArtDecor ersichtlich ist ([https://art-decor.org/art-decor/decor-datasets--exnds-?id=&effectiveDate=&conceptId=&conceptEffectiveDate=]). Daten welche in ArtDecor modeliert ([https://art-decor.org/art-decor/decor-templates--exnds-]) und weiters in CDA zu implementieren sind sind in der Tabelle ersichtlich. 
 +
 +
HR... Human Readable
 +
 +
MR...Machine Readable
 +
 +
Beschluss: Als HR lesbar können zunächst folgende Formate gelten: HTML, pdf, rtf, XML mit Stylesheet zur Bildschirmdarstellung insbesondere entsprechend der ELGA CDA Implementierungsleitfäden, Excel (zB .xls, xlsx, xlsm), Word (zB .doc, docx), Bilddaten (zB jpg, gif). Für alle anderen Formate müssen jeweils geeignete Wege zur Bildschirmdarstellung festgelegt werden.
 +
 +
{| class="wikitable"
 +
|+
 +
!Bezeichnung
 +
!Für DSGVO/Arztwechsel exportieren?
 +
!Datenformat
 +
!Beschreibung
 +
|-
 +
|Patient
 +
|ja
 +
|CDA
 +
|[https://art-decor.org/art-decor/decor-templates--exnds-?section=templates&id=1.2.40.0.34.6.0.11.1.3&effectiveDate=2019-02-20T12:10:02&language=de-DE recordTarget] bzw. Sektionen weitere Patienteninformation - [https://art-decor.org/art-decor/decor-templates--exnds-?section=templates&id=1.2.40.0.34.6.0.11.2.66&effectiveDate=2019-06-12T09:34:58&language=de-DE Administrativ]/[https://art-decor.org/art-decor/decor-templates--exnds-?section=templates&id=1.2.40.0.34.6.0.11.2.67&effectiveDate=2019-06-13T09:38:38&language=de-DE Medizinisch]
 +
|-
 +
|Behandlungsschein
 +
|ja
 +
|?
 +
|derzeit in CDA als L2 (Tabelle) abgebildet ([https://art-decor.org/art-decor/decor-templates--exnds-?section=templates&id=1.2.40.0.34.6.0.11.2.32&effectiveDate=2019-06-13T10:29:05&language=de-DE]). L3 Abbildung der Tabelle möglich
 +
|-
 +
|Behandlungen
 +
|ja
 +
|CDA
 +
|derzeit in CDA als L2 (Tabelle) abgebildet ([https://art-decor.org/art-decor/decor-templates--exnds-?section=templates&id=1.2.40.0.34.6.0.11.2.33&effectiveDate=2019-06-14T09:02:42&language=de-DE]). L3 Abbildung der Tabelle möglich
 +
|-
 +
|Karteieintragungen
 +
|ja
 +
|CDA
 +
|
 +
|-
 +
|Diagnose
 +
|ja
 +
|CDA
 +
|Soll verpflichtend ein Codesystem vorgeschrieben werden?
 +
|-
 +
|Laborbefund
 +
|ja
 +
|CDA
 +
|
 +
|-
 +
|Vitalparameter
 +
|ja
 +
|CDA
 +
|
 +
|-
 +
|Verordnung
 +
|ja
 +
|CDA
 +
|
 +
|-
 +
|Impfung
 +
|ja
 +
|CDA
 +
|
 +
|-
 +
|Geldflussdaten
 +
|ja wenn patientenbezogen
 +
|
 +
|
 +
|-
 +
|Befund
 +
|ja
 +
|CDA
 +
|
 +
|-
 +
|eCard - Konsulationsdaten
 +
|ja
 +
|
 +
|
 +
|-
 +
|ABS - Daten
 +
|ja
 +
|CSV
 +
|Diese Sektion dient zur Angabe und Kodierung von Informationen bezüglich des Arzneimittel-Bewilligungs-Services.
 +
|-
 +
|Attachment
 +
|ja
 +
|PDF
 +
|InlineCDA
 +
|-
 +
|Termin
 +
|ja
 +
|ICS
 +
|
 +
|-
 +
|Formulare, ausgefüllt
 +
|ja
 +
|JSON
 +
|
 +
|-
 +
|Rechnung
 +
|wenn Patienten bezogen, ja
 +
|JSON
 +
|
 +
|-
 +
|Registrierkasse
 +
|nein
 +
|JSON
 +
|
 +
|-
 +
|archivierte Rechnung
 +
|sofern patientenbezogen: ja
 +
|
 +
|
 +
|-
 +
|Stammdaten
 +
|generell nein, systemspezifische Codelisten: optional ja
 +
|
 +
|
 +
|-
 +
|Krankenstand
 +
|ja
 +
|CDA
 +
|
 +
|-
 +
|Lager
 +
|nein
 +
|JSON
 +
|
 +
|-
 +
|Klinische Fächer
 +
|nein
 +
|
 +
|
 +
|-
 +
|Allergien und Intoleranzen
 +
|
 +
|CDA
 +
|Diese Sektion enthält relevante Allergien oder Intoleranzen des Patienten.
 +
|-
 +
|Beilagen
 +
|
 +
|CDA / eingebettetes Dokument
 +
|Sonstige Beilagen, außer denjenigen Dokumenten, die in „Patientenverfügungen und andere juridische Dokumente“ angegeben sind. Achtung: Ein „Referenzieren“ auf Beilagen ist NICHT ERLAUBT. Beigelegte Dokumente/Bilder MÜSSEN dem Dokument in technisch eingebetteter Form beiliegen.
 +
|-
 +
|Bisherige Maßnahmen
 +
|
 +
|CDA
 +
|Enthält relevante Maßnahmen, die schon vor dem Aufenthalt durchgeführt wurden.
 +
|-
 +
|Dauerdiagnose
 +
|
 +
|CDA
 +
|Diese Sektion inkludiert die Information über die Dauerdiagnosen.
 +
|-
 +
|Cave
 +
|
 +
|CDA
 +
|Diese Sektion dient zur Angabe von besonderen Hinweisen bzw. Cave Information.
 +
|-
 +
|Familienanamnese
 +
|
 +
|CDA
 +
|Diese Sektion enthält in Form eines narrativen Textes Informationen über die Familienanamnese.
 +
|-
 +
|Frühere Erkrankungen
 +
|
 +
|CDA
 +
|Liste der bisherigen Krankheiten des Patienten. Die Sektion kann Untersektionen enthalten.
 +
|-
 +
|Impfreaktion
 +
|
 +
|CDA
 +
|Optional können auffällige (schwere) Impfreaktionen dokumentiert werden. Nur bestimmte Einträge sollen eingetragen werden, z.B. Fieber, Muskelschmerzen.
 +
|-
 +
|Laborparameter
 +
|
 +
|CDA
 +
|TODO: Müssen die Laborparameter nach den einzelnen Laborbereichen / Gruppen gegliedert werden, oder reicht eine Tabelle mit sämtlichen Laborparametern?
 +
|-
 +
|Rezept
 +
|
 +
|CDA
 +
|
 +
|-
 +
|Weitere Merkmale
 +
|
 +
|CDA
 +
|Diese Sektion wird als Sub-Sektion der Sektion "Weitere Patienteninformation - Medizinisch" geführt und beinhaltet weitere Merkmale wie z.B.: die Blutgruppe des Patienten/der Patientin. Die Liste der Merkmale ist nicht als vollständig definiert. Es können weitere Merkmale in Form eines Key/Value-Pairs angegeben werden.
 +
|-
 +
|Weitere Patienteninformation - Administrativ
 +
|
 +
|CDA
 +
|In dieser Sektion können weitere patientenrelevante administrative Information angegeben werden welche nicht im CDA Header abgebildet werden können. Z.B. Informationen über eine etwaige Rezeptgebührenbefreiung oder die Versichertenkategorie.
 +
|-
 +
|Weitere Patienteninformation - Medizinisch
 +
|
 +
|CDA
 +
|Diese Sektion enthält weitere medizinische Information zum Patienten/zur Patientin. Diese Informationen werden in die Sub-Sektionen "Vitalparameter" und "Weitere Merkmale" unterteilt.
 +
|-
 +
|Wichtige Hinweise
 +
|
 +
|CDA
 +
|Freitext für wichtige Hinweise oder Alarmhinwese für andere Behandler des Patienten.
 +
|}
 +
 +
ToDo Technikum: Tabelle um weitere Formte ergänzen.
 +
 +
===Maßnahmen zur Minimierung des Implementierungsaufwandes===
 +
*Diskussion bezüglich der Priorisierung der Use Cases / Zeitplan für die Umsetzung? Begleitmaßnahmen
 +
** Export ist dringend erwünscht
 +
*** für alle Anwendungsfälle, (Auskunftsersuchen, Archivierung, Systemwechsel)
 +
** Import ist aufwendiger
 +
** Begleitmassnahmen: Technische Tools für Export / Import werden wenig Erleichterung für Hersteller bringen, da dann die jeweilige Software wieder an das Tool angepasst werden muss.
 +
 +
ToDo: Hersteller schätzen bis zum nächsten Treffen die Aufwände (z.B. Personentage) für die Umsetzung von Import und Export des NDS für Auskunftsersuchen, Archivierung, Systemwechsel ab. Weiters wird abgefragt, ob prinzipiell interesse besteht, die Funktionen in der eigenen SW umzusetzen.
 +
 +
ToDo: ÖÄK fragt bei Mitgliedern ab, ob Bereitschaft besteht, die Funktionen NDS Export / Import (Auskunftsersuchen, Archivierung, Systemwechsel) als Module zu beschaffen.
 +
 +
ToDo Technikum stellt den Leitfaden sowie das Beispiel fertig, ca. bis Mai 2020. Dann erfolgt eine Einladung zur Kommentierung an diese Arbeitsgruppe über den HL7 NDS Verteiler. Kommentierungsfrist wird ca 6 Wochen sein. Die einlangenden Kommentare werden eingearbeitet. Der Leitfanden ergeht dann an HL7 Austria zum Ballot.

Aktuelle Version vom 1. Oktober 2020, 11:14 Uhr

Projekt-Logo ENDS 2.0

Inhaltsverzeichnis

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.

Link zur Wiki Seite des Implementierungsleitfadens für den Exportnormdatensatz ILF:ENDS_2.

1.1 Aktuelles Datenmodell

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


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.1 Review der erhaltenen Rückmeldungen

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.2.1 Beschluss: Das in Art Decor vorliegende Datenmodell wird als Grundlage für die Umsetzung des ENDS 2.0 beschlossen.(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)

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.3.1 Beschluss: Der ENDS 2.0 wird in CDA modelliert.

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
    • Buchhaltungsdaten
      • Formate der DATEV GmbH, zu klären, ob eine HL7 Norm darauf verweisen kann.
    • Formulare, Templates
      • zB Antrag für Reha, Zustimmungserklärung, Informed Consent
      • sowohl ausgefüllte Formulare (Scan) als auch nicht ausgefüllte Templates (Textverarbeitungs-Formate)
      • in den jeweils vorhandenen Formaten

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

  • Codelisten
  • Mappinglisten zwischen externen und internen Codes
  • Softwarespezifische Einstellungs-Parameter als JSON
  • Tabellen
  • Template-Dateien von Formularen (zB Word, pdf, HTML, Excel)
  • Lagerstand als JSON
  • informative Verweise auf herstellerspezifisch ergänzte Inhalte, die nicht im ENDS spezifiziert sind, zB in der INDEX.HTM oder README.TXT

(überarbeitet am 15.10.2019)

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?
    • In den Datensets tauchen Befunde an zwei Stellen auf:
      • Intern erhobene, selbst erstellte Befunde laufen als "Befunde"
      • Die Befunde in den "Attachments" sind Befunde, die extern erstellt wurden
  • Befunddaten maschinenlesbar
    • es wird im ENDS Projekt nicht machbar sein, sämtliche medizinischen Daten vollständig so zu spezifizieren, dass sie maschinlesbar exportiert und importiert werden können
    • wo im Projektverlauf möglich, werden Daten strukturiert spezifiziert,
      • Allergien
        • Für Medikamenten Unverträglichkeiten: Produkte und Wirkstoffe
      • Implantate, Schrittmacher
      • Seltene Krankheiten
    • Falls die exportierende Software Daten tiefer strukturiert als im ENDS spezifiziert:
      • diese Daten werden in ein Freitextfeld exportiert
      • zusätzlich werden Feldnamen, Feldtyp, Feldwert verspeichert
      • Die strukturierten Felder sollen in Konfigurationsdaten aufgelistet und beschrieben werden.
  • Umgang mit importierten/aufbereiteten Daten (z.B. Verläufen von Laborwerten) und Umgang mit DB-Tabellen (Texteinträge mit Timestamps, Schlagworten? für z.B. die Tabs von Radiologie, Labor, Medikation)
    • werden strukturiert umgesetzt, mit Codierung laut ELGA CDA Leitfäden, oder anderen geeigneten Codierungen, wenn Codierungen fehlen werden sie ergänzt.
  • Unterschied zwischen Rechnungen und archivierten Rechnungen?
    • durch eRechnung siehe oben geklärt

1.9.6 Versionierung

Versionsinformation soll sowohl bei den ENDS Spezifikationen aus auch in exportierten Datensätzen vollständig mitgegeben werden. Dabei sind externe Versionierungssysteme (zB ELGA Leitfaden, ELGA Codesets) zu berücksichtigen.


1.9.7 Walkthrough durch den aktuellen Stand der ENDS Spezifikationen

Templates in Art-Decor

Beschluss: Es wird ein Beispiel Export-Datensatz erstellt und im WIKI zur Verfügung gestellt. Damit werden die Unterschiede zum bestehenden Datensatz und dem neuen Format sichtbar.

1.10 Meeting 5: 15.10.2019

15.10.2019, 10-15h, Technikum Wien Academy, Eingang Meldemannstraße 18, 1200 Wien, Raum: B0.04

Bitte melden Sie sich hier für den Termin an.

Anmeldung für den Newsletter "Export-Normdatensatz (ENDS 2.0)" hier.

1.10.1 Aktueller Stand des Projektes, was ist getan


1.10.2 Diskussion, Beschlüsse

  • Zeichensatz
    • Beschluss: UTF-8 soll für die Codierung der Inhalte zwingend vorgegeben werden
  • URLs
    • Beschluss: Es ist darauf zu achten, dass URLs in allen in Frage kommenden Betriebssystemen auch funktionieren. Daraus könnten Einschränkungen auf URLs resultieren (zB darf keine Leerzeichen oder Sonderzeichen enthalten)
  • Übersicht über die exportierten PatientInnen
    • Eine Anforderung ist, Exporte zu vielen PatientInnen (zB 90.000) zu erstellen. Wir brauchen daher eine performante Möglichkeit, alle exportierten PatientInnen mit Namen und der ID auf einfache Weise zu erkennen, zB als Liste.
    • Beschluss: INDEX.HTML auf der obersten Ebene enthält ausschließlich PatientInnen Namen und Sozialversicherungsnummer und optionale weitere PatientInnen IDs.
    • Beschluss: INDEX.HTML im jeweiligen Ordner der PatientInnen enthält
    • ToDo Technikum Wien: IHE hat Anforderungen zu INDEX.HTML. Es ist zu prüfen, ob es Widersprüche zu den INDEX.HTML Lösungen gibt, die heute beschlossen wurden.
  • Export zu anderen Zwecken als der ENDS Use Cases
    • Der "alte" ENDS wird vielfach als Exportformat für andere Zwecke verwendet. Dabei wird zB auf einfache Weise anonymisiert.
    • Der neue ENDS wird um einiges komplizierter. Der Aufwand für die Anonymisierung und weitere Schritte zur Aufbereitung steigt daher beträchtlich.
    • Solange ÄrztInnen vom ASW Hersteller versorgt werden, wird der Hersteller in vielen Fällen gesonderte Exporte auch durchführen. Sobald die Betreuung durch den Hersteller wegfällt, wird das schwieriger.
    • Notiz: Der ÖÄK ist bewusst dass etwaige spezifische Export-Anforderungen die durch die ENDS Spezifikation nicht abgedeckt sind (zB Anonymisierung) bei ASW Herstellern oder Archiv-Hostsystemen zu beauftragen sein werden. Die ÖÄK wird die ÄrztInnen darauf hinweisen.
  • Nicht Patientenbezogene Stammdaten
    • Codelisten
      • ToDo Technikum Wien: Geeignete Spezifikation vorschlagen für den Export von Codelisten. Vorhandene Spezifikationen vorzugsweise verwenden, siehe vor allem Terminologieserver.
  • Versionierung
    • Im exportierten ENDS muss die Version der Spezifikation nach der exportiert wurde erkennbar sein.
    • ToDo FH Technikum Wien: Ist zu klären. Erwünscht maschinenlesbar in den METADATA.XML, zusätzlich auch human lesbar in der README.TXT, für manuelle Nachverarbeitung.

1.10.3 Offene Fragen

  • Naming convention
    • Die Dateinamen im XDM Format (IHE ITI Vol.1, IHE ITI Vol.2b und IHE ITI Vol.3 müssen laut der aktuellen IHE Spezifikation der ISO 9660 entsprechen. Diese verlangt Dateinamen nach der 8.3 Konvention (8 Buchstaben Dateiname, 3 Buchstaben Dateierweiterung). Es scheint sinnvoll, hier längere Dateinamen zuzulassen, da zB oft IDs im Dateinamen enthalten sind.
    • ToDo Technikum Wien: Längere Dateinamen als ISO 9660 sind erwünscht. Klären mit HL7 Austria, und evtl change proposal an IHE schicken?
  • Abbildung von softwarespezifischen Datenstrukturen die nicht im ENDS spezifiziert sind
    • Beschluss: klinische Inhalten als eigene Sections im CDA
      • als "nicht im ENDS spezifiziert" markieren
      • es soll möglich sein, weitere herstellerspezifische Entries zu im ENDS spezifizierten Sektionen hinzu zu fügen
      • ToDo FH Technikum Wien: CDA Spezifikation vorschlagen für Datenstrukturen die nicht im ENDS spezifiziert sind
  • Gibt es Informationen zu Dateien, die exportiert und importiert werden müssen?
    • zB Signaturen von Rechnungen, Beschreibungen, Kommentare, Freigabe für einen Termin
    • ToDo im nächsten WS: Besteht diese Anforderung?

1.10.4 Vorschlag für die weitere Vorgangsweise

Mit den Treffen heute wurden rein technisch die notwendigen Techniologien (XDM, andere Formate wie iCal, JSON)erarbeitet und auch die meisten Inhalte abgedeckt. Mit dem XML Beispiel steht auch eine vorläufige Grundlage für die Entwicklung von Software zur Verfügung.

  • Erste Implementierungen könnten starten
    • Kommentare, Fragen, ... bitte an ends@technikum-wien.at
  • Implementierungsleitfaden bis Ende Jänner als "near final" fertig stellen
    • Feedback hoch willkommen!!!
  • ENDS Workshop zur Diskussion
  • HL7 Ballot Frühjahr / Sommer 2020

1.10.5 Nächstes Treffen

  • Workshop Ende Februar 2020
    • genaue Planung erfolgt im Jänner 2020
  • Diskussion der Aufwände bei der Implementierung für einzelne Inhalte
    • zB: Export scheint einfacher als Import
    • Welche Use Cases haben Priorität?

1.11 Meeting 6: 9.3.2020, ÖÄK, Wien

1.11.1 Tagesordnung

  • Aktueller Stand des Projektes
  • Fertigstellung der Spezifikation
  • Maßnahmen zur Minimierung des Implementierungsaufwandes

1.11.2 Aktueller Stand des Projektes

  • Diskussion des Leitfadens und des IHE-XDM Beispieles

1.11.3 Fertigstellung der Spezifikation

  • Frage: Derzeitiger Stand für XDM (laut Beschluss):
    • Pro PatientIn ein Unterverzeichnis
    • Darin ein patientenspezifisches INDEX.HTM
      • Frage: Welche Metadaten sollen in das INDEX.HTM und in welcher Reihenfolge/Gruppierung sollen die Links zu den Detail-Aufstellungen oder Dateien angegeben werden?
      • Beschlüsse:
        • Patientenverzeichnis: Name, Vorname, Geburtsdatum und Link auf die patientenspezifische Dokumentübersicht INDEX.HTM als Tabellenspalten verpflichtend
        • Patienten Dokumentübersicht: Dokumentart, Datum des Dokuments, Link auf die Datei, Dateiformat als MIME Type (sofern es einen gibt), als Tabellenspalten verpflichtend
          • "Datenbankexport" als erster Tabelleneintrag
        • Bei fehlenden oder ungültigen Angaben wird äquivalent zum allgemeinen ELGA CDA Implementierungsleitfaden vorgegangen (Null Flavour "UNK")
        • Formatierung der INDEX.HTM wird als Empfehlung im Leitfaden beschrieben
    • (Systemspezifische) Codelisten sind derzeit in einem allgemeinen XDM-Ordner verspeichert
      • Frage: verlangt die DSGVO, dass dem Patienten/der Patientin auch die relevanten Codelisten ausgehändigt werden? z.B. ordinations/systemspezifische Kürzel sind in der PatientInnen-Kartei vermerkt.
      • Vorschlag: Die System / ordinationsspezifischen Codelisten können beim Datenauskunftsersuchen eines Patienten lt. GDPR und beim Arztwechsel in ein eigenes Patientenspezifisches Verzeichnis exportiert werden. Diese Codelisten können auf die Einträge beschränkt werden, die für den jewiligen PatientIn relevant sind. Alternativ sind die Volltext-Beschreibungen der Codes in den Export zu inkludieren, damit Transparenz für PatientIn gegeben ist.
      • Alternativ-Vorschlag: Die System / ordinationsspezifischen Codelisten werden beim Datenauskunftsersuchen eines Patienten lt. GDPR und beim Arztwechsel nicht exportiert. Die Volltext-Beschreibungen der Codes werden zusätzlic zu den Codes in den Export inkludiert, damit Transparenz für PatientIn gegeben ist.
      • ToDo Technikum Wien Vorschläge weiter bearbeiten, gemeinsam Lösung finden.
    • Beschluss: Datenauskunftsersuchen lt. Art 15 DSGVO und Datenübertragbarkeit lt. Art 20 DSGVO werden im selben Exportvorgang abgebildet. Egal welcher Antrag gestellt wird, bekommen PatientInnen mit einem NDS beide Möglichkeiten.
    • Sind die Use-Cases (siehe Tabelle) DSGVO/Arztwechsel/Systemwechsel bzw. Archivierung noch valide? Welche Kardinalität bzw. Konformanz sind für die einzelnen Datentypen notwendig?
    • In welcher Bildschirmdarstellung (z.b. PDF, HTML)
      • von CDA (mittels mitgelieferten Stylesheet oder als PDF)?
      • von anderen Dateiformaten, z.B.: .ICS .JSON, als "entsprechend aufbereitetes" human lesbares PDF (z.B. als Tabelle)?

1.11.3.1 Tabelle Daten / Use Cases

Daten NDS für einzelne Use Cases. Die in der Tabelle angeführten Daten (Spalte 1) basieren auf der Sammlung der Datasets welche in ArtDecor ersichtlich ist ([2]). Daten welche in ArtDecor modeliert ([3]) und weiters in CDA zu implementieren sind sind in der Tabelle ersichtlich.

HR... Human Readable

MR...Machine Readable

Beschluss: Als HR lesbar können zunächst folgende Formate gelten: HTML, pdf, rtf, XML mit Stylesheet zur Bildschirmdarstellung insbesondere entsprechend der ELGA CDA Implementierungsleitfäden, Excel (zB .xls, xlsx, xlsm), Word (zB .doc, docx), Bilddaten (zB jpg, gif). Für alle anderen Formate müssen jeweils geeignete Wege zur Bildschirmdarstellung festgelegt werden.

Bezeichnung Für DSGVO/Arztwechsel exportieren? Datenformat Beschreibung
Patient ja CDA recordTarget bzw. Sektionen weitere Patienteninformation - Administrativ/Medizinisch
Behandlungsschein ja ? derzeit in CDA als L2 (Tabelle) abgebildet ([4]). L3 Abbildung der Tabelle möglich
Behandlungen ja CDA derzeit in CDA als L2 (Tabelle) abgebildet ([5]). L3 Abbildung der Tabelle möglich
Karteieintragungen ja CDA
Diagnose ja CDA Soll verpflichtend ein Codesystem vorgeschrieben werden?
Laborbefund ja CDA
Vitalparameter ja CDA
Verordnung ja CDA
Impfung ja CDA
Geldflussdaten ja wenn patientenbezogen
Befund ja CDA
eCard - Konsulationsdaten ja
ABS - Daten ja CSV Diese Sektion dient zur Angabe und Kodierung von Informationen bezüglich des Arzneimittel-Bewilligungs-Services.
Attachment ja PDF InlineCDA
Termin ja ICS
Formulare, ausgefüllt ja JSON
Rechnung wenn Patienten bezogen, ja JSON
Registrierkasse nein JSON
archivierte Rechnung sofern patientenbezogen: ja
Stammdaten generell nein, systemspezifische Codelisten: optional ja
Krankenstand ja CDA
Lager nein JSON
Klinische Fächer nein
Allergien und Intoleranzen CDA Diese Sektion enthält relevante Allergien oder Intoleranzen des Patienten.
Beilagen CDA / eingebettetes Dokument Sonstige Beilagen, außer denjenigen Dokumenten, die in „Patientenverfügungen und andere juridische Dokumente“ angegeben sind. Achtung: Ein „Referenzieren“ auf Beilagen ist NICHT ERLAUBT. Beigelegte Dokumente/Bilder MÜSSEN dem Dokument in technisch eingebetteter Form beiliegen.
Bisherige Maßnahmen CDA Enthält relevante Maßnahmen, die schon vor dem Aufenthalt durchgeführt wurden.
Dauerdiagnose CDA Diese Sektion inkludiert die Information über die Dauerdiagnosen.
Cave CDA Diese Sektion dient zur Angabe von besonderen Hinweisen bzw. Cave Information.
Familienanamnese CDA Diese Sektion enthält in Form eines narrativen Textes Informationen über die Familienanamnese.
Frühere Erkrankungen CDA Liste der bisherigen Krankheiten des Patienten. Die Sektion kann Untersektionen enthalten.
Impfreaktion CDA Optional können auffällige (schwere) Impfreaktionen dokumentiert werden. Nur bestimmte Einträge sollen eingetragen werden, z.B. Fieber, Muskelschmerzen.
Laborparameter CDA TODO: Müssen die Laborparameter nach den einzelnen Laborbereichen / Gruppen gegliedert werden, oder reicht eine Tabelle mit sämtlichen Laborparametern?
Rezept CDA
Weitere Merkmale CDA Diese Sektion wird als Sub-Sektion der Sektion "Weitere Patienteninformation - Medizinisch" geführt und beinhaltet weitere Merkmale wie z.B.: die Blutgruppe des Patienten/der Patientin. Die Liste der Merkmale ist nicht als vollständig definiert. Es können weitere Merkmale in Form eines Key/Value-Pairs angegeben werden.
Weitere Patienteninformation - Administrativ CDA In dieser Sektion können weitere patientenrelevante administrative Information angegeben werden welche nicht im CDA Header abgebildet werden können. Z.B. Informationen über eine etwaige Rezeptgebührenbefreiung oder die Versichertenkategorie.
Weitere Patienteninformation - Medizinisch CDA Diese Sektion enthält weitere medizinische Information zum Patienten/zur Patientin. Diese Informationen werden in die Sub-Sektionen "Vitalparameter" und "Weitere Merkmale" unterteilt.
Wichtige Hinweise CDA Freitext für wichtige Hinweise oder Alarmhinwese für andere Behandler des Patienten.

ToDo Technikum: Tabelle um weitere Formte ergänzen.

1.11.4 Maßnahmen zur Minimierung des Implementierungsaufwandes

  • Diskussion bezüglich der Priorisierung der Use Cases / Zeitplan für die Umsetzung? Begleitmaßnahmen
    • Export ist dringend erwünscht
      • für alle Anwendungsfälle, (Auskunftsersuchen, Archivierung, Systemwechsel)
    • Import ist aufwendiger
    • Begleitmassnahmen: Technische Tools für Export / Import werden wenig Erleichterung für Hersteller bringen, da dann die jeweilige Software wieder an das Tool angepasst werden muss.

ToDo: Hersteller schätzen bis zum nächsten Treffen die Aufwände (z.B. Personentage) für die Umsetzung von Import und Export des NDS für Auskunftsersuchen, Archivierung, Systemwechsel ab. Weiters wird abgefragt, ob prinzipiell interesse besteht, die Funktionen in der eigenen SW umzusetzen.

ToDo: ÖÄK fragt bei Mitgliedern ab, ob Bereitschaft besteht, die Funktionen NDS Export / Import (Auskunftsersuchen, Archivierung, Systemwechsel) als Module zu beschaffen.

ToDo Technikum stellt den Leitfaden sowie das Beispiel fertig, ca. bis Mai 2020. Dann erfolgt eine Einladung zur Kommentierung an diese Arbeitsgruppe über den HL7 NDS Verteiler. Kommentierungsfrist wird ca 6 Wochen sein. Die einlangenden Kommentare werden eingearbeitet. Der Leitfanden ergeht dann an HL7 Austria zum Ballot.

Abgerufen von „http://wiki.hl7.at/index.php?title=AG_ENDS_2&oldid=127581“