217
Bearbeitungen
Änderungen
→Maßnahmen zur Minimierung des Implementierungsaufwandes
*** in den jeweils vorhandenen Formaten
=== Stammdaten/Config (ordinationsinterne Codelisten, Formulare, etc.) der Software als JSON ===
* Codelisten
* Mappinglisten zwischen externen und internen Codes
* Inhalte Softwarespezifische Einstellungs-Parameter als JSON * Tabellen * Template-Dateien von ausgefüllten 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 ===
* 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 ===
** '''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 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 ===
** 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 ===
* 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.
