CDA Header

1 Administrative Daten (CDA Header)

Dieses Kapitel basiert auf dem entsprechenden Kapitel im „Allgemeinen Implementierungsleitfaden“ [4] und beschreibt die laborspezifischen Implementierungen bzw. über die Basisdefinitionen hinausgehenden Spezifikationen zum Thema „Laborbefund“.

1.1 Überblick

Feld	Element	Opt	Kapitel
Daten zum Dokument
Realm Code	ClinicalDocument/realmCode	M	Link
Dokumentenformat	ClinicalDocument/typeId	M	Link
Dokumenten-ID	ClinicalDocument/id	M	Link
Vertraulichkeitscode	ClinicalDocument/confidentialityCode	M	Link
Sprachcode	ClinicalDocument/languageCode	M	Link
Template	ClinicalDocument/templateId	M	Link
Dokumenttitel	ClinicalDocument/title	M	Link
Dokumentenklasse	ClinicalDocument/code	M	Link
Dokumentdatum	ClinicalDocument/effectiveTime	M	Link
Versionierung des Dokuments	ClinicalDocument/setId ClinicalDocument/versionNumber	M	Link
Teilnehmende Parteien
Patient	ClinicalDocument/recordTarget	M	Link
Verwalter des originalen Dokuments	ClinicalDocument/custodian	M	Link
Rechtlicher Unterzeichner	ClinicalDocument/legalAuthenticator	M [1..1]	Link
Verfasser des Dokuments	ClinicalDocument/author	M [1..*]	Link
Vorgesehener Empfänger	ClinicalDocument/informationRecipient	O [0..*]	Link
Validatoren	ClinicalDocument/authenticator	O [0..*]	Link
Referenz zum Auftrag
Auftraggeber (IHE „Ordering Provider“)	ClinicalDocument/participant@typeCode=“REF“	R [1..1]	Link
Auftragsidentifikation	ClinicalDocument/inFulfillmentOf/order	M [1..1]	Link
Dokumentation der Gesundheitsdienstleistung
Service Events	ClinicalDocument/documentationOf/serviceEvent	M [1..*]	Link
Durchführende Labors	ClinicalDocument/documentationOf/serviceEvent/performer	O [0..*]	Link
Informationen zum Patientenkontakt
Encounter	ClinicalDocument/componentOf/encompassingEncounter	O [0..1]	Link

Tabelle 2: Überblick administrative Daten (Header)

1.2 Dokumentenstruktur

1.2.1 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

• XML Metainformationen
• Wurzelelement
• Hoheitsbereich („realmCode“)
• Dokumentformat („typeId“)
• Dokumenten-Id („id”)
• Erstellungsdatum des Dokuments („effectiveTime“)
• Vertraulichkeitscode („confidentialityCode“)
• Sprachcode des Dokuments („languageCode“)

Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.

Auszug aus dem Allgemeinen Implementierungsleitfaden

1.2.2 XML Metainformationen

1.2.2.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.2.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.3 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 speziellen Leitfäden können weitere namespace-Präfixe angegeben werden.

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.4 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.4.1 Strukturbeispiel

<realmCode code="AT'"/>

1.2.4.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.5 Dokumentformat („typeId“)

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

1.2.5.1 Strukturbeispiel

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

1.2.5.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.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 Erstellungsdatum des Dokuments („effectiveTime“)

1.2.7.1 Spezifikation

Id	1.2.40.0.34.11.90008 ref elgabbr-	Gültigkeit	2016‑07‑21 Andere Versionen mit dieser Id: CDeffectiveTime vom 2013‑11‑07
Status	Aktiv	Versions-Label
Name	CDeffectiveTime	Bezeichnung	CD effectiveTime
Beschreibung Mit Erstellungsdatum ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird. (z.B.: Wien, am …). Das Erstellungsdatum dokumentiert den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde. Bemerkung: Das Erstellungsdatum des Dokuments muss nicht mit dem Datum der rechtli-chen Unterzeichnung (oder „Vidierung“) übereinstimmen.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-8  Erstellungsdatum  Datensatz
Beziehung	Version: Template 1.2.40.0.34.11.90008 CD effectiveTime (2016‑07‑21) ref elgabbr-
Beispiel	Nur Datum: Zeitpunkt als Datum (ohne Zeit) im Format YYYYMMDD <effectiveTime value="20081224"/>
Beispiel	Datum, Zeit und Zeitzone: Zeitpunkt als Datum mit Zeit und Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM <effectiveTime value="20081224082015+0100"/>
Item DT Kard Konf Beschreibung Label hl7:effectiveTime TS.AT.TZ 1 … 1 M Erstellungsdatum des Dokuments. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (CDe...ime)   elgagab-data​element-8  Erstellungsdatum  Datensatz

1.2.8 Vertraulichkeitscode („confidentialityCode“)

1.2.8.1 Spezifikation

Id	1.2.40.0.34.11.90009 ref elgabbr-	Gültigkeit	2013‑11‑07
Status	Aktiv	Versions-Label
Name	CDconfidentialityCode	Bezeichnung	CD confidentialityCode
Beschreibung “Vertraulichkeitscode” (im CDA das Element ClinicalDocument/confidentialityCode) bezeichnet die Vertraulichkeitsstufe dieses Dokuments. Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden. Die Information des Vertraulichkeitscodes im Dokument selbst, dient nur der reinen Information und hat keine technischen Konsequenzen. Da Dokumente nach der Vidierung weder technisch noch legistisch geändert werden dürfen, kann der Vertraulichkeitscode keine konkreten Zugriffsrechte auf das Dokument regeln, sondern nur auf „Metaebenen“, wie beispielsweise „geltendes Recht XY“ oder weiterführende Verwendungen über das IHE BPPC Profil, verweisen.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-266  Vertraulichkeitscode  Datensatz
Beziehung	Version: Template 1.2.40.0.34.11.90009 CD confidentialityCode (2013‑11‑07) ref elgabbr-
Beispiel	Beispiel <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25" displayName="normal"/>
Item DT Kard Konf Beschreibung Label hl7:confidentialityCode CE 1 … 1 M (CDc...ode)   elgagab-data​element-266  Vertraulichkeitscode  Datensatz @code CONF 1 … 1 F N @codeSystem 1 … 1 F 2.16.840.1.113883.5.25 (BasicConfidentialityKind) @displayName 1 … 1 F normal

1.2.9 Sprachcode des Dokuments („languageCode“)

1.2.9.1 Spezifikation

Id	1.2.40.0.34.11.90010 ref elgabbr-	Gültigkeit	2013‑11‑07
Status	Aktiv	Versions-Label
Name	CDlanguageCode	Bezeichnung	CD languageCode
Beschreibung Die Sprache des Dokuments wird in diesem Attribut gemäß IETF (Internet Engineering Task Force), RFC 1766: Tags for the Identification of Languages nach ISO-639-1 (zweibuchstabige Codes für Sprachen, Kleinbuchstaben) und ISO 3166 (hier: zweibuchstabige Ländercodes, Großbuchstaben) festgelegt. Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben).
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-265  Sprachcode  Datensatz
Beziehung	Version: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07) ref elgabbr-
Beispiel	Beispiel <languageCode code="de-AT"/>
Item DT Kard Konf Beschreibung Label hl7:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments. (CDl...ode)   elgagab-data​element-265  Sprachcode  Datensatz @code CONF 1 … 1 F de-AT

1.2.10 Elemente mit spezielle Vorgaben

1.2.10.1 Template („ClinicalDocument/templateId“)

Das Template definiert die Summe der Einschränkungen dieser Spezifikation in Bezug auf den CDA R2 Standard. Eine templateID für den ELGA Laborbefund ist anzugeben. Ein Dokument, welches dem vorliegenden Implementierungsleitfaden folgt, muss auch dem übergeordneten „Allgemeinen Implementierungsleitfaden“ folgen. Als templateID für CDA Labordokumente gemäß diesem Leitfaden ist 1.2.40.0.34.11.4 zu verwenden.

1.2.10.1.1 Strukturbeispiel

<ClinicalDocumentxmlns="urn:hl7-org:v3">
  : 	
  <!-- ELGA CDA Dokumente -->
  <templateId root="1.2.40.0.34.11.1"/>
  <!-- ELGA CDA Laborbefund -->
  <templateId root="1.2.40.0.34.11.4"/>

  <!--   In Abhängigkeit von der ELGA Interoperabilitätsstufe (EIS) -->
  <!-- EIS „Basic“ -->
  <templateId root="1.2.40.0.34.11.4.0.1"/>
  ... oder ...
  <!-- EIS „Enhanced“ -->
  <templateId root="1.2.40.0.34.11.4.0.2"/>
  ... oder ...
  <!-- EIS „Full support“ -->
  <templateId root="1.2.40.0.34.11.4.0.3"/>
  :
</ClinicalDocument>

1.2.10.1.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
templateId	II	1..1	M	ELGA TemplateId für den Allgemeinen Implementierungsleitfaden Fester Wert: @root = 1.2.40.0.34.11.1
templateId	II	1..1	M	ELGA TemplateId für den speziellen Implementierungsleitfaden Laborbefund Fester Wert: @root = .2.40.0.34.11.4
--- zusätzlich eine der folgenden templateIds ---
Im Falle von EIS „Basic“ (Das Dokument enthält entweder unstrukturierten oder eingebetteten Inhalt (z.B. PDF) oder enthält strukturierten Inhalt, wobei jedoch nicht alle Sektionen den Vorgaben von EIS „Enhanced“ oder höher folgen)
templateId	II	1..1	M	ELGA CDA Laborbefund Fester Wert @root = 1.2.40.0.34.11.4.0.1
--- oder ---
Im Falle von EIS „Enhanced“ (Alle Sections folgen ausnahmelos den Vorgaben von EIS „Enhanced“ oder höher, aber nicht alle Sections folgen den Vorgaben von EIS „Full support“)
templateId	II	1..1	M	ELGA CDA Laborbefund in EIS „Enhanced“ Fester Wert @root = 1.2.40.0.34.11.4.0.2
--- oder ---
Im Falle von EIS „Full support“: (Alle Sektionen folgen ausnahmslos den Vorgaben von EIS „Full support“)
templateId	II	1..1	M	ELGA CDA Laborbefund in EIS „Full support“ Fester Wert @root = 1.2.40.0.34.11.4.0.3

1.2.10.2 Dokumentenklasse (“ClinicalDocument/code”)

Die zur Anwendung kommende Dokumentenklasse wird durch den LOINC Code 11502-2 für einen allgemeinen Laborbefund („multidisciplinary laboratory report“) abgebildet.

Diese Codierung stellt einen allgemeinen Laborbefund dar, der es erlaubt beliebige Befundarten und Ergebnisse im Rahmen eines Dokumentes zu übermitteln, auch wenn der Befund nur eine bestimmte Befundart (wie z.B. Hämatologie) enthält. Diesem Umstand wird jedoch durch die Angabe der enthaltenen Laborbefundarten bei der Registrierung eines Labordokumentes in der Registry Rechnung getragen. Durch die Registrierung der in einem Labordokument enthaltenen Befundkategorien über die Service-Event-Metadaten („eventCodeList“) sind auch Detailbefunde in der ELGA einfach auffindbar.

Der Mikrobiologiebefund ist in den ServiceEvents mit dem Code 18725-2 (Microbiology studies) anzugeben.

1.2.10.2.1 Strukturbeispiel

<ClinicalDocumentxmlns="urn:hl7-org:v3">
	:
	<!-- Dokumentenklasse -->
        <code code="11502-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Laboratory report"/>
	
	<!-- Titel des Dokuments -->
	<title>Allgemeiner Laborbefund</title>
	:
</ClinicalDocument>

1.2.10.2.2 Spezifikation

Element/Attribut		DT	Kard	Konf	Beschreibung
code		CE CWE	1..1	M	Code des Dokuments
	@code	cs	1..1	M	Fester Wert: 11502-2 (aus Value Set „ELGA_Dokumentklassen“ )
	@displayName	st	0..1	R2	Fester Wert: Laboratory report
	@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.6.1
	@codeSystemName	ADXP	0..1	R2	Fester Wert: LOINC

1.2.10.3 Dokumenttitel („ClinicalDocument/title“)

Der Titel des Dokumentes ist verpflichtend anzugeben, vom Ersteller frei zu vergeben und beschreibt die Art des Dokumentes näher. Der Titel des Dokuments ist für den lesenden Dokumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title. Der Sinn der Benennung ist jedoch gemäß der Dokumentenklassen zu wählen. Im allgemeinen Fall wird die Bezeichnung „Laborbefund“ verwendet.

1.2.10.3.1 Strukturbeispiel

<ClinicalDocumentxmlns="urn:hl7-org:v3">
	:
	<!-- Dokumentenklasse -->
        <code code="11502-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Laboratory report"/>
	
	<!-- Titel des Dokuments -->
	<title>Allgemeiner Laborbefund</title>
	:
</ClinicalDocument>

1.2.10.3.2 Spezifikation

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

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

Für alle Dokumente ist gemäß den Vorgaben des „Allgemeinen Implementierungsleitfadens“ eine Versionierung verpflichtend vorzusehen. Für Detailinformationen wird auf dieses Dokument verwiesen.

<ClinicalDocument xmlns="urn:hl7-org:v3">
	:
	<!-- Versionierung des Dokuments -->
	<setId root="2.2.40.0.34.99.111.1.1" extension="AAAAAAAAAAAAAAAAAAA"/>
	<versionNumber value="1"/>
	:
</ClinicalDocument>

1.3 Teilnehmende Parteien

1.3.1 IHE LAB TF-3 Konformität

Gem. [3] sind für Angaben zu Personen und Organisationen die Elemente name, addr und telecom verpflichtend. Ausgenommen sind Elemente definiert in Elemente ohne spezielle Vorgaben.

1.3.2 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

• Patient (recordTarget/patientRole)
• Personen bei der Dateneingabe (dataEnterer)
• Verwahrer des Dokuments (custodian)
• Beabsichtigte Empfänger des Dokuments(informationRecipient)

Verweis auf Allgemeinen Leitfaden:
Die Elemente erfordern keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.

Auszug aus dem Allgemeinen Implementierungsleitfaden

1.3.3 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.3.1 Spezifikation

Id	1.2.40.0.34.11.20001 ref elgabbr-	Gültigkeit	2017‑07‑20 Andere Versionen mit dieser Id: Header​Record​Target vom 2018‑10‑18 14:23:51 Header​Record​Target vom 2017‑03‑27 Header​Record​Target vom 2013‑10‑08 Header​Record​Target vom 2013‑02‑10 Header​Record​Target vom 2011‑12‑19
Status	Entwurf	Versions-Label
Name	Header​Record​Target	Bezeichnung	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)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-9  Patient  Datensatz
Benutzt	Benutzt 1 Template 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 Header​Record​Target (2017‑03‑27) ref elgabbr-
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)   elgagab-data​element-9  Patient  Datensatz @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 Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein. (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.3.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.3.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.3.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.3.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.4 Personen der Dateneingabe („dataEnterer“)

1.3.4.1 Spezifikation

Id	1.2.40.0.34.11.20003 ref elgabbr-	Gültigkeit	2013‑02‑10 Andere Versionen mit dieser Id: HeaderDataEnterer vom 2011‑12‑19
Status	Entwurf	Versions-Label
Name	HeaderDataEnterer	Bezeichnung	HeaderDataEnterer
Beschreibung	Die das Dokument „schreibende“ Person (z.B. Schreibkraft, Stationsschwester, …). Das Element "DataEnterer" ist bei automatisch erstellten Dokumenten nicht notwendig.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-65  Schreibkraft  Datensatz
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.40.0.34.11.90003 Inklusion AssignedEntityElements DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20003 HeaderDataEnterer (2013‑02‑10) ref elgabbr-
Beispiel	Beispiel <dataEnterer>   <!-- Zeitpunkt des Schreibens -->   <time value="20081224082015+0100"/>  <assignedEntity>     <!-- Die das Dokument schreibende Person -->     <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>    <telecom value="tel:+43.1.40400.4711"/>    <telecom value="mailto:eva.musterfrau@amadeusspital.at"/>    <assignedPerson>       <name>DiplKrSr. Eva Musterfrau</name>    </assignedPerson>  </assignedEntity></dataEnterer>
Item DT Kard Konf Beschreibung Label hl7:dataEnterer Person der Dateneingabe. (Hea...rer)   elgagab-data​element-65  Schreibkraft  Datensatz hl7:time TS.AT.TZ 0 … 1 Der Zeitpunkt an dem das Dokument geschrieben wurde. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (Hea...rer) hl7:assignedEntity 1 … 1 R Personendaten der schreibenden Person Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen. (Hea...rer) Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC) hl7:id II 1 … * R Mindestens eine Id der validierenden Person. Zugelassene nullFlavor: UNK (Hea...rer) hl7:addr AD 0 … 1 Ein Adress-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...rer) hl7:telecom TEL.AT 0 … * Mindestens ein Telecom-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...rer) hl7:assigned​Person 1 … 1 M Persondendaten der validierenden Person. (Hea...rer) Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name der Person 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...rer) hl7:represented​Organization 0 … 1 Organistationsdaten der validierenden Person. (Hea...rer) Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...rer) hl7:name ON 1 … 1 M (Hea...rer) hl7:telecom TEL.AT 0 … * (Hea...rer) hl7:addr AD 0 … 1 (Hea...rer)

1.3.5 Verwahrer des Dokuments („custodian“)

Auszug aus dem R-MIM:

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

1.3.5.1 Spezifikation

Id	1.2.40.0.34.11.20004 ref elgabbr-	Gültigkeit	2015‑05‑28 Andere Versionen mit dieser Id: HeaderCustodian vom 2011‑12‑19
Status	Aktiv	Versions-Label
Name	HeaderCustodian	Bezeichnung	HeaderCustodian
Beschreibung Der „Verwahrer des Dokuments“ ist diejenige Organisation, die „für die Verwahrung/Verwaltung des Dokuments verantwortlich ist“. Beispiele: Das erstellende Krankenhaus ist selbst der Verwalter des Dokuments. Der übergeordnete Krankenhausträger ist der Verwalter des Dokuments.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-73  Verwahrer  Datensatz
Beziehung	Version: Template 1.2.40.0.34.11.20004 HeaderCustodian (2015‑05‑28) ref elgabbr- Version: Template 1.2.40.0.34.11.20004 HeaderCustodian (2011‑12‑19) ref elgabbr-
Beispiel	Vollständiges Beispiel <custodian typeCode="CST">   <assignedCustodian classCode="ASSIGNED">     <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">       <id root="1.2.3.999" extension="--example only--" assigningAuthorityName="GDA-Index"/>      <name>Amadeus Spital</name>      <telecom value="tel:+43.(0)50.55460-0"/>      <addr>         <streetName>Hafenstraße</streetName>        <houseNumber>47-51</houseNumber>        <postalCode>4020</postalCode>        <city>Linz</city>        <state>Oberösterreich</state>        <country>AUT</country>      </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>
Beispiel	Minimalbeispiel <custodian>   <assignedCustodian>     <representedCustodianOrganization>       <id root="1.2.3.999" extension="--example only--"/>      <name>Amadeus Spital</name>      <addr>         <streetAddressLine>Hafenstraße 47-51</streetAddressLine>        <postalCode>4020</postalCode>        <city>Linz</city>        <country>AUT</country>      </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>
Item DT Kard Konf Beschreibung Label hl7:custodian Verwahrer des Dokuments. (Hea...ian)   elgagab-data​element-73  Verwahrer  Datensatz @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M (Hea...ian) @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M (Hea...ian) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 1 … 1 R Identifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben. Grundsätzlich sind die Vorgaben für „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 (Hea...ian) hl7:name 1 … 1 M Name des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen. (Hea...ian) hl7:telecom TEL.AT 0 … 1 Kontaktdaten des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen. (Hea...ian) hl7:addr AD 1 … 1 M Adresse des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen. (Hea...ian)

1.3.5.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.6 Beabsichtigte Empfänger des Dokuments („informationRecipient“)

Auszug aus dem R-MIM:

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

1.3.6.1 Spezifikation

Id	1.2.40.0.34.11.20005 ref elgabbr-	Gültigkeit	2011‑12‑19
Status	Entwurf	Versions-Label
Name	Header​Information​Recipient	Bezeichnung	Header​Information​Recipient
Beschreibung Die beabsichtigten Empfänger des Dokuments können in der Klasse intendedRecipient näher angegeben werden. Hierbei ist zu beachten, dass es sich um die unmittelbar bei der Erstellung des Dokuments festgelegten bzw. bekannten Empfänger handelt. Beispiel: Bei der Erstellung der Dokumentation ist beispielsweise schon bekannt, dass man das Dokument primär an den Hausarzt und ggf. als Kopie an einen mitbehandelnden Kollegen senden wird. In diesem Fall sollten genau diese beiden Empfänger angegeben werden. Empfohlene Information für einen Empfänger ist die ID aus dem GDA-Index, sein Name in möglichst hoher Granularität und die Organisation, der er angehört in möglichst hoher Granularität. Aufgrund der gängigen Praxis kann als minimale Information für den Empfänger der unstrukturierte Name angegeben werden.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-259  Empfänger  Datensatz
Benutzt	Benutzt 2 Templates Benutzt als Name Version 1.2.40.0.34.11.90001 Inklusion PersonElements DYNAMIC 1.2.40.0.34.11.90002 Inklusion OrganizationElements DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20005 Header​Information​Recipient (2011‑12‑19) ref elgabbr-
Beispiel	Beabsichtigter Empfänger ist eine bekannte Person <informationRecipient typeCode="PRCP">   <intendedRecipient>     <!-- Identifikation des beabsichtigten Empfängers -->     <id nullFlavor="UNK"/>    <!-- Personendaten des beabsichtigten Empfängers -->     <informationRecipient>       <name>         <prefix qualifier="AC"> Dr.</prefix>        <given>Robert</given>        <family>Empfänger</family>      </name>    </informationRecipient>    <!-- Organisation, der der beabsichtigte Empfänger angehört -->     <receivedOrganization>       <!-- Name der Organisation des beabsichtigten Empfängers -->       <name>Ordination Dr. Empfänger</name>      <!-- Kontaktdaten der Organisation des beabsichtigten Empfängers -->       <telecom value="tel:0512.1234567"/>      <telecom value="fax:0512.1234567.11"/>      <telecom value="mailto:office@ordination-empfaenger.at"/>      <telecom value="http://www.ordination-empfaenger.at"/>      <telecom value="me:12345678791"/>      <!-- Adresse der Organisation des beabsichtigten Empfängers -->       <addr>         <streetName>Musterstraße</streetName>        <houseNumber>27/1/13</houseNumber>        <postalCode>6020</postalCode>        <city>Innsbruck</city>        <country>AUT</country>      </addr>    </receivedOrganization>  </intendedRecipient></informationRecipient>
Beispiel	Beabsichtigter Empfänger ist eine unbekannte Person („An den Hausarzt“) <informationRecipient typeCode="PRCP">   <intendedRecipient>     <id nullFlavor="UNK"/>    <informationRecipient>       <name>Hausarzt</name>    </informationRecipient>  </intendedRecipient></informationRecipient>
Beispiel	Beabsichtigter Empfänger ist der Patient selbst <informationRecipient typeCode="PRCP">   <intendedRecipient>     <!-- Der Patient besitzt keine ID -->     <id nullFlavor="NI"/>    <!-- Hinweis auf den Patienten -->     <informationRecipient>       <name>Ergeht an den Patienten Dr. Herbert Mustermann</name>    </informationRecipient>  </intendedRecipient></informationRecipient><!--Eine erneute Angabe der Adresse des Patienten ist nicht erforderlich.-->
Item DT Kard Konf Beschreibung Label hl7:information​Recipient Beabsichtiger Empfänger des Dokuments. (Hea...ent)   elgagab-data​element-259  Empfänger  Datensatz @typeCode cs 0 … 1   Typ des Informationsempfängers. Bsp: PRCP „Primärer Empfänger“ Wird das Attribut weggelassen, gilt der Empfänger als primärer Empfänger.   CONF Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.29 ELGA_InformationRecipientType (DYNAMIC) hl7:intended​Recipient 1 … 1 M (Hea...ent) hl7:id II 1 … * R Identifikation des beabsichtigten Empfängers (Person).Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. Zugelassene nullFlavor: NI … Person hat keine ID UNK ... Person hat eine ID, diese ist jedoch unbekannt (Hea...ent)   Beispiel <id nullFlavor="UNK" assigningAuthorityName="GDA Index"/> hl7:information​Recipient 1 … 1 M Personendaten des beabsichtigten Empfängers. Grundsätzlich sind die Vorgaben gemäß Kapitel „Personen-Element“ zu befolgen. (Hea...ent) Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name der Person 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...ent) hl7:received​Organization 0 … 1 Organisation, der der beabsichtigte Empfänger angehört.z.B.: „Ordination des empfangenden Arztes“ Grundsätzlich sind die Vorgaben gemäß Kapitel „Organisations-Element“ zu befolgen. (Hea...ent) Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...ent) hl7:name ON 1 … 1 M (Hea...ent) hl7:telecom TEL.AT 0 … * (Hea...ent) hl7:addr AD 0 … 1 (Hea...ent)

1.3.7 Verfasser des Dokuments („ClinicalDocument/author“)

Der Autor ist grundsätzlich der „das Dokument verfassende Arzt“. Damit sind diejenigen Personen gemeint, welche das Dokument „inhaltlich“ verfassen (z.B.: diktieren, erheben, messen). Der Autor kann entweder eine Person, ein Software System oder beides sein. Gemäß [3] MUSS mindestens eine Person als Autor angegeben werden, mehrere Autoren sind zulässig.

1.3.8 Medizinischer Validator („ClinicalDocument/legalAuthenticator“)

Das verpflichtende legalauthenticator-Element MUSS angegeben werden und repräsentiert den rechtlichen Unterzeichner (typischerweise der „Medizinische Validator“ oder der laborverantwortliche Arzt).

Im ELGA Referenz-Stylesheet wird der rechtliche Unterzeichner als „Unterzeichnet von“ dargestellt.

1.3.9 Validator („ClinicalDocument/authenticator“)

Ein authenticator-Element repräsentiert einen Validator, der das Dokument inhaltlich freigibt (zusätzliche medizinische und technische Validatoren). Es können mehrere Validatoren angegeben werden. Einer davon kann auch ident mit dem „rechtlichen Unterzeichner“ („ClinicalDocument/legalAuthenticator“) sein.

Aufgrund der Konformität zu IHE [3] ist die Angabe von name, addr und telecom verpflichtend. Der „Validator“ ist weiters mit der templateId „1.3.6.1.4.1.19376.1.3.3.1.5“ zu kennzeichnen.

1.3.9.1 Spezifikation

Id	1.2.40.0.34.11.20007 ref elgabbr-	Gültigkeit	2011‑12‑19 Andere Versionen mit dieser Id: HeaderAuthenticator vom 2018‑10‑18 14:33:54
Status	Entwurf	Versions-Label
Name	HeaderAuthenticator	Bezeichnung	HeaderAuthenticator
Beschreibung	Dokumente können neben dem verpflichtenden legalAuthenticator („rechtlichen Unterzeichner“, Hauptunterzeichner) auch beliebig viele weitere Mitunterzeichner beinhalten.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-86  Weitere Unterzeichner  Datensatz
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.40.0.34.11.90003 Inklusion AssignedEntityElements DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20007 HeaderAuthenticator (2011‑12‑19) ref elgabbr-
Beispiel	Strukturbeispiel <authenticator>   <!-- Zeitpunkt der Unterzeichnung -->   <time value="20130324081915+0100"/>  <!-- Signaturcode -->   <signatureCode code="S"/>  <!-- Personen- und Organisationsdaten des Weiteren Unterzeichners des Dokuments -->   <assignedEntity>     <id root="1.2.40.0.34.99.111.1.3" extension="3333" assigningAuthorityName="Amadeus Spital"/>    <telecom use="WP" value="tel:+43.6138.3453446.3333"/>    <assignedPerson>       <!-- Name des Weiteren Unterzeichners des Dokuments -->       <name>         <prefix>Dr.</prefix>        <given>Walter</given>        <family>Hummel</family>      </name>    </assignedPerson>    <!-- Organisation, in deren Auftrag der Weiteren Unterzeichner des Dokuments die Dokumentationunterzeichnet hat -->     <representedOrganization>       <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <name>Amadeus Spital - Chirurgische Abteilung</name>      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="fax:+43.6138.3453446.4674"/>      <telecom value="mailto:info@amadeusspital.at"/>      <telecom value="http://www.amadeusspital.at"/>      <addr>         <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>    </representedOrganization>  </assignedEntity></authenticator>
Beispiel	Strukturbeispiel Laborbefund <authenticator>   <templateId root="1.3.6.1.4.1.19376.1.3.3.1.5"/>  <time value="20121201155300+0100"/>  <signatureCode code="S"/>  <assignedEntity>     <id nullFlavor="NA"/>    <addr nullFlavor="NA"/>    <telecom value="tel: +43.1.12345678"/>    <assignedPerson>       <name>         <prefix qualifier="AC">Dr.</prefix>        <given>Otto</given>        <family>Rotadilav</family>      </name>    </assignedPerson>    <representedOrganization>       <id root="1.2.40.0.34.3.1.999" assigningAuthorityName="EHSREG"/>      <name>Zentrallabor</name>      <telecom value="tel: +43.1.12345678"/>      <addr>         <streetAddressLine>Laborplatz 1</streetAddressLine>        <city>Wien</city>        <postalCode>1200</postalCode>        <country>AUT</country>      </addr>    </representedOrganization>  </assignedEntity></authenticator>
Item DT Kard Konf Beschreibung Label hl7:authenticator Weitere Unterzeichner. (Hea...tor)   elgagab-data​element-86  Weitere Unterzeichner  Datensatz @typeCode cs 0 … 1 F AUTHEN hl7:time TS.​DATE.​MIN 1 … 1 R Der Zeitpunkt, an dem das Dokument unterzeichnet wurde. Grundsätzlich sind die Vorgaben gemäß für „Zeit-Elemente“ zu befolgen. Zugelassene nullFlavor: UNK (Hea...tor) hl7:signatureCode CS 1 … 1 M (Hea...tor) @code CONF 1 … 1 F S hl7:assignedEntity 1 … 1 M Personendaten des weiteren Unterzeichners.Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen. (Hea...tor) Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC) hl7:id II 1 … * R Mindestens eine Id der validierenden Person. Zugelassene nullFlavor: UNK (Hea...tor) hl7:addr AD 0 … 1 Ein Adress-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...tor) hl7:telecom TEL.AT 0 … * Mindestens ein Telecom-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...tor) hl7:assigned​Person 1 … 1 M Persondendaten der validierenden Person. (Hea...tor) Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name der Person 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...tor) hl7:represented​Organization 0 … 1 Organistationsdaten der validierenden Person. (Hea...tor) Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...tor) hl7:name ON 1 … 1 M (Hea...tor) hl7:telecom TEL.AT 0 … * (Hea...tor) hl7:addr AD 0 … 1 (Hea...tor)

1.3.10 Weitere Beteiligte („participant“)

Die Kardinalitäten/Konformitäten der Beteiligten sind wie folgt geändert:

Kard	Konf	Art des Beteiligten
0..1	[R2]	Fachlicher Ansprechpartner

Es ist EMPFOHLEN, die fachliche Ansprechperson (Callback contact) im Laborbefund anzugeben.

1.4 Referenz zum Auftrag

1.4.1 Einweisender/Zuweisender/Überweisender Arzt

Aufgrund der Tatsache, dass IHE in dem Laboratory Technical Framework den Auftraggeber als participant mit dem typeCode=“REF“ führt und ELGA den einweisenden/zuweisenden/überweisenden Arzt ebenfalls als participant mit dem typeCode=“REF“ definiert, sich diese Elemente jedoch strukturell unterscheiden ist die Verwendung des ELGA Elements (mit templateId 1.2.40.0.34.11.1.1.2) NICHT ERLAUBT.

Die Verwendung dieses ELGA participant-Elements mit templateId 1.2.40.0.34.11.1.1.2 ist im Labor NICHT ERLAUBT.

1.4.2 Auftraggeber/„Ordering Provider“

Der Auftraggeber (bzw „ordering provider“, ClinicaDocument/participant@typeCode=“REF““) ist die Organisation oder der Arzt, welche/welcher den Auftrag erstellt hat. Der Auftraggeber wird als participant mit dem typeCode=“REF“ (referrer) ausgeführt und ist [R] verpflichtend anzugeben. Die Verwendung von NullFlavor ist möglich.

Der Auftraggeber ist des Weiteren mit der templateId "1.3.6.1.4.1.19376.1.3.3.1.6" zu kennzeichnen (die templateId entfällt bei Verwendung des NullFlavors).

1.4.2.1 Spezifikation

Id	1.3.6.1.4.1.19376.1.3.3.1.6 ref elgabbr-	Gültigkeit	2016‑07‑05
Status	Entwurf	Versions-Label	2016
Name	IHEOrderingProvider	Bezeichnung	Ordering Provider
Beschreibung
Kontext	Elternknoten des Template-Element mit Id 1.3.6.1.4.1.19376.1.3.3.1.6
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 2 Templates Benutzt als Name Version 1.2.40.0.34.11.90001 Inklusion PersonElements DYNAMIC 1.2.40.0.34.11.90002 Inklusion OrganizationElements DYNAMIC
Beziehung	Version: Template 1.3.6.1.4.1.19376.1.3.3.1.6 Ordering Provider (2016‑07‑05) ref elgabbr- Spezialisierung: Template 2.16.840.1.113883.10.12.108 CDA participant (2005‑09‑07) ref ad1bbr-
Beispiel	Strukturbeispiel <participant typeCode="REF">   <templateId root="1.3.6.1.4.1.19376.1.3.3.1.6"/>  <time value="20121201071500+0100"/>  <associatedEntity classCode="PROV">     <id root="2.16.840.1.113883.2.16.1.99.3.1" extension="DFRANK"/>    <addr>       <streetName>Mozartgasse</streetName>      <houseNumber>1-7</houseNumber>      <postalCode>5350</postalCode>      <city>St.Wolfgang</city>      <state>Salzburg</state>      <country>AUT</country>    </addr>    <telecom use="WP" value="tel:+43.6138.3453446.2222"/>    <associatedPerson>       <name>         <prefix qualifier="AC">Dr.</prefix>        <family>Frank</family>        <given>Dieter</given>      </name>    </associatedPerson>    <scopingOrganization>       <id extension="SampleGDA99" root="2.16.840.1.113883.2.16.1.99.3.1"/>      <name>Krankenhaus der Barmherzigen Brüder</name>      <telecom use="WP" value="tel: 01.47110815"/>      <addr nullFlavor="UNK"/>    </scopingOrganization>  </associatedEntity></participant>
Beispiel	Strukturbeispiel, wenn der Auftraggeber nicht verfügbar ist: <!-- ordering provider --> <participant nullFlavor="UNK" typeCode="REF">   <associatedEntity classCode="PROV"/></participant>
Item DT Kard Konf Beschreibung Label hl7:participant 0 … * Auftraggeber (Überweiser) Zugelassene nullFlavor: UNK … Auftraggeber ist unbekannt oder wurde nicht angegeben (IHE...der) @typeCode cs 1 … 1 F REF   In particular, when the ordering provider of the order (or group of orders) fulfilled by this laboratory report is present in the CDA, it SHALL be documented as a participant with the attribute typeCode valued “REF” (referrer). hl7:templateId II 1 … 1 M The templateId element identifies this participant as an ordering physician. The templateId SHALL have root="1.3.6.1.4.1.19376.1.3.3.1.6". (IHE...der) @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.6 hl7:associated​Entity 1 … 1 R (IHE...der) hl7:addr AD 1 … * R ClinicalDocument/participant(s) MAY be present. When present, this element SHALL be in accordance with the HL7 CDA R2 standard with a time element and further constrained by this specification to require the presence of addr. (IHE...der) hl7:telecom TEL 1 … * R ClinicalDocument/participant(s) MAY be present. When present, this element SHALL be in accordance with the HL7 CDA R2 standard with a time element and further constrained by this specification to require the presence of telecom. (IHE...der) hl7:associated​Person 0 … 1 ClinicalDocument/participant(s) MAY be present. When present, this element SHALL be in accordance with the HL7 CDA R2 standard with a time element and further constrained by this specification to require the presence of name. (IHE...der) Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name der Person 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. (IHE...der) hl7:scoping​Organization 0 … 1 All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom. (IHE...der) Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (IHE...der) hl7:name ON 1 … 1 M (IHE...der) hl7:telecom TEL.AT 0 … * (IHE...der) hl7:addr AD 0 … 1 (IHE...der)

1.4.2.2 Auftragsdatum („ClinicalDocument/participant@typeCode="REF"/time“)

Das Auftragsdatum ist das Datum/Zeit an dem der Auftrag vom Auftraggeber abgesendet wird. Das Auftragsdatum wird als time-Element beim Auftraggeber ausgeführt (siehe Kapitel Auftraggeber/Ordering Provider), und ist verpflichtend anzugeben. Bei einer manuellen Erfassung eines Auftrags im Labor kann dieses als nullFlavor=“NA“ ausgeführt werden.

1.4.3 Auftragsidentifikation („ClinicalDocument/inFulfillmentOf/order“)

Das Element beschreibt die Referenz auf den Auftrag auf der Auftraggeberseite. Es ist das id-Element für die Auftragsnummer auf Auftraggeberseite anzuführen.

Da die Referenz auf einen Auftrag im Labor eine wesentliche Information darstellt, ist das Element in Änderung zur Definition gem. „Allgemeinen Implementierungsleitfaden“ verpflichtend anzugeben.

1.4.3.1 Spezifikation

Id	1.2.40.0.34.11.20009 ref elgabbr-	Gültigkeit	2011‑12‑19
Status	Aktiv	Versions-Label
Name	HeaderInFulfillmentOf	Bezeichnung	HeaderInFulfillmentOf
Beschreibung Das Element “inFulfillmentOf” ermöglicht die Referenz zum ursprünglichen Auftrag des Auftraggebers. Dies kann zum Beispiel eine Auftrags- oder Anforderungsnummer sein. Das Element erlaubt genau ein order Unterelement.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Version: Template 1.2.40.0.34.11.20009 HeaderInFulfillmentOf (2011‑12‑19) ref elgabbr-
Beispiel	Strukturbeispiel <inFulfillmentOf typeCode="FLFS">   <order classCode="ACT" moodCode="RQO">     <id root="2.16.840.1.113883.2.16.1.99.3.1" extension="081201-004"/>  </order></inFulfillmentOf>
Item DT Kard Konf Beschreibung Label hl7:inFulfillmentOf Komponente zur Dokumentation des Auftrags. (Hea...tOf) @typeCode cs 1 … 1 F FLFS hl7:order 1 … 1 M Auftrag. (Hea...tOf) @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F RQO hl7:id II 1 … 1 M Auftragsnummer, Anforderungsnummer. Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen. (Hea...tOf)

1.5 Dokumentation der Gesundheitsdienstleistung

1.5.1 Service Events („ClinicalDocument/documentationOf/serviceEvent“)

In diesem Element erfolgt die Dokumentation der wesentlichen Untersuchungsinhalte, die in einem CDA Laborbefund enthalten sind. D.h. bei der Einbringung des Dokuments in die Registry sind die serviceEvents-Elemente die einzige Möglichkeit medizinische Informationen einzubringen. Es können beliebig viele serviceEvent-Elemente angegeben werden, es ist jedoch zumindest ein serviceEvent zu codieren.

Verweis auf Allgemeinen Leitfaden (mit Anpassungen):
Das Element ist grundsätzlich gemäß den Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“ anzugeben, es sind jedoch spezielle Vorgaben vorgeschrieben.

Auszug aus dem Allgemeinen Implementierungsleitfaden

1.6 Dokumentation der Gesundheitsdienstleistung

1.6.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.6.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.

Id	1.2.40.0.34.11.20010 ref elgabbr-	Gültigkeit	2011‑12‑19
Status	Aktiv	Versions-Label
Name	HeaderServiceEvent	Bezeichnung	HeaderServiceEvent
Beschreibung 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.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-145  Gesundheitsdienstleistung  Datensatz
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.40.0.34.11.90003 Inklusion AssignedEntityElements DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20010 (2017‑07‑21 11:18:58) ref elgabbr- Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19) ref elgabbr-
Beispiel	Strukturbeispiel Koloskopie <documentationOf typeCode="DOC">   <serviceEvent>     <code code="KOL" displayName="Koloskopie" codeSystem="2.16.840.1.2.3.4.5.6.7.8.9" codeSystemName="Name des Codesystems"/>    <effectiveTime>       <low value="20081224082015+0100"/>      <high value="20081225113000+0100"/>    </effectiveTime>    <performer typeCode="PRF">       <assignedEntity> : </assignedEntity>    </performer>  </serviceEvent></documentationOf>
Beispiel	Strukturbeispiel Hämatologie <documentationOf typeCode="DOC">   <serviceEvent>     <code code="300" codeSystem="1.2.40.0.34.5.11" codeSystemName="ELGA_LaborparameterErgaenzung" displayName="Hämatologie"/>    <effectiveTime>       <low value="20121201061325+0100"/>      <high value="20121201161500+0100"/>    </effectiveTime>  </serviceEvent></documentationOf>
Item DT Kard Konf Beschreibung Label hl7:documentationOf Komponente für die Gesundheitsdienstleistung. (Hea...ent)   elgagab-data​element-145  Gesundheitsdienstleistung  Datensatz @typeCode cs 0 … 1 F DOC hl7:serviceEvent 1 … 1 M Gesundheitsdienstleistung. (Hea...ent) @classCode cs 0 … 1 F ACT @moodCode cs 0 … 1 F EVN hl7:code CE 1 … 1 R Code der Gesundheitsdienstleistung. Zugelassene nullFlavor: UNK Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen. (Hea...ent) hl7:effectiveTime IVL_TS 1 … 1 M Zeitraum der Gesundheitsdienstleistung. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (Hea...ent) hl7:low TS 1 … 1 M (Hea...ent) hl7:high TS 1 … 1 M (Hea...ent) hl7:performer 0 … * Durchführende Entität(en) der Gesundheitsdienstleistung. (Hea...ent) hl7:assignedEntity 1 … 1 M (Hea...ent) Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC) hl7:id II 1 … * R Mindestens eine Id der validierenden Person. Zugelassene nullFlavor: UNK (Hea...ent) hl7:addr AD 0 … 1 Ein Adress-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...ent) hl7:telecom TEL.AT 0 … * Mindestens ein Telecom-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...ent) hl7:assigned​Person 1 … 1 M Persondendaten der validierenden Person. (Hea...ent) Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name der Person 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...ent) hl7:represented​Organization 0 … 1 Organistationsdaten der validierenden Person. (Hea...ent) Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...ent) hl7:name ON 1 … 1 M (Hea...ent) hl7:telecom TEL.AT 0 … * (Hea...ent) hl7:addr AD 0 … 1 (Hea...ent)

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.1.2 Spezielle Vorgaben

Für den Laborbefund sind alle im Befund enthaltenen Befundarten als serviceEvent mit der entsprechenden Codierung anzuführen. Als Codierung wird das ELGA Value Set „ELGA_ServiceEventsLabor“ vorgegeben. Die Auswahl der zu codierenden Events erfolgt durch die im Rahmen des Laborauftrags enthaltenen Parameter. Diese unterliegen über das hierarchische Value Set „ELGA_Laborparameter“ einer Hierarchie durch die sich die auf der obersten Ebene zu codierenden serviceEvent-Elemente ergeben. Die nachfolgende Abbildung zeigt einen Auszug der Liste. Enthält nun z.B. der Laborauftrag den Parameter 26515-7 „Thrombozyten“ so ist gem. Hierarchie auf der obersten Ebene der Eintrag 300 „Hämatologie“ zu finden, welcher als serviceEvent codiert wird.

Abbildung 2: Auszug aus der Liste "ELGA_LaborParameter"

Der Mikrobiologiebefund ist in den ServiceEvents zusätzlich mit dem Code 18725-2 (Microbiology studies) anzugeben.

Ein Befund kann als Mikrobiologiebefund angegeben werden, wenn eine oder mehrere der Sektionen Bakteriologie, Kultureller Erregernachweis, Antibiogramm, Minimale Hemmkonzentration oder Molekularer Erregernachweis enthalten sind.

Die Angabe eines zeitlichen Erbringungsintervalls effectiveTime mit einer Start- low und Endzeit high ist verpflichtend. Optional kann der Erbringer der Leistung angegeben werden.

Feld	Element
Service Event codiert	documentationOf/serviceEvent/code
Intervall der Erbringung	documentationOf/serviceEvent/effectiveTime
Leistungserbringende Stellen	documentationOf/serviceEvent/performer

Tabelle 3: Überblick Elemente ServiceEvent

1.6.1.3 Spezifikation

Id	1.2.40.0.34.11.20010 ref elgabbr-	Gültigkeit	2011‑12‑19
Status	Aktiv	Versions-Label
Name	HeaderServiceEvent	Bezeichnung	HeaderServiceEvent
Beschreibung 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.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz elgagab-data​element-145  Gesundheitsdienstleistung  Datensatz
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.40.0.34.11.90003 Inklusion AssignedEntityElements DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20010 (2017‑07‑21 11:18:58) ref elgabbr- Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19) ref elgabbr-
Beispiel	Strukturbeispiel Koloskopie <documentationOf typeCode="DOC">   <serviceEvent>     <code code="KOL" displayName="Koloskopie" codeSystem="2.16.840.1.2.3.4.5.6.7.8.9" codeSystemName="Name des Codesystems"/>    <effectiveTime>       <low value="20081224082015+0100"/>      <high value="20081225113000+0100"/>    </effectiveTime>    <performer typeCode="PRF">       <assignedEntity> : </assignedEntity>    </performer>  </serviceEvent></documentationOf>
Beispiel	Strukturbeispiel Hämatologie <documentationOf typeCode="DOC">   <serviceEvent>     <code code="300" codeSystem="1.2.40.0.34.5.11" codeSystemName="ELGA_LaborparameterErgaenzung" displayName="Hämatologie"/>    <effectiveTime>       <low value="20121201061325+0100"/>      <high value="20121201161500+0100"/>    </effectiveTime>  </serviceEvent></documentationOf>
Item DT Kard Konf Beschreibung Label hl7:documentationOf Komponente für die Gesundheitsdienstleistung. (Hea...ent)   elgagab-data​element-145  Gesundheitsdienstleistung  Datensatz @typeCode cs 0 … 1 F DOC hl7:serviceEvent 1 … 1 M Gesundheitsdienstleistung. (Hea...ent) @classCode cs 0 … 1 F ACT @moodCode cs 0 … 1 F EVN hl7:code CE 1 … 1 R Code der Gesundheitsdienstleistung. Zugelassene nullFlavor: UNK Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen. (Hea...ent) hl7:effectiveTime IVL_TS 1 … 1 M Zeitraum der Gesundheitsdienstleistung. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (Hea...ent) hl7:low TS 1 … 1 M (Hea...ent) hl7:high TS 1 … 1 M (Hea...ent) hl7:performer 0 … * Durchführende Entität(en) der Gesundheitsdienstleistung. (Hea...ent) hl7:assignedEntity 1 … 1 M (Hea...ent) Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC) hl7:id II 1 … * R Mindestens eine Id der validierenden Person. Zugelassene nullFlavor: UNK (Hea...ent) hl7:addr AD 0 … 1 Ein Adress-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...ent) hl7:telecom TEL.AT 0 … * Mindestens ein Telecom-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...ent) hl7:assigned​Person 1 … 1 M Persondendaten der validierenden Person. (Hea...ent) Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name der Person 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...ent) hl7:represented​Organization 0 … 1 Organistationsdaten der validierenden Person. (Hea...ent) Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...ent) hl7:name ON 1 … 1 M (Hea...ent) hl7:telecom TEL.AT 0 … * (Hea...ent) hl7:addr AD 0 … 1 (Hea...ent)

1.6.1.3.1 effectiveTime

Der Startzeitpunkt ist - sofern vorhanden - jenes Datum und jener Zeitpunkt, an dem das analysierende Labor die Anforderung vom Zuweiser in der Labor EDV erfasst hat. Anderenfalls sind Datum und Uhrzeit des Starts des Auftrags in der Labor EDV anzugeben. Die Endzeit ist die Abschlusszeit des Auftrags, welche in der Regel mit der medizinischen Freigabe des Auftrags ident ist.

1.6.2 Durchführende Labors („ClinicalDocument/documentationOf/serviceEvent/performer“)

Optional können die, die Laboruntersuchungen durchführenden, Labors dokumentiert werden. Nach [3] können diese an mehreren Stellen des Befundes angegeben werden. Wurde der Befund nur von einem Labor erstellt so ist dieses im Rahmen von ClinicalDocument/documentationOf/serviceEvent/performer anzugeben. Sind mehrere Labors an der Erstellung beteiligt so MUSS das Labor im structuredBody entweder auf entry-Ebene oder im Rahmen eines organizer oder direkt bei der Einzeluntersuchung (observation) angegeben werden.

Wird dieser Eintrag angeführt, so ist das Labor mit seinem Leiter angeführt. Gemäß [3] sind time, sowie name, telecom und addr VERPFLICHTEND anzugeben. Im Element time wird der Zeitpunkt oder die Zeitdauer angegeben, in der das Labor mit der Ausführung der Dienstleistung beschäftigt war. Weiters entspricht die Definition dem Template mit templateId „1.3.6.1.4.1.19376.1.3.3.1.7“, welche anzuführen ist.

1.6.2.1 Spezifikation

Id	1.3.6.1.4.1.19376.1.3.3.1.7 ref elgabbr-	Gültigkeit	2014‑05‑26
Status	Aktiv	Versions-Label
Name	LaboratoryPerformer	Bezeichnung	Laboratory Performer
Beschreibung
Kontext	Geschwisterknoten des Template-Element mit Id 1.3.6.1.4.1.19376.1.3.3.1.7
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 2 Templates Benutzt als Name Version 1.2.40.0.34.11.90001 Inklusion PersonElements DYNAMIC 1.2.40.0.34.11.90002 Inklusion OrganizationElements DYNAMIC
Beziehung	Version: Template 1.3.6.1.4.1.19376.1.3.3.1.7 Laboratory Performer (2014‑05‑26) ref elgabbr-
Beispiel	Strukturbeispiel <documentationOf typeCode="DOC">   <serviceEvent>     <code code="300" codeSystem="1.2.40.0.34.5.11" codeSystemName="ELGA_LaborparameterErgaenzung" displayName="Hämatologie"/>    <effectiveTime>       <low value="20121201061325+0100"/>      <high value="20121201161500+0100"/>    </effectiveTime>    <performer typeCode="PRF">       <templateId root="1.3.6.1.4.1.19376.1.3.3.1.7"/>      <time>         <low value="20121201061325+0100"/>        <high value="20121201161500+0100"/>      </time>      <assignedEntity>         <id nullFlavor="NA"/>        <addr>           <streetAddressLine>Laborplatz 1 </streetAddressLine>          <city>Wien</city>          <postalCode>1210</postalCode>        </addr>        <telecom use="WP" value="tel:+43.1.12345678"/>        <assignedPerson>           <name>             <prefix qualifier="PR">OA</prefix>            <prefix qualifier="AC">Dr.</prefix>            <given>Larissa</given>            <family>Laborleiter</family>          </name>        </assignedPerson>        <representedOrganization>           <id root="1.2.40.0.34.3.1.999"/>          <name>Zentrallabor</name>          <telecom use="WP" value="tel:+43.1.12345678"/>          <addr>             <streetAddressLine>Labplatz 1</streetAddressLine>            <city>Wien</city>            <postalCode>1200</postalCode>          </addr>        </representedOrganization>      </assignedEntity>    </performer>  </serviceEvent></documentationOf>
Item DT Kard Konf Beschreibung Label @typeCode 1 … 1 R   CONF Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.43 ELGA_ServiceEventPerformer (DYNAMIC) hl7:templateId 1 … 1 M (Lab...mer) @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.7 hl7:time IVL_TS 0 … 1 R Zeitraum, in der der Performer diese Gesundheitsdienstleistung ausgeführt hat (Lab...mer) hl7:assignedEntity 1 … 1 M (Lab...mer) hl7:id II 1 … 1 R (Lab...mer) hl7:code CE 0 … 1 R (Lab...mer)   Beispiel <code code="E" codeSystem="2.16.840.1.113883.2.16.1.4.9" codeSystemName="HL7.at.Laborkennzeichnung" displayName="EXTERN"/> hl7:addr AD 1 … 1 M (Lab...mer) hl7:telecom TEL.AT 1 … * M (Lab...mer) Auswahl 1 …  Angabe von Personenname oder Organisationsname ist verpflichtend. Elemente in der Auswahl: hl7:assigned​Person hl7:represented​Organization hl7:assigned​Person  … 1 (Lab...mer) Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name der Person 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. (Lab...mer) hl7:represented​Organization  … 1 (Lab...mer) Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Lab...mer) hl7:name ON 1 … 1 M (Lab...mer) hl7:telecom TEL.AT 0 … * (Lab...mer) hl7:addr AD 0 … 1 (Lab...mer)

1.7 Informationen zum Patientenkontakt

1.7.1 Encounter (“componentOf/encompassingEncounter”)

Gemäß [3] ist die Angabe von Informationen zum Patientenkontakt im Rahmen des componentOf/encompassingEncounter-Elementes möglich. Da im Regelfall bei einer Laborleistung keine dementsprechende zu dokumentierende Leistung existiert, ist die Angabe dieser Information im österreichischen Laborbefund optional.