Allgemeiner Implementierungsleitfaden

Aus HL7 Austria MediaWiki
Version vom 17. Mai 2018, 14:04 Uhr von Lahnsteiner (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche





Inhaltsverzeichnis

1 Informationen über dieses Dokument

1.1 Allgemeines

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen.

Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich und insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.

1.2 Sprachliche Gleichbehandlung

Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer und Frauen in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.

1.3 Verbindlichkeit

Mit der ELGA-Verordnung 2015 (in der Fassung der ELGA-VO-Nov-2015) macht die Bundesministerin für Gesundheit und Frauen die Festlegungen für Inhalt, Struktur, Format und Codierung verbindlich, die in den Implementierungsleitfäden Entlassungsbrief Ärztlich, Entlassungsbrief Pflege, Pflegesituationsbericht, Laborbefunde, Befund bildgebender Diagnostik, e-Medikation sowie XDS Metadaten (jeweils in der Version 2.06) getroffen wurden. Die anzuwendende ELGA-Interoperabilitätsstufen ergeben sich aus §21 Abs.6 ELGA-VO. Die Leitfäden in ihrer jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind von der Gesundheitsministerin auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Dokumente für ELGA wird durch das Gesundheitstelematikgesetz 2012 (GTelG 2012) und darauf basierenden Durchführungsverordnungen durch die Bundesministerin für Gesundheit und Frauen vorgegeben.

Die Verbindlichkeit und die Umsetzungsfrist dieses Leitfadens ist im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.

Neue Hauptversionen der Implementierungsleitfäden KÖNNEN ab dem Tag ihrer Veröffentlichung durch die Bundesministerin für Gesundheit und Frauen (www.gesundheit.gv.at) verwendet werden, spätestens 18 Monate nach ihrer Veröffentlichung MÜSSEN sie verwendet werden. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.

1.4 Zielgruppe

Anwender dieses Dokuments sind Softwareentwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld der ELGA, insbesondere der ELGA-Gesundheitsdaten, betraut sind. Eine weitere Zielgruppe sind alle an der Erstellung von CDA-Dokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen.

1.5 Hinweis auf verwendete Grundlagen

Der vorliegende Leitfaden wurde unter Verwendung der nachstehend beschriebenen Dokumente erstellt. Das Urheberrecht an allen genannten Dokumenten wird im vollen Umfang respektiert.

Dieser Standard beruht auf der Spezifikation "HL7 Clinical Document Architecture, Release 2.0", für die das Copyright © von Health Level Seven International gilt. HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (www.hl7.at). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.

Dieser Leitfaden beruht auf Inhalten des LOINC® (Logical Observation Identifiers Names and Codes, siehe http://loinc.org). Die LOINC-Codes, Tabellen, Panels und Formulare unterliegen dem Copyright © 1995-2014, Regenstrief Institute, Inc. und dem LOINC Committee, sie sind unentgeltlich erhältlich. Lizenzinformationen sind unter http://loinc.org/terms-of-use abrufbar. Weiters werden Inhalte des UCUM® verwendet, UCUM-Codes, Tabellen und UCUM Spezifikationen beruhen auf dem Copyright © 1998-2013 des Regenstrief Institute, Inc. und der Unified Codes for Units of Measures (UCUM) Organization. Lizenzinformationen sind unter http://unitsofmeasure.org/trac/wiki/TermsOfUse abrufbar.

1.6 Danksagung

Die ELGA GmbH weist auf das Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen“ hin, welches vom Verband der Hersteller von IT-Lösungen für das Gesundheitswesen (VHitG) herausgegeben wurde. Einige Ausführungen in dem genannten Dokument wurden in das vorliegende Dokument übernommen. Das Urheberrecht an dem Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen“, wird im vollen Umfang respektiert.


1.7 Revisionsliste

Diese Version ist eine Nebenversion zur Hauptversion 2.06 und ersetzt diese. Die durchgeführten Änderungen ersehen Sie der Revisionsliste.

1.8 Weitere unterstützende Materialien

Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH [1] weitere Dateien und Dokumente zur Unterstützung bereitgestellt: Beispieldokumente, zu verwendende Codes, Vorgaben zur Registrierung von CDA-Dokumenten, das Referenz-Stylesheet zur Darstellung von CDA-Dokumenten, Algorithmen zur Prüfung der Konformität von CDA-Dokumenten etc.


Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an cda@elga.gv.at[2] gesendet werden. Weitere Informationen finden Sie unter http://www.elga.gv.at/CDA.

1.10 Impressum

Medieneigentümer, Herausgeber, Hersteller, Verleger:
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050. Internet: http://www.elga.gv.at. Email: cda@elga.gv.at.
Geschäftsführer: DI Dr. Günter Rauchegger, DI (FH) Dr. Franz Leisch

Redaktion, Projektleitung, Koordination:
Mag. Dr. Stefan Sabutsch, stefan.sabutsch@elga.gv.at

Abbildungen: © ELGA GmbH

Nutzung: Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; www.hl7.at.
Die Nutzung ist zum Zweck der Erstellung medizinischer Dokumente ohne Lizenz- und Nutzungsgebühren ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter www.gesundheit.gv.at und www.elga.gv.at/cda

2 Harmonisierung

Erarbeitung des Implementierungsleitfadens
Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der „Arbeitsgruppe“ in den Jahren 2008-2012, bestehend aus nachfolgend genannten Personen:

Autoren
Kürzel Organisation Person1
Herausgeber, Editor, Projektleiter, ELGA CDA Koordinator
SSA ELGA GmbH Stefan Sabutsch
Autor, Moderator der Arbeitsgruppe (2008-2012)
JBR CodeWerk Software Services and Development GmbH Jürgen Brandstätter
Teilnehmer der Arbeitsgruppe
Organisation Person1
Ärztliche Vertreter
Österreichische Ärztekammer Milan Kornfeind, Robert Hawliczek, Jürgen Schwaiger, Gerhard Holler
Ärztekammer Tirol Ludwig Gruber
Initiative-ELGA Christian Husek, Susanna Michalek
Krankenhausträger
Barmherzige Schwestern Linz Michael Hubich
Oberösterreichische Gesundheits- u. Spitals AG Tilman Königswieser, Josef Hamedinger, Ingrid Wimmer
Steiermärkische Krankenanstalten-ges. m.b.H. Hubert Leitner, Walter Schwab-Ganster, Birgit Fürst, Monika Hoffberger, Daniela Sturm, Brigitte Walzl
Wiener Krankenanstaltenverbund Konrad Hölzl
Salzburger Landeskliniken Reinhard Eberl
Vinzenz Gruppe Krankenhausbeteiligungs- und Management GmbH Stefan Rausch-Schott
Länder und Projekte
Land OÖ / e-Care Projekt Benedikt Aichinger
Projekt “PatientInnenorientierte integrierte Krankenbetreuung“ Eva Friedler, Vera Em (FSW), Robert Em (WISO), Wolfgang Pfleger (FSW)
Sozialversicherung
Allg. Unfallversicherungsanstalt Gudrun Seiwald, Hubert Fankhauser, Michael Szivak
Hauptverband der österreichischen Sozialversicherungsträger Barbara Kaller
Sozialversicherungs-Chipkarten Betriebs- und Errichtungsgesellschaft Martin Asenbaum
Softwarehersteller / Befundprovider
Health Communication Service GmbH Eduard Schebesta, Christoph Unfried
shm sana health management GmbH Jochen Peter Gallob
Systema Human Information Systems GmbH Reinhard Egelkraut
Telekom Austria Peter Uher, Arnold Lengauer
T-Systems Austria GesmbH Karl Holzer
x-tention Christian Ametz
Universitäten / Fachhochschulen
Fachhochschule Technikum Wien Matthias Frohner, Ferenc Gerbovics
Normung
Austrian Standards Institute - Österreichisches Normungsinstitut, Experte der Arbeitsgruppe 250.03 “Qualitätsmanagement in der Pflege” Babette Dörr, Natalie Lottersberger
ELGA GmbH
ELGA GmbH Andrea Klostermann, Carina Seerainer, Oliver Kuttin
Patronanz, Akkordierung, Ergänzungen, Zustimmung
Organisation Person1
Bundesministerium für Gesundheit Clemens Auer
ELGA GmbH Susanne Herbek, Hubert Eisl, Martin Hurch, Oliver Kuttin, Carina Seerainer
Österreichische Ärztekammer Günther Wawrowsky, Reinhold Renner
OÖ Gesundheits- und Spitals AG Johannes Bretbacher
Vinzenz Gruppe Krankenhausbeteiligungs- und Management GmbH Christian Gierlinger
Steiermärkische Krankenanstalten GmbH Jürgen Engelbrecht
NÖ Landesklinikenholding Alexander Schanner, Wolfgang Amenitsch, Thomas Pökl
NÖ Landesheime Eva Friessenbichler, Roland Nefischer
Projekt NÖ Heim-Informationstechnologie Thomas Schubert
Oberösterreichischer Gesundheitsfonds Wolfgang Hiessl
Salzburger Landeskliniken Evelyn Müller
Medizinische Universität Wien Wolfgang Dorda
Wiener Gebietskrankenkasse Wolfgang Dufek, Karl Blauensteiner
Innomed GmbH Gerhard Stimac
Health Communication Service Gmbh Herbert Thomas
Tieto IT Services Johannes Rössler
Bundesfachgruppe Informationstechnologie der Bundeskammer der Architekten und Ingenieurkonsulenten Thomas Hrdinka
Andere ELGA Arbeitsgruppen
Bereich Organisation Person1
Laborbefund Fachhochschule Technikum Wien Stefan Sauermann, Alexander Mense
Befund bildgebende Diagnostik AIMC Martin Weigl
Lindner TAC Andreas Lindner

1 Personen sind ohne Titel angegeben

3 Einleitung

3.1 Ausgangssituation

Die Elektronische Gesundheitsakte (ELGA) ermöglicht den vom ELGA-Gesetz berechtigten Personen, entsprechend ihren Rollen, den Zugriff auf relevante Gesundheitsdaten, die in bedarfsgerecht elektronisch aufbereiteter Form online zur Verfügung gestellt werden.

Die zentrale Anwendung von ELGA ist die Bereitstellung von medizinischen Dokumenten (e Befunde) der ELGA-Teilnehmer, die in vielen unterschiedlichen Informationssystemen der verschiedenen ELGA-Gesundheitsdiensteanbieter erstellt werden. Diese Dokumente sollen nicht nur von Benutzern gelesen, sondern auch wieder in die IT-Systeme integriert und dort weiterverwendet werden können („Semantische Interoperabilität“). Beispielsweise können für den Arzt aus ELGA-Dokumenten automatisch Warnungen, Erinnerungen und Zusammenfassungen generiert und weitere Informationen berechnet sowie kontextbezogen angezeigt werden.

Um dieses Ziel zu erreichen, wird für Dokumente in ELGA der internationale Standard „Clinical Document Architecture, Release 2.0“ (CDA) von HL7 eingesetzt.

Der CDA-Standard wird für die Verwendung in ELGA im Detail ausspezifiziert. Vorgaben für einheitliche Dokumentation und Codierung der Information werden festgelegt und in implementierbaren Leitfäden veröffentlicht.

3.2 Vorgehensweise

Stärker als die Infrastrukturelemente von ELGA sind die Gesundheitsdaten im täglichen medizinischen Geschehen sichtbar. Daher ist in der Ausgestaltung der Gesundheitsdaten die breite Beteiligung der Stakeholder wesentlich, um die praktische Nutzbarkeit und die Akzeptanz durch die ELGA-Benutzer sicherzustellen. Es stehen dabei nicht die technischen, sondern vor allem medizinisch-inhaltliche Aspekte im Vordergrund.

Bis 2009 wurden erste Vorgaben für die Dokumentenklassen Entlassungsbrief (ärztlich), Entlassungsbrief (Pflege), Laborbefund und Radiologiebefund für ELGA erstellt. Diese wurden 2011 aktualisiert. Die Vorgaben wurden als sogenannte „CDA Implementierungsleitfäden“ in interdisziplinären Expertengruppen unter Einbeziehung von Vertretern aller wesentlichen Stakeholder erarbeitet („Harmonisierung“). Bei der Erstellung der Inhalte der Leitfäden wurden daher vor allem medizinische Experten aktiv eingebunden. Die technischen Inhalte wurden großteils von den Redaktionsteams beigetragen.

Ein wesentlicher Schritt auf dem Weg zur Interoperabilität der IT-Systeme im Gesundheitswesen ist die Einigung auf Vorgaben für einheitliche Dokumentation und Codierung der Information. Diese durch die Arbeitsgruppen erreichte „Harmonisierung“ etabliert neue nationale Qualitätsstandards der medizinischen Dokumentation. Die Leitfäden werden über ein reguläres Standardisierungsverfahren ("Ballot") durch die HL7 Anwendergruppe Österreich (HL7 Austria) zu einem nationalen HL7 Standard.

3.2.1 Vorgehensmodell

Der Initialisierungsschritt für neue CDA Implementierungsleitfäden wird im ELGA-Koordinierungsausschuss auf Basis eines Vorschlages der ELGA GmbH gesetzt. Die Planung umfasst die Einladung der Experten und die Beauftragung eines Redaktionsteams zur Erstellung des Leitfadens durch die ELGA GmbH.

Für die Erarbeitung der Vorgaben einer Dokumentenklasse ist jeweils eine Arbeitsgruppe verantwortlich. Jede Arbeitsgruppe wird von einem Redaktionsteam moderiert, das aus einem AG-Leiter und weiteren Redaktionsteammitgliedern besteht. Die zentrale Koordination der Arbeitsgruppen erfolgt durch die ELGA GmbH. Die typische Team-Struktur wird anhand der bisher konstituierten Arbeitsgruppen veranschaulicht:

Abbildung 1: Koordination der Harmonisierungsarbeit in interdisziplinären Arbeitsgruppen.

Die Mitglieder der Arbeitsgruppen werden von den maßgeblichen Stakeholdern des österreichischen Gesundheitswesens gestellt, die an der Erstellung und Verwendung der jeweiligen Dokumentenklassen partizipieren. Folgende Stakeholder-Gruppen werden speziell zur Teilnahme motiviert:

  • Ärzteschaft (Ärztekammer)
  • Krankenhaus-Trägergesellschaften
  • Pflegeorganisationen
  • Befundprovider
  • Hersteller von Krankenhausinformationssystemen bzw. Arztpraxissoftware
  • Bürgerinitiativen
  • Standardisierungsorganisationen

Die Arbeitsgruppen werden von der CDA Koordinationsstelle der ELGA GmbH einberufen. Sie koordiniert die Sitzungen und übernimmt die Kommunikationsaufgaben. Jede Arbeitsgruppe wird durch ein Redaktionsteam unterstützt, welches folgende Tätigkeiten durchzuführen hat:

  • Erheben, Auswerten, Analysieren, Zusammenfassen und Aufarbeiten der eingegangenen Anforderungen
  • Fachliche Vorbereitung der Arbeitsgruppensitzungen
  • Erstellung der Leitfadendokumente und ergänzender Materialien (etwa Beispiel-CDA-Dateien)

Von der Arbeitsgruppe und dem Redaktionsteam wird eine erste Version eines CDA Implementierungsleitfadens vorgelegt, mit der die Umsetzbarkeit getestet werden kann. Diese Leitfadenversion wird dann in einem HL7 „DSTU-Ballot“ abgestimmt (Draft Standard – Trial Implementation). Die Ergebnisse der Testphase laufen bei der ELGA CDA Koordination zusammen, die den Leitfaden freigibt.

Für eine verpflichtende Anwendung eines Leitfadens ist ein „normativer Ballot“ durch die HL7 Austria durchzuführen.

Über die hier geschilderten „internen“ Abstimmungsarbeiten hinaus wird eine Kooperation mit den betroffenen Standardisierungsorganisationen angestrebt, etwa mit dem Österreichischen Normungsinstitut, der HL7 Anwendergruppe Österreich und auch mit anderen nationalen und internationalen Normengremien.

3.2.2 Revision der Leitfäden

Neue und geänderte Anforderungen sowie Verbesserungen können neue Versionen der bestehenden Spezifikationen notwendig machen.

Der CDA-Koordinator evaluiert in regelmäßigen Abständen, ob und welche Änderungen (etwa durch neue medizinische oder gesetzliche Anforderungen) notwendig sind. Aufgrund des Berichtes des CDA-Koordinators empfiehlt die ELGA GmbH die Erstellung von Revisionsversionen der bestehenden Leitfäden. Die geplanten Änderungen sollen mit den maßgeblichen Stakeholdern abgestimmt werden.

Neue Versionen, die „verpflichtende Elemente“ (Sections oder Entries) neu einführen oder entfernen, sind „Hauptversionen“, die jedenfalls über eine Durchführungsverordnung verbindlich gemacht und veröffentlicht werden. Andere Versionen sind „Nebenversionen“. Alle verbindlichen Versionen sind auf http://www.gesundheit.gv.at zu veröffentlichen.

3.3 Hierarchie der Implementierungsleitfäden

Der vorliegende „Allgemeine Implementierungsleitfaden für CDA-Dokumente“ stellt eine grundlegende Implementierungsvorschrift für alle CDA-Dokumente im österreichischen Gesundheitswesen dar. Dieser Vorschrift haben alle über ELGA vermittelten CDA-Dokumente im österreichischen Gesundheitswesen zu folgen.

Darüber hinaus kann auf Basis des vorliegenden allgemeinen Implementierungsleitfadens ein spezieller Implementierungsleitfaden definiert sein (z.B. Entlassungsbrief, Laborbefund, etc.).

Abbildung 2:Zusammenspiel der Implementierungsleitfäden.

Die administrativen Daten im Dokumentheader und grundsätzliche Vorgaben für den medizinischen Inhalt werden vom „Allgemeinen Implementierungsleitfaden“ definiert. Der jeweilige „Spezielle Implementierungsleitfaden“ enthält die Vorgaben für die medizinischen Inhalte und ergänzt gegebenenfalls die Header-Vorgaben.


4 Konzept und Begründung

4.1 Zweck

Das Ziel dieses Dokuments ist die Beschreibung der Struktur von medizinischen Dokumenten der Elektronischen Gesundheitsakte ELGA (entsprechend ELGA-G, BGBl. I Nr. 111/2012). Insbesondere behandelt das Dokument alle Dokumentenklassen-übergreifend gültigen Strukturen.

Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA-Elementen.

Jeder spezielle Implementierungsleitfaden basiert auf diesem vorliegenden Allgemeinen Implementierungsleitfaden. Diese speziellen ELGA CDA Implementierungsleitfäden sind bereits für folgende Dokumentenklassen definiert (Liste kann erweitert werden):

Die Beschreibung des Zusammenhangs von ELGA CDA-Dokumenten und den zur Registrierung von CDA in ELGA notwendigen „XDS-Metadaten“ finden Sie im Dokument

4.2 Grundlagen

Für XML als grundsätzliches Format spricht die Flexibilität nicht nur bei der Länge einzelner darzustellender Texte sondern auch bezüglich der a priori unbegrenzten Möglichkeit, weitere Elemente beliebig tief zu verschachteln.

HL7 bezeichnet eine Gruppe von Standards für den Austausch von Daten zwischen Computersystemen im Gesundheitswesen. HL7 wird als Kommunikationsprotokoll vornehmlich zum Datenaustausch zwischen Abteilungssystemen in Krankenhäusern eingesetzt. Mittlerweile wird HL7 in über 50 Ländern eingesetzt.

Die ursprünglich in den USA von der Organisation „Health Level Seven International“ (HL7) (http://www.hl7.org) entwickelten Spezifikationen sind im Laufe der Zeit zu einem internationalen Standard geworden, auch dank vieler internationaler Benutzergruppen, die seit langem an der Weiterentwicklung von HL7 mitwirken.

Die HL7 Standards in Version 3 sind auf die Kommunikationsbedürfnisse des gesamten Gesundheitswesens abgestimmt. HL7 V3 bietet eine konzeptuelle Grundlage in einem gemeinsamen, umfassenden „Reference Information Model“ (RIM) für alle Teile von HL7 V3.

Dieses RIM ist ANSI- und ISO-Standard (ISO/HL7 21731:2006) und bietet:

  • ein festes semantisches Fundament
  • ausgewählte standardisierte Terminologien, die semantische Interoperabilität ermöglichen
  • die Trennung von Inhalten und Syntax

HL7 Version 3 basiert auf XML und wird für die Übermittlung von Nachrichten genutzt. HL7 stellt außerdem einen Standard zur Strukturierung, zum Inhalt und zum Austausch medizinischer Dokumente, die so genannte Clinical Document Architecture (CDA), zur Verfügung. Dabei steht der Informationsaustausch im gesamten Gesundheitswesen im Vordergrund (also nicht beschränkt auf Krankenhäuser).

Als Grundlage für ELGA-Dokumente wurde der Standard HL7 Clinical Document Architecture, Release 2.0 ausgewählt. Der Standard kann über die HL7 Anwendergruppe Österreich (http://www.hl7.at) bezogen werden.

4.3 Feststellung der Konformität

Ein zu diesem Implementierungsleitfaden konformes CDA-Dokument ist zunächst ein valides CDA Release 2.0 XML-Dokument mit Header und Body. Darüber hinaus erfüllt es alle „Geschäftsregeln“ im weiteren Text dieses Dokuments.

Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten wieder: die Validierung in zwei Schritten. Im ersten Schritt stellt dies die Validierung gegen zugehörige W3C Schemas dar. Das verwendete Schema ist das geringfügig modifizierte, generische, offizielle CDA Release 2.0 Schema (siehe Schema-Prüfung). Darüber hinaus existieren eine Reihe von Schematron Regeln, die für einen zweiten „Validierungsschritt“ genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben, sowie die Einhaltung der Geschäftsregeln (Optionalität, Kardinalität/Multiplizität, Datentypen, Wertebereiche, Abhängigkeiten) sicherstellen (siehe Schematron-Prüfung). Geschäftsregeln für Abschnitte oder Elemente werden auch technisch zu „Templates“ zusammengefasst. Eine XML-Instanz, die kein valides CDA-Dokument ist oder sich nicht gegen das XSD-Schema validieren lässt, oder im Widerspruch zu den angegebenen Geschäftsregeln steht, ist kein gültiges CDA-Dokument im Sinne dieses Implementierungsleitfadens.

4.3.1 CDA Levels

CDA bietet drei verschiedene Varianten, wie Inhalte transportiert werden können; diese Varianten (die so genannten „CDA-Levels“) ermöglichen unterschiedliche Interoperabilität.

„CDA-Level 1“ ist ausschließlich auf die Lesbarkeit durch Menschen ausgelegt. Medizinische Inhalte werden als Text, Bilder oder auch nur als „eingebettetes PDF“ (als unstrukturierter „NonXMLBody“) transportiert.

„CDA-Level 2“ ermöglicht eine Strukturierung der Inhalte nach Abschnitten („Sections“) mit festgelegter Bedeutung, z.B. „Anamnese“, „Diagnosen“. Die Abschnitte sind mit einem vereinbarten Code versehen, der es ermöglicht, dass EDV-Programme diese eindeutig erkennen und als Block verarbeiten können.

„CDA-Level 3“ ist eine Technik zur Anreicherung eines lesbaren Dokuments mit medizinischen Einzelinformationen (z.B. „diastolischer Blutdruck“, „ICD-10 Entlassungs-diagnose“, „Körpergewicht in kg“), die gemäß einer Vereinbarung maschinenlesbar codiert sind und daher automatisch in medizinische Informationssysteme integriert werden können.

Die Vereinbarungen für die Codierung in den CDA-Levels 2 und 3 werden durch Templates definiert und in Implementierungsleitfäden veröffentlicht. Die CDA-Levels können aufeinander aufbauend verwendet werden, ein Dokument kann gleichzeitig Informationen in allen drei CDA-Levels enthalten.

Eine detailliertere Beschreibung der CDA-Levels findet sich in „CDA Level 1 bis 3“.

4.3.2 ELGA Interoperabilitätsstufen

Der zukünftige Nutzen von Dokumenten in ELGA hängt von ihrem Strukturierungsgrad ab: Je einheitlicher und strukturierter die Informationen vorliegen, desto besser können die Daten durch EDV-Systeme verarbeitet und ausgewertet werden. Die so genannten „ELGA Interoperabilitätsstufen“ (EIS) definieren eine bestimmte Menge von Vorgaben aus den CDA Levels 2 und 3. Die Mindeststandards für die Datenstruktur der CDA-Dokumente und die Zeitpunkte für die verbindliche Verwendung werden per bundesministerielle Verordnung festgelegt.

  • EIS „Basic“ und EIS „Structured“: EIS „Basic“ beschreibt die für alle Dokumente in ELGA verpflichtende Mindeststrukturierung. Dokumente auf dieser Stufe müssen nur die Daten codiert enthalten, die unter anderem für das Dokumentenregister und das Berechtigungssystem unbedingt benötigt werden (CDA Header). Dieser Mindeststrukturierungsgrad und die Zuordnung zu einer definierten Dokumentenklasse sind die Voraussetzung für die Verwendung der Dokumente in ELGA. CDA-Dokumente auf dieser Stufe folgen den Anforderungen des „Allgemeinen Implementierungsleitfaden für CDA-Dokumente“ und allfälliger Header-Spezifikationen eines speziellen Leitfadens. In EIS „Basic“ ist zusätzlich die Möglichkeit gegeben, ein Organisations-Logo in Level 3 Codierung einzubetten. Die Herausforderung für die Dokumentenersteller beziehungsweise die dokumentenerstellenden EDV-Systeme ist auf dieser Stufe minimal, medizinische Inhalte sollen als XML-Textelemente vorhanden sein, können aber auch als PDF in die CDA-Dokumente eingebettet werden (eingebettetes PDF oder XML ohne Templates).
    EIS „Structured“ ist eine Erweiterung der verpflichtenden Mindeststrukturierung EIS „Basic“. Die medizinischen Inhalte folgen auf dieser Stufe der Gliederung und dem Aufbau, den der Leitfaden für die höheren EIS „Enhanced“ und „Full Support“ vorgibt, sie folgen aber nicht der entsprechenden technischen Struktur und Codierung. EIS „Structured“ Dokumente decken sich technisch mit EIS „Basic“, erscheinen dem Leser inhaltlich wie EIS „Enhanced“ und „Full Support“ Dokumente, ohne deren semantische Interoperabilität zu unterstützen.
  • EIS „Enhanced“ und EIS „Full Support“ ermöglichen eine einheitliche Darstellung und barrierefreie Anzeige der Daten im ELGA Portal, die mit PDF nicht erreichbar ist. CDA-Dokumente dieser Stufen folgen zusätzlich den Anforderungen eines speziellen Implementierungsleitfadens, der für die jeweilige Stufe angeführt wird. Die Anforderungen betreffen vorwiegend Vorgaben für die Gliederung und Strukturierung des lesbaren Textes, Verwendung und Codierung der CDA Sektionen (CDA-Level 2), können aber auch CDA Level-3 Vorgaben enthalten.
    • EIS „Enhanced“ stellt eine Zwischenstufe auf dem Weg zu „Full Support“ dar. Die Vorgaben betreffen eine kleinere Anzahl an maschinenlesbaren Elementen und sind weniger streng als bei „Full Support“.
    • EIS „Full Support“ kann gegenüber EIS „Enhanced“ zusätzliche maschinenlesbar codierte medizinische Inhalte enthalten, die in ELGA CDA-Dokumenten anzugeben sind.
ELGA Interoperabilitätsstufe „BASIC“ und „STRUCTURED“ Einheitlicher CDA-Header. Verwendung der Dokumente in ELGA (Aufnahme in Dokumentregister, Anzeige für Berechtigte). Minimale Anforderungen an erstellende Systeme („eingebettetes PDF“ oder XML ohne Templates)

EIS „Structured“ erfüllt die fachlich-inhaltlichen, aber nicht die technischen Vorgaben für den Aufbau und die Gliederung des Dokuments aus den speziellen Leitfäden.

ELGA Interoperabilitätsstufe „ENHANCED“ Einheitliche Dokumentation (Strukturierung, Gliederung), barrierefreie Darstellung. Minimale Anforderungen an Level-3 Codierung, gemäß den speziellen Leitfäden.
ELGA Interoperabilitätsstufe „FULL SUPPORT“ Maschinenlesbare Inhalte, automatische Übernahme der Daten in ein medizinisches Informationssystem möglich. Volle Unterstützung der Level 3-Codierung, gemäß den speziellen Leitfäden.

Tabelle 1: ELGA Interoperabilitätsstufen

Die ELGA Interoperabilitätsstufen beschreiben einen ansteigenden Grad der Strukturierung und Codierung der medizinischen Inhalte unabhängig von CDA-Levels. Die Harmonisierungsgruppen legen aufgrund ihrer fachlichen Expertise fest, welche Inhalte der Dokumente in welcher Form sinnvollerweise strukturiert und codiert werden müssen. Es werden nur Daten codiert, die auch medizinisch relevant sind und die mit einem vertretbaren Umsetzungsaufwand von den IT-Systemen der Gesundheitsdiensteanbieter zur Verfügung gestellt werden können.

Um codierte und damit weiter maschinell verarbeitbare strukturierte Dokumente erzeugen zu können, müssen die IT-Systeme der meisten Gesundheitsdiensteanbieter erst umgestellt werden. Die Anpassungen können in der heterogenen IT-Landschaft der Gesundheitsdiensteanbieter unterschiedlich schnell umgesetzt werden.

Zur koordinierten stufenweisen Einführung von CDA bei den verschiedenen ELGA-Gesundheitsdiensteanbietern werden die „ELGA Interoperabilitätsstufen“ als Zwischenziele definiert.

Neben den im ELGA-Gesetz definierten Dokumentenklassen können zukünftige Dokumentenklassen mit ihrer Struktur und Format für ELGA per Verordnung festgelegt werden. Auch für diese Dokumentenklassen gilt zumindest die unterste Interoperabilitätsstufe „EIS Basic“. Wenn ein CDA Implementierungsleitfaden für die Dokumentenklasse harmonisiert wurde, ist es möglich, Dokumente in den höheren Interoperabilitätsstufen „EIS Structured“, „EIS Enhanced“ und „EIS Full Support“ auszutauschen.

4.4 Zertifizierung

Das Thema „Zertifizierung“ (etwa die Zertifizierung von Softwaresystemen) wird von diesem Implementierungsleitfaden nicht behandelt.


Clinical Document Architecture (kurz CDA) ist ein HL7 Standard für den Austausch und die Speicherung von klinischen Dokumenten (Entlassungsbriefe, OP-Berichte). CDA-Dokumente sind XML-Dateien und bestehen aus einem Header mit Metadaten und einem Body mit dem eigentlichen Inhalt.

4.5 Dokumente im Gesundheitswesen

In der medizinischen Welt ist es üblich, klinische Sachverhalte und Beobachtungen mit ihrem Kontext in Dokumente zusammenstellen und zusammenfassen. Der Kontext – z.B. das Ergebnis einer Laboruntersuchung nach einer speziellen Medikamentenbehandlung – wird durch das Dokument etabliert und muss dauerhaft erhalten bleiben, da er wichtige medizinische Zusammenhänge zwischen Einzelinformationen darstellt. Gleichzeitig muss der medizinische Inhalt leicht verfügbar sein und ohne große technische Barrieren sichtbar gemacht werden können. Dies ist unabdingbar für die Akzeptanz von und das Vertrauen in Technologie bei den Endbenutzern, den GDA (Gesundheitsdiensteanbieter). Was mit der Papierwelt bis zu einem gewissen Grade erreicht wurde, muss auch für die elektronische Entsprechung des Papierdokuments gelten.

Interoperabilität“ ist unter anderem gekennzeichnet durch gemeinsam verstandene Definitionen, wie zum Beispiel die des Patienten und der zu ihm bekannten klinischen/medizinischen Informationen, sowie deren Wiederverwendbarkeit.

4.6 CDA Standard

Die „Clinical Document Architecture“ (CDA) ist ein Standard für den Austausch und die Speicherung von klinischer Dokumentation, wie zum Beispiel Entlassungsbriefe, Überweisungen, Behandlungsdokumentation oder OP-Berichte. Dabei wird die „Extensible Markup Language“ (XML) benutzt. CDA wird von „Health Level Seven“ (HL7), einem der bedeutendsten internationalen Standardentwickler für das Gesundheitswesen, entwickelt und stellt einen XML-basierten Dokumenten-Markup Standard zur strukturierten klinischen Dokumentation zur Verfügung. Der CDA Standard definiert ein Informationsobjekt, das außerhalb einer Nachricht existieren kann und neben (strukturiertem) Text auch Bilder, Töne, Biosignale usw. enthalten bzw. referenzieren kann.

4.7 Version

CDA ist Teil der HL7 Version 3 Standardsfamilie. Die erste Version von CDA (CDA Release 1) wurde bereits im September 2000 als offizieller Standard verabschiedet (CDA Level One ANSI/HL7 CDA R1.0-2000). Damit gilt CDA als erster offizieller XML-basierter Standard im Gesundheitswesen.

Die Erfahrungen und weitergehende Bedürfnisse sind in die Entwicklung von CDA Release 2.0 eingegangen. CDA Release 2.0 als Fortentwicklung dieses Standards wurde nach beinahe fünf Jahren weiterer Entwicklungsarbeit am Standard, im Juli 2005 als ANSI Standard verabschiedet. In diese Entwicklungen sind zahlreiche Erfahrungen aus weltweit mehr als 15 größeren, teilweise nationenweiten Projekten eingeflossen, die sich intensiv um CDA Rel. 1 und der Weiterentwicklung verdient gemacht haben. Im Jahr 2008 wurde CDA Rel. 2 als ISO-Standard anerkannt (ISO/HL7 27932:2008). Mittlerweile wird Release 2 in unzähligen Projekten rund um die Welt genutzt.

4.8 Eigenschaften von CDA-Dokumenten

Die Clinical Document Architecture wird zum Austausch von medizinischen Dokumenten verwendet, die typischerweise folgende Eigenschaften aufweisen:

  • Persistenz: Medizinische Dokumente sind durch Persistenz, also dauerhafte Existenz in den sendenden oder empfangenden Systemen gekennzeichnet, wo sie für einen bestimmten Zeitraum in einem unveränderten Zustand bleiben. Dieser Zeitraum wird durch lokale Regelungen definiert.
  • Verwaltung (engl. „stewardship“): Für die Verwaltung des Dokuments ist eine bestimmte Organisation verantwortlich (der „Custodian“).
  • Kontext: Medizinische Dokumente etablieren den Standard-Kontext für die in ihnen gespeicherten Inhalte (z.B. den „Entlassungsbrief“).
  • Authentisierung (engl. „potential für authentication“): Medizinische Dokumente werden authentisiert. Im medizinischen Alltag entspricht das der Signierung, Vidierung oder Validierung.
  • Ganzheit (engl. „wholeness“): Die Authentisierung eines medizinischen Dokumentes bezieht sich auf das Dokument als Ganzes und nicht nur auf einzelne aus dem Kontext gelöste Teile.
  • Lesbarkeit (engl. „human readability“): Medizinische Dokumente sind für Menschen lesbar.

4.9 Bedingungen

Eine grundsätzliche Bedingung für CDA ist die Sicherstellung der Lesbarkeit für Menschen in einem „normalen“ Webbrowser (mit der üblichen Basisfunktionalität zum Browsen im Internet).

Dafür gilt zudem:

  • Es muss einen eindeutig festgelegten Weg für einen Empfänger geben, den authentisierten Inhalt sichtbar zu machen2.
  • Es ist nicht zulässig, dass die Darstellung im Browser nur mithilfe eines bestimmten Stylesheets bewerkstelligt werden kann, das dann zusammen mit dem CDA-Dokument gesendet werden muss. Es muss auch möglich sein, den Inhalt mit einem beliebigen Stylesheet und marktüblichen Browsern darzustellen.
  • Lesbarkeit bezieht sich auf den authentisierten Inhalt. Zusätzlich kann weitere Information im Dokument vorhanden sein („CDA Level 3“), die auf Auswertbarkeit durch Anwendungssysteme abzielt, die aber nicht authentisiert oder lesbar dargestellt werden muss.
  • Wenn strukturierter Inhalt vom narrativen Text abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde, z. B. durch den Autor, durch eine Person, die eine Codierung vorgenommen hat, durch automatisierte Verarbeitung der natürlichen Sprache, durch eine spezifische Software.
  • Wenn narrativer Text von strukturierter Information abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde.


2 Für ELGA wird ein „Referenz-Stylesheet“ bereitgestellt. Das Referenz-Stylesheet ist eine XSLT-Datei zur Transformation der CDA-XML-Datei in HTML. Zur Darstellung von CDA Dokumenten im Browser wird die Verwendung des Referenz-Stylesheets empfohlen.

4.10 CDA Levels

CDA bietet drei verschiedene Varianten, wie Inhalte transportiert werden können; diese Varianten (die so genannten „CDA-Levels“) ermöglichen unterschiedliche Interoperabilität.

„CDA-Level 1“ ist ausschließlich auf die Lesbarkeit durch Menschen ausgelegt. Medizinische Inhalte werden als Text, Bilder oder auch nur als „eingebettetes PDF“ (als unstrukturierter „NonXMLBody“) transportiert.

„CDA-Level 2“ ermöglicht eine Strukturierung der Inhalte nach Abschnitten („Sections“) mit festgelegter Bedeutung, z.B. „Anamnese“, „Diagnosen“. Die Abschnitte sind mit einem vereinbarten Code versehen, der es ermöglicht, dass EDV-Programme diese eindeutig erkennen und als Block verarbeiten können.

„CDA-Level 3“ ist eine Technik zur Anreicherung eines lesbaren Dokuments mit medizinischen Einzelinformationen (z.B. „diastolischer Blutdruck“, „ICD-10 Entlassungs-diagnose“, „Körpergewicht in kg“), die gemäß einer Vereinbarung maschinenlesbar codiert sind und daher automatisch in medizinische Informationssysteme integriert werden können. Die Vereinbarungen für die Codierung in den CDA-Levels 2 und 3 werden durch Templates definiert und in Implementierungsleitfäden veröffentlicht. Die CDA-Levels können aufeinander aufbauend verwendet werden, ein Dokument kann gleichzeitig Informationen in allen drei CDA-Levels enthalten.

Eine detailliertere Beschreibung der CDA-Levels findet sich in „CDA Level 1 bis 3“.

4.11 Konzept und Modellbeschreibung

Der „Allgemeine Implementierungsleitfaden für CDA-Dokumente“ stellt eine grundlegende Implementierungsvorschrift für alle CDA-Dokumente im österreichischen Gesundheitswesen dar. Dieser Vorschrift haben alle über ELGA vermittelten CDA-Dokumente im österreichischen Gesundheitswesen zu folgen.

Darüber hinaus kann auf Basis des vorliegenden Allgemeinen Implementierungsleitfadens ein spezieller Implementierungsleitfaden definiert sein (z.B. Entlassungsbrief, Laborbefund, etc.). Diese speziellen ELGA CDA Implementierungsleitfäden sind bereits für folgende Dokumentenklassen definiert (Liste kann erweitert werden):

  1. Entlassungsbrief (Ärztlich), [OID Root 1.2.40.0.34.7.2]
  2. Entlassungsbrief (Pflege), [OID Root 1.2.40.0.34.7.3]
  3. Pflegesituationsbericht, [OID Root 1.2.40.0.34.7.12]
  4. Laborbefund, [OID Root 1.2.40.0.34.7.4]
  5. Befund bildgebende Diagnostik, [OID Root 1.2.40.0.34.7.5]
  6. e-Medikation, [OID Root 1.2.40.0.34.7.8]

Die Beschreibung des Zusammenhangs von ELGA CDA-Dokumenten und den zur Registrierung von CDA in ELGA notwendigen „XDS-Metadaten“ finden Sie im Dokument:

  1. ELGA XDS Metadaten (XDSDocumentEntry), [OID Root 1.2.40.0.34.7.6]

4.11.1 Aufbau eines CDA-Dokument

Grob gesprochen besteht ein CDA-Dokument aus einem Header und einem Body. Der Header trägt Informationen über das Dokument sowie deren Beteiligte, einschließlich dem Patient. Der Body besteht wiederum aus Body Structures (Abschnitte und narrativer Text) und Body Entries (maschinenauswertbare Detailinformationen). An die Entries können externe Referenzen (External References) geknüpft sein.

Der folgende Überblick zeigt die Hauptkomponenten des CDA R2 Modells auf, in der darauffolgenden Abbildung ist die Struktur in XML-artiger Darstellung gezeigt.

Abbildung 1: CDA R2 Modell mit Header und Body Structures (vereinfachte Übersicht).

Je nach Leitfaden variiert Header und Body aus verschiedenen Templates. Die nachfolgenden Links geben einen Überblick über die jeweiligen Templates nach Implementierungsleitfaden:

Die administrativen Daten im Dokumentheader und grundsätzliche Vorgaben für den medizinischen Inhalt werden vom „Allgemeinen Implementierungsleitfaden“ definiert.

Der jeweilige „Spezielle Implementierungsleitfaden“ enthält die Vorgaben für die medizinischen Inhalte und ergänzt gegebenenfalls die Header-Vorgaben.

Abbildung 2:Zusammenspiel der Implementierungsleitfäden.

4.11.2 CDA Header

Die Informationen zum Patienten, zum Dokument selbst, zu den weiteren beteiligten Personen und Organisationen sowie der dokumentierten Episode (Zeitereignisse) sind zum CDA Header zusammengefasst, hochstrukturiert und von der Semantik her festgelegt.

Die Informationen im Header unterstützen einen Austausch klinischer Dokumente über Institutionsgrenzen hinweg. Er trägt Informationen über das Dokument selbst (eine eineindeutige Identifikation, die Art des Dokuments), über „Teilnehmer“ am Dokument (an der Dokumentation beteiligte Behandler, Autoren, und natürlich den Patienten selbst), sowie über Beziehungen zu Dokumenten (zu Anforderungen und anderen Dokumenten). Mit den Informationen des Headers werden Dokumentenmanagement-Systeme unterstützt, der Header stellt dafür entsprechende Mechanismen zur Verfügung. Damit werden die Zusammenführung und das Wiederfinden der Dokumente in ELGA oder in lokalen Patientenakten wesentlich erleichtert.

4.11.3 CDA Body

Die eigentliche klinische Dokumentation wird im so genannten CDA Body festgehalten. Im Vordergrund steht hier „lesbarer“ (narrativer) Text, der verpflichtender Bestandteil von CDA R2 Dokumenten ist und die Interoperabilität zwischen den menschlichen Kommunikationspartnern garantiert. Hier sind Möglichkeiten gegeben, diesen Text grob zu strukturieren und formatieren, wie man dies von den Möglichkeiten der Textverarbeitung her kennt. Zur Strukturierung stellt die Standardspezifikation eine Reihe von XML-Elementen zur Verfügung, die als Body Structures zusammengefasst werden können. Der Body enthält ein oder mehrere Abschnitte (sections). Diese können auch ineinander geschachtelt sein, so wie Kapitel und Unterkapitel in einem Buch. Zudem sind Strukturierungen im Sinne von Tabellen oder Listen möglich.

  • Abschnitte <section>
  • Paragrafen <paragraph>
  • Kennzeichnung von bestimmten Inhalten <content>
  • Überschriften < caption>
  • Tabellen < table>
  • Listen <list>

Sections enthalten immer einen narrativen Block und erfüllen damit eine der oben genannten Maximen von CDA: die Mensch-zu-Mensch-Interoperabilität, die Lesbarkeit der Informationen für den Menschen. Im narrativen Block wird, durch das Textattribut in der section-Klasse repräsentiert, eingebetteter Text innerhalb eines Abschnittes angegeben. Dabei kann mit oben genanntem content-Element bestimmter Inhalt gesondert gekennzeichnet werden. Zusammengefasst sind im Fließtextblock u.a. folgende Möglichkeiten der Struktur- und Formgebung des Textes gegeben:

  • Zeilenumbrüche < br>
  • Stilistische Angaben (unterstrichen, fett, kursiv etc.)
  • Hoch- und Tiefstellung von Text
  • Fußnoten, Symbole
  • Revisionsmarken im Text mit <content revised=delete> und <content revised=insert>

Mit den beschriebenen Body Strukturen können CDA Entries verbunden sein. Diese repräsentieren den „computerlesbaren Teil“ innerhalb eines Dokumentenabschnitts. Body Entries sind im Prinzip eine Auswahl aus Klassen mitsamt Attributen aus dem HL7 Referenz-Informationsmodell (RIM). In der folgenden Abbildung ist ein Ausschnitt daraus gezeigt.

Abbildung 3: R-MIM-Ausschnitt: Auswahlliste der CDA Body Entries .

Diese Auswahlliste von Entries wird auch als Clinical Statements bezeichnet und findet sich in gleicher oder ähnlicher Form auch in HL7-Version 3 Nachrichten zu Anforderungen und Befunden etc. wieder. Insgesamt sind in der Auswahl folgende Klassen verfügbar.

  • observation, eine (codierte) Beobachtung, z.B. ein Befund oder eine Diagnose
  • procedure, eine Prozedur, z. B. eine Operation, eine andere Behandlung, rein diagnostischer Eingriff
  • encounter, Angaben zu früheren, jetzigen oder geplanten Patientenkontakten
  • substanceAdministration, medikamenten-bezogene Angaben im Sinne von stattgefundenen (Medikamentenanamnese) oder geplanten Medikamentengaben
  • supply, zur Verfügungstellung von Material oder Medikamentenverabreichungen
  • organizer, zur Gruppierung von anderen CDA Entries (Batterien, Cluster)
  • observationMedia, multimedialer Inhalt als Teil des Dokuments
  • regionOfInterest, Kennzeichnung einer Hervorhebung eines Teilaspekts eines Bildes

Alle diese Entries können untereinander linear oder rekursiv hierarchisch verbunden sein. Es sind gleichstufige Beziehungen möglich (zum Beispiel eine Liste von Beobachtungen), aber auch die Wiedergabe einer Hierarchie (z. B. „kleines Blutbild“, bestehend aus „Erythrozyten“, „Leukozyten“, ...).

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

Für das komplette dem CDA Release 2.0 zugrundeliegende Referenzmodell (R-MIM POCD_RM000040) wird auf den publizierten Standard verwiesen (http://www.hl7.at).


5 Allgemeine Richtlinien

5.1 Verwendung von Schlüsselwörtern und farblichen Hervorhebungen

Wenn im Text die Verbindlichkeit von Vorgaben angegeben wird, wird das durch Schlüsselwörter gekennzeichnet [gemäß RFC 2119], die in Majuskeln (Großbuchstaben) geschrieben werden. Die Angabe der Verbindlichkeit ersetzt nicht die Angabe von Kardinalität oder Nullwerten (die in HL7 Version 3 als NullFlavors ausgedrückt werden).

  • MUSS bedeutet eine verpflichtend einzuhaltende Vorschrift (Gebot). Entspricht den Konformitätskriterien [R] und [M].
  • NICHT ERLAUBT formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht dem Konformitätskriterium [NP].
  • SOLL oder EMPFOHLEN steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht dem Konformitätskriterium [R2].
  • KANN oder OPTIONAL (engl. MAY, OPTIONAL) Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Konformtätskriterium [O].

5.1.1 Farbliche Hervorhebungen und Hinweise

Themenbezogene Hinweise zur besonderen Beachtung:

<BEISPIEL>
Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden

Hinweis auf anderen Implementierungsleitfaden:

<BEISPIEL>
Verweis auf Allgemeinen Leitfaden:…

Themenbezogenes CDA Beispiel-Fragment im XML Format:

<BEISPIEL>
<languageCode code="de-AT" />


5.2 Kardinalität

Die Kardinalität beschreibt, wie oft ein Element innerhalb einer Struktur auftreten kann. Die Kardinalität wird durch ein Intervall zwischen der minimalen und maximalen Anzahl angegeben, getrennt durch „..“. Eine unbegrenzte Anzahl wird durch ein „*“ angegeben. Daraus ergeben sich mindestens folgende Möglichkeiten: 0..1; 0..*; 1..1; 1..*

5.3 Legende der Optionalitäten

Siehe auch “Umgang mit optionalen Elementen“.

Konformitäts-Kriterium Mögliche Kardinalität Verwendung von NullFlavor Beschreibung
[M] 1..1
1..*
nicht erlaubt Das Element MUSS mit einem korrekten "echten" Wert angegeben werden. NullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.
[NP] 0..0 nicht erlaubt Das Element ist NICHT ERLAUBT.
[R] 1..1
1..*
erlaubt Das Element MUSS in der Instanz vorhanden sein. Wenn nicht bekannt, ist die Verwendung eines NullFlavors vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT.
[R2] 0..1
0..*
nicht erlaubt Das Element SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein. NullFlavor ist NICHT ERLAUBT.
[O] 0..1
0..*
erlaubt Das Element ist OPTIONAL. Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird.
[C] KONDITIONALES Konformitätskriterium. Die Konformität des Elements variiert in Abhängigkeit von anderen Elementen, Situationen oder Zuständen. Die konkreten Abhängigkeiten sind in Folge angegeben.

Tabelle 2: Legende der Optionalitäten

5.4 Maximum-Set

Das CDA Modell beschreibt ein höchst umfangreiches Schema von Informationselementen und bietet in manchen Bereichen über rekursive, beliebig tief verschachtelbare Elemente eine theoretisch unendlich hohe Anzahl von Möglichkeiten, Informationen abzulegen. Die vollständige Beschreibung und Definition aller Elemente in einem Implementierungsleitfaden wäre daher äußerst aufwändig und ist in den ELGA Implementierungsleitfäden nicht erfolgt.

Vielmehr beschreiben die ELGA Implementierungsleitfäden lediglich jene Elemente, für die es Vorgaben gibt. Die Verwendung aller nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Die ELGA Templates können demnach als „closed templates“ betrachtet werden.

Elemente oder Attribute, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT.

Die ELGA Implementierungsleitfäden beschreiben daher ein sogenanntes „Maximum-Set“. Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:

5.4.1 Ausnahme: „entry“

Die Vorschrift des „Maximums-Sets“ gilt für alle Bereiche des CDA-Dokuments außer der Ebene der maschinenlesbaren Elemente („entry“, CDA-Level 3) von Sektionen.

Selbst-definierte maschinenlesbare Elemente KÖNNEN bei allen Sektionen zusätzlich angewandt werden (sowohl jene, die keine Entries vorsehen, als auch jene, die bereits Entries definieren)!

Achtung: Für bereits in Implementierungsleitfäden definierte Entries gilt jedoch die Regelung des „Maximum-Sets“! Ihre Erweiterung oder Veränderung ist NICHT ERLAUBT.

Diese Ausnahmeregelung soll eine erweiterte Nutzung der CDA-Dokumente ermöglichen und Innovationen bei der Weiterentwicklung der Spezifikationen zu fördern.

Es wäre dadurch erlaubt selbst-definierte Entries zu verwenden, um einen bestimmten Prozess in der eigenen Domäne oder im eigenen Einflussbereich maschinell abwickeln zu können. Die Gültigkeit in ELGA wäre bei einem derartigen Dokument dennoch gewährleistet.

Beispiel:
Ein Krankenhausträger möchte eine maschinenunterstützte Terminkoordination mit seinen Pflegediensten in einem bestimmten Gebiet etablieren, benötigt jedoch für diesen Zweck zusätzliche maschinenlesbare Einträge in den CDA Pflege-Entlassungsbriefen.

Leser aus anderen Gebieten können diese Strukturen zwar nicht interpretieren und daher auch nicht nützen, allerdings beeinflusst dies die normale Nutzung der Dokumente nicht.

5.4.1.1 Meldepflicht von selbst-definierten maschinenlesbaren Elementen

Werden selbst-definierte maschinenlesbare Elemente zur Anwendung gebracht, MÜSSEN die entsprechenden Spezifikationen der ELGA GmbH gemeldet werden.

Die Strukturen werden in Folge in die CDA Arbeitsgruppen zur Weiterentwicklung der Leitfäden eingebracht. Bei allgemeiner Akzeptanz ermöglicht dies eine spätere Integration in die Implementierungsleitfäden.

Wenn in einem Dokument selbst-definierte maschinenlesbare Elemente vorhanden sind, MUSS das bei der Registrierung in der XDS-Registry mit einem zusätzlichen Plus-Zeichen („+“) am Ende des Strings im XDS-FormatCode angezeigt werden.
Beispiel: urn:elga:lab:2011:EIS_FullSupport+
Siehe dazu die entsprechende Regelung im Leitfaden „ELGA XDS Metadaten (XDSDocumentEntry)“, [OID Root 1.2.40.0.34.7.6], Kapitel Zusatz bei selbst-definierten maschinenlesbaren Elementen (Dokumente in EIS „Enhanced“ oder „Full Support“).


5.4.2 Ausnahme: „templateId“

templateId-Elemente KÖNNEN bei Bedarf an allen laut CDA-Schema möglichen Stellen verwendet werden. Wenn bereits templateId-Elemente laut Spezifikation vorgeschrieben sind, KÖNNEN beliebig viele weitere templateId-Elemente angegeben werden.

5.4.3 Ausnahme: Verfasser von CDA-Sektionen

Der Verfasser von Sektionen KANN mittels des Elements „author“ innerhalb einer Sektion („section“-Element) abgebildet werden. Diese „author“-Elemente sind bei Bedarf OPTIONAL bei allen CDA-Sektionen zusätzlich zu verwenden, sofern die Spezifikation der Sektion dies nicht explizit ausschließt.

Siehe auch Sektionen.

5.4.4 Ausnahme: Zusätzliche weitere Beteiligte

Die möglichen Arten für die Dokumentation von wichtigen beteiligten Personen oder Organisationen (z.B. Angehörige, Verwandte, Versicherungsträger, etc.) sind in diesem Leitfaden in Weitere Beteiligte („participant“) definiert. Es ist daher NICHT ERLAUBT, darüberhinausgehende Arten von Beteiligten anzugeben, ausgenommen die entsprechende Art von Beteiligten ist in einem speziellen Implementierungsleitfaden explizit definiert.

5.4.5 Ausnahme: Fixierte Attribute

Attribute, die gem. CDA-Schema mit „fixed“ angegeben sind, haben einen festen Wert, daher können diese Attribute auch weggelassen werden. Diese Attribute werden daher üblicherweise nicht beschrieben und angegeben. Die Angabe von fixierten Attributen oder Attributen mit ihrem gem. CDA-Schema definierten Default-Wert ist erlaubt, auch wenn diese nicht explizit im Leitfaden beschrieben sind.

5.4.6 Hinweis zur Implementierung weiterverarbeitender Software

CDA-Dokumente können unter Umständen „fremde“ Elemente oder Attribute enthalten, die der „Maximum-Set“ Vorschrift dieses Dokumentleitfadens widersprechen (z.B. aufgrund von Software-Fehlern). Darüber hinaus können CDA-Dokumente ebenfalls selbst-definierte maschinenlesbare Elemente beinhalten.

Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, soll weiterverarbeitende Software so implementiert sein, dass dies nicht zu Fehlern in der Weiterverarbeitung der Dokumente führt.

5.4.7 Umgang mit Ausnahmen bei der Konformitätsprüfung

Nur Elemente, die im „Maximum-Set“ beschrieben sind, können zuverlässig geprüft werden. „Fremde“ Elemente oder Attribute4 werden daher von den Konformitätsprüfmechanismen im Sinne der „closed templates“ grundsätzlich als falsch erkannt. Selbst die genannten Ausnahmen, v.a. zusätzliche Entries oder TemplateIds, können daher falsche Fehlermeldungen auslösen. Diese Ausnahmen sollten entsprechend nur, wenn unbedingt notwendig und mit Vorsicht eingesetzt werden.


4Attribute, die im CDA-Schema als „fixed“ definiert sind oder mit ihrem Default-Wert angegeben sind, dürfen angegeben werden und werden auch nicht als Fehler bewertet.

5.5 Umgang mit optionalen Elementen

Sind Elemente bzw. Attribute als „optional“ gekennzeichnet ([O]) so ist ihre Verwendung OPTIONAL, aber es ist NICHT ERLAUBT, dass sie, wenn sie verwendet werden, leer sind. Möchte man ein optionales Element explizit mit einem leeren Wert angeben, so hat dies durch Kennzeichnung mit nullFlavor zu erfolgen, zum Beispiel:

  • NI: wenn es keine Informationen gibt
  • UNK: wenn es Informationen gibt, diese aber unbekannt sind

Zur genauen Definition und Verwendung siehe Der nullFlavor.

5.6 ELGA Value Sets

Ein Value Set ist eine eindeutig identifizierbare und versionierte Sicht auf ein oder mehrere Codesysteme. Es kann als Zusammenstellung von einem oder mehreren Codes aus einem oder mehreren Codesysteme gesehen werden. Ein Value Set enthält die Codes selbst und die Information über die Herkunft des Codes (das Source-Codesystem).

Beispiele für ELGA Value-Sets: „ELGA_NullFlavor“, „ELGA_Dokumentenklassen“.

Wo immer in den ELGA CDA Implementierungsleitfäden eine Werteauswahl getroffen werden kann, wird ein passendes Value Set mit einem eindeutigen Namen angegeben. Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert: https://termpub.gesundheit.gv.at/.

Value Sets sind nicht nur durch einen eindeutigen Namen, sondern auch durch eine OID, und eine Versionsnummer gekennzeichnet. Weiters werden Gültigkeitsstatus und ein "Gültig ab"-Datum angegeben.

Hinweise zum korrekten Umgang mit Terminologien finden sich im „Leitfaden für den Umgang mit Terminologien in ELGA“ [TERMLEIT].

5.6.1 Änderbarkeit von Value Sets

Inhalte von Value Sets können sich ändern, der Name und die OID eines Value Sets bleiben aber gleich. Bei neuen Versionen werden Versionsnummer, Änderungsdatum und „Gültig ab“-Datum (effectiveDate) angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden.

In Ausnahmen kann bei der Definition eines Value Sets angegeben werden, dass es nicht geändert oder versioniert werden darf (Property „Immutability“).

5.6.2 Value Set Binding

Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets. Das bedeutet, dass immer die aktuell am Terminologieserver publizierte Version eines Value Sets anzuwenden ist. (Das Setzen des entsprechenden Schlüsselworts DYNAMIC ist daher in den Leitfäden optional).

Für jedes Value Set ist auch ein Zeitpunkt angegeben, an dem es Gültigkeit erlangt („Gültig ab“), das ist für Value Sets wichtig, die schon vor ihrem Inkrafttreten veröffentlicht werden.

Value Sets können auch STATISCH an ein Code-Element gebunden werden. Das wird gekennzeichnet durch die Angabe des Value Sets mit Name, OID, Version und "Gültig ab"-Datum (effectiveDate) sowie dem Schlüsselwort STATIC.

5.7 PDF Format-Vorschrift

In CDA Dokumenten können Dokumente im PDF Format an verschiedensten Stellen eingebettet werden, entweder als gesamter CDA-Body oder als eingebetteter Inhalt in gewissen CDA-Sektionen. Im Hinblick auf eine dauerhafte Verfügbarkeit der Daten muss mindestens gewährleistet werden, dass diese PDF-Dokumente zuverlässig und eindeutig visuell reproduzierbar sind. Dies kann über die Einhaltung der Mindestkriterien der Norm ISO 19005-1:2005 sichergestellt werden (PDF/A-1b Basic). Die Norm beschreibt zusätzlich Barrierefreiheit der Dokumente, sodass sie von einem Screenreader vorgelesen werden können (PDF/A-1a Accessible). Dieser Implementierungsleitfaden schreibt daher vor, dass jedes eingebettete PDF-Dokument dem Standard PDF/A-1a entsprechen MUSS5.

Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1a (gemäß „ISO 19005-1:2005 Level A conformance“) entsprechen.


Info.png
Änderung
Für die nächste Version des Leitfadens ist geplant, die Vorschrift auf PDF/A-1b zu senken. PDF/A-1a bleibt erlaubt.


5 Bis zum Vorliegen von Dokumenten in EIS Full Support wird mindestens PDF/A-1b vorgeschrieben.

5.8 Größenbeschränkung von eingebetteten Objekten

In CDA Dokumenten können verschiedene Objekte (z.B. PDF-Dokumente, Bilder) eingebettet werden (siehe „ELGA EingebettetesObjekt-Entry“).

Dieser Implementierungsleitfaden schreibt keine Größenbeschränkung für diese Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers, die Größe der über ELGA bereitgestellten CDA-Dateien etwa durch Verringerung der Auflösung oder der Anzahl der Einzelbilder auf eine sinnvolle und angemessene Größe zu beschränken.

Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße der Datei 20 MB nicht überschreiten.6


6 Aktuell wird von ELGA die Größe von Doumenten auf 20MB beschränkt.

5.9 Der nullFlavor

Das Attribut @nullFlavor dient zur Kennzeichnung, wenn das Element nicht seiner Entsprechung gemäß befüllt werden kann.

Obwohl dieses Attribut vom CDA-Schema bei prinzipiell jedem CDA-Element erlaubt wäre, ist die konkrete Anwendung des @nullFlavor Attributs im Rahmen dieser Implementierungsleitfäden nur eingeschränkt erlaubt. Ein entsprechender Vermerk ist im jeweiligen Abschnitt angeführt.

Beispiel für ein Element, welches mit dem @nullFlavor versehen wurde:

<id nullFlavor="UNK" />

Zulässig sind Werte gemäß Value-Set „ELGA_NullFlavor“, solange nicht eine weitere Einschränkung beim jeweiligen Element angegeben wird.

Wenn in einem Element ein NullFlavor angegeben wurde, kann nicht gleichzeitig ein anderes Attribut eingetragen werden.

5.10 Verbot von CDATA

Die Verwendung von CDATA-Abschnitten (<![CDATA[…]]>), also von Zeichenketten, die vom Parser nicht als XML-Quellcode interpretiert werden können, ist für ELGA CDA Dokumente generell NICHT ERLAUBT.


6 Datentypen

Im folgenden Abschnitt werden nur die Datentypen beschrieben, die in ELGA CDA-Dokumenten zur Anwendung kommen. Für weiterführende Informationen wird auf den zu-grundeliegenden Standard Health Level Seven Version 3 (V3), Normative Edition verwiesen.

6.1 Identifikations-Elemente

6.1.1 id-Element II

Identifikationselemente erlauben die global eindeutige Identifikation durch Verwendung von Objektidentifikatoren (kurz „OID“), gemäß dem in ISO/IEC 9834-1 normierten Mechanismus zur weltweit eindeutigen Kennzeichnung von Informationsobjekten [OIDLEIT]. Die relevanten OID werden im OID-Portal für das Österreichische Gesundheitswesen7 registriert und veröffentlicht [OIDPORT.]

Identifikationselemente können im id-Element grundsätzlich auf zweierlei Arten angegeben werden:

  • Methode 1: Angabe der ID sowie einer OID der ID-Liste, aus der die ID stammt
  • Methode 2: Direkte Angabe der ID in Form einer OID. Alternativ zu OID kann hier auch eine UUID gemäß Standard ISO/IEC 9834-8:2005 verwendet werden, wobei die Buchstaben A-F der Hexadezimalzahlen in Großschreibung angegeben werden MÜSSEN.


7 OID Portal für das Österreichische Gesundheitswesen: https://www.gesundheit.gv.at/OID_Frontend/

6.1.1.1 Strukturbeispiele

Methode 1:

<!—
    Angabe der OID der ID-Liste in @root
    sowie der eigentlichen ID in @extension
-->
<id root="1.2.40.0.34.99.111.1.1"
    extension="134F989"
    assigningAuthorityName="KH Eisenstadt" />

Methode 2:

<!-- Angabe einer OID als direkten Identifikator -->
<id root="1.2.40.0.34.99.111.0.1"
    assigningAuthorityName="KH Eisenstadt" />


<!-- Angabe einer UUID als direkten Identifikator -->
<id root="6B48B496-C68E-CD08-55D4-B40CAC520F28"
    assigningAuthorityName="KH Eisenstadt" />

6.1.1.2 Spezifikation

Bei II Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Attribute angegeben.

Element/Attribut DT Kard Konf Beschreibung
Id II ID
@root uid 1..1 M Methode 1: OID der ID-Liste, der die ID angehört

Methode 2: OID oder UUID des Objekts

Die Hexadezimalzahlen A-F der UUID MÜSSEN bei der Verwendung in HL7 CDA in Großschreibung angegeben werden


@extension st 0..1 C
Konditioinale Konformität:
Methode 1
Methode 2

1..1
0..0

M
NP
ID des Objekts aus der ID-Liste
@assigningAuthorityName st 0..1 O Klartext-Darstellung der die ID ausgebenden Stelle

6.1.1.3 Vorschriften für bereits definierte ID-Arten

Die folgenden Unterkapitel zeigen IDs, die in CDA-Dokumenten zur Anwendung kommen können.

6.1.1.3.1 ID aus dem GDA-Index

Die Vorgaben für IDs aus dem GDA-Index sind in der Basiskomponente „GDA-Index“ beschrieben.

Informationen zum österreichischen OID-Konzept finden Sie online auf dem „OID Portal Österreich“: https://www.gesundheit.gv.at/OID_Frontend/index.jsp?section=1

6.1.1.3.2 DVR-Nummer

Die Datenverarbeitungsregister-Nummer (DVR-Nummer) des jeweiligen Gesundheitsdienstleisters kann als zusätzliches ID-Element abgebildet werden.

6.1.1.3.2.1 Spezifikation
Element/Attribut DT Kard Konf Beschreibung
Id II ID
@root uid 1..1 M Fester Wert: 1.2.40.0.10.2.0.2.1
@extension st 1..1 M Datenverarbeitungsregister-Nummer
(DVR-Nummer)
z.B.: 0000137
@assigningAuthorityName st 0..1 O Fester Wert: Österreichisches Datenverarbeitungsregister
6.1.1.3.3 ATU Nummer

Die Umsatzsteueridentifikationsnummer (ATU-Nummer) des jeweiligen Gesundheits-dienstleisters kann als zusätzliches ID-Element abgebildet werden.

6.1.1.3.3.1 Spezifikation
Element/Attribut DT Kard Konf Beschreibung
Id II ID
@root uid 1..1 M Fester Wert: 1.2.40.0.10.2.0.3.1
@extension st 1..1 M Umsatzsteueridentifikationsnummer
(ATU-Nummer)
z.B.: ATU56658245
@assigningAuthorityName st 0..1 O Fester Wert: Österreichisches Finanzamt
6.1.1.3.4 Bankverbindung

Die einzelnen Elemente einer Bankverbindung (IBAN, SWIFT-Adresse oder BIC) können jeweils als eigene ID-Elemente abgebildet werden. Bankleitzahl und Kontonummer werden nicht mehr unterstützt.

6.1.1.3.4.1 Spezifikation: IBAN
Element/Attribut DT Kard Konf Beschreibung
Id II ID
@root uid 1..1 M Fester Wert: 1.0.13616
@extension st 1..1 M IBAN
z.B.: 1200052066543301
@assigningAuthorityName st 0..1 O Fester Wert: Society for Worldwide Interbank Financial Telecommunication
6.1.1.3.4.2 Spezifikation: SWIFT-Adresse oder BIC
Element/Attribut DT Kard Konf Beschreibung
Id II ID
@root uid 1..1 M Fester Wert: 1.0.9362
@extension st 1..1 M SWIFT/BIC
z.B.: BKAUATWW
@assigningAuthorityName st 0..1 O Fester Wert: Society for Worldwide Interbank Financial Telecommunication

6.2 Codierungs-Elemente

Mit Codierungselementen können Konzepte über einen Code und der Angabe des Terminologie- bzw des Codesystems, aus dem der Code stammt ausgedrückt werden.

6.2.1 code-Element CE CWE

Begriffsdefinitionen: CE “Coded with Equivalents”, CWE „Coded with Exceptions“ (bedeutet, dass das vom Standard angegebene Vokabular empfohlen wird, im Leitfaden können Ausnahmen definiert werden).

6.2.1.1 Strukturbeispiele

6.2.1.1.1 Minimal-Variante um einen Code eindeutig darzustellen:
<code code="E10"
      codeSystem="1.2.40.0.34.5.56"/>
6.2.1.1.2 Gebräuchlichste Variante mit zusätzlichem Klartext für Code und Codesystem
<code code="E10"
      displayName="Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes"
      codeSystem="1.2.40.0.34.5.56"
      codeSystemName="ICD-10 BMG 2014"/>
6.2.1.1.3 Vollständige-Variante mit direkter Angabe des Textinhalts
<code code="E10"
    displayName="Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes"
    codeSystem="1.2.40.0.34.5.56"
    codeSystemName="ICD-10 BMG 2014"
    codeSystemVersion="1.00">
  <originalText>Diabetes mellitus Typ 2</originalText>
</code>
6.2.1.1.4 Vollständige-Variante mit Referenz in den narrativen Textbereich
<code code="E11"
      displayName="Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes"
      codeSystem="1.2.40.0.34.5.56"
      codeSystemName="ICD-10 BMG 2014"
      codeSystemVersion="1.00">
   <originalText>
      <reference value="#entldiag-1"/>
   </originalText>
</code>

Für eine detaillierte Beschreibung der Abbildung von Referenzen in den narrativen Bereich siehe Spezifikation und „Zusammenhang Text und Entry“.

6.2.1.1.5 Vollständige-Variante mit Referenz in den narrativen Textbereich und Übersetzung in zwei andere Code-Systeme
<code code="E10"
     displayName="Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes"
     codeSystem="1.2.40.0.34.5.56"
     codeSystemName="ICD-10 BMG 2014">
  <originalText>
     <reference value="#entldiag-1"/>
  </originalText>
  <translation code="46635009"
     displayName="Diabetes mellitus type I"
     codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT">
   <originalText>
     <reference value="#entldiag-1"/>
   </originalText>
  </translation>
  <translation code="xyz"
     displayName="Diabetes mellitus juvenilis"
     codeSystem="9.8.7.6.5.4.3.2.1" codeSystemName="AnderesCodesystem">
   <originalText>
     <reference value="#entldiag-1"/>
   </originalText>
 </translation>
</code>

6.2.1.2 Spezifikation

Bei CE CWE Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Attribute angegeben:

Element/Attribut DT Kard Konf Beschreibung
code CE
CWE
Code Element
@code cs 1..1 M Der eigentliche Code-Wert
z.B. E10
@displayName st 0..1 R2 Die Klartext-Darstellung des Code-Werts, wie vom originalen Codesystem (in der entsprechenden offiziellen Sprachvariante) vorgesehen.
z.B. Primär insulinabhängiger Diabetes mellitus, Typ-2-Diabetes
Der DisplayName ist nicht zur Weiterverarbeitung und zur Anzeige in einem User-Interface vorgesehen.

Die Bedeutung wird durch @code und @codeSystem getragen und SOLL über die entsprechende Codeliste aufgelöst werden.

@codeSystem uid 1..1 M Die Identifikation der Codeliste
z.B. 1.2.40.0.34.5.56 bzw. die aktuell gültige OID der Codeliste
@codeSystemName st 0..1 R2 Der Klartext-Darstellung der Codeliste
z.B. ICD-10 BMG 2014 bzw. die aktuell gültige Version


@codeSystemVersion st 0..1 O Die Versionsnummer der Codeliste
z.B. 1.00
originalText ED 0..1 O Textinhalt, der als Basis zur Codierung herangezogen wurde (… von der Person gesehen, als sie den Code vergeben hat).
Entweder direkt angegeben als „String“ oder indirekt als „Referenz“ auf eine Textstelle im narrativen Bereich.
Im Falle der direkten Angabe als „String“, z.B. Diabetes mellitus Typ 1
reference TEL 0..1 C Referenz Element
Konditionale Konformität:
Wenn indirekte Angabe als „Referenz“
Wenn direkte Angabe

1..1
0..0

M
NP
@value url 1..1 M #{generierter_ref_string}-{generierteID}
z.B.: #entldiag-1, verweist auf die Textstelle im narrativen Block: <td ID=“entldiag-1“>Diabetes mellitus Typ 1</td>
translation CE
CWE
0..* O Beliebig viele optionale Übersetzungen des Codes in andere Codesysteme gemäß derselben Spezifikation (CE CWE) wie das Code-Element selbst.

6.2.2 code-Element CS CNE

Begriffsdefinitionen: CS “Coded simple”; CNE „coded no exceptions“ (bedeutet, dass das angegebene Vokabular verwendet werden MUSS)

6.2.2.1 Strukturbeispiel

<languageCode code="de-AT" />


6.2.2.2 Spezifikation

Bei CS CNE Elementen wird nur das folgende Attribut angegeben:

Element/Attribut DT Kard Konf Beschreibung
code CS CNE Code Element
@code cs 1..1 M Der eigentliche Code-Wert
z.B. de-AT

6.3 Zeit-Elemente

Angaben von Zeiten sind in HL7 auf vielerlei Arten möglich. Es können Zeitpunkte, Zeitintervalle bestehend aus Beginn- und Endzeitpunkt, Zeitintervalle bestehend aus Beginnzeitpunkt und Dauer und vielerlei mehr Varianten abgebildet werden.

Die beiden häufigsten Varianten „Zeitpunkt“ und „Zeitintervall“ werden im Anschluss in Einfaches Zeitelement TS und Intervall-Zeitelement IVL_TS spezifiziert. Weitere Spezifizierungen von Zeit-Elementen können von den speziellen Implementierungsleitfäden vorgenommen werden, z.B. spezifiziert der Implementierungsleitfaden e-Medikation den Datentyp GTS (General Timing Specification) für komplexe Zeitangaben mit Anfang, Ende und Häufigkeit bei den Einnahmeregeln für Medikamente.

6.3.1 Allgemeines zur Angabe von Datum und Zeit

Der Wert für einen Zeitpunkt kann auf zweierlei Arten angegeben werden:

  • Nur als Datum
  • Datum und Uhrzeit

6.3.1.1 Nur Datum

Wird ein Zeitpunkt als Datum (ohne Zeit) angegeben, MUSS dies in folgendem Format erfolgen: YYYYMMDD

Bedeutung:

  • Jahr 4-stellig +
  • Monat 2-stellig +
  • Tag 2-stellig

Beispiel:

Datum 24.12.2008

<effectiveTime value="20081224"/>


6.3.1.2 Datum, Zeit und Zeitzone

Wird ein Zeitpunkt als Datum mit Zeit angegeben, MUSS dies in folgendem Format erfolgen: YYYYMMDDhhmmss[+/-]HHMM

Bedeutung:

  • Jahr 4-stellig +
  • Monat 2-stellig +
  • Tag 2-stellig
  • Stunde 2-stellig (24 Stunden Format)
  • Minute 2-stellig
  • Sekunde 2-stellig
  • + oder -
  • Zeitzonenverschiebung Stunde 2-stellig
  • Zeitzonenverschiebung Minute 2-stellig

Wird in einem Zeitelement zusätzlich zum Datum eine Zeit angegeben, MUSS die Zeitzone verpflichtend angegeben werden!

Die angegebene Zeitzone MUSS die aktuelle Sommerzeitregelung inkludieren.

Beispiele:

a) Datum 24.12.2008, um 15:00 Uhr in Europa/Wien (bei Winterzeit)

<effectiveTime value="20081224150000+0100"/>

b) Datum 24.08.2008, um 15:00 Uhr in Europa/Wien (bei Sommerzeit)

<effectiveTime value="20080824150000+0200"/>


6.3.2 Zeitpunkt: Einfaches Zeitelement TS

6.3.2.1 Strukturbeispiel

<effectiveTime value="20131224180000+0100"/>


6.3.2.2 Spezifikation

Bei Zeitpunkten werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:

Element/Attribut DT Kard Konf Beschreibung
effectiveTime TS
@value ts 1..1 M Zeitpunkt (bei Zeitangabe mit Zeitzone)
z.B. 20131224180000+0100

6.3.3 Zeitintervall: Intervall-Zeitelement IVL_TS

6.3.3.1 Strukturbeispiel

<effectiveTime>
  <low value="..."/>   <!-- Zeitpunkt von -->
  <high value="..."/>   <!-- Zeitpunkt bis -->
</effectiveTime>

6.3.3.2 Spezifikation

Bei Zeitintervallen werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:

Element/Attribut DT Kard Konf Beschreibung
effectiveTime IVL_TS Zeitintervall
low TS 1..1 R Beginn des Intervalls
Zugelassene nullFlavor: UNK
@value ts 1..1 M Zeitpunkt des Beginns des Intervalls
high TS 1..1 R Ende des Intervalls
Zugelassene nullFlavor: UNK
@value ts 1..1 M Zeitpunkt des Endes des Intervalls

Ein Datum, das mit yyyymmdd angegeben wurde, wird gemäß Standard HL7 CDA Rel.2 interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1.Dezember 2013 angegeben werden soll, MUSS das so erfolgen:

  <low value="20131201"/> 
  <high value="20131202"/>

Für mehr Klarheit empfiehlt sich daher die zusätzliche Angabe der Zeit mit Zeitzone:

  <low value="20131201000000+0100"/> 
  <high value="20131201235959+0100"/>

6.4 Kontaktdaten-Elemente

6.4.1 telecom-Element TEL

Ein telecom Kommunikations-Element dient zur Angabe von Kontaktdaten zu einem Personen- oder Organisationselement.

6.4.1.1 Strukturbeispiele

6.4.1.1.1 Beispiele für Präfixe in TEL Elementen

<telecom value="tel:+43.1.40400"/>
<telecom value="fax:(02236)83.12323-12"/>
<telecom value="mailto:office@organisation.at"/>
<telecom value="http://www.organisation.at"/>


6.4.1.1.2 Beispiel für die Angabe einer Mobilnummer

<telecom use="MC" value="tel:+43.660.1234567"/>


6.4.1.2 Spezifikation

Bei TEL Elementen werden, sofern nicht anders spezifiziert, immer die folgenden Unterelemente/Attribute angegeben:

Element/Attribut DT Kard Konf Beschreibung
telecom TEL Kontakt-Element
@value url 1..1 M Die Kontaktadresse (Telefonnummer, Email, etc.)
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten
Bsp: tel:+43.1.1234567
Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme
@use cs 0..1 O Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …)
Bsp: WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse

6.4.1.3 telecom – Format Konventionen für Telekom-Daten

Das @value Attribut des telecom-Elements …

  • … MUSS das URI Schema „tel:“, „mailto:“, etc. aufweisen
    • Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme
  • … MUSS im Falle von internationalen Telefonnummern mit einem „+“ beginnen
  • … DARF nur Ziffernzeichen 0 bis 9 nutzen sowie als visuelle Separatorzeichen nur Bindestrich –, Punkte . oder Klammern () verwenden.
    • … Leerzeichen sind in Telefonnummern NICHT ERLAUBT

6.5 Namen-Elemente

6.5.1 Namen-Elemente von Personen PN

Personen-Namen werden über das Element name abgebildet.

Die Bedeutung des Namen-Elements KANN mit dem Attribut @use angegeben werden. Fehlt das Attribut, wird der Name als „rechtlicher Name“ (Realname bzw. bürgerlicher Name) angenommen (entsprechend @use=“L“, legal name).

Werden mehrere Namen angegeben, MUSS die Bedeutung für jedes Namen-Element über das Attribut @use angegeben werden, wobei nur EIN rechtlicher Name angegeben werden DARF.

6.5.1.1 Granularitätsstufe 1: Unstrukturierte Angabe

In Granularitätsstufe 1 wird der Personen-Name unstrukturiert angegeben. Die einzelnen Elemente des Namens (Vorname, Nachname) werden nicht getrennt.

6.5.1.1.1 Strukturbeispiele

Beispiele für name-Elemente in Granularitätsstufe 1:

<name>Dr. Herbert Mustermann</name>


<name use="A">Dr. Kurt Ostbahn </name>


6.5.1.1.2 Spezifikation

Bei name-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:

Element/Attribut DT Kard Konf Beschreibung
name PN Namen-Element (Person)
@use cs 0..1 O Die genaue Bedeutung des angegebenen Namens, beispielsweise, dass der angegebene Personen-Name ein „Künstlername“ ist. Weitere Bsp: L (rechtlicher Name), A (Künstlername), R (Ordensname)
Zulässige Werte gemäß Value-Set „ELGA_EntityNameUse

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

6.5.1.2 Granularitätsstufe 2: Strukturierte Angabe

In Granularitätsstufe 2 wird der Personen-Name strukturiert angegeben. Die einzelnen Elemente des Namens (mindesten der Vorname und Nachname) werden getrennt angegeben.

6.5.1.2.1 Strukturbeispiel

Beispiel für ein name-Element in Granularitätsstufe 2:

<name>
   <prefix qualifier="PR">OMedR</prefix>
   <prefix qualifier="AC">Dr.</prefix>
   <given>Sissi</given>
   <family>Österreich</family>
   <family qualifier="BR">Habsburg</family>
   <suffix qualifier="AC">MSc</suffix>
</name>
6.5.1.2.2 Spezifikation

Bei name-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:

Element/Attribut DT Kard Konf Beschreibung
name PN Namen-Element (Person)
@use cs 0..1 O Die genaue Bedeutung des angegebenen Namens, beispielsweise, dass der angegebene Personen-Name ein „Künstlername“ ist.
Bsp: L (rechtlicher Name), A (Künstlername), R (Ordensname)

Zulässige Werte gemäß Value-Set „ELGA_EntityNameUse
Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

prefix en.prefix 0..* O Beliebig viele Präfixe zum Namen
z.B. Akademische Titel, Adelstitel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!


@qualifier cs 0..1 O Die genaue Bedeutung eines prefix-Elements, beispielsweise, dass das angegebene Präfix einen akademischen Titel darstellt.
z.B.: AC („Akademischer Titel“)
Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier
given en.given 1..* M Mindestens ein Vorname
@qualifier cs 0..1 O Die genaue Bedeutung eines given-Elements, beispielsweise, dass das angegebene Element eine Initial (z.B. middle initial) bezeichnet.
z.B.: IN („Initial“)
Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier
family en.family 1..* M Mindestens ein Hauptname (Nachname)
@qualifier cs 0..1 O Die genaue Bedeutung eines family-Elements, beispielsweise, dass das angegebene Element einen Geburtsnamen bezeichnet.
z.B.: BR („Geburtsname“)
Zulässige Werte gemäß Value-Set br/>Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier
suffix en.suffix 0..* O Beliebig viele Suffixe zum Namen
z.B. Akademische Titel, Adelstitel
@qualifier cs 0..1 O Die genaue Bedeutung eines suffix-Elements, beispielsweise, dass das angegebene Suffix einen akademischen Titel darstellt.
z.B.: AC („Akademischer Titel“)
Zulässige Werte gemäß Value-Set br/>Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier

Die korrekte Reihenfolge der einzelnen Namenselemente ist wichtig. Als Richtlinie gilt, dass diese in der "natürlichen" Reihenfolge der Benutzung des Namens angegeben werden. Das ist besonders in den folgenden Fällen relevant:

  • Präfixe (prefix) MÜSSEN immer vor dem Namen stehen, zu dem sie gehören.
  • Vornamen (given) MÜSSEN immer in der offiziellen (gesetzlichen) Sequenz stehen.
  • Nachnamen (family) und ein eventuelles Trennzeichen (meistens ‘-‘) MÜSSEN in der offiziellen Sequenz stehen, abhängig von der Wahl bei der Eheschließung.
  • Suffixe (suffix) MÜSSEN immer hinter dem Namen stehen, zu dem sie gehören.

Für die Namenselemente kann zur näheren Bestimmung ein Qualifier angegeben werden (aus dem Value Set ELGA_EntityNamePartQualifier“), v.a. für Prefix/Suffix.

Es gibt auch nicht näher bestimmte Prefixe/Suffixe, z.B. trifft das für die Angabe von "Junior" oder "Senior" bzw "Jun."/"Sen" oder "Jr."/"Sr" zu.

<name>
  <given>Herbert</given>
  <family>Mustermann</family>
  <suffix>Sen.</suffix>
</name>

6.5.2 Namen-Elemente von Organisationen ON

Organisations-Namen werden über das Element name abgebildet.

Dieser Implementierungsleitfaden lässt nur die unstrukturierte Angabe des Organisationsnamens zu. Die Verwendung des @qualifier Attributs beim name-Element ist nicht gestattet.

6.5.2.1 Strukturbeispiel

Beispiel für die Angabe eines Organisationsnamens:

<name>Krankenhaus Wels</name>


6.5.2.2 Spezifikation

Element/Attribut DT Kard Konf Beschreibung
name ON Name der Organisation

6.6 Adress-Elemente

Adressen von Personen und Organisationen werden über das Element addr abgebildet. Das Adress-Element kann in verschiedenen Kontexten mit unterschiedlicher Detailgenauigkeit vorkommen. Daher werden drei Granularitätsstufen definiert, auf die je nach Anwendung entsprechend verwiesen wird.

Sind keine Adressdaten vorhanden, kann das Element entweder wegelassen werden oder mit NullFlavor angegeben werden – je nachdem wie das Adress-Element im Kontext spezifiziert wurde.

6.6.1 Granularitätsstufe 1: Unstrukturierte Angabe

In Granularitätsstufe 1 wird die Adresse unstrukturiert angegeben. Die einzelnen Elemente der Adresse (Straße, PLZ, Ort, …) werden nicht getrennt.

Hinweis: Diese Granularitätsstufe ist ausdrücklich „nicht empfohlen“ und SOLL nur in EIS Basic angewandt werden, wenn eine feinere Granularität nicht möglich ist.
Bei EIS Enhanced und EIS Full Support MUSS die Granularitätsstufe 2 oder 3 angegeben werden.

6.6.1.1 Strukturbeispiel

Beispiel für ein addr-Element in Granularitätsstufe 1:

<addr use="HP">Musterstraße 13a, 1220 Wien, Österreich</addr>


6.6.1.2 Spezifikation

Bei addr-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:

Element/Attribut DT Kard Konf Beschreibung
addr AD Namen-Element
@use cs 0..1 O Die genaue Bedeutung der angegebenen Adresse, beispielsweise, dass die angegebene Adresse die Wohn-Adresse ist.
Bsp: HP („Home primary“)
Zulässige Werte gemäß Value-Set

ELGA_AddressUse
Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als „Wohnadresse“ („H“) und bei Organisationen als Büroadresse („WP“).

6.6.2 Granularitätsstufe 2: Strukturierte Angabe, Stufe 1

In Granularitätsstufe 2 wird die Adresse strukturiert angegeben, wobei aber Straße und Hausnummer noch zusammen angegeben werden.

6.6.2.1 Strukturbeispiel

Beispiel für ein addr-Element in Granularitätsstufe 2:

<addr>
   <streetAddressLine>Musterstraße 11a/2/1</streetAddressLine>
   <postalCode>7000</postalCode>
   <city>Eisenstadt</city>
   <state>Burgenland</state>
   <country>AUT</country>
   <additionalLocator>Station A, Zimmer 9</additionalLocator>
</addr>

6.6.2.2 Spezifikation

Bei addr-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:

Element/Attribut DT Kard Konf Beschreibung
addr AD Namen-Element
@use cs 0..1 O Die genaue Bedeutung der angegebenen Adresse, beispielsweise, dass die angegebene Adresse die Wohn-Adresse ist.
Bsp: HP („Home primary“)
Zulässige Werte gemäß Value-Set

ELGA_AddressUse
Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als „Wohnadresse“ („H“) und bei Organisationen als Büroadresse („WP“).

streetAddressLine ADXP 1..1 M Straße mit Hausnummer
Bsp: Musterstraße 11a/2/1
postalCode ADXP 1..1 M Postleitzahl
city ADXP 1..1 M Stadt
state ADXP 0..1 O Bundesland
country ADXP 1..1 M Staat

Es wird EMPFOHLEN, den Staat im ISO 3 Ländercode (ISO-3166-1 Alpha 3) anzugeben, z.B. „AUT“ für Österreich, „DEU“ für Deutschland…

additionalLocator ADXP 0..1 O Zusätzliche Addressinformationen
z.B.: Station, Zimmernummer im Altersheim

6.6.3 Granularitätsstufe 3: Strukturierte Angabe, Stufe 2

In Granularitätsstufe 3 wird die Adresse maximal strukturiert angegeben (Straße und Hausnummer getrennt).

6.6.3.1 Strukturbeispiel

Beispiel für ein addr-Element in Granularitätsstufe 3:

<addr>
   <streetName>Musterstraße</streetName>
   <houseNumber>11a/2/1</houseNumber>
   <postalCode>7000</postalCode>
   <city>Eisenstadt</city>
   <state>Burgenland</state>
   <country>AUT</country>
   <additionalLocator>Station A, Zimmer 9</additionalLocator>
</addr>

6.6.3.2 Spezifikation

Bei addr-Elementen in dieser Granularitätsstufe werden, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben:

Element/Attribut DT Kard Konf Beschreibung
addr AD Namen-Element
@use cs 0..1 O Die genaue Bedeutung der angegebenen Adresse, beispielsweise, dass die angegebene Adresse die Wohn-Adresse ist.
Bsp: HP („Home primary“)
Zulässige Werte gemäß Value-Set

ELGA_AddressUse
Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als „Wohnadresse“ („H“) und bei Organisationen als Büroadresse („WP“).

streetName ADXP 1..1 M Straße mit Hausnummer
Bsp: Musterstraße
houseNumber ADXP 1..1 M Hausnummer
Bsp: 11a/2/1
postalCode ADXP 1..1 M Postleitzahl
city ADXP 1..1 M Stadt
state ADXP 0..1 R2 Bundesland
country ADXP 1..1 M Staat

Es wird EMPFOHLEN, den Staat im ISO 3 Ländercode (ISO-3166-1 Alpha 3) anzugeben, z.B. „AUT“ für Österreich, „DEU“ für Deutschland…

additionalLocator ADXP 0..1 O Zusätzliche Addressinformationen
z.B.: Station, Zimmernummer im Altersheim

6.7 Komplexe (zusammengesetzte) Elemente

6.7.1 Personen-Element

Personen-Elemente im CDA sind komplexe, zusammengesetzte Objekte und dienen zur Abbildung von Personen. Ein Personen-Element beinhaltet im Wesentlichen das name-Element der Person.

6.7.1.1 Strukturbeispiel

<assignedPerson>
  <name>
    <prefix qualifier="AC">Dr.</prefix>
    <given>Hubert</given>
    <family>Muster</family>
  </name>
</assignedPerson>

6.7.1.2 Spezifikation

Bei Personen-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:

Element/Attribut DT Kard Konf Beschreibung
name PN 1..* M Name der Person
Grundsätzlich sind die Vorgaben gemäß „Namen-Elemente von Personen PN“ zu befolgen.

6.7.2 Organisations-Element

Organisations-Elemente im CDA sind komplexe, zusammengesetzte Objekte und dienen zur Abbildung von Organisationen unter Berücksichtigung ihrer essentiellen Informationen, wie ID, Name, Adresse, Kontaktdaten, etc.

6.7.2.1 Strukturbeispiel

<serviceProviderOrganization>
   <id root="1.2.40.0.34.3.1.xxx" assigningAuthorityName="GDA Index"/>
   <name>Amadeus Spital</name>
   <telecom value="tel:+43.1.3453446.0"/>
   <telecom value="fax:+43.1.3453446.4674"/>
   <telecom value="mailto:info@amadeusspital.at"/>
   <telecom value="http://www.amadeusspital.at"/>
   <addr>
	<streetName>Mozartgasse</streetName>
	<houseNumber>1-7</houseNumber>
	<postalCode>1234</postalCode>
	<city>St.Wolfgang</city>
	<state>Salzburg</state>
	<country>AUT</country>
   </addr>
</serviceProviderOrganization>

6.7.2.2 Spezifikation

Bei Organisations-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:

6.7.2.2.1 id
Element/Attribut DT Kard Konf Beschreibung
id II 0..* O Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.
Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.
6.7.2.2.2 Name der Organisation
Element/Attribut DT Kard Konf Beschreibung
name PN 1..1 M Name der Organisation
Grundsätzlich sind die Vorgaben gemäß „Namen-Elemente von Organisationen ON“ zu befolgen.
6.7.2.2.3 Kontakt-Elemente der Organisation
Element/Attribut DT Kard Konf Beschreibung
telecom TEL 0..* O Beliebig viele Kontakt-Elemente der Organisation
Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
6.7.2.2.4 Adress-Element der Organisation
Element/Attribut DT Kard Konf Beschreibung
addr AD 0..1 O Ein Adress-Elemente der Organisation
Grundsätzlich sind die Vorgaben gemäß „Adress-Elemente“ zu befolgen.

6.7.3 AssignedEntity-Element (Person + Organisation)

AssignedEntity-Elemente im CDA sind komplexe, zusammengesetzte Objekte und dienen zur Abbildung von abstrakten Entitäten, welche sich aus Person- und Organisationsinformationen zusammensetzen.

Hierbei MUSS jedenfalls die „Person“ der Entität angegeben werden. Die Angabe der Organisation, der die Person angehört, ist prinzipiell optional. Diese Optionalität kann sich in Abhängigkeit vom konkreten Anwendungsfall in „verpflichtend“ ändern.

6.7.3.1 Strukturbeispiel

<assignedEntity>
  <id root="1.2.40.0.34.99.111.1.3"
      extension="2222"
      assigningAuthorityName="Amadeus Spital"/>
  <addr>
      <streetName>Währinger Gürtel</streetName>
      <houseNumber>18-20</houseNumber>
      <postalCode>1090</postalCode>
      <city>Wien</city>
      <state>Wien</state>
      <country>AUT</country>
  </addr>
  <telecom value="tel:+43.1.3453446.0"/>
  <telecom value="fax:+43.1.3453446.4674"/>
  <telecom value="mailto:info@amadeusspital.at"/>
  <telecom value="http://www.amadeusspital.at"/>
  <assignedPerson>
	:
  </assignedPerson>
  <representedOrganization>
	:
  </representedOrganization>
</assignedEntity>

6.7.3.2 Spezifikation

Bei AssignedEntity-Elementen MÜSSEN, sofern nicht anders spezifiziert, immer die folgenden Elemente angegeben werden:

6.7.3.2.1 id
Element/Attribut DT Kard Konf Beschreibung
id II 1..* R Mindestens eine ID der Person der Entität

Zugelassene nullFlavor:

  • NI … Die Person der Entität hat keine Identifikationsnummer
  • UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

6.7.3.2.2 Adress-Element der Organisation
Element/Attribut DT Kard Konf Beschreibung
addr AD 0..1 O Ein Adress-Element der Person der Entität

Grundsätzlich sind die Vorgaben gemäß „Adress-Elemente“ zu befolgen.

6.7.3.2.3 Kontakt-Elemente der Organisation
Element/Attribut DT Kard Konf Beschreibung
telecom TEL 0..* O Beliebig viele Kontakt-Elemente der Person der Entität

Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

6.7.3.2.4 Personen-Element der Entität
Element/Attribut DT Kard Konf Beschreibung
assignedPerson POCD_MT000040.
Person
1..1 M Personendaten der Person der Entität

Grundsätzlich sind die Vorgaben gemäß „Personen-Element“ zu befolgen.

6.7.3.2.5 Organisations-Element der Entität
Element/Attribut DT Kard Konf Beschreibung
representedOrganization POCD_MT000040.
Organization
0..1 O Organisationsdaten der Entität

Grundsätzlich sind die Vorgaben gemäß „Organisations-Element“ zu befolgen.


7 Administrative Daten (CDA Header)

7.1 Überblick

7.1.1 Elemente der CDA Header - Dokumentstruktur

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

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

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

7.2 Dokumentenstruktur

7.2.1 XML Metainformationen

7.2.1.1 Zeichencodierung

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

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


7.2.1.2 Hinterlegung eines Stylesheets

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

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

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

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

7.2.2 Wurzelelement

Der XML-Namespace für CDA Release 2.0 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser MUSS in geeigneter Weise in jeder CDA XML Instanz genannt werden. In 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>

7.2.3 Hoheitsbereich des Dokuments („realmCode“)

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

7.2.3.1 Strukturbeispiel

<realmCode code="AT'"/>


7.2.3.2 Spezifikation

Element/Attribut DT Kard Konf Beschreibung
realmCode CS
CNE
1..1 M Hoheitsbereich des Dokuments

Fester Wert: @code = AT
(aus ValueSet „ELGA_RealmCode“)

7.2.4 Dokumentformat („typeId“)

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

7.2.4.1 Strukturbeispiel

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


7.2.4.2 Spezifikation

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

7.2.5 ELGA Implementierungsleitfaden-Kennzeichnung („templateId“)

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

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

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

7.2.5.1 Strukturbeispiel

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

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

7.2.5.2 Spezifikation

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

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

Element/Attribut DT Kard Konf Beschreibung
templateId[1] II 1..1 M ELGA TemplateId für den Allgemeinen Implementierungsleitfaden

Fester Wert: @root = 1.2.40.0.34.11.1

templateId[n] II 0..* O Weitere TemplateIds

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

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

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

7.2.6 Dokumenten-Id („id”)

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

7.2.6.1 Strukturbeispiel

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

7.2.6.2 Spezifikation

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

Element/Attribut DT Kard Konf Beschreibung
id II 1..1 M Dokumenten-Id

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

7.2.7 Dokumentenklasse („code“)

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

Beispiele für die Klasseneinteilung der Dokumente:

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

7.2.7.1 Strukturbeispiel

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

7.2.7.2 Spezifikation

Element/Attribut DT Kard Konf Beschreibung
code CE
CWE
1..1 M Dokumententyp oder Dokumentenklasse

Zulässige Werte gemäß Value-Set „ELGA_Dokumentklassen
Grundsätzlich sind die Vorgaben gemäß „code-Element CE CWE“ zu befolgen.

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


7.2.8 Titel des Dokuments („title“)

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

Beispiele für Titel der Dokumente:

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

7.2.8.1 Strukturbeispiel

<title>Entlassungsbrief</title>


7.2.8.2 Spezifikation

Element/Attribut DT Kard Konf Beschreibung
title ST 1..1 M Dokumententitel

Der Sinn der Benennung MUSS mit der Dokumentklasse übereinstimmen.

7.2.9 Erstellungsdatum des Dokuments („effectiveTime“)

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

7.2.10 Vertraulichkeitscode („confidentialityCode“)

7.2.10.1 Spezifikation

Id1.2.40.0.34.11.90009
ref
elgabbr-
Gültigkeit2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDconfidentialityCodeAnzeigenameCD 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 (Confidentialty (HL7))
Treetree.png@displayName
1 … 1Fnormal

7.2.11 Sprachcode des Dokuments („languageCode“)

7.2.11.1 Spezifikation

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

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

7.2.12.1 Spezifikation

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

Id1.2.40.0.34.11.90007
ref
elgabbr-
Gültigkeit2015‑09‑18
Andere Versionen mit dieser Id:
  • Kblank.png CDsetIdversionNumber vom 2015‑05‑29
  • Kblank.png CDsetIdversionNumber vom 2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDsetIdversionNumberAnzeigenameSetId VersionNumber
Beschreibung

Der CDA-Header repräsentiert ebenfalls die Beziehungen zu anderen Dokumenten mit Referenz auf die oben genannte Dokumenten-Identifikation.

Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden. Für ELGA-CDA-Dokumente MÜSSEN immer beide Elemente angegeben werden.

Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten). Die versionNumber ist eine natürliche Zahl für die fortlaufende Versionszählung. Mit einer neuen Version wird diese Zahl hochgezählt, die setId bleibt gleich.

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.90007 SetId VersionNumber (2015‑09‑18)
ref
elgabbr-
Beispiel
Beispiel für die 1.Version eines Dokuments
<!-- Die bei setId angegebene ID SOLLTE nicht gleich sein wie die id des Dokuments.-->
<art:placeholder>
  <id root="1.2.40.0.34.99.111.1.1" extension="AAAAAAAAAAAAAAA"/>  <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ"/>  <versionNumber value="1"/></art:placeholder>
Beispiel
Beispiel für die 2.Version eines Dokuments
<!--Die bei setId angegebene ID MUSS mit der setId der Vorversion übereinstimmen.-->
<art:placeholder>
  <id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBB"/>  <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ"/>  <versionNumber value="2"/></art:placeholder>
ItemDTKardKonfBeschreibungLabel
hl7:setId
II1 … 1M

Eindeutige Id des Dokumentensets.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

Hinweis: Bestimmte Systeme, die bei der Übernahme der SetID in die XDS-Metadaten mit dem V2-Datentyp CX arbeiten, könnten ein Problem mit @Extension-Attributen haben, die länger als 15 Zeichen sind. Die SetID sollte unterschiedlich zur clinicalDocument.id sein.

(CDs...ber)
 Beispiel<setId extension="D1127" root="1.2.276.0.76.3.1.139.2.427"/>
hl7:versionNumber
INT.​NONNEG1 … 1M
Versionsnummer des Dokuments.
(CDs...ber)
 Beispiel<versionNumber value="1"/>

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

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

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

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

7.3 Teilnehmende Parteien

7.3.1 Patient („recordTarget/patientRole“)

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

Auszug aus dem R-MIM:

Abbildung 7: Klassen rund um den Patienten.

7.3.1.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​TargetAnzeigenameHeader​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
(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)


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

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

7.3.1.1.2 addr

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

7.3.1.1.3 patient/languageCommunication

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

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

7.3.1.1.4 patient/guardian

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

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

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

7.3.2 Verfasser des Dokuments („author“)

Auszug aus dem R-MIM:

Abbildung 8: Klassen rund um den Autor.

7.3.2.1 Spezifikation

Id1.2.40.0.34.11.20002
ref
elgabbr-
Gültigkeit2015‑05‑09
Andere Versionen mit dieser Id:
  • Kblank.png HeaderAuthor vom 2018‑10‑18 14:32:49
  • Kblank.png HeaderAuthor vom 2013‑02‑10
  • Kblank.png HeaderAuthor vom 2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeaderAuthorAnzeigenameHeaderAuthor
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).

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-48Kyellow.png Autor Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
BeziehungVersion: 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>
ItemDTKardKonfBeschreibungLabel
hl7:author
Verfasser des Dokuments.
(Hea...hor)
 
Target.png
elgagab-data​element-48Kyellow.png Autor Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FAUT
Treetree.png@context​Control​Code
cs0 … 1FOP
Treetree.pnghl7:functionCode
CE0 … 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)
Treetree.pnghl7:time
TS.AT.TZ1 … 1R

Der Zeitpunkt an dem das Dokument verfasst wurde.
Grundsätzlich sind die Vorgaben für Zeit-Elemente“ zu befolgen.

Zugelassene nullFlavor: UNK
(Hea...hor)
Treetree.pnghl7:assignedAuthor
1 … 1ROrganisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.
(Hea...hor)
Treeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
 Beispiel<assignedAuthor classCode="ASSIGNED">
  <id extension="ied8984938" root="1.2.276.0.76.3.1.139.933"/>  <assignedPerson classCode="PSN" determinerCode="INSTANCE">
    <!-- ... -->
  </assignedPerson>
</assignedAuthor>
Treeblank.pngTreetree.pnghl7:id
II1 … *R

Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software.
ODER
Identifikation 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)
Treeblank.pngTreetree.pnghl7:code
CE0 … 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)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...hor)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:assigned​Person
  • hl7:assigned​Authoring​Device
Treeblank.pngTreeblank.pngTreetree.pnghl7: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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.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...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
 … 1(Hea...hor)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FDEV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:manufacturer​Model​Name
SC1 … 1RHersteller und Modellbezeichnung des datenerstellenden Gerätes.
(Hea...hor)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:softwareName
SC1 … 1RBezeichnung (und ggf Version) der datenerstellenden Software.
(Hea...hor)
Treeblank.pngTreetree.pnghl7:represented​Organization
1 … 1MOrganisation, 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>
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *MDie 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)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...hor)


7.3.2.2 Spezifikation: Datenerstellende Geräte als „author“

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

7.3.3 Personen der Dateneingabe („dataEnterer“)

7.3.3.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
NameHeaderDataEntererAnzeigenameHeaderDataEnterer
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)

7.3.4 Verwahrer des Dokuments („custodian“)

Auszug aus dem R-MIM:

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

7.3.4.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
NameHeaderCustodianAnzeigenameHeaderCustodian
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)


7.3.4.1.1 id
Element/Attribut DT Kard Konf Beschreibung
id II 1..1 R Identifikation des Verwahrers des Dokuments aus dem GDA-Index.

Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.“
Zugelassene nullFlavor:

  • NI … Organisation hat keine ID aus dem GDA-Index
  • UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt
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.

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

Auszug aus dem R-MIM:

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

7.3.5.1 Spezifikation

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

7.3.6 Rechtlicher Unterzeichner („legalAuthenticator“)

Auszug aus dem R-MIM:

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

7.3.6.1 Spezifikation

Id1.2.40.0.34.11.20006
ref
elgabbr-
Gültigkeit2011‑12‑19
Andere Versionen mit dieser Id:
  • Kblank.png HeaderLegalAuthenticator vom 2018‑10‑18 14:34:23
StatusKyellow.png EntwurfVersions-Label
NameHeaderLegalAuthenticatorAnzeigenameHeaderLegalAuthenticator
Beschreibung

Der „Rechtliche Unterzeichner“ oder Hauptunterzeichner ist jene Person, welche für das Dokument aus rechtlicher Sicht die Verantwortung übernimmt. Es muss organisatorisch sichergestellt werden, dass die Person, die als rechtlicher Unterzeichner eingetragen wird, über die entsprechende Berechtigung verfügt.

Grundsätzlich MUSS der Hauptunterzeichner angegeben werden, in bestimmten Fällen kann dies aber unterbleiben. Diese Fälle sind in den jeweiligen speziellen Leitfaden entsprechend angegeben. 

Multidisziplinäre Befunde: Der CDA-Standard in Release 2.0 erlaubt nur die Angabe eines legalAuthenticator-Elements, es können jedoch beliebig viele (Mit-) Unterzeichner angegeben werden, siehe „Weitere Unterzeichner („authenticator“)“. Wenn kein eindeutiger Hauptunterzeichner ermittelt werden kann (z.B. bei multidisziplinären Befunden, die von mehreren Fachärzten mit unterschiedlicher Fachrichtung gleichermaßen verantwortet werden), kann die Angabe des Hauptunterzeichners entfallen, wenn mindestens zwei Mitunterzeichner angegeben werden. 

Automatisch erstellte Befunde: Bei Dokumenten, die von „Geräten“ erstellt wurden (wenn der Inhalt durch einen Algorithmus erzeugt und nicht von einer natürlichen Person freigegeben wurde), entfällt die Angabe aller Unterzeichner.

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 2 Konzepte
IdNameDatensatz
elgagab-data​element-79Kyellow.png Rechtlicher Unterzeichner Kyellow.png Datensatz
elgagab-data​element-87Kyellow.png Rechtlicher 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.20006 HeaderLegalAuthenticator (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel
<legalAuthenticator>
  <!-- Zeitpunkt der Unterzeichnung -->
  <time value="20130324082015+0100"/>  <!-- Signaturcode -->
  <signatureCode code="S"/>  <!-- Personen- und Organisationsdaten des Rechtlichen Unterzeichners des Dokuments -->
  <assignedEntity>
    <!-- Identifikation des Rechtlichen Unterzeichners des Dokuments -->
    <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>    <!-- Kontaktdaten des Rechtlichen Unterzeichners des Dokuments -->
    <telecom use="WP" value="tel:+43.6138.3453446.2222"/>    <!-- Personendaten des Rechtlichen Unterzeichners des Dokuments -->
    <assignedPerson>
      <!-- Name des Rechtlichen Unterzeichners des Dokuments -->
      <name>
        <prefix>Univ.-Prof.Dr.</prefix>        <given>Sigrid</given>        <family>Kollmann</family>      </name>
    </assignedPerson>
    <!-- Organisation, in deren Auftrag der Rechtlichen Unterzeichners des Dokuments die Dokumentation unterzeichnet 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>
</legalAuthenticator>
ItemDTKardKonfBeschreibungLabel
hl7:legalAuthenticator
Rechtlicher Unterzeichner.
(Hea...tor)
 
Target.png
elgagab-data​element-79Kyellow.png Rechtlicher Unterzeichner Kyellow.png Datensatz
elgagab-data​element-87Kyellow.png Rechtlicher Unterzeichner Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FLA
Treetree.pnghl7:time
TS.​DATE.​MIN1 … 1R
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

Zugelassene nullFlavor: UNK
(Hea...tor)
Treetree.pnghl7:signatureCode
CS1 … 1MSignaturcode gibt an, dass das Originaldokument unterzeichnet wurde.
(Hea...tor)
Treeblank.pngTreetree.png@code
CONF1 … 1FS
Treetree.pnghl7:assignedEntity
1 … 1M
Personendaten des rechtlichen Unterzeichners.

Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!

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)
7.3.6.1.1 legalAuthenticator Element Allgemein
Element/Attribut DT Kard Konf Beschreibung
legalAuthenticator POCD_MT000040.LegalAuthenticator C Rechtlicher Unterzeichner
Konditionale Konformität:

Regelfall: Der Inhalt des Dokuments wird durch eine natürliche Person freigegeben.


Sonderfall: Multidisziplinärer Befund mit gleichberechtigten ärztlichen Unterzeichnern

Sonderfall „automatisch erstellte Dokumente“: Dokumente, deren Inhalt durch einen Algorithmus erzeugt und die nicht von einer natürlichen Person freigegeben werden.

1..1



0..1



0..0
M



O



NP

Der rechtliche Unterzeichner MUSS angegeben werden

Ob einer der Sonderfälle zur Anwendung kommen DARF, ist in den jeweiligen speziellen Leitfäden definiert.


Der rechtliche Unterzeichner KANN angegeben werden, wenn er fehlt, MÜSSEN mindestens zwei Authenticator-Elemente angegeben werden.


Der legalAuthenticator DARF NICHT angegeben werden. Siehe auch Spezifikation: Datenerstellende Geräte als „author“, Kapitel.

7.3.7 Weitere Unterzeichner („authenticator“)

7.3.7.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
NameHeaderAuthenticatorAnzeigenameHeaderAuthenticator
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)

7.3.8 Weitere Beteiligte („participant“)

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

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

Auszug aus dem R-MIM:

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

7.3.8.1 Festlegung der „Art“ des Beteiligten

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

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

festgelegt.

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

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

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

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

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


7.3.8.2 Fachlicher Ansprechpartner

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

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

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

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

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element Wert Beschreibung Bedeutung
@typeCode CALLBCK Callback contact Fachlicher Ansprechpartner
templateId 1.2.40.0.34.11.1.1.1 - Template ID zur Identifikation dieser Art von Beteiligten
functionCode - - Wird nicht angegeben
@classCode PROV Healthcare provider Gesundheitsdienstanbieter
7.3.8.2.1 Spezifikation
Id1.2.40.0.34.11.1.1.1
ref
elgabbr-
Gültigkeit2014‑03‑25
Andere Versionen mit dieser Id:
  • Kblank.png HeaderParticipantAnsprechpartner vom 2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantAnsprechpartnerAnzeigenameHeaderParticipant Ansprechpartner
Beschreibung
Der fachliche Ansprechpartner ist jene Kontaktperson oder –stelle, welche zur Kontaktaufnahme für fachliche Auskünfte zum betreffenden Dokument veröffentlicht wird. Diese Maßnahme dient zur Kanalisierung und Vereinheitlichung der Kommunikationsschiene zwischen dem Erzeuger und dem Empfänger der Dokumentation, beispielsweise für Rückfragen oder Erfragung weiterer fachlicher Informationen.

Die Angabe dieses Elements ist grundsätzlich optional, wobei in den speziellen Leitfäden eine verpflichtende Angabe spezifiziert sein kann. Bei Verwendung sollen möglichst präzise Kontaktdaten angegeben werden. Es obliegt der dokumenterzeugenden Organisation zu entscheiden, welchen Ansprechpartner sie veröffentlicht.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
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.1.1.1 HeaderParticipant Ansprechpartner (2014‑03‑25)
ref
elgabbr-
Beispiel
Strukturbeispiel
<participant typeCode="CALLBCK">
  <templateId root="1.2.40.0.34.11.1.1.1"/>  <associatedEntity classCode="PROV">
    <!-- Verpflichtende Telefonnummer des fachlichen Ansprechpartners -->
    <telecom use="WP" value="tel:+43.1.3453446.1"/>    <associatedPerson>
      <!-- Name des fachlichen Ansprechpartners -->
      <name>
        <prefix qualifier="AC">Dr.</prefix>        <given>Walter</given>        <family>Hummel</family>      </name>
      <!-- ... ODER ... -->
      <name>Sekretariat Labor</name>    </associatedPerson>
    <!-- Organisation des Fachlichen Ansprechpartners -->
    <scopingOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <name>Amadeus Spital - Labor</name>      <telecom value="tel:+43.1.3453446.0"/>      <telecom value="fax:+43.1.3453446.4674"/>      <telecom value="mailto:info@amadeusspital.at"/>      <telecom value="http://www.amadeusspital.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>
    </scopingOrganization>
  </associatedEntity>
</participant>
Beispiel
Fachlicher Ansprechpartner unbekannt
<participant typeCode="CALLBCK" nullFlavor="UNK">
  <associatedEntity classCode="PROV"/></participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Fachlicher Ansprechpartner).
(Hea...ner)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.1']]
Treetree.png@typeCode
cs1 … 1FCALLBCK
Treetree.pnghl7:templateId
II1 … 1M(Hea...ner)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.1
Treetree.pnghl7:time
NP(Hea...ner)
Treetree.pnghl7:associated​Entity
1 … 1M(Hea...ner)
Treeblank.pngTreetree.png@classCode
cs1 … 1FPROV
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1

Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für "Adress-Elemente" zu befolgen.

(Hea...ner)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT1 … *M

Beliebig viele Kontaktdaten des Beteiligten.

Es MUSS mindestens eine Telefon-Nummer angegeben werden

(Hea...ner)
Treeblank.pngTreetree.pnghl7:associated​Person
1 … 1M

Beteiligte Person.

(Hea...ner)
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...ner)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1

Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für "Organisations-Element" zu befolgen.

(Hea...ner)
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...ner)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ner)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...ner)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ner)


7.3.8.3 Einweisender/Zuweisender/Überweisender Arzt

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

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

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


7.3.8.3.1 Spezifikation
Id1.2.40.0.34.11.1.1.2
ref
elgabbr-
Gültigkeit2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantRefArztAnzeigenameHeaderParticipant Ref Arzt
BeschreibungEinweisender/Zuweisender Arzt/Überweisender Arzt
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-214Kyellow.png Zuweisender 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.1.1.2 HeaderParticipant Ref Arzt (2013‑10‑16)
ref
elgabbr-
Beispiel
Strukturbeispiel Einweisender Arzt
<participant typeCode="REF">
  <templateId root="1.2.40.0.34.11.1.1.2"/>  <associatedEntity classCode="PROV">
    <id root="1.2.40.0.34.3.1.xxx" extension="--example only--"/>    <addr/>    <telecom/>    <!-- Personendaten des einweisenden Arztes -->
    <associatedPerson>
      <name>
        <prefix qualifier="AC">Univ.-Prof. Dr.</prefix>        <given>Herbert</given>        <family>Empfänger</family>      </name>
    </associatedPerson>
    <!-- Organisation, der der einweisenden Arzt angehört -->
    <scopingOrganization>
      <id nullFlavor="UNK"/>      <name>Ordination Dr. Empfänger</name>      <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"/>      <addr>
        <streetName>Musterstraße</streetName>        <houseNumber>27/1/13</houseNumber>        <postalCode>6020</postalCode>        <city>Innsbruck</city>        <country>AUT</country>      </addr>
    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter.(Hea...rzt)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.2']]
 
Target.png
elgagab-data​element-214Kyellow.png Zuweisender Kyellow.png Datensatz
Treetree.png@typeCode
cs1 … 1FREF
 Einweisender/Zuweisender/Überweisender Arzt.
Treetree.pnghl7:templateId
II1 … 1M(Hea...rzt)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.2
 
Template ID für Einweisender/Zuweisender/Überweisender Arzt.

Treetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(Hea...rzt)
Treeblank.pngTreetree.png@classCode
cs1 … 1FPROV
 Gesundheitsdienstanbieter.
Treeblank.pngTreetree.pnghl7:id
II0 … *

Identifikation des Beteiligten (Person).
Zugelassene nullFlavor:

  • NI … Person hat keine ID
  • UNK … Person hat eine ID, diese ist jedoch unbekannt
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

(Hea...rzt)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...rzt)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *Beliebig viele Kontaktdaten des Beteiligten.
(Hea...rzt)
Treeblank.pngTreetree.pnghl7:associated​Person
1 … 1R
Beteiligte Person.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...rzt)
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...rzt)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation, z.B der Ordination).
Grundsätzlich sind die Vorgaben gemäß für „Organisations-Element“ zu befolgen.

(Hea...rzt)
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...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...rzt)


7.3.8.4 Hausarzt

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element Wert Beschreibung Bedeutung
@typeCode IND Indirect target In indirektem Bezug
templateId 1.2.40.0.34.11.1.1.3 - Template ID zur Identifikation dieser Art von Beteiligten
functionCode PCP primary care physician Hausarzt
@classCode PROV Healthcare provider Gesundheitsdienstanbieter
7.3.8.4.1 Spezifikation
Id1.2.40.0.34.11.1.1.3
ref
elgabbr-
Gültigkeit2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantHausarztAnzeigenameHeaderParticipant Hausarzt
BeschreibungHausarzt
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-100Kyellow.png Hausarzt 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.1.1.3 HeaderParticipant Hausarzt (2013‑10‑16)
ref
elgabbr-
Beispiel
Strukturbeispiel Hausarzt
<participant typeCode="IND">
  <templateId root="1.2.40.0.34.11.1.1.3"/>  <functionCode code="PCP" displayName="primary care physician" codeSystem="2.16.840.1.113883.5.88" codeSystemName="HL7:ParticipationFunction"/>  <associatedEntity classCode="PROV">
    <!-- Identifikation des Hausarztes (Person) aus dem GDA-Index -->
    <id root="1.2.3.999" extension="--example only--"/>    <addr/>    <telecom/>    <!-- Personendaten des Hausarztes -->
    <associatedPerson>
      <name>
        <prefix qualifier="AC">Dr.</prefix>        <given>Walter</given>        <family>Mustermann</family>      </name>
    </associatedPerson>
    <!-- Organisation, der der Hausarzt angehört -->
    <scopingOrganization>
      <id root="1.2.40.0.34.3.1.xxx" assigningAuthorityName="GDA Index"/>      <name>Allgemeinmedizinische Praxis Dr. Mustermann</name>      <telecom value="tel:0512.1234567"/>      <telecom value="fax:0512.1234567.11"/>      <telecom value="mailto:office@ordination.at"/>      <telecom value="http://www.ordination.at"/>      <telecom value="me:12345678792"/>      <addr>
        <streetName>Sekundärstraße</streetName>        <houseNumber>22</houseNumber>        <postalCode>6020</postalCode>        <city>Innsbruck</city>        <country>AUT</country>      </addr>
    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Hausarzt).
(Hea...rzt)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.3']]
 
Target.png
elgagab-data​element-100Kyellow.png Hausarzt Kyellow.png Datensatz
Treetree.png@typeCode
cs1 … 1FIND
 In indirektem Bezug.
Treetree.pnghl7:templateId
II1 … 1MTemplate ID zur Identifikation dieser Art von Beteiligten.
(Hea...rzt)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.3
Treetree.pnghl7:functionCode
CE1 … *MHausarzt.(Hea...rzt)
Treeblank.pngTreetree.png@code
CONF1 … 1FPCP
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.5.88 (Participation Function)
Treetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(Hea...rzt)
Treeblank.pngTreetree.png@classCode
cs1 … 1FPROV
 Gesundheitsdienstanbieter.
Treeblank.pngTreetree.pnghl7:id
II0 … *

Identifikation des Beteiligten (Person) aus dem GDA-Index.
Zugelassene nullFlavor:

  • NI … Organisation hat keine ID
  • UNK … Organisation hat eine ID, diese ist jedoch unbekannt
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

(Hea...rzt)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

(Hea...rzt)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *Beliebig viele Kontaktdaten des Beteiligten.
(Hea...rzt)
Treeblank.pngTreetree.pnghl7:associated​Person
1 … 1M
Beteiligte Person.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

(Hea...rzt)
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...rzt)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation), zB die Arztpraxis oder Ordination.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.

(Hea...rzt)
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...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...rzt)


7.3.8.5 Notfall-Kontakt/Auskunftsberechtigte Person

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

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element Wert Beschreibung Bedeutung
@typeCode IND Indirect target In indirektem Bezug
templateId 1.2.40.0.34.11.1.1.4 - Template ID zur Identifikation dieser Art von Beteiligten
functionCode - - Wird nicht angegeben
@classCode ECON Emergency contact Notfall-Kontakt
7.3.8.5.1 Spezifikation
Id1.2.40.0.34.11.1.1.4
ref
elgabbr-
Gültigkeit2013‑11‑13
Andere Versionen mit dieser Id:
  • Kblank.png HeaderParticipantNotfallkontakt vom 2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantNotfallkontaktAnzeigenameHeaderParticipant Notfallkontakt
BeschreibungNotfall-Kontakt / Auskunftsberechtigte Person
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-105Kyellow.png Notfall-Kontakt 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.1.1.4 HeaderParticipant Notfallkontakt (2013‑11‑13)
ref
elgabbr-
Beispiel
Strukturbeispiel Notfallkontakt
<participant typeCode="IND">
  <templateId root="1.2.40.0.34.11.1.1.4"/>  <time>
    <low value="20170721102547"/>  </time>
  <associatedEntity classCode="ECON">
    <!-- Verwandtschaftsverhältnis des Notfallkontakts zum Patienten -->
    <code code="DAU" displayName="Natural daughter" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7:RoleCode"/>    <!-- Adresse des Notfall-Kontakts -->
    <addr>Heimstrasse 1, 1220 Wien</addr>    <!-- Kontaktdaten des Notfallkontakts -->
    <telecom value="tel:0660.1234567"/>    <associatedPerson>
      <!-- Name des Notfallkontakts -->
      <name>Julia Tochter</name>    </associatedPerson>
    <!-- Organisation des Notfallkontakts (z.B.: Behörde) -->
    <scopingOrganization>
      <name>Mustermann Installationen GmbH</name>    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Notfallkontakt / Auskunftsberechtigte Person).
(Hea...akt)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.4']]
 
Target.png
elgagab-data​element-105Kyellow.png Notfall-Kontakt Kyellow.png Datensatz
Treetree.png@typeCode
cs1 … 1FIND
Treetree.pnghl7:templateId
II1 … 1M(Hea...akt)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.4
Treetree.pnghl7:time
IVL_TS0 … 1

Zeitraum, in dem der angegebene Kontakt den Notfall-Kontakt darstellt.
Wird nur angegeben, wenn der Kontakt bereits absehbar nur in einem eingeschränkten Zeitraum zur Verfügung steht.


Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.


(Hea...akt)
Treetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(Hea...akt)
Treeblank.pngTreetree.png@classCode
cs1 … 1FECON
Treeblank.pngTreetree.pnghl7:code
CE0 … 1

Verwandtschaftsverhältnis des Beteiligten zum Patienten.
Beispiel: DAU („daughter“), wenn die Beteiligte die Tochter des Patienten ist.

(Hea...akt)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

(Hea...akt)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *R
Beliebig viele Kontaktdaten des Beteiligten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

Es SOLL mindestens eine Telefonnummer angegeben werden.
(Hea...akt)
Treeblank.pngTreetree.pnghl7:associated​Person
1 … 1M
Name des Beteiligten.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

(Hea...akt)
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...akt)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...akt)
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...akt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...akt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...akt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...akt)


7.3.8.6 Angehörige

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

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element Wert Beschreibung Bedeutung
@typeCode IND Indirect target In indirektem Bezug
templateId 1.2.40.0.34.11.1.1.5 - Template ID zur Identifikation dieser Art von Beteiligten
functionCode - - Wird nicht angegeben
@classCode PRS Personal relationship In persönlicher Beziehung
7.3.8.6.1 Spezifikation
Id1.2.40.0.34.11.1.1.5
ref
elgabbr-
Gültigkeit2016‑07‑21
Andere Versionen mit dieser Id:
  • Kblank.png HeaderParticipantAngehoerige vom 2013‑11‑13
  • Kblank.png HeaderParticipantAngehoerige vom 2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantAngehoerigeAnzeigenameHeaderParticipant Angehörige
BeschreibungAls Angehörige sind in Österreich jene Personen anzusehen, welche in einem Verwandtschaftsverhältnis zum Patienten stehen, aber nicht unter die Gruppe der „Auskunftsberechtigten Personen“ fallen.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
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.1.1.5 HeaderParticipant Angehörige (2016‑07‑21)
ref
elgabbr-
Beispiel
Strukturbeispiel Angehörige
<participant typeCode="IND">
  <templateId root="1.2.40.0.34.11.1.1.5"/>  <associatedEntity classCode="PRS">
    <!-- Verwandtschaftsverhältnis des Angehörigen zum Patienten -->
    <code code="MTH" displayName="mother" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7: RoleCode"/>    <!-- Kontaktdaten des Angehörigen -->
    <addr/>    <telecom value="tel:0660.1234567"/>    <associatedPerson>
      <name>Herta Mutter</name>    </associatedPerson>
    <scopingOrganization/>  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Angehöriger).
(Hea...ige)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.5']]
Treetree.png@typeCode
cs1 … 1FIND
Treetree.pnghl7:templateId
II1 … 1M(Hea...ige)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.5
Treetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(Hea...ige)
Treeblank.pngTreetree.png@classCode
cs1 … 1FPRS
Treeblank.pngTreetree.pnghl7:code
CE1 … 1M

Verwandtschaftsverhältnis des Beteiligten zum Patienten.
Beispiel: DAU („Daughter“), wenn die Beteiligte die Tochter des Patienten ist.

(Hea...ige)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1

Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.


(Hea...ige)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Beliebig viele Kontaktdaten des Beteiligten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

(Hea...ige)
Treeblank.pngTreetree.pnghl7:associated​Person
1 … 1MBeteiligte Person.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...ige)
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...ige)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.

(Hea...ige)
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...ige)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ige)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...ige)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ige)


7.3.8.7 Versicherter/Versicherung

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element Wert Beschreibung Bedeutung
@typeCode HLD Holder Teilnehmer hält ein finanzielles Instrument
templateId 1.2.40.0.34.11.1.1.6 - Template ID zur Identifikation dieser Art von Beteiligten
functionCode - - Wird nicht angegeben
@classCode POLHOLD Policy holder Halter einer Versicherungspolizze
7.3.8.7.1 Spezifikation
Id1.2.40.0.34.11.1.1.6
ref
elgabbr-
Gültigkeit2015‑11‑25
Andere Versionen mit dieser Id:
  • Kblank.png HeaderParticipantVersicherung vom 2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantVersicherungAnzeigenameHeaderParticipant Versicherung
BeschreibungVersicherter/Versicherung
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-119Kyellow.png Versicherter/Versicherung 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.1.1.6 HeaderParticipant Versicherung (2015‑11‑25)
ref
elgabbr-
Beispiel
Patient ist selbst der Versicherungsnehmer
<!-- In diesem Fall können die Angaben zur Person (Adresse, Kontaktdaten, Name des Patienten) entfallen, da diese bereits in der Klasse patientRole angegeben sind. -->
<participant typeCode="HLD">
  <templateId root="1.2.40.0.34.11.1.1.6"/>  <time>
    <low value="20020101"/>    <high value="20151231"/>  </time>
  <associatedEntity classCode="POLHOLD">
    <id root="1.2.40.0.10.1.4.3.1" extension="123424121970" assigningAuthorityName="Österreichische Sozialversicherung"/>    <code code="SELF" displayName="self" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7:RoleCode"/>    <scopingOrganization>
      <name>Sozialversicherung der gew. Wirtschaft</name>      <telecom value="tel:01.54654-0"/>      <telecom value="fax:01.54654-385"/>      <telecom value="http://esv-sva.sozvers.at"/>      <addr>
        <streetName>Wiedner Hauptstraße</streetName>        <houseNumber>84-86</houseNumber>        <postalCode>1051</postalCode>        <city>Wien</city>        <country>AUT</country>      </addr>
    </scopingOrganization>
  </associatedEntity>
</participant>
Beispiel
Patient ist bei einem Angehörigen mitversichert
<!-- In diesem Fall MÜSSEN die Angaben zur versicherten Person vorhanden sein. Im Mindesten MUSS der Name der versicherten Person angegeben sein. -->
<participant typeCode="HLD">
  <templateId root="1.2.40.0.34.11.1.1.6"/>  <!-- Versicherungszeitraum vom 01.01.2002 – 31.12.2008 -->
  <time>
    <low value="20020101"/>    <high value="20081231"/>  </time>
  <associatedEntity classCode="POLHOLD">
    <!-- SV Nummer der Person, bei der der Patient mitversichert ist -->
    <id root="1.2.40.0.10.1.4.3.1" extension="123424121970" assigningAuthorityName="Österreichische Sozialversicherung"/>    <!-- Code FAMDEP (Mitversichert bei Familienangehörigen) -->
    <code code="FAMDEP" displayName="family dependent" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7:RoleCode"/>    <!-- Adresse der Person, bei der der Patient mitversichert ist -->
    <addr>
      <streetName>Musterstrasse</streetName>      <houseNumber>47-51</houseNumber>      <postalCode>8010</postalCode>      <city>Graz</city>      <country>AUT</country>    </addr>
    <!-- Kontakt(e) der Person, bei der der Patient mitversichert ist -->
    <telecom value="tel:+43.(0)50.55460-0"/>    <!-- Name der Person, bei der der Patient mitversichert ist -->
    <associatedPerson>
      <name>
        <given>Herbert</given>        <family>Vater</family>      </name>
    </associatedPerson>
    <!-- Versicherungsgesellschaft -->
    <scopingOrganization>
      <name>Sozialversicherung der gew. Wirtschaft</name>      <telecom value="tel:01.54654-0"/>      <telecom value="fax:01.54654-385"/>      <telecom value="http://esv-sva.sozvers.at"/>      <addr>
        <streetName>Wiedner Hauptstraße</streetName>        <houseNumber>84-86</houseNumber>        <postalCode>1051</postalCode>        <city>Wien</city>        <state>Wien</state>        <country>AUT</country>      </addr>
    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Versicherter/Versicherung).
(Hea...ung)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.6']]
 
Target.png
elgagab-data​element-119Kyellow.png Versicherter/Versicherung Kyellow.png Datensatz
Treetree.png@typeCode
cs1 … 1FHLD
Treetree.pnghl7:templateId
II1 … 1M(Hea...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.6
Treetree.pnghl7:time
IVL_TS0 … 1
Gültigkeitszeitraum der Versicherungspolizze.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

(Hea...ung)
Treetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(Hea...ung)
Treeblank.pngTreetree.png@classCode
cs1 … 1FPOLHOLD
Treeblank.pngTreetree.pnghl7:id
II0 … *

Sozialversicherungsnummer des Patienten (SELF) oder der Person, bei der der Patient mitversichert ist (FAMDEP)

Zugelassene nullFlavor:

  • NI … Patient hat keine Sozialversicherungsnum­mer (z.B. Ausländer, …)
  • UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
(Hea...ung)
Treeblank.pngTreetree.pnghl7:code
CE0 … 1

Versicherungsverhältnis codiert.
Beispiele:
SELF, wenn der Patient selbst der Versicherte ist.
FAMDEP, wenn der Patient bei einem Familienmitglied mitversichert ist.

(Hea...ung)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.9 ELGA_InsuredAssocEntity (DYNAMIC)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

(Hea...ung)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Beliebig viele Kontaktdaten des Beteiligten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

(Hea...ung)
Treeblank.pngTreetree.pnghl7:associated​Person
0 … 1
Name des Beteiligten.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...ung)
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...ung)
 Schematron assertrole error 
 testhl7:code/@code!='FAMDEP' or count(hl7:associated​Person)=1 
 MeldungWenn das Versicherungsverhältnis "familienversichert" ist, dann muss eine associatedPerson angegeben sein 
Treeblank.pngTreetree.pnghl7:scoping​Organization
1 … 1R
Versicherungsgesellschaft.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...ung)
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...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ung)


7.3.8.8 Betreuende Organisation

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

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

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element Wert Beschreibung Bedeutung
@typeCode IND Indirect target In indirektem Bezug
templateId 1.2.40.0.34.11.1.1.7 - Template ID zur Identifikation dieser Art von Beteiligten
functionCode - - Wird nicht angegeben
@classCode CAREGIVER Betreuer Betreuende Entität
7.3.8.8.1 Spezifikation
Id1.2.40.0.34.11.1.1.7
ref
elgabbr-
Gültigkeit2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantBetreuorgAnzeigenameHeaderParticipant Betreuungsorganisation
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-251Kyellow.png Betreuende Organisation Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.1.1.7 HeaderParticipant Betreuungsorganisation (2013‑10‑16)
ref
elgabbr-
Beispiel
Strukturbeispiel Betreuende Organisation
<participant typeCode="IND">
  <templateId root="1.2.40.0.34.11.1.1.7"/>  <associatedEntity classCode="CAREGIVER">
    <!-- Betreuende Organisation -->
    <scopingOrganization>
      <!-- Name der betreuenden Organisation -->
      <name>Altenpflegeheim Sorgenfrei</name>      <!-- Kontaktdaten der betreuenden Organisation -->
      <telecom value="tel:+43.1.3453446.0"/>      <telecom value="fax:+43.1.3453446.4674"/>      <telecom value="mailto:info@altenpflegeheim-sorgenfrei.at"/>      <telecom value="http://www.altenpflegeheim-sorgenfrei.at"/>      <!-- Adresse der betreuenden Organisation -->
      <addr>
        <streetName>Im schönen Walde</streetName>        <houseNumber>24</houseNumber>        <postalCode>2500</postalCode>        <city>Baden</city>        <state>Niederösterreich</state>        <country>AUT</country>      </addr>
    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Betreuende Organisation).
(Hea...org)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.7']]
 
Target.png
elgagab-data​element-251Kyellow.png Betreuende Organisation Kyellow.png Datensatz
Treetree.png@typeCode
cs1 … 1FIND
Treetree.pnghl7:templateId
II1 … 1M(Hea...org)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.7
Treetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(Hea...org)
Treeblank.pngTreetree.png@classCode
cs1 … 1FCAREGIVER
Treeblank.pngTreetree.pnghl7:scoping​Organization
1 … 1M
Betreuende Organisation.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...org)
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...org)
Treeblank.png