Rückübermittlung Bericht aus Subsystemen (Composition)


Motivation

In der heterogenen Systemlandschaft im Krankenhaus sind eine Vielzahl spezialisierter Subsysteme im Einsatz. Die Ergebnisse aus diesen Subsystemen sind aktuell jedoch häufig nicht in den Primärsystemen des Krankenhauses verfügbar, denn es bestehen folgende Herausforderungen:

  1. Die Daten in Subsystemen sind sehr heterogen und können hochspezialisiert sein.
  2. Bei der Nutzung dieser Subsysteme besteht häufig ein Interesse, auf die menschenlesbare Repräsentation der strukturierten Daten einwirken zu können.
  3. Künftig ist mit Szenarien zu rechnen, bei denen Befunde aus Subsystemen in eine elektronische Patientenakte übertragen werden sollen.
  4. Aktuell werden Befunde, obwohl diese in den Subsystemen in hochstrukturierter Form vorliegen, nur als PDF an das Primärsystem zurückübermittelt. Oft weil kein strukturiertes Format spezifiziert ist, das sowohl versendendes Subsystem als auch empfangendes Primärsystem implementiert haben.
  5. Der Umfang, in dem eine Datenübernahme in ein Primärsystem möglich ist, variiert stark zwischen den Systemen oder Installationen, z.B. abhängig davon, ob ein Modul für Vitalparameter installiert ist.

Die ISiK-Spezifikation begegnet diesen Herausforderungen, indem sie die Rückübermittlung von Ergebnissen aus Subsystemen an die Primärsysteme in Form von strukturierten Dokumenten erfordert, die über eine menschenlesbare Repräsentation verfügen. Diese strukturierten Dokumente werden im ISiK-Kontext als Berichte bezeichnet. Dabei sind die strukturierten Inhalte der Berichte harmonisiert mit den verbreiteten Formaten für Primärsysteme.

In der aktuellen Ausbaustufe von ISiK ist lediglich die Übernahme und Anzeige der Dokument-Metadaten (z.B. Dokumenttyp, Dokumentdatum, Quelle) und der menschenlesbaren HTML-Repräsentation in die Primärsysteme erforderlich.

In weiteren Ausbaustufen von ISiK soll darüber hinaus eine Übernahme der strukturierten Anteile der Dokumente möglich sein, die den ISiK-Spezifikationen entsprechen, z.B. Diagnosen und Prozeduren.

Es obliegt dabei dem Ermessen des Herstellers, ob die Übernahme strukturierter Daten in das Primärsystem automatisch erfolgt, oder durch den Benutzer initiiert wird.

Die Berichte werden, wie von der FHIR Spezifikation für die Composition Ressource vorgesehen, in einem FHIR-Bundle versendet.


Interaktionen

Die Rückübermittlung eines Document-Bundles an ein Primärsystem erfolgt mittels einer 'POST'-Interaktion auf den Endpunkt des Primärsystems.

Beispiele:

POST [base]/ mit einer FHIR-Bundle Ressource im Request-Body.

Anwendungshinweise: Weitere Informationen zu den verschiedenen Endpunkten für Dokumente finden sich in der FHIR-Basisspezifikation - Abschnitt "Document End-Points".

Das Bundle dient der Aggregation aller Ressourcen, die Bestandteil des Dokumentes sind. Dabei ist die erste Ressource im Bundle (Bundle.entry.resource) stets eine Composition, alle weiteren Entries enthalten zusätzliche Ressourcen, auf die die Composition verweist.

Falls die im Dokumenten-Bundle enthaltene Patient-Ressource und/oder Encounter-Ressource nicht anhand der Business-Identifier oder anderer Matching-Kriterien im empfangenden System gefunden werden kann (d.h. der Patient oder der Encounter existiert im empfangenden System noch nicht), MUSS als Antwort der HTTP Status Code "422 - Unprocessable Entity" zurückgegeben werden. Im Body der Response ist eine OperationOutcome zurückzugeben, welche ein Issue mit dem Verweis auf die nicht auflösbare Referenz enthält. Zur Kodierung von OperationOutcome.issue.code MUSS als Code "processing" verwendet werden.

Das Bundle muss folgendem Profil entsprechen:

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
identifierS Σ1..1Identifier
typeS Σ1..1codeBindingFixed Value
timestampS Σ1..1instant
totalΣ I0..1unsignedInt
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
relationΣ1..1string
urlΣ1..1uri
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
fullUrlS Σ1..1uri
resourceS Σ1..1Resource
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
fullUrlΣ0..1uri
resourceΣ I0..1ISiKBerichtSubSysteme
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

Unterscheidungshinweis: Informationen zu Interaktionen mit Dokument-Binaries finden sich im Modul ISiK Dokumentenaustausch - Abgrenzung zu ISiK Stufe 2.

Verarbeitung des Dokumentes

Hinweis: Die nachfolgenden Regeln für die Verarbeitung eines Dokumentes gelten nur für Document-Bundles die an den oben genannten Endpunkt gesendet werden. Weitere ISiK-Module können Regeln für die Verarbeitung von anderen Bundle-Typen (z.B. 'transaction') aufstellen.

In der aktuellen Ausbaustufe von ISiK MUSS ein empfangenes Dokument in folgenden Schritten verarbeitet werden:

  1. Extraktion der Patient-Ressource aus dem Bundle und Herstellung des Patientenbezuges anhand eines eindeutigen Identifiers ('Patient.identifier') oder ähnlich identifizieren Merkmalen
  2. Extraktion der Encounter.Ressource aus dem Bundle und Herstellung des Fallbezuges anhand der Abrechnungsfallnummer ('Encounter.account.identifier') oder ähnlich identifizieren Merkmalen
  3. Extraktion der Composition-Ressource aus dem Bundle und Auslesen der mit 'mustSupport' gekennzeichneten Meta-Daten, sowie der menschenlesbaren Repräsentation des Dokumentes ('Composition.text', 'Composition.section.text', 'Composition.section.section.text')
  4. Hinzufügen des Dokumentes und seiner Metadaten zur Fallakte des Patienten.
  5. Visualisierung des Dokumentes und seiner Metadaten in der Fallakte des Patienten
Composition Bundle

Die Grafik zeigt an einem vereinfachten Beispiel die Zuordnung des HTML-Dokumentes zu Patient und Kontakt in der aktuellen Ausbaustufe von ISiK (schwarze Pfeile). Die grauen Pfeile deuten die Übernahme strukturierter Daten, wie sie in weiteren Ausbaustufen erforderlich wird.

Hinweise zum Umgang mit der menschenlesbaren Repräsentation

Die menschenlesbare Repräsentation ("Narrative") eines Dokumentes setzt sich zusammen aus dem Inhalt von 'Composition.text', einer Repräsentation der Metadaten (z.B. Dokumenttyp, Patientenname, Patientennummer, Aufnahmenummer, Datum) sowie der Aggregation der Inhalte von 'Composition.section', wobei zu beachten ist, dass ein Dokument beliebig viele Sections haben kann. Die einzelnen Bestandteile des Narratives KÖNNEN mit <div>-Elementen zusammengefügt werden.

Extraktion der Patient-/ und Encounter-Ressource im Document-Bundle

Folgende Fälle sind zu beachten um eine Patient-/ und Encounter-Ressource aus dem Document-Bundle zu extrahieren:

  • Die aufzulösende Referenz ist eine URN (immer absolut, z. B. "urn:uuid:9d1714da-b7e6-455b-bfd2-69ce0ff5fb12"):

    • Suche nach einem Bundle-Entry mit einer fullUrl, die mit dem reference.value übereinstimmt
    • Wenn einer gefunden wird, ist die Auflösung erfolgreich (und endet hier)
    • Andernfalls schlägt die Auflösung fehl (und endet hier). Die Referenz hat in dieser Spezifikation keine definierte Bedeutung.
  • Wenn die Referenz eine absolute URL ist (z. B. "https://fhir.example.org/base/Patient/123", "https://fhir.example.org/base/Patient/123/_history/a"):

    • Suche nach einem Bundle-Entry mit einer fullUrl, die mit dem reference.value übereinstimmt
    • Wenn einer gefunden wird, ist die Auflösung hier erfolgreich (und endet)
    • Wird mehr als ein Eintrag gefunden, KANN der Server nach der neuesten Version suchen (basierend auf meta.lastUpdated). Wenn jener auf diese Weise genau eine aktuelle Version findet, ist die Auflösung erfolgreich (und endet hier)
  • Wenn die Referenz die Form "[Typ]/[id]" hat (z. B. "Patient/123")

    • Wenn der Bundle-Entry, der den Verweis enthält, eine FullUrl hat, die dem RESTful-URL-Regex entspricht (z. B. "https://fhir.example.org/Observation/456"):
      • Extrahiert wird die [root] aus der fullUrl des Bundle-Entries und mit der relative Referenz zusammenangefügt (z. B. "https://fhir.example.org/" + "Patient/123" --> "https://fhir.example.org/Patient/123")
      • Gefolgt wird den Schritten für die Auflösung absoluter Referenzen. Siehe oben.

Persistierung der menschenlesbaren Repräsentation

Das Narrative der Ressource KANN innerhalb einer DocumentReference-Ressource persistiert werden. Zum derzeitigen Zeitpunkt obliegt es der jeweiligen Implementierung wie diese DocumentReference Ressource ausgestaltet ist. Ein Mapping der Composition-Metadaten auf DocumentReference-Metadaten KANN der FHIR Kernspezifikation entnommen werden. Siehe Abschnitt "2.42.8.7 FHIR Composition".

Das Narrative MUSS als Binary-Ressource unter DocumentReference.content.attachment.url angegeben werden.

Hinweis: Es ist zu beachten, dass in einem Attachment-Datentyp im Element "url" eine absolute URL anzugeben ist. Somit muss zunächst das Binary auf dem externen System per POST angelegt werden. Der hieraus resultierende Link kann anschließend im Attachment verwendet werden.

Falls ein Bundle erneut mit dem gleichen Bundle.identifier übermittelt wird, MUSS eine neue DocumentReference erstellt werden, welche unter DocumentReference.relatesTo.target angegeben wird.

Hinweise zum Umgang mit strukturierten Daten

Auch wenn in der aktuellen Stufe nur die Übernahme der menschenlesbaren Repräsentation erforderlich ist, empfiehlt es sich dennoch, das vollständige Bundle samt der strukturierten Anteile zu einem Dokument zu persistieren, sodass zu einem späteren Zeitpunkt, wenn eine Übernahme einzelner Daten möglich ist, diese auch rückwirkend erfolgen kann.


Profil

NameCanonical
ISiKBerichtSubSystemehttps://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKBerichtSubSysteme

idS Σ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
id0..1string
extensionI0..*Extension
statusS1..1codeBindingFixed Value
divS I1..1xhtml
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
id0..1string
extensionI0..*Extension
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemS Σ1..1uri
valueS Σ1..1string
periodΣ I0..1Period
assignerΣ I0..1Reference(Organization)
statusS Σ ?!1..1codeBindingFixed Value
id0..1string
extensionI0..*Extension
id0..1string
extensionI0..*Extension
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1codeFixed Value
displayΣ0..1string
userSelectedΣ0..1boolean
id0..1string
extensionI0..*Extension
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ I1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
id0..1string
extensionI0..*Extension
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
id0..1string
extensionI0..*Extension
id0..1string
extensionI0..*Extension
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
id0..1string
extensionI0..*Extension
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
id0..1string
extensionI0..*Extension
referenceS Σ I1..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayΣ0..1string
encounterS Σ I0..1Reference(Encounter)
dateS Σ1..1dateTime
id0..1string
extensionI0..*Extension
referenceΣ I0..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayS Σ1..1string
titleS Σ1..1string
confidentialityΣ0..1codeBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
mode1..1codeBinding
time0..1dateTime
partyI0..1Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization)
custodianΣ I0..1Reference(Organization)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
code1..1codeBinding
targetIdentifierIdentifier
targetReferenceReference(Composition)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
codeΣ0..*CodeableConcept
periodΣ I0..1Period
detailΣ I0..*Reference(Resource)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
titleS1..1string
code0..1CodeableConcept
authorI0..*Reference(Practitioner | PractitionerRole | Device | Patient | RelatedPerson | Organization)
focusI0..1Reference(Resource)
textS I1..1Narrative
mode0..1codeBinding
orderedBy0..1CodeableConceptBinding
entryI0..*Reference(Resource)
emptyReasonI0..1CodeableConceptBinding
sectionS I0..*see (section)


Anmerkungen zu den Must-Support-Feldern

Composition.id

Bedeutung: Subsystem-interne Datensatz-ID

Composition.profile

Bedeutung: Erklärung zur Konformität zum ISiK-Profil

Composition.text

Bedeutung: menschenlesbare Repräsentation des Dokumentenkopfes (Metadaten)

Hinweise: Die Mindestanforderungen an den Inhalt der menschenlesbaren Repräsentation umfasst folgende Informationen:

  • Composition.subject:Patient.name.family
  • Composition.subject:Patient.birthDate
  • Composition.subject:Patient.identifier:pid
  • Composition.status
  • Composition.type.text
  • Composition.date
  • Composition.title
  • Composition.author.display

Composition.identifier

Bedeutung: Subsystem-seitig zugewiesener Identifier des Berichtes mit Angabe der URL des vom Subsystem verwendeten Namensraumes

Hinweise: Werden eigene Identifier bzw. NamingSystems verwendet, so sei auf den Leitfaden der Basisprofile Deutschland (HL7 Deutschland) zu den Best-Practices bei Namensräumen verwiesen.

Dazu ein Beispiel für einen Identifier eines Sub-System-Berichts:

<identifier>
    <system value="https://fhir.krankenhaus.example/sid/system-a/berichtnummer" />
    <value value="0123456789" />
</identifier>

Die Verwendung von OIDs ist möglich, wird jedoch nicht empfohlen. Für die Verwendnung von OIDs KANN folgendes Format verwendet werden:

  • Das Feld system enthält den festen Wert "urn:ietf:rfc:3986"
  • Das Feld value enthält die OID mit dem Präfix "urn:oid:"

Beispiel:

<identifier>
    <system value="urn:ietf:rfc:3986"/>
    <value value="urn:oid:2.16.840.1.113883.6.96"/>
</identifier>

Composition.status

Bedeutung: Status des Dokumentes

Composition.type

Bedeutung: Dokumenttyp

Hinweise: In der aktuellen Ausbaustufe von ISiK ist textuelle Repräsentation des Dokumenttyps (type.text) ausreichend. Die darüber hinausgehende Codierung des Dokumenttyps (z.B. mit LOINC, IHE-Typecodes oder KDL) in type.coding KANN implementiert werden

Composition.subject

Bedeutung: Patientenbezug des Dokumentes

Composition.encounter

Bedeutung: Fallbezug des Dokumentes

Composition.date

Bedeutung: Datum der letzten Änderung am Dokument

Composition.author.display

Bedeutung: Autor des Dokumentes (Person, Subsystem)

Hinweise: In der aktuellen Ausbaustufe von ISiK ist die Verwendung der textuellen Repräsentation (display) von Autor und Subsystem ausreichend. Die darüber hinaus gehende Verlinkung auf Practitioner bzw. Device-Ressourcen KANN implementiert werden.

Composition.title

Bedeutung: Dokumentenbezeichnung

Hinweise: Die Dokumentenbezeichnung dient der Darstellung des Dokumentes in einer Übersicht, z.B. in einer Patientenakte, und KANN der schnellen Auffindbarkeit eines gesuchten Dokumentes dienen. Geeignete Bezeichnungen sind zum Beispiel

  • "Kleines Blutbild vom 13.10.2020"
  • "Pathologiebefund (Abstrich) vom 13.10.2020"
  • "Blutgasmessung vom 13.10.2020 14:14h"

Composition.section.title

Bedeutung: Kapitelüberschrift

Composition.section.text

Bedeutung: menschenlesbare Repräsentation des Inhalts eines Kapitels

Hinweise: Für Aggregation einer vollständigen menschenlesbaren Repräsentation MÜSSEN die Repräsentationen der einzelnen Kapitel an die Repräsentation der Metadaten (Composition.text) angehängt werden. Für die Separierung KÖNNEN einfache <div>-Tags verwendet werden. Es ist zu beachten, dass Kapitel auch Unterkapitel enthalten KÖNNEN (Composition.section.section), die bei der Aggregation entsprechend berücksichtigt werden MÜSSEN.

Die Mindestanforderungen an den Inhalt der menschenlesbaren Repräsentation umfasst folgende Informationen:

  • section.title + Freitext oder
  • section.title + Resource.text der referenzierten Ressource oder
  • section.title + eine aggregierte Repräsentation von Resource.text wenn in einer Section mehrere Ressourcen referenziert werden.

Beispiele

{
    "resourceType": "Composition",
    "id": "composition-blutdruck",
    "meta": {
        "profile":  [
            "https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKBerichtSubSysteme"
        ]
    },
    "status": "final",
    "text": {
        "status": "extensions",
        --- We have skipped the narrative for better readability of the resource ---
    },
    "identifier": {
        "type": {
            "coding":  [
                {
                    "code": "FILL",
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0203"
                }
            ]
        },
        "system": "https://fhir.krankenhaus.example/sid/system-a/berichtnummer",
        "value": "0123456789"
    },
    "type": {
        "coding":  [
            {
                "code": "55112-7",
                "system": "http://loinc.org"
            }
        ]
    },
    "subject": {
        "reference": "urn:uuid:3bada18a-6fd2-11ed-a1eb-0242ac112345"
    },
    "encounter": {
        "reference": "urn:uuid:74b46c1a-6fc9-11ed-a1eb-0242ac198765"
    },
    "date": "2022-05-03",
    "author":  [
        {
            "type": "Device",
            "display": "Gerät XY, Fa. Z, Modell T"
        }
    ],
    "title": "Blutdruckmessung vom 3.5.2022",
    "section":  [
        {
            "title": "Messung",
            "text": {
                "status": "generated",
                "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><table><tr><td><b>Systolisch</b></td><td><b>Diastolisch</b></td><td><b>Einheit</b></td><td><b>Uhrzeit</b></td></tr><tr><td>140</td><td>110</td><td>mmHG</td><td>17:15h</td></tr></table></div>"
            }
        }
    ]
}