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. Dokumentenserver müssen mindestens die Interaktion "Dokumentenabfrage" implementieren. Die Umsetzung der Dokumentenbereitstellung ist optional. Um Clients die Herstellung von Patienten- und Encounterkontext zu ermöglichen, müssen weiterhin die im Basismodul Stufe 2 festgelegten Interaktionen auf den Datenobjekten "Patient" und "Kontakt/Fall (Encounter)" implementiert werden.
(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.
Interaktionen
Dokumentenabfrage und -Zugriff (bestätigungsrelevant)
UseCase: 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 UseCases. Der Zugriff auf die von den DocumentReferences verlinkten Dokumente (z.B. im PDF-Format) erfolgt per READ-Interaktion auf der Binary-Ressource gemäß FHIR-Spezifikation.
Dokumentenbereitstellung (bestätigungsrelevant)
UseCase: Ein (webbasierter/mobiler) Client möchte neu erstellte, geänderte oder erweiterte Dokumente an einen Dokumentenserver übermitteln. Der Server nimmt Dokument und Metadaten entgegen, persistiert diese und stellt die anschließend für die Dokumentabfrage und den -zugriff bereit.
Update von Dokumentenmetadaten (optional)
UseCase: 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)
UseCase: Ein Client möchte ein gem. ISiK Basismodul Stufe 2 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
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!" } ] } } ] }
Dokumentenabfrage und -zugriff
Dokumentenabfrage
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.
Es gelten die allgemeinen Festlegungen zu Suchparametern gemäß ISiK Basisprofil Stufe 2
Die Ergebnisse einer Suchanfrage werden in Form eines Bundles zurückgegeben:
Bundle | I | Bundle | |
identifier | Σ | 0..1 | Identifier |
type | Σ | 1..1 | codeBindingFixed Value |
timestamp | Σ | 0..1 | instant |
total | Σ I | 1..1 | unsignedInt |
link | Σ | 0..* | BackboneElement |
relation | Σ | 1..1 | string |
url | Σ | 1..1 | uri |
entry | Σ I | 0..* | BackboneElement |
(All Slices) | |||
link | Σ | 0..* | see (link) |
fullUrl | Σ | 1..1 | uri |
resource | Σ | 0..1 | Resource |
search | Σ I | 0..1 | BackboneElement |
mode | Σ | 0..1 | codeBinding |
score | Σ | 0..1 | decimal |
request | Σ I | 0..1 | BackboneElement |
method | Σ | 1..1 | codeBinding |
url | Σ | 1..1 | uri |
ifNoneMatch | Σ | 0..1 | string |
ifModifiedSince | Σ | 0..1 | instant |
ifMatch | Σ | 0..1 | string |
ifNoneExist | Σ | 0..1 | string |
response | Σ I | 0..1 | BackboneElement |
status | Σ | 1..1 | string |
location | Σ | 0..1 | uri |
etag | Σ | 0..1 | string |
lastModified | Σ | 0..1 | instant |
outcome | Σ | 0..1 | Resource |
DocumentReference | Σ I | 0..* | BackboneElement |
link | Σ | 0..* | see (link) |
fullUrl | Σ | 0..1 | uri |
resource | Σ I | 1..1 | Erforderliche Metadaten für Dokumentenaustausch in ISiK |
search | Σ I | 0..1 | BackboneElement |
mode | Σ | 0..1 | codeBinding |
score | Σ | 0..1 | decimal |
request | Σ I | 0..1 | BackboneElement |
method | Σ | 1..1 | codeBinding |
url | Σ | 1..1 | uri |
ifNoneMatch | Σ | 0..1 | string |
ifModifiedSince | Σ | 0..1 | instant |
ifMatch | Σ | 0..1 | string |
ifNoneExist | Σ | 0..1 | string |
response | Σ I | 0..1 | BackboneElement |
status | Σ | 1..1 | string |
location | Σ | 0..1 | uri |
etag | Σ | 0..1 | string |
lastModified | Σ | 0..1 | instant |
outcome | Σ | 0..1 | Resource |
signature | Σ | 0..1 | Signature |
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.
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
Das den Metadaten zugeordnete Dokument kann jeweils unter DocumentReference.content.attachment.url
vom Server abgerufen werden.
Es gelten die Festlegungen gem. IHE ITI-68: Retrieve Document
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.
Dokumentenserver SOLLEN das Dokument präferiert über einen Binary-Endpunkt bereitstellen. Dieser verfügt über folgende Besonderheit:
- Wenn der Zugriff mit dem Accept-Header
application/fhir+xml
oderapplication/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
oderapplication/fhir+json
erfolgt, so soll das Dokument im angeforderten Format zurückgegeben werden, z.B. MUSS bei Zugriffen mit Accept-Headerapplication/pdf
das Dokument unmittelbar als PDF zurückgegeben werden, sofern dies dem Content-Type der Binary-Ressource entspricht.
Interaktion: Update von Metadaten
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 ($submit-document
mit Referenz auf das zu ersetzende Dokument in DocumentReference.relatesTo
) übermittelt werden.
Für den ISiK-Usecase als maßgeblich relevant und unkritisch in Bezug auf die Versionierung hat sich jedoch das Element docStatus
erwiesen, 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. vorläufig -> final), ohne dass dies Auswirkungen auf den Inhalt hat. Die Anlage eines neuen Dokumentes wäre in diesem Kontext nicht effizient.
Daher spezifiziert ISiK eine geeignete Operation, die das gezielte Ändern des Dokumentenstatus ermöglicht.
OperationDefinition $update-metadata
Invocations
URL: [base]/DocumentReference/[id]/$update-metadata
Parameters (In)
Name | Cardinality | Type | Binding | Documentation |
docStatus | 1..1 | code | CompositionStatus (required) | new value for element |
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
Hinweis | Work in Progress! |
---|---|
Die hier vorliegende Definition der Operation dient als Vorschlag, der auf Basis von Implementierungserfahrungen weiterentwickelt werden soll. Kritik, Feedback und Verbesserungsvorschläge, insbesondere UseCases für das Update weiterer Metadaten-Elemente bitte im ISiK-Community-Chat diskutieren! |
Erzeugen von Dokumentenmetadaten
Abgrenzung zu ISiK Stufe 2 (Basis) bei der Kommunikation strukturierter Dokumente (FHIR-Document-Bundle)
Interaktion ISiK Modul Basis Stufe 2: 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 Stufe 2: Dokumentenbereitstellung
- UseCase: Client übermittelt ein strukturiertes Dokument zur inhaltsagnositschen, dauerhaften, ggf. rechtssicheren Archivierung
- HTTP-verb: POST auf [base]/$submit-document
- Content: Parameters (DocumentReference + Binary mit Base64-codiertem Bundle vom Typ
document
) - 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:
- Erzeugen einer DocumentReference-Ressource (siehe dazu $generate-metadata)
- Übermittlung der DocumentReference sowie des Base64-codierten Bundles gemäß Interaktion ISiK Modul Dokumentenaustausch Stufe 2
- Extraktion und der verarbeitbaren Ressourcen aus dem Bundle
- 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:
- Erzeugen einer DocumentReference-Ressource (siehe dazu $generate-metadata)
- Übermittlung der DocumentReference sowie des Base64-codierten Bundles gemäß Interaktion ISiK Modul Dokumentenaustausch Stufe 2
- Übermittlung des Dokumentes zur Verarbeitung gemäß Interaktion ISiK Modul Basis Stufe 2: Bericht aus Subsystem
Der Empfänger eines Dokumentes gem. Modul "Dokumentenaustausch" möchte neben der Archivierung des Dokumentes auch dessen Inhalte weiterverarbeiten.
Empfohlenes Vorgehen:
- Entgegennahme und Persistierung des Original-Dokumentes gemäß Interaktion ISiK Modul Dokumentenaustausch Stufe 2
- Extraktion des Bundles aus der Binary-Ressource
- Extraktion der verarbeitbaren Ressourcen aus dem Bundle
- Verlinkung zwischen den extrahierten Ressourcen und dem Original-Dokument mittels einer
Provenance
-Ressource.
Operation $generate-metadata
Die Operation $generate-metadata
wurde spezifiziert in Anlehnung an die Operation $generate
im current build der FHIR-Kernspezifikation, die jedoch noch nicht in implementierbarem Zustand ist. Die hier getroffenen Änderungen werden parallel als Feedback zur Verbesserung der Kernspezifikation als ChangeRequest eingereicht.
Um die Diskussion mit der internationalen Community zu erleichtern, erfolgt die Spezifikation der Operation in Englisch.
Hinweis | Work in Progress! |
---|---|
Die hier vorliegende Definition der Operation dient als Vorschlag, der auf Basis von Implementierungserfahrungen weiterentwickelt werden soll. Kritik, Feedback und Verbesserungsvorschläge bitte im ISiK-Community-Chat diskutieren! |
Invocations
URL: [base]/DocumentReference/$generate-metadata
Parameters (In)
Name | Cardinality | Type | Documentation |
fhir-document | 0..1 | Bundle | FHIR document Bundle |
non-fhir-document | 0..1 | Binary | non FHIR structured document or other document metadata source |
non-fhir-document-type | 0..1 | code | type of submitted non fhir document |
target-endpoint | 0..1 | uri | fhir endpoint on which matches for Patient (and other items) are searched |
Return Values (Out)
Name | Cardinality | Type | Documentation |
output-metadata | 1..1 | DocumentReference | DocumentReference created based on the submitted input |
information | 0..* | OperationOutcome | Additional information and/or warnings about the operation the server whishes to convey to the client |
Expected behaviour:
Servers SHALL create DocumentReference Resources from the Bundle provided through the 'fhir.document' parameter by mapping the metadata fields from the Composition in the document Bundle according to the Composition-DocumentReference.Mapping
Servers SHALL attempt to match the target of Composition.subject to an existing Resource on it's own endpoint and populate DocumentReference.subject.reference accordingly.
If no matching target id found, the Server SHALL reply with HTTP 412 (precondition failed) and return an OperationOutcome
Servers MAY attempt to resolve additional references, such as Composition.author, Composition.encounter etc.
Servers MAY allow clients to redirect any attempts to find matches to another endpoint. This is especially helpful, when the $generate-metadata operation is provided by a third party other than the document's intended destination server.
Servers MAY offer additional mapping services for non-fhir-documents although these may need more advanced mapping/business logic, terminology mapping services and more complex patient matching. If they offer additional non-fhir mapping capabilities, Servers SHOULD expose a derived OperationDefinition in their CapabilityStatment, which clearly defines the acceptable
non-fhir-document-types
.Clients SHOULD populate
non-fhir-document-type
with a code acceptable to the server, when submittingnon-fhir-document
s
In-Parameters Definition (ISiK)
Parameters | I | Parameters | |
parameter | S | 2.. | |
fhir-document | S | 0..1 | |
name | S | ||
resource | S | 1.. | ISiKBerichtBundle |
non-fhir-document | 0..1 | ||
name | S | ||
resource | S | 1.. | ISiKBinary |
non-fhir-document-type | 0..1 | ||
name | S | ||
value[x] | S | 1.. | |
valueCode | code | ||
target-endpoint | 0..1 | ||
name | S | ||
value[x] | S | 1.. | |
valueUri | uri |
Out-Parameters Definition (ISiK)
Parameters | Parameters | ||
parameter | S | 1..1 | |
output-metadata | S | 1..1 | |
name | S | Fixed Value | |
resource | Erforderliche Metadaten für Dokumentenaustausch in ISiK | ||
id | S | 1.. | |
information | 0..1 | ||
name | S | Fixed Value | |
resource | OperationOutcome |
ISiK-Spezifisches Mapping Composition -> DocumentReference
Path | map | comment |
---|---|---|
DocumentReference.masterIdentifier | Bundle.identifier | |
DocumentReference.identifier | Composition.identifier | |
DocumentReference.status | =current | |
DocumentReference.docStatus | Composition.status | |
DocumentReference.type.coding:KDL | Composition.type.coding[KDL] | |
DocumentReference.type.coding:XDS | Composition.type.coding[XDS] | Kann mittels Lookup in den KDL->XDS ConceptMaps anhand des KDL-Type-Codes ermittelt werden |
DocumentReference.category.coding:XDS | Composition.category.coding[XDS] | Kann mittels Lookup in den KDL->XDS ConceptMaps anhand des KDL-Type-Codes ermittelt werden |
DocumentReference.subject | Lookup Composition.subject.resolve().identifier[PID] | Ermittlung des korrekten Patienten auf dem Server anhand des Identifiers (PID) und/oder weiterer Kriterien erforderlich |
DocumentReference.author | Composition.author | |
DocumentReference.relatesTo.code | Composition.relatesTo.code | |
DocumentReference.relatesTo.target | Lookup Composition.relatesTo.targetReference.resolve().identifier | Ermittlung der zu ersetzenden DocumentReference anhand des identifiers der referenzierten Composition erforderlich |
DocumentReference.description | Composition.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.url | vom Server festgelegter Speicherort des Bundles/Narratives | |
DocumentReference.content.attachment.creation | Composition.date | |
DocumentReference.content.format | =urn:ihe:iti:xds:2017:mimeTypeSufficient | |
DocumentReference.context.encounter | Lookup Composition.encounter.resolve().identifier | Ermittlung des korrekten Encounters auf dem Server anhand des Identifiers(Fallnummer) und/oder weiterer Kriterien erforderlich |
DocumentReference.context.facilityType | =KHS, sofern nichts anderes bekannt |