Bschuetze: Die Seite wurde neu angelegt: „=DocumentEntry.formatCode= Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode soll der formatCode für hinreichende Information sorgen,…“

2015-06-10T12:35:04Z

Die Seite wurde neu angelegt: „=DocumentEntry.formatCode= Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode soll der formatCode für hinreichende Information sorgen,…“

Neue Seite

=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 
<code>urn:ihe:iti:</code> 
Beispiele hierzu finden sich im Wiki von IHE International ([http://wiki.ihe.net/index.php?title=IHE_Format_Codes http://wiki.ihe.net/index.php?title=IHE_Format_Codes]). Wenn andere IHE Domänen formatCodes definieren, so sollen sie das Präfix 
<code>urn:ihe:’domain initials’:</code> 
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 
<code>urn:ad:’creating entity’:</code> 
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 "<code>urn:ad:GesDe:</code>". 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<ref>RFC 3406 (2002) URN Namespace Definition Mechanisms. Online, verfügbar unter [http://tools.ietf.org/html/rfc3406 http://tools.ietf.org/html/rfc3406 http://tools.ietf.org/html/rfc3406]</ref>. 
formatCodes, welche von IHE Deutschland herausgegeben werden, haben immer das Präfix 
<code>urn:ihe-d:</code> 
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- http://art-decor.org/art-decor/decor-valuesets--ihede-]). 
Innerhalb von Deutschland sollen formatCodes dem nachfolgend beschriebenem Aufbau entsprechen. 
== CDA-Dokumente ==
{| class="hl7table"
|-
|CDA-Dokumente ohne binären Inhalt || <code>urn:ihe-d:’Bezeichner’:’Jahr’</code> bzw. <code>urn:ad:’creating entity’:’Bezeichner’:’Jahr’</code>
|-
|CDA-Dokumente mit einem Body, der aus einem binärem Inhalt besteht ||<code>urn:ihe-d:’Bezeichner’:’Jahr’:’nonXmlBody’</code> bzw. <code>urn:ad:’creating entity’:’Bezeichner’:’Jahr’:’nonXmlBody’</code>
|-
|CDA-Dokumente mit einem Body, der aus einer XML-Inhalten und mind. einer eingebettenen binärem Datei besteht || <code>urn:ihe-d:’Bezeichner’:’Jahr’:’crossXmlBody’</code> bzw. <code>urn:ad:’creating entity’:’Bezeichner’:’Jahr’:’crossXmlBody’</code>
|}
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 <code>urn:ihe-d:pcc:arztbrief:2014</code> 
# Arztbrief: Level 1 CDA mit Body bestehend aus einer PDF-Datei ([http://wiki.hl7.de/index.php?title=cdaab2:Beispiel_(vollst%C3%A4ndig) http://wiki.hl7.de/index.php?title=cdaab2:Beispiel_(vollst%C3%A4ndig)]) <code>urn:ihe-d:pcc:arztbrief:2014:nonXmlBody</code> 
# Arztbrief: sowohl mit XML-Inhalt wie auch mindestens einer eingebetteten binären Datei
<code>urn:ihe-d:pcc:arztbrief:2014:crossXmlBody</code> 
== 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<ref>Internet Assigned Numbers Authority (IANA). Media Types. Online, verfügbar unter [http://www.iana.org/assignments/media-types/media-types.xhtml http://www.iana.org/assignments/media-types/media-types.xhtml]</ref> genutzt werden:
{| class="hl7table"
|-
|IHE Deutschland ||<code>urn:ihe-d:‘Bezeichner‘:Jahr</code> urn:ihe-d:‘mime‘:Jahr</code>
|-
|Betreiber einer XDS-Domäne ||<code>urn:ad:’creating entity’:’Bezeichner’</code> <code>urn:ad:’creating entity’:’mime’</code> <code>urn:ad:’pdfA1’</code> 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 "<code>urn:ihe-d:application/pdf</code> 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: "<code>urn:ihe-d:PDF/A-1</code>" 
In beiden Fällen kommt "/" vor, was in dieser Form nicht in einer URN verwendet werden darf<ref>RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter [http://tools.ietf.org/html/rfc2288 http://tools.ietf.org/html/rfc2288]</ref>. Entsprechend Kapitel 5.2 "Encoding Considerations and Lexical Equivalence" von RFC 2288 muss "/" %-encoded werden (siehe auch RFC 2141<ref>RFC 2141 (1997).URN Syntax. Online, verfügbar unter [https://www.ietf.org/rfc/rfc2141.txt https://www.ietf.org/rfc/rfc2141.txt]</ref>). 
Dementsprechend sind die Angaben aus dem Beispiel wie folgt umzusetzen (%2F repräsentiert „/“, siehe RFC 3151<ref>RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter [https://tools.ietf.org/html/rfc3151 https://tools.ietf.org/html/rfc3151]</ref>):
# <code>urn:ihe-d:application %2Fpdf</code>
# <code>urn:ihe-d:PDF %2FA-1</code>

== Fußnoten ==
<references />

FormatCode bei Dokumenten - Versionsgeschichte

Bschuetze: Die Seite wurde neu angelegt: „=DocumentEntry.formatCode= Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode soll der formatCode für hinreichende Information sorgen,…“