Ihevs:DocumentEntry.formatCode

Aus Hl7wiki
(Teildokument von )
Wechseln zu: Navigation, Suche
(Initialfassung)
 
K
 
(29 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=DocumentEntry.formatCode=
+
{{DocumentPart}}
 +
==DocumentEntry.formatCode==
  
Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode soll der formatCode für hinreichende Information sorgen, um einem potenziellen XDS-Dokument-Verbraucher die Entscheidung zu ermöglichen, ob er das Dokumentenformat verarbeiten kann.
+
Das Attribut 'formatCode' spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.
  
Das formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes zu gewährleisten. D.h. die jeweiligen Werte des formatCodes stellen eine Sammlung von Schlüsselwörtern dar, die dem Anwender der Dokumente die Bedeutung der Dokumentenart erläutert.
+
Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumenten zu gewährleisten.
  
formatCodes können durch verschiedene Organisationen definiert werden, insbesondere durch die Betreiber einer XDS-Domäne.
+
===Vergabe von formatCodes===
 +
 
 +
formatCodes können durch verschiedene Organisationen, insbesondere durch IHE International, IHE Deutschland, HL7 Deutschland oder die Betreiber einer XDS-Domäne definiert werden. Die vergebende Organisation legt den Aufbau des Codes fest. Die einzige Vorgabe für alle vergebenden Organisationen besteht darin, dass eine eindeutige URN verwendet werden soll.
 +
 
 +
===Umfang des IHE Deutschland formatCode ValueSets===
 +
 
 +
Das ValueSet hat die OID 1.2.276.0.76.11.35 und setzt sich aus Codes von IHE International, IHE Deutschland, HL7, HL7 Deutschland sowie weiteren Organisationen zusammen.
 +
 
 +
===Aufbau der formatCodes===
 +
====Aufbau der durch IHE International vergebenen formatCodes====
  
 
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix
 
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix
Zeile 11: Zeile 21:
 
  urn:ihe:iti:
 
  urn:ihe:iti:
  
Beipiele hierzu finden sich im Wiki von IHE International (http://wiki.ihe.net/index.php?title=IHE_Format_Codes). Wenn andere IHE Domänen formatCodes definieren, so sollen sie das Präfix
+
Beispiel: urn:ihe:iti:xds-sd:pdf:2008. Beipiele hierzu finden sich im Wiki von IHE International (http://wiki.ihe.net/index.php?title=IHE_Format_Codes). Wenn andere IHE Domänen formatCodes definieren, so sollen sie das Präfix
  
 
  urn:ihe:’domain initials’:
 
  urn:ihe:’domain initials’:
  
benutzen, wobei „domain initials“ die Domäne selbst repräsentiert. Wenn ein Betreiber einer XDS-Domäne einen eigenen formatCode definiert, so muss das Präfix
+
benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.
  
urn:ad:’creating entity’:
+
====Aufbau der durch IHE Deutschland vergebenen formatCodes====
  
verwendet werden, wobei „creating entity“ die definierende Institution vertritt. Definiert beispielsweise die Domäne „Gesundheitsversorgung Deutschland“, welche die Abkürung „GesDe“ nutzt, formatCodes, so lautet das Präfix „urn:ad:GesDe:“. Idealerweise wird für die AD die OID verwendet, da die OID der AD im Gegensatz zu freitextlichen Bezeichnern immer eindeutig ist. Damit wird zugleich die Vorgabe bzgl. der Vergabe des namespace identifier entsprochen, dass dieser mehr als zwei Zeichen umfassen muss .
+
formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix
 
 
formatCodes, welche von IHE Deutschland herausgegeben werden, haben immer das Präfix
 
  
 
  urn:ihe-d:
 
  urn:ihe-d:
  
URN-Codes können außerhalb des Einsatzes für formatCodes auch für andere Zwecke verwendet werden. Daher werden die URN-Codes in zwei URN-Codesystemen angegeben: 1) MIME-Codes, 2) Non-MIME-Codes. MIME-Types wird immer das Präfix „urn:ihe-d:mime:“ vorangestellt, Non-MIME-Codes das Präfix „urn:ihe-d:xxxyyyzzz:“. Aus diesen Codesystemen sowie aus international verfügbaren Angaben von IHE zum Einsatz von formatCodes wird das ValueSet für formatCodes zusammengestellt.
+
Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:
  
Die Codes für das ValueSet „formatCode“ werden in art-decor zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-).
+
=====Aufbau für CDA-Dokumente=====
  
Innerhalb von Deutschland sollen URN-Codes dem folgenden Aufbau genügen:
 
 
==CDA-Dokumente==
 
 
{| border=1
 
{| border=1
 
|-
 
|-
 
|CDA-Dokumente ohne binärem Inhalt
 
|CDA-Dokumente ohne binärem Inhalt
 
|
 
|
  urn:ihe-d:xxxyyyzzz:’Bezeichner’:’Jahr’
+
  urn:ihe-d:ig:'Bezeichner':'Jahr'
bzw.
 
urn:ad:’creating entity’:’Bezeichner’:’Jahr’
 
 
|-
 
|-
 
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht
 
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht
 
|
 
|
  urn:ihe-d:xxxyyyzzz:’Bezeichner’:’Jahr’:’nonXmlBody’
+
  urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody
bzw.
 
urn:ad:’creating entity’:’Bezeichner’:’Jahr’:’nonXmlBody’
 
 
|-
 
|-
 
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei  besteht
 
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei  besteht
 
|
 
|
  urn:ihe-d:xxxyyyzzz:’Bezeichner’:’Jahr’:’crossXmlBody’
+
  urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody
bzw.
 
urn:ad:’creating entity’:’Bezeichner’:’Jahr’:’crossXmlBody’
 
 
|}
 
|}
  
wobei „Bezeichner“ für den Inhalt des Dokumentes steht, „Jahr“ für das Jahr der Veröffentlichung. Sollten innerhalb eines Jahres mehr als eine Version erscheinen, wird zusätzlich die zweistellige Monatszahl der Angabe des Jahres hinzugefügt, getrennt von einem Bindestrich -. (Beispiel: 2010-07).
+
„ig“ ist die feste Abkürzung für Implementierungsleitfäden (implementation guide). 'Bezeichner' und 'Jahr' sollen Platzhalter für den Inhalt des Dokuments und für das Jahr der Veröffentlichung sein. Sollten innerhalb eines Jahres mehrere Versionen erscheinen, wird der Angabe des Jahres zusätzlich eine zweistellige Monatszahl, getrennt von einem Bindestrich, '-'. hinzugefügt (Beispiel: 2010-07).
 +
 
 +
Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:
  
Beispiel: Der 2014 von HL7 Deutschland veröffentlichte CDA-Arztbrief wird entsprechend der obigen Beschreibung wie folgt abgebildet:
+
a) Verordnung: Level 1-3 ohne binärem Inhalt
 +
urn:ihe-d:ig:Verordnung:2016
 +
b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([[IG:CDA_und_PDF/A3]])
 +
urn:ihe-d:ig:Verordnung:2016:nonXmlBody
 +
c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei
 +
urn:ihe-d:ig:Verordnung:2016:crossXmlBody
  
a) Arztbrief: Level1-3 ohne binärem Inhalt
+
=====Aufbau für nicht CDA-Dokumente=====
urn:ihe-d:pcc:arztbrief:2014
 
b) Arztbrief: Level 1 CDA mit Body bestehend aus einer PDF-Datei (http://wiki.hl7.de/index.php?title=cdaab2:Beispiel_(vollst%C3%A4ndig))
 
urn:ihe-d:pcc:arztbrief:2014:nonXmlBody
 
c) Arztbrief: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei
 
urn:ihe-d:pcc:arztbrief:2014:crossXmlBody
 
  
==Nicht CDA-Dokumente==
+
Nicht-CDA-Dokumente sollten über eine möglichst genaue Beschreibung des Dokumentenformats abgebildet werden, sobald der MIME Type allein das Format des Dokuments nicht ausreichend beschreibt.
  
Nicht CDA-Dokumente sollten über eine möglichst genaue Beschreibung des Dokumentenformats abgebildet werden. Ist dies nicht möglich, so soll der MIME-Type entsprechen der Liste von IANA  genutzt werden:
 
 
{| border=1
 
{| border=1
 
|-
 
|-
 
|IHE Deutschland
 
|IHE Deutschland
 
|
 
|
  urn:ihe-d:xxxyyyzzz:‘Bezeichner‘:Jahr
+
  urn:ihe-d:ig:'Bezeichner':'Jahr'
  urn:ihe-d:mime:‘mime‘:Jahr
+
  urn:ihe-d:spec:'Bezeichner':'Jahr'
|-
+
|}
|Betreiber einer XDS-Domäne
+
 
|
+
„ig“ ist die feste Abkürzung für Implementierungsleitfäden (implementation guide), „spec“ für eine Spezifikation (specification). Auch hier sind 'Bezeichner' und 'Jahr' Platzhalter für den Inhalt des Dokumentes bzw. für das Jahr der Veröffentlichung, welches wann immer möglich angegeben werden sollte. Werden innerhalb eines Jahres mehrere Versionen des Formates veröffentlicht, so wird auch hier zusätzlich die zweistellige Monatszahl der Angabe des Jahres hinzugefügt, getrennt von einem Bindestrich '-' (Beispiel: 2010-07).
  urn:ad:’creating entity’:’Bezeichner’
+
 
urn:ad:’creating entity’:’mime’
+
Falls der MIME Type allein das Format des Dokuments ausreichend beschreibt, wird dies im formatCode durch die fest vorgegebene URN „urn:ihe:iti:xds:2017:mimeTypeSufficient“ ausgedrückt. Der MIME Type selbst wird in den IHE Document Sharing Metadaten bei DocumentEntry.mimeType angegeben. Die URN „urn:ihe:iti:xds:2017:mimeTypeSufficient“ wurde von IHE International im Dezember 2017 festgelegt und ist Teil der Revision 15 des IHE ITI Technical Frameworks. Der äquivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt daher als "deprecated" und sollte nicht mehr verwendet werden.
urn:ad:’pdfA1’
+
 
 +
'''Beispiel'''
 +
Um ein gewöhnliches PDF-Dokument in einer Document Registry zu registrieren, über dessen Aufbau (Strukturierung) keine weiteren Informationen vorhanden sind, werden der Format-Code (DocumentEntry.formatCode) „urn:ihe:iti:xds:2017:mimeTypeSufficient“ und der MIME Type (DocumentEntry.mimeType) „application/pdf“ verwendet.
 +
 
 +
'''Sonderfall'''
 +
Die unterschiedlichen Ausprägungen des PDF Formats (z.B. PDF-A für elektronische Archivierung) benötigen eine gesonderte Behandlung. Da der MIME Type „application/pdf“ diese unterschiedlichen Ausprägungen nicht differenziert, nutzt IHE Deutschland in bestimmten Fällen statt des Codes „urn:ihe:iti:xds:2017:mimeTypeSufficient“ selbst definierte formatCodes. Beispiel: „urn:ihe-d:spec:PDF_A1:2005”.
 +
Wenn IHE Deutschland keinen formatCode für die verwendete PDF Ausprägung definiert hat (wie z.B. für PDF/X), wird der Code „urn:ihe:iti:xds:2017:mimeTypeSufficient“ als formatCode und „application/pdf“ als MIME Type verwendet.
 +
 
 +
====Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen====
 +
Wir empfehlen die Verwendung eines IANA-registrierten domain names als Namespace Identifier (NID: der Teil der URN, der auf „urn: “ folgt und bis zum nächsten Doppelpunkt reicht). Definiert beispielsweise die Domäne „Gesundheitsversorgung Deutschland“ formatCodes, lautet das Präfix „urn:gesde.de:“, da die Domäne die URL http://www.gesde.de verwendet. Eine weitere Unterstrukturierung des Namensraums (d.h. nach dem zweiten Doppelpunkt) in Anlehnung an die Vorgehensweise von IHE Deutschland wird empfohlen.
 +
 
 +
====formatCodes für FHIR Ressourcen====
 +
FHIR Ressourcen die über IHE XDS/XDR/XDM kommuniziert werden sollten die MIME Types "application/fhir+xml" für die XML Repräsentation und "application/fhir+json" für die JSON Repräsentation verwenden. Für einfache Ressourcen ist dies ausreichend, daher kann "urn:ihe:iti:xds:2017:mimeTypeSufficient" als formatCode verwendet werden. Bei Verwendung von FHIR Documents (http://hl7.org/fhir/documents.html) und ähnlichen Repräsentationen mit Dokumentencharakter wird der Einsatz eines spezifischeren formatCodes empfohlen. Von IHE Deutschland definierte formatCodes für FHIR Dokumentenleitfäden werden den oben dargestellten Vorgehen für CDA-Leitfäden ohne binären Inhalt folgen, d.h. urn:ihe-d:ig:'Bezeichner':'Jahr'.
 +
 
  
Bezeichner = Typisierung des Formats, wenn kein genauerer Bezeichner da ist, Angabe mime-type
 
|}
 
  
Auch hier steht „Bezeichner“ für den Inhalt des Dokumentes und „Jahr“ für das Jahr der Veröffentlichung, welches wann immer möglich angegeben werden sollte. Werden innerhalb eines Jahres mehr als eine Version des Formates veröffentlicht, so wird auch hier zusätzlich die zweistellige Monatszahl der Angabe des Jahres hinzugefügt, getrennt von einem Bindestrich ‘-. (Beispiel: 2010-07).
+
Die Codes für das ValueSet werden in ART-DECOR zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-) und hier eingebunden. Bei Darstellungsproblemen der eingebundenen Wertelisten kommen, finden Sie die Inhalte auf [[https://art-decor.org/art-decor/decor-valuesets--ihede-?id=1.2.276.0.76.11.35&effectiveDate=2018-07-13T16:16:59&language=de-DE ART-DECOR]].
  
Beispiel: um ein pdf darzustellen kann der Format-Code „urn:ihe-d:mime:application/pdf“ unter Nutzung des MIMe-Types verwendet werden. Spezifischer wäre die Nutzung eines Bezeichners „PDF/A-1“, um das hiermit bezeichnete pdf-Format für die elektronische Archivierung abzubilden: „urn:ihe-d:xxxyyyzzz:PDF/A-1“
+
{{:1.2.276.0.76.11.35/dynamic}}
In beiden Fällen kommt „/“ vor, was in dieser Form nicht in einer URN verwendet werden darf . Entsprechend Kapitel 5.2 „Encoding Considerations and Lexical Equivalence“ von RFC 2288 muss „/“ %-encoded werden (siehe auch RFC 2141 ).
 
Dementsprechend sind die Angaben aus dem Beispiel wie folgt umzusetzen (%2F repräsentiert „/“, siehe RFC 3151 ):
 
a) urn:ihe-d:application %2Fpdf
 
b) urn:ihe-d:PDF %2FA-1
 
 
  
==Links==
+
===Links===
 
* RFC 3406 (2002) URN Namespace Definition Mechanisms. Online, verfügbar unter http://tools.ietf.org/html/rfc3406*  Internet Assigned Numbers Authority (IANA). Media Types. Online, verfügbar unter  http://www.iana.org/assignments/media-types/media-types.xhtml
 
* RFC 3406 (2002) URN Namespace Definition Mechanisms. Online, verfügbar unter http://tools.ietf.org/html/rfc3406*  Internet Assigned Numbers Authority (IANA). Media Types. Online, verfügbar unter  http://www.iana.org/assignments/media-types/media-types.xhtml
 
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288
 
* RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288
Zeile 100: Zeile 106:
 
[[Kategorie:Enzyklopädie]]
 
[[Kategorie:Enzyklopädie]]
 
[[Kategorie:Abkürzungen|formatCode]]
 
[[Kategorie:Abkürzungen|formatCode]]
 +
[[Kategorie:ihevs]]

Aktuelle Version vom 31. März 2021, 09:02 Uhr

Dieses Material ist Teil des Leitfadens [[Category:|Ihevs:DocumentEntry.formatCode]].
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: [[:Category:|hier]], Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

DocumentEntry.formatCode

Das Attribut 'formatCode' spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.

Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumenten zu gewährleisten.

Vergabe von formatCodes

formatCodes können durch verschiedene Organisationen, insbesondere durch IHE International, IHE Deutschland, HL7 Deutschland oder die Betreiber einer XDS-Domäne definiert werden. Die vergebende Organisation legt den Aufbau des Codes fest. Die einzige Vorgabe für alle vergebenden Organisationen besteht darin, dass eine eindeutige URN verwendet werden soll.

Umfang des IHE Deutschland formatCode ValueSets

Das ValueSet hat die OID 1.2.276.0.76.11.35 und setzt sich aus Codes von IHE International, IHE Deutschland, HL7, HL7 Deutschland sowie weiteren Organisationen zusammen.

Aufbau der formatCodes

Aufbau der durch IHE International vergebenen formatCodes

formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix

urn:ihe:iti:

Beispiel: urn:ihe:iti:xds-sd:pdf:2008. Beipiele hierzu finden sich im Wiki von IHE International (http://wiki.ihe.net/index.php?title=IHE_Format_Codes). Wenn andere IHE Domänen formatCodes definieren, so sollen sie das Präfix

urn:ihe:’domain initials’:

benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.

Aufbau der durch IHE Deutschland vergebenen formatCodes

formatCodes, welche von IHE Deutschland definiert werden, haben immer das Präfix

urn:ihe-d:

Von IHE Deutschland festgelegte formatCodes werden wie folgt aufgebaut:

Aufbau für CDA-Dokumente
CDA-Dokumente ohne binärem Inhalt
urn:ihe-d:ig:'Bezeichner':'Jahr'
CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht
urn:ihe-d:ig:'Bezeichner':'Jahr':nonXmlBody
CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht
urn:ihe-d:ig:'Bezeichner':'Jahr':crossXmlBody

„ig“ ist die feste Abkürzung für Implementierungsleitfäden (implementation guide). 'Bezeichner' und 'Jahr' sollen Platzhalter für den Inhalt des Dokuments und für das Jahr der Veröffentlichung sein. Sollten innerhalb eines Jahres mehrere Versionen erscheinen, wird der Angabe des Jahres zusätzlich eine zweistellige Monatszahl, getrennt von einem Bindestrich, '-'. hinzugefügt (Beispiel: 2010-07).

Beispiel: Sollte IHE Deutschland 2016 ein eigenes CDA-Dokument für eine Verordnung veröffentlichen, wird dieses entsprechend der obigen Beschreibung wie folgt abgebildet:

a) Verordnung: Level 1-3 ohne binärem Inhalt

urn:ihe-d:ig:Verordnung:2016

b) Verordnung: Level 1 CDA mit Body bestehend aus einer PDF-Datei (IG:CDA_und_PDF/A3)

urn:ihe-d:ig:Verordnung:2016:nonXmlBody

c) Verordnung: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei

urn:ihe-d:ig:Verordnung:2016:crossXmlBody
Aufbau für nicht CDA-Dokumente

Nicht-CDA-Dokumente sollten über eine möglichst genaue Beschreibung des Dokumentenformats abgebildet werden, sobald der MIME Type allein das Format des Dokuments nicht ausreichend beschreibt.

IHE Deutschland
urn:ihe-d:ig:'Bezeichner':'Jahr'
urn:ihe-d:spec:'Bezeichner':'Jahr'

„ig“ ist die feste Abkürzung für Implementierungsleitfäden (implementation guide), „spec“ für eine Spezifikation (specification). Auch hier sind 'Bezeichner' und 'Jahr' Platzhalter für den Inhalt des Dokumentes bzw. für das Jahr der Veröffentlichung, welches wann immer möglich angegeben werden sollte. Werden innerhalb eines Jahres mehrere Versionen des Formates veröffentlicht, so wird auch hier zusätzlich die zweistellige Monatszahl der Angabe des Jahres hinzugefügt, getrennt von einem Bindestrich '-' (Beispiel: 2010-07).

Falls der MIME Type allein das Format des Dokuments ausreichend beschreibt, wird dies im formatCode durch die fest vorgegebene URN „urn:ihe:iti:xds:2017:mimeTypeSufficient“ ausgedrückt. Der MIME Type selbst wird in den IHE Document Sharing Metadaten bei DocumentEntry.mimeType angegeben. Die URN „urn:ihe:iti:xds:2017:mimeTypeSufficient“ wurde von IHE International im Dezember 2017 festgelegt und ist Teil der Revision 15 des IHE ITI Technical Frameworks. Der äquivalente, von IHE Deutschland eingeführte formatCode "urn:ihe-d:mime" gilt daher als "deprecated" und sollte nicht mehr verwendet werden.

Beispiel Um ein gewöhnliches PDF-Dokument in einer Document Registry zu registrieren, über dessen Aufbau (Strukturierung) keine weiteren Informationen vorhanden sind, werden der Format-Code (DocumentEntry.formatCode) „urn:ihe:iti:xds:2017:mimeTypeSufficient“ und der MIME Type (DocumentEntry.mimeType) „application/pdf“ verwendet.

Sonderfall Die unterschiedlichen Ausprägungen des PDF Formats (z.B. PDF-A für elektronische Archivierung) benötigen eine gesonderte Behandlung. Da der MIME Type „application/pdf“ diese unterschiedlichen Ausprägungen nicht differenziert, nutzt IHE Deutschland in bestimmten Fällen statt des Codes „urn:ihe:iti:xds:2017:mimeTypeSufficient“ selbst definierte formatCodes. Beispiel: „urn:ihe-d:spec:PDF_A1:2005”. Wenn IHE Deutschland keinen formatCode für die verwendete PDF Ausprägung definiert hat (wie z.B. für PDF/X), wird der Code „urn:ihe:iti:xds:2017:mimeTypeSufficient“ als formatCode und „application/pdf“ als MIME Type verwendet.

Empfehlungen von IHE Deutschland für den Aufbau von formatCodes für andere Organisationen

Wir empfehlen die Verwendung eines IANA-registrierten domain names als Namespace Identifier (NID: der Teil der URN, der auf „urn: “ folgt und bis zum nächsten Doppelpunkt reicht). Definiert beispielsweise die Domäne „Gesundheitsversorgung Deutschland“ formatCodes, lautet das Präfix „urn:gesde.de:“, da die Domäne die URL http://www.gesde.de verwendet. Eine weitere Unterstrukturierung des Namensraums (d.h. nach dem zweiten Doppelpunkt) in Anlehnung an die Vorgehensweise von IHE Deutschland wird empfohlen.

formatCodes für FHIR Ressourcen

FHIR Ressourcen die über IHE XDS/XDR/XDM kommuniziert werden sollten die MIME Types "application/fhir+xml" für die XML Repräsentation und "application/fhir+json" für die JSON Repräsentation verwenden. Für einfache Ressourcen ist dies ausreichend, daher kann "urn:ihe:iti:xds:2017:mimeTypeSufficient" als formatCode verwendet werden. Bei Verwendung von FHIR Documents (http://hl7.org/fhir/documents.html) und ähnlichen Repräsentationen mit Dokumentencharakter wird der Einsatz eines spezifischeren formatCodes empfohlen. Von IHE Deutschland definierte formatCodes für FHIR Dokumentenleitfäden werden den oben dargestellten Vorgehen für CDA-Leitfäden ohne binären Inhalt folgen, d.h. urn:ihe-d:ig:'Bezeichner':'Jahr'.


Die Codes für das ValueSet werden in ART-DECOR zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-) und hier eingebunden. Bei Darstellungsproblemen der eingebundenen Wertelisten kommen, finden Sie die Inhalte auf [ART-DECOR].


Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.
Id1.2.276.0.76.11.35Gültigkeit2022‑03‑04 12:58:48
Canonical URIhttp://ihe-d.de/ValueSets/IHEXDSformatCodeDE
StatusKyellow.png EntwurfVersions-Labelv4 draft
NameIHEXDSformatCodeDEBezeichnungIHE XDS formatCode
Beschreibung
EN-US.png formatCode (XDSDocumentEntry)
Globally unique code specifying the format of an XDS Document. Along with the typeCode, it should provide sufficient information to allow a potential consumer to know if it will be able to process the document.
3 Quell-Codesysteme
1.3.6.1.4.1.19376.3.276.1.5.6 - Deutsche Dokumentenformate - FHIR: urn:oid:1.3.6.1.4.1.19376.3.276.1.5.6
1.2.840.10008.2.6.1 - DICOM UID - FHIR: urn:oid:1.2.840.10008.2.6.1
1.3.6.1.4.1.19376.1.2.3 - IHE.FormatCode.cs - FHIR: http://ihe.net/fhir/ValueSet/IHE.FormatCode.codesystem
Level/ TypCodeBezeichnung / Intentionale DefinitionCodesystemDesignationsBeschreibung
 
Circleplus.png Einfügen
Value Set 1.2.276.0.76.11.71 Flexibilität 2018-07-13T17:06:39
0‑L
Medical Summaries (XDS-MS)
IHE.FormatCode.cs
0‑L
Exchange of Personal Health Records (XPHR)
IHE.FormatCode.cs
0‑L
Emergency Department Referral (EDR)
IHE.FormatCode.cs
0‑L
Antepartum Summary (APS)
IHE.FormatCode.cs
0‑L
Emergency Department Encounter Summary (EDES)
IHE.FormatCode.cs
0‑L
Antepartum History and Physical (APHP)
IHE.FormatCode.cs
0‑L
Antepartum Laboratory (APL)
IHE.FormatCode.cs
0‑L
Antepartum Education (APE)
IHE.FormatCode.cs
0‑L
Immunization Content (IC)
IHE.FormatCode.cs
0‑L
Care Management (CM)
IHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑LIHE.FormatCode.cs
0‑L
Scanned Documents (PDF)
IHE.FormatCode.cs
0‑L
Scanned Documents (text)
IHE.FormatCode.cs
0‑L
Basic Patient Privacy Consents
IHE.FormatCode.cs
0‑L
Basic Patient Privacy Consents with Scanned Document
IHE.FormatCode.cs
0‑L
APPC Privacy Consent Document
IHE.FormatCode.cs
0‑L
XDW Workflow Document
IHE.FormatCode.cs
0‑L
DSG Detached Document
IHE.FormatCode.cs
0‑L
DSG Enveloping Document
IHE.FormatCode.cs
0‑L
CDA Laboratory Report
IHE.FormatCode.cs
0‑L
XDS-I CDA Wrapped Text Report (XDS-I)
IHE.FormatCode.cs
0‑L
XDS-I PDF (XDS-I)
IHE.FormatCode.cs
0‑L
XDS-I Imaging Report with Structured Headings (XDS-I)
IHE.FormatCode.cs
0‑L
Cardiology ??? (CRC)
IHE.FormatCode.cs
0‑L
Cardiology ??? (EPRC-IE)
IHE.FormatCode.cs
0‑L
Cardiac Imaging Report
IHE.FormatCode.cs
0‑L
Dental CDA Wrapped Text Report (DENT)
IHE.FormatCode.cs
0‑L
Dental PDF (DENT)
IHE.FormatCode.cs
0‑L
Dental Imaging Report with Structured Headings (DENT)
IHE.FormatCode.cs
0‑L
Anatomic Pathology Structured Report (APSR)
IHE.FormatCode.cs
0‑L
Pharmacy ??? (urn:ihe:pharm:pre:2010)
IHE.FormatCode.cs
0‑L
Pharmacy ??? (urn:ihe:pharm:padv:2010)
IHE.FormatCode.cs
0‑L
Pharmacy ??? (urn:ihe:pharm:dis:2010)
IHE.FormatCode.cs
0‑L
Pharmacy ??? (urn:ihe:pharm:pml:2013)
IHE.FormatCode.cs
0‑L
1.2.840.10008.5.1.4.1.1.88.59
DICOM Manifest (DICOM KOS SOP Class UID)
DICOM UID
0‑L
Format aus MIME Type ableitbar
IHE.FormatCode.cs
0‑L
Entlassmanagementbrief
Deutsche Dokumentenformate
0‑L
NotaufnahmeregisterTraumamodul
Deutsche Dokumentenformate
0‑L
NotaufnahmeregisterBasismodul
Deutsche Dokumentenformate
0‑L
Meldepflichtige Krankheiten: Labormeldung
Deutsche Dokumentenformate
0‑L
Übermittlung meldepflichtiger Krankheiten – Arztmeldung
Deutsche Dokumentenformate
0‑L
Ärztlicher Reha-Entlassungsbericht
Deutsche Dokumentenformate
0‑L
Überleitungsmanagement Ärztlicher Kurzbericht über den Krankenhausaufenthalt
Deutsche Dokumentenformate
0‑L
Überleitungsmanagement Ärztlicher Kurzbericht des niedergelassenen Arztes
Deutsche Dokumentenformate
0‑L
Medikationsplan
Deutsche Dokumentenformate
0‑L
Arztbrief plus
Deutsche Dokumentenformate
0‑L
Arztbrief 2014
Deutsche Dokumentenformate
0‑L
Enhanced Patient Privacy Consent - Germany
Deutsche Dokumentenformate
0‑L
Enhanced Patient Privacy Consent - Germany - Scanned Document Option
Deutsche Dokumentenformate
0‑L
PDF/A-1
Deutsche DokumentenformatePDF Format für die elektronische Archivierung nach ISO 19005-1:2005
0‑L
PDF/A-2
Deutsche DokumentenformatePDF Format für die elektronische Archivierung nach ISO 19005-2
0‑L
PDF/A-3
Deutsche DokumentenformatePDF Format für die elektronische Archivierung nach ISO 19005-3
0‑L
PDF/UA
Deutsche DokumentenformateBarrierefreies PDF nach ISO 14289
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: durch MIME Type beschrieben
Dieser Code wurde verwendet, wenn das Dokumentenformat ausreichend durch den MIME Type beschrieben war. Dafür gibt es nun den internationalen Code "urn:ihe:iti:xds:2017:mimeTypeSufficient" mit Code System 1.3.6.1.4.1.19376.1.2.3. Daher gilt dieser code als obsolet (engl. "deprecated") und sollte nicht mehr für neue Dokumente verwendet werden.
0‑L
Arztbrief § 291f SGB V
Deutsche Dokumentenformate
0‑L
Medikationsplan (gematik)
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Verodnungsdatensatz Medikation (gematik)
0‑L
Notfalldatensatz
Deutsche Dokumentenformate
0‑L
Datensatz für persönliche Erklärungen (gematik)
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Impfausweis (gematik)
0‑L
Impfausweis (gematik)
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Mutterpass (gematik)
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Mutterpass (gematik)
0‑L
Mutterpass (gematik)
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Kinderuntersuchungsheft (gematik)
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Kinderuntersuchungsheft (gematik)
0‑L
Untersuchungen Kinderuntersuchungsheft
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Zahnbonusheft (gematik)
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Zahnbonusheft (gematik)
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Arbeitsunfähigkeitsbescheinigung (gematik)
0‑L
Arbeitsunfähigkeitsbescheinigung (gematik) v1.1
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Verordnungsdatensatz Medikation (gematik)
0‑L
rn:gematik:ig:VerordnungsdatensatzMedikation:v1.1
Verordnungsdatensatz Medikation (gematik) v1.1
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Untersuchungen Kinderuntersuchungsheft
0‑L
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Untersuchungen Kinderuntersuchungsheft
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Teilnahmekarte Kinderuntersuchungsheft
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Teilnahmekarte Kinderuntersuchungsheft
0‑L
Teilnahmekarte Kinderuntersuchungsheft
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Notizen Kinderuntersuchungsheft
0‑D
obsolet
Deutsche Dokumentenformate
DE-DE.png Synonym: Notizen Kinderuntersuchungsheft
0‑L
Notizen Kinderuntersuchungsheft
Deutsche Dokumentenformate
0‑L
DGUV Stationärer Entlassbrief
Deutsche Dokumentenformate
0‑L
Zahnbonusheft (gematik)
Deutsche Dokumentenformate
0‑D
obsolet
Deutsche Dokumentenformate
0‑L
DiGA (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Asthma (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Herzinsuffizienz (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Rückenschmerz (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Chronic Obstrusive Pulmonary Disease (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Depression (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Diabetes mellitus Typ 1 (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Diabetes mellitus Typ 2 (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Koronare Herzkrankheit (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Osteoporose (gematik)
Deutsche Dokumentenformate
0‑L
eDMP Rheumatoide Arthritis (gematik)
Deutsche Dokumentenformate
0‑L
Telemedizinisches Monitoring (gematik)
Deutsche Dokumentenformate
0‑L
Pflegeüberleitungsbogen (gematik)
Deutsche Dokumentenformate
0‑L
Patientenkurzakte (gematik) v1.0
Deutsche Dokumentenformate

Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.


Links