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 aktuell bestehen noch 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 sie 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 Referenz auf die in der Composition enthaltenen Patienten und/oder Encounter nicht auflösbar ist, 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:

identifierΣ0..1Identifier
typeS Σ1..1codeBindingFixed Value
timestampS Σ1..1instant
totalΣ0..1unsignedInt
relationΣ1..1string
urlΣ1..1uri
fullUrlΣ0..1uri
resourceΣ0..1Resource
modeΣ0..1codeBinding
scoreΣ0..1decimal
methodΣ1..1codeBinding
urlΣ1..1uri
ifNoneMatchΣ0..1string
ifModifiedSinceΣ0..1instant
ifMatchΣ0..1string
ifNoneExistΣ0..1string
statusΣ1..1string
locationΣ0..1uri
etagΣ0..1string
lastModifiedΣ0..1instant
outcomeΣ0..1Resource
fullUrlΣ0..1uri
resourceΣ0..1ISiKBerichtSubSysteme
modeΣ0..1codeBinding
scoreΣ0..1decimal
methodΣ1..1codeBinding
urlΣ1..1uri
ifNoneMatchΣ0..1string
ifModifiedSinceΣ0..1instant
ifMatchΣ0..1string
ifNoneExistΣ0..1string
statusΣ1..1string
locationΣ0..1uri
etagΣ0..1string
lastModifiedΣ0..1instant
outcomeΣ0..1Resource
signatureΣ0..1Signature

Verarbeitung des Dokumentes

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 der Aufnahmenummer ('Patient.identifier')
  2. Extraktion der Encounter.Ressource aus dem Bundle und Herstellung des Fallbezuges anhand der Aufnahmenummer ('Encounter.identifier')
  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')
  4. Hinzufügen des Dokumentes und seiner Metadaten zur Fallakte des Patienten
  5. Visualisierung des Dokumentes und seiner Metadaten in der Fallakte des Patienten

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.

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, so dass zu einem späteren Zeitpunkt, wenn eine Übernahme einzelner Daten möglich ist, diese auch rückwirkend erfolgen kann.

Profil

Canonical URL: https://gematik.de/fhir/ISiK/StructureDefinition/ISiKBerichtSubSysteme

idΣ1..1System.String
statusS1..1codeBindingFixed Value
divS1..1xhtml
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ1..1uri
valueΣ1..1string
periodΣ0..1Period
assignerΣ0..1Reference(Organization)
statusΣ ?!1..1codeBindingFixed Value
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
systemΣ1..1uriFixed Value
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
referenceS Σ1..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayΣ0..1string
referenceS Σ1..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayΣ0..1string
dateS Σ1..1dateTime
referenceΣ0..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayS Σ1..1string
titleS Σ1..1string
confidentialityΣ0..1codeBinding
mode1..1codeBinding
time0..1dateTime
party0..1Reference(Patient| RelatedPerson| Practitioner| PractitionerRole| Organization)
custodianΣ0..1Reference(Organization)
code1..1codeBinding
targetIdentifierIdentifier
targetReferenceReference(Composition)
codeΣ0..*CodeableConcept
periodΣ0..1Period
detailΣ0..*Reference(Resource)
titleS1..1string
code0..1CodeableConcept
author0..*Reference(Practitioner| PractitionerRole| Device| Patient| RelatedPerson| Organization)
focus0..1Reference(Resource)
textS1..1Narrative
mode0..1codeBinding
orderedBy0..1CodeableConceptBinding
entry0..*Reference(Resource)
emptyReason0..1CodeableConceptBinding
sectionS0..*see (section)

Link Simplifier Profil Übersicht

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: Die Verwendung von OIDs ist möglich. Dafür KANN folgendes Format verwenden:

  • 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.context

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

<Composition xmlns="http://hl7.org/fhir">
    <id value="composition-blutdruck" />
    <meta>
        <profile value="https://gematik.de/fhir/ISiK/StructureDefinition/ISiKBerichtSubSysteme" />
    </meta>
    <text>
        <status value="extensions" />
        --- We have skipped the narrative for better readability of the resource ---
    </text>
    <identifier>
        <system value="urn:ietf:rfc:3986" />
        <value value="urn:oid:2.16.840.1.113883.6.96" />
    </identifier>
    <status value="final" />
    <type>
        <coding>
            <system value="http://loinc.org" />
            <code value="55112-7" />
        </coding>
    </type>
    <subject>
        <reference value="Patient/patient" />
    </subject>
    <encounter>
        <reference value="Encounter/encounter" />
    </encounter>
    <date value="2020-10-19" />
    <author>
        <type value="Device" />
        <display value="Ger&#228;t XY, Fa. Z, Modell T" />
    </author>
    <title value="Blutdruckmessung vom 19.10.2020" />
    <section>
        <title value="Messung" />
        <text>
            <status value="generated" />
            <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>
        </text>
        <!--  OBSERVATION AUF DIE HIER VERWIESEN WIRD EXISTIERT NOCH NICHT ALS EXAMPLE    -->
        <!--     <entry> -->
        <!--       <reference value="Observation/example2" /> -->
        <!--     </entry> -->
    </section>
</Composition>