HTML-Repräsentation des Dokumenten-Headers.
Bitte Hinweise unter Document Presentation beachten.
Der DokumentenHeader muss mindestens die folgenden Informationen enthalten:

• 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

Eine vom erzeugenden Subsystem vergebene, eindeutige DokumentenID.
Wenn es sich bei dem verwendeten Identifier um eine OID oder UUID handelt, so ist hier der Wert urn:ietf:rfc:3986 anzugeben und in Identifier.value das jeweilige Präfix urn:uuid: bzw. urn:oid: zu verwenden.
Beispiel:

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

Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, aus dem der Identifier stammt. Hinweise zur Festlegung der URLs für lokale Namensräume sind in den Deutschen Basisprofilen beschrieben.
Begründung Pflichtfeld: system stellt in Kombination mit value die Eindeutigkeit eines Identifiers sicher.

Enthält den eigentlichen Wert des Identifiers.
Begründung Pflichtfeld: Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.

Im Kontext diese Moduls ist nur der Austausch finaler Berichte vorgesehen. Ein Mechanismus zur Änderung oder Ersetzung bereits übermittelter Daten ist derzeit nicht spezifiziert. Hier ist stets der Wert final anzugeben.

Begründung zu Must Support: Der Dokumenttyp ist für die Identifikation des Berichtes und die Zuordnung zu einem Subsystem für die weitere Verarbeitung erforderlich.

Hinweis für Implementierer: Der zu übermittelnde Bericht repräsentiert eine Zusammenfassung der strukturierten Daten aus dem Subsystem. Das Dokument KANN z.B. mittels KDL oder IHE-D-XDS-Typecodes klassifiziert werden.
Es KANN derzeit jedoch auch eine rein textuelle Beschreibung des Dokumenttyps angegeben werden.

Während KDL-Codes eine feingranulare Dokumentenklassifikation für die gezielte Suche nach medizinischen und Administrativen Dokumenten ermöglichen, sind IHE-XDS-Type-Codes für den einrichtungsübergreifenden Dokumentenaustausch maßgeblich. Der XDS-Type-Code kann mit Hilfe der bereitgestellten ConceptMaps aus dem KDL-Code ermittelt werden. Weitere Typisierungen (z.B. nach SNOMED oder LOINC) sind uneingeschränkt erlaubt. [Konsens der Arbeitsgruppe vom 18.02.2022]. Im Falle, dass der Code 'UNK' entsprechend der ConceptMap verwendet werden soll, MUSS das System 'http://terminology.hl7.org/CodeSystem/v3-NullFlavor' verwendet werden.

Freitextliche Beschreibung oder assoziierter Displaywert der primären Codierung des Dokumenttyps.

Begründung zu Must Support: Die Klassifizierung kann zur Strukturierung der Berichte genutzt werden, in dem Fall, dass das Narrative des Berichts dem Benutzer angezeigt wird. Das Dokument KANN z.B. mittels LOINC oder IHE-D-XDS-Classcodes klassifiziert werden.

Begründung Pflichtfeld: Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung des Dokumentes zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Begründung Pflichtfeld: Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
WICHTIGER Hinweis für Implementierer: Die Zuordnung MUSS auf auf einen Encounter der Ebene "Abteilungskontakt" (siehe hierzu Abbildung des Konstrukts "Fall") erfolgen. Bei der Auswahl des Encounters ist zu beachten, dass unter einer (Abrechnungs-)"Fallnummer" (hier: Encounter.account) unter Umständen mehrere Encounter gruppiert sein können (z.B. stationärer Besuch mit mehreren vor- und nachstationären Aufenthalten.)

Datum der letzten Änderung des Dokumentes

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

Freitextliche Bezeichnung des Verfassers (Person oder Subsystem/Gerät)

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"

Das Dokument kann in mehrere Kapitel und Unterkapitel gegliedert werden.

menschenlesbare HTML-Repräsentation des Inhalts dieses 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