Akteure und Interaktionen


Akteure

Dokumentenserver

Das bestätigungsrelevante System nimmt die Rolle des Dokumentenservers ein. Ein Dokumentenserver nimmt Dokumente von Clients zur Speicherung/Archivierung/Verwaltung entgegen und erlaubt Clients die Suche nach und den Abruf von Dokumenten.

Dieses ISiK-Modul legt fest, welche Suchkriterien mindestens implementiert werden müssen und welche Kriterien darüber hinaus optional bereitgestellt werden können. Um Clients die Herstellung von Patienten- und Encounterkontext zu ermöglichen, müssen weiterhin die im Basismodul Stufe 4 festgelegten Interaktionen auf den Datenobjekten "Patient" und "Kontakt/Fall (Encounter)" implementiert werden.

Der Dokumentenserver nimmt im IHE-MHD-Kontext die Rollen Document Recipient und Document Responder ein und implementiert die IHE-MHD-Interaktionen

  • Simplified Publish [ITI-105] (verpflichtend)
  • Generate Metadata [ITI-106] (optional)
  • Find Document References [ITI-67] (verpflichtend)
  • Retrieve Document [ITI-68] (verpflichtend)

(Webbasierter/Mobiler) Client

Clients können Dokumente von einem Dokumentenserver abfragen, um sie z.B. einem Anwender anzuzeigen. Dabei können sie die für die Server verpflichtend festgelegten Suchkriterien beliebig kombinieren. Clients sind nicht verpflichtet, alle von den Servern geforderten Suchkriterien zu unterstützen. Weiterhin können Clients neu erstellte, geänderte oder erweiterte Dokumente an einen Dokumentenserver übermitteln. Dabei müssen sie jedoch mindestens die in diesem Modul verpflichtend festgelegten Metadaten zu den Dokumenten bereitstellen. Sowohl die Implementierung der Interaktion "Dokumentenabfrage" als auch "Dokumentenbereitstellung" sind für Clients optional.

Der Client nimmt im IHE-MHD-Kontext die Rollen Document Source und Document Consumer ein und implementiert die IHE-MHD-Interaktionen

  • Simplified Publish [ITI-105] (optional)
  • Generate Metadata [ITI-106] (optional)
  • Find Document References [ITI-67] (optional)
  • Retrieve Document [ITI-68] (optional)

Could not find subject. File not found for 'subject=Material-Images-isikprimaerscope'


Interaktionen

Dokumentenabfrage und -Zugriff (bestätigungsrelevant)

Use Case: Ein (webbasierter/mobiler) Client möchte Dokumente anhand definierter Kriterien abfragen. Zur Dokumenten(-Metadaten)abfrage nutzt diese Spezifikation die SEARCH-Interaktionen auf der DocumentReference-Ressource gemäß der FHIR-Spezifikation. Dabei MÜSSEN ausgewählte Suchparameter von Dokumentenservern verpflichtend unterstützt werden. Die Selektion erfolgt anhand der Relevanz der Parameter für die identifizierten Use Cases.

Der Zugriff auf die von den DocumentReferences verlinkten Dokumente (z.B. im PDF-Format) MUSS per READ-Interaktion auf der Binary-Ressource gemäß ISIK-Spezifikation erfolgen.

Dokumentenbereitstellung (bestätigungsrelevant)

Use Case: Ein (webbasierter/mobiler) Client möchte neu erstellte, geänderte oder erweiterte Dokumente an einen Dokumentenserver übermitteln. Der Server MUSS Dokument und Metadaten entgegennehmen, diese persistieren und anschließend für die Dokumentabfrage und den -zugriff bereitstellen.

Update von Dokumentenmetadaten (optional)

Use Case: Ein Client möchte die Metadaten eines Dokumentes ändern, ohne den Inhalt des Dokumentes selbst zu beeinflussen oder eine neue Version des Dokumentes hochladen zu müssen. Dies ist nur für eine stark eingeschränkte Menge von Elementen möglich. Der Server stellt dafür eine Operation zur Verfügung, deren Parameter den änderbaren Elementen entsprechen.

Erzeugen von Dokumentenmetadaten (optional)

Use Case: Ein Client möchte ein gem. ISiK Basismodul erzeugtes, strukturiertes, FHIR-basiertes Dokument an einen Dokumentenserver übermitteln. Der Server stellt dazu eine Operation zur Verfügung, die aus den strukturierten Daten des Dokumentes die erforderlichen Metadaten extrahiert und dem Client eine entsprechend ausgefüllte DocumentReference-Ressource zurückgibt. Diese Operation kann von einem Dokumentenserver aber auch einem Drittsystem bereitgestellt werden.


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"
            }
        ]
    }
}

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

Dokumentenabfrage und -zugriff

Dokumentenabfrage (IHE MHD ITI-67 (Find DocumentReferences))

Dokumente können anhand ihrer Metadaten gesucht werden. Im Rahmen der ISiK-Spezifikation müssen mindestens die im Kapitel Interaktionen mit MUSS gekennzeichneten Suchparameter unterstützt werden. Einzelnen Systemen steht es frei, darüber hinaus weitere FHIR-konforme Suchparameter zu implementieren.

Die Ergebnisse einer Suchanfrage werden in Form eines Bundles zurückgegeben:

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
identifierΣ0..1Identifier
typeS Σ1..1codeBindingFixed Value
timestampΣ0..1instant
totalΣ I1..1unsignedInt
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
relationΣ1..1string
urlΣ1..1uri
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
fullUrlΣ0..1uri
resourceΣ0..1Resource
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
modeΣ0..1codeBinding
scoreΣ0..1decimal
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
methodΣ1..1codeBinding
urlΣ1..1uri
ifNoneMatchΣ0..1string
ifModifiedSinceΣ0..1instant
ifMatchΣ0..1string
ifNoneExistΣ0..1string
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
statusΣ1..1string
locationΣ0..1uri
etagΣ0..1string
lastModifiedΣ0..1instant
outcomeΣ0..1Resource
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
fullUrlS Σ1..1uri
resourceS I1..1ISiKDokumentenMetadaten
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
modeΣ0..1codeBinding
scoreΣ0..1decimal
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
methodΣ1..1codeBinding
urlΣ1..1uri
ifNoneMatchΣ0..1string
ifModifiedSinceΣ0..1instant
ifMatchΣ0..1string
ifNoneExistΣ0..1string
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
statusΣ1..1string
locationΣ0..1uri
etagΣ0..1string
lastModifiedΣ0..1instant
outcomeΣ0..1Resource
signatureΣ0..1Signature

Suchergebnisse können zahlreich sein. Server MÜSSEN daher FHIR-konformes Paging unterstützen. Server KÖNNEN im SearchSet-Bundle auch Ressourcen vom Typ OperationOutcome mit Informationen über die Suchergebnisse zurückgeben. Diese müssen in Bundle.entry.search.mode mit dem Wert outcome gekennzeichnet sein. Die Issues im OperationOutcome dürfen nur dem Schweregrad information oder warning entsprechen. Issues vom Schweregrad error oder fatal sind unzulässig.

Hinweise und Anmerkungen zur Implementierung von IHE MHD ITI-67 (Find DocumentReferences)

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

2:3.67.4.1 Find Document References Request Message

2:3.67.4.1.1 Trigger Events

Die Vereinbarungen gelten uneingeschränkt.

2:3.67.4.1.2 Message Semantics

Es gelten darüber hinaus die allgemeinen Festlegungen zu Suchparametern gemäß ISiK Basisprofil Stufe

2:3.67.4.1.2.1 Query Search Parameters

Im Rahmen der ISiK-Spezifikation müssen mindestens die im Kapitel Interaktionen mit MUSS gekennzeichneten Suchparameter unterstützt werden. Einzelnen Systemen steht es frei, darüber hinaus weitere FHIR-konforme bzw in IHE MHD geforderte Suchparameter zu implementieren.

Die in IHE bestehende Verpflichtung für Clients, bei jeder Query mindestens einen der Parameter patient oder patient.identifier verwenden zu müssen, besteht im ISiK-Kontext nicht. Patientenübergreifende Suchanfragen sind zulässig.

2:3.67.4.1.2.2 Populating Expected Response Format

Die Vereinbarungen gelten uneingeschränkt.

2:3.67.4.1.3 Expected Actions

Die Vereinbarungen gelten uneingeschränkt.

2:3.67.4.1.3.1 XDS on FHIR Option

Die Implementierung der "XDS on FHIR"-Option ist im ISiK-Kontext nicht gefordert.

2:3.67.4.2 Find Document References Response Message

2:3.67.4.2.1 Trigger Events

Die Vereinbarungen gelten uneingeschränkt.

2:3.67.4.2.2 Message Semantics
  • Suchergebnisse können zahlreich sein. Server MÜSSEN daher FHIR-konformes Paging unterstützen. Server KÖNNEN im SearchSet-Bundle auch Ressourcen vom Typ OperationOutcome mit Informationen über die Suchergebnisse zurückgeben. Diese müssen in Bundle.entry.search.mode mit dem Wert outcome gekennzeichnet sein. Die Issues im OperationOutcome dürfen nur dem Schweregrad information oder warning entsprechen. Issues vom Schweregrad error oder fatal sind unzulässig.
  • Das Ergebnis-Bundle der Suche muss konform sein zum Profil "ISiKDokumentenSuchergebnisse"
    idΣ0..1string
    metaΣ0..1Meta
    implicitRulesΣ ?!0..1uri
    language0..1codeBinding
    identifierΣ0..1Identifier
    typeS Σ1..1codeBindingFixed Value
    timestampΣ0..1instant
    totalΣ I1..1unsignedInt
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    relationΣ1..1string
    urlΣ1..1uri
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    fullUrlΣ0..1uri
    resourceΣ0..1Resource
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    modeΣ0..1codeBinding
    scoreΣ0..1decimal
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    methodΣ1..1codeBinding
    urlΣ1..1uri
    ifNoneMatchΣ0..1string
    ifModifiedSinceΣ0..1instant
    ifMatchΣ0..1string
    ifNoneExistΣ0..1string
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    statusΣ1..1string
    locationΣ0..1uri
    etagΣ0..1string
    lastModifiedΣ0..1instant
    outcomeΣ0..1Resource
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    fullUrlS Σ1..1uri
    resourceS I1..1ISiKDokumentenMetadaten
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    modeΣ0..1codeBinding
    scoreΣ0..1decimal
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    methodΣ1..1codeBinding
    urlΣ1..1uri
    ifNoneMatchΣ0..1string
    ifModifiedSinceΣ0..1instant
    ifMatchΣ0..1string
    ifNoneExistΣ0..1string
    id0..1string
    extensionI0..*Extension
    modifierExtensionΣ ?! I0..*Extension
    statusΣ1..1string
    locationΣ0..1uri
    etagΣ0..1string
    lastModifiedΣ0..1instant
    outcomeΣ0..1Resource
    signatureΣ0..1Signature
2:3.67.4.2.2.1 DocumentReference Resource Contents
  • Die DocumentReference-Ressoucen müssen im ISiK-Kontext auf Basis des Profils "ISiKDokumentenMetadaten" und den dort vereinbarten Kardinalitäten bzw. MustSupport-Flags erstellt werden.
2:3.67.4.2.2.1.1 Document Location

Die Vereinbarungen gelten uneingeschränkt.

Alle weiteren Unterkapitel von 2:3.67.4.2.2.1 DocumentReference Resource Contents sind für den ISiK-Kontext nicht relevant.

2:3.67.4.3 Expected Actions

Die Vereinbarungen gelten uneingeschränkt.

2:3.67.4.4 CapabilityStatement Resource

Es gelten die Vereinbarungen gemäß

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

2:3.67.5 Security Considerations

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

Beispiele

  • Suche anhand von Patientenkontext (PID) und Dokumentendatum: [base]/DocumentReference?patient.identifier=1234&creation=gt2021-10-06
  • Suche nach vorläufigen Endoskopiebefunden (anhand KDL-Dokumenttyp und docStatus): [base]/DocumentReference?type=http://dvmd.de/fhir/CodeSystem/kdl|DG02010&doc-status=preliminary
  • Suche von Dokumenten anhand der Nummer des Abrechnungsfalles: [base]/DocumentReference?encounter.account:identifier=56789

Dokumentenzugriff (IHE MHD ITI-68 (Retrieve Document))

Das den Metadaten zugeordnete Dokument kann jeweils unter DocumentReference.content.attachment.url vom Server abgerufen werden.

Hinweise und Anmerkungen zur Implementierung von IHE MHD ITI-68 (Retrieve Document)

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

2:3.68.4.1 Retrieve Document Request Message

2:3.68.4.1.1 Trigger Events

Die Vereinbarungen gelten uneingeschränkt.

2:3.68.4.1.2 Message Semantics

Der einzige MIME-Type, den alle Dokumentenserver verpflichtend zurückgeben können MÜSSEN, ist der MIME Type, der dem DocumentReference.content.attachment.contentType entspricht.

Im ISiK-Kontext SOLLEN Dokumentenserver das Dokument darüber hinaus über einen Binary-Endpunkt bereitstellen können. Dieser verfügt über folgende Besonderheit:

  • Wenn der Zugriff mit dem Accept-Header application/fhir+xml oder application/fhir+json erfolgt, müssen die Daten als Binary-Ressource im angeforderten Format zurückgegeben werden.
  • Wenn der Zugriff mit einem anderen Accept-Header als application/fhir+xml oder application/fhir+json erfolgt, so soll das Dokument im angeforderten Format zurückgegeben werden, z.B. MUSS bei Zugriffen mit Accept-Header application/pdf das Dokument unmittelbar als PDF zurückgegeben werden, sofern dies dem Content-Type der Binary-Ressource entspricht.
2:3.68.4.1.3 Expected Actions

Die Vereinbarungen gelten uneingeschränkt.

2:3.68.4.2 Retrieve Document Response Message

Die Vereinbarungen dieses Kapitels und aller Unterkapitel gelten uneingeschränkt.

2:3.68.4.2.1 Trigger Events

Die Vereinbarungen gelten uneingeschränkt.

2:3.68.4.2.2 Message Semantics

Die Vereinbarungen gelten uneingeschränkt.

2:3.68.4.3 Expected Actions

Die Vereinbarungen gelten uneingeschränkt.

2:3.68.4.4 CapabilityStatement Resource

Es gelten die Vereinbarungen gemäß

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

2:3.68.5 Security Considerations

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

Interaktion: Update von Metadaten, Löschen von Dokumenten

Herstellung von Dokumentenkontext

Der Client muss zunächst die URL der DocumentReference ermitteln, auf die das Update angewendet werden soll. Hierzu kann die Interaktion Dokumentenabfrage verwendet werden.

Metadatenupdate

Das Update der Metadaten erfolgt mittels der $update-metadata Operation. Hinweis: Der zum Zeitpunkt der Erstellung dieser Spezifikation vorliegende IHE-MHD-Implementierungsleitfaden sieht kein Metadatenupdate vor. Hier müsste stets ein neues Dokument übermittelt werden.

Für den ISiK Use Case als maßgeblich relevant und unkritisch in Bezug auf die Versionierung hat sich jedoch das Element docStatuserwiesen, welches im IHE-Kontext keine Berücksichtigung findet. Im einrichtungsinternen Dokumentenaustausch kommt es häufig vor, dass sich der Status eines Dokumentes ändert (z.b. preliminary -> final), ohne dass dies Auswirkungen auf den Inhalt hat. Die Anlage eines neuen Dokumentes wäre in diesem Kontext nicht effizient.

Ebenso erlaubt diese Operation, vorläufige Dokumente durch ein Update von docStatus zu löschen (preliminary -> entered-in-error ).

Wenn Dokumenten-Server $update-metadata unterstützen, dann MÜSSEN Dokumenten-Server das Löschen von vorläufigen Dokumenten unterstützen, d.h. dann MÜSSEN Server bei einem Update auf den Status entered-in-error auch den Code in DocumentReference.status auf entered-in-error setzen und dafür Sorge tragen, dass diese Dokumente bei Suchanfragen nicht mehr als Ergebnisse zurückgegeben werden (siehe Search Related Safety Checks), es sei denn der Client sucht explizit nach gelöschten Dokumenten (z.B. /DocumentReference?status=entered-in-error).

Sobald ein Dokument den Status final erreicht hat, MUSS ein Server die Änderungen von Metadaten NICHT mehr zulassen (d.h. ein Server KANN in diesem Fall die Löschung finaler Dokumente erlauben, MUSS es aber nicht. Der Server KANN in diesem Fall auch eine Fehlermeldung ausgeben).

Finale Dokumente SOLLEN nur noch mit MHD-konformen Methoden aktualisiert bzw. gelöscht werden, indem sie durch eine neue bzw. leere Version ersetzt werden. Ein Client SOLL in diesem Fall eine erneute Dokumentenbereitstellung durchführen, mit Referenz auf das zu ersetzende Dokument in DocumentReference.relatesTo.target und dem Code replaces in DocumentReference.relatesTo.code.

Hinweis Experimentelle Funktion
Die Löschung vorläufiger Dokumente mittels $update-metadata ist experimentell. 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.

OperationDefinition $update-metadata

Invocations

URL: [base]/DocumentReference/[id]/$update-metadata

Parameters (In)

NameCardinalityTypeBindingDocumentation
docStatus1..1codeCompositionStatus (required)

new value for element docStatus

Expected behaviour:
  • Servers SHALL update the DocumentReference.docStatus with the submitted values
  • Servers SHALL ensure that DocumentReference.text reflects this change

Beispiel

[base]/DocumentReference/example/$update-metadata?docStatus=final

Erzeugen von Metadaten (IHE MHD ITI-106 Generate Metadata)

Hinweis Breaking Change!
Die in der Stufe 3 erfolgte Umstellung der Definition von $generate-metadata von der in ISiK Stufe 2 spezifizierten OperationDefinition auf die in IHE MHD ITI-106 spezifizierte Fassung ist nicht kompatibel zu den Festlegungen dieses Moduls in Stufe 2! Die Änderung dient dem Zweck der Harmonisierung mit der IHE-MHD-Interaktion ITI-106 (Generate Metadata), die zum Zeitpunkt des Releases von Stufe 2 noch nicht zur Verfügung stand.

Hinweise und Anmerkungen zur Implementierung von IHE MHD ITI-106 (Generate Metadata)

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

2:3.106.4.1 Generate Metadata Request Message

2:3.106.4.1.1 Trigger Events

Die Vereinbarungen gelten uneingeschränkt.

2:3.106.4.1.2 Message Semantics

Die Vereinbarungen gelten uneingeschränkt.

2:3.106.4.1.3 Expected Actions

Der Fokus für die Implementierung der Operation ISiK-Kontext sollte auf dem Persistieren und Erzeugen von Metadaten für ISiK-konforme Bundles gemäß Interaktion ISiK Modul Basis: Bericht aus Subsystem liegen. Für die Implementierung kann das unten angegeben ISiK-Spezifische Mapping Composition -> DocumentReference als Anhaltspunkt verwendet werden.

Die Unterstützung weiterer Input-Formate (z.B. CDA oder andere FHIR-Dokumente, wie MIOs, eRezept, eAU etc.) ist optional.

Alle weiteren Unterkapitel von 2:3.106.4.1.3 Expected Actions sind für den ISiK-Kontext nicht relevant.

2:3.106.4.2 Generate Metadata Response Message

2:3.106.4.2.1 Trigger Events

Die Vereinbarungen gelten uneingeschränkt.

2:3.106.4.2.2 Message Semantics

Die Vereinbarungen gelten uneingeschränkt.

2:3.106.4.2.3 Expected Actions

Die Vereinbarungen gelten uneingeschränkt.

2:3.106.4.3 CapabilityStatement Resource

Es gelten die Vereinbarungen gemäß

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

2:3.106.5 Security Considerations

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

ISiK-Spezifisches Mapping Composition -> DocumentReference

Pathmapcomment
DocumentReference.masterIdentifierBundle.identifier
DocumentReference.identifierComposition.identifier
DocumentReference.status=current
DocumentReference.docStatusComposition.status
DocumentReference.type.coding:KDLComposition.type.coding[KDL]
DocumentReference.type.coding:XDSComposition.type.coding[XDS]Kann mittels Lookup in den KDL->XDS ConceptMaps anhand des KDL-Type-Codes ermittelt werden
DocumentReference.category.coding:XDSComposition.category.coding[XDS]Kann mittels Lookup in den KDL->XDS ConceptMaps anhand des KDL-Type-Codes ermittelt werden
DocumentReference.subjectLookup Composition.subject.resolve().identifier[PID]Ermittlung des korrekten Patienten auf dem Server anhand des Identifiers (PID) und/oder weiterer Kriterien erforderlich
DocumentReference.authorComposition.author
DocumentReference.relatesTo.codeComposition.relatesTo.code
DocumentReference.relatesTo.targetLookup Composition.relatesTo.targetReference.resolve().identifierErmittlung der zu ersetzenden DocumentReference anhand des identifiers der referenzierten Composition erforderlich
DocumentReference.descriptionComposition.title
DocumentReference.content.attachment.contentType`application/html` für den extrahierten Narrative, `application/fhir+xml` oder `application/fhir+json` für das Bundle
DocumentReference.content.attachment.language=de sofern keine abweichende Angabe in Composition.language
DocumentReference.content.attachment.urlvom Server festgelegter Speicherort des Bundles/Narratives
DocumentReference.content.attachment.creationComposition.date
DocumentReference.content.format=urn:ihe:iti:xds:2017:mimeTypeSufficient
DocumentReference.context.encounterLookup Composition.encounter.resolve().identifierErmittlung des korrekten Encounters auf dem Server anhand des Identifiers(Fallnummer) und/oder weiterer Kriterien erforderlich
DocumentReference.context.facilityType=KHS, sofern nichts anderes bekannt

Abgrenzung zu ISiK Basis bei der Kommunikation strukturierter Dokumente (FHIR-Document-Bundle)

Interaktion ISiK Modul Basis: Bericht aus Subsystem

  • UseCase: Client übermittelt diverse strukturierte Informationen in Form eines Dokumentes an einen Empfänger. Der Empfänger (oder ggf. dessen Benutzer) kann selbst entscheiden, welche Informationen übernommen und ggf. weiterverarbeitet werden können/sollen. Als Minimum muss die Narrative (die HTML-Repräsentation des gesamten Dokumentes) übernommen werden.
  • HTTP-verb: POST auf [base]
  • Content: Bundle vom Typ document
  • erforderliches Verhalten: der Empfänger verarbeitet den Inhalt des Dokumentes (HTML + Ressourcen soweit möglich), das Original muss nicht zwingend persistiert werden. Es besteht kein zwingendes Erfordernis, dass das Dokument oder seine Inhalte über die API wieder bereitgestellt werden können.

Interaktion ISiK Modul Dokumentenaustausch: Dokumentenbereitstellung

  • Use Case: Client übermittelt ein strukturiertes Dokument zur inhaltsagnostischen, dauerhaften, ggf. rechtssicheren Archivierung
  • HTTP-verb: POST auf [base]/DocumentReference
  • Content: DocumentReference mit Base64-codiertem Bundle vom Typ document (eingebettet in DocumentReference.content.attachment.data)
  • erforderliches Verhalten: das Dokument sowie seine Metadaten werden persistiert und über die API mittels der Interaktionen "Dokumentenabfrage" und "Dokumentenzugriff" bereitgestellt.

Typische Szenarien mit Koexistenz beider Interaktionen:

Der Empfänger eines Subsystem-Berichtes gem. Modul "Basis" möchte vor der Verarbeitung des Dokumenteninhalts das Original zur Archivierung an einen Dokumentenserver gem. Modul "Dokumentenaustausch" übermitteln und die Herkunft der extrahierten Daten aus dem Dokument nachvollziehbar machen.

Empfohlenes Vorgehen:

  1. Erzeugen einer DocumentReference-Ressource (siehe dazu $generate-metadata)
  2. Übermittlung der DocumentReference sowie des Base64-codierten Bundles gemäß Interaktion ISiK Modul Dokumentenaustausch: Dokumentenbereitstellung
  3. Extraktion der verarbeitbaren Ressourcen aus dem Bundle
  4. Verlinkung zwischen den extrahierten Ressourcen und dem Original-Dokument mittels einer Provenance-Ressource.

Der Sender eines Subsystem-Berichtes gem. Modul "Basis" möchte parallel zur Übermittlung an z.B. ein KIS zur Weiterverarbeitung der Informationen das Dokument ebenfalls im Original archivieren lassen.

Empfohlenes Vorgehen:

  1. Erzeugen einer DocumentReference-Ressource (siehe dazu $generate-metadata)
  2. Übermittlung der DocumentReference sowie des Base64-codierten Bundles gemäß Interaktion ISiK Modul Dokumentenaustausch: Dokumentenbereitstellung
  3. Übermittlung des Dokumentes zur Verarbeitung gemäß Interaktion ISiK Modul Basis: Bericht aus Subsystem

Der Empfänger eines Dokumentes gem. Modul "Dokumentenaustausch" möchte neben der Archivierung des Dokumentes auch dessen Inhalte weiterverarbeiten.

Empfohlenes Vorgehen:

  1. Entgegennahme und Persistierung des Original-Dokumentes gemäß Interaktion ISiK Modul Dokumentenaustausch: Dokumentenbereitstellung
  2. Extraktion des Bundles aus den eingebetteten Binärdaten
  3. Extraktion der verarbeitbaren Ressourcen aus dem Bundle
  4. Verlinkung zwischen den extrahierten Ressourcen und dem Original-Dokument mittels einer Provenance-Ressource.