### Anmerkungen zu Must-Support-Feldern

Feldname | Kurzbeschreibung | Hinweise
--- | --- | ---
DocumentReference.masterIdentifier | Versionsspezifische OID des Dokumentes |
DocumentReference.masterIdentifier.system | Namensraum des Identifiers | Fix: `urn:ietf:rfc:3986`
DocumentReference.masterIdentifier.value | Wert des Identifiers | OID mit URI-Präfix "urn:oid:"
DocumentReference.identifier |  | Abweichend zu MHD V4.0.1 ist die Angabe eines Identifiers in ISiK nicht erforderlich. Ein solcher kann bei Bedarf (z.B. zur Weitergabe des Dokumentes per XDS) erzeugt werden. [Konsens der Arbeitsgruppe vom 12.11.2021] Update für Stufe 3: In MHD 4.2.0 wurde die Verpflichtung zur Angabe eines Identifiers gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.
DocumentReference.status | Status des Dokumentenmetadatensatzes | Der Status des Dokumentes wird in DocumentReference.docStatus gesetzt!
DocumentReference.docStatus | Bearbeitungsstatus des Dokumentes | Abweichend zu MHD V4.0.1 ist die Verwendung von docStatus im ISiK-Kontext erlaubt. Doe Verwendung von docStatus bleibt jedoch optional, da nicht alle Dokumentenerzeugende Systeme einen expliziten Freigabe-Workflow haben. Dokumentenserver müssen jedoch in der Lage sein, den Dokumentenstatus (sofern vorhanden) zu persistieren, anzuzeigen und zu reproduzieren. [Konsens der Arbeitsgruppe vom 10.12.2021]
DocumentReference.type | Dokumententyp | Im ISiK-Kontext ist die Typisierung eines Dokumentes mit Hilfe eines KDL-Codes und des IHE-XDS-Type-Codes erforderlich. Während ersterer eine feingranulare Dokumentenklassifikation für die gezielte Suche nach medizinischen udn Administrativen Dokumenten ermöglicht, ist letzterer für den einrichtungsübergreifenden Dokumentenautausch 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 Arbeitgruppe vom 18.02.2022]
DocumentReference.type.coding:KDL | Dokumenttyp gem. KDL-Terminologie |
DocumentReference.type.coding:KDL.system | Kodiersystem | Fix: "http://dvmd.de/fhir/CodeSystem/kdl"
DocumentReference.type.coding:KDL.code | Code | Der KDL-Code
DocumentReference.type.coding:KDL.display | Anzeigetext | Der Anzeigetext zum KDL-Code
DocumentReference.type.coding:XDS | Dokumenttyp gem. IHE-De-Terminologie | Die Übermittlung des XDS-Type-Codes ist im Rahmen der Dokumentenbereitstellung für Clients nicht verpflichtend, muss jedoch vom Server bei der Entgegennahme ggf. ergänzt und bei der Dokumentenabfrage zurückgegeben werden. Der XDS-Type-Code kann über die im Rahmen der KDL-Spezifikation publizierten ConceptMaps aus dem KDL-Code ermittelt werden
DocumentReference.category | Dokumentklasse/-Kategorie | Die Kategorisierung von Dokumenten erfolgt mittels der von IHE Deutschland publizierten XDS-Class-Codes. Die übermittlung des XDS-Class-Codes ist im Rahmen der Dokumentenbereitstellung für Clients nicht verpflichtend, muss jedoch vom Server bei der Entgegennahme ggf. ergänzt und bei der Dokumentenabfrage zurückgegeben werden. Der XDS-Class-Code kann mit Hilfe der bereitgestellten ConceptMap aus dem KDL-Code ermittelt werden.
DocumentReference.category.coding:XDS |  |
DocumentReference.category.coding:XDS.system | Kodiersystem |
DocumentReference.category.coding:XDS.code | Code | Der XDS-Class-Code
DocumentReference.category.coding:XDS.display | Anzeigetext | Der Anzeigetext zum XDS-Class-Code
DocumentReference.subject | Patientenbezug des Dokumentes | Siehe Beschreibung in der FHIR Kernspezifikation
DocumentReference.subject.reference | Absolute oder relative URL des Patienten auf dem Server | Absolute oder relative URL des Patienten auf dem Server
DocumentReference.author | Autor des Dokumentes | In dieser Ausbaustufe ist die Nennung des Namens oder Kürzels des Autors ausreichend. Eine darüber hinaus gehende Verlinkung auf einen Pracitioner (auflösbar auf dem Server) ist möglich aber nicht erforderlich.
DocumentReference.author.display |  |
DocumentReference.relatesTo |  |
DocumentReference.description |  | Genaue menschenlesbare Beschreibung des Dokumentes, z.B. "Lungenfunktionstest vom 18.02.2022"
DocumentReference.securityLabel | Vertraulichkeit | Die Bereitstellung des Vertraulichkeitsinformation durch den Ersteller des Dokumentes ist verpflichtend. Ebenso sind Dokumentenserver verpflichtet, diese Information zu persistieren und bei der Dokumentenabfrage zu reproduzieren. Die ISiK-Spezifikation trifft jedoch keine Annahmen darüber, wie sich einzelne Vertraulichkeitsstufen auf die Zugriffsberechtigungen verschiedener benutzer auf ein Dokument auswirken. Im ISiK-Kontext ist die Angabe einer der drei Vertraulichkeitsstufen N | R | V verpflichtend, jedoch ohne Einschränkung der Verwendung zusätzlicher Vertraulichkeits-Flags. [Konsens der Arbeitsgruppe vom 12.11.2021]
DocumentReference.content | Beschreibung des Dokumenteninhaltes |
DocumentReference.content.attachment | Anhang |
DocumentReference.content.attachment.contentType | Mimetype des Dokumentes | Mimetype (Dateityp) des Dokumentes (z.B. "application/pdf")
DocumentReference.content.attachment.language | Sprache, in der das Dokument verfasst wurde. | Kann bei Systemen, die keine Mehrsprachigkeit unterstützen, fest auf "de" oder "de-DE" gesetzt werden.
DocumentReference.content.attachment.data | Base64-codierte Binärdaten | Um die Suche nach Dokumenten effizient zu gestalten, dürfen die Dokumente selbst nicht in die DocumentReference eingebettet werden, sondern müssen als separates Datenobjekt referenziert werden. Update für Stufe 3: Die Ausnahme bildet die Interaktion "Dokumentenbereitstellung", bei der die Binärdaten des Dokumentes eingebettet in die DocumentReference an den Server übermittelt und dort dann in eine separate Ressource ausgelagert und über Attachment.url referenziert werden.
DocumentReference.content.attachment.url | Referenz auf Dokument | Um die Suche nach Dokumenten effizient zu gestalten, dürfen die Dokumente selbst nicht in die DocumentReference eingebettet werden, sondern müssen als separates Datenobjekt referenziert werden. Update für Stufe 3: Die Ausnahme bildet die Interaktion "Dokumentenbereitstellung", bei der die Binärdaten des Dokumentes eingebettet in die DocumentReference an den Server übermittelt und dort dann in eine separate Ressource ausgelagert und über Attachment.url referenziert werden.
DocumentReference.content.attachment.creation | Dokumentendatum | Es obliegt dem erzeugenden System, zu entscheiden, welches Datum als Dokumentendatum geeignet ist, z.B. Datum der Erstellung oder Datum der letzten Änderung
DocumentReference.content.format | Format des Dokumentes | Sofern das Dokument nicht auf einem standardisierten, strukturierten Austauschformat (z.B. CDA) basiert, für dessen Interpretation ein konkretes Schema herangezogen werden muss, genügt die Angabe des Codes "urn:ihe:iti:xds:2017:mimeTypeSufficient"
DocumentReference.context |  |
DocumentReference.context.encounter |  | Abweichend zu MHD V4.0.1 ist die Verwendung der Encounter-Referenz im ISiK-Kontext erlaubt. Update für Stufe 3: In MHD 4.2.0 wurde das Verbot der Angabe einer Encounter-Referenz gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.
DocumentReference.context.facilityType | Art der Einrichtung, aus der das Dokument stammt | Kann, sofern keine abweichende Information bekannt ist auf "KHS" gesetzt werden.
DocumentReference.context.practiceSetting |  | Binding auf IHE-DE Terminologie hinzugefügt