217
Bearbeitungen
Änderungen
→Maßnahmen zur Minimierung des Implementierungsaufwandes
* Vorstellung eines '''Beispiel CDA''' Dokuments zum neuen ENDS
** wird nach dem Treffen hier veröffentlicht[https://cloud.technikum-wien.at/s/Ke3CL4ZMGQjdMwC Download als zip Archiv]
=== Diskussion, Beschlüsse ===
** 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 patientenbezogenen Datenstrukturen die nicht im ENDS spezifiziert sind und für den herstellerübergreifenden Export und Import vorgesehen sind''' ** Beschluss: klinische Inhalten als eigene Sections im CDA** in dem Fall verpflichtend Bedeutung der Felder * als "nicht im Sinne einer kommentierten Datenstruktur: VariablennameENDS spezifiziert" markieren*** es soll möglich sein, Beschreibung, Datentyp, Position weitere herstellerspezifische Entries zu im ENDSspezifizierten Sektionen hinzu zu fügen** Frage* '''ToDo FH Technikum Wien: Wie CDA Spezifikation vorschlagen''' für Datenstrukturen die nicht im ENDS spezifiziert sind * '''Gibt es Informationen zu Dateien, die exportiert und wo genauimportiert 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 ===
* Implementierungsleitfaden bis Ende Jänner als "near final" fertig stellen
** Feedback hoch willkommen!!!
* ENDS Workshop im Jänner 2020zur 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"
|+
!Daten
!Für DSGVO / Arztwechsel exportieren ja/nein
!
!
!Format
!Hinweise/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
|-
|Behandlung
|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
|-
|Karteieintragung
|ja
|
|
|CDA
|
|-
|Diagnose
|ja
|
|
|CDA
|Soll verpflichtend ein Codesystem vorgeschrieben werden?
|-
|Laborbefund
|ja
|
|
|CDA
|
|-
|Vitalwerte
|ja
|
|
|CDA
|
|-
|Verordnung
|ja
|
|
|CDA
|
|-
|Impfung
|ja
|
|
|CDA
|
|-
|Geldflussdaten
|ja wenn patientenbezogen
|
|
|
|
|-
|Befund
|ja
|
|
|CDA
|
|-
|eCard - Konsulationsdaten
|ja
|
|
|
|
|-
|ABS - Daten
|ja
|
|
|CSV
|
|-
|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
|
|
|
|
|}
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.
