1.2.40.0.34.6.0.11.1.24/static-2019-03-26T130859

Id	1.2.40.0.34.6.0.11.1.24 ref at-cda-bbr-	Gültigkeit	2019‑03‑26 13:08:59
Status	Entwurf	Versions-Label	2019
Name	atcdabbr_header_Information_Recipient	Anzeigename	Information Recipient
Beschreibung Der beabsichtigte Empfänger des Dokuments. 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 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.  ↔ Hinweis zum XDS-Mapping:  Dieses Element kann ins XDS-Attribut intendedRecipient gemappt werden (derzeit von ELGA nicht unterstützt).
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt	Benutzt 3 Templates Benutzt als Name Version 1.2.40.0.34.6.0.11.9.12 Inklusion Person Name Compilation G1 M (2019) DYNAMIC 1.2.40.0.34.6.0.11.9.11 Inklusion Person Name Compilation G2 M (2019) DYNAMIC 1.2.40.0.34.6.0.11.9.9 Inklusion Organization Compilation with name (2019) DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.20005 Header​Information​Recipient (2011‑12‑19) ref elgabbr-
Beispiel	Beabsichtigter Empfänger in hoher Granularität angegeben werden <informationRecipient typeCode="PRCP">   <intendedRecipient>     <!-- Identifikation des beabsichtigten Empfängers -->     <id nullFlavor="UNK"/>    <!-- Personendaten des beabsichtigten Empfängers -->     <informationRecipient>       <!-- include template 1.2.40.0.34.6.0.11.9.11 'Person Name Compilation G2 M' (dynamic) 1..1 M -->     </informationRecipient>    <!-- Organisation, der der beabsichtigte Empfänger angehört -->     <receivedOrganization>       <!-- include template 1.2.40.0.34.6.0.11.9.9 'Organization Compilation with name' (dynamic) 0..1 O -->     </receivedOrganization>  </intendedRecipient></informationRecipient>
Beispiel	Beabsichtigter Empfänger ist eine unbekannte Person („An den Hausarzt“) <informationRecipient typeCode="PRCP">   <intendedRecipient>     <!-- Identifikation des beabsichtigten Empfängers -->     <id nullFlavor="UNK"/>    <!-- Personendaten des beabsichtigten Empfängers -->     <informationRecipient>       <!-- include template 1.2.40.0.34.6.0.11.9.12 'Person Name Compilation G1 M' (dynamic) 1..1 M -->     </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>      <!-- Diese Angabe erfolgt in template 1.2.40.0.34.6.0.11.9.12 'Person Name Compilation G1 M' (dynamic) 1..1 M -->     </informationRecipient>  </intendedRecipient>  <!--Eine erneute Angabe der Adresse des Patienten ist nicht erforderlich.--> </informationRecipient>
Item DT Kard Konf Beschreibung Label hl7:information​Recipient Beabsichtiger Empfänger des Dokuments.  (atc...ent) @typeCode cs 0 … 1   Typ des Informationsempfängers. z.B: PRCP „Primärer Empfänger“ Werden mehrere Empfänger angegeben, MUSS der primäre Empfänger über den typeCode definiert werden.  Hinweis: Das ist relevant, wenn Funktionen aus dem gerichteten Befundversand oder für den Briefdruck auf das Dokument angewendet werden. TODO: Assert: Wenn mehrere Empfänger, dann muss immer typeCode gesetzt werden und genau 1 PRCP.   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 (atc...ent) @classCode cs 0 … 1   hl7:id II 1 … * R Identifikation des beabsichtigten Empfängers (Person).  Empfohlene Information für einen Empfänger ist die ID aus dem GDA-Index.  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 (atc...ent) @nullFlavor cs 0 … 1   @assigningAuthorityName st 0 … 1   @extension st 0 … 1   @root uid 1 … 1 R   Beispiel <id nullFlavor="UNK" assigningAuthorityName="GDA Index"/>   Schematron assert role  error     test hl7:id/@nullFlavor='NI' or hl7:id/@nullFlavor='UNK'     Meldung Zugelassene @nullFlavor sind "NI" oder "UNK"   Auswahl 1 … 1 Personendaten des beabsichtigten Empfängers.  Empfehlung: Der Name des Empfängers und die Organisation, der er angehört, sollen in möglichst hoher Granularität angegeben werden. Aufgrund der gängigen Praxis kann als minimale Information für den Empfänger der unstrukturierte Name angegeben werden. Grundsätzlich sind die Vorgaben gemäß Kapitel „Personen-Element“ zu befolgen.  Elemente in der Auswahl: hl7:information​Recipient hl7:information​Recipient hl7:information​Recipient 0 … 1 (atc...ent) Eingefügt von 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Namen-Element (Person) (atc...ent)   elgaimpf-data​element-236  Name  Datensatz e-Impfpass 2019 @use cs 0 … 1   Die genaue Bedeutung des angegebenen Namens, beispielsweise dass der angegebene Personen-Name ein „Künstlername“ ist, z.B. A („Artist“). Zulässige Werte gemäß Value-Set „ELGA_EntityNameUse“. Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“). hl7:information​Recipient 0 … 1 (atc...ent) Eingefügt von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Namen-Element (Person) (atc...ent)   elgaimpf-data​element-172  Name  Datensatz e-Impfpass 2019 elgaimpf-data​element-373  Name  Datensatz e-Impfpass 2019 @use cs 0 … 1   Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“. Zulässige Werte gemäß Value-Set „ELGA_EntityNameUse“. Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“). hl7:prefix ENXP 0 … * Beliebig viele Präfixe zum Namen, z.B. Akademische Titel Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen! (atc...ent) @qualifier cs 0 … 1   Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“. Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier".   CONF Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (DYNAMIC) hl7:family ENXP 1 … * M Mindestens ein Hauptname (Nachname). (atc...ent)   elgaimpf-data​element-241  Nachname  Datensatz e-Impfpass 2019 elgaimpf-data​element-177  Nachname  Datensatz e-Impfpass 2019 @qualifier cs 0 … 1   Bedeutung eines family-Elements, z.B Angabe eines Geburtsnamen mit „BR" für „Birth“. Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier“.   CONF Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (DYNAMIC) hl7:given ENXP 1 … * M Mindestens ein Vorname (atc...ent)   elgaimpf-data​element-176  Vorname  Datensatz e-Impfpass 2019 elgaimpf-data​element-240  Vorname  Datensatz e-Impfpass 2019 @qualifier cs 0 … 1   Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“). Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier“   CONF Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (DYNAMIC) hl7:suffix ENXP 0 … * Beliebig viele Suffixe zum Namen (atc...ent) @qualifier cs 0 … 1   Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“). Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier“.   CONF Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (DYNAMIC) 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.  (atc...ent) Eingefügt 0 … 1 von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … 1 Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (atc...ent) hl7:name ON 0 … 1 M Name der Organisation. Zu dem Namen von größere Organisationen SOLL auch die Abteilung angegeben werden., z.B.: „Amadeus Spital, Chirurgische Abteilung“ Warnung: Wenn isMandatory=true dann muss minimumMultiplicity größer 0 sein. (atc...ent) hl7:telecom TEL.AT 0 … 1 Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atc...ent) @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atc...ent)   Schematron assert role  error     test count(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use]))     Meldung Das Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein.