Vorlage:Elga-cdalab-2.06.3:CDA Header

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

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

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 4: Überblick administrative Daten (Header)

1.1 Dokumentenstruktur

1.1.1 Elemente ohne spezielle 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.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

Id1.2.40.0.34.11.90008
ref
elgabbr-
Gültigkeit2016‑07‑21
Andere Versionen mit dieser Id:
  • Kblank.png CDeffectiveTime vom 2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDeffectiveTimeBezeichnungCD 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.

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-8Kyellow.png Erstellungsdatum Kyellow.png Datensatz
BeziehungVersion: 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"/>
ItemDTKardKonfBeschreibungLabel
hl7:effectiveTime
TS.AT.TZ1 … 1M
Erstellungsdatum des Dokuments.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(CDe...ime)
 
Target.png
elgagab-data​element-8Kyellow.png Erstellungsdatum Kyellow.png Datensatz

1.1.8 Vertraulichkeitscode („confidentialityCode“)

1.1.8.1 Spezifikation

Id1.2.40.0.34.11.90009
ref
elgabbr-
Gültigkeit2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDconfidentialityCodeBezeichnungCD 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.

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-266Kyellow.png Vertraulichkeitscode Kyellow.png Datensatz
BeziehungVersion: 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"/>
ItemDTKardKonfBeschreibungLabel
hl7:confidentialityCode
CE1 … 1M(CDc...ode)
 
Target.png
elgagab-data​element-266Kyellow.png Vertraulichkeitscode Kyellow.png Datensatz
Treetree.png@code
CONF1 … 1FN
Treetree.png@codeSystem
1 … 1F2.16.840.1.113883.5.25 (BasicConfidentialityKind)
Treetree.png@displayName
1 … 1Fnormal

1.1.9 Sprachcode des Dokuments („languageCode“)

1.1.9.1 Spezifikation

Id1.2.40.0.34.11.90010
ref
elgabbr-
Gültigkeit2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDlanguageCodeBezeichnungCD 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).

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-265Kyellow.png Sprachcode Kyellow.png Datensatz
BeziehungVersion: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07)
ref
elgabbr-
Beispiel
Beispiel
<languageCode code="de-AT"/>
ItemDTKardKonfBeschreibungLabel
hl7:language​Code
CS.LANG1 … 1MSprachcode des Dokuments.(CDl...ode)
 
Target.png
elgagab-data​element-265Kyellow.png Sprachcode Kyellow.png Datensatz
Treetree.png@code
CONF1 … 1Fde-AT


1.1.10 Elemente mit spezielle Vorgaben

1.1.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.1.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.1.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.1.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. Im Falle eines reinen mikrobiologischen Befundes wird der LOINC Code 18725-2 (Microbio-logy studies) zur Codierung der Dokumentenklasse verwendet.

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.

1.1.10.3 Strukturbeispiel

<ClinicalDocumentxmlns="urn:hl7-org:v3">
	:
	<!-- —Dokumentenklasse für den allgemeinen Laborbefund (welcher event. auch
    mikrobiologische Ergebnisse enthalten kann) -->
<code code="11502-2" codeSystem="2.16.840.1.113883.6.1"
 codeSystemName="LOINC"
 displayName="Laboratory report"/>
	
	<!-- Titel des Dokuments -->
	<title>Allgemeiner Laborbefund</title>
	
<!--  ODER  -->:

 <!—Dokumentenklasse für den mikrobiologischen Befund -->
<code code="18725-2" codeSystem="2.16.840.1.113883.6.1"
 codeSystemName="LOINC"
 displayName="Microbiology studies"/>
	
	<!-- Titel des Dokuments -->
	<title></title>

</ClinicalDocument>
1.1.10.3.1 Spezifikation
Element/Attribut DT Kard Konf Beschreibung
code CE
CWE
1..1 M Code des Dokuments
@code cs 1..1 M Fester Wert für den allgemeinen Laborbefund: 11502-2
ODER
Fester Wert für den mikrobiologischen Befund:
18725-2
@displayName st 0..1 R2 Fester Wert für den allgemeinen Laborbefund: Laboratory report
ODER
Fester Wert für den mikrobiologischen Befund:
Microbiology studies
@codeSystem uid 1..1 M Fester Wert: 2.16.840.1.113883.6.1
@codeSystemName ADXP 0..1 R2 Fester Wert: LOINC

1.1.10.4 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 Do-kumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title. Der Sinn der Be-nennung ist jedoch gemäß der Dokumentenklassen zu wählen. Im allgemeinen Fall wird die Bezeichnung „Laborbefund“ verwendet bzw. die Bezeichnung „Mikrobiologischer Befund“ für mikrobiologische Befunde.

1.1.10.4.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.1.10.4.2 Spezifikation
Element/Attribut DT Kard Konf Beschreibung
title ST 1..1 M Dokumententitel
Der Sinn der Benennung MUSS mit der Dokumentenklasse übereinstimmen.

1.1.10.5 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.2 Teilnehmende Parteien

1.2.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.2.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.2.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.2.3.1 Spezifikation

Id1.2.40.0.34.11.20001
ref
elgabbr-
Gültigkeit2017‑07‑20
Andere Versionen mit dieser Id:
  • Kblank.png Header​Record​Target vom 2018‑10‑18 14:23:51
  • Kblank.png Header​Record​Target vom 2017‑03‑27
  • Kblank.png Header​Record​Target vom 2013‑10‑08
  • Kblank.png Header​Record​Target vom 2013‑02‑10
  • Kblank.png Header​Record​Target vom 2011‑12‑19
StatusKyellow.png EntwurfVersions-Label
NameHeader​Record​TargetBezeichnungHeader​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.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-9Kyellow.png Patient Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90017InklusionKyellow.png Language CommunicationDYNAMIC
BeziehungVersion: 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>
ItemDTKardKonfBeschreibungLabel
hl7:recordTarget
Komponente für die Patientendaten.
(Hea...get)
 
Target.png
elgagab-data​element-9Kyellow.png Patient Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FRCT
Treetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treetree.pnghl7:patientRole
1 … 1RPatientendaten.(Hea...get)
Treeblank.pngTreetree.png@classCode
cs0 … 1FPAT
 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 assertrole error 
 teststring-length(hl7:id[1]/@root)>0 
 Meldung patientRole id[1] MUSS als lokale Patienten ID vom System vorhanden sein 
 Schematron assertrole error 
 testhl7: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 
Treeblank.pngTreetree.pnghl7:id
II2 … *Rid[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-->
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Adresse des Patienten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:streetAddressLine
0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:streetName
0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:houseNumber
0 … 1(Hea...get)
 Schematron assertrole error 
 testhl7:streetAddressLine or (hl7:streetName and hl7:houseNumber) 
 MeldungGranularitätsstufen Adresse beachten: streetAddressLine oder streetName+houseNumber 
Treeblank.pngTreeblank.pngTreetree.pnghl7:postalCode
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:city
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:state
0 … 1C(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:country
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:additionalLocator
0 … 1(Hea...get)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten des Patienten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...get)
Treeblank.pngTreetree.pnghl7:patient
0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M
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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
0 … *(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
1 … *M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
1 … *M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
0 … *(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE1 … 1R

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)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.​DATE.​MIN1 … 1R
Geburtsdatum des Patienten.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
Zugelassene nullFlavor: UNK
(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:marital​Status​Code
CE0 … 1Codierung 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)
Treeblank.pngTreeblank.pngTreetree.pnghl7:religious​Affiliation​Code
CE0 … 1Codierung 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)
Treeblank.pngTreeblank.pngTreetree.pnghl7:raceCode
NP
Rasse des Patienten
Darf nicht verwendet werden!
(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:ethnic​Group​Code
NPEthnische Zugehörigkeit des Patienten.
Darf nicht verwendet werden!
(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:guardian
0 … *Gesetzlicher Vertreter: Erwachsenenvertreter, Vormund, Obsorgeberechtigter(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1
Die Adresse des gesetzlichen Vertreters oder der Organisation.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Beliebig viele Kontaktdatendes gesetzlichen Vertreters oder der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...get)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:guardian​Person
  • hl7:guardian​Organization
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
 … 1Name des des gesetzlichen Vertreters (Person). (Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1MName der Person. (Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Organization
 … 1Name des des gesetzlichen Vertreters (Organisation). (Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation.(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthplace
0 … 1Geburtsort des Patienten.(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:place
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1M

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)
Treeblank.pngTreeblank.pngTreetree.pnghl7:language​Communication
0 … *
Komponente zur Angabe der Sprachfähigkeiten des Patienten.
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Code
CS0 … 1Sprache, 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:modeCode
CE0 … 1Ausdrucksform 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:proficiency​Level​Code
CE0 … 1Grad 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:preference​Ind
BL0 … 1Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.(Hea...get)


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

1.2.4.1 Spezifikation

Id1.2.40.0.34.11.20003
ref
elgabbr-
Gültigkeit2013‑02‑10
Andere Versionen mit dieser Id:
  • Kblank.png HeaderDataEnterer vom 2011‑12‑19
StatusKyellow.png EntwurfVersions-Label
NameHeaderDataEntererBezeichnungHeaderDataEnterer
Beschreibung

Die das Dokument „schreibende“ Person (z.B. Schreibkraft, Stationsschwester, …).
Das Element "DataEnterer" ist bei automatisch erstellten Dokumenten nicht notwendig.

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-65Kyellow.png Schreibkraft Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90003InklusionKgreen.png AssignedEntityElementsDYNAMIC
BeziehungVersion: 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>
ItemDTKardKonfBeschreibungLabel
hl7:dataEnterer
Person der Dateneingabe.(Hea...rer)
 
Target.png
elgagab-data​element-65Kyellow.png Schreibkraft Kyellow.png Datensatz
Treetree.pnghl7:time
TS.AT.TZ0 … 1
Der Zeitpunkt an dem das Dokument geschrieben wurde.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(Hea...rer)
Treetree.pnghl7:assignedEntity
1 … 1R
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)
Treeblank.pngTreetree.pnghl7:id
II1 … *R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1MPersondendaten der validierenden Person.(Hea...rer)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

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)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1Organistationsdaten der validierenden Person.(Hea...rer)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...rer)

1.2.5 Verwahrer des Dokuments („custodian“)

Auszug aus dem R-MIM:

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

1.2.5.1 Spezifikation

Id1.2.40.0.34.11.20004
ref
elgabbr-
Gültigkeit2015‑05‑28
Andere Versionen mit dieser Id:
  • Kblank.png HeaderCustodian vom 2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeaderCustodianBezeichnungHeaderCustodian
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.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-73Kyellow.png Verwahrer Kyellow.png Datensatz
BeziehungVersion: 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>
ItemDTKardKonfBeschreibungLabel
hl7:custodian
Verwahrer des Dokuments.(Hea...ian)
 
Target.png
elgagab-data​element-73Kyellow.png Verwahrer Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FCST
Treetree.pnghl7:assignedCustodian
1 … 1M(Hea...ian)
Treeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1R
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)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
1 … 1M Name des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen.
(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … 1Kontaktdaten des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1M Adresse des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...ian)


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

Auszug aus dem R-MIM:

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

1.2.6.1 Spezifikation

Id1.2.40.0.34.11.20005
ref
elgabbr-
Gültigkeit2011‑12‑19
StatusKyellow.png EntwurfVersions-Label
NameHeader​Information​RecipientBezeichnungHeader​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.

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-259Kyellow.png Empfänger Kyellow.png Datensatz
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
BeziehungVersion: 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.-->
ItemDTKardKonfBeschreibungLabel
hl7:information​Recipient
Beabsichtiger Empfänger des Dokuments.(Hea...ent)
 
Target.png
elgagab-data​element-259Kyellow.png Empfänger Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 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)
Treetree.pnghl7:intended​Recipient
1 … 1M(Hea...ent)
Treeblank.pngTreetree.pnghl7:id
II1 … *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"/>
Treeblank.pngTreetree.pnghl7:information​Recipient
1 … 1M

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)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

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)
Treeblank.pngTreetree.pnghl7: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)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ent)


1.2.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.2.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.2.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.2.9.1 Spezifikation

Id1.2.40.0.34.11.20007
ref
elgabbr-
Gültigkeit2011‑12‑19
Andere Versionen mit dieser Id:
  • Kblank.png HeaderAuthenticator vom 2018‑10‑18 14:33:54
StatusKyellow.png EntwurfVersions-Label
NameHeaderAuthenticatorBezeichnungHeaderAuthenticator
Beschreibung
Dokumente können neben dem verpflichtenden legalAuthenticator („rechtlichen Unterzeichner“, Hauptunterzeichner) auch beliebig viele weitere Mitunterzeichner beinhalten.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-86Kyellow.png Weitere Unterzeichner Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90003InklusionKgreen.png AssignedEntityElementsDYNAMIC
BeziehungVersion: 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>
ItemDTKardKonfBeschreibungLabel
hl7:authenticator
Weitere Unterzeichner.(Hea...tor)
 
Target.png
elgagab-data​element-86Kyellow.png Weitere Unterzeichner Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FAUTHEN
Treetree.pnghl7:time
TS.​DATE.​MIN1 … 1R
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)
Treetree.pnghl7:signatureCode
CS1 … 1M(Hea...tor)
Treeblank.pngTreetree.png@code
CONF1 … 1FS
Treetree.pnghl7:assignedEntity
1 … 1MPersonendaten 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)
Treeblank.pngTreetree.pnghl7:id
II1 … *R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1MPersondendaten der validierenden Person.(Hea...tor)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

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)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1Organistationsdaten der validierenden Person.(Hea...tor)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...tor)


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