Interaktion: Dokumentenbereitstellung
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 folgende Verfahren möglich:
- SMARTApp Launch: Wenn der Aufruf der App im Rahmen des SMART-Frameworks erfolgt, kennt der Client bereits beim Start den aktuellen Patienten- und ggf. den Encounterkontext. Dabei wählt ein Anwender im Primärsystem (Server) einen Patienten und Fall aus und startet in diesem Kontext die App. Referenzen auf Patient und Encounter werden im Zuge der Authorisierung vom Server an Client übermittelt. (Siehe Modul Sicherheit - Launch Context und Scopes).
- Bekannte Fallnummer: Der Client kennt die (Abrechnungs-)Fallnummer (z.B. durch das Einscannen eines Barcodes, oder beim Mapping von V2 auf FHIR aus PV1.#19). Der Client sucht den Encounter anhand der Fallnummer (
[base]/Encounter?account:identifier=<Fallnummer>
). Da unter einer Abrechnungs-Fallnummer mehrere Encounter (Besuche) zusammengefasst werden können (z.B. vorstationär + stationär + nachstationär), sollte als zusätzliches Suchkriterium entweder ein Datum/Zeitraum oder eine Selektion aufEncounter.status
verwendet werden. Wenn ein zutreffender Encounter gefunden wurde, kann der Patientenkontext aus der subject-Referenz des Encounters entnommen werden. - Arbeitsliste: Der Client ruft auf dem Server eine Arbeitsliste ab (z.B. Liste aller Encounter, die aktuell auf einer bestimmten Station/Ambulanz stattfinden, Liste aller ServiceRequests/Tasks, die durch den Client abgearbeitet werden müssen (aktuell noch nicht im Scope der ISiK-Spezifikationen!) und etabliert den Kontext, nachdem der Benutzer einen Eintrag der Liste ausgewählt hat.
- Manuelle Auswahl. Nach dem Start des Clients verwendet der Benutzer eine Suchmaske, in der anhand von Patientennummer oder anderer demografischer Daten gesucht werden kann. Der Client verwendet die Patient-Interaktionen des ISiK-Basismoduls, um auf dem Server nach zutreffenden Patienten zu suchen. Der Anwender wählt den gesuchten Patienten aus der Liste der Suchtreffer aus. Im Anschluss listet der Client, mithílfe der Encounter-Interaktionen des ISiK-Basismoduls, die relevanten Besuche des ausgewählten Patienten auf. (Anm.: Welche Besuche als "relevant" erachtet werden, liegt im Ermessen des Clients. Es könnte z.B. anhand von
Encounter.period
,Encounter.class
und/oderEncounter.status
gefiltert werden). Der Anwender wählt den zutreffenden Encounter aus.
Hinweis | Gefahr fehlerhafter Zuordnung! |
---|---|
Die manuelle Auswahl von Patienten- und Fallkontext durch einen Benutzer ist fehleranfällig. Clients müssen geeigente Vorkehrungen und Plausibilitätsprüfungen implementieren um Falschzuordnungen zu verhindern. |
Dokumentenübermittlung
Die Übermittlung des Dokumentes vom Client an den Server erfolgt mithílfe der $submit-document
Operation.
Hinweis: Der zum Zeitpunkt der Erstellung dieser Spezifikation vorliegende IHE MHD-Implementierungsleitfaden sieht für die Dokumentenbereitstellung ein Transaction-Bundle mit POST-Interaktionen vor. Aus Gründen, die in der diesbezüglichen Diskussion im internationalen FHIR-Chat nachzulesen sind, ist dieses Vorgehen jedoch zu hinterfragen und wird seitens IHE voraussichtlich in künftigen MHD-Versionen geändert. Siehe hierzu Kapitel Kompatibilität
Um den hier erarbeiteten Vorschlag einer Dokumentenübermittlung mittels Operations der internationalen FHIR-Community im Allgemeinen und IHE im Besonderen vorstellen zu können, in der Hoffnung und Erwartung, dass diese dem Vorgehen folgen, wird dieser Teil der ISiK-Spezifikation ausnahmsweise auf Englisch spezifiziert.
OperationDefinition $submit-document
Invocations
URL: [base]/$submit-document
Parameters (In)
Name | Cardinality | Type | Documentation |
metadata | 1..1 | DocumentReference | DocumentReference containing document metadata |
payload | 1..1 | Binary | Binary containing document payload |
Return Values (Out)
Name | Cardinality | Type | Documentation |
output-metadata | 1..1 | DocumentReference | DocumentReference as persisted by the server |
information | 0..* | OperationOutcome | Additional information and/or warnings about the operation the server whishes to convey to the client |
Expected behaviour:
- Servers SHALL store the submitted binary with the associated metadata and make it available through the FHIR API
- If the submission contains a structured FHIR document-Bundle, Servers MAY chose to store additional representations of the document,
e.g. native FHIR (XML and/or JSON) for FHIR aware Clients and/or an HTML-Document representing the document's narrative to allow easy read access for FHIR agnostic clients.
The Binary representation mostly serves the purpose of archiving an immutable version of the document, rather than making it available to other consumers!
If Servers can provide multiple representations of the same document, this SHOULD be reflected in multiple
content
-elements in the DocumentReference with the respective mime-type. - If a Client submits a DocumentReference which includes a
relatesTo
-Element, the Server SHALL process the submission in accordance withrelatesTo.code
as either a replacement, transformation, appendix or a signature of the document referenced inrelatesTo.target
. If applicable, Servers SHALL update thestatus
of the related DocumentReference tosuperseded
. - Servers SHALL return HTTP 412 (precondition failed) the
relatesTo.target
reference does not resolve on the server. - Servers SHALL ignore any information submitted by the Client in
DocumentReference.content.attachment.url
and assume the content to be the Binary submitted with thepayload
parameter. - Servers SHALL adjust the
content
-element to reflect how and where the document has been stored by the server.
In-Parameters-Profil (ISiK)
Parameters | Parameters | ||
parameter | S | 2.. | |
metadata | S | 1..1 | |
name | S | Fixed Value | |
resource | S | 1.. | Erforderliche Metadaten für Dokumentenaustausch in ISiK |
content | ..1 | ||
payload | S | 1..1 | |
name | S | Fixed Value | |
resource | S | 1.. | ISiKBinary |
Feldname | Kurzbeschreibung | Hinweise |
---|---|---|
Parameters.parameter | ||
Parameters.parameter:metadata | Dokumentenmetadaten in Form einer DocumentReference-Ressource | ... |
Parameters.parameter:metadata.name | Name des Parameters | =metadata |
Parameters.parameter:metadata.resource | Resource vom Typ `DocumentReference` | |
Parameters.parameter:payload | das Dokument | |
Parameters.parameter:payload.name | Name des Parameters | =payload |
Parameters.parameter:payload.resource | Ressource vom Typ `Binary` |
Out-Parameters-Profil (ISiK)
Parameters | Parameters | ||
parameter | S | 1.. | |
output-metadata | S | 1..1 | |
name | S | Fixed Value | |
resource | S | 1.. | Erforderliche Metadaten für Dokumentenaustausch in ISiK |
id | S | 1.. | |
type | |||
coding | 2.. | ||
XDS | 1.. | ||
category | |||
XDS | |||
information | 0..1 | ||
name | S | Fixed Value | |
resource | S | 1.. | OperationOutcome |
Feldname | Kurzbeschreibung | Hinweise |
---|---|---|
Parameters.parameter | ||
Parameters.parameter:output-metadata | Dokumentenmetadaten wie sie vom Server verstanden/persistiert wurden | ... |
Parameters.parameter:output-metadata.name | Name des Parameters | =output-metadata |
Parameters.parameter:output-metadata.resource | Ressource vom Type `DocumentReference` | |
Parameters.parameter:output-metadata.resource.id | Serverseitig zugewiesene Datensatz-ID | Der Server mus dem Datensatz eine eindeutige ID zuweisen und diese zurückgeben. |
Parameters.parameter:information.name | Name des Parameters | =information |
Parameters.parameter:information.resource | Ressource vom Type `OperationOutcome` |
Beispiel:
Hinweis: Die Binary-Ressourcen sind der Lesbarkeit halber verkürzt dargestellt!
Request
POST [base]/$submit-document
{ "resourceType": "Parameters", "id": "submit-document-in-params", "meta": { "profile": [ "https://gematik.de/fhir/isik/v2/Dokumentenaustausch/StructureDefinition/SubmitDocumentInput" ] }, "parameter": [ { "name": "metadata", "resource": { "masterIdentifier": { "system": "urn:ietf:rfc:3986", "value": "urn:oid:1.2.840.113556.1.8000.2554.58783.21864.3474.19410.44358.58254.41281.46340" }, "type": { "coding": [ { "system": "http://dvmd.de/fhir/CodeSystem/kdl", "code": "PT130102", "display": "Molekularpathologiebefund" }, { "system": "http://ihe-d.de/CodeSystem/IHEXDStypeCode", "code": "PATH", "display": "Pathologiebefundberichte" } ] }, "resourceType": "DocumentReference", "id": "dok-beispiel-client", "meta": { "security": [ { "code": "HTEST", "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason" } ], "profile": [ "https://gematik.de/fhir/isik/v2/Dokumentenaustausch/StructureDefinition/ISiKDokumentenMetadaten" ] }, "status": "current", "category": [ { "coding": [ { "code": "BEF", "system": "http://ihe-d.de/CodeSystems/IHEXDSclassCode", "display": "Befundbericht" } ] } ], "description": "Molekularpathologiebefund vom 31.12.21", "subject": { "reference": "Patient/PatientinMusterfrau" }, "securityLabel": [ { "coding": [ { "code": "N", "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality" } ] } ], "content": [ { "attachment": { "contentType": "application/pdf", "language": "de", "url": "Binary/12345", "creation": "2020-12-31T23:50:50-05:00" }, "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/BeispielBesuch" } ] } } }, { "name": "payload", "resource": { "resourceType": "Binary", "id": "Binary-PDF-Example-short", "contentType": "application/pdf", "securityContext": { "reference": "Patient/PatientinMusterfrau" }, "data": "JVBERi0xLjUNJeLjz9MNCjEw" } } ] }
Response
{ "resourceType": "Parameters", "id": "submit-document-out-params", "meta": { "profile": [ "https://gematik.de/fhir/isik/v2/Dokumentenaustausch/StructureDefinition/SubmitDocumentOutput" ] }, "parameter": [ { "name": "output-metadata", "resource": { "masterIdentifier": { "system": "urn:ietf:rfc:3986", "value": "urn:oid:1.2.840.113556.1.8000.2554.58783.21864.3474.19410.44358.58254.41281.46340" }, "type": { "coding": [ { "system": "http://dvmd.de/fhir/CodeSystem/kdl", "code": "PT130102", "display": "Molekularpathologiebefund" }, { "code": "PATH", "system": "http://ihe-d.de/CodeSystem/IHEXDStypeCode", "display": "Pathologiebefundberichte" } ] }, "resourceType": "DocumentReference", "id": "123456789", "meta": { "security": [ { "code": "HTEST", "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason" } ], "profile": [ "https://gematik.de/fhir/isik/v2/Dokumentenaustausch/StructureDefinition/ISiKDokumentenMetadaten" ] }, "status": "current", "category": [ { "coding": [ { "code": "BEF", "system": "http://ihe-d.de/CodeSystems/IHEXDSclassCode", "display": "Befundbericht" } ] } ], "description": "Molekularpathologiebefund vom 31.12.21", "subject": { "reference": "Patient/PatientinMusterfrau" }, "securityLabel": [ { "coding": [ { "code": "N", "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality" } ] } ], "content": [ { "attachment": { "contentType": "application/pdf", "language": "de", "url": "http://mein-dokumentenserver/dokumente/1231232312.pdf", "creation": "2020-12-31T23:50:50-05:00" }, "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/BeispielBesuch" } ] } } }, { "name": "information", "resource": { "resourceType": "OperationOutcome", "id": "oo-beispiel", "issue": [ { "severity": "information", "code": "informational", "diagnostics": "Well done!" } ] } } ] }