Administrative Daten (CDA Header)

1 Administrative Daten (CDA Header)

1.1 Überblick

1.1.1 Elemente der CDA Header - Dokumentstruktur

Dieses Kapitel zeigt einen Überblick über die Elemente der CDA Header-Dokumentstruktur.

Element	Bedeutung
realmCode	Hoheitsbereich des Dokuments
typeId	Kennzeichnung CDA R2
templateId	Kennzeichnung von Strukturvorschriften
id	Dokumenten-Id
code	Dokumentenklasse
title	Titel des Dokuments
effectiveTime	Erstellungsdatum des Dokuments
confidentialityCode	Vertraulichkeitscode
languageCode	Sprachcode des Dokuments
setId versionNumber	Versionierung des Dokuments
recordTarget	Patient
author	Verfasser des Dokuments
dataEnterer	Personen der Dateneingabe
custodian	Verwahrer des Dokuments
informationRecipient	Beabsichtigte Empfänger des Dokuments
legalAuthenticator	Rechtlicher Unterzeichner
authenticator	Weitere Unterzeichner
participant	Weitere Beteiligte
inFulfillmentOf	Zuweisung und Ordermanagement
serviceEvent	Gesundheitsdienstleistungen
relatedDocument	Bezug zu vorgehenden Dokumenten
authorization	Einverständniserklärung
encompassingEncounter	Patientenkontakt (Aufenthalt)

Tabelle 3: Überblick über die Elemente des CDA Headers

1.2 Dokumentenstruktur

1.2.1 XML Metainformationen

1.2.1.1 Zeichencodierung

CDA-Dokumente MÜSSEN mit UTF-8 (8-Bit Universal Character Set Transformation Format, nach RFC 3629 / STD 63 (2003)) codiert werden.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”?>
<ClinicalDocument xmlns="urn:hl7-org:v3">
:

1.2.1.2 Hinterlegung eines Stylesheets

Um ein CDA-Dokument in einem Webbrowser anzeigen zu können, muss es nach HTML tranformiert werden. Das kann durch eine XSLT-Transformation (ein so genanntes „Stylesheet“) geschehen. Ist das Stylesheet im angegebenen Pfad erreichbar, wird dieses beim Öffnen des CDA-Dokuments mit einem Browser üblicherweise automatisch auf das CDA-Dokument angewandt und die Darstellung gerendert.

ELGA stellt zur einheitlichen Darstellung von CDA-Dokumenten ein „Referenz-Stylesheet“ zur Verfügung (Download ist von der ELGA Website http://www.elga.gv.at/cda möglich). Da der Zugriff auf XSLT-Programme von den meisten Browsern eingeschränkt ist, wird kein absoluter Pfad auf eine Webressource angegeben.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”?>
<?xml-stylesheet type="text/xsl" href="ELGA_Stylesheet_v1.0.xsl"?>
<ClinicalDocument xmlns="urn:hl7-org:v3">
:

Das Stylesheet „ELGA_Stylesheet_v1.0.xsl“ MUSS angegeben werden [M]. Die Angabe eines Pfades ist NICHT ERLAUBT. Ausnahmen können für automatisiert erstellte Dokumente notwendig sein, diese müssen im allgemeinen und speziellen Leitfäden beschrieben werden.

1.2.2 Wurzelelement

Der XML-Namespace für CDA Release 2.0 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser MUSS in geeigneter Weise in jeder CDA XML Instanz genannt werden. In diesem Leitfaden werden namespace-Präfixe nicht genutzt.

Für ELGA CDA-Dokumente MUSS der Zeichensatz UTF-8 verwendet werden.

CDA-Dokumente beginnen mit dem Wurzelelement ClinicalDocument, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.

<ClinicalDocument xmlns="urn:hl7-org:v3">
   <!-- CDA Header -->
      … siehe Beschreibung CDA R2 Header …
   <!-- CDA Body -->
   <component>
      <structuredBody>
         … siehe Beschreibung CDA R2 Body …
      </structuredBody>
   </component>
</ClinicalDocument>

1.2.3 Hoheitsbereich des Dokuments („realmCode“)

Dieses Element kennzeichnet, dass das Dokument aus dem Hoheitsbereich Österreich (bzw. Bereich der HL7 Affiliate Austria, Code „AT“) stammt.

1.2.3.1 Strukturbeispiel

<realmCode code="AT'"/>

1.2.3.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
realmCode	CS CNE	1..1	M	Hoheitsbereich des Dokuments Fester Wert: @code = AT (aus ValueSet „ELGA_RealmCode“)

1.2.4 Dokumentformat („typeId“)

Dieses Element kennzeichnet, dass das Dokument im Format CDA R2 vorliegt.

1.2.4.1 Strukturbeispiel

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>

1.2.4.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
typeId	II	1..1	M	Dokumentformat CDA R2 Feste Werte: @root = 2.16.840.1.113883.1.3' @extension = POCD_HD000040

1.2.5 ELGA Implementierungsleitfaden-Kennzeichnung („templateId“)

Templates sind definierte Vorlagen, die Strukturen von Dokumenten, Dokumentteilen oder Datenelementen vorgeben. In CDA bezeichnen solche Templates bestimmte Teilstrukturen. Mittels templateId-Elementen können Teile von CDA-Dokumenten hinsichtlich ihrer Konformität zu Templates oder Implementierungsleitfäden gekennzeichnet werden.

Der Einsatz von so genannten „templateId”-Elementen sichert zu, dass eine CDA-Instanz nicht nur CDA konform ist, sondern auch dem referenzierten Template oder Implementierungsleitfaden entspricht. Mit Zusicherung ist dabei nur eine informelle Behauptung des Verfassers gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung bzw. Zertifizierung.

Ein CDA Dokument, welches den Vorgaben dieses Implementierungsleitfadens entspricht, ist berechtigt und verpflichtet, die entsprechende templateId-Kennung einzutragen.

1.2.5.1 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
  <realmCode code="AT"/>
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>

  <!—   Folgt dem vorliegenden Implementierungsleitfaden-Template -->
  <templateId root="1.2.40.0.34.11.1"/>
  
  <!—   Beliebig viele weitere templateIds, falls das Dokumente noch weiteren Implementierungsleitfäden oder Spezifikationen folgt -->
  <templateId root="…"/>
	:
</ClinicalDocument>

1.2.5.2 Spezifikation

Die OID des vorliegenden Implementierungsleitfadens MUSS im @root Attribut des Elements angegeben werden.

Mit Angabe dieses Elements wird ausgesagt, dass das vorliegende CDA-Dokument zu diesem Implementierungsleitfaden konform ist.

Element/Attribut	DT	Kard	Konf	Beschreibung
templateId[1]	II	1..1	M	ELGA TemplateId für den Allgemeinen Implementierungsleitfaden Fester Wert: @root = 1.2.40.0.34.11.1
templateId[n]	II	0..*	O	Weitere TemplateIds

Verweis auf speziellen Implementierungsleitfaden:
Des Weiteren können zusätzlich die geforderten templateIds eines weiteren speziellen Implementierungsleitfadens angegeben werden (z.B. Entlassungsbrief, Laborbefund, etc.).

Die jeweils im @root Attribut einzutragende OID entnehmen Sie bitte den entsprechenden Implementierungsleitfaden gemäß der Dokumentklasse.

Folgt das CDA-Dokument noch anderen Implementierungsleitfäden oder Spezifikationen können beliebig viele weitere templateId-Elemente angegeben werden. 

1.2.6 Dokumenten-Id („id”)

Die Dokumenten-Id eines CDA-Dokuments ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit eindeutig und für alle Zeit identifiziert. Ein CDA-Dokument hat genau eine Id.

1.2.6.1 Strukturbeispiel

<id
  root="1.2.40.0.34.99.111.1.1"
  extension="134F989"
  assigningAuthorityName="Amadeus Spital"/>

1.2.6.2 Spezifikation

Es MUSS eine gültige und innerhalb des ID-Pools eindeutige Dokumenten-ID angegeben werden.

Element/Attribut	DT	Kard	Konf	Beschreibung
id	II	1..1	M	Dokumenten-Id Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

1.2.7 Dokumentenklasse („code“)

Der “Code des Dokuments” (im CDA das Element ClinicalDocument/code) bezeichnet die „Dokumentklasse'“ bzw den präziseren „'Dokumenentyp'“.

Beispiele für die Klasseneinteilung der Dokumente:

• Dokumentenklasse: Entlassungsbrief
  • Dokumententyp: „Entlassungsbrief aus stationärer Behandlung (Ärztlich)“
  • Dokumententyp: „Entlassungsbrief aus stationärer Behandlung (Pflege)“
• Dokumentenklasse: Laborbefund
• Dokumentenklasse: Befundbericht Befund bildgebende Diagnostik
• …

Für das Mapping in XDS siehe den entsprechenden Leitfaden „ELGA XDS Metadaten“.

1.2.7.1 Strukturbeispiel

  displayName="Physician Discharge summary"
  codeSystem="2.16.840.1.113883.6.1"
  codeSystemName="LOINC" />

1.2.7.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
code	CE CWE	1..1	M	Dokumententyp oder Dokumentenklasse Zulässige Werte gemäß Value-Set „ELGA_Dokumentklassen“ Grundsätzlich sind die Vorgaben gemäß „code-Element CE CWE“ zu befolgen.

Verweis auf speziellen Implementierungsleitfaden:
Die gültigen Wertebereiche dieses Elements entnehmen Sie bitte den entsprechenden speziellen Implementierungsleitfaden gemäß der Dokumentklasse bzw dem Dokumententyp.

1.2.8 Titel des Dokuments („title“)

“Titel” (im CDA das Element ClinicalDocument/title) bezeichnet die verpflichtende „Dokumentenüberschrift“ (zusätzlich zur Dokumentenklasse).

Beispiele für Titel der Dokumente:

• „Arztbrief“
• „Entlassungsbrief der gynäkologischen Abteilung des SMZ Ost“
• „Vorläufiger Entlassungsbrief“
• „Befundbericht“
• …

1.2.8.1 Strukturbeispiel

<title>Entlassungsbrief</title>

1.2.8.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
title	ST	1..1	M	Dokumententitel Der Sinn der Benennung MUSS mit der Dokumentklasse übereinstimmen.

1.2.9 Erstellungsdatum des Dokuments („effectiveTime“)

1.2.9.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.90008/static-2017-07-20T130010

1.2.10 Vertraulichkeitscode („confidentialityCode“)

1.2.10.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.90009/static-2017-07-20T130221

1.2.11 Sprachcode des Dokuments („languageCode“)

1.2.11.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.90010/static-2017-07-20T130511

1.2.12 Versionierung des Dokuments („setId“ und „versionNumber“)

1.2.12.1 Spezifikation

Es MÜSSEN immer beide Elemente (setID und versionNumber) angegeben werden.

1. REDIRECT 1.2.40.0.34.11.90007/static-2017-07-20T131534

Für die setId sind grundsätzlich die Vorgaben gemäß Kapitel „id-Element II“ zu befolgen. Die versionNumber von neuen Dokumenten wird mit 1 festgelegt.

Anhänge oder Ersetzungen von Vordokumenten MÜSSEN ebenfalls diese zusätzlichen Angaben enthalten.

Der genaue Zusammenhang zwischen diesen Attributen finden Sie im „Bezug zu vorgehenden Dokumenten“.

Achtung: Manche Validatoren erkennen es als Fehler, wenn die SetID und ID gleich sind.

1.3 Teilnehmende Parteien

1.3.1 Patient („recordTarget/patientRole“)

Im CDA-Header wird mindestes eine Patientenrolle beschrieben, die zu genau einer Person zugehörig ist. Die recordTarget Beziehung weist auf die Patient-Klasse und gibt an, zu welchem Patienten dieses Dokument gehört.

Auszug aus dem R-MIM:

Abbildung 7: Klassen rund um den Patienten.

1.3.1.1 Spezifikation

Id	1.2.40.0.34.11.20001	Gültigkeit	2017‑07‑20 Andere Versionen mit dieser Id: Header​Record​Target vom 2017‑03‑27 Header​Record​Target vom 2013‑10‑08
Status	Entwurf	Versions-Label
Name	Header​Record​Target	Anzeigename	Header​Record​Target
Beschreibung Das RecordTarget-Element enthält den Patienten: Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw über deren Gesundheitsdaten im Dokument berichtet wird.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt	Benutzt von 0 Transactions und 2 Templates, Benutzt 1 Template Benutzt von als Name Version 1.2.40.0.34.11.1 Inklusion Allgemeiner Implementierungsleitfaden ELGA CDA Dokumente 2017‑02‑20 1.2.40.0.34.11.1 Inklusion Allgemeiner Implementierungsleitfaden ELGA CDA Dokumente 2011‑12‑19 Benutzt als Name Version 1.2.40.0.34.11.90017 Inklusion Language Communication DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20001 (2017‑03‑27)
Beispiel	Vollständiges Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <!-- lokale Patienten ID vom System -->     <id root="1.2.40.0.34.99.111.1.2" extension="4711" assigningAuthorityName="Amadeus Spital"/>    <!-- Sozialversicherungsnummer des Patienten -->     <id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>    <!-- Adresse des Patienten -->     <addr use="H">       <streetName>Musterstraße</streetName>      <houseNumber>13a</houseNumber>      <postalCode>7000</postalCode>      <city>Eisenstadt</city>      <state>Burgenland</state>      <country>AUT</country>    </addr>    <!-- Kontaktdaten des Patienten-->     <telecom value="tel:+43.1.40400" use="H"/>    <telecom value="tel:+43.664.1234567" use="MC"/>    <telecom value="mailto:herbert.mustermann@provider.at"/>    <!-- Name des Patienten -->     <patient classCode="PSN" determinerCode="INSTANCE">       <name>         <prefix qualifier="AC">Dipl.Ing.</prefix>        <given>Herbert</given>        <given>Hannes</given>        <family>Mustermann</family>        <family qualifier="BR">VorDerHeirat</family>        <suffix qualifier="AC">BSc</suffix>        <suffix qualifier="AC">MBA</suffix>      </name>      <!-- Geschlecht des Patienten -->       <administrativeGenderCode code="M" displayName="Male" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>      <!-- Geburtsdatum des Patienten -->       <birthTime value="19701224"/>      <!-- Familienstand des Patienten -->       <maritalStatusCode code="D" displayName="Divorced" codeSystem="2.16.840.1.113883.5.2"/>      <!-- Religionszugehörigkeit des Patienten -->       <religiousAffiliationCode code="101" displayName="Römisch-Katholisch" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria"/>      <!-- Vormund/Sachwalter des Patienten "Organisation"-->       <guardian>         <!--Eine Organisation als Guardian, hier als Strukturbeispiel-->         <addr>           <streetAddressLine>Kinderdorfstraße 1</streetAddressLine>          <postalCode>2371</postalCode>          <city>Hinterbrühl</city>          <state>Niederösterreich</state>          <country>AUT</country>        </addr>        <!-- Kontaktdaten des Vormunds/Sachwalters (Organisation)-->         <telecom use="H" value="tel:+43.2236.2928"/>        <telecom use="WP" value="tel:+43.2236.9000"/>        <guardianOrganization>           <!-- Name der Vormund/Sachwalter-Organisation-->           <name>SOS Kinderdorf Hinterbrühl</name>        </guardianOrganization>      </guardian>      <!-- Vormund/Sachwalter des Patienten "Person" -->       <guardian>         <!-- Adresse des Vormunds/Sachwalters (Person) -->         <addr>           <streetAddressLine>Musterstraße 1234</streetAddressLine>          <postalCode>8011</postalCode>          <city>Graz</city>          <state>Steiermark</state>          <country>AUT</country>        </addr>        <!-- Kontaktdaten des Vormunds/Sachwalters (Person) -->         <telecom use="MC" value="tel:+43.676.1234567"/>        <telecom use="H" value="tel:+43.316.717.653.9939"/>        <telecom use="WP" value="tel:+43.316.608.271.9000"/>        <guardianPerson>           <!-- Name der Vormund/Sachwalter-Organisation -->           <name>             <given>Susi</given>            <family>Sorgenvoll</family>          </name>        </guardianPerson>      </guardian>      <!-- Geburtsort des Patienten -->       <birthplace>         <place>           <addr>Graz</addr>        </place>      </birthplace>    </patient>  </patientRole></recordTarget>
Beispiel	Minimalbeispiel 1 <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <!-- lokale Patienten ID vom System -->     <id root="1.2.40.0.34.99.111.1.2" extension="4711"/>    <!-- Name des Patienten -->     <patient classCode="PSN" determinerCode="INSTANCE">       <name>         <given>Herbert</given>        <family>Mustermann</family>      </name>      <!-- Geschlecht des Patienten -->       <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>      <!-- Geburtsdatum des Patienten -->       <birthTime value="19701224"/>    </patient>  </patientRole></recordTarget>
Beispiel	Minimalbeispiel 2 <recordTarget>   <patientRole>     <!-- lokale Patienten ID -->     <id root="1.2.40.0.34.99.111.1.2" extension="4711"/>    <!-- Name des Patienten -->     <patient>       <name>         <given>Herbert</given>        <family>Mustermann</family>      </name>      <!-- Geschlecht des Patienten -->       <administrativeGenderCode nullFlavor="UNK"/>      <!-- Geburtsdatum des Patienten -->       <birthTime nullFlavor="UNK"/>    </patient>  </patientRole></recordTarget>
Item DT Kard Konf Beschreibung Label hl7:recordTarget Komponente für die Patientendaten. (Hea...get) @typeCode cs 0 … 1 F RCT @context​Control​Code cs 0 … 1 F OP   Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <!-- ... -->   </patientRole></recordTarget> hl7:patientRole 1 … 1 R Patientendaten. (Hea...get) @classCode cs 0 … 1 F PAT   Beispiel <patientRole classCode="PAT">   <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>  <patient classCode="PSN" determinerCode="INSTANCE">     <!-- ... -->   </patient></patientRole>   Schematron assert role  error     test string-length(hl7:id[1]/@root)>0     Meldung patientRole id[1] MUSS als lokale Patienten ID vom System vorhanden sein     Schematron assert role  error     test hl7:id[2]/@root = '1.2.40.0.10.1.4.3.1' or hl7:id[2]/@nullFlavor='NI' or hl7:id[2]/@nullFlavor='UNK'     Meldung patientRole id[2] MUSS Sozialversicherungsnummer des Patienten sein (1.2.40.0.10.1.4.3.1) oder @nullFlavor 'NI' oder 'UNK' ist angegeben   hl7:id II 2 … * R id[1] Identifikation des Patienten im lokalen System. id[2] Sozialversicherungsnummer des Patienten Zugelassene nullFlavor: NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …) UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt id[3] Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit) (Hea...get)   Beispiel lokale Patienten ID vom System, notwendig für XDS <id root="1.2.40.0.34.99.111.1.2" extension="4711" assigningAuthorityName="Amadeus Spital"/>   Beispiel Patienten SV Nummer <id root="1.2.40.0.10.1.4.3.1" extension="1234241270" assigningAuthorityName="Österreichische Sozialversicherung"/>   Beispiel bPK-GH des Patienten: Bereichskürzel + bPK (Base64,28 Zeichen) <id root="1.2.40.0.10.2.1.1.149" extension="GH:XNV5ThCj5OwJR0oOcWmK4WUs5p4=" assigningAuthorityName="Österreichische Stammzahlenregisterbehörde"/><!--Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen--> hl7:addr AD 0 … 1 Adresse des Patienten. Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen. (Hea...get) hl7:streetAddressLine 0 … 1 (Hea...get) hl7:streetName 0 … 1 (Hea...get) hl7:houseNumber 0 … 1 (Hea...get)   Schematron assert role  error     test hl7:streetAddressLine or (hl7:streetName and hl7:houseNumber)     Meldung Granularitätsstufen Adresse beachten: streetAddressLine oder streetName+houseNumber   hl7:postalCode 1 … 1 M (Hea...get) hl7:city 1 … 1 M (Hea...get) hl7:state 0 … 1 C (Hea...get) hl7:country 1 … 1 M (Hea...get) hl7:additionalLocator 0 … 1 (Hea...get) hl7:telecom TEL.AT 0 … * Kontaktdaten des Patienten. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (Hea...get) hl7:patient 0 … 1 (Hea...get) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name des Patienten. Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden! Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen. (Hea...get) hl7:prefix 0 … * (Hea...get) hl7:given 1 … * M (Hea...get) hl7:family 1 … * M (Hea...get) hl7:suffix 0 … * (Hea...get) hl7:administrative​Gender​Code CE 1 … 1 R Codierung des Geschlechts des Patienten. Zugelassene nullFlavor: UNK (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC) hl7:birthTime TS.​DATE.​MIN 1 … 1 R Geburtsdatum des Patienten. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Zugelassene nullFlavor: UNK (Hea...get) hl7:marital​Status​Code CE 0 … 1 Codierung des Familienstands des Patienten. (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC) hl7:religious​Affiliation​Code CE 0 … 1 Codierung des Religionsbekenntnisses des Patienten. (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC) hl7:raceCode NP Rasse des Patienten Darf nicht verwendet werden! (Hea...get) hl7:ethnic​Group​Code NP Ethnische Zugehörigkeit des Patienten. Darf nicht verwendet werden! (Hea...get) hl7:guardian 0 … * Gesetzlicher Vertreter: Erwachsenenvertreter, Vormund, Obsorgeberechtigter (Hea...get) hl7:addr AD 0 … 1 Die Adresse des gesetzlichen Vertreters oder der Organisation. Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen. (Hea...get) hl7:telecom TEL.AT 0 … * Beliebig viele Kontaktdatendes gesetzlichen Vertreters oder der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (Hea...get) Auswahl 1 … 1 Elemente in der Auswahl: hl7:guardian​Person hl7:guardian​Organization hl7:guardian​Person  … 1 Name des des gesetzlichen Vertreters (Person). (Hea...get) hl7:name PN 1 … 1 M Name der Person. (Hea...get) hl7:guardian​Organization  … 1 Name des des gesetzlichen Vertreters (Organisation). (Hea...get) hl7:name ON 1 … 1 M Name der Organisation. (Hea...get) hl7:birthplace 0 … 1 Geburtsort des Patienten. (Hea...get) hl7:place 1 … 1 M (Hea...get) hl7:addr AD 1 … 1 M Die Adresse des Geburtsorts. Grundsätzlich sind die Vorgaben gemäß „Adress-Elemente“ für Granularitätsstufe 1 zu befolgen. Granularitätsstufe 2 oder 3 ist auch bei EIS Enhanced und Full Support nicht erforderlich. (Hea...get) Eingefügt von 1.2.40.0.34.11.90017 Language Communication (DYNAMIC) hl7:language​Communication 0 … * Komponente zur Angabe der Sprachfähigkeiten des Patienten. (Hea...get) hl7:language​Code CS 0 … 1 Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen). (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.173 ELGA_HumanLanguage (DYNAMIC) hl7:modeCode CE 0 … 1 Ausdrucksform der Sprache. @codeSystem Fester Wert: 2.16.840.1.113883.5.60 (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC) hl7:proficiency​Level​Code CE 0 … 1 Grad der Sprachkenntnis in der Sprache. @codeSystem Fester Wert: 2.16.840.1.113883.5.61 (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC) hl7:preference​Ind BL 0 … 1 Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird. (Hea...get)

1.3.1.1.1 id

Element/Attribut		DT	Kard	Konf	Beschreibung
id[1]		II	1..1	M	Identifikation des Patienten im lokalen System Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.
id[2]		II	1..1	R	Sozialversicherungsnummer des Patienten Zugelassene nullFlavor: NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …) UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
	@root	uid	1..1	M	OID der Liste aller österreichischen Sozialversicherungen Fester Wert: 1.2.40.0.10.1.4.3.1
	@extension	st	1..1	M	Vollständige Sozialversicherungsnummer des Patienten (alle 10 Stellen)
	@assigningAuthorityName	st	0..1	O	Fester Wert: Österreichische Sozialversicherung
id[3]		II	0..1	O	Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit)
	@root	uid	1..1	M	OID der österreichischen bPK Fester Wert: 1.2.40.0.10.2.1.1.149
	@extension	st	1..1	M	bPK-GH des Patienten: Bereichskürzel + bPK (Base64, 28 Zeichen) (insg. 31 Stellen) Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen
	@assigningAuthorityName	st	0..1	O	Fester Wert: Österreichische Stammzahlenregisterbehörde

Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!

1.3.1.1.2 addr

Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass auch mehr als eine Adresse unterstützt werden muss.

1.3.1.1.3 patient/languageCommunication

In der Klasse languageCommunication können Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform (z.B. gesprochen oder geschrieben) des Patienten angegeben werden.

Dieser Leitfaden schränkt die möglichen Werte für die Sprache auf Werte aus dem Value Set ELGA_HumanLanguage ein. Gemäß IETF / RFC 3066 enthält es ein bestimmtes Subset von Codes aus ISO 639-1 und ISO 639-2 (also zwei- und dreistellige Sprachcodes). Gemäß RFC 3066 ist es zulässig, eine Angabe der landestypischen Ausprägung der Sprache nach einem Bindestrich anzufügen. Das Land wird dabei nach ISO 3166-1 Alpha 2 angegeben. Dies MUSS bei der Auswertung des languageCodes berücksichtigt und toleriert werden.

1.3.1.1.4 patient/guardian

In der Klasse guardian können Informationen bezüglich eines Vormunds/Sachwalters des Patienten angegeben werden. Begriffsdefinition:

• Ein Vormund kann existieren, wenn die Person noch nie geschäftsfähig war
  • z.B. Kinder
• Ein Sachwalter kann existieren, wenn die Person schon geschäftsfähig war, die Geschäftsfähigkeit aber entzogen wurde
  • z.B. Alte Personen

Vormund/Sachwalter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein. Beim Patient können optional ein oder mehrere Vormund/Sachwalter Element(e) angegeben werden. Wenn ein Sachwalter bekannt ist, SOLL diese Information auch angegeben werden.

1.3.2 Verfasser des Dokuments („author“)

Auszug aus dem R-MIM:

Abbildung 8: Klassen rund um den Autor.

1.3.2.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20002/static-2017-07-21T114519

1.3.2.2 Spezifikation: Datenerstellende Geräte als „author“

Datenerstellende Geräte/Software (z.B.: das Service der e-Medikation, das die aktuelle Medikationsliste generiert). Siehe auch Rechtlicher Unterzeichner („legalAuthenticator“).

1.3.3 Personen der Dateneingabe („dataEnterer“)

1.3.3.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20003/static-2017-07-20T162544

1.3.4 Verwahrer des Dokuments („custodian“)

Auszug aus dem R-MIM:

Abbildung 9: Klassen rund um die das Dokument verwaltende Organisation.

1.3.4.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20004/static-2017-07-20T090815

1.3.4.1.1 id

Element/Attribut		DT	Kard	Konf	Beschreibung
id		II	1..1	R	Identifikation des Verwahrers des Dokuments aus dem GDA-Index. Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.“ Zugelassene nullFlavor: NI … Organisation hat keine ID aus dem GDA-Index UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt

In der nächsten Version des Leitfadens wird die Konformität entsprechend dem CDA-Standard auf [M] erhöht, Null Flavors sind dann nicht mehr erlaubt.

1.3.5 Beabsichtigte Empfänger des Dokuments („informationRecipient“)

Auszug aus dem R-MIM:

Abbildung 10: Klassen rund um die beabsichtigten Empfänger des Dokuments.

1.3.5.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20005/static-2017-07-20T163654

1.3.6 Rechtlicher Unterzeichner („legalAuthenticator“)

Auszug aus dem R-MIM:

Abbildung 11: Klassen rund um den Rechtlichen Unterzeichner und Mitunterzeichner.

1.3.6.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20006/static-2017-07-21T093710

1.3.6.1.1 legalAuthenticator Element Allgemein

Element/Attribut	DT	Kard	Konf	Beschreibung
legalAuthenticator	POCD_MT000040.LegalAuthenticator		C	Rechtlicher Unterzeichner
Konditionale Konformität: Regelfall: Der Inhalt des Dokuments wird durch eine natürliche Person freigegeben. Sonderfall: Multidisziplinärer Befund mit gleichberechtigten ärztlichen Unterzeichnern Sonderfall „automatisch erstellte Dokumente“: Dokumente, deren Inhalt durch einen Algorithmus erzeugt und die nicht von einer natürlichen Person freigegeben werden.		1..1 0..1 0..0	M O NP	Der rechtliche Unterzeichner MUSS angegeben werden Ob einer der Sonderfälle zur Anwendung kommen DARF, ist in den jeweiligen speziellen Leitfäden definiert. Der rechtliche Unterzeichner KANN angegeben werden, wenn er fehlt, MÜSSEN mindestens zwei Authenticator-Elemente angegeben werden. Der legalAuthenticator DARF NICHT angegeben werden. Siehe auch Spezifikation: Datenerstellende Geräte als „author“, Kapitel.

1.3.7 Weitere Unterzeichner („authenticator“)

1.3.7.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20007/static-2017-07-21T094204

1.3.8 Weitere Beteiligte („participant“)

Mit dieser Assoziation und den entsprechenden Klassen können weitere für die Dokumentation wichtige beteiligte Personen oder Organisationen wie Angehörige, Verwandte, Versicherungsträger sowie weitere in Beziehung zum Patienten stehende Parteien genannt werden.

Es können grundsätzlich beliebig viele participant-Elemente im Dokument angegeben werden, teilweise gibt es aber Einschränkungen für die einzelnen Elemente.

Auszug aus dem R-MIM:

Abbildung 12: Klassen rund um weitere Beteiligte (participants).

1.3.8.1 Festlegung der „Art“ des Beteiligten

Die „Art“ des Beteiligten wird über eine Kombination aus

• Attribut participant/@typeCode
• Element participant/functionCode
• Attribut participant/associatedEntity/@classCode

festgelegt.

Eine eindeutige Identifikation ist darüber hinaus noch über das templateId-Element möglich, welches für jede Art von Beteiligten einen eindeutigen Wert enthält.

Ebenfalls erhalten die Elemente innerhalb der Unterelemente ihre Bedeutung in Abhängigkeit von der Beteiligten-Art. Beispielsweise drückt das time-Element zwar generell den Zeitraum der Beteiligung, im Falle der Darstellung einer Versicherung allerdings den Gültigkeitsbereich der Versicherungspolizze aus.

Dieses Kapitel enthält eine detaillierte Anleitung zur Angabe der folgenden Arten von „weiteren Beteiligten“:

Kard	Konf	Art des Beteiligten
0..1	O	Fachlicher Ansprechpartner
0..1	O	Einweisender/Zuweisender/Überweisender Arzt
0..1	O	Hausarzt
0..*	O	Notfall-Kontakt / Auskunftsberechtigte Person
0..*	O	Angehörige
0..*	O	Versicherter/Versicherung
0..1	O	Betreuende Organisation
0..1	O	Weitere Behandler

Verweis auf speziellen Implementierungsleitfaden:
Welche der folgenden „weiteren Beteiligten“ im Dokument angegeben werden müssen bzw. sollen ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

1.3.8.2 Fachlicher Ansprechpartner

Der fachliche Ansprechpartner ist jene Kontaktperson oder –stelle, welche zur Kontaktaufnahme für fachliche Auskünfte zum betreffenden Dokument veröffentlicht wird. Diese Maßnahme dient zur Kanalisierung und Vereinheitlichung der Kommunikationsschiene zwischen dem Erzeuger und dem Empfänger der Dokumentation, beispielsweise für Rückfragen oder Erfragung weiterer fachlicher Informationen. Die Angabe dieses Elements ist grundsätzlich optional, wobei in den speziellen Leitfäden eine verpflichtende Angabe spezifiziert sein kann. Bei Verwendung sollen möglichst präzise Kontaktdaten angegeben werden. Es obliegt der dokumenterzeugenden Organisation zu entscheiden, welchen Ansprechpartner sie veröffentlicht.

Abbildung 13: Besonders hervorgehobene Darstellung des fachlichen Ansprechpartners durch das ELGA Referenz-Stylesheet.

Soll als Ansprechpartner der Verfasser des Dokuments angegeben werden, so sind die entsprechenden Daten an dieser Stelle noch einmal anzugeben.

Als fachlicher Ansprechpartner kann aber auch eine Stelle beschrieben sein, die eingehende Anfragen als erste entgegennimmt und in Folge an die zuständigen Personen weiterleitet.

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	CALLBCK	Callback contact	Fachlicher Ansprechpartner
templateId	1.2.40.0.34.11.1.1.1	-	Template ID zur Identifikation dieser Art von Beteiligten
functionCode	-	-	Wird nicht angegeben
@classCode	PROV	Healthcare provider	Gesundheitsdienstanbieter

1.3.8.2.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.1.1.1/static-2017-07-21T094957

1.3.8.3 Einweisender/Zuweisender/Überweisender Arzt

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	REF	Referrer	Einweisender/Zuweisender/Überweisender Arzt
templateId	1.2.40.0.34.11.1.1.2 1.3.6.1.4.1.19376.1.3.3.1.6	-	Template ID für: Einweisender/Zuweisender/Überweisender Arzt Labor-Auftraggeber
functionCode	-	-	Wird nicht angegeben
@classCode	PROV	Healthcare provider	Gesundheitsdienstanbieter

Verweis auf speziellen Implementierungsleitfaden:
Für den Laborbefund gilt hier eine Ausnahme. Der participant mit dem typeCode="REF" wird in der Definition des IHE Laboratory Technical Framework als Auftraggeber bzw. „Ordering Provider“ mit templateId "1.3.6.1.4.1.19376.1.3.3.1.6" angewendet.

1.3.8.3.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.1.1.2/static-2017-07-21T101213

1.3.8.4 Hausarzt

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	IND	Indirect target	In indirektem Bezug
templateId	1.2.40.0.34.11.1.1.3	-	Template ID zur Identifikation dieser Art von Beteiligten
functionCode	PCP	primary care physician	Hausarzt
@classCode	PROV	Healthcare provider	Gesundheitsdienstanbieter

1.3.8.4.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.1.1.3/static-2017-07-21T102159

1.3.8.5 Notfall-Kontakt/Auskunftsberechtigte Person

Der Notfall-Kontakt entspricht in Österreich der „Auskunftsberechtigten Person“ (oder auch „Vertrauensperson“).

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	IND	Indirect target	In indirektem Bezug
templateId	1.2.40.0.34.11.1.1.4	-	Template ID zur Identifikation dieser Art von Beteiligten
functionCode	-	-	Wird nicht angegeben
@classCode	ECON	Emergency contact	Notfall-Kontakt

1.3.8.5.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.1.1.4/static-2017-07-21T102815

1.3.8.6 Angehörige

Als Angehörige sind in Österreich jene Personen anzusehen, welche in einem Verwandtschaftsverhältnis zum Patienten stehen, aber nicht unter die Gruppe der „Auskunftsberechtigten Personen“ fallen (siehe Notfall-Kontakt/Auskunftsberechtigte Person).

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	IND	Indirect target	In indirektem Bezug
templateId	1.2.40.0.34.11.1.1.5	-	Template ID zur Identifikation dieser Art von Beteiligten
functionCode	-	-	Wird nicht angegeben
@classCode	PRS	Personal relationship	In persönlicher Beziehung

1.3.8.6.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.1.1.5/static-2017-07-21T104419

1.3.8.7 Versicherter/Versicherung

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	HLD	Holder	Teilnehmer hält ein finanzielles Instrument
templateId	1.2.40.0.34.11.1.1.6	-	Template ID zur Identifikation dieser Art von Beteiligten
functionCode	-	-	Wird nicht angegeben
@classCode	POLHOLD	Policy holder	Halter einer Versicherungspolizze

1.3.8.7.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.1.1.6/static-2017-07-20T095742

1.3.8.8 Betreuende Organisation

Als betreuende Organisation ist jene Organisation anzusehen, welche den Patienten nach Entlassung betreut (Trägerorganisationen, Vereine).

Beispiele: Mobile Hauskrankenpflege, Wohn- und Pflegeheime, Behinderteneinrichtungen, sozial betreutes Wohnen, …

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	IND	Indirect target	In indirektem Bezug
templateId	1.2.40.0.34.11.1.1.7	-	Template ID zur Identifikation dieser Art von Beteiligten
functionCode	-	-	Wird nicht angegeben
@classCode	CAREGIVER	Betreuer	Betreuende Entität

1.3.8.8.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.1.1.7/static-2017-07-21T105505

1.3.8.9 Weitere Behandler

Über dieses Element können weitere an der medizinischen Behandlung maßgeblich beteiligte Personen angegeben werden. Das können Ärzte aus der gleichen oder einer anderen Abteilung sein, weiters niedergelassene behandelnde Ärzte (z.B. der behandelnde Internist oder Kinderarzt) aber auch nicht-ärztliche Behandler, wie z.B. Psychologen.

Die Angabe dieses Elements ist grundsätzlich optional, wobei in den speziellen Leitfäden eine verpflichtende Angabe spezifiziert sein kann. Bei Verwendung sollen möglichst präzise Kontaktdaten angegeben werden. Es obliegt der dokumenterzeugenden Organisation zu entscheiden, welche weitere Behandler sie veröffentlicht.

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	CON	Consultant	Weitere Behandler
templateId	1.2.40.0.34.11.1.1.8	-	Template ID zur Identifikation dieser Art von Beteiligten
functionCode	Wert aus Value Set ELGA_Funktionscodes		Angabe der Funktion bzw. der Fachrichtung des Behandlers
@classCode	PROV	Healthcare provider	Gesundheitsdienstanbieter

1.3.8.9.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.1.1.8/static-2017-07-21T105629

1.4 Zuweisung und Ordermanagement

1.4.1 Auftrag („inFulfillmentOf“)

Das Element inFulfillmentOf enthält den Bezug zum zugrundeliegenden Auftrag des Auftraggebers. Dies kann zum Beispiel eine Auftrags- oder Anforderungsnummer sein. Das Element erlaubt genau ein order Unterelement.

Auszug aus dem R-MIM:

Abbildung 14: Klassen rund um den Zuweisung und Ordermanagement.

1.4.1.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20009/static-2017-07-21T110855

1.5 Dokumentation der Gesundheitsdienstleistung

1.5.1 Service Events („documentationOf/serviceEvent“)

Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z. B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.

In serviceEvent/effectiveTime kann der Zeitpunkt/Zeitraum der Gesundheitsdienstleistung angegeben werden. Im Gegensatz zum Encounter (siehe Kapitel „Informationen zum Patientenkontakt“), der ggf. mehrere Gesundheitsdienstleistungen „umrahmt“.

Da diese Informationen in die XDS-Metadaten übernommen werden, ergeben sich folgende Implikationen:

• Die serviceEvents sind die einzigen (rein) medizinischen Informationen zum Dokument im Dokumentenregister
• Können daher als Such-/Filterkriterium verwendet werden
• Scheint ggf. in den Ergebnissen der Suchabfragen auf

-> Sollte eine wertvolle Information sein (für den Behandler!)

Auszug aus dem R-MIM:

Abbildung 15: Klassen rund um die Gesundheitsdienstleistung.

1.5.1.1 Spezifikation

Da dieses Element automatisch in die XDS-Metadaten übernommen wird, SOLL mindestens eine Gesundheitsdienstleistung als documentationOf/serviceEvent-Element angegeben werden [R2].

ACHTUNG: Die Zeitangaben der Gesundheitsdienstleistung (erstes documentationOf/serviceEvent-Element) werden in die Dokument-Metadaten übernommen!

Die Bedeutung der Dokument-Metadaten-Elemente lautet daher wie folgt:

serviceStartTime: Beginn des ersten documentationOf/serviceEvent-Elements
serviceStopTime: Ende des ersten documentationOf/serviceEvent-Elements

Die semantische Bedeutung dieser Zeitpunkte wird in den speziellen Implementierungs-leitfäden festgelegt.

Es können beliebig viele weitere Gesundheitsdienstleistungen als weitere documentationOf/serviceEvent-Elemente angegeben werden.

1. REDIRECT 1.2.40.0.34.11.20010/static-2017-08-09T153928

Verweis auf speziellen Implementierungsleitfaden:
serviceEvent Element Allgemein
Ob eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
code
Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
effectiveTime
Welche Start- und Endezeiten eingetragen werden sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
performer
Ob und welche durchführende Entität eingetragen werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

effectiveTime
Hinweis: Für die automatisierte Datenübernahme aus dem CDA-Dokument in die XDS-Dokumentmetadaten ist stets ein Zeitintervall anzugeben.

1.6 Bezug zu vorgehenden Dokumenten

1.6.1 Allgemeines

Dieses Kapitel beschreibt die Versionsverwaltung von CDA-Dokumenten.

Der Bezug zu Vorgängerversionen von Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse (siehe Versionierung des Dokuments), spezifiziert.

Abbildung 16: Grundsätzlicher Aufbau eines CDA-Dokuments aus XML Sicht.

Der Bezug zum Vordokument wird dabei über die parentDocument Beziehung ausgedrückt, in dem der dazugehörige @typeCode einen Wert aus der Liste der gültigen @typeCodes in der relatedDocument-Beziehung erhält. Das Originaldokument, auf das sich das Dokument bezieht, bleibt dabei unverändert.

Liste der möglichen Werte der @typeCodes in der relatedDocument Beziehung:

code	displayName	Bedeutung
APND	append	Verwendung NICHT ERLAUBT Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.
RPLC	replaces	Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "überholt" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.
XFRM	transformed	Verwendung NICHT ERLAUBT Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen. Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden. Es ist nicht auszuschließen, dass die Transformation in lokalen Affiniy Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

Tabelle 4: Vokabel-Domäne relatedDocument.typeCode

1.6.1.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20011/static-2017-07-21T112308

1.7 Einverständniserklärung

1.7.1 Autorisierung („authorization“)

In dieser optionalen Klasse können die Einverständniserklärungen reflektiert werden, die mit dem Dokument verbunden sind. Dies kann ein Einverständnis für einen Eingriff oder die Verfügbarmachung der Informationen gegenüber Dritten beinhalten. Der Typ der Einverständniserklärung wird dabei in Consent.code angegeben.

Auszug aus dem R-MIM:

Abbildung 17: Consent Klasse.

1.7.1.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20012/static-2017-07-21T112451

1.8 Informationen zum Patientenkontakt

1.8.1 Encounter („componentOf/encompassingEncounter“)

Diese Klasse repräsentiert Informationen, in welchem Rahmen der Patientenkontakt, der dokumentiert wird, stattgefunden hat. Dokumente werden nicht notwendigerweise immer während eines Patientenkontakts erstellt, sondern ggf. auch zu einem späteren Zeitpunkt, wenn beispielsweise ein Arzt wegen eines pathologischen Laborwertes den Patienten vergeblich versucht zu erreichen und dennoch seine Verlaufsdokumentation fortführt.

Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, muss die Information in dieser Klasse mitgegeben werden, inklusive der Dauer des Aufenthalts (hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) und der Einrichtung, wo der Patientenaufenthalt stattfand.

Auszug aus dem R-MIM:

Abbildung 18: EncompassingEncounter Klasse und Umgebung.

1.8.1.1 Spezifikation

1. REDIRECT 1.2.40.0.34.11.20013/static-2017-07-21T113225

1.8.1.1.1 encompassingEncounter Element Allgemein

Verweis auf speziellen Implementierungsleitfaden:
Ob der Patientenkontakt angegeben werden muss, und welche Bedeutung dieses Element hat ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

1.8.1.1.2 id

Grundsätzlich sind die Vorgaben gemäß Kapitel „id-Element II“ zu befolgen.

Verweis auf speziellen Implementierungsleitfaden:
Ob, und welche Identifikation eingetragen werden soll ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

1.8.1.1.3 code

Grundsätzlich sind die Vorgaben gemäß Kapitel „code-Element CE CWE“ zu befolgen.

Verweis auf speziellen Implementierungsleitfaden:
Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

1.8.1.1.4 effectiveTime

Verweis auf speziellen Implementierungsleitfaden:
Welche Start- und Endezeiten eingetragen werden sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

1.8.1.1.5 responsibleParty

Die verantwortliche Person für den Patientenkontakt (Aufenthalt) KANN optional angegeben werden.

Verweis auf speziellen Implementierungsleitfaden:
Die konkrete Bedeutung der verantwortlichen Person für den Patientenkontakt (Aufenthalt) und eine ggf. verpflichtende Angabe dieses Elements ergeben sich aus dem jeweiligen speziellen Implementierungsleitfaden.

1.8.1.1.6 location

Die Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand, MUSS verpflichtend angegeben werden (z.B.: die entlassende Krankenanstalt mit Abteilung).

Verweis auf speziellen Implementierungsleitfaden:
Die konkrete Bedeutung der Organisation, in deren Verantwortungsbereich der Patientenkontakt (Aufenthalt) stattfand, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.