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-typewith a code acceptable to the server, when submittingnon-fhir-documents
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 |