Source: http://wiki.hl7.de/index.php?title=IG:Wechselschnittstelle
Timestamp: 2018-04-25 20:12:10+00:00

Document:
IG:Wechselschnittstelle – Hl7wiki
This article was last edited by Foemig (talk| contribs) 12 days ago. (Purge)
Implementierungsleitfaden Wechselschnittstelle (0.1).
Die Teilmaterialien gehören der Kategorie ihewss an.
Wechselschnittstelle auf Basis von IHE ITI XDM und HL7 FHIR
01 12.05.2018 Entwurf Deutschland
2.3.1 Ergebnis
2.3.2 Rechtliche Anforderungen
2.3.2.1 Randbedingungen dazu
2.4 Überlegungen zum Lösungsansatz
2.6 Struktur dieses Dokumentes
2.7 Sprachliche Regelungen
3.1 Systemwechsel
3.1.1 Inhaltliche Vorgaben lt. KBV
3.2 Arztwechsel
3.3 Aktentransport
3.4 EU-DSGVO
3.5 Auskunftsersuchen
5 Grobstruktur der Dateien für IHE ITI XDM
5.2 Inhalte eines Ordners
5.3 "fixe" Hauptdateien
5.3.1 README.TXT
5.3.2 INDEX.HTM
5.3.3 METADATA.XML
5.3.3.1 Beispiel
5.3.3.2 Struktur
5.3.3.3 Attribute
5.3.3.3.1 für Dokumente
5.3.3.3.2 für Submission Set
5.3.3.3.3 für Folder
5.4 weitere Dateien
5.5 Namenskonvention für die Dateinamen
6 Umsetzung der Use Cases
7.1 Stammdaten und Kataloge (Vokabularien)
7.2 PDF-Dokumente
7.4 FHIR
7.4.1 Ressourcen
7.4.2 Datentypen
7.4.3 Codesysteme
7.4.4 ValueSets
7.4.5 Transaktionen
7.4.6 Encoding
8.1 Signatur
8.1.1 Einzelsignatur
8.1.2 Stapelsignatur
8.2 Verschlüsselung
8.3 Transportmöglichkeiten
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!
Dr. Marc Kämmerer, Visus GmbH, Bochum
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.
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.
Näheres unter http://www.hl7.de, http://www.hl7.org und http://www.ihe.net.
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.
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. 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 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.
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.
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.
Die Änderung von §291d SGB V erfolgte mit der Zielsetzung, die elektronische Datenübertragung zzgl. übertragbarer Krankheiten zu ermöglichen.
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.
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
Bestätigung ist im Sinne eines Gütesiegels zu verstehen (BT-Drs. 18/5293, 53))
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 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
Andere Lösungsansätze gehen nur von einer inhaltlich limitierten Abfrage von Informationen ohne Wiedereinlesen wie bspw. "Blue Button" oder einem Online-Verfahren wie "HL7 FHIR Bulk Data" aus. Letzteres liefert alle Daten in einem strukturierten Format, das ein Wiedereinlesen prinzipiell ermöglicht. FHIR Bulk Data wäre das derzeit bevorzugte Verfahren, stellt aber höhere Anforderungen an die Systeme als das nachfolgend beschriebene Verfahren, welches einen späteren Umstieg vorbereiten soll.
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
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 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)
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.
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.
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:
Behandlungsdokumentation inkl. Verordnungshistorie
Erst- und Folgedokumentation von eDMP
administrative Praxisdaten
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.
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.
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.
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.
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. 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.
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:
Auf oberster Ebene MÜSSEN folgende Dateien und Ordner vorhanden sein.
XDM-Optionalität
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:
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
*.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
"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.
Die README.TXT Datei ist eine Datei, die laut XDM vorhanden sein MUSS und Aufschluss über das Medium bei Rückfragen gibt.
Gesundheitsweg 47
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.
Die INDEX.HTM Datei MUSS individuell für das zu erstellende Medium erzeugt werden und enthält (patientenspezifische) Links, um das Navigieren zu erleichtern.
<title>XDM - klinische Dokumente für STEVE FARNSWORTH</title>
XDM Dokumente:
Erzeugt von: <br/>
Allgemeines Krankenhaus <br/>
Gesundheitsweg 47 <br/>
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/>
<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>
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.
Die Metadatendatei MUSS vorhanden sein und beinhaltet alle notwendigen Metadaten für alle auf dem Medium vorhandenen Dateien.
validieren + ergänzen
<lcm:SubmitObjectsRequest
<rim:ObjectRef id="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" />
<rim:RegistryPackage id="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54">
<rim:Value>20110119094335</rim:Value>
<rim:Name />
<rim:Description />
<rim:Classification id="cs129545181532887187021426829752701"
classifiedObject="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54"
nodeRepresentation="Summarization of episode">
<rim:LocalizedString charset="UTF-8" xml:lang="en-us"
value="Summarization of episode" />
<rim:ExternalIdentifier id="i129545181532873297332487895283681"
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:ExternalIdentifier id="i1295451815328-75133792076035487272"
value="1.3.6.1.4.1.21367.13.2300">
<rim:ExternalIdentifier id="i129545181532885853874948009515163"
value="2.16.840.1.113883.3.140.1.0.6.10.1027010453125023">
id="urn:uuid:9573e35e-356a-882c-9ba9-0016cf875c54"
mimeType="text/xml" >
<rim:Value>20110119154305</rim:Value>
<rim:Value>093fe223f551c82e275d56d962781f38dc60d360</rim:Value>
<rim:Value>20100119</rim:Value>
<rim:Value>20110119</rim:Value>
<rim:Value>38235</rim:Value>
<rim:Value>CCD_FARN.xml</rim:Value>
<rim:Value>3014^^^&amp;2.16.840.1.113883.3.140.1.0.6.4&amp;ISO</rim:Value>
<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-11|820 JORIE BLVD^^CHICAGO^IL^60523^US</rim:Value>
<rim:LocalizedString charset="UTF-8" xml:lang="en-us" value="Madison Medical Center P. A. Continuity of Care Document" />
<rim:Classification id="c1295451815359-16821550949756222801"
classifiedObject="urn:uuid:9573e35e-356a-882c-9ba9-0016cf875c54"
xml:lang="en-us" value="Summarization of episode" />
<rim:ExternalIdentifier id="i129545181535932337158254820973541"
registryObject="urn:uuid:9573e35e-356a-882c-9ba9-0016cf875c54"
<rim:LocalizedString value="XDSDocumentEntry.patientId" />
<rim:Association id="a1295451815359-13126249208320826000"
sourceObject="urn:uuid:9573ae3e-356a-882c-2852-0016cf875c54"
targetObject="urn:uuid:9573e35e-356a-882c-9ba9-0016cf875c54">
Die hierarchische Struktur der Metadaten-Datei sieht vereinfacht 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)
rim:Slot (s.u.)
rim:ValueList
rim:Value (s.u.)
rim:Association (n-mal für jede Assoziation)
rim:RegistryPackage (n-mal für jeden Folder)
Die Metadaten MÜSSEN gemäß nachfolgender Aufstellugne 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.
prüfen und ggf. (mit Links) ergänzen!
ExtrinsicObject - Slot
author Autor der Datei:
authorSpecialty Der Autor sollte nur angegeben werden, wenn er - wie bei einem ganz bestimmten Dokument - genau identifiziert werden kann. R2
availabilityStatus Verfügbarkeit O
classCode classCode R2
comments Kommentare O ST
confidentialityCode Vertaulichkeit: confidentialityCode R2
creationTime Erzeugungsdatum der Datei R2 TS 20110119154305
entryUUID eindeutige ID R
eventCodeList evnetCodeList O
formatCode Dateiformat: formatCode R2 CE
hash Hashwert der Datei über den Hashwert des Dokumentes lässt sich eine Signatur aufbringen R INT
healthcareFacilityTypeCode healthcareFacilityTpeCode R2 CE
homeCommunityId O
languageCode Sprachkennzeichen R2 CE
legalAuthenticator O
limitedMetadata O
mimeType R
objectType R
patientID R2
practiceSettingCode practiceSeettingCode 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 typeCode R
uniqueId R
URI Name der Datei R 8+3
für Submission Set
contentTypeCode R2 ST
intendedRecipient R2
sourceId R
submissionTime Übermittlungsdatum der Datei R TS 20110119154305
title Titel des Dokuments O
uniqueId eindeutige Identifikation für das Dokument R
für Folder
codelist Liste an Codes, vgl. Cookbook: codeList R2
lastUpdateTime O TS
title Titel des Dokuments O ST
uniqueId eindeutige ID für den Ordner R
Brauchen wir weitere Dateien?
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.
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.
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
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-Resourcen bereitgestellt werden.
Stammdaten und Kataloge (Vokabularien)
Im Falle eines Systemwechsels sind auch Stammdaten und Kataloge zu ex- und importieren.
Stationen, Fachbereiche, ..
ICD (besser über off. Server)
ICPM (besser über off. Server)
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.
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)
Diagnosen: http://wiki.hl7.de/index.php?title=Diagnosen_(Projekt)
Maßnahmen: http://wiki.hl7.de/index.php?title=Ma%C3%9Fnahmen_(Projekt)
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
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)
Die älteren HL7 Standards - hier wäre insbesondere v2.x zu nennen - sind primär nachrichtenbasiert. Somit käme auch in Betracht, die Basisinformationen als abzuspielende Nachrichten zu repräsentieren. Mit dem immer stärkeren Aufkommen von FHIR 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:
http://www.fhir.de
https://simplifier.net/BasisprofilDE/Grundlagen
Darüber hinaus MÜSSEN die auf fhir.hl7.org beschriebenen Grundlagen eingehalten werden.
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
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
Coverage Versicherungsinformationen http://fhir.de/StructureDefinition/coverage-de-basis, https://simplifier.net/BasisprofilDE/coverage-de-gkv, https://simplifier.net/BasisprofilDE/coverage-de-sel
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 Resourcen sind nicht nur auf Ressourcenebene profiliert, es gibt auch spezielle Vorgaben für die Nutzung der Datentypen in bestimmten Kontexten:
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
https://simplifier.net/BasisprofilDE/anlage-6-vorsatzworte
https://simplifier.net/BasisprofilDE/anlage-7-namenszusaetze
https://simplifier.net/BasisprofilDE/anlage-8-laenderkennzeichen
Da die Resourcen 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.
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.
Die Repräsentation der Daten in Form von Dateien bieten eine einfache Signaturmöglichkeit.
Individuell für einzelne Dateien: Diese kann parallel zu der zu signierenden Datei (gleicher Basisdateiname) abgelegt werden.
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 anzugeben. Die Signatur wird auf die Metadatendatei angewendet und parallel zu dieser abgelegt.
Eine Verschlüsselung des Mediums ist über gängige Verfahren wie ZIP möglich, dies ist aber nicht Bestandteil dieser Spezifikation.
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.
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.
https://www.gesetze-im-internet.de/sgb_5/__291d.html
Abgerufen von „http://wiki.hl7.de/index.php?title=IG:Wechselschnittstelle&oldid=49284“
Ihewss
Diese Seite wurde zuletzt am 13. April 2018 um 13:41 Uhr geändert.

References: § 291
 §291
 §291
 §291
 Art. 8
 §291
 §291
 § 291
 § 14
 §291
 § 14
 §291
 §291
 § 73
 § 73

§ 14
 § 291
 § 291
 § 291