217
Bearbeitungen
Änderungen
→Maßnahmen zur Minimierung des Implementierungsaufwandes
** 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.
