IG:Wechselschnittstelle

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

Wechselschnittstelle

Implementierungsleitfaden

vorgelegt von:
.

in Arbeit

Version:	0.1
Datum:	9. März 2018
Status:	Entwicklung
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2018: HL7 Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
01	01.04.2018	Entwurf	Deutschland
		noch kein download verfügbar

Kontributoren
	Deutsche Telekom Healthcare and Security Solutions GmbH	Bonn
	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 und der Technischen Komitees von HL7 Deutschland e. V.

Ansprechpartner und Autoren

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

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 aber 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 und die Daten auch wieder eingelesen werden sollen. Insbesondere Letzteres ist mit Text 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 XDM, CDA und FHIR - eine Vorgabe für einen strukturierten Datenaustausch bereitstellen, der die u.g. Szenarien abdeckt.

Anforderungen

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: Das RKI kann nur vorhandene Schnittstellen nutzen.

Ergebnis

1. Die Änderung von § 291d SGB V erfolgte mit der Zielsetzung, die elektronische Datenübertragung zzgl. übertragbarer Krankheiten zu ermöglichen.
2. 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:

1. systemneutrale Archivierung von Patientendaten (Abs. 1 S.1)
2. Übertragung von Patientendaten bei einem Systemwechsel (Abs. 1 S.1)
3. 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

1. 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

1. „Anbieter“ will der Gesetzgeber weit ausgelegt wissen; er umfasse sowohl Hersteller, Zwischenhändler als auch Lieferanten von informationstechnischen Systemen (BT-Drs. 18/5293, 53).
2. 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)
3. 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.
4. Einvernehmen mit RKI herstellen (Abs. 1a S. 3 Hs. 2)
5. Festlegung ist in Benehmen mit der Gesellschaft für Telematik zu treffen
6. 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
7. Veröffentlichung einer Liste mit bestätigten IT-Systemen
8. 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.
9. 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 sind 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:

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

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)
• verwendet 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

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 System 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 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)

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. 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.

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.

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

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 bietet die Möglichkeit einer Skalierung in mehrere Dimensionen, so dass klein angefangen, später aber mit zusätzlichen Details ergänzt 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.

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

Auf oberster Ebene MÜSSEN folgende Dateien und Ordner 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	optional	R
SUBSET02	Unterordner	max. 8 Großbuchstaben	optional	R
...	weitere Unterordner	max. 8 Großbuchstaben	optional
OTHERDOC.DAT	sonstige Datei, von IHE erlaubt	max. 8+3 Großbuchstaben	optional	O

Inhalte eines Ordners

Jeder einzelne Ordner MUSS folgende Inhalte besitzen:

Dateistruktur	Inhalt	Dateiname	XDM-Optionalität	Profilierung
SUBSET01	Unterordner mit Daten	max. 8 Großbuchstaben	R	R
METADATA.XML	Metadaten für alle in diesem Ordner enthaltene Dateien	fix	R	R
*.PDF	PDF-Dokumente	max. 8 Großbuchstaben	optional	R
*.XML	CDA-Dokumente	max. 8 Großbuchstaben	optional	O
*.XML	FHIR-Ressourcen im XML-Format	max. 8 Großbuchstaben	optional	O
30px *.JSN	FHIR-Ressourcen im JSON-Format	max. 8 Großbuchstaben	optional	O
*.BDT	xBDT-Dateien	max. 8 Großbuchstaben	optional	O
*.XML	andere XML-basierte Dokumente	max. 8 Großbuchstaben	optional	O
*.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. 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/>
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>

Struktur

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

• lcm:SubmitObjectsRequest (1-mal)
  • rim:RegistryObjectList (1-mal)
    • rim:RegistryPackage (1-mal für das Submission Set)
    • rim:ExtrinsicObject (n-mal für jedes Dokument)
      • @id
      • @objectType
      • @mimeType
      • rim:Slot (s.u.)
        • @name
        • rim:ValueList
          • rim:Value (s.u.)
    • rim:Association (n-mal für jede Assoziation)
    • rim:RegistryPackage (n-mal für jeden Folder)

Attribute

Folgende Metadaten sind bereitzustellen:

für Dokumente

Slot Name	Inhalt	Kommentar	Optionalität	Datentyp	Beispiel
RegistryPackage
Classification
ExtrinsicObject - Slot
author	Autor der Datei	Der Autor sollte nur angegeben werden, wenn er - wie bei einem ganz bestimmten Dokument - genau identifiziert werden kann.	R2
availabilityStatus	Verfügbarkeit		O
classCode	http://art-decor.org/art-decor/decor-valuesets--ihede-		R2
comments	Kommentare		O	ST
confidentialityCode	Vertaulichkeit		R2
creationTime	Erzeugungsdatum der Datei		R2	TS	20110119154305
entryUUID	eindeutige ID		R
eventCodeList			O
formatCode	Dateiformat		R2	CE
hash	Hashwert der Datei	über den Hashwert des Dokumentes lässt sich eine Signatur aufbringen	R	INT
healthcareFacilityTypeCode			R2	CE
homeCommunityId			O
languageCode	Sprachkennzeichen		R2	CE
legalAuthenticator			O
limitedMetadata			O
mimeType			R
objectType			R
patientID			R2
practiceSettingCode			R2
referenceIdList			O
repositoryUniqueId			O
serviceStartTime			R2	TS
serviceStopTime			R2	TS
size	Größe der Datei		R	INT
sourcePatientId	Id des Patienten		R2	XPN
sourcePatientInfo	weitere Informationen über den Patienten (Nutzung über HL7 v2.x Segmente und Datentypen)		R2	XPN
title	Titel des Dokuments		C
typeCode			R
uniqueId			R
URI	Name der Datei		R	8+3

für Submission Set

Slot Name	Inhalt	Kommentar	Optionalität	Datentyp	Beispiel
RegistryPackage
Classification
ExtrinsicObject - Slot
author	Autor der Datei	Der Autor sollte nur angegeben werden, wenn er - wie bei einem ganz bestimmten Dokument - genau identifiziert werden kann.	R2
availabilityStatus	Verfügbarkeit		O
comments	Kommentare		O	ST
contentTypeCode			R2	ST
entryUUID	eindeutige ID		R
intendedRecipient			R2
limitedMetadata			O
patientId			R2
sourceId			R
submissionTime	Übermittlungsdatum der Datei		R	TS	20110119154305
title	Titel des Dokuments		O
uniqueId			R

für Folder

Slot Name	Inhalt	Kommentar	Optionalität	Datentyp	Beispiel
RegistryPackage
Classification
ExtrinsicObject - Slot
availabilityStatus	Verfügbarkeit		O
codelist	Liste an Codes, vgl. Cookbook		R2
comments	Kommentare		O	ST
entryUUID	eindeutige ID		R
homeCommunityId			O
lastUpdateTime			O	TS
limitedMetadata			O
patientId			R2
title	Titel des Dokuments		O
uniqueId			R

Umsetzung der Use Cases

	Use Cases
Inhalt	Systemwechsel	Arztwechsel	Konsil	..
Stammdaten	R [1..*]	O	O
Kataloge	R [1..*]	O	O
Patient	R [1..*]	O [0..1]
Fall/Aufenthalt	R [1..*]	O [0..1]
Diagnosen	O	O	O
Medikation	O	O	O
Maßnahmen	O	O	O
Versichertendaten	R	R	O
Dokumente	R	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:

• 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
  • Anforderung von Krankentransporten
• 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

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, 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	Medikation	http://hl7.org/implement/standards/fhir/medication.html
MedicationStatement		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
Questionnaire	Fragebogen	http://hl7.org/implement/standards/fhir/questionnaire.html
QuestionnaireResponse	ausgefüllter Fragebogen	http://hl7.org/implement/standards/fhir/questionnaireresponse.html
finanziell
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	Rollen 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		http://hl7.org/implement/standards/fhir/careteam.html
...

FHIR-Datentypen

Datentyp	Inhalt	Link	Beispiele
humanname	Name einer Person	https://simplifier.net/BasisprofilDE/humanname-de-basis	https://simplifier.net/BasisprofilDE/Example-patient-de-basis-humanname-komplex
	Adresse	https://simplifier.net/BasisprofilDE/address-de-basis

FHIR-Codesysteme

• https://simplifier.net/BasisprofilDE/anlage-6-vorsatzworte
• https://simplifier.net/BasisprofilDE/anlage-7-namenszusaetze
• https://simplifier.net/BasisprofilDE/anlage-8-laenderkennzeichen

FHIR-Datentypen

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

• http://fhir.de/StructureDefinition/humanname-de-basis
• ...

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

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
• xBDT
• Gesetze
  • https://www.gesetze-im-internet.de/sgb_5/__291d.html
  • https://dsgvo-gesetz.de/art-20-dsgvo/