FormatCode bei Dokumenten
Inhaltsverzeichnis
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 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.
formatCodes können durch verschiedene Organisationen definiert werden, insbesondere durch die Betreiber einer XDS-Domäne.
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix
urn:ihe:iti:
Beispiele 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. Wenn ein Betreiber einer XDS-Domäne einen eigenen formatCode definiert, so muss das Präfix
urn:ad:’creating entity’:
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[1].
formatCodes, welche von IHE Deutschland herausgegeben werden, haben immer das Präfix
urn:ihe-d:
Die Codes werden in art-decor zusammen mit den anderen von IHE Deutschland erstellten ValueSets veröffentlicht (http://art-decor.org/art-decor/decor-valuesets--ihede-).
Innerhalb von Deutschland sollen formatCodes dem nachfolgend beschriebenem Aufbau entsprechen.
CDA-Dokumente
| CDA-Dokumente ohne binären Inhalt | urn:ihe-d:’Bezeichner’:’Jahr’bzw. urn:ad:’creating entity’:’Bezeichner’:’Jahr’
|
| CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht | urn:ihe-d:’Bezeichner’:’Jahr’:’nonXmlBody’bzw.< br /> 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 | urn:ihe-d:’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).
Beispiel: Der 2014 von HL7 Deutschland veröffentlichte CDA-Arztbrief wird entsprechend der obigen Beschreibung wie folgt abgebildet:
- Arztbrief: Level1-3 ohne binärem Inhalt
urn:ihe-d:pcc:arztbrief:2014 - 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 - 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. Ist dies nicht möglich, so soll der MIME-Type entsprechen der Liste von IANA[2] genutzt werden:
| IHE Deutschland | urn:ihe-d:‘Bezeichner‘:Jahrurn:ihe-d:‘mime‘:Jahr |
| Betreiber einer XDS-Domäne | urn:ad:’creating entity’:’Bezeichner’urn:ad:’creating entity’:’mime’urn:ad:’pdfA1’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. Sollten innerhalb eines Jahres mehr als eine Version des Formates veröffentlicht werden, so wird auch hier zusätzlich die zweistellige Monatszahl der Angabe des Jahres hinzugefügt, getrennt von einem Bindestrich ‘-‘. (Beispiel: 2010-07).
Beispiel: um ein pdf darzustellen kann der Format-Code "urn:ihe-d: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:PDF/A-1"
In beiden Fällen kommt "/" vor, was in dieser Form nicht in einer URN verwendet werden darf[3]. Entsprechend Kapitel 5.2 "Encoding Considerations and Lexical Equivalence" von RFC 2288 muss "/" %-encoded werden (siehe auch RFC 2141[4]).
Dementsprechend sind die Angaben aus dem Beispiel wie folgt umzusetzen (%2F repräsentiert „/“, siehe RFC 3151[5]):
urn:ihe-d:application %2Fpdfurn:ihe-d:PDF %2FA-1
Fußnoten
- ↑ RFC 3406 (2002) URN Namespace Definition Mechanisms. Online, verfügbar unter http://tools.ietf.org/html/rfc3406 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 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt
- ↑ RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151
