Aktuelle Version vom 20. Juni 2018, 13:57 Uhr

	Dieses Dokument gibt wieder: Implementierungsleitfaden Wechselschnittstelle (0.5). Die Teilmaterialien gehören der Kategorie ihewss an.

Wechselschnittstelle auf Basis von IHE ITI XDM und HL7 FHIR
für das deutsche Gesundheitswesen

Wechselschnittstelle

Implementierungsleitfaden

vorgelegt von:
HL7 Deutschland

abgelehnt

Version:	0.5
Datum:	15. Mai 2018
Status:	Abstimmung
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
0.5	15.05.2018	abgelehnt	Deutschland
		[download]

Kontributoren
	Deutsche Telekom Healthcare and Security Solutions GmbH	Bonn
	Heitmann Consulting and Services GmbH, Gefyra GmbH	Hürth
	VISUS Health IT GmbH	Bochum
	timeproof GmbH	Planegg
	CCeSigG	Braunschweig

Inhaltsverzeichnis

1 Dokumenteninformationen
2 Einleitung
3 Szenarien
4 Lösungsansatz
- 4.1 Ausprägungen
5 Grobstruktur der Dateien für IHE ITI XDM
6 Umsetzung der Use Cases
7 Signatur – Zeitstempel – Evidence Record
- 7.1 Einzelsignatur
- 7.2 Stapelsignatur
8 Inhalte
9 Sonstige Angaben
10 Anhang

Dokumenteninformationen

Hinweis

Spezifikation erfüllt die Anforderungen zur "Festlegung der Schnittstellen nach § 291d Absatz 1 Satz 1 Nr. 1 SGB V" und ist damit nicht zu verwechseln mit der Schnittstellenspezifikation für eine Verordnungssoftware, die häufig auch als §291d-Spezifikation genannt wird!

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 ist im Rahmen des Interoperabilitätsforums, den Technischen Komitees von HL7 Deutschland e. V., IHE Deutschland e.V. sowie der entsprechenden Projektgruppen zusammengestellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums^[1], der Technischen Komitees von HL7 Deutschland e. V. ^[2] und IHE Deutschland e. V. ^[3]

Ansprechpartner und Autoren

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

Kontributoren

Olaf Feller, timeproof, Planegg
Jürgen Bosk, CCESigG, Braunschweig
Daniel Haak, Visus GmbH, Bochum
Dr. Bernd Schütze, DTHS, Düsseldorf

Disclaimer

Der Inhalt dieses Dokumentes ist öffentlich. Zu beachten ist, dass Teile dieses Dokuments auf der Normative Edition 2005 von HL7 Version 3 bzw. auf HL7 FHIR(R) beruhen, für die © HL7 International gilt.
Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann HL7 Deutschland keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.

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. oder IEH 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, http://www.ihe-d.de und http://www.ihe.net.

Einleitung

Es gibt eine Reihe von Szenarien (s.u.), die einen Austausch von patientenbezogenen Daten erfordern, der über simple Dokumente hinausgeht. Hier sollen dann auch strukturierte Basisdaten wie Diagnosen, Maßnahmen o.ä. oder sogar Stammdaten und Vokabularien übermittelt werden.

Dieser Leitfaden soll eine Brücke schaffen zwischen den aktenbasierten Spezifikationen, die IHE XDS einsetzen, und der sich gegenwärtig abzeichnenden Technologie FHIR.

Hintergrund

Das Bundesministerium für Gesundheit hat mit der Änderung des Paragraphen §291 - speziell §291d Absatz 1 Satz 1 - 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. Archivierungsschnittstelle 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 zusätzlich gefordert, dass bei "inhaltlichen Gemeinsamkeiten der Schnittstellen sektorübergreifende einheitliche Vorgaben zu treffen" sind.

Laut der europäischen Datenschutzgrundverordnung (EU-DSVG), die am 25.Mai 2018 in Kraft tritt, hat der Patient ein Recht, seine Daten nicht nur elektronisch sondern auch in "strukturierter" Form zu bekommen. Mit letzterem ist gemeint, dass eine papierbasierte Zurverfügungstellung nicht ausreicht und die Daten auch wieder eingelesen werden sollen. Insbesondere Letzteres ist mit reinem Text - bspw. als PDF - nicht ohne weiteres möglich.

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 - insbesondere IHE ITI XDM, HL7 CDA und HL7 FHIR - eine Vorgabe für einen strukturierten Datenaustausch bereitstellen, der die u.g. Szenarien abdeckt. Auch soll er eine Brücke schaffen zwischen der reinen XDS-basierten "Aktenwelt/-sicht", die auf ebXML mit SOAP und entsprechenden Metadaten und der zukünftig immer stärker Verbreitung finden FHIR-Welt.

Anforderungen

Die Änderung von §291d SGB V erfolgte mit der Zielsetzung, die elektronische Datenübertragung zzgl. übertragbarer Krankheiten zu ermöglichen.

Die Änderung von §291d SGB V erfolgte mit Art. 8a „Gesetz zur Modernisierung der epidemiologischen Überwachung übertragbarer Krankheiten (BGBl. 1, 2017(49), S. 2615ff). Im Gesetzesentwurf vom 23. Januar 2017 war die Gesetzesänderung noch nicht enthalten. Erst im Laufe der parlamentarischen Diskussion wurde die Änderung von §291d SGB V in das Gesetz integriert. In der Beschlussempfehlung des Ausschusses für Gesundheit (Bundestag Drucksache 18/12604, 2017-05-31) wurde die Änderung als „Artikel 8a“ in das Gesetz aufgenommen. Die Begründung zur Änderung von §291d SGB V lautete wie folgt:

„Durch eine Änderung des § 291d SGB V wird die obligatorische Integration offener und standardisierter Schnittstellen (für das elektronische Melde- und Informationssystem nach § 14 IfSG) in informationstechnische Systeme der vertragsärztlichen und der vertragszahnärztlichen Versorgung und der Krankenhäuser (Praxisverwaltungssysteme und Krankenhausinformationssysteme), für Softwarehersteller geregelt.“ (S. 72, Ziff. 7)
„[…] Mit elektronischen Programmen sollen insbesondere auch Add-on/Plug-in-Programme gemeint sein. Softwarehersteller sollen nach §291d Absatz 1a SGB V Programmierschnittstellen zu ihren Produkten bereitstellen, mit deren Hilfe Erweiterungen (Plug-ins) für diese Softwareprodukte integriert werden können. Denkbar sind aber auch eigenständige elektronische Programme. Das Robert Koch-Institut muss in die Lage versetzt werden, einheitliche technische Standards des Meldeverfahrens festlegen zu können. […]“ (S.74, zu Nummer 11, zu § 14 Absatz 8 Satz 1 Nummer 2)

Verbunden mit der Anforderung, dass die Schnittstelle nach §291d SGB V genutzt werden soll, war damit auch die Änderung von „SOLL“ zu „MUSS“ bzgl. der Integration der Schnittstelle verbunden, weil das RKI nur vorhandene Schnittstellen nutzen kann.

Ergebnis

Die Schnittstelle muss – neben den anderen gesetzlichen Anforderungen – insbesondere
- Die Nutzung von Add-on/Plug-in-Programme ermöglichen
- Die Schnittstelle muss das Robert Koch-Institut in die Lage versetzen, einheitliche technische Standards des Meldeverfahrens festlegen zu können.

Insbesondere ist damit eine Abstimmung mit dem RKI erforderlich.

Rechtliche Anforderungen

Aus dem Gesetzestext und ggf. der dazugehörigen Begründung lassen sich folgende Anforderungen an diese Schnittstelle ableiten:

systemneutrale Archivierung von Patientendaten (Abs. 1 S.1)
Übertragung von Patientendaten bei einem Systemwechsel (Abs. 1 S.1)
Datenübermittlung entspr. Abs. 1a, d.h. Berücksichtigung
- von § 73 Abs. 9 SGB V, d. h.
- der Rechtsverordnung nach § 73 Abs. 9 S. 2SGB V
- § 14 Abs. 8 S. 1 des Infektionsschutzgesetzes
idealerweise berücksichtigen, dass künftige Rechtsverordnungen des Bundesministeriums für Gesundheit weitere Datenübermittllungen vorsehen (Abs. 1b), d.h. von Anfang an offene, erweiterbare sektorübergreifende Konzeption der Schnittstelle

Randbedingungen dazu

„Anbieter“ will der Gesetzgeber weit ausgelegt wissen; er umfasse sowohl Hersteller, Zwischenhändler als auch Lieferanten von informationstechnischen Systemen (BT-Drs. 18/5293, 53).
Offen und standardisierte Schnittstellen gefordert
- Hinweis: „Soweit Festlegungen der Absätze 2 bis 4 Inhalte berühren, zu denen es bereits Interoperabilitätsfestlegungen nach § 291e Abs. 7 S. 1 oder Referenzfestlegungen nach § 291e Abs. 9 S. 1 gibt, sollen diese berücksichtigt werden.“ (BT-Drs. 18/5293, 53)
Bestätigung, dass Implementierung in einem System den Anforderungen entspricht, vor Einsatz
- Hinweise:
  1. Bestätigung ist im Sinne eines Gütesiegels zu verstehen (BT-Drs. 18/5293, 53))
  2. Offenes und nachprüfbares Verfahren (indirekt aus der Forderung nach offenen und standardisierten Schnittstellen ableitbar) zur Beantragung und Erhalt einer Bestätigung wie auch Definition, wann Bestätigung verweigert wird, erforderlich.
Einvernehmen mit RKI herstellen (Abs. 1a S. 3 Hs. 2)
Festlegung ist in Benehmen mit der Gesellschaft für Telematik zu treffen
Festlegung ist in Benehmen mit den für die Wahrnehmung der Interessen der Industrie maßgeblichen Bundesverbänden aus dem Bereich der Informationstechnologie im Gesundheitswesen zu treffen
Veröffentlichung einer Liste mit bestätigten IT-Systemen
Bei inhaltlichen Gemeinsamkeiten sind sektorübergreifende einheitliche Vorgaben zu treffen
- Hinweis: inhaltliche Gemeinsamkeiten existieren durch § 291d Abs. 1a SGB V, daher ist Abstimmung zingend erforderlich.
Abstimmung mit RKI ist nicht explizit gefordert, aber durch Zielsetzung des Gesetzgebers gegeben.

Überlegungen zum Lösungsansatz

Als Lösungsanatz sollte auch ein Offline-Datenaustausch unterstützt werden, weil ein System ggf. nicht verfügbar bzw. die Systeme nicht online miteinander verbunden sind.

Damit bietet sich IHE ITI XDM an, weil XDM selbst keine direkten inhaltlichen Vorgaben macht, 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. Dazu kommen dann weitere Vorgaben zu den einzelnen genutzten Dateitypen, die im Technical Framework zu IT-I aufgelistet sind:

Vol.1, Kap.16
Vol.2b, Kap. 3.32
Vol.3, Kap. 4.3.1

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 andere Anforderungen an die Systeme als das nachfolgend beschriebene Verfahren, welches einen späteren Umstieg nach FHIR vorbereiten soll. Allerdings müssen bei FHIR Buld Data noch die aktuellen Entwicklungsschritte abgewartet werden. Dazu kommt, dass FHIR Bulk Data auf einen Export fokussiert ist und für den Import noch Zusatzanforderungen beschrieben werden müssen, um auch ein Offline-Verfahren zu unterstützen.

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, HL7 FHIR)
verwendet bereits vorhandene deutsche Profile (Arztbrief PLUS, FHIR-Basisprofilierung, ..) bzw. das, was vorhanden ist (Anm. die Profile werden derzeit noch weiterentwickelt und besitzen selbst keine Constraints, die für eine Interoperabilität notwendig wären.)
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 (s. Basisprofilierung)
Kurzfristig realisierbar (Spezifikation + Implementierung)
Einstieg in internationale Standards
- Förderung der Interoperabilität der Systeme

Struktur dieses Dokumentes

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, um so die Anforderungen bzw. Möglichkeiten der einzelnen Systeme besser kenntlich zu machen. Damit würden keine Änderungen an den Implementierungen einhergehen, es geht in erster Linie um eine Verbesserung der Dokumentation.

Außerdem gibt es ein 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)

Datenschutzaspekte gemäß EU-Verordnung und nationalem Recht und Verordnungen

Die folgenden Begriffsdefinitionen sind dem Kap. 3.5 Rechtliche Grundlagen in „Empfehlungen für den Einsatz elektronischer Signaturen und Zeitstempel in Versorgungseinrichtungen des Gesundheitswesens“, CCESigG, 2010^[4] entnommen und dienen zur Klarstellung der Einsatzoptionen.

Um die Rechtssicherheit eines elektronischen Dokumentes zu gewährleisten, müssen grundsätzliche Anforderungen erfüllt sein. Die elektronische Form muss den gesetzlichen Vorgaben wie z.B. einem Schriftformerfordernis entsprechen, um rechtsgemäß zu sein. Zudem sollen elektronische Dokumente keinen geringeren Beweiswert aufweisen, als unterschriebene Papierdokumente.

Des Weiteren ist zu beachten, dass die Ordnungsmäßigkeit der Dokumentation und Aufbewahrung entsprechend Handelsgesetzbuch (§ 239, § 257 HGB), Abgabenordnung (§ 146, § 147 AO) und den Grundsätzen ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) eingehalten wird. Demnach werden folgende funktionale Anforderungen im Rahmen der Beweissicherung an ein elektronisches Dokument über den Zeitraum der Aufbewahrung gestellt:

Erhalt der Authentizität: Die Aufbewahrung verfolgt in der Regel auch den Zweck, feststellen zu können, von wem das Dokument stammt (Urheber) [gekürzt].

Erhalt der Integrität: Es muss sichergestellt werden, dass ein Dokument nach der Signierung für die Dauer des Aufbewahrungszeitraumes nicht unbemerkt verändert wird.

Erhalt der Vollständigkeit: Soll der Gesamtzusammenhang mehrerer Dokumente (wie z.B. einer Patientenakte) erhalten bleiben, so muss der Erhalt der Vollständigkeit sichergestellt werden. Dies bedeutet z.B., dass einzelne Dokumente oder Teile eines Dokumentes nicht versehentlich gelöscht werden oder verloren gehen können (inkl. Datenverlust durch äußere Umstände).

Erhalt der Verkehrsfähigkeit: Das Dokument muss aus dem aufbewahrenden System entnommen bzw. versandt werden können, ohne dass der Beweiswert dadurch verringert wird. Integrität und Authentizität müssen für das jeweilige Dokument unabhängig von einem aufbewahrenden System nachweisbar sein.

Die folgenden Aspekte sind nicht Bestandteil dieser Spezifikation und müssen durch geeignete Maßnahmen sichergestellt werden.

Erhalt der Lesbarkeit: Ein Dokument muss jederzeit wieder lesbar gemacht werden können. Dies bedeutet, dass bei elektronischen Dokumenten die entsprechende Hard- und Software zur Präsentation der Dokumente zur Verfügung stehen muss.

Erhalt der Verfügbarkeit: Ein Dokument muss in angemessener Zeit auffindbar sein und lesbar zur Verfügung gestellt werden können.

Für Signaturen ist die eIDAS Verordnung (EU) Nr. 910/2014 maßgeblich und übersteuert nationales Recht in der EU, soweit die hier getroffen Regelungen abschließend sind (s.g. Siebmodell). Quelle: [eIDAS]^[5] - Verordnung (EU) Nr. 910/2014 des Europäischen Parlaments und des Rates vom 23. Juli 2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG.

eIDAS Begriffsbestimmungen zu Signaturen, Siegeln, Zeitstempeln und Evidence Records für diese Spezifikation siehe [eIDAS] Artikel 3 - Begriffsbestimmungen.

Die Rechtswirkung der eIDAS wird in den folgend zitierten Abschnitten der [eIDAS] geregelt:

ABSCHNITT 4: Elektronische Signaturen
ABSCHNITT 5: Elektronische Siegel
ABSCHNITT 6: Elektronische Zeitstempel
KAPITEL IV: ELEKTRONISCHE DOKUMENTE

Die Anhänge I bis III regeln die Anforderungen an qualifizierte Zertifikate für elektronische Signaturen, qualifizierte elektronische Signaturerstellungseinheiten und qualifizierte Zertifikate für elektronische Siegel.

Zusammenfassend sieht die eIDAS also Signaturen, Siegel, Zeitstempel und abgeleitete Evidence Records als probates Sicherungsmittel für die oben genannten Anforderungen an. Es werden zwei Sicherheitslevels (elektronisch, qualifiziert) für alle Versiegelungsarten definiert, die die Rechtswirkung und die Zulässigkeit als Beweismittel in Gerichtsverfahren bewirkt.

Für Signaturen und Siegel ist zu beachten, dass Sie eine Willenserklärung für die identifizierte natürliche oder juristische Person darstellen.

Zeitstempel und damit erstellte Evidence Records, die maßgeblich von der gesetzlich gültigen Zeit bestimmt werden (Dt. Zeitgesetz^[6]), sind eher als technische Transportsicherung und in elektronischen Archiven als langzeiterhaltendes Beweismittel im Einsatz also unabhängig von der Person (juristisch/natürlich).

Ergänzend zur eIDAS sollte auch die technische Richtlinie des BSI TR-ESOR^[7] für die langfristige Erhaltung der Beweiswerte und die Erhaltung der Verkehrsfähigkeit herangezogen werden, auch beim Transport von einem System/Medium zum Anderen (Manipulationsausschluss).

Sprachliche Regelungen

Anforderungen als Ausdruck normativer Festlegungen werden gemäß RFC 2119 in Großbuchstaben mit den Schlüsselworten MUSS, DARF NICHT, SOLL, SOLL NICHT sowie KANN gekennzeichnet.

Szenarien

Zur Erfüllung der Anforderungen gemäß eHealth-Gesetz (§291) müssen zwei Szenarien abgedeckt werden. (1) Das ist zum Einen die Möglichkeit, dass ein Arzt das von ihm genutzte System wechseln kann. (2) Zum Anderen müssen die Patientendaten systemneutral archiviert werden können. Über die Anwendungsfälle §291d hinaus gibt es zwei weitere Anwendungsfälle: (1) Ein Patient hat das Recht, seinen Arzt zu wechseln und dazu alle notwendigen Daten mitzunehmen (Arzt-Arzt Kommunikation) oder (2) 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.

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:

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.

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 basiert auf einer Profilierung von IHE ITI XDM und bietet somit die Möglichkeit einer Skalierung in mehrere Dimensionen, so dass klein angefangen, später aber mit zusätzlichen Details ergänzt werden kann. Dies betrifft auch den Umfang dieser Spezifikation, die in mehreren Schritten erweitert werden kann.

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.

Ausprägungen

Da die hier beschriebene Lösung unterschiedliche Szenarien unterstützt, ist anzugeben, welche Ausprägung realisiert worden sind:

Systemwechsel
- mit Stammdaten/Kataloge
Arztwechsel
Signatur
Verwendung von Ordnern
unterstützte Formate
- Dokumentformate
- FHIR-Ressourcen

Grobstruktur der Dateien für IHE ITI XDM

Neben ein paar Zusatzinformationen schreibt XDM primär eine Verzeichnisstruktur unter Nutzung von Metadaten vor. Die grobe Dateistruktur sieht für die oben skizzierten Use Cases dann wie folgt aus:

Media-Ebene

Das Medium wird gemäß nachfolgender Struktur aufgebaut. Dabei MÜSSEN mit "R" markierte Elemente vorhanden sein.


Dateistruktur	Inhalt	Dateiname	XDM-Optionalität	Profilierung
README.TXT	statische Readme-Datei	fix	R	R
INDEX.HTM	HTML-basierte Navigationsseite	fix	R	R
IHE_XDM	Hauptordner	fix	R	R
SUBSET01	Unterordner	max. 8 Großbuchstaben inkl. Ziffern und Unterstrich	optional	R
SUBSET02	Unterordner	max. 8 Großbuchstaben inkl. Ziffern und Unterstrich	optional	R
...	weitere Unterordner	max. 8 Großbuchstaben	optional	O
METADATA.XML	zusätzliche Metadatendatei; äquivalent zu METADATA.XML für die Ordner (von IHE erlaubt, aber derzeit nicht vorgesehen)	fix	-	neu: O
METADATA.PK7	Signaturdatei für METADATA.XML	fix	-	neu: O
OTHERDOC.DAT	sonstige Datei, von IHE erlaubt	max. 8+3 Großbuchstaben	optional	O

Hinweis: "neu" in der Spalte Profilierung ist ein Hinweis darauf, dass dieses Element im Originalprofil nicht vorkommt.

Ordner-Ebene

Jeder einzelne Ordner MUSS Inhalte gemäß folgender Tabelle besitzen:


Dateistruktur	Inhalt	Dateiname	XDM-Optionalität	Profilierung
SUBSET01	Unterordner mit Daten	max. 8 Großbuchstaben inkl. Ziffern und Unterstrich	R	R
METADATA.XML	Metadaten für alle in diesem Ordner enthaltene Dateien	fix	R	R
METADATA.PK7	Signaturdatei für METADATA.XML	fix	-	neu: O
*.PDF	PDF-Dokumente	max. 8 Großbuchstaben	optional	R
*.XML	CDA-Dokumente	max. 8 Großbuchstaben inkl. Ziffern und Unterstrich	optional	O
*.XML	FHIR-Ressourcen im XML-Format	max. 8 Großbuchstaben inkl. Ziffern und Unterstrich	optional	O
30px *.JSN	FHIR-Ressourcen im JSON-Format	max. 8 Großbuchstaben inkl. Ziffern und Unterstrich	optional	O
*.XML	andere XML-basierte Dokumente	max. 8 Großbuchstaben inkl. Ziffern und Unterstrich	optional	O
.JPG, .GIF, .TIF, .DCM	bildbasierte Formate bspw. für Scans	max. 8 Großbuchstaben inkl. Ziffern und Unterstrich	optional	O
*.PK7	Signaturdatei für andere Datei gleichen Namens	8 Großbuchstaben inkl. Ziffern und Unterstrich	-	O

"fixe" Hauptdateien

XDM sieht vor, dass ein paar Dateien vorhanden sein MÜSSEN, deren Inhalte können jedoch variieren. 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. Hier MÜSSEN die entsprechenden Hersteller- und Kundenangaben angeben werden.

INDEX.HTM

Die INDEX.HTM Datei MUSS individuell für das zu erstellende Medium erzeugt werden 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/>
Geburtsdatum:<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. Welche Links mit welchem Text konkret enthalten sind, KANN von dem Hersteller in geeigneter Form für den jeweiligen Use Case bestimmt werden.

METADATA.XML

Die Metadatendatei im Subordner MUSS vorhanden sein und beinhaltet alle notwendigen Metadaten für alle auf dem Medium vorhandenen Dateien. (Vgl. Beispiel im Anhang)

Struktur

Die hierarchische Struktur der Metadaten-Datei sieht vereinfacht wie folgt aus:

SubmitObjectsRequest (1-mal)
- RegistryObjectList (1-mal für das Submission Set)
  - RegistryPackage (1-mal für das Submission Set)
    - @id
    - @status
    - Slot (s.u.)
    - Name
      - LocalizedString
        @charset
        
        @value
    - VersionInfo
      - @versionName
    - Classification
      - Slot (s.u.)
      - Name
    - ExternalIdentifier
      - Name
  - ExtrinsicObject (n-mal, d.h. für jedes Dokument einmal)
    - @id
    - @objectType
    - @mimeType
    - @status
    - Slot (s.u.)
  - Association (n-mal für jede Assoziation)
  - RegistryPackage (n-mal für jeden Folder)

Jeder Slot besitzt folgenden Aufbau:

Slot
- @name
- ValueList
  - Value

Die konkreten Ausprägungen für den jeweiligen Slot sind in den Tabellen unter "Attribute" zu entnehmen.

Bei der Instanziierung dieser Struktur in METADATA.xml sind die Namespaces zu beachten, die hier der Einfachheit halber weggelassen wurden.

Attribute

Die Metadaten MÜSSEN gemäß nachfolgender Aufstellung bereitgestellt werden. Hierbei ist die Optionalitätsangabe zu beachten, d.h. nicht alle Attribute müssen angegeben werden. Die Tabellen enthalten alle Attribute, die gemäß IHE ITI XDM vorgesehen sind. Optionale Attribute KÖNNEN genutzt werden. Die mit "R2" gekennzeichneten Attribute MÜSSEN entsprechend dem Use Case bereitgestellt werden.

für Dokumente (ExtrinsicObject)


Attribut	Repräsentation	Inhalt	Kommentar	Optionalität	Datentyp	Beispiel
author	Slot	Autor der Datei: authorRole authorSpecialty	Der Autor sollte nur angegeben werden, wenn er - wie bei einem ganz bestimmten Dokument - genau identifiziert werden kann.	R2
availabilityStatus	Slot	Verfügbarkeit		O
classCode	via Classification	classCode	(TF-3:4.2.3.2.3)	R2
comments	Description	Kommentare	beliebige ergänzende Informationen (TF-3:4.2.3.2.4)	O	ST
confidentialityCode	Classification	Vertaulichkeit: confidentialityCode	wiederholbares Feld, für: Confidentiality [1..1], Sensitivity [0..], Compartment [0..], Integrity [0..], Handling [0..] (TF-3:4.2.3.2.5)	R2	URN
creationTime	Slot	Erzeugungsdatum der Datei		R2	TS	20110119154305
entryUUID	ExtrinsicObject (id)	eindeutige ID		R
eventCodeList	Classification	eventCodeList		O
formatCode	Classification	Dateiformat: formatCode		R2	CE
hash	Slot	Hashwert der Datei	über den Hashwert des Dokumentes lässt sich eine Signatur aufbringen Anm.: SHA1 ist aktuell nicht mehr zulässig, muss aber aus Kompatibilitätsgründen weiter gefüllt werden.	R	INT	f5eb92f4ee4e9e9426 db8b75eaaf8f8745512964
hashValue	Slot	Hashwert der Datei	über den Hashwert des Dokumentes über das in hashAlgorithm hinterlegte Verfahren	neu: R2	INT	f5eb92f4ee4e9e9426 db8b75eaaf8f8745512964
hashAlgorithm	Slot	Hashalgorithmus	der für den Hashwert genutzte Algorithmus; Empfehlung SHA256 oder SHA512	neu: R2	ST	SHA256
healthcareFacilityTypeCode	Classification	healthcareFacilityTypeCode		R2	CE
homeCommunityId	ExtrinsicObject (home)			O
languageCode	Slot	Sprachkennzeichen	in welcher Sprache wurde der Inhalt des Objectes verfasst? Das bietet sich primär für Dokumente an.	R2	CE	DE
legalAuthenticator	Slot			O
limitedMetadata	Slot			O
mimeType	ExtrinsicObject (mimeType)	mimeType		R	ID	application/pdf
objectType	ExtrinsicObject (objectType)			R	URN	urn:uuid: 7edca82f-054d-47f2-a032-9b2a5b5186c1
patientID	ext. ID	Identifikation des Patienten in dieser Affinity Domain		R2	CX
practiceSettingCode	Classification	practiceSettingCode		R2
referenceIdList	Slot			O
repositoryUniqueId	Slot			O
serviceStartTime	Slot	Startzeitpunkt, wann begonnen wurde die Informationen zu dokumentieren.	Diese Information bietet sich nur für Informationen an, die Dokumenten entsprechen und wo diese Information klar nachvollziehbar sind. Für Informationen, die über einen längeren Zeitraum nach und nach erfasst wurden (wie bspw. die Patient Ressource) erübrigt sich das.	R2	TS	20170123143145
serviceStopTime	Slot	Stopzeitpunkt, wann die Erfassung der Informationen beendet wurden.	dto.	R2	TS	20170123143145
size	Slot	Größe der Datei	Angabe in Bytes	R	INT	17075
sourcePatientId	Slot	Identifikation des Patienten	ID des Patienten, so wie sie im originären Record enthalten ist. Da dieses Feld nur "R2" ist, sollte überlegt werden, es nicht zu füllen, da hier eine HL7v2-typische Repräsentation genutzt wird, die eine Implementierung erschwert.	R2	HD	8955^^^&1.2.276.0.76.3.1.260&ISO
sourcePatientInfo	Slot	weitere Informationen über den Patienten (Nutzung über HL7 v2.x Segmente und Datentypen)	Die Information entspricht den verschiedenen Feldern des PID-Segments und werden in einzelnen Wiederholungen von "value" in der valuelist repräsentiert. Da dieses Feld nur "R2" ist, sollte überlegt werden, es nicht zu füllen, da hier eine HL7v2-typische Repräsentation genutzt wird, die eine Implementierung erschwert.	R2	XPN	8955^^^&1.2.276.0.76.3.1.260&ISO PID-5\|Schmidt^Stefan PID-7\|19850623 PID-8\|M
title	Name	Titel des Dokuments		C
typeCode	Slot	typeCode		R
uniqueId	ext. ID	eindeutige ID		R
URI	Slot	Name der Datei	Name, so wie sie auf dem Medium vorhanden ist.	R	8+3	DOC1.XML

Die Attribute hashValue und hashAlgorithm sind NICHT Bestandteil der offiziellen XDS/XDM-Spezifikation. Das dort vorgeschlagene Verfahren SHA1 ist seit 2017 nachweislich nicht mehr kollisionssicher. Laut Aussage ITI ist trotzdem nicht babsichtigt, hier eine Aktualisierung vorzunehmen, da eine Kombination aus size/hash eine Veränderung des Dokumentes zuverlässig erkennen lässt. Ein Change Proposal für XDS/XDM ist deshalb separat zu überlegen.

für Submission Set (ExtrinsicObject)


Attribut	Repräsentation	Inhalt	Kommentar	Optionalität	Datentyp	Beispiel
author	Slot	Autor der Datei: authorRole authorSpecialty	Der Autor sollte nur angegeben werden, wenn er - wie bei einem ganz bestimmten Dokument - genau identifiziert werden kann.	R2	UUID
availabilityStatus	Attribut (status)	Verfügbarkeit	als URN	O	URN
comments	Slot	Kommentare		O	ST
contentTypeCode	Slot			R2	CE
entryUUID	ExtrinsicObject	eindeutige ID		R
intendedRecipient	Slot			R2
limitedMetadata	Slot			O
patientId	ext. ID			R2
sourceId	ext. ID			R	URN
submissionTime	Slot	Übermittlungsdatum der Datei		R	TS	20110119154305
title	Slot	Titel des Dokuments		O	ST
uniqueId	ext. ID	eindeutige Identifikation für das Dokument		R

für Folder (ExtrinsicObject)

Für einen einfachen Datenaustausch ist die Nutzung von Ordnern nicht notwendig.


Attribut	Repräsentation	Inhalt	Kommentar	Optionalität	Datentyp
availabilityStatus	Attribut (status)	Verfügbarkeit	als URN	O
codelist	Slot	Liste an Codes, vgl. Cookbook: codeList		R2
comments	Dscription	Kommentare		O	ST
entryUUID	ExtrinsicObject	eindeutige ID		R
homeCommunityId	ExtrinsicObject			O
lastUpdateTime	Slot			O	TS
limitedMetadata	Slot			O
patientId	ext. ID			R2
title	Slot	Titel des Dokuments		O	ST
uniqueId	ext. ID	eindeutige ID für den Ordner		R

ValueSets

Die Value Sets ergeben sich aus dem IHE Value Set Projekt: http://art-decor.org/art-decor/decor-project--ihede-:

Namenskonvention für die Dateinamen

Die Namen aller Dateien MÜSSEN in der "alten" 8+3-Konvention mit Großbuchstaben erstellt werden. Ordner MÜSSEN mit 8 Großbuchstaben ausgezeichnet werden. Für eine korrekte Abarbeitung MÜSSEN die Dateinamen so gewählt werden, dass sie alphabetisch sortiert werden können und gemäß dieser Sortierreihenfolge abgearbeitet werden können. Das gilt auch für Ordner.

Umsetzung der Use Cases

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.


	Use Cases
Inhalt	Systemwechsel	Arztwechsel	Konsil	..
Stammdaten	R [1..*]	O	O
Kataloge	R [1..*]	O	O
Patient	R [1..*]	O [0..1]	[0..1]
Fall/Aufenthalt	R [1..*]	O [0..1]	O [0..1]
Diagnosen	O	O	R2
Medikation	O	O	R2
Maßnahmen	O	O	R2
Versichertendaten	R	R	O
Dokumente	R	R	R
..

Signatur – Zeitstempel – Evidence Record

Die Repräsentation der Daten in Form von Dateien in dieser Spezifikation bieten eine einfache Signaturmöglichkeit. Alternativ kann auch ein Siegel, Zeitstempel oder Evidence Record aufgebracht werden. SIGNATUR wird im Folgenden als Synonym für die hier angegebenen Signaturverfahren verwendet, wenn dies nicht ausdrücklich anders bezeichnet wird.

Die folgende Tabelle gibt einen Überblick auf die Erfüllung der o.g. funktionalen Anforderungen und technische Aspekte bei der Umsetzung:


Funktionale Anforderungen	Signatur	Siegel	Zeitstempel (ZS)	Evidence Record (ERS)
Authentizität	Natürliche Person	Juristische Person	Keine	Keine
Integrität	Willensakt	Willensakt	Gesetzliche Zeit	Gesetzliche Zeit
Vollständigkeit	Keine	Keine	Keine	Gegeben
Verkehrsfähigkeit	In Verbindung mit ZS/ERS	In Verbindung mit ZS/ERS	Gegeben	Gegeben
Technische Aspekte	Signatur	Siegel	Zeitstempel (ZS)	Evidence Record (ERS)
Gültigkeit	2-3 Jahre	2-3 Jahre	ca. 5 - 10 Jahre	Jahrzehnte
abhängig von	Zertifikatdauer	Zertifikatdauer	Sicherheitseignung des ZS	Wie ZS + kryptographische Stärke des HashAlgoritmus
Verfahrensart	Einzel/Stapel	Einzel/Stapel	Einzel	Einzel/Stapel/Warteschlange
Client Software notwendig	Ja	Ja	Per API	(RFC 3161)	Per API	(RFC 4998)
WebService	Fernsignatur	Fernsiegel	REST	REST
Verschlußdauer	RSA2k 2 sec RSA4k 4 sec	RSA2k 2 sec RSA4k 4 sec	RSA2k 2 sec RSA4k 4 sec ECC# 0,5 sec	Zeit wie bei ZS jedoch im Stapel nur 1x notwendig d.h. für z.B. 1.000 Dokumente 1/tsd. durchschnittlich
Nameskonvention METADATA.[SIG ]	.PK7	.PK7	.TS	.ERS

Einzelsignatur

Individuell für einzelne Dateien: Diese kann parallel zu der zu signierenden Datei (gleicher Basisdateiname und [SIG] siehe Tabelle oben) abgelegt werden. In diesem Fall wird davon ausgegangen, dass es sich um die Bestätigung für den Inhalt handelt und dann von der Person vorgenommen wird, die für den Inhalt verantwortlich ist. Überlicherweise muss eine derartige Signatur bereits vor dem Export, d.h. bei der Erstellung, vorgenommen werden.

Einsatz von

Signaturen/Siegel für Willensakte der Person/Institution und
Zeitstempel/Evidence Records für Transportsicherung, Langzeitspeicherung

Stapelsignatur

Im Falle von Stapelsignaturen wird von den Metadatendateien (METADATA.XML) Gebrauch gemacht. Dafür sind für alle betroffenen, d.h. zu signierenden Dateien die entsprechenden Hashwerte zu berechnen und im Attribut „hashValue“ (neu) abzulegen. Als Hash-Algorithmen werden die in der SOGIS-Agreed-Cryptographic-Mechanisms in der aktuellen Version (2016 https://www.sogis.org/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.0.pdf, 2.3 Hash Functions) verwendet und im Attribut „hashAlgo“ das verwendete Hash-Verfahren notiert, z.B.“SHA-256“.

Hinweis: Erweiterung/Änderung der Attribute in der METADATA.XML von „hash“ auf „hashValue“ und „hashAlgo“.

Als Hashverfahren muss lt. XDM SHA1 verwendet werden, welches aber seit 2017 offiziell nicht mehr zulässig ist.

Die Signatur wird auf die Metadatendatei angewendet und parallel (gleicher Basisdateiname und [SIG] siehe Tabelle oben) zu dieser abgelegt.

Weiterhin wird empfohlen einen „Aktendeckel“ je Transportpaket als METADATA.XML auf der obersten Ordnerebene (root) zu schreiben, der auf die METADATA.XML in den SUBFOLDERN referenziert und das Transportpaket vollständig absichert.

Struktur der METADATA.XML:

SUBSET01 <HASH über SUBSET01 METADATA>

SUBSET02 <HASH über SUBSET02 METADATA>

...

SUBSET#n <HASH über SUBSET#n METADATA>

Signaturen/Siegel für Willensakte

Zeitstempel/Evidence Records für Transportsicherung, Langzeitspeicherung

Inhalte

Dieser Abschnitt kann als nationale Extension zu XDM aufgefasst werden!

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-Ressourcen 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. Alternativ KÖNNEN auch Links auf extern gespeicherten Medien verwendet 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:

ArztbriefPlus: http://wiki.hl7.de/index.php?title=Arztbrief_2016_(Projekt)
Arztbrief 2014/15: http://download.hl7.de/documents/cdar2-arztbrief/Arztbrief2014-v100.pdf
Entlassbrief: http://wiki.hl7.de/index.php?title=Entlassmanagement_(Projekt)
Ein-/Überweisung
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
- Laboranforderung: http://wiki.hl7.de/index.php?title=IG:Laboranforderung
- Anforderung von Krankentransporten
ePflegebericht: http://wiki.hl7.de/index.php?title=EPflegebericht_(Projekt)
eWundbericht: 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)
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
außerklinische Beatmung: http://wiki.hl7.de/index.php?title=Au%C3%9Ferklinische_Beatmung_(Projekt)
..

FHIR

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. (HL7 v2.x ist allerdings nur im stationären Umfeld verbreitet.) Mit dem immer stärkeren Aufkommen von FHIR wird davon aber Abstand genommen.

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) MÜSSEN diese Profile eingehalten werden:

Grundlegende Informationen zur Nutzung von FHIR-Profilen sind hier zu finden:

Darüber hinaus MÜSSEN die auf fhir.hl7.org beschriebenen Grundlagen eingehalten werden.

Ressourcen

Die folgende Tabelle zeigt eine initiale Liste, die je nach Anforderung ergänzt oder präzisiert werden kann.


Ressource	Inhalt	Link	Beispiele
administrativ
Patient	demographische Daten	http://fhir.de/StructureDefinition/patient-de-basis, http://hl7.org/implement/standards/fhir/patient-extensions.html	https://simplifier.net/BasisprofilDE/Patient-example
Encounter	Falldaten	http://hl7.org/implement/standards/fhir/encounter.html, http://hl7.org/implement/standards/fhir/encounter-extensions.html
EpisodeOfCare	Fallinformationen	http://hl7.org/implement/standards/fhir/episodeofcare.html
Person	Personen	http://hl7.org/implement/standards/fhir/person.html
RelatedPerson	Bezugspersonen	http://hl7.org/implement/standards/fhir/relatedperson.html
...
klinisch
Condition	(aka Problem)	http://hl7.org/implement/standards/fhir/condition.html, https://simplifier.net/BasisprofilDE/condition-de-basis
Observation	Beobachtungen, Meßwerte und Befunde	http://hl7.org/implement/standards/fhir/observation-extensions.html
Procedure	Maßnahmen	http://hl7.org/implement/standards/fhir/procedure.html, http://hl7.org/implement/standards/fhir/procedure-extensions.html
Medication	Medikament	http://hl7.org/implement/standards/fhir/medication.html
MedicationStatement	Medikation (eines Patienten)	http://hl7.org/implement/standards/fhir/medicationstatement.html
AllergyIntolerance	Allergien und Unverträglichkeiten	http://hl7.org/implement/standards/fhir/allergyintolerance.html
Goal	Vorgaben	http://hl7.org/implement/standards/fhir/goal.html
FamilyMemberHistory	Familienanamnese	http://hl7.org/implement/standards/fhir/familymemberhistory.html
Substance	Substanz	http://hl7.org/implement/standards/fhir/substance.html
Questionnaire	Fragebogen	http://hl7.org/implement/standards/fhir/questionnaire.html
QuestionnaireResponse	ausgefüllter Fragebogen	http://hl7.org/implement/standards/fhir/questionnaireresponse.html
...
finanziell
Account	Konto	http://hl7.org/implement/standards/fhir/acoount.html
Claim		http://hl7.org/implement/standards/fhir/claim.html
ClaimResponse		http://hl7.org/implement/standards/fhir/claimresponse.html
Coverage	Versicherungsinformationen	http://fhir.de/StructureDefinition/coverage-de-basis, https://simplifier.net/BasisprofilDE/coverage-de-gkv, https://simplifier.net/BasisprofilDE/coverage-de-sel
...
organisatorisch
Practitioner	Ärzte	http://hl7.org/implement/standards/fhir/practitioner.html
PractitionerRole	Rolle/Funktion für Ärzte	http://hl7.org/implement/standards/fhir/practitionerrole.html
Organization	Organisationen	http://fhir.de/StructureDefinition/organization-de-basis, https://simplifier.net/BasisprofilDE/organization-de-basis
CareTeam	ärztliches Team, Pflegeteam	http://hl7.org/implement/standards/fhir/careteam.html
...
technisch
CodeSystem	Codesystem	http://hl7.org/implement/standards/fhir/codesystem.html
ValueSet	Value Set (Menge an Codes)	http://hl7.org/implement/standards/fhir/valueset.html
...
Sonstige
...

Datentypen

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


Datentyp	Inhalt	Link	Beispiele
komplex
HumanName	Name einer Person	https://simplifier.net/BasisprofilDE/humanname-de-basis	https://simplifier.net/BasisprofilDE/Example-patient-de-basis-humanname-komplex
Address	Adresse	https://simplifier.net/BasisprofilDE/address-de-basis
CodeableConcept	kodierte Informationen (komplex)	http://hl7.org/implement/standards/fhir/datatypes.html#CodeableConcept	erlaubt auch die Eingabe von Freitext
Identifier	Identifikatoren	https://www.hl7.org/fhir/datatypes.html#identifier	s.a. Namensräume
Reference	Referenzen auf andere Ressourcen	http://hl7.org/implement/standards/fhir/references.html
ContactPoint	Kontaktinformationen (Telefon, eMail, ..)	http://hl7.org/implement/standards/fhir/datatypes.html#ContactPoint
..	..	..
einfach
boolean	Boolesche Werte	http://hl7.org/implement/standards/fhir/datatypes.html#boolean
integer	Zahlen	https://www.hl7.org/fhir/datatypes.html#integer
unsignedInt	vorzeichenlose Integerwerte	http://hl7.org/implement/standards/fhir/datatypes.html#unsignedInt
string	Zeichenketten	http://hl7.org/implement/standards/fhir/datatypes.html#string
code	kodierte Information (einfach)	http://hl7.org/implement/standards/fhir/datatypes.html#code
..	..	..

Codesysteme

Weitere Kodesysteme sind auf simplifier.net zu finden.

ValueSets

tbd

Transaktionen

Da die Ressourcen auf ein Medium geschrieben bzw. von dort gelesen werden, wird FHIR nur in Form eines Persistenzformats eingesetzt und daher sind keine expliziten Transaktionen (create, read, ..) zu unterstützen.

Encoding

Als Encoding wird XML und JSON zugelassen. Das jeweils verwendete Format wird in den Metadateien hinterlegt. In dem Capability-Statement der Software ist jedoch anzugeben, welches Encoding unterstützt wird. Da ein Server typischerweise beide Formate zu unterstützen hat, muss beim Erstellen angegeben werden können, welches Encoding gewünscht ist, damit der potientielle Client die Daten auch wieder einlesen kann.

Sonstige Angaben

Verschlüsselung

Eine Verschlüsselung des Mediums ist über gängige Verfahren wie ZIP möglich, dies ist aber nicht Bestandteil dieser Spezifikation.

Transportmöglichkeiten

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

Bei Cloud Speichern sollte zukünftig das in der eIDAS definierte ASIC Container Signatur Verfahren verwendet werden.

Darüber hinaus besteht die Möglichkeit, die Inhalte - insbesondere wenn die Datenmenge nicht allzugroß ist - auch per eMail zu verschicken.

Security

Es wird davon ausgegangen, dass das Erstellen des Mediums in einem entsprechenden Kontext von berechtigten Personen vorgenommen wird und deshalb nur die dafür vorgesehenen Vorkehrungen getroffen werden müssen.

Anhang

Beispiel für eine METADATA.XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:SubmitObjectsRequest xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">
    <RegistryObjectList>
        <RegistryPackage status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750">
            <Slot name="submissionTime">
                <ValueList>
                    <Value>20180424111239</Value>
                </ValueList>
            </Slot>
            <VersionInfo/>
            <Classification classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" nodeRepresentation="22232009" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:06acf13b-40cd-48f2-b9dd-4f7a45d56b2b">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>2.16.840.1.113883.6.96</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="Hospital"/>
                </Name>
            </Classification>
            <Classification classifiedObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:f4104572-6006-470e-88da-50011065232a"/>
            <ExternalIdentifier registryObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446" value="8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO" id="urn:uuid:849a6d34-0513-4d6e-a2bc-9b33195ec652">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSSubmissionSet.patientId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier registryObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832" value="1.2.276.0.76.3.1.260" id="urn:uuid:469c6ea5-0d5a-423d-8b77-f8143471b31d">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSSubmissionSet.sourceId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier registryObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" value="1.2.276.0.76.3.1.260.1.0.56.172031037100.1524561159234" id="urn:uuid:722991fc-3ce5-4a81-9d3c-28461517f932">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSSubmissionSet.uniqueId"/>
                </Name>
            </ExternalIdentifier>
        </RegistryPackage>
        <ExtrinsicObject mimeType="text/xml" lid="cffedcb1-3deb-4660-892d-e1475fbea575" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="cffedcb1-3deb-4660-892d-e1475fbea575">
            <Slot name="hash">
                <ValueList>
                    <Value>f5eb92f4ee4e9e9426db8b75eaaf8f8745512964</Value>
                </ValueList>
            </Slot>
            <Slot name="size">
                <ValueList>
                    <Value>17075</Value>
                </ValueList>
            </Slot>
            <Slot name="creationTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="languageCode">
                <ValueList>
                    <Value>DE</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStartTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStopTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="URI">
                <ValueList>
                    <Value>DOC1.XML</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientId">
                <ValueList>
                    <Value>8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientInfo">
                <ValueList>
                    <Value>PID-3|8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO</Value>
                    <Value>PID-5|Schmidt^Stefan</Value>
                    <Value>PID-7|19850623</Value>
                    <Value>PID-8|M</Value>
                </ValueList>
            </Slot>
            <Name>
                <LocalizedString charset="windows-1252" value="FHIR Substance"/>
            </Name>
            <VersionInfo versionName="1"/>
            <Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="cffedcb1-3deb-4660-892d-e1475fbea575" nodeRepresentation="urn:ihe-d:mime" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:df4e60cc-424e-4834-ad6b-e6208b9b9cfa">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>1.3.6.1.4.1.19376.3.276.1.5.6</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="durch Mime Type beschrieben"/>
                </Name>
            </Classification>
            <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="cffedcb1-3deb-4660-892d-e1475fbea575" nodeRepresentation="KHS" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:e5b7f012-b484-4f00-8e53-f5c13f16dbce">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>1.3.6.1.4.1.19376.3.276.1.5.2</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="Krankenhaus"/>
                </Name>
            </Classification>
            <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="cffedcb1-3deb-4660-892d-e1475fbea575" nodeRepresentation="N" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:c3d87ee5-6380-437f-b3b7-fc66fb5ce39f">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>2.16.840.1.113883.5.25</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="normal"/>
                </Name>
            </Classification>
            <ExternalIdentifier registryObject="cffedcb1-3deb-4660-892d-e1475fbea575" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO" id="urn:uuid:8dc217b0-0918-4846-be05-16cd97e6aef9">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSDocumentEntry.patientId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier registryObject="cffedcb1-3deb-4660-892d-e1475fbea575" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="f62034ec-014b-5fd2-afc0-c894c7f1490e" id="urn:uuid:fa62e16c-101a-4642-828c-e17373494e05">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSDocumentEntry.uniqueId"/>
                </Name>
            </ExternalIdentifier>
        </ExtrinsicObject>
        <ExtrinsicObject mimeType="text/xml" lid="8ddd1ac9-27d3-4774-bc4c-8c5f07e5b376" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="8ddd1ac9-27d3-4774-bc4c-8c5f07e5b376">
            <Slot name="hash">
                <ValueList>
                    <Value>f5eb92f4ee4e9e9426db8b75eaaf8f8745512964</Value>
                </ValueList>
            </Slot>
            <Slot name="size">
                <ValueList>
                    <Value>17075</Value>
                </ValueList>
            </Slot>
            <Slot name="creationTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="languageCode">
                <ValueList>
                    <Value>DE</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStartTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStopTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="URI">
                <ValueList>
                    <Value>DOC2.XML</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientId">
                <ValueList>
                    <Value>8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientInfo">
                <ValueList>
                    <Value>PID-3|8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO</Value>
                    <Value>PID-5|Schmidt^Stefan</Value>
                    <Value>PID-7|19850623</Value>
                    <Value>PID-8|M</Value>
                </ValueList>
            </Slot>
            <Name>
                <LocalizedString charset="windows-1252" value="FHIR Patient"/>
            </Name>
            <VersionInfo versionName="1"/>
            <Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="8ddd1ac9-27d3-4774-bc4c-8c5f07e5b376" nodeRepresentation="urn:ihe-d:mime" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classiffication" id="urn:uuid:41dc5122-e5c6-4b01-b5a1-7f667de45de9">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>1.3.6.1.4.1.19376.3.276.1.5.6</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="durch Mime Type beschrieben"/>
                </Name>
            </Classification>
            <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="8ddd1ac9-27d3-4774-bc4c-8c5f07e5b376" nodeRepresentation="KHS" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:f62b946a-60d9-461e-b4ea-3bf8e9f7b00e">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>1.3.6.1.4.1.19376.3.276.1.5.2</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="Krankenhaus"/>
                </Name>
            </Classification>
            <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="8ddd1ac9-27d3-4774-bc4c-8c5f07e5b376" nodeRepresentation="N" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:261eed12-c0d0-4339-94df-c689d5bdee7a">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>2.16.840.1.113883.5.25</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="normal"/>
                </Name>
            </Classification>
            <ExternalIdentifier registryObject="8ddd1ac9-27d3-4774-bc4c-8c5f07e5b376" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO" id="urn:uuid:ff542fba-ec70-4324-9524-e187b96fee3b">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSDocumentEntry.patientId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier registryObject="8ddd1ac9-27d3-4774-bc4c-8c5f07e5b376" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="f62034e9-004b-4fd2-afc0-c894c7f1490e" id="urn:uuid:d67c96f2-b7b4-449b-b09c-41aeaa357e75">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSDocumentEntry.uniqueId"/>
                </Name>
            </ExternalIdentifier>
        </ExtrinsicObject>
        <ExtrinsicObject mimeType="text/xml" lid="3e39304f-f7e3-4d37-b5a5-c00a73684e92" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="3e39304f-f7e3-4d37-b5a5-c00a73684e92">
            <Slot name="hash">
                <ValueList>
                    <Value>f5eb92f4ee4e9e9426db8b75eaaf8f8745512964</Value>
                </ValueList>
            </Slot>
            <Slot name="size">
                <ValueList>
                    <Value>17075</Value>
                </ValueList>
            </Slot>
            <Slot name="creationTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="languageCode">
                <ValueList>
                    <Value>DE</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStartTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStopTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="URI">
                <ValueList>
                    <Value>DOC3.XML</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientId">
                <ValueList>
                    <Value>8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientInfo">
                <ValueList>
                    <Value>PID-3|8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO</Value>
                    <Value>PID-5|Schmidt^Stefan</Value>
                    <Value>PID-7|19850623</Value>
                    <Value>PID-8|M</Value>
                </ValueList>
            </Slot>
            <Name>
                <LocalizedString charset="windows-1252" value="FHIR Encounter"/>
            </Name>
            <VersionInfo versionName="1"/>
            <Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="3e39304f-f7e3-4d37-b5a5-c00a73684e92" nodeRepresentation="urn:ihe-d:mime" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:012e1c06-cb4b-45f4-a5c0-0988fbe669d0">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>1.3.6.1.4.1.19376.3.276.1.5.6</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="durch Mime Type beschrieben"/>
                </Name>
            </Classification>
            <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="3e39304f-f7e3-4d37-b5a5-c00a73684e92" nodeRepresentation="KHS" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:f2957e1e-cc47-4c4d-a730-00781360b620">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>1.3.6.1.4.1.19376.3.276.1.5.2</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="Krankenhaus"/>
                </Name>
            </Classification>
            <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="3e39304f-f7e3-4d37-b5a5-c00a73684e92" nodeRepresentation="N" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:ee32ad82-8fec-4be3-bbe0-bc69e1e2efe9">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>2.16.840.1.113883.5.25</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="normal"/>
                </Name>
            </Classification>
            <ExternalIdentifier registryObject="3e39304f-f7e3-4d37-b5a5-c00a73684e92" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO" id="urn:uuid:93f56c7c-358f-44b6-9718-de6aee1d7140">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSDocumentEntry.patientId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier registryObject="3e39304f-f7e3-4d37-b5a5-c00a73684e92" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="f62034ec-004b-4fd2-afc0-c894c7f1490e" id="urn:uuid:1cc6c752-cb48-440e-b013-5de28359d915">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSDocumentEntry.uniqueId"/>
                </Name>
            </ExternalIdentifier>
        </ExtrinsicObject>
        <ExtrinsicObject mimeType="text/xml" lid="64af6991-f020-41fe-824a-4904b04e57ee" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="64af6991-f020-41fe-824a-4904b04e57ee">
            <Slot name="hash">
                <ValueList>
                    <Value>f5eb92f4ee4e9e9426db8b75eaaf8f8745512964</Value>
                </ValueList>
            </Slot>
            <Slot name="size">
                <ValueList>
                    <Value>17075</Value>
                </ValueList>
            </Slot>
            <Slot name="creationTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="languageCode">
                <ValueList>
                    <Value>DE</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStartTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStopTime">
                <ValueList>
                    <Value>20170123143145</Value>
                </ValueList>
            </Slot>
            <Slot name="URI">
                <ValueList>
                    <Value>DOC4.XML</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientId">
                <ValueList>
                    <Value>8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientInfo">
                <ValueList>
                    <Value>PID-3|8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO</Value>
                    <Value>PID-5|Schmidt^Stefan</Value>
                    <Value>PID-7|19850623</Value>
                    <Value>PID-8|M</Value>
                </ValueList>
            </Slot>
            <Name>
                <LocalizedString charset="windows-1252" value="FHIR Practitioner"/>
            </Name>
            <VersionInfo versionName="1"/>
            <Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="64af6991-f020-41fe-824a-4904b04e57ee" nodeRepresentation="urn:ihe-d:mime" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:be65c34b-ac76-4ac4-a0bd-35255a4ffc94">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>1.3.6.1.4.1.19376.3.276.1.5.6</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="durch Mime Type beschrieben"/>
                </Name>
            </Classification>
            <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="64af6991-f020-41fe-824a-4904b04e57ee" nodeRepresentation="KHS" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:faceee84-b88d-42cc-a9f7-5c6d9b082098">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>1.3.6.1.4.1.19376.3.276.1.5.2</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="Krankenhaus"/>
                </Name>
            </Classification>
            <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="64af6991-f020-41fe-824a-4904b04e57ee" nodeRepresentation="N" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="urn:uuid:cc9bd3b6-3943-436f-a7e9-7b0f9814fac4">
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>2.16.840.1.113883.5.25</Value>
                    </ValueList>
                </Slot>
                <Name>
                    <LocalizedString charset="windows-1252" value="normal"/>
                </Name>
            </Classification>
            <ExternalIdentifier registryObject="64af6991-f020-41fe-824a-4904b04e57ee" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="8955^^^&amp;1.2.276.0.76.3.1.260&amp;ISO" id="urn:uuid:d4cfb2e4-a18f-419d-bb7a-a1637683705c">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSDocumentEntry.patientId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier registryObject="64af6991-f020-41fe-824a-4904b04e57ee" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="f72034ec-004b-5fd2-afc0-c894c7f1490e" id="urn:uuid:deefcb6c-00dc-4b21-ab97-a316567c2956">
                <Name>
                    <LocalizedString charset="windows-1252" value="XDSDocumentEntry.uniqueId"/>
                </Name>
            </ExternalIdentifier>
        </ExtrinsicObject>
        <Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" sourceObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" targetObject="cffedcb1-3deb-4660-892d-e1475fbea575" id="urn:uuid:c5102f81-5498-47ba-8418-5e690c6dd723">
            <Slot name="SubmissionSetStatus">
                <ValueList>
                    <Value>Original</Value>
                </ValueList>
            </Slot>
        </Association>
        <Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" sourceObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" targetObject="8ddd1ac9-27d3-4774-bc4c-8c5f07e5b376" id="urn:uuid:2fee4ee0-002f-4222-a60c-6f72f6a333bc">
            <Slot name="SubmissionSetStatus">
                <ValueList>
                    <Value>Original</Value>
                </ValueList>
            </Slot>
        </Association>
        <Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" sourceObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" targetObject="3e39304f-f7e3-4d37-b5a5-c00a73684e92" id="urn:uuid:6107fc40-d1d9-4628-b901-5b41b3a346ad">
            <Slot name="SubmissionSetStatus">
                <ValueList>
                    <Value>Original</Value>
                </ValueList>
            </Slot>
        </Association>
        <Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" sourceObject="urn:uuid:8e78d34e-a41a-4eeb-aa8e-b2872724b750" targetObject="64af6991-f020-41fe-824a-4904b04e57ee" id="urn:uuid:dff32be3-2a79-4e5b-9977-fb199ea5d6ca">
            <Slot name="SubmissionSetStatus">
                <ValueList>
                    <Value>Original</Value>
                </ValueList>
            </Slot>
        </Association>
    </RegistryObjectList>
</ns3:SubmitObjectsRequest>

Literatur

IHE
- www.ihe.net
- XDM
CDA
FHIR
- http://hl7.org/fhir
- Bulk Data:
  - http://docs.smarthealthit.org/flat-fhir/
  - https://github.com/smart-on-fhir/fhir-bulk-data-docs
Gesetze
- https://www.gesetze-im-internet.de/sgb_5/__291d.html
- https://dsgvo-gesetz.de/art-20-dsgvo/

Referenzen

↑ Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)
↑ HL7 Deutschland e. V. http://www.hl7.de
↑ IHE Deutschland e. V. http://www.ihe-d.de
↑ CCESigG, 2010
↑ eIDAS: http://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32014R0910
↑ Dt. Zeitgesetz: https://www.gesetze-im-internet.de/me_einhg/BJNR007090969.html
↑ BSI TR-ESOR: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03125/BSI_TR_03125_V1_2_1.pdf?__blob=publicationFile&v=2

[1] Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)

[2] HL7 Deutschland e. V. http://www.hl7.de

[3] IHE Deutschland e. V. http://www.ihe-d.de

[4] CCESigG, 2010

[5] IDAS: http://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32014R0910

[6] Dt. Zeitgesetz: https://www.gesetze-im-internet.de/me_einhg/BJNR007090969.html

[7] BSI TR-ESOR: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03125/BSI_TR_03125_V1_2_1.pdf?__blob=publicationFile&v=2

[1]

[2]

[3]

[4]

[5]

[6]

[7]

@@ Zeile 237: / Zeile 237: @@
 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.
-===Inhaltliche Vorgaben lt. KBV===
-Die KBV hat in ihrer Präsentation dazu folgende inhaltliche Vorgaben gemacht:
-*Patientenstammdaten
-*Behandlungsdokumentation inkl. Verordnungshistorie
-*Dokumentation
-**Dokumentenarchiv
-**Erst- und Folgedokumentation von eDMP
-**QS-Dokumentationen
-*administrative Praxisdaten
 ==Arztwechsel==
@@ Zeile 462: / Zeile 451: @@
 ***Value
-Die konkreten Ausprägungen für den jeweiligen Slot sind nachfolgender Tabelle zu entnehmen.
+Die konkreten Ausprägungen für den jeweiligen Slot sind in den  Tabellen unter "Attribute" zu entnehmen.
 {{NoteBox|
@@ Zeile 497: / Zeile 486: @@
 | hash || Slot || Hashwert der Datei || über den Hashwert des Dokumentes lässt sich eine Signatur aufbringen<br/>Anm.: SHA1 ist aktuell nicht mehr zulässig, muss aber aus Kompatibilitätsgründen weiter gefüllt werden. || R || INT || f5eb92f4ee4e9e9426 db8b75eaaf8f8745512964
 |-
-| hashValue || Slot || Hashwert der Datei || über den Hashwert des Dokumentes über das in hashAlgo hinterlegte Verfahren || neu: R2 || INT || f5eb92f4ee4e9e9426 db8b75eaaf8f8745512964
+| hashValue || Slot || Hashwert der Datei || über den Hashwert des Dokumentes über das in hashAlgorithm hinterlegte Verfahren || neu: R2 || INT || f5eb92f4ee4e9e9426 db8b75eaaf8f8745512964
 |-
 | hashAlgorithm || Slot || Hashalgorithmus|| der für den Hashwert genutzte Algorithmus; Empfehlung SHA256 oder SHA512 || neu: R2 || ST || SHA256
 |-
-| healthcareFacilityTypeCode || Classification || [http://art-decor.org/decor/services/RetrieveValueSet?prefix=ihede-&language=de-DE&version=&id=1.2.276.0.76.11.36&format=xml healthcareFacilityTpeCode] || || R2 || CE ||
+| healthcareFacilityTypeCode || Classification || [http://art-decor.org/decor/services/RetrieveValueSet?prefix=ihede-&language=de-DE&version=&id=1.2.276.0.76.11.36&format=xml healthcareFacilityTypeCode] || || R2 || CE ||
 |-
 | homeCommunityId || ExtrinsicObject (home)  ||  || || O ||  ||
@@ Zeile 688: / Zeile 677: @@
 |'''Verfahrensart''' ||Einzel/Stapel ||Einzel/Stapel	||Einzel ||Einzel/Stapel/Warteschlange
 |-
-|'''Client Software notwendig''' ||Ja	||Ja	||Per API <br/>|(RFC 3161)	||Per API<br/>|(RFC 4998)
+|'''Client Software notwendig''' || Ja || Ja || Per API <br/>||(RFC 3161) ||Per API<br/> || (RFC 4998)
 |-
 |'''WebService''' ||Fernsignatur ||Fernsiegel	||REST	||REST

Wechselschnittstelle

Aktuelle Version vom 20. Juni 2018, 13:57 Uhr

Inhaltsverzeichnis

Dokumenteninformationen

Impressum

Ansprechpartner und Autoren

Kontributoren

Disclaimer

Copyright-Hinweis, Nutzungshinweise

Einleitung

Hintergrund

Zweck

Anforderungen

Ergebnis

Rechtliche Anforderungen

Randbedingungen dazu

Überlegungen zum Lösungsansatz

Vorteile

Struktur dieses Dokumentes

Datenschutzaspekte gemäß EU-Verordnung und nationalem Recht und Verordnungen

Sprachliche Regelungen

Szenarien

Systemwechsel

Arztwechsel

Aktentransport

EU-DSGVO

Auskunftsersuchen

Lösungsansatz

Ausprägungen

Grobstruktur der Dateien für IHE ITI XDM

Media-Ebene

Ordner-Ebene

"fixe" Hauptdateien

README.TXT

INDEX.HTM

METADATA.XML

Struktur

Attribute

für Dokumente (ExtrinsicObject)

für Submission Set (ExtrinsicObject)

für Folder (ExtrinsicObject)

ValueSets

Namenskonvention für die Dateinamen

Umsetzung der Use Cases

Signatur – Zeitstempel – Evidence Record

Einzelsignatur

Stapelsignatur

Inhalte

Stammdaten und Kataloge (Vokabularien)

PDF-Dokumente

CDA

FHIR

Ressourcen

Datentypen

Codesysteme

ValueSets

Transaktionen

Encoding

Sonstige Angaben

Verschlüsselung

Transportmöglichkeiten

Security

Anhang

Beispiel für eine METADATA.XML

Literatur

Referenzen

Navigationsmenü

Suche