This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template.
This article was last edited by Foemig (talk| contribs) 6 years ago. (Purge)

Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage.
This article was last edited by Foemig (talk| contribs) 6 years ago. (Purge)

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

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

Wechselschnittstelle

Implementierungsleitfaden

vorgelegt von:
.

in Arbeit

Version:	0.1
Datum:	18. Dezember 2017
Status:	Entwicklung
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
01	01.03.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

Inhaltsverzeichnis

1 Dokumenteninformationen
2 Einleitung
3 Szenarien
4 Grobstruktur der Dateien für IHE ITI XDM
5 Inhalte
6 Signatur
- 6.1 Einzelsignatur
- 6.2 Stapelsignatur
7 Verschlüsselung
8 Transportmöglichkeiten
9 Implementierung
10 Anhang

Dokumenteninformationen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Impressum

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

Ansprechpartner und Autoren

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

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 .

Disclaimer

Der Inhalt dieses Dokumentes ist öffentlich. Zu beachten ist, dass Teile dieses Dokuments auf der Normative Edition 2005 von HL7 Version 3 bzw. dem ISO-Standard Clinical Document Architecture (CDA) Release 2 (ISO/HL7 27932:2009 Data Exchange Standards -- HL7 Clinical Document Architecture, Release 2) 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 CDA-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.

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

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.

Laut eHealth-Gesetz und EU-DSVG hat der Patient in naher Zukunft ein Recht, seine Daten mitzunehmen.

Sobald (diese) Vorgaben in VESTA verankert sind, kann der Gesetzgeber dafür Fristen vorsehen.

Zweck

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

Lösungsansatz

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

Andere Lösungsansätze wie bspw. "Blue Button" oder "FHIR Bulk Data" gehen nur von einer inhaltlich limitierten Abfrage von Informationen ohne Wiedereinlesen bzw. einem Online-Verfahren aus.

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 einfache Basisdaten:
- Patient, Fälle, Aufenthalte, Diagnosen, Prozeduren, Maßnahmen, ..
- Ggf. zuzügl. Stammdaten (Value Sets)
Eine Umsetzung ist inkrementell erweiterbar
- weitere Ressourcen/Dateien
- weitere Details in den Ressourcen/Dateien
Kurzfristig realisierbar (Spezifikation + Implementierung)
Einstieg in Standardisierung

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.

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.

Grobstruktur der Dateien für IHE ITI XDM

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

Media


Dateistruktur	Inhalt	Dateiname	XDM-Optionalität	Profilierung
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


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

INDEX.HTM

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

Beispiel

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

METADATA.XML

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

Beispiel

validieren + ergänzen

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

Folgende Metadaten sind bereitzustellen:

prüfen und ggf. ergänzen


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

weitere Dateien

Namenskonvention für die Dateinamen

XDM verlangt, dass alle Dateien in der "alten" 8+3-Konvention mit Großbuchstaben erstellt werden. (Für Ordner gelten nur 8 Großbuchstaben.) Für eine korrekte Abarbeitung sind Namen zu wählen, die alphabetisch sortiert werden können und die gemäß dieser Sortierreihenfolge abzuarbeiten sind. Das gilt auch für Ordner.

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 können alle genutzt werden:

Arztbrief
Entlassbrief
Ein-/Überweisung
Rezepte, Medikationsplan
..

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:

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

FHIR-Ressourcen


Resource	Inhalt	Link	Beispiele
administrativ
Patient	demographische Daten	http://fhir.de/StructureDefinition/patient-de-basis	https://simplifier.net/BasisprofilDE/Patient-example
Encounter	Fallinformationen
klinisch
Concern (Diagnosis)	Diagnosen
Condition		https://simplifier.net/BasisprofilDE/condition-de-basis
Observation	Beobachtungen, Meßwerte und Befunde
Procedure	Maßnahmen
Medication	Medikation
MedicationStatement
AllergyIntolerance
Goal
FamilyMemberHistory
finanziell
Coverage	Versicherungsinformationen	http://fhir.de/StructureDefinition/coverage-de-basis, https://simplifier.net/BasisprofilDE/coverage-de-gkv, https://simplifier.net/BasisprofilDE/coverage-de-sel
technisch
CodeSystem	Kataloge
ValueSet	Wertemengen (Auswahllisten)
organisatorisch
Practitioner	Ärzte
Organization	Organisationen	http://fhir.de/StructureDefinition/organization-de-basis, https://simplifier.net/BasisprofilDE/organization-de-basis
...

FHIR-Datentypen

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

(xBDT)

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

Folgende Satzarten sind zu unterstützen:


Satzart	Inhalt	Optionalität	Beispiel
...		R

Zu besseren Integration sollte hier aber überlegt werden, ob nicht zugunsten internationaler Standards nicht besser auf FHIR Resourcen gewechselt wird.

Signatur

Einzelsignatur

Individuell für einzelne Dateien.

Stapelsignatur

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

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.

Implementierung

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.

Anhang

Beispiele

Literatur

IHE
- www.ihe.net
- XDM
CDA
FHIR
- http://hl7.org/fhir
- BULK Data: http://docs.smarthealthit.org/flat-fhir/
xBDT
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

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

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

[1]

[2]

Wechselschnittstelle

Inhaltsverzeichnis

Dokumenteninformationen

Impressum

Ansprechpartner und Autoren

Disclaimer

Copyright-Hinweis, Nutzungshinweise

Einleitung

Hintergrund

Zweck

Lösungsansatz

Vorteile

Szenarien

Systemwechsel

Arztwechsel

Aktentransport

EU-DSGVO

Auskunftsersuchen

Grobstruktur der Dateien für IHE ITI XDM

Inhalte eines Ordners

XDM Hauptdateien

README.TXT

INDEX.HTM

METADATA.XML

weitere Dateien

Namenskonvention für die Dateinamen

Inhalte

Stammdaten und Kataloge (Vokabularien)

PDF-Dokumente

CDA

FHIR

FHIR-Ressourcen

FHIR-Datentypen

(xBDT)

Signatur

Einzelsignatur

Stapelsignatur

Verschlüsselung

Transportmöglichkeiten

Implementierung

Anhang

Beispiele

Literatur

Referenzen

Navigationsmenü

Suche