elga-cdapsb-2.06.2:Administrative Daten (CDA Header)

1 Administrative Daten (CDA Header)

Dieses Kapitel basiert auf dem entsprechenden Kapitel im „Allgemeinen Implementierungsleitfaden“ (HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [OID Root 1.2.40.0.34.7.1]) und beschreibt die darüber hinausgehenden Spezifikationen zum Thema „Pflegesituationsbericht“.

1.1 Dokumentenstruktur

1.1.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:
Die Elemente erfordern keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.

Auszug aus dem Allgemeinen Implementierungsleitfaden

1.1.2 XML Metainformationen

1.1.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.1.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.1.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.1.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.1.4.1 Strukturbeispiel

<realmCode code="AT'"/>

1.1.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.1.5 Dokumentformat („typeId“)

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

1.1.5.1 Strukturbeispiel

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

1.1.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.1.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.1.6.1 Strukturbeispiel

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

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

1.1.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.1.8 Vertraulichkeitscode („confidentialityCode“)

1.1.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.1.9 Sprachcode des Dokuments („languageCode“)

1.1.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.1.10 Elemente mit speziellen Vorgaben

1.1.10.1 ELGA Implementierungsleitfaden-Kennzeichnung („templateId“)

Mit Angabe dieses Elements wird ausgesagt, dass das vorliegende CDA-Dokument zu diesem Implementierungsleitfaden konform ist. Ein Dokument, welches dem vorliegenden Implementierungsleitfaden folgt, muss auch dem übergeordneten „Allgemeinen Implementierungsleitfaden“ folgen.

1.1.10.1.1 Spezielle Vorgaben für Pflegesituationsberichte

Die templateId-Elemente für diesen Implementierungsleitfaden sind anzugeben.

1.1.10.1.2 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
   :
  <!-- ELGA CDA Dokumente -->
  <templateId root="1.2.40.0.34.11.1"/>

  <!-- ELGA CDA Pflegesituationsbericht -->
  <templateId root="1.2.40.0.34.11.12"/>

  <!--
        In Abhängigkeit von der ELGA Interoperabilitätsstufe (EIS)
  -->

  <!-- EIS „Basic” -->
  <templateId root="1.2.40.0.34.11.12.0.1"/>
     ... oder ...
  <!-- EIS „Enhanced” -->
  <templateId root="1.2.40.0.34.11.12.0.2"/>
     ... oder ...
  <!-- EIS „Full support” -->
  <templateId root="1.2.40.0.34.11.12.0.3"/>
   :
</ClinicalDocument>

1.1.10.1.3 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 Pflegesituationsbericht Fester Wert: @root = 1.2.40.0.34.11.12
--- 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 Pflegesituationsbericht Fester Wert @root = 1.2.40.0.34.11.12.0.1
--- oder ---
Im Falle von EIS „Enhanced“ (Alle Sektionen folgen ausnahmslos den Vorgaben von EIS „Enhanced“ oder höher, aber nicht alle Sektionen folgen den Vorgaben von EIS „Full support“)
templateId	II	1..1	M	ELGA CDA Pflegesituationsbericht Fester Wert @root = 1.2.40.0.34.11.12.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 Pflegesituationsbericht in EIS „Full support“ Fester Wert @root = 1.2.40.0.34.11.12.0.3

1.1.10.2 Titel des Dokuments („title“)

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.

1.1.10.2.1 Spezielle Vorgaben für Pflegesituationsbericht

Der Titel des Dokuments SOLL „Pflegesituationsbericht“ sein.

Da im code-Element nicht zwischen „vorläufigen“ oder „endgültigen“ Fassungen der Dokumente unterschieden wird, KANN der Titel auch die darüber hinausgehende Zusatzinformation, wie „vorläufig“ o.ä. oder Hinweise zur Abteilung / Organisation enthalten. Natürlich müssen auch „vorläufige“ Situationsbericht freigegeben („vidiert“) werden (siehe Weitere Beteiligte).

1.1.10.3 Dokumentenklasse (“code”)

1.1.10.3.1 Spezielle Vorgaben für Pflegesituationsberichte

Alle Pflegesituationsberichte werden unabhängig von Inhalt, ausstellender Abteilung oder Status (z.B. „vorläufig“ oder „abgeschlossen“) mit dem folgenden LOINC Code codiert:

28651-8, Nurse Transfer note

1.1.10.3.2 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
	:
   <code code="28651-8" displayName="Nurse Transfer note" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />
	:
</ClinicalDocument>

1.1.10.3.3 Spezifikation

Element/Attribut		DT	Kard	Konf	Beschreibung
code		CE CWE	1..1	M	Code des Dokuments
	@code	cs	1..1	M	Fester Wert: 28651-8 (aus Value-Set „ELGA_Dokumentklassen“)
	@displayName	st	1..1	M	Fester Wert: Nurse Transfer note
	@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.6.1
	@codeSystemName	st	1..1	M	Fester Wert: LOINC

1.2 Teilnehmende Parteien

1.2.1 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

• Verfasser des Dokuments („author“)
• Personen bei der Dateneingabe („dataEnterer“)
• Verwahrer des Dokuments („custodian“)
• Beabsichtigte Empfänger des Dokuments („informationRecipient“)
• Weitere Unterzeichner („authenticator“)

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

Auszug aus dem Allgemeinen Implementierungsleitfaden

1.2.2 Verfasser des Dokuments („author“)

Auszug aus dem R-MIM:

Abbildung 8: Klassen rund um den Autor.

1.2.2.1 Spezifikation

Id	1.2.40.0.34.11.20002 ref elgabbr-	Gültigkeit	2015‑05‑09 Andere Versionen mit dieser Id: HeaderAuthor vom 2018‑10‑18 14:32:49 HeaderAuthor vom 2013‑02‑10 HeaderAuthor vom 2011‑12‑19
Status	Aktiv	Versions-Label
Name	HeaderAuthor	Bezeichnung	HeaderAuthor
Beschreibung Der Dokumentersteller („author“) ist in der Regel die „das Dokument verfassende Person“ oder ein „datenerstellendes Gerät“. Damit ist diejenige Person oder das Gerät gemeint, welche das Dokument „inhaltlich“ verfasst (z.B.: diktiert). Die das Dokument „schreibende“ Person (z.B. Schreibkraft, Stationsschwester, …) wird in CDA in einem eigenen Element (dataEnterer) abgebildet (siehe „Personen der Dateneingabe („dataEnterer“)“). Es kann auch mehr als ein Dokumentersteller angegeben werden (mehrere author-Elemente).
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-48  Autor  Datensatz
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.40.0.34.11.90001 Inklusion PersonElements DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20002 HeaderAuthor (2015‑05‑09) ref elgabbr-
Beispiel	Strukturbeispiel für eine Person als „author“ <author typeCode="AUT" contextControlCode="OP">   <!-- Funktionscode -->   <functionCode code="OA" displayName="Diensthabender Oberarzt" codeSystem="1.2.40.0.34.99.111.2.1" codeSystemName="Amadeus Spital Funktionen"/>  <!-- Zeitpunkt der Erstellung -->   <time value="20081224082015+0100"/>  <assignedAuthor classCode="ASSIGNED">     <!-- Identifikation des Verfassers des Dokuments -->     <id root="1.2.40.0.34.99.111.1.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>    <!-- Fachrichtung des Verfassers des Dokuments -->     <code code="107" displayName="Fachärztin/Facharzt für Chirurgie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>    <!-- Kontaktdaten des Verfassers des Dokuments -->     <telecom value="tel:+43.1.40400"/>    <telecom value="mailto:herbert.mustermann@organization.at"/>    <assignedPerson classCode="PSN" determinerCode="INSTANCE">       <!-- Name des Verfassers des Dokuments -->       <name>         <prefix qualifier="AC">Univ.-Prof. Dr.</prefix>        <given>Isabella</given>        <family>Stern</family>      </name>    </assignedPerson>    <!-- Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat -->     <representedOrganization>       <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <!-- Name der Organisation -->       <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      <!-- Kontaktdaten der Organisation -->       <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@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>  </assignedAuthor></author>
Beispiel	Strukturbeispiel für datenerstellende Geräte als „author“ <author>   <!-- Zeitpunkt der Erstellung -->   <time value="20081224082015+0100"/>  <assignedAuthor>     <!-- Geräte Identifikation (oder nullFlavor) -->     <id root="86562fe5-b509-4ce9-b976-176fd376e477"/>    <!-- Geräte Beschreibung -->     <assignedAuthoringDevice>       <manufacturerModelName>Good Health System</manufacturerModelName>      <softwareName>Best Health Software Application</softwareName>    </assignedAuthoringDevice>    <representedOrganization>       <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <!-- Name der Organisation -->       <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      <!-- Kontaktdaten der Organisation -->       <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@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>  </assignedAuthor></author>
Item DT Kard Konf Beschreibung Label hl7:author Verfasser des Dokuments. (Hea...hor)   elgagab-data​element-48  Autor  Datensatz @typeCode cs 0 … 1 F AUT @context​Control​Code cs 0 … 1 F OP hl7:functionCode CE 0 … 1 Funktionscode des Verfassers des Dokuments z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, … Eigene Codes und Bezeichnungen können verwendet werden.  Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen. (Hea...hor) hl7:time TS.AT.TZ 1 … 1 R Der Zeitpunkt an dem das Dokument verfasst wurde.Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Zugelassene nullFlavor: UNK (Hea...hor) hl7:assignedAuthor 1 … 1 R Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. (Hea...hor) @classCode cs 0 … 1 F ASSIGNED   Beispiel <assignedAuthor classCode="ASSIGNED">   <id extension="ied8984938" root="1.2.276.0.76.3.1.139.933"/>  <assignedPerson classCode="PSN" determinerCode="INSTANCE">     <!-- ... -->   </assignedPerson></assignedAuthor> hl7:id II 1 … * R Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software.ODERIdentifikation des/der datenerstellenden Gerätes/Software. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. Zugelassene nullFlavor: NI … Person hat keine ID / Gerät/Software hat keine ID UNK … Person hat eine ID, diese ist jedoch unbekannt /Gerät/Software hat eine ID, diese ist jedoch unbekannt (Hea...hor) hl7:code CE 0 … 1 Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung)z.B: „Facharzt/Fachärzting für Gynäkologie“, Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben. Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen. (Hea...hor)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC) hl7:telecom TEL.AT 0 … * Kontaktdaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (Hea...hor) Auswahl 1 … 1 Elemente in der Auswahl: hl7:assigned​Person hl7:assigned​Authoring​Device hl7:assigned​Person  … 1 Personendaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen. (Hea...hor) 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...hor) hl7:assigned​Authoring​Device  … 1 (Hea...hor) @classCode cs 0 … 1 F DEV @determiner​Code cs 0 … 1 F INSTANCE hl7:manufacturer​Model​Name SC 1 … 1 R Hersteller und Modellbezeichnung des datenerstellenden Gerätes. (Hea...hor) hl7:softwareName SC 1 … 1 R Bezeichnung (und ggf Version) der datenerstellenden Software. (Hea...hor) hl7:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. (Hea...hor)   Beispiel <representedOrganization classCode="ORG" determinerCode="INSTANCE">   <id root="1.2.40.0.34.99.111.1.3" extension="1111"/>  <name>     <!-- ... -->   </name></representedOrganization> hl7:id II 1 … * M Die OID der Organisation aus dem GDA-Index. Hinweise: id[1] MUSS aus dem GDA-I stammen, weitere id-Elemente können hinzugefügt werden. Für den Namen von größere Organisationen SOLL auch die Abteilung angegeben werden., z.B.: „Amadeus Spital, Chirurgische Abteilung“ Für die Adresse MUSS mindestens Granularitätsstufe 2 angewendet werden. Grundsätzlich sind die Vorgaben gemäß Kapitel „Organisations-Element“ zu befolgen. (Hea...hor) hl7:name ON 1 … 1 M (Hea...hor) hl7:telecom TEL.AT 0 … * (Hea...hor) hl7:addr AD 0 … 1 (Hea...hor)

1.2.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.2.3 Personen der Dateneingabe („dataEnterer“)

1.2.3.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.2.4 Verwahrer des Dokuments („custodian“)

Auszug aus dem R-MIM:

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

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

Auszug aus dem R-MIM:

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

1.2.5.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.2.6 Weitere Unterzeichner („authenticator“)

1.2.6.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.2.7 Elemente mit speziellen Vorgaben

1.2.7.1 Patient („recordTarget/patientRole“)

Prinzipiell gelten für dieses Element die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.

In dem Fall, dass der Patient nicht zuhause gepflegt werden kann, kann im Pflegesituationsbericht die Angabe einer „Pflege-Adresse“ notwendig werden.

1.2.7.1.1 Spezielle Vorgaben für Pflegesituationsberichte

Die Angabe einer Pflege-Adresse des Patienten hat in Form eines zusätzlichen addr-Elements zu erfolgen, welche mit dem @use Attribut „TMP“ gekennzeichnet ist.

1.2.7.1.2 Strukturbeispiel

<addr use="TMP">
  <streetAddressLine>Musterstraße 13a</streetAddressLine>
  <postalCode>7000</postalCode>
  <city>Eisenstadt</city>
  <country>AUT</country>
</addr>

1.2.7.2 Weitere Beteiligte („participants“)

Im Pflegesituationsbericht ist verpflichtend die Angabe eines „Ansprechpartners“ vorgesehen. Dieser ist mit vollständiger Kontaktadresse inklusive Telefonnummer anzugeben.

Zweck dieser Information ist es, etwaige Anfragen der Dokumentempfänger an den Dokumentersteller zu kanalisieren. Es obliegt der Organisation des Dokumenterstellers, diese Information gemäß ihrer eigenen Richtlinien zu befüllen.

1.2.7.2.1 Spezielle Vorgaben für Pflegesituationsbericht

Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“ mit folgenden Änderungen:

1.2.7.2.1.1 Änderung 1: Konformitäten der Beteiligten geändert

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

Kard	Konf	Art des Beteiligten
1..1	[M]	Rechtlicher Unterzeichner (legalAuthenticator)
1..1	[M]	Fachlicher Ansprechpartner
0..1	[R2]	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

1.3 Dokumentation der Gesundheitsdienstleistung

1.3.1 Service Events („documentationOf/serviceEvent“)

Da die angegebenen Gesundheitsdienstleistungen in die XDS-Metadaten übernommen werden, stellen sie die einzigen (rein) medizinischen Informationen zum Dokument im Dokumentenregister dar. Sie können daher in Folge für Suche und Filterung verwendet werden, und erleichtern mitunter die Navigation in der Krankengeschichte des Patienten.

Verweis auf den 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.4 Dokumentation der Gesundheitsdienstleistung

1.4.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.4.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.4.1.2 Spezielle Vorgaben für Pflegesituationsberichte

Hier kann überblicksartig angegeben werden, welche Art der Gesundheitsdienstleistung im Dokument beschrieben ist. Eine genaue Angabe der einzelnen Leistungen ist an dieser Stelle nicht beabsichtigt.

Es wird der fixe Wert „GDLPUB“ („Gesundheitsdienstleistung Pflege und Betreuung“) aus der Codeliste „ELGA_ServiceEventsSituationsbericht“ angegeben.

Als Zeitangabe MUSS der Zeitraum des Pflege- oder Betreuungsverhältnisses angegeben werden. Wenn das Ende des Pflege- oder Betreuungsverhältnisses zum Zeitpunkt der Erstellung des Dokuments noch nicht bekannt ist, kann „Unbekannt“ angegeben werden.

ACHTUNG: Diese Zeitangaben werden in die Dokument-Metadaten übernommen!

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

• serviceStartTime: Beginn des Pflege- oder Betreuungsverhältnisses
• serviceStopTime: Ende oder Unterbrechung des Pflege- oder Betreuungsverhältnisses

1.4.1.3 Strukturbeispiel

Wenn das Ende des Pflege- oder Betreuungsverhältnisses bekannt ist:

<documentationOf>
  <serviceEvent>
    <code code="GDLPUB"
          displayName="Gesundheitsdienstleistung Pflege und Betreuung"
          codeSystem="1.2.40.0.34.5.21"
          codeSystemName="ELGA_ServiceEventsEntlassbrief" />
    <effectiveTime>
      <low value="20121117000000+0100"/>
      <high value="20150128000000+0100"/>
    </effectiveTime>
  </serviceEvent>
</documentationOf>

Wenn das Ende des Pflege- oder Betreuungsverhältnisses nicht bekannt ist:

<documentationOf>
  <serviceEvent>
    <code code="GDLPUB"
          displayName="Gesundheitsdienstleistung Pflege und Betreuung"
          codeSystem="1.2.40.0.34.5.21"
          codeSystemName="ELGA_ServiceEventsEntlassbrief" />
    <effectiveTime>
      <low value="20121117000000+0100"/>
      <high nullFlavor="UNK"/>
    </effectiveTime>
  </serviceEvent>
</documentationOf>

1.4.1.4 Spezifikation

Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“ mit folgenden Änderungen:

1.4.1.4.1 Änderung 1: serviceEvent-Element Allgemein

Konformität geändert auf [M]. Kardinalität geändert auf 1..1.

Element/Attribut		DT	Kard	Konf	Beschreibung
documentationOf		POCD_MT000040.DocumentationOf	1..1	M	Komponente für die Gesundheitsdienstleistung
	serviceEvent	POCD_MT000040.ServiceEvent	1..1	M	Gesundheitsdienstleistung

1.4.1.4.2 Änderung 2: code

Es wird der fixe Wert „GDLPUB“ („Gesundheitsdienstleistung Pflege und Betreuung“) angegeben.

Element/Attribut		DT	Kard	Konf	Beschreibung
code		CE CWE	1..1	M	Code der Gesundheitsdienstleistung
	@code	cs	1..1	M	Fester Wert: GDLPUB
	@displayName	st	1..1	M	Fester Wert: Gesundheitsdienstleistung Pflege und Betreuung
	@codeSystem	uid	1..1	M	Fester Wert: 1.2.40.0.34.5.21
	@codeSystemName	st	1..1	M	Fester Wert: ELGA_ServiceEventsEntlassbrief

1.4.1.4.3 Änderung 3: effectiveTime

Als Zeitangabe MUSS der Zeitraum des Pflege- oder Betreuungsverhältnisses angegeben werden.

Der Zeitraum des Aufenthalts erstreckt sich vom

Zeitpunkt des Beginns

bis zum

Zeitpunkt des Endes oder der Unterbrechung des Pflege- oder Betreuungsverhältnisses.

Wenn der Zeitraum, der Zeitpunkt des Beginns oder des Endes des Pflege- oder Betreuungsverhältnisses unbekannt ist, kann das durch die Angabe von „Unbekannt“ (nullFlavor="UNK") im High oder Low-Element ausgedrückt werden.

1.4.1.4.4 Änderung 4: performer

Es wird keine durchführende Entität der Gesundheitsdienstleistung angegeben.

Element/Attribut	DT	Kard	Konf	Beschreibung
performer	POCD_MT000040.Performer1	0..0	NP	Durchführende Entität der Gesundheitsdienstleistung

1.5 Bezug zu vorgehenden Dokumenten

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

Id	1.2.40.0.34.11.20011 ref elgabbr-	Gültigkeit	2014‑12‑06 Andere Versionen mit dieser Id: HeaderRelatedDocument vom 2011‑12‑19
Status	Aktiv	Versions-Label
Name	HeaderRelatedDocument	Bezeichnung	HeaderRelatedDocument
Beschreibung	Der Bezug zu vorgehenden Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse, spezifiziert.
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-155  Bezug zu vorgehenden Dokumenten  Datensatz
Beziehung	Version: Template 1.2.40.0.34.11.20011 HeaderRelatedDocument (2014‑12‑06) ref elgabbr-
Beispiel	Strukturbeispiel <relatedDocument typeCode="RPLC">   <parentDocument>     <id root="1.2.40.0.34.99.111.1.1" extension="134F989EAAE3F43B6AD"/>  </parentDocument></relatedDocument>
Item DT Kard Konf Beschreibung Label hl7:relatedDocument Komponente für das vorgehende Dokument. (Hea...ent)   elgagab-data​element-155  Bezug zu vorgehenden Dokumenten  Datensatz @typeCode cs 1 … 1 F RPLC   Art des Bezugs zum Vordokument. hl7:parentDocument 1 … 1 M Vorhergehendes Dokument. (Hea...ent) @classCode cs 0 … 1 F DOCCLIN @moodCode cs 0 … 1 F EVN hl7:id II 1 … 1 M Dokumenten-Id des vorgehenden Dokuments. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. (Hea...ent)

1.7 Einverständniserklärung

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.8 Einverständniserklärung

1.8.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.8.1.1 Spezifikation

Id	1.2.40.0.34.11.20012 ref elgabbr-	Gültigkeit	2011‑12‑19
Status	Aktiv	Versions-Label
Name	HeaderAuthorization	Bezeichnung	HeaderAuthorization
Beschreibung Der Einverständniserklärung ist derzeit ungenutzt. Dieses Element wird daher derzeit nicht angegeben. 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.
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.20012 HeaderAuthorization (2011‑12‑19) ref elgabbr-
Item DT Kard Konf Beschreibung Label hl7:authorization NP Komponente für die Einverständniserklärung. Wird in ELGA nicht verwendet! (Hea...ion)

1.9 Informationen zum Patientenkontakt

1.9.1 Encounter („componentOf/encompassingEncounter“)

Verweis auf den Allgemeinen Leitfaden (mit Anpassungen):
Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“ mit folgenden Änderungen:

Auszug aus dem Allgemeinen Implementierungsleitfaden

1.10 Informationen zum Patientenkontakt

1.10.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.10.1.1 Spezifikation

Id	1.2.40.0.34.11.20013 ref elgabbr-	Gültigkeit	2011‑12‑19
Status	Aktiv	Versions-Label
Name	Header​Encompassing​Encounter	Bezeichnung	Header​Encompassing​Encounter
Beschreibung 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.
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-156  Patientenkontakt  Datensatz
Benutzt	Benutzt 2 Templates Benutzt als Name Version 1.2.40.0.34.11.90003 Inklusion AssignedEntityElements DYNAMIC 1.2.40.0.34.11.90006 Inklusion Encounter Location 1 DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20013 Header​Encompassing​Encounter (2011‑12‑19) ref elgabbr-
Beispiel	Strukturbeispiel <componentOf>   <encompassingEncounter>     <!-- Aufenthaltszahl -->     <id root="1.2.40.0.34.99.111.1.4" extension="Az123456" assigningAuthorityName="Amadeus Spital"/>    <!-- Codierung des Patientenkontakts -->     <code code="IMP" displayName="Inpatient encounter" codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7:ActCode"/>    <!-- Zeitraum des Patientenkontakts -->     <effectiveTime>       <low value="20081224082015+0100"/>      <high value="20081225113000+0100"/>    </effectiveTime>    <!-- Verantwortliche Person für den Patientenkontakt -->     <responsibleParty>       <assignedEntity>         <!-- Identifikation der Verantwortlichen Person für den Patientenkontakt-->         <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>        <!-- Kontaktdaten der Verantwortlichen Person für den Patientenkontakt -->         <telecom use="WP" value="tel:+43.6138.3453446.2222"/>        <!-- Personendaten der Verantwortlichen Person für den Patientenkontakt -->         <assignedPerson>           <!-- Name der Verantwortlichen Person für den Patientenkontakt -->           <name>             <prefix>Univ.-Prof.Dr.</prefix>            <given>Sigrid</given>            <family>Kollmann</family>          </name>        </assignedPerson>      </assignedEntity>    </responsibleParty>    <!-- Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand -->     <location>       <healthCareFacility>         <serviceProviderOrganization>           <!-- ID der Organisation aus dem GDA Index -->           <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>          <!-- Name der Organisation -->           <name>Amadeus Spital - Chirurgische Abteilung</name>          <!-- Kontaktdaten der Organisation -->           <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"/>          <!-- Adresse der Organisation -->           <addr>             <streetName>Mozartgasse</streetName>            <houseNumber>1-7</houseNumber>            <postalCode>5350</postalCode>            <city>St.Wolfgang</city>            <state>Salzburg</state>            <country>AUT</country>          </addr>        </serviceProviderOrganization>      </healthCareFacility>    </location>  </encompassingEncounter></componentOf>
Item DT Kard Konf Beschreibung Label hl7:componentOf Komponente für den Patientenkontakt. (Hea...ter)   elgagab-data​element-156  Patientenkontakt  Datensatz @typeCode cs 0 … 1 F COMP hl7:encompassing​Encounter 1 … 1 R Patientenkontakt. (Hea...ter) @classCode cs 0 … 1 F ENC @moodCode cs 0 … 1 F EVN hl7:id II 0 … 1 Identifikationselement zur Aufnahme der Aufenthaltszahl. (Hea...ter) hl7:code CE 1 … 1 M Codierung des Patientenkontakts. (Hea...ter)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.5 ELGA_ActEncounterCode (DYNAMIC) hl7:effectiveTime IVL_TS 1 … 1 M Zeitraum des Patientenkontakts. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (Hea...ter) hl7:low TS.​DATE.​MIN 1 … 1 R (Hea...ter) hl7:high TS.​DATE.​MIN 0 … 1 (Hea...ter) hl7:responsible​Party 0 … 1 Komponente für die verantwortliche Person. (Hea...ter) hl7:assignedEntity 1 … 1 M Entität der verantwortlichen Person. Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen. (Hea...ter) 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...ter) hl7:addr AD 0 … 1 Ein Adress-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...ter) hl7:telecom TEL.AT 0 … * Mindestens ein Telecom-Element der validierenden Person. Zugelassene nullFlavor: UNK (Hea...ter) hl7:assigned​Person 1 … 1 M Persondendaten der validierenden Person. (Hea...ter) 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...ter) hl7:represented​Organization 0 … 1 Organistationsdaten der validierenden Person. (Hea...ter) 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...ter) hl7:name ON 1 … 1 M (Hea...ter) hl7:telecom TEL.AT 0 … * (Hea...ter) hl7:addr AD 0 … 1 (Hea...ter) Eingefügt 1 … 1 M von 1.2.40.0.34.11.90006 Encounter Location 1 (DYNAMIC) hl7:location 1 … 1 M Komponente Organisation. (Hea...ter) @typeCode cs 0 … 1 F LOC   Beispiel <location typeCode="LOC">   <healthCareFacility classCode="SDLOC">     <!-- ... -->   </healthCareFacility></location> hl7:health​Care​Facility 1 … 1 M (Hea...ter) @classCode cs 0 … 1 F SDLOC   Beispiel <healthCareFacility classCode="SDLOC">   <location classCode="PLC" determinerCode="INSTANCE">     <!-- ... -->   </location>  <serviceProviderOrganization classCode="ORG" determinerCode="INSTANCE">     <!-- ... -->   </serviceProviderOrganization></healthCareFacility> hl7:service​Provider​Organization 1 … 1 M Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand. Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen. (Hea...ter) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE   Beispiel <serviceProviderOrganization classCode="ORG" determinerCode="INSTANCE">   <name/>  <addr>     <!-- ... -->   </addr></serviceProviderOrganization> hl7:id II 1 … * R (Hea...ter) hl7:name ON 1 … 1 M (Hea...ter) hl7:telecom TEL.AT 1 … * M (Hea...ter) hl7:addr AD 1 … 1 M (Hea...ter)

1.10.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.10.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.10.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.10.1.1.4 effectiveTime

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

1.10.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.10.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.

1.10.1.2 Spezielle Vorgaben für den Pflegesituationsbericht

Das Element für den Patientenkontakt erhält im Rahmen der „Pflegesituationsberichte“ derzeit die Bedeutung des „„Pflege- oder Betreuungsverhältnis“.

1.10.1.3 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
	:
  <componentOf>
    <encompassingEncounter>

      <!-- Fallzahl oder Klientennummer -->
      <id root="1.2.40.0.34.3.1.x.x.x"
          extension="123456789012"
          assigningAuthorityName="Fonds Soziales Wien" />

      <!-- Pflege- oder Betreuungsverhältnis -->
      <code code="HH" displayName="Home health" codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7:ActCode" />

      <!-- Zeitraum des Pflege- oder Betreuungsverhältnisses -->
      <effectiveTime>
        <low value="20121224082015+0100"/>
        <high value="20121225113000+0100"/>
      </effectiveTime>

      <!--      Verantwortliche Person (Abteilungsvorstand oder  Pflegebereichsleitung) -->
      <responsibleParty>
        <assignedEntity>
          <id nullFlavor="UNK"/>
          <telecom value="tel:+43.1.40400.4711"/>
          <telecom value="mailto:wolfgang.mustermann@akh-wien.at"/>
          <assignedPerson>
            <name>Dr. Wolfgang Mustermann</name>
          </assignedPerson>
        </assignedEntity>
      </responsibleParty>

      <!-- Pflegende oder betreuende Organisation  -->
      <location>
        <healthCareFacility>
          <serviceProviderOrganization>
            <id root="2.16.40.1.2.3" assigningAuthorityName="GDA Index"/>
            <name>AKH Wien</name>
            <telecom value="tel:+43.1.40400"/>
            <telecom value="fax:+43.1.40400.1212"/>
            <telecom value="http://www.akh-wien.at"/>
            <addr>
              <streetName>Währinger Gürtel</streetName>
              <houseNumber>18-20</houseNumber>
              <postalCode>1090</postalCode>
              <city>Wien</city>
              <state>Wien</state>
              <country>AUT</country>
            </addr>
          </serviceProviderOrganization>
        </healthCareFacility>
      </location>
    </encompassingEncounter>
  </componentOf>
	:
</ClinicalDocument>

1.10.1.4 Spezifikation

Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“ mit folgenden Änderungen:

1.10.1.4.1 Änderung 1: encompassingEncounter-Element Allgemein

Konformität geändert auf [M].

Element/Attribut		DT	Kard	Konf	Beschreibung
componentOf		POCD_MT000040.Component1	1..1	M	Komponente für den Patientenkontakt
	encompassingEncounter	POCD_MT000040.encompassingEncounter	1..1	M	Patientenkontakt

1.10.1.4.2 Änderung 2: id

Konformität geändert auf [R].

Element/Attribut		DT	Kard	Konf	Beschreibung
id		II	1..1	R	Identifikationselement zur Aufnahme der Aufenthaltszahl. Zugelassene nullFlavor: NI … Patient hat keine ID UNK … Patient hat eine ID, diese ist jedoch unbekannt
	@root	uid	1..1	M	OID der Liste der ID(z.B. Fallzahl oder Klientennummer) der Organisation
	@extension	st	1..1	M	ID (Fallzahl oder Klientennummer)
	@assigningAuthorityName	st	0..1	O	Name der Stelle, welche die ID zugewiesen hat<br7>z.B.: „Amadeus Spital“

1.10.1.4.3 Änderung 3: code

Der Implementierungsleitfaden lässt alle Formen der nicht-stationären Pflege und Betreuung zu.

Für die Entlassung aus stationären Aufnahmen SOLL der Leitfaden „Pflegerischer Entlassungsbrief“ verwendet werden.

Element/Attribut		DT	Kard	Konf	Beschreibung
code		CE CWE	1..1	M	Codierung des Patientenkontakts
	@code	cs	1..1	M	Aus Value Set ELGA_ActEncounterCode Mögliche Werte (Beispiele): AMB: ambulatory (Pflege oder Betreuung in Ambulanz) HH: home health (Hausbetreuung, mobile Betreuung, betreutes Wohnen) NONAC: inpatient non-acute (stationäre Pflege, Pflegeheim, Altenheim) SS:short stay (Tagesbetreuung, Tageszentrum)
	@displayName	st	1..1	M
	@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.5.4
	@codeSystemName	st	1..1	M	Fester Wert: HL7:ActCode
	originalText	ED	0..1	O	Textinhalt, der codiert wurde. z.B.: Pflege im Tageszentrum

1.10.1.4.4 Änderung 4: effectiveTime

Als Zeitangabe MUSS der Zeitraum des Pflege- oder Betreuungsverhältnisses angegeben werden.

Der Zeitraum des Aufenthalts erstreckt sich vom

Zeitpunkt des Beginns

bis zum

Zeitpunkt des Endes oder der Unterbrechung des Pflege- oder Betreuungsverhältnisses.

Wenn der Zeitraum, der Zeitpunkt des Beginns oder des Endes des Pflege- oder Betreuungsverhältnisses unbekannt ist, kann das durch die Angabe von „Unbekannt“ (nullFlavor="UNK") im High oder Low-Element ausgedrückt werden.

1.10.1.4.5 Änderung 5: responsibleParty

Konformität geändert auf [R2].

Als verantwortliche Person MUSS die (gesetzliche) pflegerische Leitung der Organisation angegeben werden.

Element/Attribut		DT	Kard	Konf	Beschreibung
responsibleParty		POCD_MT000040.ResponsibleParty	0..1	R2	Komponente für die verantwortliche Person
	assignedEntity	POCD_MT000040.AssignedEntity	1..1	M	Entität der verantwortlichen Person. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“.

1.10.1.4.6 Änderung 6: location

Die „Organisationsdaten des Aufenthalts“ MÜSSEN die berichtende Organisation darstellen.

Granularität des Organisation-Elements der entlassenden Organisation:

• id
  • Konformität geändert auf [R].
  • Mindestanforderung:
    • ID aus dem GDA-Index
      • Zugelassene nullFlavor:
        • NI … Organisation hat keine ID aus dem GDA-Index
        • UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt
    • Empfohlene weitere IDs:
      • DVR, ATU, Bankverbindung (IBAN, SWIFT/BIC)
• telecom
  • Optionalität geändert auf [R2].
  • Mindestanforderung: tel
  • Empfohlen: tel, fax, mailto, http, me-nummer
• addr
  • Optionalität geändert auf [R2].
  • Mindestanforderung: Variante 1 „Nur Textzeile“
  • Empfohlen: Strukturiert gemäß Variante 2 oder 3