Wechselschnittstelle

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
Zeile 64: Zeile 64:
  
 
== Hintergrund==
 
== Hintergrund==
Deutschland hat mit der Änderung des Paragraphen §291 im SGB V eine gesetzliche Forderung nach offenen und standardisierten Schnittstellen verankert. Laut diesem eHealth-Gesetz sind die KBV für den ambulanten und die DKG für den stationären Sektor für die Festlegung einer System- bzw. Arztwechselschnittstelle verantwortlich. Mit der letzten Änderung an diesem Gesetz Ende Mai 2017 sind außerdem Fristen ("2 Jahre nach der Festlegung") festgeschrieben worden.
+
Deutschland hat mit der Änderung des Paragraphen §291 - speziell §291d - im SGB V eine gesetzliche Forderung nach offenen und standardisierten Schnittstellen verankert. Laut diesem eHealth-Gesetz sind die KBV für den ambulanten und die DKG für den stationären Sektor für die Festlegung einer System- bzw. Arztwechselschnittstelle verantwortlich. Mit der letzten Änderung an diesem Gesetz Ende Mai 2017 sind außerdem Fristen ("2 Jahre nach der Festlegung") festgeschrieben worden. Im Absatz 5 wird außerdem gefordert, dass bei "inhaltlichen Gemeinsamkeiten der Schnittstellen sektorübergreifende einheitliche Vorgaben zu treffen" sind.
  
Der bvitg hat der KBV hier xBDT vorgeschlagen. (Von der QMS kam noch BDT3.0 als Gegenvorschlag.) Bei der DKG verzichtet man vorläufig auf eine Festlegung.
+
Der bvitg hat der KBV hier xBDT vorgeschlagen. (Von der QMS kam noch BDT3.0 als Gegenvorschlag.) Bei der DKG verzichtet man vorläufig auf eine Festlegung. (Im Gesetz ist hier von "KANN" die Rede, was als "nicht müssen" interpretiert wird.) Ob deshalb auf eine Festlegung verzichtet werden kann wird derzeit unterschiedlich interpretiert.
  
Laut eHealth-Gesetz und EU-DSVG hat der Patient in naher Zukunft ein Recht, seine Daten mitzunehmen.
+
Laut der europäischen Datenschutzgrundverordnung (EU-DSVG), die am 18.Mai 2018 in Kraft tritt,  hat der Patient ein Recht, seine Daten in "strukturierter" Form mitzunehmen. Mit letzterem ist gemeint, dass eine papierbasierte Zurverfügungstellung nicht ausreicht.
  
Sobald (diese) Vorgaben in VESTA verankert sind, kann der Gesetzgeber dafür Fristen vorsehen.
+
Für die Systemwechselschnittstelle ist eine Frist von zwei Jahren vorgesehen, sobald die Vorgaben in vesta hinterlegt sind. Für weitere Schnittstellen, das können dann die hier beschriebenen Szenarien sein, kann der Gesetzgeber ebenfalls Fristen vorgeben.
  
 
==Zweck==
 
==Zweck==
  
Dieser Leitfaden soll unter Verwendung bereits vorhandener und genutzter Spezifikationen einen Strukturvorgabe für einen Datenaustausch bereitstellen, der die u.g. Szenarien abdeckt.
+
Dieser Leitfaden soll unter Verwendung bereits vorhandener und genutzter Spezifikationen eine vorgabe für einen strukturierten Datenaustausch bereitstellen, der die u.g. Szenarien abdeckt.
  
 
==Lösungsansatz==
 
==Lösungsansatz==
  
Als Lösungsanatz wird hier XDM gewählt, da damit insbesondere ein Offline-Datenaustausch (ein System ist nicht verfügbar bzw. die Systeme sind nicht online miteinander verbunden) unterstützt wird. XDM selbst macht keine inhaltlichen Vorgaben, was genau auszutauschen ist. XDM stellt eine Strukturvorgabe auf einem Medium bereit und kombiniert dies mit Metadaten, um die bereitgestellten Dateien wieder einlesen/verarbeiten zu können.
+
Als Lösungsanatz wird hier XDM gewählt, da damit insbesondere ein Offline-Datenaustausch unterstützt wird, weil ein System ggf. nicht verfügbar bzw. die Systeme sind nicht online miteinander verbunden sind. XDM selbst macht keine direkten inhaltlichen Vorgaben, was genau auszutauschen ist. XDM stellt eine Strukturvorgabe auf einem Medium bereit und kombiniert dies mit Metadaten, um die bereitgestellten Dateien wieder einlesen/verarbeiten zu können.
  
Andere Lösungsansätze wie bspw. "Blue Button" oder "FHIR Bulk Data" gehen nur von einer inhaltlich limitierten Abfrage von Informationen ohne Wiedereinlesen bzw. einem Online-Verfahren aus.
+
{{BestPracticeBox|
 +
Andere Lösungsansätze gehen nur von einer inhaltlich limitierten Abfrage von Informationen ohne Wiedereinlesen wie bspw. "Blue Button" oder einem Online-Verfahren wie "HL7 FHIR Bulk Data" aus. Letzteres liefert alle Daten in einem strukturierten Format, das ein Wiedereinlesen prinzipiell ermöglicht. FHIR Bulk Data wäre das derzeit bevorzugte Verfahren, stellt aber höhere Anforderungen an die Systeme als das nachfolgend beschriebene Verfahren, welches einen späteren Umstieg vorbereiten soll.
 +
}}
  
 
==Vorteile==
 
==Vorteile==
Zeile 87: Zeile 89:
  
 
*einsetzbar für verschiedene Szenarien (s.u.)
 
*einsetzbar für verschiedene Szenarien (s.u.)
*Basiert auf bereits genutzten Standards (wie bspw. IHE ITI XDM, HL7 V3 CDA, DICOM, PDF, FHIR)
+
*basiert auf bereits genutzten Standards (wie bspw. IHE ITI XDM, HL7 V3 CDA, DICOM, PDF, FHIR)
*Verwendet bereits vorhandene deutsche Profile (Arztbrief PLUS, FHIR-Basisprofilierung, ..) bzw. das, was vorhanden ist
+
*cerwendet bereits vorhandene deutsche Profile (Arztbrief PLUS, FHIR-Basisprofilierung, ..) bzw. das, was vorhanden ist
*FHIR gestattet einfache Basisdaten:
+
*FHIR gestattet eine einfache Übermittlung von Basisdaten:
**Patient, Fälle, Aufenthalte, Diagnosen, Prozeduren, Maßnahmen, ..
+
**Patient, Fälle + Aufenthalte (Encounter), Diagnosen, Prozeduren, Maßnahmen, Medikation, ..
**Ggf. zuzügl. Stammdaten (Value Sets)
+
**Stammdaten: Ärzte (Practitioner, Organization)
*Eine Umsetzung ist inkrementell erweiterbar
+
**Kataloge (Value Sets)
**weitere Ressourcen/Dateien
+
*die Umsetzung ist inkrementell erweiterbar
**weitere Details in den Ressourcen/Dateien
+
**weitere Ressourcen/Dateien (-> [http://wiki.hl7.org/index.php?title=201801_Bulk_Data FHIR Bulk Data])
 +
**weitere Details in den Ressourcen/Dateien (- Basisprofilierung)
 
*Kurzfristig realisierbar (Spezifikation + Implementierung)
 
*Kurzfristig realisierbar (Spezifikation + Implementierung)
*Einstieg in Standardisierung
+
*Einstieg in internationale Standards
 +
**Förderung der Interoperabilität der Systeme
 +
 
 +
==Aufbau==
 +
Derzeit wird international bei IHE ITI diskutiert, wie mit XDM verfahren werden soll. Hier laufen Überlegungen, wie durch Optionen Präzisierungen für die Datenablage in XDM erreicht werden können. Außerdem gibt es internationales Interesse an den hier erarbeiteten Vorgaben. Aus diesem Grund sollen nach einer Einleitung und Grundlagen die weiteren Vorgaben in zwei separaten Teilen erfolgen:
 +
 
 +
#Use Case bezogen: das kann international weiterverwendet werden
 +
#nationale Vorgaben bzgl. konkreter Inhalte (Vorbereitung einer National Extension für XDM)
  
 
=Szenarien=
 
=Szenarien=
Zeile 140: Zeile 150:
  
 
[[datei:IHEwss_Skalierung.JPG|600px]]
 
[[datei:IHEwss_Skalierung.JPG|600px]]
 +
 +
Minimal können so die Dokumente in PDF (oder CDA/DICOM/etc.) mit Angaben zum Patienten und Encounter (Besuch, Aufenthalt) übertragen werden. Unmittelbar daran lassen sich dann weitere administrative sowie klinische Information anschließen/ergänzen.
  
 
=Grobstruktur der Dateien für IHE ITI XDM=
 
=Grobstruktur der Dateien für IHE ITI XDM=
Zeile 145: Zeile 157:
 
Die grobe Dateistruktur, die im Folgenden weiter verfeinert wird, sieht wie folgt aus:
 
Die grobe Dateistruktur, die im Folgenden weiter verfeinert wird, sieht wie folgt aus:
  
<p>
+
==Media==
<b>Media</b><br>
+
 
 
{| class="hl7table"
 
{| class="hl7table"
 
|+
 
|+
Zeile 214: Zeile 226:
 
/IHE_XDM – administrative + klinische Daten
 
/IHE_XDM – administrative + klinische Daten
 
</pre>
 
</pre>
 +
 +
Diese Datei kann statisch erzeugt werden und im Prinzip immer die gleichen Informationen enthalten.
  
 
===INDEX.HTM===
 
===INDEX.HTM===
Zeile 254: Zeile 268:
 
</html>
 
</html>
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
 +
Je nach repräsentierten Use Case sollte diese Datei entsprechende Links auf die Inhalte enthalten, sollte also parallel zu den exportierten Inhalten aufgebaut werden.
  
 
===METADATA.XML===
 
===METADATA.XML===
Zeile 454: Zeile 470:
  
 
==weitere Dateien==
 
==weitere Dateien==
 +
 +
{{WorkBox| Brauchen wir weitere Dateien? }}
  
 
==Namenskonvention für die Dateinamen==
 
==Namenskonvention für die Dateinamen==
XDM verlangt, dass alle Dateien in der "alten" 8+3-Konvention mit Großbuchstaben erstellt werden. (Für Ordner gelten nur 8 Großbuchstaben.) Für eine korrekte Abarbeitung sind Namen zu wählen, die alphabetisch sortiert werden können und die gemäß dieser Sortierreihenfolge abzuarbeiten sind. Das gilt auch für Ordner.
+
{{ConstraintBox|
 +
XDM verlangt, dass alle Dateien in der "alten" 8+3-Konvention mit Großbuchstaben erstellt werden. Für Ordner sind nur 8 Großbuchstaben zugelassen. Für eine korrekte Abarbeitung sind Namen zu wählen, die alphabetisch sortiert werden können und die gemäß dieser Sortierreihenfolge abzuarbeiten sind. Das gilt auch für Ordner.
 +
}}
 +
 
 +
=Umsetzung der Use Cases=
 +
 
 +
{{WorkBox| Hier sollten Vorgaben stehen, die den repräsentierten Use Case erkennen lassen und genauer spezifizieren, was in welchem Use Case auf dem Medium enthalten sein sollte. }}
 +
 
 +
 
 +
{| class="hl7table"
 +
|+
 +
! !! Use Cases
 +
|+
 +
!Inhalt !! Systemwechsel !! Arztwechsel !! Konsil !! ..
 +
|-
 +
|Stammdaten || || ||
 +
|-
 +
|Kataloge || R || X ||
 +
|-
 +
| Patient || R [1..*] || O [0..1]
 +
|-
 +
| Fall/Aufenthalt || R [1..*] || O [0..1] ||
 +
|-
 +
| Diagnosen || || ||
 +
|-
 +
| Dokumente || R || R ||
 +
|-
 +
|..
 +
|}
  
 
=Inhalte=
 
=Inhalte=
Zeile 484: Zeile 530:
 
==CDA==
 
==CDA==
  
HL7-Deutschland hat offiziell eine Reihe von Leitfäden erstellt, die auf CDA basieren. Diese können alle genutzt werden:
+
HL7-Deutschland hat offiziell eine Reihe von Leitfäden erstellt, die auf CDA basieren. Diese sind auf http://wiki.hl7.de/index.php?title=CDA_und_Version_3_/_XML zu finden.
  
*Arztbrief
+
Diese können alle genutzt werden:
*Entlassbrief
+
 
 +
*Arztbrief 2014/15: http://download.hl7.de/documents/cdar2-arztbrief/Arztbrief2014-v100.pdf
 +
*ArztbriefPlus
 +
*Entlassbrief: http://wiki.hl7.de/index.php?title=Entlassmanagement_(Projekt)
 
*Ein-/Überweisung
 
*Ein-/Überweisung
*Rezepte, Medikationsplan
+
*Diagnosen: http://wiki.hl7.de/index.php?title=Diagnosen_(Projekt)
 +
*Maßnahmen: http://wiki.hl7.de/index.php?title=Ma%C3%9Fnahmen_(Projekt)
 +
*Rezepte
 +
*Medikationsplan: http://wiki.hl7.de/index.php?title=Medikationsplan_(Projekt)
 +
*Verordnungsmanagement:
 +
** Arbeitsunfähigkeitsbescheinigung: http://wiki.hl7.de/index.php?title=IG:Arbeitsunf%C3%A4higkeitsbescheinigung
 +
*Ein-/Überweisung: http://wiki.hl7.de/index.php?title=IG:Einweisung
 +
*Pflegebericht: http://wiki.hl7.de/index.php?title=EPflegebericht_(Projekt)
 +
*Wundbericht: http://wiki.hl7.de/index.php?title=EWundbericht_(Projekt)
 +
*Pflegeüberleitungsbogen: http://wiki.hl7.de/index.php?title=Pflege%C3%BCberleitungsbogen_(Projekt)
 +
*Pathologiebefund: http://wiki.hl7.de/index.php?title=Pathologiebefund_(Projekt)
 +
*onkologische Versorgung/Krebsregistermeldung: http://wiki.hl7.de/index.php?title=Onkologische_Versorgung_(Projekt)
 +
*außerklinische Beatmung: http://wiki.hl7.de/index.php?title=Au%C3%9Ferklinische_Beatmung_(Projekt)
 +
*Patiententeilnehmerverzeichnis: http://wiki.hl7.de/index.php?title=Patiententeilnehmerverzeichnis_(Projekt)
 +
*Mutterpass: http://wiki.hl7.de/index.php?title=Mutterpass_(Projekt)
 +
*Meldewesen und Infektionsschutz: http://wiki.hl7.de/index.php?title=Meldewesen_und_Infektionsschutz_(Projekt)
 +
*Notaufnahmeregister: http://wiki.hl7.de/index.php?title=Notaufnahmeregister_(Projekt)
 +
**Basismodul: http://wiki.hl7.de/index.php?title=IG:Notaufnahmeregister
 +
**Traumamodul: http://wiki.hl7.de/index.php?title=IG:Notaufnahmeregister_trauma
 
* ..
 
* ..
  
 
==FHIR==
 
==FHIR==
 +
{{ NoteBox |
 +
Die älteren HL7 Standards - hier wäre insbesondere v2.x zu nennen - sind primär nachrichtenbasiert. Somit käme auch in Betracht, die Basisinformationen als abzuspielende Nachrichten zu repräsentieren. Mit dem immer stärkeren Aufkommen von FHIR kommt das aber nicht mehr in Betracht.
 +
}}
  
 
Das technische Komitee für FHIR erarbeitet derzeit eine Reihe von Basisprofilen zur Nutzung von FHIR in Deutschland. Bei der Nutzung von FHIR-basierten Dateien (=Ressourcen) sind diese Profile einzuhalten:
 
Das technische Komitee für FHIR erarbeitet derzeit eine Reihe von Basisprofilen zur Nutzung von FHIR in Deutschland. Bei der Nutzung von FHIR-basierten Dateien (=Ressourcen) sind diese Profile einzuhalten:
Zeile 512: Zeile 582:
 
|Patient || demographische Daten || http://fhir.de/StructureDefinition/patient-de-basis || https://simplifier.net/BasisprofilDE/Patient-example
 
|Patient || demographische Daten || http://fhir.de/StructureDefinition/patient-de-basis || https://simplifier.net/BasisprofilDE/Patient-example
 
|-
 
|-
|Encounter|| Fallinformationen || ||
+
|Encounter|| || ||
 +
|-
 +
|EpisodeOfCare || Fallinformationen ||
 +
|-
 +
|Person || ||
 +
|-
 +
|RelatedPerson || ||
 
|-
 
|-
 
!klinisch !! !! !!
 
!klinisch !! !! !!
 
|-
 
|-
|Concern (Diagnosis)|| Diagnosen ||
+
|Condition || (aka Problem) || https://simplifier.net/BasisprofilDE/condition-de-basis ||
|-
 
|Condition || || https://simplifier.net/BasisprofilDE/condition-de-basis ||
 
 
|-
 
|-
 
|Observation|| Beobachtungen, Meßwerte und Befunde || ||
 
|Observation|| Beobachtungen, Meßwerte und Befunde || ||
Zeile 528: Zeile 602:
 
|MedicationStatement || || ||
 
|MedicationStatement || || ||
 
|-
 
|-
|AllergyIntolerance || || ||
+
|AllergyIntolerance || Allergien und Unverträglichkeiten|| ||
 
|-
 
|-
 
|Goal || || ||
 
|Goal || || ||
 
|-
 
|-
|FamilyMemberHistory || || ||
+
|FamilyMemberHistory || Familienanamnese || ||
 +
|-
 +
|Questionnaire|| ||
 +
|-
 +
|QuestionnaireResponse || ||
 
|-
 
|-
 
!finanziell !! !! !!
 
!finanziell !! !! !!
Zeile 547: Zeile 625:
 
|-
 
|-
 
|Practitioner || Ärzte || ||
 
|Practitioner || Ärzte || ||
 +
|-
 +
|PractitionerRole || || ||
 
|-
 
|-
 
|Organization || Organisationen || http://fhir.de/StructureDefinition/organization-de-basis, https://simplifier.net/BasisprofilDE/organization-de-basis ||
 
|Organization || Organisationen || http://fhir.de/StructureDefinition/organization-de-basis, https://simplifier.net/BasisprofilDE/organization-de-basis ||
 +
|-
 +
|CareTeam || ||
 
|-
 
|-
 
|... || || ||
 
|... || || ||
Zeile 639: Zeile 721:
  
 
==Signatur==
 
==Signatur==
 +
Die Repreäsentation der Daten in Form von Dateien bieten eine einfache Signaturmöglichkeit.
  
 
===Einzelsignatur===
 
===Einzelsignatur===
  
Individuell für einzelne Dateien.
+
Individuell für einzelne Dateien. Diese kann parallel zu der zu signierenden Datei (gleicher Basisdateiname) abgelegt werden.
  
 
===Stapelsignatur===
 
===Stapelsignatur===
  
Im Falle von Stapelsignaturen kann am besten von den Metadatendateien Gebrauch gemacht werden. Dafür sind für alle betroffenen, d.h. zu signierenden Dateien die entsprechenden Hashwerte anzugeben. Die Signatur wird auf die Metadatendatei angewendet.
+
Im Falle von Stapelsignaturen kann am besten von den Metadatendateien (METADATA.XML) Gebrauch gemacht werden. Dafür sind für alle betroffenen, d.h. zu signierenden Dateien die entsprechenden Hashwerte anzugeben. Die Signatur wird auf die Metadatendatei angewendet und parallel zu dieser abgelegt.
  
 
==Verschlüsselung==
 
==Verschlüsselung==
Zeile 655: Zeile 738:
  
 
XDM sieht laut Technical Framework CD-R, USB-Sticks und ZIP-Dateien vor. Es spricht aber auch nichts dagegen, hier auch DVD, Terrabyte-Festplatten, NAS-Laufwerke und ggf. - sofern es datenschutzrechtlich abgesichert ist - Cloud-Speicher einzusetzen.
 
XDM sieht laut Technical Framework CD-R, USB-Sticks und ZIP-Dateien vor. Es spricht aber auch nichts dagegen, hier auch DVD, Terrabyte-Festplatten, NAS-Laufwerke und ggf. - sofern es datenschutzrechtlich abgesichert ist - Cloud-Speicher einzusetzen.
 
  
 
=Anhang=
 
=Anhang=
  
 
==Beispiele==
 
==Beispiele==
 +
 +
{{WorkBox| tbd }}
  
 
==Literatur==
 
==Literatur==

Version vom 7. Februar 2018, 09:27 Uhr


Abstimmungsdokument 
Version Datum Status Realm
01 01.03.2018 Si-draft.svg Entwurf Flag de.svg Deutschland
Document PDF.svg noch kein download verfügbar
Kontributoren 
Logo telekom healthcare.png Deutsche Telekom Healthcare and Security Solutions GmbH Bonn
Logo-Hcs.jpg Heitmann Consulting and Services GmbH, Gefyra GmbH Hürth


Dokumenteninformationen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Impressum

Dieser Leitfaden wurde im Rahmen des Interoperabilitätsforums und der Technischen Komitees von HL7 Deutschland e. V. sowie der entsprechenden Projektgruppen erstellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums[1] und der Technischen Komitees von HL7 Deutschland e. V. [2]

Ansprechpartner und Autoren

  • Dr. Frank Oemig, Deutsche Telekom Healthcare and Security Solutions GmbH, Bonn
  • Dr. Marc Kämmerer, Visus GmbH, Bochum

Disclaimer


Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

Für alle veröffentlichten Dateien mit einem HL7 CDA- bzw. HL7 FHIR-Bezug gilt ferner: Alle abgestimmten und veröffentlichten Spezifikationen wie Implementierungsleitfäden, Stylesheets und Beispieldateien sind frei verfügbar und unterliegen keinerlei Einschränkungen, da die Autoren auf alle Rechte, die sich aus der Urheberschaft der Dokumente ableiten lassen, verzichten.

Alle auf nationale Verhältnisse angepassten und veröffentlichten CDA-Schemas können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
Aus der Nutzung ergibt sich kein weiter gehender Anspruch gegenüber HL7 Deutschland e.V., zum Beispiel eine Haftung bei etwaigen Schäden, die aus dem Gebrauch der Spezifikationen bzw. der zur Verfügung gestellten Dateien entstehen.

Näheres unter http://www.hl7.de, http://www.hl7.org und http://www.ihe.net.

Für xBDT ist eine Lizenz erforderlich.

Einleitung

Es gibt eine Reihe von Szenarien (s.u.), die einen etwas umfassenderen Austausch von Patientendaten erfordern, wo es sich dann nicht nur um eine Art von Informationen wie bspw. Dokumente oder Arztbriefe handelt.

Hintergrund

Deutschland hat mit der Änderung des Paragraphen §291 - speziell §291d - im SGB V eine gesetzliche Forderung nach offenen und standardisierten Schnittstellen verankert. Laut diesem eHealth-Gesetz sind die KBV für den ambulanten und die DKG für den stationären Sektor für die Festlegung einer System- bzw. Arztwechselschnittstelle verantwortlich. Mit der letzten Änderung an diesem Gesetz Ende Mai 2017 sind außerdem Fristen ("2 Jahre nach der Festlegung") festgeschrieben worden. Im Absatz 5 wird außerdem gefordert, dass bei "inhaltlichen Gemeinsamkeiten der Schnittstellen sektorübergreifende einheitliche Vorgaben zu treffen" sind.

Der bvitg hat der KBV hier xBDT vorgeschlagen. (Von der QMS kam noch BDT3.0 als Gegenvorschlag.) Bei der DKG verzichtet man vorläufig auf eine Festlegung. (Im Gesetz ist hier von "KANN" die Rede, was als "nicht müssen" interpretiert wird.) Ob deshalb auf eine Festlegung verzichtet werden kann wird derzeit unterschiedlich interpretiert.

Laut der europäischen Datenschutzgrundverordnung (EU-DSVG), die am 18.Mai 2018 in Kraft tritt, hat der Patient ein Recht, seine Daten in "strukturierter" Form mitzunehmen. Mit letzterem ist gemeint, dass eine papierbasierte Zurverfügungstellung nicht ausreicht.

Für die Systemwechselschnittstelle ist eine Frist von zwei Jahren vorgesehen, sobald die Vorgaben in vesta hinterlegt sind. Für weitere Schnittstellen, das können dann die hier beschriebenen Szenarien sein, kann der Gesetzgeber ebenfalls Fristen vorgeben.

Zweck

Dieser Leitfaden soll unter Verwendung bereits vorhandener und genutzter Spezifikationen eine vorgabe für einen strukturierten Datenaustausch bereitstellen, der die u.g. Szenarien abdeckt.

Lösungsansatz

Als Lösungsanatz wird hier XDM gewählt, da damit insbesondere ein Offline-Datenaustausch unterstützt wird, weil ein System ggf. nicht verfügbar bzw. die Systeme sind nicht online miteinander verbunden sind. XDM selbst macht keine direkten inhaltlichen Vorgaben, was genau auszutauschen ist. XDM stellt eine Strukturvorgabe auf einem Medium bereit und kombiniert dies mit Metadaten, um die bereitgestellten Dateien wieder einlesen/verarbeiten zu können.

Vorteile

Dieser Leitfaden nutzt folgende Eigenschaften, um eine breitere Akzeptanz zu ermöglichen:

  • einsetzbar für verschiedene Szenarien (s.u.)
  • basiert auf bereits genutzten Standards (wie bspw. IHE ITI XDM, HL7 V3 CDA, DICOM, PDF, FHIR)
  • cerwendet bereits vorhandene deutsche Profile (Arztbrief PLUS, FHIR-Basisprofilierung, ..) bzw. das, was vorhanden ist
  • FHIR gestattet eine einfache Übermittlung von Basisdaten:
    • Patient, Fälle + Aufenthalte (Encounter), Diagnosen, Prozeduren, Maßnahmen, Medikation, ..
    • Stammdaten: Ärzte (Practitioner, Organization)
    • Kataloge (Value Sets)
  • die Umsetzung ist inkrementell erweiterbar
    • weitere Ressourcen/Dateien (-> FHIR Bulk Data)
    • weitere Details in den Ressourcen/Dateien (- Basisprofilierung)
  • Kurzfristig realisierbar (Spezifikation + Implementierung)
  • Einstieg in internationale Standards
    • Förderung der Interoperabilität der Systeme

Aufbau

Derzeit wird international bei IHE ITI diskutiert, wie mit XDM verfahren werden soll. Hier laufen Überlegungen, wie durch Optionen Präzisierungen für die Datenablage in XDM erreicht werden können. Außerdem gibt es internationales Interesse an den hier erarbeiteten Vorgaben. Aus diesem Grund sollen nach einer Einleitung und Grundlagen die weiteren Vorgaben in zwei separaten Teilen erfolgen:

  1. Use Case bezogen: das kann international weiterverwendet werden
  2. nationale Vorgaben bzgl. konkreter Inhalte (Vorbereitung einer National Extension für XDM)

Szenarien

Zur Erfüllung der Anforderungen gemäß eHealth-Gesetz (§291) müssen zwei Szenarien abgedeckt werden. Das ist zum Einen die Möglichkeit, dass ein Arzt das von ihm genutzte System wechseln kann, zum Anderen müssen die Patientendaten systemneutral archiviert werden können. Darüber hinaus hat ein Patient unbenommen das Recht, seinen Arzt zu wechseln und dazu alle notwendigen Daten mitzunehmen (Arzt-Arzt Kommunikation) oder auch nur die Daten selbst zu bekommen (Arzt-Patient Kommunikation). Letzteres wird bisher in Form von papiergebundenen Kopien realisiert.

Die europäische Datenschutzgrundverordnung sieht ab Mai 2018 vor, dass ein Patient das Recht hat, seine Daten in strukturierter Form zu bekommen. Mit "strukturiert" ist in diesem Fall "maschinenlesbar" gemeint, da nur so die Daten für eine weitere Nutzung auch wieder eingelesen werden können.

IHEwss Transaktion.JPG

Welche Prozessschritte und Berechtigungen notwendig sind, um an die Daten zu gelangen, ist nicht Gegenstand dieses Leitfadens.

Systemwechsel

Die erste Möglichkeit der Nutzung ist ein Systemwechsel, d.h. ein System wird durch ein gleichwertiges/ähnliches/besseres von einem anderen Hersteller ausgetauscht. Primäres Ziel hierbei ist die Über-/Mitnahme aller relevanten Daten:

IHEwss Systemwechsel.JPG

Bei einem Systemwechsel ist zu beachten, dass das Medium hierbei Daten unterschiedlicher Patienten beinhalten kann. Außerdem können zuerst Kataloge und Stammdaten abgelegt werden.

Arztwechsel

Die zweite Möglichkeit ist die Übertragung aller patientenrelevanten Daten von einem Arzt zu einem anderen. Das primäre Ziel hierbei ist die möglichst vollständige Mitnahme aller behandlungsrelevanten Daten.

IHEwss Arztwechsel.JPG

Aktentransport

Nicht zuletzt kann dieser Mechanismus auch dafür benutzt werden, eine Untermenge der Daten für einen bestimmten Zweck zu übertragen, beispielsweise zur Übertragung von Informationen an einen Nachbehandler oder die Einholung einer Zweitmeinung.

EU-DSGVO

Laut europäischer Datenschutzgrundverordnung (EU-DSGVO, Artikel 20, Abs.1 und 2) hat der Patient ab 18.5.2018 ein Recht darauf, seine Daten in strukturierter Form zu bekommen: "in einem strukturierten, gängigen und maschinenlesbaren Format zu erhalten, und ... einem anderen Verantwortlichen ohne Behinderung durch den Verantwortlichen ... zu übermitteln". Mit "strukturiert" ist in diesem Fall maschinenlesbar und kodiert gemeint, da nur so gewährleistet ist, dass eine größere Datenmenge auch sinnvoll wieder eingelesen und weitergenutzt werden kann. Damit scheidet PDF dann als mögliches Format aus und CDA oder FHIR tritt an diese Stelle.

Dieser Leitfaden auf Basis von XDM deckt damit eine indirekte Übermittlung bspw. per USB-Stick ab.

Auskunftsersuchen

Ein anderer Use Case ist die Beantwortung von Auskunftsersuchen, mit dem nach den lokal gespeicherten Daten gefragt wird. Hier sind ebenfalls alle Daten bereitzustellen, die zu einem Patienten gehören.

Lösungsansatz

Der hier vorgestellte Ansatz bietet die Möglichkeit einer Skalierung in mehrere Dimensionen, so dass klein angefangen, später aber mit zusätzlichen Details ergänzt werden kann.

IHEwss Skalierung.JPG

Minimal können so die Dokumente in PDF (oder CDA/DICOM/etc.) mit Angaben zum Patienten und Encounter (Besuch, Aufenthalt) übertragen werden. Unmittelbar daran lassen sich dann weitere administrative sowie klinische Information anschließen/ergänzen.

Grobstruktur der Dateien für IHE ITI XDM

Die grobe Dateistruktur, die im Folgenden weiter verfeinert wird, sieht wie folgt aus:

Media

Dateistruktur Inhalt Dateiname XDM-Optionalität Profilierung
Treetree.png Document DOC.svg README.TXT statische Readme-Datei fix R R
Treetree.png Document HTML.svg INDEX.HTM HTML-basierte Navigationsseite fix R R
Treetree.png Icon folder.JPG IHE_XDM Hauptordner fix R R
Treeblank.png Treetree.png Icon folder.JPG SUBSET01 Unterordner max. 8 Großbuchstaben optional R
Treeblank.png Treetree.png Icon folder.JPG SUBSET02 Unterordner max. 8 Großbuchstaben optional R
Treeblank.png Treetree.png ... weitere Unterordner max. 8 Großbuchstaben optional
Treetree.png Document DOC.svg OTHERDOC.DAT sonstige Datei, von IHE erlaubt max. 8+3 Großbuchstaben optional O

Inhalte eines Ordners

Dateistruktur Inhalt Dateiname XDM-Optionalität Profilierung
Treetree.png Icon folder.JPG SUBSET01 Unterordner mit Daten max. 8 Großbuchstaben R R
Treeblank.png Treetree.png Document XML.svg METADATA.XML Metadaten für alle in diesem Ordner enthaltene Dateien fix R R
Treeblank.png Treetree.png Document PDF.svg *.PDF PDF-Dokumente max. 8 Großbuchstaben optional R
Treeblank.png Treetree.png Document DOC.svg *.XML CDA-Dokumente max. 8 Großbuchstaben optional O
Treeblank.png Treetree.png Document XML.svg *.XML FHIR-Ressourcen im XML-Format max. 8 Großbuchstaben optional O
Treeblank.png Treetree.png Document DOC.svg *.BDT xBDT-Dateien max. 8 Großbuchstaben optional O
Treeblank.png Treetree.png Document XML.svg *.XML andere XML-basierte Dokumente max. 8 Großbuchstaben optional O
Treeblank.png Treetree.png *.JPG, *.GIF, *.TIF, *.DCM bildbasierte Formate bspw. für Scans max. 8 Großbuchstaben optional O

XDM Hauptdateien

XDM sieht vor, dass ein paar Dateien fix vorhanden sein müssen. Diese werden nachfolgend kurz erläutert.

README.TXT

Die README.TXT Datei ist eine Datei, die laut XDM vorhanden sein muss und Aufschluss über das Medium bei Rückfragen gibt.

Beispiel

Erzeugt von:
Allgemeines Krankenhaus
Gesundheitsweg 47
12345 Berlin

Für technische Unterstützung:
Customer Support
0800-555-0889

Erzeugt durch xy GmbH

Inhalt des Mediums:
INDEX.HTM - Inhaltsangabe
/IHE_XDM – administrative + klinische Daten

Diese Datei kann statisch erzeugt werden und im Prinzip immer die gleichen Informationen enthalten.

INDEX.HTM

Die INDEX.HTM Datei wird individuell für das zu erstellende Medium erzeugt und enthält (patientenspezifische) Links, um das Navigieren zu erleichtern.

Beispiel

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<title>XDM - klinische Dokumente für STEVE FARNSWORTH</title>
</head>
<body>
<h1>
XDM Dokumente:
</h1>
<p>
Erzeugt von: <br/>
Allgemeines Krankenhaus <br/>
Gesundheitsweg 47 <br/>
12345 Berlin
</p>
<p>
Name des Patienten: STEVE FARNSWORTH<br/>
Pat-ID: 3014 (1.3.6.1.4.1.21367.2009.1.2.400)<br/>
Geschlecht: M <br/>
Gebrutsdatum:<br/>
Hintere Gasse 7<br/>
12346 Berlin
</p>
<h2>
Dokumente:
</h2>
<p><a href="IHE_XDM\CCD1\CCD_FARN.xml">Allg. Krh. Arztbrief</a></p>
<p><a href="IHE_XDM\CCD2\CCD_FARN.xml">Allg. Krh. Einweisung</a></p>
</body>
</html>

Je nach repräsentierten Use Case sollte diese Datei entsprechende Links auf die Inhalte enthalten, sollte also parallel zu den exportierten Inhalten aufgebaut werden.

METADATA.XML

Die Metadatendatei beinhaltet alle notwendigen Metadaten für alle auf dem Medium vorhandenen Dateien.

Beispiel

<?xml version="1.0" encoding="UTF-8"?>
<lcm:SubmitObjectsRequest
       xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
       xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
  <rim:RegistryObjectList>
    <rim:ObjectRef id="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" />
    <rim:RegistryPackage id="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54">
      <rim:Slot name="submissionTime">
        <rim:ValueList>
          <rim:Value>20110119094335</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Name />
      <rim:Description />
      <rim:Classification id="cs129545181532887187021426829752701"
             classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
             classifiedObject="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54"
             nodeRepresentation="Summarization of episode">
        <rim:Slot name="codingScheme">
          <rim:ValueList>
            <rim:Value>Connect-a-thon contentTypeCodes</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" xml:lang="en-us"
              value="Summarization of episode" />
        </rim:Name>
      </rim:Classification>
      <rim:ExternalIdentifier id="i129545181532873297332487895283681"
              identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446"
              registryObject="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54"
              value="3014^^^&amp;1.3.6.1.4.1.21367.2009.1.2.400&amp;ISO">
        <rim:Name>
          <rim:LocalizedString value="XDSSubmissionSet.patientId" />
        </rim:Name>
      </rim:ExternalIdentifier>
      <rim:ExternalIdentifier id="i1295451815328-75133792076035487272"
             identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832"
             registryObject="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54"
             value="1.3.6.1.4.1.21367.13.2300">
        <rim:Name>
          <rim:LocalizedString value="XDSSubmissionSet.sourceId" />
        </rim:Name>
      </rim:ExternalIdentifier>
      <rim:ExternalIdentifier id="i129545181532885853874948009515163"
            identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8"
            registryObject="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54"
            value="2.16.840.1.113883.3.140.1.0.6.10.1027010453125023">
        <rim:Name>
          <rim:LocalizedString value="XDSSubmissionSet.uniqueId" />
        </rim:Name>
      </rim:ExternalIdentifier>
    </rim:RegistryPackage>
     <rim:ExtrinsicObject
          id="urn:uuid:9573e35e-356a-882c-9ba9-0016cf875c54"
          objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
          mimeType="text/xml" >
      <rim:Slot name="creationTime">
          <rim:ValueList>
             <rim:Value>20110119154305</rim:Value>
          </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="hash">
          <rim:ValueList>
             <rim:Value>093fe223f551c82e275d56d962781f38dc60d360</rim:Value>
          </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="languageCode">
        <rim:ValueList>
          <rim:Value>en-US</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="serviceStartTime">
        <rim:ValueList>
          <rim:Value>20100119</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="serviceStopTime">
        <rim:ValueList>
          <rim:Value>20110119</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="size">
          <rim:ValueList>
             <rim:Value>38235</rim:Value>
          </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="URI">
          <rim:ValueList>
             <rim:Value>CCD_FARN.xml</rim:Value>
          </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="sourcePatientId">
        <rim:ValueList>
          <rim:Value>3014^^^&amp;2.16.840.1.113883.3.140.1.0.6.4&amp;ISO</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="sourcePatientInfo">
        <rim:ValueList>
          <rim:Value>PID-3|3014^^^&amp;2.16.840.1.113883.3.140.1.0.6.4&amp;ISO</rim:Value>
          <rim:Value>PID-5|FARNSWORTH^STEVE</rim:Value>
          <rim:Value>PID-8|M</rim:Value>
          <rim:Value>PID-11|820 JORIE BLVD^^CHICAGO^IL^60523^US</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Name>
        <rim:LocalizedString charset="UTF-8" xml:lang="en-us" value="Madison Medical Center P. A. Continuity of Care Document" />
      </rim:Name>
      <rim:Description />
      <rim:Classification id="c1295451815359-16821550949756222801"
             classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
             classifiedObject="urn:uuid:9573e35e-356a-882c-9ba9-0016cf875c54"
             nodeRepresentation="Summarization of episode">
        <rim:Slot name="codingScheme">
          <rim:ValueList>
            <rim:Value>Connect-a-thon classCodes</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Name>
          <rim:LocalizedString charset="UTF-8"
               xml:lang="en-us" value="Summarization of episode" />
        </rim:Name>
      </rim:Classification>
      <rim:ExternalIdentifier id="i129545181535932337158254820973541"
             identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
             registryObject="urn:uuid:9573e35e-356a-882c-9ba9-0016cf875c54"
             value="3014^^^&amp;1.3.6.1.4.1.21367.2009.1.2.400&amp;ISO">
        <rim:Name>
          <rim:LocalizedString value="XDSDocumentEntry.patientId" />
        </rim:Name>
      </rim:ExternalIdentifier>
       ...
    </rim:ExtrinsicObject>
    <rim:Association id="a1295451815359-13126249208320826000"
           associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"
           sourceObject="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54"
           targetObject="urn:uuid:9573e35e-356a-882c-9ba9-0016cf875c54">
      <rim:Slot name="SubmissionSetStatus">
        <rim:ValueList>
          <rim:Value>Original</rim:Value>
        </rim:ValueList>
      </rim:Slot>
    </rim:Association>
    ....
  </rim:RegistryObjectList>
</lcm:SubmitObjectsRequest>

Folgende Metadaten sind bereitzustellen:

Slot Name Inhalt Optionalität Beispiel
RegistryPackage
Classification
ExtrinsicObject - Slot
size Größe der Datei O
URI Name der Datei R
hash Hashwert der Datei C (Signatur)
creationTime Erzeugungsdatum der Datei O 20110119154305
submissionTime Übermittlungsdatum der Datei O 20110119154305
Beschreibung des Inhaltes O
Dateiformat O
languageCode Sprachkennzeichen O
serviceStartTime O
serviceStopTime O
sourcePatientId Id des Patienten C
sourcePatientInfo weitere Informationen über den Patienten (Nutzung über HL7 v2.x Segmente und Datentypen) C

weitere Dateien

Namenskonvention für die Dateinamen

Umsetzung der Use Cases


Use Cases
Inhalt Systemwechsel Arztwechsel Konsil ..
Stammdaten
Kataloge R X
Patient R [1..*] O [0..1]
Fall/Aufenthalt R [1..*] O [0..1]
Diagnosen
Dokumente R R
..

Inhalte

Als Dateien können alle Dateien verwendet werden, die aufgrund anderer Use Cases schon erstellt und kommuniziert werden. Darüber hinaus werden strukturierte Inhalte verlangt, die in Form von CDA-basierten Dokumenten und FHIR-Resourcen bereitgestellt werden.

Stammdaten und Kataloge (Vokabularien)

Im Falle eines Systemwechsels sind auch Stammdaten und Kataloge zu ex- und importieren.

  • Stammdaten
    • Ärzte
    • Organisationen
    • Stationen, Fachbereiche, ..
    • ..
  • Kataloge
    • ICD (besser über off. Server)
    • ICPM (besser über off. Server)
    • Hauskataloge
    • ..

PDF-Dokumente

Die derzeit gängige Art Informationen auszutauschen ist über PDF. Hier können alle PDF-basierten Dokumente genutzt werden.

CDA

HL7-Deutschland hat offiziell eine Reihe von Leitfäden erstellt, die auf CDA basieren. Diese sind auf http://wiki.hl7.de/index.php?title=CDA_und_Version_3_/_XML zu finden.

Diese können alle genutzt werden:

FHIR

Das technische Komitee für FHIR erarbeitet derzeit eine Reihe von Basisprofilen zur Nutzung von FHIR in Deutschland. Bei der Nutzung von FHIR-basierten Dateien (=Ressourcen) sind diese Profile einzuhalten:

FHIR-Ressourcen

Resource Inhalt Link Beispiele
administrativ
Patient demographische Daten http://fhir.de/StructureDefinition/patient-de-basis https://simplifier.net/BasisprofilDE/Patient-example
Encounter
EpisodeOfCare Fallinformationen
Person
RelatedPerson
klinisch
Condition (aka Problem) https://simplifier.net/BasisprofilDE/condition-de-basis
Observation Beobachtungen, Meßwerte und Befunde
Procedure Maßnahmen
Medication Medikation
MedicationStatement
AllergyIntolerance Allergien und Unverträglichkeiten
Goal
FamilyMemberHistory Familienanamnese
Questionnaire
QuestionnaireResponse
finanziell
Coverage Versicherungsinformationen http://fhir.de/StructureDefinition/coverage-de-basis, https://simplifier.net/BasisprofilDE/coverage-de-gkv, https://simplifier.net/BasisprofilDE/coverage-de-sel
technisch
CodeSystem Kataloge
ValueSet Wertemengen (Auswahllisten)
organisatorisch
Practitioner Ärzte
PractitionerRole
Organization Organisationen http://fhir.de/StructureDefinition/organization-de-basis, https://simplifier.net/BasisprofilDE/organization-de-basis
CareTeam
...

FHIR-Datentypen

FHIR Resourcen sind nicht nur auf Ressourcenebene profiliert, es gibt auch spezielle Vorgaben für die Nutzung der Datentypen in bestimmten Kontexten:

xBDT

Für den ambulanten Bereich hat der bvitg der KBV die Nutzung von xBDT vorgeschlagen. Daher können die entsprechenden Satzarten ebenfalls genutzt werden.

Folgende Satzarten sind zu unterstützen:

Satzart Inhalt Optionalität Beispiel
2.Stammdaten
0080 „adrs“ Adressenstamm
0081 „diag“ Diagnosenliste
0082 „tbau“ Textbausteine
0084 „medi“ Medikamente (selbst angelegte und Rezepturen)
0083 „lket“ Leistungsketten
0085 „term“ Terminkalender
3.Standard-BDT
0010 Praxisdaten
„besa“ Praxisdaten nach VÄndG
0020 Datenträger-Header
0021 Datenträger-Abschluss
0022 Datenpaket-Header
0023 Datenpaket-Abschluss
4. Kassen-Scheine
0101
0102
0103
0104
5. IV/HzV-Scheine
0111
0112
0113
0114
6.Privat-Abrechnung und 0191 BG-Abrechnung
0190 Privatfall
0191 BG-Fall/Unfall
7. Patientenstamm
6100
8.Behandlungsdaten
6200

Sonstiges

Signatur

Die Repreäsentation der Daten in Form von Dateien bieten eine einfache Signaturmöglichkeit.

Einzelsignatur

Individuell für einzelne Dateien. Diese kann parallel zu der zu signierenden Datei (gleicher Basisdateiname) abgelegt werden.

Stapelsignatur

Im Falle von Stapelsignaturen kann am besten von den Metadatendateien (METADATA.XML) Gebrauch gemacht werden. Dafür sind für alle betroffenen, d.h. zu signierenden Dateien die entsprechenden Hashwerte anzugeben. Die Signatur wird auf die Metadatendatei angewendet und parallel zu dieser abgelegt.

Verschlüsselung

Eine Verschlüsselung des Mediums ist über gängige Verfahren wie ZIP möglich, wird hier aber nicht beschrieben.

Transportmöglichkeiten

XDM sieht laut Technical Framework CD-R, USB-Sticks und ZIP-Dateien vor. Es spricht aber auch nichts dagegen, hier auch DVD, Terrabyte-Festplatten, NAS-Laufwerke und ggf. - sofern es datenschutzrechtlich abgesichert ist - Cloud-Speicher einzusetzen.

Anhang

Beispiele

Literatur

Referenzen

  1. Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)
  2. HL7 Deutschland e. V. http://www.hl7.de