Interaktion: Dokumentenbereitstellung

Dokumentenübermittlung (IHE MHD ITI-105 (Simplified Publish))

Die Dokumentenübermittlung erfolgt mittels IHE MHD ITI-105 (Simplified Publish)

Die Übermittlung des Dokumentes vom Client an den Server erfolgt mittels einer CREATE-Interaktion auf dem Ressourcentyp DocumentReference. Das anzulegende Dokument wird im Body der Interaktion übermittelt. Es gelten die Vorgaben der FHIR-Kernspezifikation für den Rückgabewert der Create-Interaktion, siehe Managing Return Content.

Hinweise und Anmerkungen zur Implementierung von ITI-105 (Simplified Publish) im Kontext von ISiK

Für die Implementierung der Interaktion "Dokumentenbereitstellung" gelten die in IHE MHD festgelegten Vereinbarungen zu ITI-105 gemäß der unten aufgelisteten Kapitel. Abweichungen bzw. zusätzliche Festlegungen im Kontext von ISiK sind im Folgenden zu den einzelnen Kapiteln vermerkt.

2:3.105.4.1 Simplified Publish Request Message

2:3.105.4.1.1 Trigger Events

Die Vereinbarungen gelten uneingeschränkt.

2:3.105.4.1.2 Message Semantics
  • Die übermittelte Ressource muss nur gegen das Profil "ISiKDokumentenMetadaten" valide sein, nicht gegen die IHE-DocumentReference-Profile, da die Übermittlung des Elementes DocumentReference.docStatus im ISiK-Kontext erlaubt, im IHE-Kontext jedoch verboten ist.
  • Für Clients ist es ausreichend, das Dokument mit Hilfe eines KDL-Codes in DocumentReference.type zu klassifizieren. Die entsprechenden XDS-Class- und -Type-Codes müssen vom Server bei der Verarbeitung ergänzt werden. DocumentReference.category kann bei der Dokumentenbereitstellung leer bleiben.
2:3.105.4.1.2.1 DocumentReference Resources
  • Die DocumentReference-Ressoucen müssen im ISiK-Kontext auf Basis des Profils "ISiKDokumentenMetadaten" und den dort vereinbarten Kardinalitäten bzw. MustSupport-Flags erstellt werden.
  • Die Verwendung von Contained-Ressourcen ist im ISiK-Kontext nicht erlaubt
2:3.105.4.1.2.2 Patient Identity
  • Der Client MUSS eine der im Kapitel "Herstellung von Patient- und Enocunterkontext" beschriebenen Optionen verwenden, um den Patienten- und Encounter-Kontext zu etablieren.
  • Logische Referenzen für Patient und Encounter sind im ISiK-Kontext nicht erlaubt
  • DocumentReference.sourcePatientInfo wird im ISiK-Kontext nicht verwendet
2:3.105.4.1.2.3 Replace, Transform, Signs, and Append Associations

Die Vereinbarungen gelten uneingeschränkt.

Hinweis: Dies bedeutet, dass inhaltliche Updates von Dokumenten, in Abgrenzung zu Updates von Dokumentenmetadaten, durch den Client als neue Create-Interaktion durchgeführt werden muss. Update-Interaktionen sind in diesem Kontext undefiniert. Das Dokument, welches das Update repräsentiert, muss eine entsprechende relatesTo-Relation zum vorherigen Dokument aufweisen. Der Status des vorherigen Dokumentes MUSS durch den Server auf superseded gesetzt werden.

2:3.105.4.1.3 Expected Actions
  • Die Erzeugung einer SubmissionSet Ressource durch den Server ist im ISiK-Kontext nicht erforderlich.
  • Der Server muss ggf. fehlende XDS-Class- und -Type-Codes anhand des übermittelten KDL-Codes ergänzen und in DocumentReference.type bzw. DocumentReference.category zurückliefern. Die XDS-Codes können über die im Rahmen der KDL-Spezifikation publizierten ConceptMaps aus dem KDL-Code ermittelt werden. Die XDS-Codes werden für den einrichtungsübergreifenden Dokumentenaustausch über IHE XDS, bzw. MHD oder für die Übermittlung der Dokumente an die ePA des Patienten benötigt.
2:3.105.4.1.3.1 Grouping with Actors in other Document Sharing Profiles

Das Kapitel ist für den ISiK-Kontext nicht relevant.

2:3.105.4.2 Simplified Publish Response Message

2:3.105.4.2.1 Trigger Events

Die Vereinbarungen gelten uneingeschränkt.

2:3.105.4.2.2 Message Semantics

Die Vereinbarungen gelten uneingeschränkt.

2:3.105.4.2.3 Expected Actions

Die Vereinbarungen gelten uneingeschränkt.

2:3.105.4.3 CapabilityStatement Resource

Es gelten die Vereinbarungen gemäß

Command 'pagelink' could not render: Page not found.

2:3.105.5 Security Considerations

Für Hinweise zur Implementierung von Autorisation und Authentifikation im ISiK-Kontext, siehe Modul ISiK-Connect

Herstellung von Patient- und Encounterkontext

Vor der Bereitstellung von Dokumenten muss ein Client einen Patienten- und Encounterkontext herstellen, damit das Dokument serverseitig anhand der Patient- und Encounter-Verlinkungen in der DocumentReference korrekt zugeordnet werden kann. Zur Herstellung des Kontextes sind die in ISiK Basis beschriebenen Verfahren möglich: https://simplifier.net/guide/isik-basis-stufe-5/Einfuehrung/UebergreifendeFestlegungen/Patient-Besuch-Kontext

Zusätzlich kann der Bezug mit Hilfe einer Logischen Referenz hergestellt werden. Dieses Verfahren ist experimentell und derzeit nur auf die Herstellung des Patientenkontextes begrenzt:

Der Client übermittelt in DocumentReference.subject.identifier einen Identifier, über den im Dokumentensystem ein eindeutiger Bezug hergestellt werden kann (z.B. eine einrichtungsinterne PID oder eine Krankenversichertenummer). Das Dokumentensystem (Server) muss dann bei der Verarbeitung den Identifier (unter Berücksichtigung von system und value) auflösen und durch eine Referenz auf die entsprechende lokale Patienten-Ressource substituieren. Typische UseCases hierfür sind u.A.:

  • die Konvertierung von HL7 V2 MDM-Nachrichten in eine FHIR-REST-Interaktion
  • die Übernahme von Patienten über die kommende REST-basierte Möglichkeit, Dokumente aus der ePA eines Patienten abzurufen (auch hier werden voraussichtlich ausschließlich DocumentReference-Ressourcen mit der Versichertennummer als logischer Referenz auf den Patienten bereitgestellt)

Server, die eine Zuordnung von Dokumenten mittels logischer Referenz erlauben, MÜSSEN dies im CapabilityStatement für den Ressourcentyp DocumentReference unter CapabilityStatement.rest.resource.referencePolicy` kenntlich machen:

  • Der Code resolves ist zu verwenden wenn logical Identifier erlaubt sind, aber stets auflösbar sein müssen (Trifft ein Identifier aus einen oder mehrere Patienten zu, stellt dies einen Fehlerzustand dar.)
  • Der Code logical ist zusätzlich anzugeben, wenn der Server auch DocumentReferences akzeptiert, denen kein Patient zugeordnet werden kann (z.B. in Erwartung, dass dieser zu einem späteren Zeitpunkt ergänzt wird).
  • Clients sind verpflichtet vor der Verwendung von DocumentReferences mit logischen Referenzen anhand des CapabilityStatements zu überprüfen, ob ein konkreter Server diese Funktionalität unterstützt.

Weitere Hinweise siehe https://hl7.org/fhir/R4/references.html#logical

Hinweis Experimentelle Funktion
Die Zuordnung mittels logischer Identifier ist bisher nicht erprobt. Entwickler, die diese Funktionalität nutzen, sind gebeten, im Chat ein Feedback zu hinterlassen, ob sich diese Funktion implementierbar/nützlich oder komplex/problematisch erwiesen hat. Abhängig von der Rückmeldung kann dieses Feature in späteren Releases entweder verbindlich gemacht oder entfernt werden.

Änderungen zwischen ISiK Stufe 2 und ISiK Stufe 3

Hinweis Breaking Change!
Die in der Stufe 3 erfolgte Umstellung der Interaktion von der $submit-document-Operation auf eine REST-basierte CREATE-Interaktion ist nicht kompatibel zu den Festlegungen dieses Moduls in Stufe 2! Die Änderung dient dem Zweck der Harmonisierung mit der IHE-MHD-Interaktion ITI-105 (Simplified Publish), die zum Zeitpunkt des Releases von Stufe 2 noch nicht zur Verfügung stand.

Maßgebliche Änderungen gegenüber Stufe 2 für den Client

  • Der Client muss das eigentliche Dokument (PDF, JPEG o.ä.) base64-codiert in DocumentReference.content.attachment.data einbetten und den Mime-Type des Dokumentes in DocumentReference.content.attachment.contentType adäquat setzen
  • Die Übermittlung erfolgt mittels POST auf den Endpunkt [base]/DocumentReference anstatt wie bisher mittels POST auf den Endpunkt [base]\DocumentReference\$submit-document
  • Die DocumentReference-Ressource mit den eingebetteten Binärdaten wird nun unmittelbar im Body der Interaktion gesendet. Die Notwendigkeit, DocumentReference und Binary in eine Parameters-Ressource zu wrappen, entfällt damit.
  • Die Antwort des Servers erfolgt in Form einer DocumentReference-Ressource (im Erfolgsfall) bzw. einer OperationOutcome-Ressource im Fehlerfall anstelle wie bisher einer Parameters-Ressource.

Maßgebliche Änderungen gegenüber Stufe 2 für den Server

  • Die DocumentReference-Ressource mit den eingebetteten Binärdaten wird nun unmittelbar im Body der Interaktion gesendet. Die Notwendigkeit, DocumentReference und Binary aus der Parameters-Ressource zu extrahieren, entfällt damit.
  • Die Übermittlung erfolgt mittels POST auf den Endpunkt [base]/DocumentReference anstatt wie bisher mittels POST auf den Endpunkt [base]\DocumentReference\$submit-document
  • Der Server MUSS das eingebettete Dokument aus der DocumentReference herauslösen, separat persistieren und in DocumentReference.content.attachemnt.url auf das separierte Dokument verweisen. Beim Abruf einer DocumentReference, bzw. bei der Suche nach DocumentReference-Ressourcen darf das Dokument niemals eingebettet an den Client zurückgegeben werden. Das Dokument muss über den Binary-Endpunkt der API abrufbar gemacht werden.
  • Die Antwort des Servers erfolgt in Form einer DocumentReference-Ressource (im Erfolgsfall) bzw. einer OperationOutcome-Ressource im Fehlerfall anstelle wie bisher einer Parameters-Ressource.

Beispiel

POST [base]/DocumentReference

DocumentReference
<DocumentReference xmlns="http://hl7.org/fhir">
    <id value="dok-beispiel-client-with-binary-jpeg-example-short" />
    <meta>
        <profile value="https://gematik.de/fhir/isik/StructureDefinition/ISiKDokumentenMetadaten" />
        <security>
            <system value="http://terminology.hl7.org/CodeSystem/v3-ActReason" />
            <code value="HTEST" />
        </security>
    </meta>
    <masterIdentifier>
        <system value="urn:ietf:rfc:3986" />
        <value value="urn:oid:1.2.840.113556.1.8000.2554.58783.21864.3474.19410.44358.58254.41281.46340" />
    </masterIdentifier>
    <status value="current" />
    <type>
        <coding>
            <system value="http://dvmd.de/fhir/CodeSystem/kdl" />
            <code value="ED020101" />
            <display value="Fotodokumentation Operation" />
        </coding>
    </type>
    <subject>
        <reference value="Patient/PatientinMusterfrau" />
    </subject>
    <description value="Fotodokumentation Operation vom 31.12.21" />
    <securityLabel>
        <coding>
            <system value="http://terminology.hl7.org/CodeSystem/v3-Confidentiality" />
            <code value="N" />
        </coding>
    </securityLabel>
    <content>
        <attachment>
            <contentType value="image/jpeg" />
            <language value="de" />
            <data value="4AAQSkZJRgABAQEB" />
            <creation value="2020-12-31T23:50:50-05:00" />
        </attachment>
        <format>
            <system value="http://ihe.net/fhir/ihe.formatcode.fhir/CodeSystem/formatcode" />
            <code value="urn:ihe:iti:xds:2017:mimeTypeSufficient" />
            <display value="mimeType Sufficient" />
        </format>
    </content>
    <context>
        <encounter>
            <reference value="Encounter/FachabteilungskontaktNormal" />
        </encounter>
        <facilityType>
            <coding>
                <system value="http://ihe-d.de/CodeSystems/PatientBezogenenGesundheitsversorgung" />
                <code value="KHS" />
                <display value="Krankenhaus" />
            </coding>
        </facilityType>
        <practiceSetting>
            <coding>
                <system value="http://ihe-d.de/CodeSystems/AerztlicheFachrichtungen" />
                <code value="ALLG" />
            </coding>
        </practiceSetting>
    </context>
</DocumentReference>

{
    "resourceType": "DocumentReference",
    "id": "dok-beispiel-client-with-binary-jpeg-example-short",
    "meta": {
        "security":  [
            {
                "code": "HTEST",
                "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason"
            }
        ],
        "profile":  [
            "https://gematik.de/fhir/isik/StructureDefinition/ISiKDokumentenMetadaten"
        ]
    },
    "type": {
        "coding":  [
            {
                "system": "http://dvmd.de/fhir/CodeSystem/kdl",
                "code": "ED020101",
                "display": "Fotodokumentation Operation"
            }
        ]
    },
    "masterIdentifier": {
        "system": "urn:ietf:rfc:3986",
        "value": "urn:oid:1.2.840.113556.1.8000.2554.58783.21864.3474.19410.44358.58254.41281.46340"
    },
    "status": "current",
    "description": "Fotodokumentation Operation vom 31.12.21",
    "subject": {
        "reference": "Patient/PatientinMusterfrau"
    },
    "securityLabel":  [
        {
            "coding":  [
                {
                    "code": "N",
                    "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality"
                }
            ]
        }
    ],
    "content":  [
        {
            "attachment": {
                "contentType": "image/jpeg",
                "data": "4AAQSkZJRgABAQEB",
                "language": "de",
                "creation": "01/01/2021 04:50:50"
            },
            "format": {
                "code": "urn:ihe:iti:xds:2017:mimeTypeSufficient",
                "system": "http://ihe.net/fhir/ihe.formatcode.fhir/CodeSystem/formatcode",
                "display": "mimeType Sufficient"
            }
        }
    ],
    "context": {
        "facilityType": {
            "coding":  [
                {
                    "code": "KHS",
                    "system": "http://ihe-d.de/CodeSystems/PatientBezogenenGesundheitsversorgung",
                    "display": "Krankenhaus"
                }
            ]
        },
        "practiceSetting": {
            "coding":  [
                {
                    "code": "ALLG",
                    "system": "http://ihe-d.de/CodeSystems/AerztlicheFachrichtungen"
                }
            ]
        },
        "encounter":  [
            {
                "reference": "Encounter/FachabteilungskontaktNormal"
            }
        ]
    }
}
dok-beispiel-client-with-binary-jpeg-example-short

Hinweis: Die Binary-Ressourcen sind der Lesbarkeit halber verkürzt dargestellt!