elga-cdaxds-2.06.2:XDS Metadaten 2: explizit zu setzen (ELGA relevant)

1 XDS Metadaten 2: explizit zu setzen (ELGA relevant)

1.1 availabilityStatus

Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments.

Mögliche Werte laut IHE sind:

• Approved
• Deprecated

Dieses Attribut ist im Zuge des Einbringens von neuen Dokumenten („Submission“) immer auf “Approved” gesetzt.

1.2 formatCode (und formatCodeDisplayName)

Das formatCode Element beschreibt das Format des Dokuments bezüglich seiner semantischen Interoperabilität. Es ermöglicht einem empfangenden System (Document Consumer Actor) die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments.

Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung, die Information lässt sich aber gegebenenfalls aus dem Element clinicalDocument.templateId ableiten.

1.2.1 Dokumente in ELGA Interoperabilitätsstufe „Basic“ und „Structured“

Die Angabe der ELGA-Interoperabilitäts-Stufe erfolgt durch den entsprechenden Formatcode (EIS_Basic) gemäß der in ELGA gültigen Formatcodes, beschrieben im Value Set „ELGA_FormatCode_VS“ (OID 1.2.40.0.34.10.61).

In den XDS-Metadaten wird nicht zwischen den EIS Basic“ und „Structured“ unterschieden, da sie sich hinsichtlich der technischen und semantischen Interoperabilität gleich verhalten.

Die Angabe des eingebetteten Dokuments ist zusätzlich notwendig, siehe 2.3.2.3.

1.2.2 Dokumente in ELGA Interoperabilitätsstufe „Enhanced“ und „Full Support“

Die Angabe erfolgt gemäß der Liste der in ELGA gültigen Formatcodes mit zusätzlicher Angabe der ELGA-Interoperabilitäts-Stufe (EIS „Enhanced“, …).

Zulässige Werte gemäß Value Set „ELGA_FormatCode_VS“.
(aus der Codeliste ELGA_FormatCode 1.2.40.0.34.5.37)

Beispiele:

• urn:elga:dissum:2011:EIS_Enhanced
  • Gemäß dem Implementierungsleitfaden „Ärztlicher Entlassungsbrief“ [2], im ELGA-Interoperabilitätsstufe „Enhanced“ (Mindest-Stufe für strukturierte Dokumentinhalte).
• urn:elga:lab:2011:EIS_FullSupport
  • Gemäß dem Implementierungsleitfaden „Laborbefund“ [4], im ELGA-Interoperabilitätsstufe „Full Support“..

1.2.3 Dokumente in ELGA Interoperabilitätsstufe „Basic“: Zusatz erforderlich

Folgt ein ELGA CDA Dokument einem Implementierungsleitfaden einer Fachdomäne in ELGA-Interoperabilitätsstufe „Basic“, so enthält dieses Dokument entweder unstrukturierten oder strukturierten Text gemäß CDA Level 1 oder ein eingebettetes Objekt (PDF, JPEG-Grafik, etc.).

Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A 1a (gemäß „ISO 19005-1:2005 Level A conformance“) entsprechen.

Bemerkung: Folgt das Dokument lediglich den Basisanforderungen im Allgemeinen Implementierungsleitfaden „CDA Dokumente im österreichischen Gesundheitswesen“ [1], so liegt das Dokument implizit immer in der ELGA Interoperabilitätsstufe „Basic“ vor.

Im Fall eines Dokuments in ELGA Interoperabilitätsstufe „Basic“ MUSS der formatCode ebenfalls das „Format“ des unstrukturierten/eingebetteten Inhalts beinhalten. Das Format MUSS mittels „:“ (Doppelpunkt) am Ende angefügt werden.

Zulässige Zusätze gemäß Value Set „ELGA_FormatCodeZusatz_VS“.

Beispiel:

• urn:elga:dissum:2015-v2.06:EIS_Basic:PDF
  

Gemäß dem Implementierungsleitfaden „Entlassungsbrief Ärztlich“ [2], im ELGA-Interoperabilitätslevel „Basic“/„Structured“, das eingebettete Objekt liegt als im PDF/A vor.

1.2.4 Zusatz bei selbst-definierten maschinenlesbaren Elementen (Dokumente in EIS „Enhanced“ oder „Full Support“)

Liegt ein CDA Dokument in ELGA Interoperabilitätsstufe „Enhanced“ oder „Full Support“ vor und enthält das Dokument zusätzliche selbst-definierte maschinenlesbare Elemente (CDA Level 3 oder „Entries“)', so ist dies durch den Zusatz eines Plus-Zeichens („+“) im Formatcode zu kennzeichnen.

Die Kennzeichnung von Dokumenten mit selbst-definierten maschinenlesbaren Elementen ist ein „+“ (Plus-Zeichen) am Ende des Formatcodes.

Beispiele:

• urn:elga:dissum-n:2015-v2.06:EIS_Enhanced+
• urn:elga:lab:2015-v2.06:EIS_FullSupport+

1.2.5 Bildungsregel für den formatCodeDisplayName

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames der entsprechenden Value Sets zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels „:“ (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

Beispiele:

• ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF
• ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+
• ELGA Laborbefund, EIS Full Support v2.06+

1.2.6 Spezifikation

formatCode (und formatCodeDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:
$code = gemäß Liste der in ELGA gültigen FormatCodes
$displayName = gemäß Liste der in ELGA gültigen FormatCodes
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes,

             fixiert mit OID 1.2.40.0.34.5.37

<rim:Classification
  classificationScheme=
      "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
  classifiedObject="theDocument"
  nodeRepresentation="$code"
>
  <rim:Name>
    <rim:LocalizedString value="$displayName"/>
  </rim:Name>
  <rim:Slot name="codingScheme">
    <rim:ValueList>
      <rim:Value>urn:oid:$codeSystem</rim:Value>
    </rim:ValueList>
  </rim:Slot>
</rim:Classification>

1.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)

Das healthcareFacilityTypeCode Element beschreibt die Klassifizierung des GDA.

Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.

Zulässige Werte gemäß Value Set „ELGA_ HealthcareFacilityTypeCode“.

1.3.1 Spezifikation

healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:

<span style="color:red;">$code </span>= Klassifizierung des GDA (Code)
<span style="color:red;">$displayName </span>= Klartext des angegebenen Codes
<span style="color:red;">$codeSystem </span>= OID der ausgebenden Stelle
 
<rim:Classification
  classificationScheme=
      "urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
  classifiedObject="theDocument"
  nodeRepresentation="$code"
>
  <rim:Name>
    <rim:LocalizedString value="$displayName"/>
  </rim:Name>
  <rim:Slot name="codingScheme">
    <rim:ValueList>
      <rim:Value>urn:oid:$codeSystem</rim:Value>
    </rim:ValueList>
  </rim:Slot>
</rim:Classification>

1.4 mimeType

Das mimeType Element beschreibt den „Internet Media Type“ des Dokuments gemäß dem „Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard wird beschrieben in RFC 2045¹⁵ bis RFC 2049¹⁶.

Im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".

1.4.1 Spezifikation

mimeType wird gemäß folgender Vorschrift gespeichert.

Folgende Mime-Types sind für Dokumente zugelassen:

 CDA R2: text/xml
 DICOM/KOS: application/dicom

<rim:ExtrinsicObject mimeType="text/xml"
	id="urn:uuid:<entryUUID>" 
	objectType=
		"urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
>

1.5 parentDocumentId, parentDocumentRelationship

Das parentDocumentId Element verweist auf das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation steht. Das parentDocumentRelationship Element beschreibt den Typ der Relation (Versionierung, Transformation). Da nicht alle lokalen und temporären Versionen eines Dokuments veröffentlicht werden müssen, können die tatsächlichen und technischen Dokumentenverweise in XDS nicht über die parentDocumentId erfasst werden, sondern über Association-Objekte.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:

• ClinicalDocument/relatedDocument

1. Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:

• ClinicalDocument/relatedDocument/@typeCode
• Folgende Relationen sind in ELGA erlaubt (siehe „Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente“ [1]):
  • Versionierung (RPLC)

1. Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:

• ClinicalDocument/relatedDocument/parentDocument

¹⁵ http://tools.ietf.org/html/rfc2045 ¹⁶ http://tools.ietf.org/html/rfc2049

1.5.1 Spezifikation

parentDocumentId MUSS mit folgenden Elementen in CDA übereinstimmen:

concat(
ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",
ClinicalDocument/relatedDocument/parentDocument/id/@extension
)

parentDocumentRelationship MUSS mit folgenden Elementen in CDA übereinstimmen:

ClinicalDocument/relatedDocument/@typeCode

1.6 practiceSettingCode (und practiceSettingCodeDisplayName)

Das practiceSettingCode Element beschreibt die fachliche Zuordnung des Dokumentes. Es SOLL den Fachbereich wiedergeben, dem der Inhalt des Dokuments am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung.

Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.

Zulässige Werte gemäß Value Set „ELGA_PracticeSetting_VS“.

1.6.1 Spezifikation

practiceSettingCode (und practiceSettingCodeDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:

$code = Code aus ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12)

<rim:Classification
  classificationScheme=
      "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
  classifiedObject="theDocument"
  nodeRepresentation="$code"
>
  <rim:Name>
    <rim:LocalizedString value="$displayName"/>
  </rim:Name>
  <rim:Slot name="codingScheme">
    <rim:ValueList>
      <rim:Value>urn:oid:$codeSystem</rim:Value>
    </rim:ValueList>
  </rim:Slot>
</rim:Classification>

1.7 objectType

Das objectType Element gibt den Typ des Dokuments wieder, entweder ein „stabiles Dokument“ (stable document, SD) oder ein „On-demand Dokument“ (on-demand document, ODD). Der Datentyp ist eine UUID.

Zulässige Werte:
urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 (Stable Document)
urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 (On-Demand Document)