431
Bearbeitungen
Änderungen
→Tabelle Daten / Use Cases
Die derzeit verwendete Fassung des Normdatensatzes ist bereits mehr als 25 Jahre alt[https://wiki.hl7.at/index.php?title=ENDS_-_Export-Normdatensatz_2008]. 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]].
==Aktuelles Datenmodell==
** 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 als JSON ===* 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
=== Container als IHE XDM zum Zusammenführen der einzelnen Artefakte ===
=== 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 Headeranderen 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-ElementenHostsystemen 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: unter //www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf IHE ITI Vol.3] müssen laut der Annahmeaktuellen 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, dass 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 zwei Ausprägungen 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 Exportnormdatensatzes 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 (patientenzentriert vsz.b. systemzentriertPDF, 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 Headerin 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 -Elemente Administrativ||CDA|In dieser Sektion können weitere patientenrelevante administrative Information angegeben werden welche nicht im Systemansatz weggelassen 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 werdenin 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.
