[unmarkierte Version]

[geprüfte Version]

Aktuelle Version vom 1. Dezember 2023, 10:28 Uhr

	Dieses Dokument gibt wieder: Implementierungsleitfaden Allgemeiner Implementierungsleitfaden (2.06.5), OID: n.n., Datum: 30. November 2023, Status: Entwurf. Die Teilmaterialien gehören der Kategorie elga-cdaalf-2.06.2 an.

ELGA CDA
Implementierungsleitfäden

HL7 Implementation Guide for CDA^® R2:
Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente

Zur Anwendung im österreichischen
Gesundheitswesen [1.2.40.0.34.7.1.6.2]

30. November 2023

2.06.5

Entwurf

Inhaltsverzeichnis

1 Informationen über dieses Dokument
2 Harmonisierung
3 Einleitung
4 Konzept und Begründung
5 Allgemeine Richtlinien
6 Datentypen
7 Administrative Daten (CDA Header)
8 Medizinische Inhalte (CDA Body)
9 Technische Konformitätsprüfung
10 Anhang
- 10.1 Referenzen
- 10.2 Revisionsliste

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	Person¹
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	Person¹
Ä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	Person¹
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	Person¹
Laborbefund	Fachhochschule Technikum Wien	Stefan Sauermann, Alexander Mense
Befund bildgebende Diagnostik	AIMC	Martin Weigl
Befund bildgebende Diagnostik	Lindner TAC	Andreas Lindner

¹ 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):

Entlassungsbrief (Ärztlich), [OID Root 1.2.40.0.34.7.2]
Entlassungsbrief (Pflege), [OID Root 1.2.40.0.34.7.3]
Pflegesituationsbericht, [OID Root 1.2.40.0.34.7.12]
Laborbefund, [OID Root 1.2.40.0.34.7.4]
Befund bildgebende Diagnostik, [OID Root 1.2.40.0.34.7.5]
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

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

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

² 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):

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

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

⁴Attribute, 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 MUSS^{5^.}

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

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

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

⁶ 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:

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

⁷ 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

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

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)

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

6.3.2 Zeitpunkt: Einfaches Zeitelement TS

6.3.2.1 Strukturbeispiel

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

6.4.1.1.2 Beispiel für die Angabe einer Mobilnummer

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

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

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:

Dokumentenklasse: Entlassungsbrief
- Dokumententyp: „Entlassungsbrief aus stationärer Behandlung (Ärztlich)“
- Dokumententyp: „Entlassungsbrief aus stationärer Behandlung (Pflege)“
Dokumentenklasse: Laborbefund
Dokumentenklasse: Befundbericht Befund bildgebende Diagnostik
…

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

Id

1.2.40.0.34.11.90008

ref

elgabbr-

Gültigkeit

2016‑07‑21

Andere Versionen mit dieser Id:

CDeffectiveTime vom 2013‑11‑07

Status

Aktiv

Versions-Label

Name

CDeffectiveTime

Bezeichnung

CD effectiveTime

Beschreibung

Mit Erstellungsdatum ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird. (z.B.: Wien, am …). Das Erstellungsdatum dokumentiert den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde.

Bemerkung: Das Erstellungsdatum des Dokuments muss nicht mit dem Datum der rechtli-chen Unterzeichnung (oder „Vidierung“) übereinstimmen.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-8	Erstellungsdatum	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.90008 CD effectiveTime (2016‑07‑21)

ref

elgabbr-

Beispiel

Nur Datum: Zeitpunkt als Datum (ohne Zeit) im Format YYYYMMDD

Beispiel

Datum, Zeit und Zeitzone: Zeitpunkt als Datum mit Zeit und Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM

Item

DT

Kard

Konf

Beschreibung

Label

hl7:effectiveTime

TS.AT.TZ

1 … 1

M

Erstellungsdatum des Dokuments.

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

(CDe...ime)


	elgagab-dataelement-8	Erstellungsdatum	Datensatz

7.2.10 Vertraulichkeitscode („confidentialityCode“)

7.2.10.1 Spezifikation

Id

1.2.40.0.34.11.90009

ref

elgabbr-

Gültigkeit

2013‑11‑07

Status

Aktiv

Versions-Label

Name

CDconfidentialityCode

Bezeichnung

CD confidentialityCode

Beschreibung

“Vertraulichkeitscode” (im CDA das Element ClinicalDocument/confidentialityCode) bezeichnet die Vertraulichkeitsstufe dieses Dokuments.

Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden. Die Information des Vertraulichkeitscodes im Dokument selbst, dient nur der reinen Information und hat keine technischen Konsequenzen.

Da Dokumente nach der Vidierung weder technisch noch legistisch geändert werden dürfen, kann der Vertraulichkeitscode keine konkreten Zugriffsrechte auf das Dokument regeln, sondern nur auf „Metaebenen“, wie beispielsweise „geltendes Recht XY“ oder weiterführende Verwendungen über das IHE BPPC Profil, verweisen.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-266	Vertraulichkeitscode	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.90009 CD confidentialityCode (2013‑11‑07)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:confidentialityCode

CE

1 … 1

M

(CDc...ode)


	elgagab-dataelement-266	Vertraulichkeitscode	Datensatz

@code

CONF

1 … 1

F

N

@codeSystem

1 … 1

F

2.16.840.1.113883.5.25 (BasicConfidentialityKind)

@displayName

1 … 1

F

normal

7.2.11 Sprachcode des Dokuments („languageCode“)

7.2.11.1 Spezifikation

Id

1.2.40.0.34.11.90010

ref

elgabbr-

Gültigkeit

2013‑11‑07

Status

Aktiv

Versions-Label

Name

CDlanguageCode

Bezeichnung

CD languageCode

Beschreibung

Die Sprache des Dokuments wird in diesem Attribut gemäß IETF (Internet Engineering Task Force), RFC 1766: Tags for the Identification of Languages nach ISO-639-1 (zweibuchstabige Codes für Sprachen, Kleinbuchstaben) und ISO 3166 (hier: zweibuchstabige Ländercodes, Großbuchstaben) festgelegt.

Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben).

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-265	Sprachcode	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:languageCode

CS.LANG

1 … 1

M

Sprachcode des Dokuments.

(CDl...ode)


	elgagab-dataelement-265	Sprachcode	Datensatz

@code

CONF

1 … 1

F

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

Id

1.2.40.0.34.11.90007

ref

elgabbr-

Gültigkeit

2015‑09‑18

Andere Versionen mit dieser Id:

CDsetIdversionNumber vom 2015‑05‑29
CDsetIdversionNumber vom 2013‑11‑07

Status

Aktiv

Versions-Label

Name

CDsetIdversionNumber

Bezeichnung

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

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.90007 SetId VersionNumber (2015‑09‑18)

ref

elgabbr-

Beispiel

Beispiel für die 1.Version eines 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

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

Item

DT

Kard

Konf

Beschreibung

Label

hl7:setId

II

1 … 1

M

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

hl7:versionNumber

INT.NONNEG

1 … 1

M

Versionsnummer des Dokuments.

(CDs...ber)

Beispiel

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

Id

1.2.40.0.34.11.20001

ref

elgabbr-

Gültigkeit

2017‑07‑20

Andere Versionen mit dieser Id:

HeaderRecordTarget vom 2018‑10‑18 14:23:51
HeaderRecordTarget vom 2017‑03‑27
HeaderRecordTarget vom 2013‑10‑08
HeaderRecordTarget vom 2013‑02‑10
HeaderRecordTarget vom 2011‑12‑19

Status

Entwurf

Versions-Label

Name

HeaderRecordTarget

Bezeichnung

HeaderRecordTarget

Beschreibung

Das RecordTarget-Element enthält den Patienten: Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw über deren Gesundheitsdaten im Dokument berichtet wird.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-9	Patient	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90017	Inklusion	Language Communication	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20001 HeaderRecordTarget (2017‑03‑27)

ref

elgabbr-

Beispiel

Vollständiges Beispiel

<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    
    <id root="1.2.40.0.34.99.111.1.2" extension="4711" assigningAuthorityName="Amadeus Spital"/>    
    <id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>    
    <addr use="H">
      <streetName>Musterstraße</streetName>      <houseNumber>13a</houseNumber>      <postalCode>7000</postalCode>      <city>Eisenstadt</city>      <state>Burgenland</state>      <country>AUT</country>    </addr>    
    <telecom value="tel:+43.1.40400" use="H"/>    <telecom value="tel:+43.664.1234567" use="MC"/>    <telecom value="mailto:herbert.mustermann@provider.at"/>    
    <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>      
      <administrativeGenderCode code="M" displayName="Male" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>      
      <birthTime value="19701224"/>      
      <maritalStatusCode code="D" displayName="Divorced" codeSystem="2.16.840.1.113883.5.2"/>      
      <religiousAffiliationCode code="101" displayName="Römisch-Katholisch" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria"/>      
      <guardian>
        
        <addr>
          <streetAddressLine>Kinderdorfstraße 1</streetAddressLine>          <postalCode>2371</postalCode>          <city>Hinterbrühl</city>          <state>Niederösterreich</state>          <country>AUT</country>        </addr>        
        <telecom use="H" value="tel:+43.2236.2928"/>        <telecom use="WP" value="tel:+43.2236.9000"/>        <guardianOrganization>
          
          <name>SOS Kinderdorf Hinterbrühl</name>        </guardianOrganization>      </guardian>      
      <guardian>
        
        <addr>
          <streetAddressLine>Musterstraße 1234</streetAddressLine>          <postalCode>8011</postalCode>          <city>Graz</city>          <state>Steiermark</state>          <country>AUT</country>        </addr>        
        <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>
            <given>Susi</given>            <family>Sorgenvoll</family>          </name>        </guardianPerson>      </guardian>      
      <birthplace>
        <place>
          <addr>Graz</addr>        </place>      </birthplace>    </patient>  </patientRole></recordTarget>

Beispiel

Minimalbeispiel 1

<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    
    <id root="1.2.40.0.34.99.111.1.2" extension="4711"/>    
    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Herbert</given>        <family>Mustermann</family>      </name>      
      <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>      
      <birthTime value="19701224"/>    </patient>  </patientRole></recordTarget>

Beispiel

Minimalbeispiel 2

<recordTarget>
  <patientRole>
    
    <id root="1.2.40.0.34.99.111.1.2" extension="4711"/>    
    <patient>
      <name>
        <given>Herbert</given>        <family>Mustermann</family>      </name>      
      <administrativeGenderCode nullFlavor="UNK"/>      
      <birthTime nullFlavor="UNK"/>    </patient>  </patientRole></recordTarget>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:recordTarget

Komponente für die Patientendaten.

(Hea...get)


	elgagab-dataelement-9	Patient	Datensatz

@typeCode

cs

0 … 1

F

RCT

@contextControlCode

cs

0 … 1

F

OP

Beispiel

hl7:patientRole

1 … 1

R

Patientendaten.

(Hea...get)

@classCode

cs

0 … 1

F

PAT

Beispiel

Schematron assert

role

error

test

string-length(hl7:id[1]/@root)>0

Meldung

patientRole id[1] MUSS als lokale Patienten ID vom System vorhanden sein

Schematron assert

role

error

test

hl7:id[2]/@root = '1.2.40.0.10.1.4.3.1' or hl7:id[2]/@nullFlavor='NI' or hl7:id[2]/@nullFlavor='UNK'

Meldung

patientRole id[2] MUSS Sozialversicherungsnummer des Patienten sein (1.2.40.0.10.1.4.3.1) oder @nullFlavor 'NI' oder 'UNK' ist angegeben

hl7:id

II

2 … *

R

id[1] Identifikation des Patienten im lokalen System.
id[2]

Sozialversicherungsnummer des Patienten
Zugelassene nullFlavor:

NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …)
UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt

id[3] Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit)

(Hea...get)

Beispiel

lokale Patienten ID vom System, notwendig für XDS

Beispiel

Patienten SV Nummer

Beispiel

bPK-GH des Patienten: Bereichskürzel + bPK (Base64,28 Zeichen)

hl7:addr

AD

0 … 1

Adresse des Patienten.

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

(Hea...get)

hl7:streetAddressLine

0 … 1

(Hea...get)

hl7:streetName

0 … 1

(Hea...get)

hl7:houseNumber

0 … 1

(Hea...get)

Schematron assert

role

error

test

hl7:streetAddressLine or (hl7:streetName and hl7:houseNumber)

Meldung

Granularitätsstufen Adresse beachten: streetAddressLine oder streetName+houseNumber

hl7:postalCode

1 … 1

M

(Hea...get)

hl7:city

1 … 1

M

(Hea...get)

hl7:state

0 … 1

C

(Hea...get)

hl7:country

1 … 1

M

(Hea...get)

hl7:additionalLocator

0 … 1

(Hea...get)

hl7:telecom

TEL.AT

0 … *

Kontaktdaten des Patienten.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

(Hea...get)

hl7:patient

0 … 1

(Hea...get)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name des Patienten.

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...get)

hl7:prefix

0 … *

(Hea...get)

hl7:given

1 … *

M

(Hea...get)

hl7:family

1 … *

M

(Hea...get)

hl7:suffix

0 … *

(Hea...get)

hl7:administrativeGenderCode

CE

1 … 1

R

Codierung des Geschlechts des Patienten.

Zugelassene nullFlavor: UNK

Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)

hl7:birthTime

TS.DATE.MIN

1 … 1

R

Geburtsdatum des Patienten.

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

Zugelassene nullFlavor: UNK

(Hea...get)

hl7:maritalStatusCode

CE

0 … 1

Codierung des Familienstands des Patienten.

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC)

hl7:religiousAffiliationCode

CE

0 … 1

Codierung des Religionsbekenntnisses des Patienten.

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC)

hl7:raceCode

NP

Rasse des Patienten

Darf nicht verwendet werden!

(Hea...get)

hl7:ethnicGroupCode

NP

Ethnische Zugehörigkeit des Patienten.
Darf nicht verwendet werden!

(Hea...get)

hl7:guardian

0 … *

Gesetzlicher Vertreter: Erwachsenenvertreter, Vormund, Obsorgeberechtigter

(Hea...get)

hl7:addr

AD

0 … 1

Die Adresse des gesetzlichen Vertreters oder der Organisation.

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

(Hea...get)

hl7:telecom

TEL.AT

0 … *

Beliebig viele Kontaktdatendes gesetzlichen Vertreters oder der Organisation.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

(Hea...get)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:guardianPerson
hl7:guardianOrganization

hl7:guardianPerson

… 1

Name des des gesetzlichen Vertreters (Person).

(Hea...get)

hl7:name

PN

1 … 1

M

Name der Person.

(Hea...get)

hl7:guardianOrganization

… 1

Name des des gesetzlichen Vertreters (Organisation).

(Hea...get)

hl7:name

ON

1 … 1

M

Name der Organisation.

(Hea...get)

hl7:birthplace

0 … 1

Geburtsort des Patienten.

(Hea...get)

hl7:place

1 … 1

M

(Hea...get)

hl7:addr

AD

1 … 1

M

Die Adresse des Geburtsorts.

Grundsätzlich sind die Vorgaben gemäß „Adress-Elemente“ für Granularitätsstufe 1 zu befolgen.

Granularitätsstufe 2 oder 3 ist auch bei EIS Enhanced und Full Support nicht erforderlich.

(Hea...get)

Eingefügt

von 1.2.40.0.34.11.90017 Language Communication (DYNAMIC)

hl7:languageCommunication

0 … *

Komponente zur Angabe der Sprachfähigkeiten des Patienten.

(Hea...get)

hl7:languageCode

CS

0 … 1

Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.173 ELGA_HumanLanguage (DYNAMIC)

hl7:modeCode

CE

0 … 1

Ausdrucksform der Sprache.
@codeSystem Fester Wert: 2.16.840.1.113883.5.60

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)

hl7:proficiencyLevelCode

CE

0 … 1

Grad der Sprachkenntnis in der Sprache.
@codeSystem Fester Wert: 2.16.840.1.113883.5.61

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC)

hl7:preferenceInd

BL

0 … 1

Kennzeichnung, 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

Id

1.2.40.0.34.11.20002

ref

elgabbr-

Gültigkeit

2015‑05‑09

Andere Versionen mit dieser Id:

HeaderAuthor vom 2018‑10‑18 14:32:49
HeaderAuthor vom 2013‑02‑10
HeaderAuthor vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderAuthor

Bezeichnung

HeaderAuthor

Beschreibung

Der Dokumentersteller („author“) ist in der Regel die „das Dokument verfassende Person“ oder ein „datenerstellendes Gerät“. Damit ist diejenige Person oder das Gerät gemeint, welche das Dokument „inhaltlich“ verfasst (z.B.: diktiert). Die das Dokument „schreibende“ Person (z.B. Schreibkraft, Stationsschwester, …) wird in CDA in einem eigenen Element (dataEnterer) abgebildet (siehe „Personen der Dateneingabe („dataEnterer“)“).

Es kann auch mehr als ein Dokumentersteller angegeben werden (mehrere author-Elemente).

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-48	Autor	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20002 HeaderAuthor (2015‑05‑09)

ref

elgabbr-

Beispiel

Strukturbeispiel für eine Person als „author“

<author typeCode="AUT" contextControlCode="OP">
  
  <functionCode code="OA" displayName="Diensthabender Oberarzt" codeSystem="1.2.40.0.34.99.111.2.1" codeSystemName="Amadeus Spital Funktionen"/>  
  <time value="20081224082015+0100"/>  <assignedAuthor classCode="ASSIGNED">
    
    <id root="1.2.40.0.34.99.111.1.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>    
    <code code="107" displayName="Fachärztin/Facharzt für Chirurgie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>    
    <telecom value="tel:+43.1.40400"/>    <telecom value="mailto:herbert.mustermann@organization.at"/>    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      
      <name>
        <prefix qualifier="AC">Univ.-Prof. Dr.</prefix>        <given>Isabella</given>        <family>Stern</family>      </name>    </assignedPerson>    
    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      
      <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      
      <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>
  
  <time value="20081224082015+0100"/>  <assignedAuthor>
    
    <id root="86562fe5-b509-4ce9-b976-176fd376e477"/>    
    <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>Amadeus Spital, 1. Chirurgische Abteilung</name>      
      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>    </representedOrganization>  </assignedAuthor></author>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:author

Verfasser des Dokuments.

(Hea...hor)


	elgagab-dataelement-48	Autor	Datensatz

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

0 … 1

Funktionscode des Verfassers des Dokuments

z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …

Eigene Codes und Bezeichnungen können verwendet werden.

Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

(Hea...hor)

hl7:time

TS.AT.TZ

1 … 1

R

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

Zugelassene nullFlavor: UNK

(Hea...hor)

hl7:assignedAuthor

1 … 1

R

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

(Hea...hor)

@classCode

cs

0 … 1

F

ASSIGNED

Beispiel

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software.ODERIdentifikation des/der datenerstellenden Gerätes/Software.

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

Zugelassene nullFlavor:

NI … Person hat keine ID / Gerät/Software hat keine ID
UNK … Person hat eine ID, diese ist jedoch unbekannt /Gerät/Software hat eine ID, diese ist jedoch unbekannt

(Hea...hor)

hl7:code

CE

0 … 1

Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung)z.B: „Facharzt/Fachärzting für Gynäkologie“,

Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.
Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

(Hea...hor)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)

hl7:telecom

TEL.AT

0 … *

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

(Hea...hor)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

… 1

Personendaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

(Hea...hor)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...hor)

hl7:assignedAuthoringDevice

… 1

(Hea...hor)

@classCode

cs

0 … 1

F

DEV

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:manufacturerModelName

SC

1 … 1

R

Hersteller und Modellbezeichnung des datenerstellenden Gerätes.

(Hea...hor)

hl7:softwareName

SC

1 … 1

R

Bezeichnung (und ggf Version) der datenerstellenden Software.

(Hea...hor)

hl7:representedOrganization

1 … 1

M

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

(Hea...hor)

Beispiel

hl7:id

II

1 … *

M

Die OID der Organisation aus dem GDA-Index.

Hinweise:
id[1] MUSS aus dem GDA-I stammen, weitere id-Elemente können hinzugefügt werden.

Für den Namen von größere Organisationen SOLL auch die Abteilung angegeben werden., z.B.: „Amadeus Spital, Chirurgische Abteilung“

Für die Adresse MUSS mindestens Granularitätsstufe 2 angewendet werden.

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

(Hea...hor)

hl7:name

ON

1 … 1

M

(Hea...hor)

hl7:telecom

TEL.AT

0 … *

(Hea...hor)

hl7:addr

AD

0 … 1

(Hea...hor)

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

Id

1.2.40.0.34.11.20003

ref

elgabbr-

Gültigkeit

2013‑02‑10

Andere Versionen mit dieser Id:

HeaderDataEnterer vom 2011‑12‑19

Status

Entwurf

Versions-Label

Name

HeaderDataEnterer

Bezeichnung

HeaderDataEnterer

Beschreibung

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

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-65	Schreibkraft	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90003	Inklusion	AssignedEntityElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20003 HeaderDataEnterer (2013‑02‑10)

ref

elgabbr-

Beispiel

<dataEnterer>
  
  <time value="20081224082015+0100"/>  <assignedEntity>
    
    <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>    <telecom value="tel:+43.1.40400.4711"/>    <telecom value="mailto:eva.musterfrau@amadeusspital.at"/>    <assignedPerson>
      <name>DiplKrSr. Eva Musterfrau</name>    </assignedPerson>  </assignedEntity></dataEnterer>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:dataEnterer

Person der Dateneingabe.

(Hea...rer)


	elgagab-dataelement-65	Schreibkraft	Datensatz

hl7:time

TS.AT.TZ

0 … 1

Der Zeitpunkt an dem das Dokument geschrieben wurde.

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

(Hea...rer)

hl7:assignedEntity

1 … 1

R

Personendaten der schreibenden Person

Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen.

(Hea...rer)

Eingefügt

von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...rer)

hl7:addr

AD

0 … 1

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...rer)

hl7:telecom

TEL.AT

0 … *

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...rer)

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

(Hea...rer)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...rer)

hl7:representedOrganization

0 … 1

Organistationsdaten der validierenden Person.

(Hea...rer)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...rer)

hl7:name

ON

1 … 1

M

(Hea...rer)

hl7:telecom

TEL.AT

0 … *

(Hea...rer)

hl7:addr

AD

0 … 1

(Hea...rer)

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

Id

1.2.40.0.34.11.20004

ref

elgabbr-

Gültigkeit

2015‑05‑28

Andere Versionen mit dieser Id:

HeaderCustodian vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderCustodian

Bezeichnung

HeaderCustodian

Beschreibung

Der „Verwahrer des Dokuments“ ist diejenige Organisation, die „für die Verwahrung/Verwaltung des Dokuments verantwortlich ist“.

Beispiele:

Das erstellende Krankenhaus ist selbst der Verwalter des Dokuments.

Der übergeordnete Krankenhausträger ist der Verwalter des Dokuments.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-73	Verwahrer	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.20004 HeaderCustodian (2015‑05‑28)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.20004 HeaderCustodian (2011‑12‑19)

ref

elgabbr-

Beispiel

Vollständiges Beispiel

<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <id root="1.2.3.999" extension="--example only--" assigningAuthorityName="GDA-Index"/>      <name>Amadeus Spital</name>      <telecom value="tel:+43.(0)50.55460-0"/>      <addr>
        <streetName>Hafenstraße</streetName>        <houseNumber>47-51</houseNumber>        <postalCode>4020</postalCode>        <city>Linz</city>        <state>Oberösterreich</state>        <country>AUT</country>      </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>

Beispiel

Minimalbeispiel

<custodian>
  <assignedCustodian>
    <representedCustodianOrganization>
      <id root="1.2.3.999" extension="--example only--"/>      <name>Amadeus Spital</name>      <addr>
        <streetAddressLine>Hafenstraße
47-51</streetAddressLine>        <postalCode>4020</postalCode>        <city>Linz</city>        <country>AUT</country>      </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:custodian

Verwahrer des Dokuments.

(Hea...ian)


	elgagab-dataelement-73	Verwahrer	Datensatz

@typeCode

cs

0 … 1

F

CST

hl7:assignedCustodian

1 … 1

M

(Hea...ian)

@classCode

cs

0 … 1

F

ASSIGNED

hl7:representedCustodianOrganization

1 … 1

M

(Hea...ian)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … 1

R

Identifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben.

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

Zugelassene nullFlavor:

NI … Organisation hat keine ID aus dem GDA-Index
UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt

(Hea...ian)

hl7:name

1 … 1

M

Name des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen.

(Hea...ian)

hl7:telecom

TEL.AT

0 … 1

Kontaktdaten des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.

(Hea...ian)

hl7:addr

AD

1 … 1

M

Adresse des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

(Hea...ian)

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

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

Id

1.2.40.0.34.11.20005

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Entwurf

Versions-Label

Name

HeaderInformationRecipient

Bezeichnung

HeaderInformationRecipient

Beschreibung

Die beabsichtigten Empfänger des Dokuments können in der Klasse intendedRecipient näher angegeben werden. Hierbei ist zu beachten, dass es sich um die unmittelbar bei der Erstellung des Dokuments festgelegten bzw. bekannten Empfänger handelt.

Beispiel: Bei der Erstellung der Dokumentation ist beispielsweise schon bekannt, dass man das Dokument primär an den Hausarzt und ggf. als Kopie an einen mitbehandelnden Kollegen senden wird. In diesem Fall sollten genau diese beiden Empfänger angegeben werden.

Empfohlene Information für einen Empfänger ist die ID aus dem GDA-Index, sein Name in möglichst hoher Granularität und die Organisation, der er angehört in möglichst hoher Granularität. Aufgrund der gängigen Praxis kann als minimale Information für den Empfänger der unstrukturierte Name angegeben werden.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-259	Empfänger	Datensatz

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20005 HeaderInformationRecipient (2011‑12‑19)

ref

elgabbr-

Beispiel

Beabsichtigter Empfänger ist eine bekannte Person

<informationRecipient typeCode="PRCP">
  <intendedRecipient>
    
    <id nullFlavor="UNK"/>    
    <informationRecipient>
      <name>
        <prefix qualifier="AC"> Dr.</prefix>        <given>Robert</given>        <family>Empfänger</family>      </name>    </informationRecipient>    
    <receivedOrganization>
      
      <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>    </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>
    
    <id nullFlavor="NI"/>    
    <informationRecipient>
      <name>Ergeht an den Patienten Dr. Herbert Mustermann</name>    </informationRecipient>  </intendedRecipient></informationRecipient>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:informationRecipient

Beabsichtiger Empfänger des Dokuments.

(Hea...ent)


	elgagab-dataelement-259	Empfänger	Datensatz

@typeCode

cs

0 … 1

Typ des Informationsempfängers.

Bsp: PRCP „Primärer Empfänger“

Wird das Attribut weggelassen, gilt der Empfänger als primärer Empfänger.

CONF

Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.29 ELGA_InformationRecipientType (DYNAMIC)

hl7:intendedRecipient

1 … 1

M

(Hea...ent)

hl7:id

II

1 … *

R

Identifikation des beabsichtigten Empfängers (Person).Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

Zugelassene nullFlavor:

NI … Person hat keine ID
UNK ... Person hat eine ID, diese ist jedoch unbekannt

(Hea...ent)

Beispiel

hl7:informationRecipient

1 … 1

M

Personendaten des beabsichtigten Empfängers.
Grundsätzlich sind die Vorgaben gemäß Kapitel „Personen-Element“ zu befolgen.

(Hea...ent)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...ent)

hl7:receivedOrganization

0 … 1

Organisation, der der beabsichtigte Empfänger angehört.z.B.: „Ordination des empfangenden Arztes“
Grundsätzlich sind die Vorgaben gemäß Kapitel „Organisations-Element“ zu befolgen.

(Hea...ent)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...ent)

hl7:name

ON

1 … 1

M

(Hea...ent)

hl7:telecom

TEL.AT

0 … *

(Hea...ent)

hl7:addr

AD

0 … 1

(Hea...ent)

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

Id

1.2.40.0.34.11.20006

ref

elgabbr-

Gültigkeit

2011‑12‑19

Andere Versionen mit dieser Id:

HeaderLegalAuthenticator vom 2018‑10‑18 14:34:23

Status

Entwurf

Versions-Label

Name

HeaderLegalAuthenticator

Bezeichnung

HeaderLegalAuthenticator

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.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 2 Konzepte

Id	Name	Datensatz
elgagab-dataelement-79	Rechtlicher Unterzeichner	Datensatz
elgagab-dataelement-87	Rechtlicher Unterzeichner	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90003	Inklusion	AssignedEntityElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20006 HeaderLegalAuthenticator (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<legalAuthenticator>
  
  <time value="20130324082015+0100"/>  
  <signatureCode code="S"/>  
  <assignedEntity>
    
    <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>    
    <telecom use="WP" value="tel:+43.6138.3453446.2222"/>    
    <assignedPerson>
      
      <name>
        <prefix>Univ.-Prof.Dr.</prefix>        <given>Sigrid</given>        <family>Kollmann</family>      </name>    </assignedPerson>    
    <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>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:legalAuthenticator

Rechtlicher Unterzeichner.

(Hea...tor)


elgagab-dataelement-79	Rechtlicher Unterzeichner	Datensatz
elgagab-dataelement-87	Rechtlicher Unterzeichner	Datensatz

@typeCode

cs

0 … 1

F

LA

hl7:time

TS.DATE.MIN

1 … 1

R

Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.

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

Zugelassene nullFlavor: UNK

(Hea...tor)

hl7:signatureCode

CS

1 … 1

M

Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde.

(Hea...tor)

@code

CONF

1 … 1

F

S

hl7:assignedEntity

1 … 1

M

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)

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...tor)

hl7:addr

AD

0 … 1

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...tor)

hl7:telecom

TEL.AT

0 … *

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...tor)

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

(Hea...tor)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...tor)

hl7:representedOrganization

0 … 1

Organistationsdaten der validierenden Person.

(Hea...tor)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...tor)

hl7:name

ON

1 … 1

M

(Hea...tor)

hl7:telecom

TEL.AT

0 … *

(Hea...tor)

hl7:addr

AD

0 … 1

(Hea...tor)

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

Id

1.2.40.0.34.11.20007

ref

elgabbr-

Gültigkeit

2011‑12‑19

Andere Versionen mit dieser Id:

HeaderAuthenticator vom 2018‑10‑18 14:33:54

Status

Entwurf

Versions-Label

Name

HeaderAuthenticator

Bezeichnung

HeaderAuthenticator

Beschreibung

Dokumente können neben dem verpflichtenden legalAuthenticator („rechtlichen Unterzeichner“, Hauptunterzeichner) auch beliebig viele weitere Mitunterzeichner beinhalten.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-86	Weitere Unterzeichner	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90003	Inklusion	AssignedEntityElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20007 HeaderAuthenticator (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<authenticator>
  
  <time value="20130324081915+0100"/>  
  <signatureCode code="S"/>  
  <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>
        <prefix>Dr.</prefix>        <given>Walter</given>        <family>Hummel</family>      </name>    </assignedPerson>    
    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <name>Amadeus Spital - Chirurgische Abteilung</name>      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="fax:+43.6138.3453446.4674"/>      <telecom value="mailto:info@amadeusspital.at"/>      <telecom value="http://www.amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>    </representedOrganization>  </assignedEntity></authenticator>

Beispiel

Strukturbeispiel Laborbefund

<authenticator>
  <templateId root="1.3.6.1.4.1.19376.1.3.3.1.5"/>  <time value="20121201155300+0100"/>  <signatureCode code="S"/>  <assignedEntity>
    <id nullFlavor="NA"/>    <addr nullFlavor="NA"/>    <telecom value="tel: +43.1.12345678"/>    <assignedPerson>
      <name>
        <prefix qualifier="AC">Dr.</prefix>        <given>Otto</given>        <family>Rotadilav</family>      </name>    </assignedPerson>    <representedOrganization>
      <id root="1.2.40.0.34.3.1.999" assigningAuthorityName="EHSREG"/>      <name>Zentrallabor</name>      <telecom value="tel: +43.1.12345678"/>      <addr>
        <streetAddressLine>Laborplatz
1</streetAddressLine>        <city>Wien</city>        <postalCode>1200</postalCode>        <country>AUT</country>      </addr>    </representedOrganization>  </assignedEntity></authenticator>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:authenticator

Weitere Unterzeichner.

(Hea...tor)


	elgagab-dataelement-86	Weitere Unterzeichner	Datensatz

@typeCode

cs

0 … 1

F

AUTHEN

hl7:time

TS.DATE.MIN

1 … 1

R

Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.

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

Zugelassene nullFlavor: UNK

(Hea...tor)

hl7:signatureCode

CS

1 … 1

M

(Hea...tor)

@code

CONF

1 … 1

F

S

hl7:assignedEntity

1 … 1

M

Personendaten des weiteren Unterzeichners.Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen.

(Hea...tor)

Eingefügt

von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...tor)

hl7:addr

AD

0 … 1

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...tor)

hl7:telecom

TEL.AT

0 … *

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...tor)

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

(Hea...tor)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...tor)

hl7:representedOrganization

0 … 1

Organistationsdaten der validierenden Person.

(Hea...tor)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...tor)

hl7:name

ON

1 … 1

M

(Hea...tor)

hl7:telecom

TEL.AT

0 … *

(Hea...tor)

hl7:addr

AD

0 … 1

(Hea...tor)

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

Id

1.2.40.0.34.11.1.1.1

ref

elgabbr-

Gültigkeit

2014‑03‑25

Andere Versionen mit dieser Id:

HeaderParticipantAnsprechpartner vom 2013‑10‑16

Status

Aktiv

Versions-Label

Name

HeaderParticipantAnsprechpartner

Bezeichnung

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

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: Template 1.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">
    
    <telecom use="WP" value="tel:+43.1.3453446.1"/>    <associatedPerson>
      
      <name>
        <prefix qualifier="AC">Dr.</prefix>        <given>Walter</given>        <family>Hummel</family>      </name>      
      <name>Sekretariat Labor</name>    </associatedPerson>    
    <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

Item

DT

Kard

Konf

Beschreibung

Label

hl7:participant

Beteiligter (Fachlicher Ansprechpartner).

(Hea...ner)

wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.1']]

@typeCode

cs

1 … 1

F

CALLBCK

hl7:templateId

II

1 … 1

M

(Hea...ner)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.1.1

hl7:time

NP

(Hea...ner)

hl7:associatedEntity

1 … 1

M

(Hea...ner)

@classCode

cs

1 … 1

F

PROV

hl7:addr

AD

0 … 1

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

(Hea...ner)

hl7:telecom

TEL.AT

1 … *

M

Beliebig viele Kontaktdaten des Beteiligten.

Es MUSS mindestens eine Telefon-Nummer angegeben werden

(Hea...ner)

hl7:associatedPerson

1 … 1

M

Beteiligte Person.

(Hea...ner)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...ner)

hl7:scopingOrganization

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)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...ner)

hl7:name

ON

1 … 1

M

(Hea...ner)

hl7:telecom

TEL.AT

0 … *

(Hea...ner)

hl7:addr

AD

0 … 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

Id

1.2.40.0.34.11.1.1.2

ref

elgabbr-

Gültigkeit

2013‑10‑16

Status

Aktiv

Versions-Label

Name

HeaderParticipantRefArzt

Bezeichnung

HeaderParticipant Ref Arzt

Beschreibung

Einweisender/Zuweisender Arzt/Überweisender Arzt

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-214	Zuweisender	Datensatz

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.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/>    
    <associatedPerson>
      <name>
        <prefix qualifier="AC">Univ.-Prof. Dr.</prefix>        <given>Herbert</given>        <family>Empfänger</family>      </name>    </associatedPerson>    
    <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>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:participant

Beteiligter.

(Hea...rzt)

wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.2']]


	elgagab-dataelement-214	Zuweisender	Datensatz

@typeCode

cs

1 … 1

F

REF

Einweisender/Zuweisender/Überweisender Arzt.

hl7:templateId

II

1 … 1

M

(Hea...rzt)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.1.2

Template ID für Einweisender/Zuweisender/Überweisender Arzt.

hl7:associatedEntity

1 … 1

M

Beschreibung der Entität.

(Hea...rzt)

@classCode

cs

1 … 1

F

PROV

Gesundheitsdienstanbieter.

hl7:id

II

0 … *

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)

hl7:addr

AD

0 … 1

Adresse des Beteiligten.

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

(Hea...rzt)

hl7:telecom

TEL.AT

0 … *

Beliebig viele Kontaktdaten des Beteiligten.

(Hea...rzt)

hl7:associatedPerson

1 … 1

R

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)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...rzt)

hl7:scopingOrganization

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)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...rzt)

hl7:name

ON

1 … 1

M

(Hea...rzt)

hl7:telecom

TEL.AT

0 … *

(Hea...rzt)

hl7:addr

AD

0 … 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

Id

1.2.40.0.34.11.1.1.3

ref

elgabbr-

Gültigkeit

2013‑10‑16

Status

Aktiv

Versions-Label

Name

HeaderParticipantHausarzt

Bezeichnung

HeaderParticipant Hausarzt

Beschreibung

Hausarzt

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-100	Hausarzt	Datensatz

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.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">
    
    <id root="1.2.3.999" extension="--example only--"/>    <addr/>    <telecom/>    
    <associatedPerson>
      <name>
        <prefix qualifier="AC">Dr.</prefix>        <given>Walter</given>        <family>Mustermann</family>      </name>    </associatedPerson>    
    <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>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:participant

Beteiligter (Hausarzt).

(Hea...rzt)

wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.3']]


	elgagab-dataelement-100	Hausarzt	Datensatz

@typeCode

cs

1 … 1

F

IND

In indirektem Bezug.

hl7:templateId

II

1 … 1

M

Template ID zur Identifikation dieser Art von Beteiligten.

(Hea...rzt)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.1.3

hl7:functionCode

CE

1 … *

M

Hausarzt.

(Hea...rzt)

@code

CONF

1 … 1

F

PCP

@codeSystem

1 … 1

F

2.16.840.1.113883.5.88 (Participation Function)

hl7:associatedEntity

1 … 1

M

Beschreibung der Entität.

(Hea...rzt)

@classCode

cs

1 … 1

F

PROV

Gesundheitsdienstanbieter.

hl7:id

II

0 … *

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)

hl7:addr

AD

0 … 1

Adresse des Beteiligten.

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

(Hea...rzt)

hl7:telecom

TEL.AT

0 … *

Beliebig viele Kontaktdaten des Beteiligten.

(Hea...rzt)

hl7:associatedPerson

1 … 1

M

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)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...rzt)

hl7:scopingOrganization

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)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...rzt)

hl7:name

ON

1 … 1

M

(Hea...rzt)

hl7:telecom

TEL.AT

0 … *

(Hea...rzt)

hl7:addr

AD

0 … 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

Id

1.2.40.0.34.11.1.1.4

ref

elgabbr-

Gültigkeit

2013‑11‑13

Andere Versionen mit dieser Id:

HeaderParticipantNotfallkontakt vom 2013‑10‑16

Status

Aktiv

Versions-Label

Name

HeaderParticipantNotfallkontakt

Bezeichnung

HeaderParticipant Notfallkontakt

Beschreibung

Notfall-Kontakt / Auskunftsberechtigte Person

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-105	Notfall-Kontakt	Datensatz

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.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">
    
    <code code="DAU" displayName="Natural daughter" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7:RoleCode"/>    
    <addr>Heimstrasse 1, 1220 Wien</addr>    
    <telecom value="tel:0660.1234567"/>    <associatedPerson>
      
      <name>Julia Tochter</name>    </associatedPerson>    
    <scopingOrganization>
      <name>Mustermann Installationen GmbH</name>    </scopingOrganization>  </associatedEntity></participant>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:participant

Beteiligter (Notfallkontakt / Auskunftsberechtigte Person).

(Hea...akt)

wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.4']]


	elgagab-dataelement-105	Notfall-Kontakt	Datensatz

@typeCode

cs

1 … 1

F

IND

hl7:templateId

II

1 … 1

M

(Hea...akt)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.1.4

hl7:time

IVL_TS

0 … 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)

hl7:associatedEntity

1 … 1

M

Beschreibung der Entität.

(Hea...akt)

@classCode

cs

1 … 1

F

ECON

hl7:code

CE

0 … 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)

hl7:addr

AD

0 … 1

Adresse des Beteiligten.

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

(Hea...akt)

hl7:telecom

TEL.AT

0 … *

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)

hl7:associatedPerson

1 … 1

M

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)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...akt)

hl7:scopingOrganization

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)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...akt)

hl7:name

ON

1 … 1

M

(Hea...akt)

hl7:telecom

TEL.AT

0 … *

(Hea...akt)

hl7:addr

AD

0 … 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

Id

1.2.40.0.34.11.1.1.5

ref

elgabbr-

Gültigkeit

2016‑07‑21

Andere Versionen mit dieser Id:

HeaderParticipantAngehoerige vom 2013‑11‑13
HeaderParticipantAngehoerige vom 2013‑10‑16

Status

Aktiv

Versions-Label

Name

HeaderParticipantAngehoerige

Bezeichnung

HeaderParticipant Angehörige

Beschreibung

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.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: Template 1.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">
    
    <code code="MTH" displayName="mother" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7: RoleCode"/>    
    <addr/>    <telecom value="tel:0660.1234567"/>    <associatedPerson>
      <name>Herta Mutter</name>    </associatedPerson>    <scopingOrganization/>  </associatedEntity></participant>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:participant

Beteiligter (Angehöriger).

(Hea...ige)

wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.5']]

@typeCode

cs

1 … 1

F

IND

hl7:templateId

II

1 … 1

M

(Hea...ige)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.1.5

hl7:associatedEntity

1 … 1

M

Beschreibung der Entität.

(Hea...ige)

@classCode

cs

1 … 1

F

PRS

hl7:code

CE

1 … 1

M

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)

hl7:addr

AD

0 … 1

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

(Hea...ige)

hl7:telecom

TEL.AT

0 … *

Beliebig viele Kontaktdaten des Beteiligten.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

(Hea...ige)

hl7:associatedPerson

1 … 1

M

Beteiligte 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)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...ige)

hl7:scopingOrganization

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)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...ige)

hl7:name

ON

1 … 1

M

(Hea...ige)

hl7:telecom

TEL.AT

0 … *

(Hea...ige)

hl7:addr

AD

0 … 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

Id

1.2.40.0.34.11.1.1.6

ref

elgabbr-

Gültigkeit

2015‑11‑25

Andere Versionen mit dieser Id:

HeaderParticipantVersicherung vom 2013‑10‑16

Status

Aktiv

Versions-Label

Name

HeaderParticipantVersicherung

Bezeichnung

HeaderParticipant Versicherung

Beschreibung

Versicherter/Versicherung

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-119	Versicherter/Versicherung	Datensatz

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.1.6 HeaderParticipant Versicherung (2015‑11‑25)

ref

elgabbr-

Beispiel

Patient ist selbst der Versicherungsnehmer

<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

<participant typeCode="HLD">
  <templateId root="1.2.40.0.34.11.1.1.6"/>  
  <time>
    <low value="20020101"/>    <high value="20081231"/>  </time>  <associatedEntity classCode="POLHOLD">
    
    <id root="1.2.40.0.10.1.4.3.1" extension="123424121970" assigningAuthorityName="Österreichische Sozialversicherung"/>    
    <code code="FAMDEP" displayName="family dependent" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7:RoleCode"/>    
    <addr>
      <streetName>Musterstrasse</streetName>      <houseNumber>47-51</houseNumber>      <postalCode>8010</postalCode>      <city>Graz</city>      <country>AUT</country>    </addr>    
    <telecom value="tel:+43.(0)50.55460-0"/>    
    <associatedPerson>
      <name>
        <given>Herbert</given>        <family>Vater</family>      </name>    </associatedPerson>    
    <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>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:participant

Beteiligter (Versicherter/Versicherung).

(Hea...ung)

wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.6']]


	elgagab-dataelement-119	Versicherter/Versicherung	Datensatz

@typeCode

cs

1 … 1

F

HLD

hl7:templateId

II

1 … 1

M

(Hea...ung)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.1.6

hl7:time

IVL_TS

0 … 1

Gültigkeitszeitraum der Versicherungspolizze.

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

(Hea...ung)

hl7:associatedEntity

1 … 1

M

Beschreibung der Entität.

(Hea...ung)

@classCode

cs

1 … 1

F

POLHOLD

hl7:id

II

0 … *

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

Zugelassene nullFlavor:

NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …)
UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt

(Hea...ung)

hl7:code

CE

0 … 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)

hl7:addr

AD

0 … 1

Adresse des Beteiligten.

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

(Hea...ung)

hl7:telecom

TEL.AT

0 … *

Beliebig viele Kontaktdaten des Beteiligten.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

(Hea...ung)

hl7:associatedPerson

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)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...ung)

Schematron assert

role

error

test

hl7:code/@code!='FAMDEP' or count(hl7:associatedPerson)=1

Meldung

Wenn das Versicherungsverhältnis "familienversichert" ist, dann muss eine associatedPerson angegeben sein

hl7:scopingOrganization

1 … 1

R

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)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...ung)

hl7:name

ON

1 … 1

M

(Hea...ung)

hl7:telecom

TEL.AT

0 … *

(Hea...ung)

hl7:addr

AD

0 … 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

Id

1.2.40.0.34.11.1.1.7

ref

elgabbr-

Gültigkeit

2013‑10‑16

Status

Aktiv

Versions-Label

Name

HeaderParticipantBetreuorg

Bezeichnung

HeaderParticipant Betreuungsorganisation

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-251	Betreuende Organisation	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: 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">
    
    <scopingOrganization>
      
      <name>Altenpflegeheim Sorgenfrei</name>      
      <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"/>      
      <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>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:participant

Beteiligter (Betreuende Organisation).

(Hea...org)

wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.7']]


	elgagab-dataelement-251	Betreuende Organisation	Datensatz

@typeCode

cs

1 … 1

F

IND

hl7:templateId

II

1 … 1

M

(Hea...org)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.1.7

hl7:associatedEntity

1 … 1

M

Beschreibung der Entität.

(Hea...org)

@classCode

cs

1 … 1

F

CAREGIVER

hl7:scopingOrganization

1 … 1

M

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)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...org)

hl7:name

ON

1 … 1

M

(Hea...org)

hl7:telecom

TEL.AT

0 … *

(Hea...org)

hl7:addr

AD

0 … 1

(Hea...org)

7.3.8.9 Weitere Behandler

Über dieses Element können weitere an der medizinischen Behandlung maßgeblich beteiligte Personen angegeben werden. Das können Ärzte aus der gleichen oder einer anderen Abteilung sein, weiters niedergelassene behandelnde Ärzte (z.B. der behandelnde Internist oder Kinderarzt) aber auch nicht-ärztliche Behandler, wie z.B. Psychologen.

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, welche weitere Behandler sie veröffentlicht.

Diese Beteiligten-Art wird durch folgende Kombination angegeben:

Element	Wert	Beschreibung	Bedeutung
@typeCode	CON	Consultant	Weitere Behandler
templateId	1.2.40.0.34.11.1.1.8	-	Template ID zur Identifikation dieser Art von Beteiligten
functionCode	Wert aus Value Set ELGA_Funktionscodes		Angabe der Funktion bzw. der Fachrichtung des Behandlers
@classCode	PROV	Healthcare provider	Gesundheitsdienstanbieter

7.3.8.9.1 Spezifikation

Id

1.2.40.0.34.11.1.1.8

ref

elgabbr-

Gültigkeit

2017‑02‑20

Status

Aktiv

Versions-Label

Name

HeaderParticipantConsultant

Bezeichnung

HeaderParticipant Weitere Behandler

Beschreibung

Über dieses Element können weitere an der medizinischen Behandlung maßgeblich beteiligte Personen angegeben werden. Das können Ärzte aus der gleichen oder einer anderen Abteilung sein, weiters niedergelassene behandelnde Ärzte (z.B. der behandelnde Internist oder Kinderarzt) aber auch nicht-ärztliche Behandler, wie z.B. Psychologen.
Bei Verwendung sollen möglichst präzise Kontaktdaten angegeben werden. Es obliegt der dokumenterzeugenden Organisation zu entscheiden, welche weitere Behandler sie veröffentlicht.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-136	Weitere Behandler	Datensatz

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC
1.2.40.0.34.11.90002	Inklusion	OrganizationElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.1.8 HeaderParticipant Weitere Behandler (2017‑02‑20)

ref

elgabbr-

Beispiel

Strukturbeispiel Weitere Behandler

<participant typeCode="CON">
  <templateId root="1.2.40.0.34.11.1.1.8"/>  <functionCode code="130" displayName="Facharzt für Neurologie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>  <associatedEntity classCode="PROV">
    
    <telecom value="tel:+43.6138.3453446.1"/>    <telecom value="mailto:robert.betterman@amadeusspital.at"/>    <associatedPerson>
      
      <name>
        <prefix qualifier="AC">Dr.</prefix>        <given>Robert</given>        <family>Betterman</family>      </name>      
      <name>Dr. Robert Betterman</name>    </associatedPerson>  </associatedEntity></participant>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:participant

Beteiligter (Fachlicher Ansprechpartner).

(Hea...ant)

wo [hl7:templateId [@root='1.2.40.0.34.11.1.1.8']]


	elgagab-dataelement-136	Weitere Behandler	Datensatz

@typeCode

cs

1 … 1

F

CON

Weitere Behandler.

hl7:templateId

II

1 … 1

M

(Hea...ant)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.1.8

hl7:functionCode

CE

0 … 1

R

Angabe der Funktion bzw. der Fachrichtung des Behandlers.

z.B: „Facharzt für Neurologie“

Eigene Codes und Bezeichnungen dürfen verwendet werden.

Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

(Hea...ant)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)

hl7:associatedEntity

1 … 1

M

(Hea...ant)

@classCode

cs

1 … 1

F

PROV

Gesundheitsdienstanbieter.

hl7:addr

AD

0 … 1

Adresse des Beteiligten.

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

(Hea...ant)

hl7:telecom

TEL.AT

0 … *

R

Beliebig viele Kontaktdaten des Beteiligten.
Es MUSS mindestens eine Telefon-Nummer angegeben werden.

(Hea...ant)

hl7:associatedPerson

1 … 1

M

Beteiligte Person

Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

(Hea...ant)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...ant)

hl7:scopingOrganization

0 … 1

R

Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation)

Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.

(Hea...ant)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...ant)

hl7:name

ON

1 … 1

M

(Hea...ant)

hl7:telecom

TEL.AT

0 … *

(Hea...ant)

hl7:addr

AD

0 … 1

(Hea...ant)

7.4 Zuweisung und Ordermanagement

7.4.1 Auftrag („inFulfillmentOf“)

Das Element inFulfillmentOf enthält den Bezug zum zugrundeliegenden Auftrag des Auftraggebers. Dies kann zum Beispiel eine Auftrags- oder Anforderungsnummer sein. Das Element erlaubt genau ein order Unterelement.

Auszug aus dem R-MIM:

Abbildung 14: Klassen rund um den Zuweisung und Ordermanagement.

7.4.1.1 Spezifikation

Id

1.2.40.0.34.11.20009

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderInFulfillmentOf

Bezeichnung

HeaderInFulfillmentOf

Beschreibung

Das Element “inFulfillmentOf” ermöglicht die Referenz zum ursprünglichen Auftrag des Auftraggebers.
Dies kann zum Beispiel eine Auftrags- oder Anforderungsnummer sein. Das Element erlaubt genau ein order Unterelement.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.20009 HeaderInFulfillmentOf (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:inFulfillmentOf

Komponente zur Dokumentation des Auftrags.

(Hea...tOf)

@typeCode

cs

1 … 1

F

FLFS

hl7:order

1 … 1

M

Auftrag.

(Hea...tOf)

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

RQO

hl7:id

II

1 … 1

M

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

(Hea...tOf)

7.5 Dokumentation der Gesundheitsdienstleistung

7.5.1 Service Events („documentationOf/serviceEvent“)

Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z. B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.

In serviceEvent/effectiveTime kann der Zeitpunkt/Zeitraum der Gesundheitsdienstleistung angegeben werden. Im Gegensatz zum Encounter (siehe Kapitel „Informationen zum Patientenkontakt“), der ggf. mehrere Gesundheitsdienstleistungen „umrahmt“.

Da diese Informationen in die XDS-Metadaten übernommen werden, ergeben sich folgende Implikationen:

Die serviceEvents sind die einzigen (rein) medizinischen Informationen zum Dokument im Dokumentenregister
Können daher als Such-/Filterkriterium verwendet werden
Scheint ggf. in den Ergebnissen der Suchabfragen auf

-> Sollte eine wertvolle Information sein (für den Behandler!)

Auszug aus dem R-MIM:

Abbildung 15: Klassen rund um die Gesundheitsdienstleistung.

7.5.1.1 Spezifikation

Da dieses Element automatisch in die XDS-Metadaten übernommen wird, SOLL mindestens eine Gesundheitsdienstleistung als documentationOf/serviceEvent-Element angegeben werden [R2].

ACHTUNG: Die Zeitangaben der Gesundheitsdienstleistung (erstes documentationOf/serviceEvent-Element) werden in die Dokument-Metadaten übernommen!

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

serviceStartTime: Beginn des ersten documentationOf/serviceEvent-Elements
serviceStopTime: Ende des ersten documentationOf/serviceEvent-Elements

Die semantische Bedeutung dieser Zeitpunkte wird in den speziellen Implementierungs-leitfäden festgelegt.

Es können beliebig viele weitere Gesundheitsdienstleistungen als weitere documentationOf/serviceEvent-Elemente angegeben werden.

Id

1.2.40.0.34.11.20010

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderServiceEvent

Bezeichnung

HeaderServiceEvent

Beschreibung

Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z. B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-145	Gesundheitsdienstleistung	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90003	Inklusion	AssignedEntityElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20010 (2017‑07‑21 11:18:58)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel Koloskopie

Beispiel

Strukturbeispiel Hämatologie

Item

DT

Kard

Konf

Beschreibung

Label

hl7:documentationOf

Komponente für die Gesundheitsdienstleistung.

(Hea...ent)


	elgagab-dataelement-145	Gesundheitsdienstleistung	Datensatz

@typeCode

cs

0 … 1

F

DOC

hl7:serviceEvent

1 … 1

M

Gesundheitsdienstleistung.

(Hea...ent)

@classCode

cs

0 … 1

F

ACT

@moodCode

cs

0 … 1

F

EVN

hl7:code

CE

1 … 1

R

Code der Gesundheitsdienstleistung.
Zugelassene nullFlavor: UNK
Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.

(Hea...ent)

hl7:effectiveTime

IVL_TS

1 … 1

M

Zeitraum der Gesundheitsdienstleistung.

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

(Hea...ent)

hl7:low

TS

1 … 1

M

(Hea...ent)

hl7:high

TS

1 … 1

M

(Hea...ent)

hl7:performer

0 … *

Durchführende Entität(en) der Gesundheitsdienstleistung.

(Hea...ent)

hl7:assignedEntity

1 … 1

M

(Hea...ent)

Eingefügt

von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ent)

hl7:addr

AD

0 … 1

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ent)

hl7:telecom

TEL.AT

0 … *

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ent)

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

(Hea...ent)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...ent)

hl7:representedOrganization

0 … 1

Organistationsdaten der validierenden Person.

(Hea...ent)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...ent)

hl7:name

ON

1 … 1

M

(Hea...ent)

hl7:telecom

TEL.AT

0 … *

(Hea...ent)

hl7:addr

AD

0 … 1

(Hea...ent)

Verweis auf speziellen Implementierungsleitfaden:
serviceEvent Element Allgemein
Ob eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
code
Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
effectiveTime
Welche Start- und Endezeiten eingetragen werden sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
performer
Ob und welche durchführende Entität eingetragen werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

effectiveTime
Hinweis: Für die automatisierte Datenübernahme aus dem CDA-Dokument in die XDS-Dokumentmetadaten ist stets ein Zeitintervall anzugeben.

7.6 Bezug zu vorgehenden Dokumenten

7.6.1 Allgemeines

Dieses Kapitel beschreibt die Versionsverwaltung von CDA-Dokumenten.

Der Bezug zu Vorgängerversionen von Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse (siehe Versionierung des Dokuments), spezifiziert.

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

Der Bezug zum Vordokument wird dabei über die parentDocument Beziehung ausgedrückt, in dem der dazugehörige @typeCode einen Wert aus der Liste der gültigen @typeCodes in der relatedDocument-Beziehung erhält. Das Originaldokument, auf das sich das Dokument bezieht, bleibt dabei unverändert.

Liste der möglichen Werte der @typeCodes in der relatedDocument Beziehung:

code	displayName	Bedeutung
~~APND~~	~~append~~	Verwendung NICHT ERLAUBT Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.
RPLC	replaces	Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "überholt" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.
~~XFRM~~	~~transformed~~	Verwendung NICHT ERLAUBT Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen. Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden. Es ist nicht auszuschließen, dass die Transformation in lokalen Affiniy Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

Tabelle 4: Vokabel-Domäne relatedDocument.typeCode

7.6.1.1 Spezifikation

Id

1.2.40.0.34.11.20011

ref

elgabbr-

Gültigkeit

2014‑12‑06

Andere Versionen mit dieser Id:

HeaderRelatedDocument vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderRelatedDocument

Bezeichnung

HeaderRelatedDocument

Beschreibung

Der Bezug zu vorgehenden Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse, spezifiziert.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-155	Bezug zu vorgehenden Dokumenten	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.20011 HeaderRelatedDocument (2014‑12‑06)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:relatedDocument

Komponente für das vorgehende Dokument.

(Hea...ent)


	elgagab-dataelement-155	Bezug zu vorgehenden Dokumenten	Datensatz

@typeCode

cs

1 … 1

F

RPLC

Art des Bezugs zum Vordokument.

hl7:parentDocument

1 … 1

M

Vorhergehendes Dokument.

(Hea...ent)

@classCode

cs

0 … 1

F

DOCCLIN

@moodCode

cs

0 … 1

F

EVN

hl7:id

II

1 … 1

M

Dokumenten-Id des vorgehenden Dokuments.

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

(Hea...ent)

7.7 Einverständniserklärung

7.7.1 Autorisierung („authorization“)

In dieser optionalen Klasse können die Einverständniserklärungen reflektiert werden, die mit dem Dokument verbunden sind. Dies kann ein Einverständnis für einen Eingriff oder die Verfügbarmachung der Informationen gegenüber Dritten beinhalten. Der Typ der Einverständniserklärung wird dabei in Consent.code angegeben.

Auszug aus dem R-MIM:

Abbildung 17: Consent Klasse.

7.7.1.1 Spezifikation

Id

1.2.40.0.34.11.20012

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderAuthorization

Bezeichnung

HeaderAuthorization

Beschreibung

Der Einverständniserklärung ist derzeit ungenutzt. Dieses Element wird daher derzeit nicht angegeben.

In dieser optionalen Klasse können die Einverständniserklärungen reflektiert werden, die mit dem Dokument verbunden sind. Dies kann ein Einverständnis für einen Eingriff oder die Verfügbarmachung der Informationen gegenüber Dritten beinhalten. Der Typ der Einverständniserklärung wird dabei in Consent.code angegeben.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.20012 HeaderAuthorization (2011‑12‑19)

ref

elgabbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:authorization

NP

Komponente für die Einverständniserklärung.
Wird in ELGA nicht verwendet!

(Hea...ion)

7.8 Informationen zum Patientenkontakt

7.8.1 Encounter („componentOf/encompassingEncounter“)

Diese Klasse repräsentiert Informationen, in welchem Rahmen der Patientenkontakt, der dokumentiert wird, stattgefunden hat. Dokumente werden nicht notwendigerweise immer während eines Patientenkontakts erstellt, sondern ggf. auch zu einem späteren Zeitpunkt, wenn beispielsweise ein Arzt wegen eines pathologischen Laborwertes den Patienten vergeblich versucht zu erreichen und dennoch seine Verlaufsdokumentation fortführt.

Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, muss die Information in dieser Klasse mitgegeben werden, inklusive der Dauer des Aufenthalts (hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) und der Einrichtung, wo der Patientenaufenthalt stattfand.

Auszug aus dem R-MIM:

Abbildung 18: EncompassingEncounter Klasse und Umgebung.

7.8.1.1 Spezifikation

Id

1.2.40.0.34.11.20013

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderEncompassingEncounter

Bezeichnung

HeaderEncompassingEncounter

Beschreibung

Diese Klasse repräsentiert Informationen, in welchem Rahmen der Patientenkontakt, der dokumentiert wird, stattgefunden hat. Dokumente werden nicht notwendigerweise immer während eines Patientenkontakts erstellt, sondern ggf. auch zu einem späteren Zeitpunkt, wenn beispielsweise ein Arzt wegen eines pathologischen Laborwertes den Patienten vergeblich versucht zu erreichen und dennoch seine Verlaufsdokumentation fortführt.

Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, muss die Information in dieser Klasse mitgegeben werden, inklusive der Dauer des Aufenthalts (hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) und der Einrichtung, wo der Patientenaufenthalt stattfand.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-156	Patientenkontakt	Datensatz

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90003	Inklusion	AssignedEntityElements	DYNAMIC
1.2.40.0.34.11.90006	Inklusion	Encounter Location 1	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20013 HeaderEncompassingEncounter (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<componentOf>
  <encompassingEncounter>
    
    <id root="1.2.40.0.34.99.111.1.4" extension="Az123456" assigningAuthorityName="Amadeus Spital"/>    
    <code code="IMP" displayName="Inpatient encounter" codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7:ActCode"/>    
    <effectiveTime>
      <low value="20081224082015+0100"/>      <high value="20081225113000+0100"/>    </effectiveTime>    
    <responsibleParty>
      <assignedEntity>
        
        <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>        
        <telecom use="WP" value="tel:+43.6138.3453446.2222"/>        
        <assignedPerson>
          
          <name>
            <prefix>Univ.-Prof.Dr.</prefix>            <given>Sigrid</given>            <family>Kollmann</family>          </name>        </assignedPerson>      </assignedEntity>    </responsibleParty>    
    <location>
      <healthCareFacility>
        <serviceProviderOrganization>
          
          <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>        </serviceProviderOrganization>      </healthCareFacility>    </location>  </encompassingEncounter></componentOf>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:componentOf

Komponente für den Patientenkontakt.

(Hea...ter)


	elgagab-dataelement-156	Patientenkontakt	Datensatz

@typeCode

cs

0 … 1

F

COMP

hl7:encompassingEncounter

1 … 1

R

Patientenkontakt.

(Hea...ter)

@classCode

cs

0 … 1

F

ENC

@moodCode

cs

0 … 1

F

EVN

hl7:id

II

0 … 1

Identifikationselement zur Aufnahme der Aufenthaltszahl.

(Hea...ter)

hl7:code

CE

1 … 1

M

Codierung des Patientenkontakts.

(Hea...ter)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.5 ELGA_ActEncounterCode (DYNAMIC)

hl7:effectiveTime

IVL_TS

1 … 1

M

Zeitraum des Patientenkontakts.

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

(Hea...ter)

hl7:low

TS.DATE.MIN

1 … 1

R

(Hea...ter)

hl7:high

TS.DATE.MIN

0 … 1

(Hea...ter)

hl7:responsibleParty

0 … 1

Komponente für die verantwortliche Person.

(Hea...ter)

hl7:assignedEntity

1 … 1

M

Entität der verantwortlichen Person.

Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen.

(Hea...ter)

Eingefügt

von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ter)

hl7:addr

AD

0 … 1

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ter)

hl7:telecom

TEL.AT

0 … *

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ter)

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

(Hea...ter)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...ter)

hl7:representedOrganization

0 … 1

Organistationsdaten der validierenden Person.

(Hea...ter)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...ter)

hl7:name

ON

1 … 1

M

(Hea...ter)

hl7:telecom

TEL.AT

0 … *

(Hea...ter)

hl7:addr

AD

0 … 1

(Hea...ter)

Eingefügt

1 … 1

M

von 1.2.40.0.34.11.90006 Encounter Location 1 (DYNAMIC)

hl7:location

1 … 1

M

Komponente Organisation.

(Hea...ter)

@typeCode

cs

0 … 1

F

LOC

Beispiel

hl7:healthCareFacility

1 … 1

M

(Hea...ter)

@classCode

cs

0 … 1

F

SDLOC

Beispiel

hl7:serviceProviderOrganization

1 … 1

M

Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand.

Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.

(Hea...ter)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

Beispiel

hl7:id

II

1 … *

R

(Hea...ter)

hl7:name

ON

1 … 1

M

(Hea...ter)

hl7:telecom

TEL.AT

1 … *

M

(Hea...ter)

hl7:addr

AD

1 … 1

M

(Hea...ter)

7.8.1.1.1 encompassingEncounter Element Allgemein

Verweis auf speziellen Implementierungsleitfaden:
Ob der Patientenkontakt angegeben werden muss, und welche Bedeutung dieses Element hat ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

7.8.1.1.2 id

Grundsätzlich sind die Vorgaben gemäß Kapitel „id-Element II“ zu befolgen.

Verweis auf speziellen Implementierungsleitfaden:
Ob, und welche Identifikation eingetragen werden soll ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

7.8.1.1.3 code

Grundsätzlich sind die Vorgaben gemäß Kapitel „code-Element CE CWE“ zu befolgen.

Verweis auf speziellen Implementierungsleitfaden:
Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

7.8.1.1.4 effectiveTime

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

7.8.1.1.5 responsibleParty

Die verantwortliche Person für den Patientenkontakt (Aufenthalt) KANN optional angegeben werden.

Verweis auf speziellen Implementierungsleitfaden:
Die konkrete Bedeutung der verantwortlichen Person für den Patientenkontakt (Aufenthalt) und eine ggf. verpflichtende Angabe dieses Elements ergeben sich aus dem jeweiligen speziellen Implementierungsleitfaden.

7.8.1.1.6 location

Die Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand, MUSS verpflichtend angegeben werden (z.B.: die entlassende Krankenanstalt mit Abteilung).

Verweis auf speziellen Implementierungsleitfaden:
Die konkrete Bedeutung der Organisation, in deren Verantwortungsbereich der Patientenkontakt (Aufenthalt) stattfand, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

8 Medizinische Inhalte (CDA Body)

8.1 Allgemeiner Aufbau des CDA Body

Der CDA Body eines CDA-Dokuments kann entweder „strukturiert“ oder „unstrukturiert“ angegeben werden.

8.1.1 Unstrukturierter medizinischer Inhalt: nonXMLBody

Diese Art des CDA Body dient dazu, medizinische Inhalte völlig unstrukturiert anzugeben. Dies erfolgt in einem text-Element, wobei der Inhalt dieses Elements auch ein eingebettetes Dokument, beispielsweise PDF, codiert in Base64 sein kann.
Welche Art von Inhalt in dem text-Element abgebildet ist, wird über die Attribute @mediaType und @representation festgelegt.

8.1.1.1 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
   :
   CDA Header
   :
   <component>
     <!-- Unstrukturierter CDA Body (Non-XML) -->
     <nonXMLBody>
       <text mediaType="application/pdf" representation="B64">
          :
       </text>
     </nonXMLBody>
   </component>
</ClinicalDocument>

8.1.2 Strukturierter medizinischer Inhalt: structuredBody

Der structuredBody eines CDA Release 2.0 Dokuments setzt sich aus ein oder mehreren Komponenten zusammen, wobei jede Komponente wiederum aus einer oder mehreren Sektionen und gegebenenfalls aus einem oder mehreren „Entry“-Elementen (siehe „Level 1 bis 3“ unten) besteht.

8.1.2.1 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
   :
   CDA Header
   :
   <component>
      <!-- strukturierter CDA Body -->
      <structuredBody>
         :
        <component>
           <section>
             … CDA Body Sektion …
           </section>
        </component>
         :
      </structuredBody>
   </component>
</ClinicalDocument>

8.1.2.2 CDA Level 1 bis 3

Die CDA Level repräsentieren die unterschiedliche Feinheit (Granularität) der wiedergegebenen klinischen Informationen und des maschinenauswertbaren Markups (standardisierte Form der maschinenauswertbaren Auszeichnung von Text).

8.1.2.2.1 CDA Level 1

Mit Level 1 ist ein XML Dokument gekennzeichnet, das vor allem auf „menschliche Interoperabilität“ abzielt („human readable“), also leicht für den menschlichen Gebrauch zugänglich gemacht werden kann, zum Beispiel durch Stylesheets. Es gibt keine Einschränkungen den Gebrauch oder Zweck des Dokuments oder den Inhalt betreffend. Die technischen Anforderungen, Level 1 Dokumente zu erzeugen oder zu verarbeiten, sind verhältnismäßig niedrig. Dies ist aus Datenverarbeitungssicht das gröbste Niveau von Informationen, gewährleistet damit aber sofort die Mensch-Mensch-Interoperabilität, die aus der reinen Papierwelt bekannt ist.

CDA Level 1 sind alle Dokumente mit einem CDA „nonXMLBody“ und jene mit Sektionen ohne Codierung:

<section>
   <title>Aufnahmegrund</title>
   <text>
	… Medizinischer Text …
   </text>
</section>

8.1.2.2.2 CDA Level 2

Im Level 2 werden die Abschnitte klassifiziert. Die Identifikation dieser Abschnitte ist auch für Applikationen zugänglich, also maschinenauswertbar. Dies wird durch die Assoziation des Abschnitts mit einem Code erreicht. Als Codierung der Sektionen kann prinzipiell jedes Codesystem, vorzugsweise aber LOINC herangezogen werden.

Als Folge davon können so genannte section-level Templates zur Anwendung kommen. Mit den Codes sind die Abschnitte auch maschinenauswertbar, d.h. durch Applikationen identifizierbar. Das bedeutet unter anderem, dass ein CDA-Dokument dahingehend näher bestimmt werden kann, dass es spezifische Abschnitte, Paragrafen und andere Strukturbestandteile aufweisen muss. So kann ein Entlassungsbrief beispielsweise ganz bestimmte Abschnitte beinhalten (Anamnese, Behandlung, Medikation, weiteres Vorgehen etc.), während ein Befundbericht ganz andere Erfordernisse bezüglich der Abschnitte und Strukturen haben kann.

<section>
  <code
     code="42349-1"
     displayName="Grund für die Überweisung/Einweisung"
     codeSystem="2.16.840.1.113883.6.1"
     codeSystemName="LOINC" />
     <title>Aufnahmegrund</title>
     <text>
	… Medizinischer Text …
     </text>
</section>

8.1.2.2.3 CDA Level 3

CDA-Dokumente, die auch Level 3 konform sind, beinhalten zusätzlich zu der lesbaren Text-Sektion auf dem Niveau von Einzelinformationen maschinenauswertbare Komponenten (wie beispielsweise „systolischer Blutdruck“), die RIM-Klassen entsprechen.

Eine Anwendung kann damit Daten wie eine einzelne Beobachtung, Prozedur, Medikamentengabe etc. identifizieren und verarbeiten. Selbst die Anwesenheit von bestimmten Einzelinformationen kann durch Vorgaben (Templates-Konzept) verpflichtend gemacht werden.

Alle relevanten medizinischen Daten MÜSSEN im „menschenlesbaren Teil“, dem narrativen Block (title und text-Elemente der Sections) enthalten sein [R]. Die maschinenlesbaren Einträge (entry) MÜSSEN inhaltlich konsistent zum lesbaren Textbereich sein und sollen zusätzlich die entsprechenden Inhaltsstellen im Textbereich referenzieren. Zusätzliche maschinenlesbare Informationen können angegeben werden, sofern sie nicht dargestellt werden müssen und auch nicht Bestandteil des signierten Originalbefundes sind. Sind die narrativen Daten direkt von den maschinenlesbaren abgeleitet und daher inhaltlich gleich, wird das im Entry durch das Attribut typeCode="DRIV" angegeben. Hier kann ausschließlich der maschinenlesbare Teil ohne Informationsverlust zur Weiterverarbeitung verwendet werden.

<section>
   <code
     code="42349-1"
     displayName="Grund für die Überweisung/Einweisung"
     codeSystem="2.16.840.1.113883.6.1"
     codeSystemName="LOINC" />
     <title>Aufnahmegrund</title>
     <text>
	… Medizinischer Text …
     </text>
     <entry>
        … HL7 Version 3 RIM Klassen (Beobachtung, Prozedur, …) mit Codes …
     </entry>
</section>

8.1.3 Sektionen

CDA bietet die Möglichkeit Sektionen mit sogenannten „templateId“-Elementen zu versehen. Mit diesen Elementen ist es möglich, analog zur ELGA Implementierungsleitfaden-Kennzeichnung für das gesamte Dokument, auch einzelne Sektionen zu kennzeichnen.

Diese Kennzeichnung ist speziell für Prüfmittel (z.B.: Schematron) wichtig, da über diese Kennzeichnungen die zugrundeliegenden Regeln zur Befüllung der Sektion zugeordnet und abgeprüft werden können.

Verweis auf speziellen Implementierungsleitfaden:
Welche templateId angegeben werden muss, ist im entsprechenden speziellen Implementierungsleitfaden in der Definition der Sektionen beschrieben.

8.1.3.1 Spezifikation

Id

1.2.40.0.34.11.30001

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

BodySection

Bezeichnung

BodySection

Beschreibung

CDA bietet die Möglichkeit Sektionen mit sogenannten „templateId“-Elementen zu versehen. Mit diesen Elementen ist es möglich, analog zur ELGA Implementierungsleitfaden-Kennzeichnung für das gesamte Dokument, auch einzelne Sektionen zu kennzeichnen.

Diese Kennzeichnung ist speziell für Prüfmittel (z.B.: Schematron) wichtig, da über diese Kennzeichnungen die zugrundeliegenden Regeln zur Befüllung der Sektion zugeordnet und abgeprüft werden können.

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90004	Inklusion	AuthorElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.30001 BodySection (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<hl7:ClinicalDocument>
   : CDA Header :   <hl7:component>
    
    <hl7:structuredBody>
      <hl7:component>
        <hl7:section>
          <hl7:templateId root="1.2.3.4.5.6.7.8"/>          <hl7:code/>          <hl7:title>Name der Sektion</hl7:title>           : … CDA Body Sektion …         </hl7:section>      </hl7:component>    </hl7:structuredBody>  </hl7:component></hl7:ClinicalDocument>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:templateId

II

0 … *

Templateidentifikation(en) der Sektion.

(Bod...ion)

hl7:id

II

0 … 1

Eindeutige ID der Sektion (optional).

(Bod...ion)

hl7:code

CE

0 … 1

Code der Sektion.

(Bod...ion)

hl7:title

ST

0 … 1

Titel der Sektion.

(Bod...ion)

hl7:text

1 … 1

R

Information für den menschlichen Leser.

(Bod...ion)

Eingefügt

0 … *

von 1.2.40.0.34.11.90004 AuthorElements (DYNAMIC)

Auswahl

0 … *

Elemente in der Auswahl:

hl7:author[not(@nullFlavor)]
hl7:author[@nullFlavor]

hl7:author

Verfasser des Dokuments.

(Bod...ion)

wo [not(@nullFlavor)]

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

0 … 1

Funktionscode des Verfassers des Dokuments

z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …

Eigene Codes und Bezeichnungen können verwendet werden.

Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

(Bod...ion)

hl7:time

TS.DATE.MIN

1 … 1

R

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

Zugelassene nullFlavor: UNK

(Bod...ion)

hl7:assignedAuthor

1 … 1

M

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

(Bod...ion)

@classCode

cs

0 … 1

F

ASSIGNED

Beispiel

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software.

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

(Bod...ion)

hl7:code

CE

0 … 1

Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung)z.B: „Facharzt/Fachärzting für Gynäkologie“,

Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.
Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

(Bod...ion)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)

hl7:telecom

TEL.AT

0 … *

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

(Bod...ion)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

… 1

Personendaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

(Bod...ion)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.

(Bod...ion)

hl7:assignedAuthoringDevice

… 1

(Bod...ion)

@classCode

cs

0 … 1

F

DEV

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:manufacturerModelName

SC

0 … 1

Hersteller und Modellbezeichnung des datenerstellenden Gerätes.

(Bod...ion)

hl7:softwareName

SC

0 … 1

Bezeichnung (und ggf Version) der datenerstellenden Software.

(Bod...ion)

hl7:representedOrganization

1 … 1

M

(Bod...ion)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Bod...ion)

hl7:name

ON

1 … 1

M

(Bod...ion)

hl7:telecom

TEL.AT

0 … *

(Bod...ion)

hl7:addr

AD

0 … 1

(Bod...ion)

hl7:author

Verfasser nicht bekannt/nicht anwendbar

(Bod...ion)

wo [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Beispiel

hl7:time

1 … 1

R

(Bod...ion)

@nullFlavor

cs

1 … 1

F

NA

hl7:assignedAuthor

1 … 1

R

(Bod...ion)

@nullFlavor

cs

1 … 1

F

NA

hl7:id

1 … 1

R

(Bod...ion)

@nullFlavor

cs

1 … 1

F

NA

hl7:entry

0 … *

Maschinenlesbare Elemente der Sektion.

(Bod...ion)

8.1.4 Textstrukturierung

Die medizinischen Informationen werden im CDA Body immer in Textform wiedergegeben (der „narrative Block“ ist verpflichtend). Dies garantiert, dass die Dokumente immer für den Menschen lesbar (und verstehbar) sind.

Der Text selber kann wiederum Strukturelemente aufweisen. Dies kann genutzt werden, um Listen, Tabellen oder auch Unterabschnitte zu definieren.

Der CDA-Standard erlaubt nur eine kleine Auswahl an Formatierungsoptionen für den narrativen Block, damit die oben genannte einfache Lesbarkeit („human readability“) zuverlässig erhalten bleibt und die Anforderungen für die Wiedergabe einfach bleiben.

Dieses Kapitel behandelt die verschiedenen Möglichkeiten der Textstrukturierung im text-Element einer CDA Sektion.

Hinweis: Damit die Textstrukturierung möglichst von allen im Umlauf befindlichen Style-sheets korrekt wiedergegeben kann, dürfen nur bekannte Formatierungsoptionen verwendet werden.
Nur die in diesem Leitfaden genannten Optionen für die Strukturierung des Textes im narrativen Block sind ERLAUBT, alle anderen daher VERBOTEN.

Innerhalb eines Section-Tags wird in CDA Level 2 das <text>-Element verwendet, um den narrativen Text („plain text“) darzustellen. In vielen Fällen lassen sich die medizinischen Inhalte aber auch noch weitergehend strukturieren. Dazu stehen in CDA als Stil-Elemente Listen, Tabellen und Unterabschnitte (Paragrafen) zur Verfügung. Mit Hilfe eines einfachen Stylesheets können die Inhalte in diesen Strukturelementen für den Menschen lesbar dargestellt werden.

8.1.4.1 Listen

Das Strukturelement „Liste“ dient zur Abbildung einer einfachen Aufzählung medizinischer Inhalte.

Eine Liste wird mit dem list Tag eingeschlossen. Das optionale Attribut @listType ermöglicht die Auflistung unsortiert (@listType=“unordered“), die üblicherweise mit Bulletpoints • dargestellt wird, und in sortierter Form (@listType=“ordered“), die mit Zahlen etc. dargestellt wird. Ohne Angabe von @listType ist die Liste unsortiert.

Ein Element der Aufzählung (item) wird mit dem item Tag eingeschlossen.

Folgende styleCodes können für die Formatierung von Listen mittels Aufzählungspunkten verwendet werden:

styleCode	Definition	Nutzungsbeispiel
Disc	Unsortierte Liste mit ausgefüllten Kreisen	<list listType="unordered" styleCode= "Disc">
Circle	Unsortierte Liste mit nicht ausgefüllten Kreisen	<list listType="unordered" styleCode= "Circle">
Square	Unsortierte Liste mit ausgefüllten Quadraten	<list listType="unordered" styleCode= "Square">
Arabic	Sortierte Liste mit Zahlen (1, 2, 3)	<list listType="ordered" styleCode= ”Arabic">
LittleRoman	Sortierte Liste mit kleingeschriebenen römischen Zahlen (i, ii, iii)	<list listType="ordered" styleCode= ”LittleRoman">
BigRoman	Sortierte Liste mit großgeschriebenen römischen Zahlen (I, II, III)	<list listType="ordered" styleCode= ”BigRoman">
LittleAlpha	Sortierte Liste mit kleingeschriebenen Buchstaben (a, b, c)	<list listType="ordered" styleCode= ”LittleAlpha">
BigAlpha	Sortierte Liste mit großgeschriebenen Buchstaben (A, B, C)	<list listType="ordered" styleCode= ”BigAlpha">
None	Unterdrückt die Ausgabe von Aufzählungszeichen⁹	<list styleCode= "none">

⁹ Kann verwendet werden, um eine Tabelle in einem Tabellenfeld einzufügen. Dabei wird ein List-Item im <td> -Element eingefügt, darin kann eine Tabelle als Unterelement angegeben werden.

8.1.4.1.1 Strukturbeispiel

Eine Liste hat das folgende Aussehen:

<text>
   :
   <list listType="ordered" styleCode= ”BigAlpha">
     <item>Pulmo: Basal diskrete RGs</item>
     <item>Cor: oB</item>
     <item>Abdomen: weich, Peristaltik: +++</item>
     <item>Muskulatur: atrophisch</item>
     <item>Mundhöhle: Soor, Haarleukoplakie</item>
     <item>Haut blass, seborrhoisches Ekzem, Schleimhäute blass, Hautturgor herabgesetzt</item>
     <item>Neuro: herabgesetztes Vibrationsempfinden der Beine,	distal betont, Parästesien der Beine, PSR, AST oB und seitengleich.</item>
   </list>
     : 
</text>

8.1.4.2 Tabellen

Zur Repräsentation medizinischer Inhalte, die sich adäquat tabellarisch darstellen lassen, bietet sich die Tabellenform an. Als Beispiele seien genannt: Laborwerte, Allergiewerte, Diagnosen mit ICD-Codierung etc.

CDA realisiert ein vereinfachtes XHTML Table Modell, das HTML sehr ähnelt. Eine Tabelle wird mit dem table-Element angegeben. Siehe auch Erweiterte styleCodes.

Die Tabellenüberschrift wird eingeschlossen in thead Tags, die Überschriftenzeile in tr Tags und die einzelnen Spalten-Items der Überschrift mit th Tags.

Die optionale Tabellenunterschrift <tfoot> wird entsprechend der HTML-Tabellenkonvention direkt vor dem <tbody>-Tag und nach dem <thead> Tag angeführt. Es wird für Fußnoten in Tabellen verwendet und enthält genau einen <tr> und einen <td>-Tag (Siehe auch Beispiel in Fußnoten)

Die eigentlichen Tabelleninhalte werden in tbody Tags, die Datenzeile in tr Tags und die einzelnen Spalteninhalte einer Datenzeile mit td Tag gekapselt.

Die Vorgaben für Tabellen MÜSSEN korrekt eingehalten werden, damit sie zuverlässig und korrekt durch Stylesheets dargestellt werden können. Die Anzahl der Spalten MUSS über eine komplette Tabelle in thead und tbody gleich bleiben (ausgenommen tfoot).

8.1.4.2.1 Strukturbeispiel

Eine Tabelle hat das folgende Aussehen:

<text>
   :
   <table>
     <!-- Kopfzeile -->
     <thead>
       <tr>
          <th>Spaltenüberschrift 1</th>
          <th>Spaltenüberschrift 2</th>
       </tr>
     </thead>

     <!-- Optionale Fußzeile mit EINER Spalte -->
     <tfoot>
	<tr>
		<td>Die Fußzeile hat eine durchgehende Spalte</td>
	</tr>
     </tfoot>

     <!-- Tabelleninhalte - Anzahl der Spalten gleich wie Kopfzeile -->
     <tbody>
       <tr>
         <td>1. Zeile - Daten der Spalte 1</td>
         <td>1. Zeile - Daten der Spalte 2</td>
       </tr>
       <tr>
         <td>n. Zeile - Daten der Spalte 1</td>
         <td>n. Zeile - Daten der Spalte 2</td>
       </tr>
     </tbody>
   </table>
   :
</text>

8.1.4.3 Unterabschnitte

Zur Strukturierung eines längeren Textes kann das paragraph Tag verwendet werden.

8.1.4.3.1 Strukturbeispiel

<text>
   :
     <paragraph>Sollten nach der empfohlenen Medikation mit Atemur die klinischen Zeichen weiterhin bestehen, halte ich bei dem umfangreichen Risikoprofil einen Kuraufenthalt für zwingend notwendig.</paragraph>
     <paragraph>Ich bitte dann um Wiedervorstellung des Patienten.</paragraph>
   :
</text>

8.1.4.4 Referenzierter bzw. Attribuierter Inhalt (content)

Das CDA content-Element wird benutzt, um Text ausdrücklich mit Tags „einzurahmen“, so dass er referenziert werden kann oder bestimmte Möglichkeiten zur visuellen Darstellung genutzt werden können. Das content-Element kann rekursiv ineinander geschachtelt werden, was die Einrahmung von ganzen Texten bis hin zu kleinsten Teilen (Worte, Buchstaben etc.) erlaubt.

Referenzierter Inhalt
Das content-Element enthält ein optionales Identifikator Attribut, das als Ziel einer XML Referenz dienen kann. Alle diese IDs sind als XML IDs definiert und MÜSSEN im gesamten Dokument eindeutig sein. Die originalText Komponente einer RIM Klasse, die sich in den CDA Entries (siehe unten) wiederfindet, kann sich somit explizit auf die vom content-Element im Textteil umschlossene Information beziehen.

Attribuierter Inhalt
Das content-Element wird auch zur Einrahmung von Text benutzt, der in einem bestimmten Stil dargestellt werden soll, was mit dem @styleCode Attribut näher beschrieben wird.

8.1.4.4.1 Zugelassene styleCode Attribut-Werte

styleCode	Definition	Nutzungsbeispiel
bold	Fettdruck	<content styleCode="bold"> text </content>
underline	Unterstrichen	<content styleCode="underline"> text </content>
italics	Kursivschrift	<content styleCode="italics"> text </content>
emphasis	Kapitälchen	<content styleCode="emphasis"> text </content>

8.1.4.4.2 Strukturbeispiel

Im folgenden Beispiel wird das Textstück „Asthma“ durch das content-Element eingerahmt, so dass in einem möglichen Level 3 Entry darauf Bezug genommen werden kann (siehe „Zusammenhang Text und Entry“).

Darunter findet sich ein Text, der fett gedruckt erscheinen soll.

<text>
   :
   Diagnose des Patienten: <content ID="diag1">Asthma</content>
   <content styleCode="bold">Dieser Text ist fettgedruckt.</content>
   <content styleCode="bold italics"> Text ist fett und kursiv.</content>
   :
</text>

8.1.4.5 Erweiterte styleCodes

Neben den vom CDA-Standard vorgesehenen Möglichkeiten der Formatierung von Textelementen, erlaubt dieser Leitfaden die Nutzung weiterer styleCodes. Das ELGA Referenz-Stylesheet unterstützt die Verwendung dieser erweiterten, ELGA-spezifischen StyleCodes.

Die Darstellung der erweiterten, ELGA-spezifischen StyleCodes erfordert ein speziell angepasstes Stylesheet (z.B. das ELGA Referenz-Stylesheet).

Textstrukturen können durch diese ELGA-spezifisch erweiterten StyleCodes formatiert werden, z.B. um bestimmte Abschnitte wie Überschriften oder Unterüberschriften zu formatieren, oder um die Textfarbe zu setzen.

styleCode	Definition	Nutzungsbeispiel
xELGA_h1	Überschriften gem. HTML < h1>	<paragraph styleCode="xELGA_h1">
xELGA_h2	Überschriften gem. HTML < h2>	<paragraph styleCode="xELGA_h2">
xELGA_h3	Überschriften gem. HTML < h3>	<paragraph styleCode="xELGA_h3">
xELGA_blue	CMYK: 100, 60, 0, 6 RGB: 0, 96, 240 HTML: #0060f0	<content styleCode="xELGA_blue"> Anmerkung: Dient zur farblichen Hervorhebung von Wörtern oder Passagen im Fließtext.
xELGA_red	CMYK: 0, 91, 65, 12 RGB 224, 20, 79 HTML: #e3144f Zusätzlich wird der Text Fett dargestellt, da Rot für farbfehlsichtige Personen schwer erkennbar ist.	<content styleCode="xELGA_red"> Anmerkung: Dient zur farblichen Kennzeichnung von pathologischen Labormesswerten in Tabellen (wird für die ganze Ergebniszeile in einer Tabelle) verwendet.
xELGA_colw:NN	NN...numerische Angabe des Prozentwertes der Spaltenbreite in Tabellen, maximal 2 Ziffern, nur positive Ganzzahlen. Wird nichts angegeben, wird die Spaltenbreite automatisch berechnet (bei n Spalten -- 1/n der gesamten Tabellenbreite)	< th styleCode="xELGA_colw:20"> Die Spaltenbreite entspricht 20% der gesamten Tabellenbreite Anmerkung: Weicht die Summe der angegebenen Spaltenbreiten von 100% ab, wird die Gesamtsumme als 100% angenommen und die einzelnen Spalten entsprechend angepasst
xELGA_tabVertical	Gilt nur für die Ausgabe als Druckvorstufe (PDF): Die Ausrichtung der Tabelle ist um 90% in eine vertikale Orientierung gedreht Defaultausrichtung ist horizontal	< table styleCode="xELGA_tabVertical"> Die Tabelle ist auf einer neuen Seite vertikal ausgerichtet, Tabellenbreite = Seitenhöhe Default: Horizontale Ausrichtung, Tabellenbreite = Textbreite
xELGA_monospaced	Statt der normalen Proportionalschrift wird eine nichtproportionale Schriftart (Festbreitenschrift) verwendet.	<content styleCode="xELGA_monospaced"> Anmerkung: Verwendung in Anwendungsszenarien, wo Texte in Befunde übernommen werden, die durch Verwendung von äquidistanten Schriftarten formatiert wurden. Beispiel: Laborwerttabellen

8.1.4.6 Zeilenumbrüche

Das br-Element < br/> kann benutzt werden, um im laufenden Text einen „harten“ Zeilumbruch zu erzwingen. Dies unterscheidet es vom paragraph-Element, da der Zeilenumbruch keinen Inhalt hat. Empfänger sind angehalten, dieses Element als Zeilenumbruch darzustellen.

8.1.4.6.1 Strukturbeispiel

<text>
   :
   Patient hat Asthma seit seinem zehnten Lebensjahr.<br/>
   Patient kommt damit gut zurecht.
   :
</text>

8.1.4.7 Superscript und Subscript

Ein Textbereich kann mit dem Element sup umspannt werden, um ihn Superscript (hochgestellt) darzustellen. Er kann mit sub umspannt werden, um ihn Subscript (tiefgestellt) darzustellen.

8.1.4.7.1 Strukturbeispiel

<text>
   :
   Dieses Wort ist <sup>hochgestellt</sup>
   Dieses Wort ist <sub>tiefgestellt</sub>
   :
</text>

8.1.4.8 Fußnoten

Mit den Elementen footnote und footnoteref sind diese Gestaltungsmöglichkeiten im CDA-Standard beschrieben.

8.1.4.8.1 Strukturbeispiel

Die Fußnotenreferenzen werden fortlaufend nummeriert und durch einen Tag hochgestellt. Der Text wird unter <tfoot> mit dem <footnote> Tag gekennzeichnet. Die ID gibt eine eindeutige Referenz auf den Text einer Fußnote.

<table>
    <thead>
        ...
    </thead>
    <tfoot>
    	<tr>
            <td>
                <footnote ID="fn1"><sup>1)</sup> Wert kontrolliert</footnote>
            </td>
        </tr>
    </tfoot>
    <tbody>
        ...
        <tr ID="OBS-13-1">
            <td ID="OBS-13-1-Code">aPTT</td>
            <td ID="OBS-13-1-Value">57.0
            <!-- Fußnoten werden durch das XSL entsprechend angezeigt -->
                    <sup>1)</sup>
            </td>
            <td ID="OBS-13-1-Unit">s</td>
            <td ID="OBS-13-1-Reference">26.0-40.0</td>
            <td ID="OBS-13-1-Interpretation">++</td>
            <td ID="OBS-13-1-Delta"/>
            <td ID="OBS-13-1-Extern">E</td>
        </tr>
        ...
    <tbody>
</table>

8.1.4.9 HTML-Verweise

Über das Element linkHtml lassen sich Verweise dokumentintern und auf externe Webseites (ähnlich wie im HTML-Standard beschrieben) realisieren. Wird in diesem Leitfaden nicht genutzt.

8.1.4.10 Geschützte Leerzeichen

Grundsätzlich werden zusätzliche Leerzeichen am Anfang und am Ende eines Elementinhaltes bei der Darstellung entfernt, auch mehrere Leerzeichen hintereinander (bspw. zwischen Wörtern) werden wie ein Leerzeichen behandelt.

Zusätzlicher Leerraum (whitespace bzw „no-break space“) kann in CDA erzeugt werden durch & #160; oder & #xA0;

Es erzeugt einen Leerraum von einem Zeichen und entspricht dem in HTML verwendeten, in CDA aber NICHT ERLAUBTEN „& nbsp;“.

8.1.5 Strukturen in Level 3

Es wird angestrebt, Level 3 Darstellungen schrittweise einzuführen. Das bedeutet, dass neben der obligatorischen Repräsentation der medizinischen Inhalte auf Level 2 auch optional die zusätzliche Darstellung dieser Inhalte auf Level 3 verwendet werden kann, um sie für das empfangende System strukturiert auswertbar zu machen. Es sei an dieser Stelle nochmals darauf hingewiesen, dass der Text in Level 1 bzw. 2 führend für den medizinischen Inhalt ist, und dass Level 3 Konstrukte dieselbe (aber maschinenauswertbare) Information tragen.

Generell sind in der CDA Entry Auswahl folgende Klassen aus dem RIM modelliert:

CDA Entry	Bedeutung
Observation	Allgemeine oder spezifische Beobachtung, wie z. B. Diagnosen, Befunde, Laborergebnisse etc.
ObservationMedia	Medieninformation zur Beobachtung, z. B. externe Referenzen auf Bilder etc.
Procedure	Prozeduren, Eingriffe, die den Patienten „verändern“
RegionOfInterest	Fokusinformation
SubstanceAdministration	Verordnung von Medikamenten, Hilfsmitteln etc.
Supply	Verabreichung, Verfügbarmachung von Medikamenten, Hilfsmitteln etc.
Encounter	Kontakt mit Patient
Act	Generische Aktivität
Organizer	Ordnungsmöglichkeit für CDA Entries

Tabelle 5: CDA Entry Klassen

Dieses Kapitel behandelt den Zusammenhang von text und entry und gibt eine grundsätzliche Anleitung für den Aufbau von Level 3 Strukturen.

8.1.5.1 Zusammenhang Text und Entry

Elemente innerhalb des Textabschnittes (<text>) nutzen die ID Attribute, um von den zugehörigen Level 3 Entries referenziert zu werden. Dies stellt eine Verknüpfung zwischen dem codierten Eintrag und dem Text dar. Dabei wird das Ziel verfolgt, schrittweise mehr strukturiertes Markup zur Verfügung zu stellen, das Applikationen nutzen können. Außerdem werden dadurch Doppeleinträge von Informationen verhindert.

Jedes Element im narrativen Kontext kann ein ID Attribut mitführen. Dies ist vom Typ xs:ID und MUSS im gesamten Dokument eindeutig sein. IDs dieser Art beginnen mit einem Buchstaben, gefolgt von einem oder mehreren Buchstaben, Zahlen, Bindestrichen oder Unterstrichen.

Abbildung 19: Referenzierung Text - Entry.

Dies erlaubt, dass der Text mit einer einfachen URI dereferenziert werden kann. Die URI ist lokal im Dokument definiert, beginnt mit einem #-Zeichen, gefolgt von der ID.

Aus den obigen Beispielen würde das folgende Textfragment durch De-Referenzierung der Referenz „#disdiag1_diagnosis“ gewonnen: „M25.46, Meniskus: Empyema gen. sin.“.

Der Bezug vom Quelltext zu den Entries wird im @typeCode Attribut des entry-Elements angegeben und ist im Normalfall (und Default) COMP (component). Dies ist der allgemeine Fall und bedeutet, dass die Information in den Entries im Inhalt des Quelltexts enthalten ist. Weiter sind keine inhaltlichen Implikationen dabei vorhanden. In diesem Falle ist außerdem der narrative Quelltext der authentifizierte Inhalt.

CDA Entries können durch verschiedene Methoden abgeleitet werden, z.B. durch Verarbeitung der natürlichen Sprache, einer Person, die den Eintrag codiert, einem Werkzeug, das sowohl codierte Einträge als auch Text produziert. Die jeweilige Methode kann durch die participantRole unter Angabe der Person oder des benutzten Algorithmus identifiziert werden.

Ähnlich wie bei einzelnen Sections können auch jedem Entry einzeln Participants zugeordnet werden. So kann eine bestimmte Prozedur um teilnehmende Personen ergänzt werden, die nur an dieser Prozedur beteiligt waren (siehe nachfolgende Abbildung)

Abbildung 20: Zuordnung von Participants zu einzelnen Sections.

8.1.5.2 Bezug zwischen Entries

Angabe dieser Beziehung in entryRelationship. Beispiele für solche Beziehungen zwischen Entries sind:

Observation und ObservationMedia (entryReleationship.typeCode = COMP „component“)
Observation („Nesselsucht“) und Observation („Allergie“), entryReleationship.typeCode = MFST („Manifestation of“)
Eine Beobachtung besteht aus Teilbeobachtungen, z. B. eine Batterie von Labortests, systolischer und diastolischer Blutdruck.

Über die entryRelationship Klasse können die verschiedenen Entries miteinander verbunden werden. Der @typeCode gibt dabei die Art der Beziehung wieder.

Abbildung 21: entryRelationship Klasse. @typeCode gibt die Art der Beziehung wieder.

Weiterhin gibt es Situationen, in denen Entries vorhanden sind, ohne dass dazu ein Quelltext vorhanden ist, z.B. bei Kalibierungsangaben, Reagenzien oder andere Informationen, die für die weitere Verarbeitung notwendig sind. Auch hier ist der @typeCode der entryRelationship = COMP. Für den Fall, dass der narrative Text gänzlich aus codierten Entries abgeleitet ist, wird dies mit dem @typeCode DRIV (derived from) ausgedrückt. Dies ist beispielsweise bei Diagnoseninformationen der Fall, die eigentlich vollständig hoch-codiert in den Entries vorliegen und woraus der klinische Text erzeugt wird.

Auch ein Mix aus verschiedenen Entries und verschiedenen Beziehungstypen ist möglich.

8.1.6 Untersektionen – Hierarchischer Aufbau

Sektionen können laut CDA Schema beliebig verschachtelt werden.

Eine Sektion kann eine oder mehrere Untersektionen enthalten, welche jeweils wiederum Untersektionen enthalten können, usw.

Verweis auf speziellen Implementierungsleitfaden:
Ob eine Sektion weitere Untersektionen enthält, ist im entsprechenden speziellen Implementierungsleitfaden in der Definition der Sektionen beschrieben.

8.1.6.1 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
   :
   <!-- CDA Header -->
   :
   <component>
   <!-- strukturierter CDA Body -->
     <structuredBody>
       <component>
         <section>
            <code …/>
            <title>Name der Sektion</name>
            <text>…</text>
            <!-- Untersektion -->
            <component>
               <section>
                  <code …/>
                  <title>Name der Untersektion</name>
                  <text>…</text>
               </section>
            </component>
          </section>
       </component>
     </structuredBody>
   </component>
</ClinicalDocument>

8.1.7 Einbetten von Dokumenten/Multimedia-Dateien

Es ist möglich, zusätzlich zu dem Text auch Referenzen auf externe Multimediaobjekte wie Bilder etc. zu spezifizieren. Dies geschieht über das renderMultiMedia-Element und dient dazu aufzuzeigen, wo das Multimedia-Objekt gezeigt/dargestellt werden soll.

Das renderMultiMedia-Element trägt dabei im @referencedObject Attribut die ID auf den Verweis auf das Multimedia-Objekt. Dieser Verweis wird als entry in der ObservationMedia-Klasse abgelegt. Im value-Element des observationMedia-Elements wird das eigentliche Objekt (Dokument, Bild …) eingebettet. Im caption-Unterelement wird eine Beschreibung des Multimedia-Objektes angegeben. Das Referenzstylesheet wird den Inhalt als Mouseover und als Alternativtext ausgeben.

Abbildung 22: ObservationMedia Klasse zur Ablage von Multimedia-Objekten.

Hinweis zur erlaubten Größe von Multimedia-Inhalten:
Die Gesamtgröße des CDA-Dokumentes bzw. der XML-Datei SOLL 20 MB nicht überschreiten¹⁰. Die Größe der eingebetteten Dateien soll auf ein sinnvolles und angemessenes Mininum beschränkt werden.

Siehe auch „Größenbeschränkung von eingebetteten Objekten“.

Hinweis zur Verwendung von Multimedia-Inhalten und Barrierefreiheit:
Die Empfänger der Dokumente haben unterschiedliche Ausgabegeräte und unterschiedliche Bedürfnisse. Bilder, sowie Audio- und Videodateien werden möglicherweise nicht dargestellt oder gedruckt werden können. Bitte beachten Sie also im Sinne der Barrierefreiheit folgende Punkte

Bei Multimedia-Daten MÜSSEN die relevanten Inhalte immer im lesbaren Text beschrieben werden.
Wo Multimedia-Dateien normalerweise angezeigt werden, MUSS eine sprechende Beschreibung ihres Inhaltes angegeben werden (z.B. Textalternative, Bildunterschrift).
Die Textalternative für Bilddaten SOLL auch im Unterelement von <renderMultimedia> angegeben werden, dieses Element kann in Screenreadern entsprechend ausgewertet werden und erhöht die Barrierefreiheit.
Grafiken mit Transparenzen sind NICHT ERLAUBT.

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

8.1.7.1 Strukturbeispiele

8.1.7.1.1 Eingebettetes PDF

Das folgende Beispiel beschreibt einen eingebetteten Befund, der in der Sektion „Beigelegte Befunde“ angegeben wurde.

<section>
   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.31"/>
   <code code="BEFBEI"
         displayName="Beigelegte erhobene Befunde"
         codeSystem="1.2.40.0.34.5.40"
         codeSystemName="ELGA_Sections"/>
   <title>Beigelegte erhobene Befunde</title>
   <text>
     <table>
        <thead>
           <tr>
              <th>Name des Dokuments</th>
              <th>Datum</th>
              <th>Dokument</th>
           </tr>
       </thead>
       <tbody>
           <tr>
              <td>Laborbefund</td>
              <td>01.01.2009</td>
              <td><renderMultiMedia referencedObject="MM1">
                  <caption>Eingebetteter Laborbefund</caption>
                  </renderMultimedia>
              </td>
           </tr>
        </tbody>
      </table>
   </text>
   <entry>
     <observationMedia classCode="OBS" moodCode="EVN" ID="MM1">
       <!-- ELGA EingebettetesObjekt-Entry -->
       <templateId root="1.2.40.0.34.11.1.3.1"/>
       <value
           mediaType="application/pdf"
           representation="B64">
           JVBEi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyI
           C9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM1aW28dtxFGnLfzK/ap3S0ihveLU
           M5z5OHt+bjgTznIVGh7/o/84Xi0+PwjN+d3i54Vh1nNjezltH6+a50sYJngj
           AuOu2Z5thB9n2gcZ55r2XjoEzBjuVq0Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ90
           e0opgNXrv2p40zBn/YAZU0HLR+cb3lnW Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ
            :      :      :
       </value>
     </observationMedia>
   </entry>
</section>

8.1.7.1.2 Eingebettetes Bild

Das folgende Beispiel beschreibt einen Befund am linken Zeigefinger, der zusätzlich mit einem Bild dokumentiert ist.

<section>
    <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.31"/>
    <code
       code="29554-3" codeSystem="2.16.840.1.113883.6.1"
       codeSystemName="LOINC" displayName="Prozeduren"/>
    <title>Durchgeführte Maßnahmen</title>
    <text>Rötung an der Palmarfläche des linken Zeigefingers
       <renderMultiMedia referencedObject="MM1"/>
         <caption>Roter Fleck am linken Zeigefinger</caption>
       </renderMultiMedia>
    </text>
    <entry>
       <observationMedia classCode="OBS" moodCode="EVN" ID="MM1">
       <!-- ELGA EingebettetesObjekt-Entry -->
       <templateId root="1.2.40.0.34.11.1.3.1"/>
         <value
            mediaType="image/jpeg"
            representation="B64">
          JVBEi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyI
          C9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM1aW28dtxFGnLfzK/ap3S0ihveLU
          AQYydprBSJcJICNvqgu1TrSI4kN0H+bF76M/LQ4S7Jmd3DlY/kg6IO4NBDch
          e0opgNXrv2p40zBn/YAZU0HLR+cb3lnW Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ
            :      :      :
         </value>
       </observationMedia>
     </entry>
</section>

8.1.7.2 Spezifikation

Siehe „ELGA EingebettetesObjekt-Entry“.

8.1.7.3 Zugelassene mediaType Attribut-Werte

Der Datentyp von Multimedia-Objekten ist immer ED (encapsulated data). Dabei ist auch der Medientyp (MIME) im entsprechenden @mediaType Attribut zu nennen.

Zulässige Werte gemäß Value-Set „ELGA_Medientyp“

Verweis auf speziellen Implementierungsleitfaden:
Spezielle Implementierungsleitfäden können zusätzliche Medientypen (MIME) erlauben.

Achtung: Grafiken mit Transparenz (z.B: bei GIF oder PNG möglich) können zu schweren Problemen bei der Wiedergabe oder Konvertierung zu PDF/A-1 führen und sind daher NICHT ERLAUBT.

8.2 CDA Body in EIS „Basic“

Neben den allgemein gültigen Aussagen über den grundsätzlichen Aufbau eines CDA Body, spezifiziert dieser Allgemeine Implementierungsleitfaden auch die Vorgaben, die ein ELGA Dokument in Interoperabilitätsstufe EIS „Basic“ erfüllen muss.

8.2.1 Dokumente gemäß dem Allgemeinen Implementierungsleitfaden (EIS „Basic“)

Damit ein Dokument im medizinischen Bereich (CDA Body) diesem Leitfaden entspricht, müssen keine besonderen Vorgaben eingehalten werden.

Der CDA Body kann unstrukturiert („nonXMLBody“) oder strukturiert („structuredBody“) angegeben werden. Die grundsätzlichen Richtlinien von CDA sind einzuhalten.

Siehe „Allgemeiner Aufbau des CDA Body“.

Verweis auf speziellen Implementierungsleitfaden:
Existiert bereits ein spezieller Implementierungsleitfaden zur Dokumentklasse, (z.B. Entlassungsbrief, Laborbefund etc.), MUSS dieser angewandt werden. Spezielle Leitfäden definieren gegebenenfalls zusätzliche Vorgaben sowohl im administrativen Bereich („CDA Header“) als auch im medizinischen Bereich („CDA Body“), wie beispielsweise:

Welche Art von CDA Body ist zugelassen (nonXMLBody, structuredBody)
Welche Sektionen sind anzugeben (verpflichtend, optional)
Sektionendetails (Code und Titel der Sektionen)
In welcher Granularität soll die Sektion angegeben werden (mit maschinenlesbaren Einträgen)
Welche Codelisten werden für die maschinenlesbaren Einträge verwendet
Reihenfolge der Sektionen im Dokument
etc.

8.3 Allgemeine Sektionen-Templates

Dieses Kapitel beschreibt ELGA Sektionen-Templates, die von mehr als einem speziellen Implementierungsleitfaden verwendet werden.

8.3.1 Brieftext

8.3.1.1 Überblick

	EIS „Enhanced“ und „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.1.2.1
Parent Template ID	-
Titel der Sektion	Brieftext
Definition	Ein am Anfang des Briefes formulierter Freitext für eine Anrede oder Begrüßung. Die Angabe von medizinisch fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT. Bsp: „Danke für die Zuweisung …“
Codierung	ELGA: BRIEFT, „Brieftext“
Konformität	[O]
Konformität Level 3	[O] (falls ein Logo angegeben wird)

8.3.1.2 Spezifikation

8.3.1.2.1 Sektion Allgemein

Id

1.2.40.0.34.11.1.2.1

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

Brieftext

Bezeichnung

Brieftext

Beschreibung

Ein am Anfang des Briefes formulierter Freitext für eine Anrede oder Begrüßung. Die Angabe von medizinisch fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.1

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.1.3.2	Containment	Logo Entry	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.2.1 Brieftext (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section classCode="DOCSECT">
  
  <templateId root="1.2.40.0.34.11.1.2.1"/>  
  <code code="BRIEFT" displayName="Brieftext" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  
  <title>Brieftext</title>  
  <text/>  
  <entry>
    <templateId root="1.2.40.0.34.11.1.3.2"/>  </entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe des Brieftexts.

(Bri...ext)

@classCode

cs

0 … 1

F

DOCSECT

hl7:templateId

II

1 … 1

R

(Bri...ext)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.1

hl7:code

CE

1 … 1

M

Code der Sektion.

(Bri...ext)

@code

CONF

1 … 1

F

BRIEFT

@codeSystem

1 … 1

F

1.2.40.0.34.5.40

@displayName

1 … 1

F

Brieftext

hl7:title

ST

1 … 1

R

(Bri...ext)

CONF

Elementinhalt muss "Brieftext" sein

hl7:text

1 … 1

R

Information für den menschlichen Leser.
Achtung: Wird ein Logo als maschinenlesbares Element angegeben, darf keine Referenz darauf im narrativen Text-Bereich angegeben werden (<renderMultiMedia referencedObject="…"/>).

(Bri...ext)

hl7:entry

0 … 1

Es KANN zusätzlich ein Logo als maschinenlesbares Element angegeben werden.
Maschinenlesbares Element gemäß Template „ELGA Logo-Entry“ (1.2.40.0.34.11.1.3.2).
Beinhaltet 1.2.40.0.34.11.1.3.2 Logo Entry (DYNAMIC)

(Bri...ext)

Der Titel dieser Sektion wird vom ELGA Referenz-Stylesheet nicht angezeigt, das Logo wird speziell platziert. Andere CDA-Stylesheets könnten den Titel der Sektion anzeigen und das Logo direkt im Text der Sektion darstellen.

8.3.2 Abschließende Bemerkungen

8.3.2.1 Überblick

	EIS „Enhanced“ und „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.1.2.2
Parent Template ID	-
Titel der Sektion	Abschließende Bemerkungen
Definition	Ein am Ende des Briefes formulierter Freitext entsprechend einer Grußformel. Die Angabe von medizinisch fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT. z.B. Abschließende Worte, Gruß
Codierung	ELGA: ABBEM, „Abschließende Bemerkungen“
Konformität	[O]
Konformität Level 3	[NP]

8.3.2.2 Spezifikation

Id

1.2.40.0.34.11.1.2.2

ref

elgabbr-

Gültigkeit

2012‑07‑14

Status

Aktiv

Versions-Label

Name

AbschliessendeBemerkung

Bezeichnung

AbschliessendeBemerkung

Beschreibung

Ein am Ende des Briefes formulierter Freitext entsprechend einer Grußformel.
Die Angabe von medizinisch fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.2

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.1.3.1	Containment	Eingebettetes Objekt Entry	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.2.2 AbschliessendeBemerkung (2012‑07‑14)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  
  <templateId root="1.2.40.0.34.11.1.2.2"/>  
  <code code="ABBEM" displayName="Abschließende Bemerkungen" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  
  <title>Abschließende Bemerkungen</title>  
  <text> ... Lesbarer Textbereich ... </text></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe der abschließenden Bemerkungen.

(Abs...ung)

hl7:templateId

II

1 … 1

R

(Abs...ung)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.2

hl7:code

CE

1 … 1

M

(Abs...ung)

@code

CONF

1 … 1

F

ABBEM

@codeSystem

1 … 1

F

1.2.40.0.34.5.40

@displayName

1 … 1

F

Abschließende Bemerkungen

hl7:title

ST

1 … 1

R

(Abs...ung)

CONF

Elementinhalt muss "Abschließende Bemerkungen" sein

hl7:text

ST

1 … 1

R

Information für den menschlichen Leser.

(Abs...ung)

hl7:entry

0 … *

R

Beinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)

(Abs...ung)

Der Titel dieser Sektion wird vom ELGA Referenz-Stylesheet nicht angezeigt. Andere CDA-Stylesheets könnten den Titel der Sektion anzeigen.

8.3.3 Beilagen

8.3.3.1 Überblick

	EIS „Enhanced“ und „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.1.2.3
Parent Template ID	-
Titel der Sektion	Beilagen
Definition	Sonstige Beilagen, außer denjenigen Dokumenten, die in „Patientenverfügungen und andere juridische Dokumente“ oder "Beigelegte erhobene Befunde" angegeben sind. Achtung: Ein „Referenzieren“ auf Beilagen ist NICHT ERLAUBT. Beigelegte Dokumente/Bilder MÜSSEN dem Dokument in technisch eingebetteter Form beiliegen.
Codierung	ELGA: BEIL, „Beilagen“
Konformität	[O]
Konformität Level 3	[M]

8.3.3.1.1 Spezifikation

Id

1.2.40.0.34.11.1.2.3

ref

elgabbr-

Gültigkeit

2015‑04‑23

Andere Versionen mit dieser Id:

Beilagen vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

Beilagen

Bezeichnung

Beilagen

Beschreibung

Sonstige Beilagen, außer denjenigen Dokumenten, die in „Patientenverfügungen und andere juridische Dokumente“ angegeben sind.

Achtung: Ein „Referenzieren“ auf Beilagen ist NICHT ERLAUBT. Beigelegte Dokumente/Bilder MÜSSEN dem Dokument in technisch eingebetteter Form beiliegen.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.3

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.1.3.1	Containment	Eingebettetes Objekt Entry	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.2.3 Beilagen (2015‑04‑23)

ref

elgabbr-

Beispiel

<section>
  
  <templateId root="1.2.40.0.34.11.1.2.3"/>  
  <code code="BEIL" displayName="Beilagen" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  
  <title>Beilagen</title>  
  <text> ... Lesbarer Textbereich ... </text>  
  <entry>
    
    <templateId root="1.2.40.0.34.11.1.3.1"/>  </entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe der Beilagen.

(Bei...gen)

hl7:templateId

II

1 … 1

R

(Bei...gen)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.3

hl7:code

CE

1 … 1

M

(Bei...gen)

@code

CONF

1 … 1

F

BEIL

@codeSystem

1 … 1

F

1.2.40.0.34.5.40

hl7:title

ST

1 … 1

R

(Bei...gen)

CONF

Elementinhalt muss "Beilagen" sein

hl7:text

SD.TEXT

1 … 1

R

Information für den menschlichen Leser.

Die Vorgaben und Empfehlungen zur Gestaltung dieses Bereichs im Falle von CDA Level 3 sind zu beachten!

(Bei...gen)

hl7:entry

1 … *

R

Maschinenlesbares Element.
Die Vorgaben und Empfehlungen zur Gestaltung dieses Bereichs im Falle von CDA Level 3 sind zu beachten!
Beinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)

(Bei...gen)

8.3.3.1.2 Textbereich der Sektion

Vorgaben und Empfehlungen zur Gestaltung des Textbereichs der Sektion im Falle des Vorhandenseins von maschinenlesbaren Elementen (CDA Level 3):

Vorgaben
- Es SOLLEN der Titel des Dokuments, sowie das Erstellungsdatum angegeben werden
Empfehlungen
- -

8.3.3.1.3 Maschinenlesbare Elemente der Sektion

Die Beilagen MÜSSEN als maschinenlesbare Elemente angegeben werden.

8.3.4 Patientenverfügungen und andere juridische Dokumente

8.3.4.1 Überblick

	EIS „Enhanced“ und „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.1.2.4
Parent Template ID	IHE PCC Advance Directives Section: 1.3.6.1.4.1.19376.1.5.3.1.3.34 HL7 CCD 3.2: 2.16.840.1.113883.10.20.1.1
Titel der Sektion	Patientenverfügungen und andere juridische Dokumente
Definition	Alle Patientenverfügungen und diejenigen juridischen Dokumente, welche als „wichtig“ erachtet werden. Die Aufstellung SOLL narrativ in tabellarischer Form erfolgen und die „Art des vorliegenden Dokuments“, sowie den Hinweis „wo dieses aufliegt“ enthalten. Beispiel: „Testament“ – „liegt bei Tochter auf“
Codierung	LOINC: 42348-3, „Advance directives“
Konformität	[O]
Konformität Level 3	[NP]

8.3.4.2 Spezifikation

Id

1.2.40.0.34.11.1.2.4

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

Patientenverfuegung

Bezeichnung

Patientenverfügung

Beschreibung

Diese Sektion enthält Hinweise auf Willenserklärungen des Patienten wie Patientenverfügung, Transplantationswiderspruch, Vorsorgevollmacht, sowie diejenigen juridischen Dokumente, welche als relevant erachtet werden.

Die Aufstellung SOLL narrativ in tabellarischer Form erfolgen und die „Art des vorliegenden Dokuments“, sowie einen Hinweis enthalten, wo dieses aufliegt.

Beispiel: „Patientenverfügung – wird von der Tochter aufbewahrt (Name, Adresse)“

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.4

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.1.2.4 Patientenverfügung (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  <templateId root="1.2.40.0.34.11.1.2.4"/>  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.34"/>  
  <templateId root="2.16.840.1.113883.10.20.1.1"/>  
  
  <code code="42348-3" displayName="Advance directives" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  
  <title>Patientenverfügungen und andere juridische Dokumente</title>  <text> ... Lesbarer Textbereich ... </text></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe der Patientenverfügungen und anderer juridischer Dokumente.

(Pat...ung)

hl7:templateId

II

1 … 1

R

(Pat...ung)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.4

hl7:templateId

II

1 … 1

R

(Pat...ung)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.3.34

hl7:templateId

II

1 … 1

R

(Pat...ung)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.1

hl7:code

CE (extensible)

1 … 1

M

(Pat...ung)

@code

CONF

1 … 1

F

42348-3

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Advance directives

hl7:title

ST

1 … 1

R

(Pat...ung)

CONF

Elementinhalt muss "Patientenverfügungen und andere juridische Dokumente" sein

hl7:text

1 … 1

R

Information für den menschlichen Leser, tabellarische Auflistung der Willenserklärungen

(Pat...ung)

8.3.5 Anmerkungen

8.3.5.1 Überblick

	EIS „Enhanced“ und „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.1.2.5
Parent Template ID	-
Titel der Sektion	Anmerkungen
Definition	Ein Freitext für beliebige weitere nicht-medizinische Anmerkungen zum Patienten. Der Text soll keine fachlich relevante Information beinhalten. z.B. „Die Patientin mag besonders Kamelien.“
Codierung	ELGA: ANM, „Anmerkungen“
Konformität	[O]
Konformität Level 3	[NP]

8.3.5.2 Spezifikation

Id

1.2.40.0.34.11.1.2.5

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

Anmerkungen

Bezeichnung

Anmerkungen

Beschreibung

Ein Freitext für beliebige weitere nicht-medizinische Anmerkungen zum Patienten. Der Text soll keine fachlich relevante Information beinhalten.
z.B. „Die Patientin mag besonders Kamelien.“

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.5

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-178	Anmerkungen	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.1.2.5 Anmerkungen (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  <templateId root="1.2.40.0.34.11.1.2.5"/>  
  <code code="ANM" displayName="Anmerkungen" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  
  <title>Anmerkungen</title>  
  <text> ... Lesbarer Textbereich ... </text></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe der Anmerkungen.

(Anm...gen)


	elgagab-dataelement-178	Anmerkungen	Datensatz

hl7:templateId

II

1 … 1

R

(Anm...gen)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.5

hl7:code

CE

1 … 1

M

(Anm...gen)

@code

CONF

1 … 1

F

ANM

@codeSystem

1 … 1

F

1.2.40.0.34.5.40

@displayName

1 … 1

F

Anmerkungen

hl7:title

ST

1 … 1

R

(Anm...gen)

CONF

Elementinhalt muss "Anmerkungen" sein

hl7:text

1 … 1

R

Information für den menschlichen Leser.

(Anm...gen)

8.3.6 Vitalparameter

8.3.6.1 Überblick

	EIS „Enhanced“	„Full Support“
Template ID	ELGA: 1.2.40.0.34.11.1.2.6	ELGA: 1.2.40.0.34.11.1.2.7
Parent Template ID	IHE PCC Vital Signs Section: 1.3.6.1.4.1.19376.1.5.3.1.3.25 HL7 CCD 3.12: 2.16.840.1.113883.10.20.1.16	IHE PCC Coded Vital Signs Section: 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2 IHE PCC Vital Signs Section: 1.3.6.1.4.1.19376.1.5.3.1.3.25 HL7 CCD 3.12: 2.16.840.1.113883.10.20.1.16
Titel der Sektion	Vitalparameter
Definition	Informationen zu den Vitalparametern (Körpertemperatur, Puls, Blutdruck …). Diese Sektion wird hauptsächlich bei Verlegungen von Pflegeheimen in Krankenhäusern oder in Notfällen angewandt.
Codierung	LOINC: 8716-3, „Vital signs“
Konformität	[O]
Konformität Level 3	[NP] ELGA VitalparameterGruppe-Entry (1.2.40.0.34.11.1.3.3)	[M] ELGA VitalparameterGruppe-Entry (1.2.40.0.34.11.1.3.3)

8.3.6.2 Spezifikation

Vitalparameter (alle EIS)

Id

1.2.40.0.34.11.30002

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

VitalparameterAlleEIS

Bezeichnung

Vitalparameter (alle EIS)

Beschreibung

Informationen zu den Vitalparametern (Körpertemperatur, Puls, Blutdruck …).

Diese Sektion wird hauptsächlich bei Verlegungen von Pflegeheimen in Krankenhäusern oder in Notfällen angewandt.

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.30002 Vitalparameter (alle EIS) (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  
  <templateId root="1.2.40.0.34.11.1.2.6"/>  
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.25"/>  
  <templateId root="2.16.840.1.113883.10.20.1.16"/>  
   … oder …   
  <templateId root="1.2.40.0.34.11.1.2.7"/>  
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2"/>  
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.25"/>  
  <templateId root="2.16.840.1.113883.10.20.1.16"/>  
  
  <code code="8716-3" displayName="Vital signs" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  
  <title>Vitalparameter</title>  
  <text> ... Lesbarer Textbereich ... </text>  
  <entry>
     :     
    <templateId root="1.2.40.0.34.11.1.3.3"/>     :   </entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:code

CE

1 … 1

M

Code der Sektion.

(Vit...EIS)

@code

CONF

1 … 1

F

8716-3

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

hl7:title

ST

1 … 1

R

(Vit...EIS)

CONF

Elementinhalt muss "Vitalparameter" sein

hl7:text

1 … 1

R

Information für den menschlichen Leser.

Die Vorgaben und Empfehlungen zur Gestaltung dieses Bereichs im Falle von CDA Level 3 sind zu beachten!

(Vit...EIS)

Vitalparameter (enhanced)

Id

1.2.40.0.34.11.1.2.6

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

VitalparameterEnhanced

Bezeichnung

Vitalparameter (enhanced)

Beschreibung

Informationen zu den Vitalparametern (Körpertemperatur, Puls, Blutdruck, …).
Diese Sektion wird hauptsächlich bei Verlegungen von Pflegeheimen in Krankenhäuser oder in Notfällen angewandt.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.6

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.30002	Inklusion	Vitalparameter (alle EIS)	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.2.6 Vitalparameter (enhanced) (2011‑12‑19)

ref

elgabbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe der Vitalparameter.

(Vit...ced)

hl7:templateId

II

1 … 1

R

(Vit...ced)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.6

hl7:templateId

II

1 … 1

R

(Vit...ced)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.3.25

hl7:templateId

II

1 … 1

R

(Vit...ced)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.16

Eingefügt

von 1.2.40.0.34.11.30002 Vitalparameter (alle EIS) (DYNAMIC)

hl7:code

CE

1 … 1

M

Code der Sektion.

(Vit...ced)

@code

CONF

1 … 1

F

8716-3

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

hl7:title

ST

1 … 1

R

(Vit...ced)

CONF

Elementinhalt muss "Vitalparameter" sein

hl7:text

1 … 1

R

Information für den menschlichen Leser.

Die Vorgaben und Empfehlungen zur Gestaltung dieses Bereichs im Falle von CDA Level 3 sind zu beachten!

(Vit...ced)

hl7:entry

NP

(Vit...ced)

Vitalparameter (full)

Id

1.2.40.0.34.11.1.2.7

ref

elgabbr-

Gültigkeit

2017‑02‑20

Andere Versionen mit dieser Id:

VitalparameterFull vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

VitalparameterFull

Bezeichnung

Vitalparameter (full)

Beschreibung

Informationen zu den Vitalparametern (Körpertemperatur, Puls, Blutdruck …).

Diese Sektion wird hauptsächlich bei Verlegungen von Pflegeheimen in Krankenhäusern oder in Notfällen angewandt.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.7

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 3 Konzepte

Id	Name	Datensatz
exnds-dataelement1-14	Groesse	Test2 2019
exnds-dataelement1-15	Gewicht	Test2 2019
	Vitalwerte	Test2 2019

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.30002	Inklusion	Vitalparameter (alle EIS)	DYNAMIC
1.2.40.0.34.11.1.3.3	Containment	Vitalparameter Gruppe Entry	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.2.7 Vitalparameter (full) (2017‑02‑20)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  <templateId root="1.2.40.0.34.11.1.2.7"/>  
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2"/>  
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.25"/>  
  <templateId root="2.16.840.1.113883.10.20.1.16"/>  
  
  <code code="8716-3" displayName="Vital signs" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  
  <title>Vitalparameter</title>  
  <text> ... Lesbarer Textbereich ... </text>  
  <entry>
    
    <templateId root="1.2.40.0.34.11.1.3.3"/>  </entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe der Vitalparameter.

(Vit...ull)


exnds-dataelement1-14	Groesse	Test2 2019
exnds-dataelement1-15	Gewicht	Test2 2019
	Vitalwerte	Test2 2019

hl7:templateId

II

1 … 1

R

(Vit...ull)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.7

hl7:templateId

II

1 … 1

R

(Vit...ull)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2

hl7:templateId

II

1 … 1

R

(Vit...ull)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.3.25

hl7:templateId

II

1 … 1

R

(Vit...ull)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.16

Eingefügt

von 1.2.40.0.34.11.30002 Vitalparameter (alle EIS) (DYNAMIC)

hl7:code

CE

1 … 1

M

Code der Sektion.

(Vit...ull)

@code

CONF

1 … 1

F

8716-3

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

hl7:title

ST

1 … 1

R

(Vit...ull)

CONF

Elementinhalt muss "Vitalparameter" sein

hl7:text

1 … 1

R

Information für den menschlichen Leser.

Die Vorgaben und Empfehlungen zur Gestaltung dieses Bereichs im Falle von CDA Level 3 sind zu beachten!

(Vit...ull)

hl7:entry

1 … *

R

Maschinenlesbares Element.
Beinhaltet 1.2.40.0.34.11.1.3.3 Vitalparameter Gruppe Entry (DYNAMIC)

(Vit...ull)

@typeCode

cs

0 … 1

F

DRIV

8.3.6.2.1 Vorgaben und Empfehlungen zur Gestaltung im Falle von CDA Level 3

Vorgaben und Empfehlungen zur Gestaltung des Textbereichs der Sektion im Falle des Vorhandenseins von maschinenlesbaren Elementen (CDA Level 3):

Vorgaben
- Darstellung der Vitalparameter in Tabellenform
- Reihenfolge der Informationen:
  - Vitalparameterart (@displayName des Codes des Vitalparameter-Entry)
  - Wert (@value des Werts des Vitalparameter-Entry)
  - Einheit (@unit des Werts des Vitalparameter-Entry)
- Das Erhebungsdatum SOLL den Vitalparametern eindeutig zugeordnet werden (Erhebungsdatum des VitalparameterGruppe-Entry)
Empfehlungen
- -

8.3.6.2.2 Maschinenlesbare Elemente der Sektion

Im Falle von EIS „Full Support“ KÖNNEN zusätzlich maschinenlesbare Elemente angegeben werden.

8.3.7 Risiken

8.3.7.1 Überblick

	EIS „Enhanced“ und „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.1.2.8
Parent Template ID	-
Titel der Sektion	Risiken
Definition	Wird ausschließlich als Untersektion zu einer fachlichen Sektion angewandt. Enthält die Risiken zum Thema der übergeordneten Sektion als narrative Beschreibung oder Auflistung.
Codierung	LOINC: 51898-5, „Risk factors“
Konformität	[O]
Konformität Level 3	[NP]

8.3.7.2 Spezifikation

Id

1.2.40.0.34.11.1.2.8

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

Risiken

Bezeichnung

Risiken

Beschreibung

Wird ausschließlich als Untersektion zu einer fachlichen Sektion angewandt.
Enthält die Risiken zum Thema der übergeordneten Sektion als narrative Beschreibung oder Auflistung.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.8

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.1.2.8 Risiken (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  <templateId root="1.2.40.0.34.11.1.2.8"/>  
  <code code="51898-5" displayName="Risk factors" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  
  <title>Risiken</title>  
  <text> ... Lesbarer Textbereich ... </text></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe der Risiken.

(Risiken)

hl7:templateId

II

1 … 1

R

(Risiken)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.8

hl7:code

CE

1 … 1

M

(Risiken)

@code

CONF

1 … 1

F

51898-5

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

hl7:title

ST

1 … 1

R

(Risiken)

CONF

Elementinhalt muss "Risiken" sein

hl7:text

1 … 1

R

Information für den menschlichen Leser.

(Risiken)

8.3.8 Hilfsmittel und Ressourcen

8.3.8.1 Überblick

	EIS „Enhanced“ und „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.1.2.9
Parent Template ID	-
Titel der Sektion	Hilfsmittel und Ressourcen
Definition	Wird ausschließlich als Untersektion zu einer fachlichen Sektion angewandt. Enthält die Hilfsmittel und Ressourcen zum Thema der übergeordneten Sektion als narrative Beschreibung oder Auflistung.
Codierung	ELGA: RES, „Hilfsmittel und Ressourcen“
Konformität	[O]
Konformität Level 3	[NP]

8.3.8.2 Spezifikation

Id

1.2.40.0.34.11.1.2.9

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

HilfsmittelRessourcen

Bezeichnung

Hilfsmittel und Ressourcen

Beschreibung

Wird ausschließlich als Untersektion zu einer fachlichen Sektion angewandt.

Enthält die Hilfsmittel und Ressourcen zum Thema der übergeordneten Sektion als narrative Beschreibung oder Auflistung.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.9

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.1.2.9 Hilfsmittel und Ressourcen (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  <templateId root="1.2.40.0.34.11.1.2.9"/>  
  <code code="RES" displayName="Hilfsmittel und Ressourcen" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  
  <title>Hilfsmittel und Ressourcen</title>  
  <text> ... Lesbarer Textbereich ... </text></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

Container zur Angabe der Hilfsmittel und Ressourcen.

(Hil...cen)

hl7:templateId

II

1 … 1

R

(Hil...cen)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.2.9

hl7:code

CE

1 … 1

M

(Hil...cen)

@code

CONF

1 … 1

F

RES

@codeSystem

1 … 1

F

1.2.40.0.34.5.40

@displayName

1 … 1

F

Hilfsmittel und Ressourcen

hl7:title

ST

1 … 1

R

(Hil...cen)

CONF

Elementinhalt muss "Hilfsmittel und Ressourcen" sein

hl7:text

1 … 1

R

Information für den menschlichen Leser.

(Hil...cen)

8.4 Maschinenlesbare Elemente

Dieses Kapitel beschreibt ELGA Entry-Templates, die von mehr als einem speziellen Implementierungsleitfaden verwendet werden.

8.4.1 ELGA EingebettetesObjekt-Entry

Template ID	ELGA: 1.2.40.0.34.11.1.3.1
Parent Template ID	-

8.4.1.1 ELGA EingebettetesObjekt-Entry

8.4.1.2 Spezifikation

Id

1.2.40.0.34.11.1.3.1

ref

elgabbr-

Gültigkeit

2017‑05‑05

Andere Versionen mit dieser Id:

EingebettetesObjektEntry vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

EingebettetesObjektEntry

Bezeichnung

Eingebettetes Objekt Entry

Beschreibung

Achtung: Grafiken mit Transparenz (z.B: bei GIF oder PNG möglich) können zu schweren Problemen bei der Wiedergabe oder Konvertierung zu PDF/A-1 führen und sind daher NICHT ERLAUBT

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.3.1

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (2017‑05‑05)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<observationMedia classCode="OBS" moodCode="EVN" ID="Beilage-1">
<templateId root="1.2.40.0.34.11.1.3.1"/> <value mediaType="application/pdf" representation="B64"> JVBEi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyI C9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM1aW28dtxFGnLfzK/ap3S0ihveLU
AQYydprBSJcJICNvqgu1TrSI4kN0H+bF76M/LQ4S7Jmd3DlY/kg6IO4NBDch M5z5OHt+bjgTznIVGh7/o/84Xi0+PwjN+d3i54Vh1nNjezltH6+a50sYJngj AuOu2Z5thB9n2gcZ55r2XjoEzBjuVq0Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ90 e0opgNXrv2p40zBn/YAZU0HLR+cb3lnW Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ : : : </value></observationMedia>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observationMedia

1 … 1

R

Container zur Angabe eines eingebetteten Objekts.

(Ein...try)

@classCode

cs

1 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

@ID

1 … 1

R

ID des eingebetteten Objekts.
Wird vom Element <render-MultiMedia referencedObject=" "/> im narrativen Text-Bereich referenziert.

hl7:templateId

II

1 … 1

M

(Ein...try)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.3.1

hl7:value

ED

1 … 1

M

Das eingebettete Objekt (PDF, Bild), unkomprimiert, Base64 enkodiert.

Siehe „Größenbeschränkung von eingebetteten Objekten“

(Ein...try)

@mediaType

cs

1 … 1

R

Medientyp des eingebetteten Objekts.

Zulässige Werte gemäß Value-Set „ELGA_Medientyp“

Verweis auf speziellen Implementierungsleitfaden:

Spezielle Implementierungsleitfäden können zusätzliche Medientypen (MIME) erlauben.

CONF

Der Wert von @mediaType muss gewählt werden aus dem Value Set 1.2.40.0.34.10.42 ELGA_Medientyp (DYNAMIC)

@representation

cs

1 … 1

F

B64

Zur Größe der eingebetteten Dateien siehe „Größenbeschränkung von eingebetteten Objekten“

8.4.2 ELGA Logo-Entry

Template ID	ELGA: 1.2.40.0.34.11.1.3.2
Parent Template ID	-

8.4.2.1 Spezifikation

Id

1.2.40.0.34.11.1.3.2

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

LogoEntry

Bezeichnung

Logo Entry

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.3.2

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.1.3.2 Logo Entry (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<entry>
  <observationMedia classCode="OBS" moodCode="EVN">
    
    <templateId root="1.2.40.0.34.11.1.3.2"/>    <value mediaType="image/jpeg" representation="B64"> JVBEi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyI C9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM1aW28dtxFGnLfzK/ap3S0ihveLU AQYydprBSJcJICNvqgu1TrSI4kN0H+bF76M/LQ4S7Jmd3DlY/kg6IO4NBDch M5z5OHt+bjgTznIVGh7/o/84Xi0+PwjN+d3i54Vh1nNjezltH6+a50sYJngj
AuOu2Z5thB9n2gcZ55r2XjoEzBjuVq0Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ90 e0opgNXrv2p40zBn/YAZU0HLR+cb3lnW Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ : : : </value>  </observationMedia></entry>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observationMedia

1 … 1

R

(Log...try)

@classCode

cs

1 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

R

(Log...try)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.3.2

hl7:value

ED

1 … 1

M

Das eingebettete Logo in einem Bildformat, unkomprimiert, Base64 enkodiert.

Maximale Abmessungen des Bildes:

•Höhe: 80px

•Breite: 270px

(Log...try)

@mediaType

st

1 … 1

R

Medientyp des eingebetteten Objekts gemäß zugelassener Werteliste:

•image/png

•image/jpeg

@representation

cs

1 … 1

F

B64

8.4.3 ELGA VitalparameterGruppe-Entry

Template ID	ELGA: 1.2.40.0.34.11.1.3.3
Parent Template ID	IHE PCC Vital Signs Organizer Entry: 1.3.6.1.4.1.19376.1.5.3.1.4.13.1 HL7 CCD 3.13: 2.16.840.1.113883.10.20.1.32 HL7 CCD 3.12: 2.16.840.1.113883.10.20.1.35

8.4.3.1 Spezifikation

Id

1.2.40.0.34.11.1.3.3

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Entwurf

Versions-Label

Name

VitalparameterGruppeEntry

Bezeichnung

Vitalparameter Gruppe Entry

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.3.3

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.1.3.4	Containment	Vitalparameter Entry	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.3.3 Vitalparameter Gruppe Entry (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:organizer

1 … 1

M

(Vit...try)

@classCode

cs

1 … 1

F

CLUSTER

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

R

ELGA

(Vit...try)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.3.3

hl7:templateId

II

1 … 1

R

HL7 CCD 3.13

(Vit...try)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.32

hl7:templateId

II

1 … 1

R

HL7 CCD 3.12

(Vit...try)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.35

hl7:templateId

II

1 … 1

R

IHE PCC Vital Signs Organizer Entry

(Vit...try)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.13.1

hl7:id

1 … 1

R

ID der VitalparameterGruppe.

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

(Vit...try)

hl7:code

CE

1 … 1

M

Code des VitalparameterGruppe-Entry.

(Vit...try)

@code

CONF

1 … 1

F

46680005

@codeSystem

1 … 1

F

2.16.840.1.113883.6.96 (SNOMED Clinical Terms)

hl7:statusCode

CS

1 … 1

M

(Vit...try)

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Erhebungsdatum.

Zugelassene nullFlavor: UNK

(Vit...try)

Constraint

Wenn in allen untergeordneten Kind-Elementen observation/effectiveTime angeführt wird KANN, R [0..1] dieses Element mit /low/@nullFlavor == "UNK" und /high/@nullFlavor == "UNK" strukturiert sein oder komplett entfallen.

Wenn nicht in allen untergeordneten Kind-Elementen observation/effectiveTime angeführt wird MUSS, R [1..1] dieses Element angegeben werden und KANN mittels /low/@nullFlavor == "UNK" und /high/@nullFlavor == "UNK" strukturiert sein.

hl7:component

1 … *

M

ELGA Vitalparameter-Entry.
Beinhaltet 1.2.40.0.34.11.1.3.4 Vitalparameter Entry (DYNAMIC)

(Vit...try)

8.4.3.1.1 Vitalparameter (component)

Jeder Vitalparameter ist als Komponente der Vitalparametergruppe angeführt. Es MUSS mindestens ein Vitalparameter angegeben werden.

Jeder Vitalparameter des ELGA VitalparameterGruppe-Entry ist in Form eines ELGA Vitalparameter-Entry (1.2.40.0.34.11.1.3.4) anzugeben.

8.4.4 ELGA Vitalparameter-Entry

Template ID	ELGA: 1.2.40.0.34.11.1.3.4
Parent Template ID	IHE PCC Simple Observation Entry: 1.3.6.1.4.1.19376.1.5.3.1.4.13 IHE PCC Vital Signs Observation Entry: 1.3.6.1.4.1.19376.1.5.3.1.4.13.2 HL7 CCD 3.13: 2.16.840.1.113883.10.20.1.31

8.4.4.1 Spezifikation

Id

1.2.40.0.34.11.1.3.4

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Entwurf

Versions-Label

Name

VitalparameterEntry

Bezeichnung

Vitalparameter Entry

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.3.4

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.1.3.4 Vitalparameter Entry (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

<hl7:ClinicalDocument>
  <cda:observation classCode="OBS" moodCode="EVN">
    
    <cda:templateId root="1.2.40.0.34.11.1.3.4"/>    
    <cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>    
    <cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13.2"/>    
    <cda:templateId root="2.16.840.1.113883.10.20.1.31"/>    
    <cda:id root=" " extension=" "/>    
    <cda:code code="2710-2" displayName="Oxygen saturation in Capillary blood by Oximetry" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC">
      <cda:originalText>
        <cda:reference value="#vitsigtype-1"/>      </cda:originalText>    </cda:code>    
    <cda:text>
      <cda:reference value="tel:+1-12345678"/>    </cda:text>    
    <cda:statusCode code="completed"/>    
    <cda:value xsi:type="PQ" value="120" unit="/min"/>  </cda:observation></hl7:ClinicalDocument>

Beispiel

Keine Vitalparameter erhoben

<cda:observation classCode="OBS" moodCode="EVN">
  <cda:templateId root="1.2.40.0.34.6.0.11.3.24"/>  <cda:templateId root="2.16.840.1.113883.10.20.1.31"/>  <cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>  <cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13.2"/>  
  <cda:id root=" " extension=" "/>  
  <cda:code code="373121007" displayName="Test not done" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT">
    <cda:originalText>
      <cda:reference value="#vitsigtype-1"/>    </cda:originalText>  </cda:code>  
  <cda:text>
    <cda:reference value="#vitsig-1"/>  </cda:text>  
  <cda:statusCode code="completed"/>  
  <cda:value xsi:type="PQ" nullFlavor="NA"/></cda:observation>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

1 … 1

R

(Vit...try)

@classCode

cs

1 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

R

ELGA

(Vit...try)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.3.4

hl7:templateId

II

1 … 1

R

IHE PCC Simple Observation Entry

(Vit...try)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.13

hl7:templateId

II

1 … 1

R

IHE PCC Vital Signs Observation Entry

(Vit...try)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.13.2

hl7:templateId

II

1 … 1

R

HL7 CCD 3.13

(Vit...try)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.31

hl7:id

1 … 1

R

ID des Vitalparameters

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

(Vit...try)

hl7:code

CE

1 … 1

M

Code des Vitalparameters.

Die Art des angegebenen Vitalparameters (Puls, Blutdruck systolisch, etc.) wird codiert in diesem Element angegeben. Die Angabe der Art des Vitalparameters bestimmt auch die möglichen Einheiten des Werts.

Verweis auf speziellen Implementierungsleitfaden:

Welche der Vitalparameterarten angegeben werden müssen bzw. sollen, kann im jeweiligen speziellen Implementierungsleitfaden eingeschränkt werden.

(Vit...try)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.34 ELGA_Vitalparameterarten (DYNAMIC)

hl7:originalText

ED

1 … 1

M

Verweist auf die Stelle im narrativen Textbereich, in dem die Vitalparameterart beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).

(Vit...try)

hl7:text

ED

1 … 1

M

Verweist auf die Stelle im narrativen Text-Bereich, an der der gegebene Vitalparameter narrativ beschrieben ist (mit zusätzlichen Informationen, wie Datum, Beschreibung, etc).

(Vit...try)

hl7:reference

TEL

1 … 1

M

(Vit...try)

hl7:statusCode

CS

1 … 1

M

(Vit...try)

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Erhebungsdatum. Zugelassene nullFlavor: UNK

(Vit...try)

Constraint

Wenn im übergeordneten Container-Element organizer/effectiveTime angeführt wird KANN, R [0..1] dieses Element mit /low/@nullFlavor == "UNK" und /high/@nullFlavor == "UNK" strukturiert sein oder komplett entfallen.

Wenn im übergeordneten Container-Element organizer/effectiveTime NICHT angeführt wird MUSS, R [1..1] dieses Element angegeben werden und KANN mittels /low/@nullFlavor == "UNK" und /high/@nullFlavor == "UNK" strukturiert sein.

Auswahl

1 … 1

Wert des Vitalparameters.

Elemente in der Auswahl:

hl7:value[not(@nullFlavor)]
hl7:value[@nullFlavor='NA']

Constraint

Wenn kein Vitalparameter erhoben wurde (code/@code="373121007"), MUSS, M [1..1], value mit @nullFlavor="NA" strukturiert sein.

In allen anderen Fällen MUSS, M [1..1], value angegeben sein. Die Verwendung von @nullFlavor="NA" ist NICHT ERLAUBT.

hl7:value

PQ

0 … 1

(Vit...try)

wo [not(@nullFlavor)]

hl7:value

PQ

0 … 1

(Vit...try)

wo [@nullFlavor='NA']

@nullFlavor

cs

1 … 1

F

NA

8.4.5 ELGA Problem/Bedenken-Entry

Ein Problem/Bedenken ist eine Spezialisierung eines allgemeinen „Bedenkens“ (engl.: Concern, eine allgemeine Beschreibung von Problemen oder Allergien und Unverträglichkeiten) auf die Kategorie „Problem“.

Ein Problem/Bedenken-Entry erlaubt die Dokumentation der Geschichte eines Problems als eine Serie von Beobachtungen (engl.: Observation) von Problemen (siehe Kapitel „ELGA Problem-Entry“).

Template ID	ELGA: 1.2.40.0.34.11.1.3.5
Parent Template ID	IHE PCC Concern Entry: 1.3.6.1.4.1.19376.1.5.3.1.4.5.1 IHE PCC Problem Concern Entry: 1.3.6.1.4.1.19376.1.5.3.1.4.5.2 HL7 CCD 3.5: 2.16.840.1.113883.10.20.1.27

8.4.5.1 Spezifikation

Id

1.2.40.0.34.11.1.3.5

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

ProblemBedenkenEntry

Bezeichnung

Problem Bedenken Entry

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.3.5

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.1.3.6	Containment	Problem Entry	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.1.3.5 Problem Bedenken Entry (2011‑12‑19)

ref

elga-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:act

1 … 1

R

(Pro...try)

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

R

ELGA

(Pro...try)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.3.5

hl7:templateId

II

1 … 1

R

IHE PCC Concern Entry

(Pro...try)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.5.1

hl7:templateId

II

1 … 1

R

IHE PCC Problem Concern Entry

(Pro...try)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.5.2

hl7:templateId

II

1 … 1

R

HL7 CCD 3.5

(Pro...try)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.27

hl7:id

II

1 … 1

R

ID des Problem/Bedenken-Entry

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

(Pro...try)

hl7:code

CE

1 … 1

R

Code des Problem/Bedenken-Entry.

(Pro...try)

@nullFlavor

cs

1 … 1

F

NA

hl7:statusCode

CS

1 … 1

M

(Pro...try)

CONF

@code muss "active" sein

oder

@code muss "suspended" sein

oder

@code muss "completed" sein

oder

@code muss "aborted" sein

hl7:effectiveTime

1 … 1

R

Zeitintervall in dem das Problem/Bedenken existent war/ist.

Grundsätzlich sind die Vorgaben gemäß Kapitel 5.3, „Zeit-Elemente“ zu befolgen.

Anforderung in Abhängigkeit von „statusCode“:

Ist das Element statusCode auf „active“ oder „suspended“ gesetzt, MUSS das high-Element des Zeitintervalls weggelassen werden.

(Pro...try)

hl7:low

1 … 1

R

(Pro...try)

hl7:high

0 … 1

(Pro...try)

Schematron assert

role

error

test

count(hl7:statusCode[@code='active' or @code='suspended'])=0 or count(hl7:effectiveTime/hl7:high)=0

Meldung

Ist das Element statusCode auf „active“ oder „suspended“ gesetzt, muss das high-Element des Zeitintervalls weggelassen werden.

hl7:entryRelationship

1 … *

M

Das eigentliche Problem ist als Beziehung zum Problem/Bedenken angeführt. Es MUSS mindestens ein Problem angegeben werden.

Jedes Problem des ELGA Problem/Bedenken-Entry ist in Form eines ELGA Problem-Entry (1.2.40.0.34.11.1.3.6) anzugeben.

Beinhaltet 1.2.40.0.34.11.1.3.6 Problem Entry (DYNAMIC)

(Pro...try)

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

false

8.4.5.1.1 statusCode

Der statusCode zeigt den derzeitigen Zustand an, in dem sich das angegebene Problem/Bedenken befindet („aktiv“, „bereits beendet“ …). Die folgenden Zustände sind möglich:

active („Aktiv“)
- Beschreibung: Das Problem/Bedenken besteht noch und wird weiter beobachtet.
suspended („Ausgesetzt“)
- Beschreibung: Das Problem/Bedenken besteht noch, die Beobachtung wird aber derzeit ausgesetzt.
aborted („Abgebrochen“)
- Beschreibung: Das Problem/Bedenken besteht noch (nicht gelöst/beigelegt), wird jedoch nicht länger verfolgt.
completed („Abgeschlossen“)
- Beschreibung: Das Problem/Bedenken besteht nicht mehr und wird auch nicht länger verfolgt.

8.4.6 ELGA Problem-Entry

Ein Problem-Entry erlaubt die Dokumentation eines Problems über Beobachtungen (engl.: Observation) von:

Zuständen (Condition)
Symptomen (Symptom)
Befunden (Finding)
Beschwerden (Complaint)
Funktionellen Einschränkungen (Functional limitation)
Problemen (Problem)
Diagnosen (Diagnosis)

Template ID	ELGA: 1.2.40.0.34.11.1.3.6
Parent Template ID	IHE PCC Problem Entry: 1.3.6.1.4.1.19376.1.5.3.1.4.5 HL7 CCD 3.5: 2.16.840.1.113883.10.20.1.28

8.4.6.1 Spezifikation

Id

1.2.40.0.34.11.1.3.6

ref

elgabbr-

Gültigkeit

2019‑12‑05

Andere Versionen mit dieser Id:

ProblemEntry vom 2017‑02‑20
ProblemEntry vom 2015‑09‑24
ProblemEntry vom 2011‑12‑19

Status

Entwurf

Versions-Label

Name

ProblemEntry

Bezeichnung

Problem Entry

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.1.3.6

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.11.1.3.6 Problem Entry (2017‑02‑20)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.1.3.6 Problem Entry (2017‑02‑20)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

1 … 1

R

Container zur Angabe eines Problems.

(Pro...try)

@classCode

cs

1 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

@negationInd

bl

1 … 1

R

SOLL standardmäßig auf false gesetzt werden.

Kann auf true gesetzt werden, um anzuzeigen, dass das dokumentierte Problem nicht beobachtet wurde.

hl7:templateId

II

1 … 1

R

ELGA

(Pro...try)

@root

uid

1 … 1

F

1.2.40.0.34.11.1.3.6

hl7:templateId

II

1 … 1

R

IHE PCC Problem Entry

(Pro...try)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.5

hl7:templateId

II

1 … 1

R

HL7 CCD 3.5

(Pro...try)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.28

hl7:id

II

1 … 1

R

ID des Problem-Entry.

Auch wenn nur ein Problem-Entry angegeben ist, soll die ID von der ID des Problem/Bedenken-Entry unterscheiden.

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

(Pro...try)

hl7:code

CE

1 … 1

M

Code des Problems.
Die Art des angegebenen Problems (Diagnose, Symptom, etc.) wird codiert in diesem Element angegeben.

Verweis auf speziellen Implementierungsleitfaden:

Welche der Problemarten angegeben werden müssen bzw. sollen, kann im jeweiligen speziellen Implementierungsleitfaden eingeschränkt werden.

(Pro...try)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.35 atcdabbr_Problemarten_VS (DYNAMIC)

hl7:originalText

ED

0 … 1

Textinhalt, der codiert wurde.
Grundsätzlich sind die Vorgaben gemäß Kapitel „Codierungs-Elemente“ zu befolgen.

(Pro...try)

hl7:text

ED

1 … 1

M

Verweist auf die Stelle im narrativen Text-Bereich, an der das gegebene Problem narrativ beschrieben ist (mit zusätzlichen Informationen, wie Datum, Beschreibung, etc.).

(Pro...try)

hl7:reference

TEL

1 … 1

M

(Pro...try)

hl7:statusCode

CS

1 … 1

M

(Pro...try)

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

1 … 1

M

Zeitintervall, in dem das Problem existent war/ist.

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

(Pro...try)

hl7:low

TS.AT.TZ

1 … 1

R

Zeitpunkt des ersten Auftretens des Problems.

(Pro...try)

hl7:high

TS.AT.TZ

0 … 1

C

Zeitpunkt, zu dem der Problemstatus des übergeordneten Act auf "aborted" oder "completed" gesetzt wird. In allen anderen Fällen bleibt der Wert leer.

(Pro...try)

hl7:value

CD

1 … 1

R

Problem (codiert oder uncodiert).

Hinweis: Die Wahl des Codesystems ist abhängig von der Problemart!

(Pro...try)

hl7:originalText

ED

1 … 1

M

Verweist auf die Stelle im narrativen Textbereich, in dem das Problem beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).

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

(Pro...try)

hl7:qualifier

CR

0 … 1

R

Qualifier zur genaueren Beschreibung des Problems.

z.B. zur Angabe der Diagnosesicherheit.

Angabe der Seitenlokalisation als Kind-Element des value-Elements des Problems (Diagnose)

(Pro...try)

wo [hl7:name [@code='7']]

hl7:name

CD

1 … 1

M

(Pro...try)

@code

CONF

1 … 1

F

7

@codeSystem

1 … 1

F

2.16.840.1.113883.3.7.1.0 (Sciphox)

hl7:value

CD

1 … 1

R

(Pro...try)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.176 ELGA_Seitenlokalisation (DYNAMIC)

hl7:qualifier

CR

0 … 1

R

Angabe der Diagnosesicherheit als Kind-Element des value-Elements des Problems (Diagnose)

(Pro...try)

wo [hl7:name [@code='8']]

hl7:name

CD

1 … 1

M

(Pro...try)

@code

CONF

1 … 1

F

8

@codeSystem

1 … 1

F

2.16.840.1.113883.3.7.1.0 (Sciphox)

hl7:value

CD

1 … 1

M

(Pro...try)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.168 ELGA_Diagnosesicherheit (DYNAMIC)

hl7:qualifier

CR

0 … 1

R

Angabe der "LKF Diagnose–Art" als Kind-Element des value-Elements des Problems (Diagnose)

(Pro...try)

wo [hl7:name [@code='ART']]

hl7:name

CD

1 … 1

M

(Pro...try)

@code

CONF

1 … 1

F

ART

@codeSystem

1 … 1

F

1.2.40.0.34.5.211

hl7:value

CD

1 … 1

M

(Pro...try)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.67 LKF_Diagnose-Art_VS (DYNAMIC)

hl7:qualifier

CR

0 … 1

R

Angabe des "LKF Diagnose–Typs" als Kind-Element des value-Elements des Problems (Diagnose)

(Pro...try)

wo [hl7:name [@code='TYP']]

hl7:name

CD

1 … 1

M

(Pro...try)

@code

CONF

1 … 1

F

TYP

@codeSystem

1 … 1

F

1.2.40.0.34.5.211

hl7:value

CD

1 … 1

M

(Pro...try)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.69 LKF_Diganose-Typ_VS (DYNAMIC)

hl7:qualifier

CR

0 … 1

R

Angabe der "LKF Diagnose – im stationären Aufenthalt erworben" als Kind-Element des value-Elements des Problems (Diagnose)

(Pro...try)

wo [hl7:name [@code='STAT']]

hl7:name

CD

1 … 1

M

(Pro...try)

@code

CONF

1 … 1

F

STAT

@codeSystem

1 … 1

F

1.2.40.0.34.5.211

hl7:value

CD

1 … 1

M

(Pro...try)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.68 LKF_Diagnose-statAuf_VS (DYNAMIC)

hl7:translation

CE

0 … *

Codierung(en) des Problems in alternativen Codesystemen.

(Pro...try)

Verweis auf speziellen Implementierungsleitfaden:
Ob das Problem codiert angegeben werden muss und welche Codesysteme zur Anwendung kommen müssen bzw. sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

8.4.6.2 Diagnosesicherheit

Im Fall der Angabe einer Diagnose kann zusätzlich die Diagnosesicherheit angegeben werden, etwa um ungesicherte, gesicherte oder vergangene Diagnosen zu unterscheiden: Zur Angabe der Diagnosesicherheit kann eines der nachgenannten Zusatzkennzeichen angegeben werden (Value Set „ELGA_Diagnosesicherheit_VS“)¹¹ :

G für eine gesicherte Diagnose
V für eine Verdachtsdiagnose

¹¹ Derzeit nicht vorgesehen ist die Darstellung von „ausgeschlossenen Diagnosen“ um Fehlinterpretationen zu vermeiden. „status post“ Diagnosen sollen über den statusCode des übergeordneten ELGA Problem/Bedenken-Entry ausgedrückt werden.

8.4.6.2.1 Strukturbeispiel

Die Diagnosesicherheit wird als Qualifier-Element des Values abgebildet:

 <!-- Problem (codiert) -->
    <value xsi:type='CD'
          code='F30' displayName='Manische Episode'
          codeSystem='1.2.40.0.34.5.56' codeSystemName='ICD-10 BMG 2014'/>
      <orignalText>
        <reference value='#problem_value-1'/>
      </originalText>
  <!--Diagnosesicherheit-->
      <qualifier>
         <name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
         <value code="V" codeSystem="2.16.840.1.113883.3.7.1.8"/>
      </qualifier>
    </value>

8.4.6.2.2 Spezifikation Qualifier Diagnosesicherheit

Die Spezifikation ist dem „ICD-Diagnose Entry“ aus dem Arztbrief 2.x.von HL7 Deutschland entnommen.

Element/Attribut			DT	Kard	Konf	Beschreibung
qualifier			cr	0..1	O	Angabe der Diagnosesicherheit als Kind-Element des value-Elements des Problems (Diagnose)
	name		CD	1..1	M	Bezeichnung des Qualifiers.
		@code	cs	1..1	M	Fester Wert: 8
		@displayName	st	0..1	O	Diagnosesicherheit
		@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.3.7.1.0
		@codeSystemName	st	0..1	O	Wenn angegeben: „Sciphox“
	value		CD	1..1	M	Angabe zur Diagnosesicherheit
		@code	cs	1..1	M	Zulässige Werte gemäß Value Set ELGA_Diagnosesicherheit_VS
		@displayName	st	0..1	O
		@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.3.7.1.8
		@codeSystemName	st	0..1	O	Wenn angegeben: „Diagnosenzusatz“

8.4.6.3 Seitenlokalisation

Im Fall der Angabe einer Diagnose kann die Seitenlokalisation mit einem Zusatzkennzeichen angegeben werden: Zur Angabe der Seitenlokalisation kann eines der nachgenannten Zusatzkennzeichen angegeben werden (Value Set „ELGA_Seitenlokalisation_VS“):

R für rechts
L für links
B für beidseits
M für die Mittellinienzone
nullFlavor = NA für Systemerkrankung (bzw. im Sinne von „nicht zutreffend")
nullFlavor = UNK für Unbekannt

8.4.6.3.1 Strukturbeispiel

Die Seitenlokalisation wird als Qualifier-Element des Values abgebildet:

 <!-- Problem (codiert) -->
    <value xsi:type='CD'
          code=' H33.2' displayName='Seröse Netzhautablösung'
          codeSystem='1.2.40.0.34.5.56' codeSystemName='ICD-10 BMG 2014'/>
      <orignalText>
        <reference value='#problem_value-1'/>
      </originalText>
 <!--Seitenlokalisation-->
      <qualifier>
         <name code="7" codeSystem="2.16.840.1.113883.3.7.1.0"/>
         <value code="L" codeSystem="2.16.840.1.113883.3.7.1.7"/>
      </qualifier>
    </value>

8.4.6.3.2 Spezifikation Qualifier Seitenlokalisation

Die Spezifikation wird hier UNTERSCHIEDLICH zum „ICD-Diagnose Entry“ aus dem Arztbrief 2.x.von HL7 Deutschland vorgeschlagen, die die Seitenlokalisation als Qualifier des TargetSiteCodes angibt.

Element/Attribut			DT	Kard	Konf	Beschreibung
qualifier			cr	0..1	O	Angabe der Seitenlokalisation als Kind-Element des value-Elements des Problems (Diagnose)
	name		CD	1..1	M	Bezeichnung des Qualifiers.
		@code	cs	1..1	M	Fester Wert: 7
		@displayName	st	0..1	O	Seitenlokalisation
		@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.3.7.1.0
		@codeSystemName	st	0..1	O	Wenn angegeben: „Sciphox“
	value		CD	1..1	M	Angabe zur Seitenlokalisation
		@code	cs	1..1	M	Zulässige Werte gemäß Value Set ELGA_Seitenlokalisation_VS
		@displayName	st	0..1	O
		@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.3.7.1.7
		@codeSystemName	st	0..1	O	Wenn angegeben: „Seitenlokalisation“

9 Technische Konformitätsprüfung

Dieses Kapitel behandelt die technische Konformitätsprüfung von CDA-Dokumenten gemäß diesem Dokumentleitfaden mittels Schema und Schematron.

9.1 Schema-Prüfung

Das Absolvieren der Schema-Prüfung ist der erste Teil der technischen Konformitätsprüfung.

Eine Prüfung gegen das CDA Schema prüft die gültige „Struktur“ eines CDA-Dokuments, wie beispielsweise

ob die XML Struktur generell gültig ist
ob alle Elemente die richtigen Namen haben
ob alle Elemente an der richtigen Stelle platziert sind
ob alle gemäß Schema erforderlichen Elemente vorhanden sind

Die Schema-Prüfung stellt sicher, dass es sich beim geprüften CDA-Dokument tatsächlich um eine gültige CDA-Struktur handelt.

Die Gültigkeit der „Inhalte“ wird nur in Bezug auf den erforderlichen Datentyp der Elemente geprüft. Hiermit kann beispielsweise sichergestellt werden, dass ein „id“-Element (technisch) immer eine gültige ID enthält.

Das von ELGA verwendete Schema basiert im Wesentlichen auf dem original publizierten Schema von CDA, weist aber einige Spezifika auf. Das angepasste Schema wird auf der Website der ELGA GmbH bereitgestellt.

Die Mindestvoraussetzung, damit ein CDA-Dokument als „gültig“ erachtet wird, ist die fehlerfreie Validierung mit dem CDA-Schema. Das maßgebliche CDA-Schema wird auf http://www.elga.gv.at/cda publiziert.

9.2 Schematron-Prüfung

Im Unterschied zu einer CDA Schema Prüfung kann mittels einer Schematron-Prüfung jede beliebige Inhaltsvorschrift geprüft werden.

Das Schematron-Prüfmittel wird gemäß den Spezifikationen dieses Implementierungsleitfadens angefertigt, und stellt sicher, dass das geprüfte CDA-Dokument auch jene Anforderungen erfüllt, die über die Anforderungen des CDA Schemas hinausgehen. Solche Anforderungen sind beispielsweise:

Optionalitäten von Elementen
- Zusätzliche Pflicht-Elemente
- Eventuell konditional von anderen Inhalten abhängig
Anforderungen an den Inhalt von Elementen
- Bestimmte Code/Wertelisten
- Anzugebende Identifikatoren (ID)
etc.

Das Absolvieren der Schematron-Prüfung ist der zweite Teil der technischen Konformitätsprüfung und stellt sicher, dass das geprüfte Dokument die in den Implementierungsleitfäden beschriebenen „Geschäftsregeln“ befolgt.

Damit ein CDA-Dokument als vollständig „gültig“ hinsichtlich der ELGA Implementierungsleitfäden erachtet wird, ist die fehlerfreie Konformitätsprüfung mit den entsprechenden Schematron-Prüfregeln vorausgesetzt. Eine vollständige Prüfung der Geschäftsregeln kann nur durch einen menschlichen Prüfer erfolgen. Die ELGA GmbH kann auf Anfrage an http://cda@elga.gv.at eine solche Prüfung durchführen. Die maßgeblichen Schematron-Prüfmittel werden auf http://www.elga.gv.at/cda publiziert.

9.3 Online-Validation von CDA-Dokumenten

Für die Prüfung von einzelnen CDA-XML-Instanzen mit dem entsprechenden Schema und Schematron-Regeln stellt ELGA GmbH eine Webapplikation zur Verfügung. Diese ist erreichbar über https://ovp.elga-services.at/. Eine erfolgreiche Prüfung durch den Online-Validator beweist nicht automatisch die vollständige Einhaltung aller Geschäftsregeln, sondern nur die technische Konformität zu den Templates.

10 Anhang

10.1 Referenzen

[HL7]	Health Level Seven
	http://www.hl7.org
[CDA]	HL7 Clinical Document Architecture, Release 2.0
	ANSI/HL7 CDA, R2-2005 (R2010) und ISO/HL7 27932:2008)
[IHE]	Integrating the Healthcare Enterprise (IHE)
	http://www.ihe.net
[XML]	World Wide Web Consortium. Extensible Markup Language, 1.0, 2nd Edition.
	http://www.w3.org/TR/REC-xml
[OIDPORT]	OID Portal für das Österreichische Gesundheitswesen:
	https://www.gesundheit.gv.at/OID_Frontend/
[OIDLEIT]	Object Identifier (OID) Konzept für das österreichische Gesundheitswesen
	https://www.gesundheit.gv.at/OID_Frontend/OID_Konzept_1-1-0.pdf
[TERMLEIT]	Sabutsch, S. & C. Seerainer: Leitfaden zur Nutzung von ELGA-Terminologien,
	Version 1.1. http://www.elga.gv.at

10.2 Revisionsliste

Version	Datum	Änderungsgrund
1.00	06.07.2009	Erste Version des Implementierungsleitfadens. Veröffentlichtes Ergebnis aus der zweiten ELGA CDA Harmonisierungsphase.
2.00 rc1	12.08.2011	Erster „Release candidate“ der zweiten Version des Implementierungsleitfadens, erarbeitet in der dritten ELGA CDA Harmonisierungsphase. Veröffentlicht für internen Review innerhalb der Arbeitsgruppe.
2.00 FWGD	10.10.2011	Fertigstellung des „Final Working Group Draft“. veröffentlicht für öffentlichen Review.
2.01	01.03.2012 21.12.2012	Finale Version. Einarbeitung der Kommentare aus dem öffentlichen Review und dem HL7 Ballot Endredaktion, Erweiterungen, Korrekturen nach Schematron-Überprüfung
2.01a	04.02.2013	6.3.6.2.3. signatureCode: Beschreibung für den Code „S“ ergänzt
2.01a	04.02.2013	Überschrift 4.6 korrigiert
2.01a	04.02.2013	Doppelte Abschnitte zwischen 4.6 und 4.12 entfernt: "Größenbeschränkung von eingebetteten Objekten (Bildern)", „ELGA Value-Sets“ „NullFlavor“
2.01a	12.02.2013	Kapitel 4.8: Letzter Satz korrigiert „etwa durch Verringerung der Auflösung oder der Anzahl der Einzelbilder auf eine sinnvolle und angemessene Größe zu beschränken.“
2.01a	05.02.2013	Tabelle 4: Korrigiert „Hoheitsbereich“
2.01a	15.02.2013	Seite 159, Korrektur im Stylecode: Leerzeichen entfernt
2.01a	04.03.2013	Korrekturen in Zeilen: 5: ebenso -> sowohl; 6,8 "und" eingefügt; 22: "diesem" eingefügt; ~60: LOINC Erklärung vorgezogen; 245, 246: und/Sowie eingefügt; 247: ermöglichen -> erreichen; 250: Satz getrennt; 299: "mit" eingefügt; 383: "und bietet" eingefügt; 390: "der" -> "die"; 427: "den" eingefügt; 454: "aber" eingefügt; 558: "den" vor Zeitraum eingefügt; 789 "von" eingefügt; 795 "von" gelöscht; 1645 das Gerät, "das" eingefügt; 1616: "können" -> "kann"; 1860: ist jene Person, "ist" eingefügt; 1858: Das folgende Beispiel -> im folgenden Beispiel Änderungen in Tabellen: Tabelle in 5.5.1.1.2 2. Korrektur auf "rechtlicher Name" (auch bei Tabelle in 5.5.1.2.2) 1045 "Präfix", auch Tabelle 3, Zeile 1059, Tabelle in 5.5.1.2.2. Tabelle in 7.1.4.5: Anmerkung: Ist die Summe -> "Weicht" die Summe
2.01a	09.04.2013	5.1.1.3.4.3: Korrigiert OID für IBAN = 1.0.13616
2.01a	09.04.2013	6.2.7. Begriff Dokumententyp ergänzt
2.01a	09.04.2013	6.3.8.6.1.Strukturbeispiel korrigiert in Zeile 2165 codeSystemName="HL7: RoleCode"
2.01a	09.04.2013	6.3.8.4.1. (Zeile 2098) displayName="primary care physician" auf Kleinschreibung geändert
2.01a	10.04.2013	6.3.8.2. Fachlicher Ansprechpartner: Ist in der tabellarischen Angabe auf [O], der Text wurde dazu passend korrigiert. Im speziellen Leitfaden kann eine Verpflichtung spezifiziert werden.
2.02	24.06.2013	Umbenennung des weiteren Beteiligten „Einweisender/Zuweisender Arzt“ in „Einweisender/Zuweisender/Überweisender Arzt,“
2.02	03.07.2013	Korrektur des listType von (un)sorted auf (un)ordered
2.02	16.07.2013	displayName des confidentialityCode kleingeschrieben
2.02	25.07.2013	GDA-Index: OID durchgängig auf 1.2.40.0.34.3.1.xxx geändert, bei nullflavor zusätzliche Attribute gelöscht
2.02	09.08.2013	Template 1.2.40.0.34.11.1.1.2: Der Namen des Beteiligten „Einweisender/Zuweisender/Überweisender Arzt“ wurde von [M] auf [R] korrigiert, so dass die Verwendung von NullFlavor möglich ist.
2.02	09.08.2013	Beschreibung der styleCodes für Listen in Kapitel 7.1.4.1 „Listen“ hinzugefügt.
2.02	13.08.2013	6.3.1.2.2. id des Patienten/RecordTarget: "Vollständige Sozialversicherungsnummer des Patienten (alle 10 Stellen)"
2.02	19.08.2013	7.1.7.1.1. Eingebettetes PDF: im Beispiel die Angabe codeSystem="1.2.40.0.34.11.2.2.15" auf codeSystem='1.2.40.0.34.5.40' korrigiert
2.02	20.08.2013	6.3.2.3.1.5 assignedAuthor/telecom: Korrektur der Elementangabe von telecom auf assignedAuthor/telecom
2.02	20.08.2013	5.1.1.3.3.1 Spezifikation Umsatzsteueridentifikationsnummer (ATU): Korrekte OID : 1.2.40.0.10.2.0.3.1 (statt 1.2.40.0.34.4.12)
2.02	20.08.2013	5.1.1.3.2.1 Spezifikation Datenverarbeitungsregister-Nummer (DVR-Nummer): OID 1.2.40.0.10.2.0.2.1 (statt 1.2.40.0.34.4.10)
2.02	20.08.2013	5.1.1.3.4 Bankverbindung: Die Definitionen für Bankleitzahl und Kontonummer wurden entfernt, da obsolet.
2.02	20.08.2013	7.1.2.2.3. CDA Level 3-Vorgaben angepasst: Entry-Elemente, die Inhalte tragen, die nicht im lesbaren Teil enthalten sind, sind erlaubt, sofern sie nicht Teil des signierten Befundes sind und auch nicht dargestellt werden müssen.
2.02	22.08.2013	5.6. Adress-Elemente: Verwendung des Elementes genauer beschrieben
2.02.	22.08.2013	7.1.4.5. Erweiterte styleCodes xELGA_colw:NN% korrigiert auf xELGA_colw:NN
2.02	22.08.2013	Textbeschreibung des linkHtml-Elements verbessert
2.02	22.08.2013	Kapitel 8.1 Neu: Hinweis auf angepasstes CDA-Schema
2.02	22.08.2013	Kapitel 8.3 „Online-Validation von CDA-Dokumenten“ eingefügt
2.02.	26.08.2013	6.3.1. Patient („recordTarget/patientRole“): bPK-GH als optionalen Patientenidentifikator hinzugefügt
2.02	26.08.2013	ServiceEvent: 6.5.1.2.3. effectiveTime: Hinweis auf Gleichsetzung von Low und High gelöscht (nicht zulässig)
2.02	16.09.2013	Typos, Formatierung und Seitenumbrüche ausgebessert
2.02a	8.11.2013	Strukturbeispiel in 6.5.1 (DocumentationOf/ServiceEvent): Das Element ServiceEvent wurde an der falschen Stelle geschlossen, wurde korrigiert
2.02a	18.03.2014	7.3.1 und 7.3.2: Hinweis hinzugefügt, dass der Titel der Sektionen „Brieftext“ und „Abschließende Bemerkungen“ vom ELGA-Referenzstylesheet nicht angezeigt werden.
2.02a	27.03.2014	Kapitel 3.4 Abbildungsreferenz zu Abbildung 5 ausgebessert
2.02a	01.04.2014	Kapitel 7.4.6: Codesystem für Diagnosen auf ICD-10 BMG 2014 aktualisiert
2.02a	01.04.2014	5.2.1 Codierte Elemente: Beispiele aktualisiert und mit neuen Codes versehen.
2.02a	01.04.2014	Kapitel 5.3 (Zeit-Elemente) überarbeitet, kommentiert, präzisiert (Interpretation der Zeitintervalle)
2.02a	02.04.2014	5.5.1. Namenselemente: Ergänzung der Spezifikation der Namensteile und ihrer Reihenfolge.
2.02a	02.04.2014	6.2.12.2. SetId: Hinweis hinzugefügt, dass es bei der Übernahme in XDS ein Problem mit @Extension-Attributen geben könnte, die länger als 15 Zeichen sind.
2.02a	02.04.2014	6.3.1.2.2. recordTarget.id - bPK korrigiert: Kardinalität muss bei [O] richtigerweise 0..1 lauten.
2.02a	02.04.2014	6.2.5.2. Spezifikationstabelle korrigiert, mehrere <templateId> Elemente sind möglich
2.02a	02.04.2014	5.4.1.3. In "telecom – Format Konventionen für Telekom-Daten" explzit hinzugefügt, dass Leerzeichen nicht erlaubt sind.
2.02a	02.04.2014	7.1.4.2. Tabellen: Verwendung von @border ist nicht mehr möglich (deprecated)
2.02a	02.04.2014	2.4.2. Beschreibung der ELGA Interoperabilitätsstufen von EIS Basic/Strucutred ergänzt: „eingebettetes PDF“ oder XML ohne Templates
2.02a	02.04.2014	6.3.1.1. Strukturbeispiel korrigiert: "HL7:MaritalStatus"
2.02a	02.04.2014	6.5.1.1.1. serviceEvent Element Allgemein: <documentationOf> mit [0..] bei R2 statt [1..].
2.02a	02.04.2014	6.3.1.2.3. Gemäß Entlassungsbrief Pflege sind zwei (statt einer) Adressen möglich [0..2].
2.02a	02.04.2014	6.3.2.4. Beispiel im Text geändert: Datenerstellende Geräte/Software (z.B.: das Service der e-Medikation, das die aktuelle Medikationsliste generiert).
2.02a	08.04.2014	4.8 Empfehlung für Beschränkung der Gesamtgröße von ELGA CDA-Dateien auf 20 MB hinzugefügt
2.02a	08.04.2014	2.1 Verweis auf e-Medikation und XDS-Metadaten hinzugefügt
2.02b	12.05.2014	Kapitel 4.7: Formatvorgabe PDF/A-1a ergänzt, PDF/A-1b ist für EIS Basic/Structured/Enhanced mindestens vorgeschrieben.
2.02b	13.05.2014	7.1.4.2. Tabellen: Hinweis auf korrekte Positionierung von <tfoot> eingebaut.
2.02b	03.06.2014	5.6.1.2., 5.6.2.2., 5.6.3.2. Beschreibung des Elementes addr korrigiert (Entfernen von "Person")
2.02b	27.06.2014	5.1.1.3.4.2 Andere OID für SWIFT-Adresse oder BIC
2.02b	27.06.2014	6.3.5.1.3. Codebeispiel für „Beabsichtigter Empfänger ist der Patient selbst“ hinzugefügt
2.02b	30.06.2014	6.2.12.1.1. SetID und clinicalDocument.ID sollen nun unterschiedlich sein (davor: können auch gleich sein)
2.02b	18.07.2014	6.5.1.1.4. performer.time als [O] ergänzt (wird im Laborbefund verwendet)
2.02b	21.07.2014	4.4.6. Kapitel „Umgang mit Ausnahmen bei der Konformitätsprüfung“ zur Erklärung falsch-positiver Fehler eingefügt
2.02b	21.07.2014	7.1.7 Hinweis zur Verwendung von Multimedia-Inhalten in Bezug auf Druck und Barrierefreiheit hinzugefügt.
2.02b	18.08.2014	Dokumenteninformation auf Seite 6: Haftungsausschuss gelöscht, Hinweis zur Verbindlichkeit eingefügt Kapitel 1.2.2: Absatz zur Veröffentlichung von neuen Versionen eingefügt
2.02b	25.08.2014	In 5.4.1. und 4.9 Ergänzungen zur Verwendung von NullFlavor mit telekom-Elementen
2.02b	25.08.2014	7.1.7: Vorgaben zur Barrierefreiheit bei Verwendung von Multimedia-Daten (Textalternative)
2.02b	25.08.2014	5.6.1. Granularitätsstufe 1 von Adressen ist nur in EIS Basic zulässig.
2.02b	25.08.2014	6.3.2.3.1.7 assignedAuthor/representedOrganization: Präzisierung der Angaben für die Organisation des Autors (Name mit Abteilung/Station) und der Adresse (in Granularitätsstufe 2 oder 3)
2.02b	25.08.2014	6.3.8.2. Abbildung des "fachlicher Ansprechpartners" hinzugefügt
Version 2.05
2.05	23.12.2014	Dokumenteninformation (Seite 2) ergänzt mit Hinweis auf Einhaltung der Rechtsordnung und relevanten Materiengesetzen
2.05	12.03.2014	Seite 5: Formulierung zur Verbindlichkeit aktualisiert
2.05	04.02.2015	4.3. Legende der Optionalitäten: Korrigiert „Konformität“ statt „Konformanz“
2.05	18.11.2014	6.3.1.2.2. id: Kardinalität des bPK entsprechend [O] auf 0..1 korrigiert
2.05	18.11.2014	Einleitungstext umformuliert Verbindlichkeit: Absatz „Verbindlichkeit“ umformuliert 1.2.2 Zyklische Revision: Text zur Verbindlichkeit umformuliert 2.5 Verbindlichkeit der Vorgaben ergänzt
2.05	18.11.2014	6.3.2.3.1.3 assignedAuthor/id: Zusatz „oder aus dem GDA-Index“ gestrichen.
2.05	18.11.2014	6.3.8.3.2. Spezifikation für Einweisender/Zuweisender/Überweisender Arzt: NullFLavors für ID hinzugefügt
2.05	18.11.2014	5.4.1. telecom-Element TEL: Verwendung des NullFlavors ist NICHT möglich, die entsprechende Angabe wurde entfernt (auch aus 4.9)
2.05	18.11.2014	6.3.2.3.1.1 functionCode: Verweis auf Value Set „ELGA_AuthorRole“ wurde gestrichen, da dieses keine Werte enthält 6.3.1.4.1. Strukturbeispiel für functionCode hinzugefügt
2.05	18.11.2014	6.3.2.3.1.4 AssignedAuthor/code: Beschreibung verbessert.
2.05	18.11.2014	1.2. Vorgehensweise: Mehrere Umstellungen des Textes (Vorgehensmodell und zyklische Revision).
2.05	19.11.2014	6.2.1.1. Zeichencodierung mit UTF-8 präzisiert
2.05	19.11.2014	4.10. Verbot von CDATA explizit hinzugefügt
2.05	19.11.2014	7.1.1.1. Im Strukturbeispiel Kommentar korrigiert
2.05	19.11.2014	6.6. und 6.6.1.2 Bezug zu vorgehenden Dokumenten: XFRM verboten
2.05	19.11.2014	6.3.2. Author: Spezifikation des Elements „assignedAuthor/representedOrganization“ zu den allgemeinen Vorgaben für den Autor verschoben. 6.3.2.1.2. Im Strukturbeispiel für datenerstellende Geräte die representedOrganization hinzugefügt
2.05	20.11.2014	6.3.2.1.1: Codesystem und OID für Fachärzte angepasst (im Beispiel)
2.05	19.11.2014	5.3. Zeit-Elemente: Hinweis auf komplexe Zeit-Datentypen in den speziellen Leitfäden
2.05	21.11.2014	6.3.2.2.1.1 assignedAuthor/representedOrganization: Präzisiert, dass zur Identifikation der Organisation des Autors die OID aus dem GDA-I angegeben werden MUSS
2.05	05.03.2015	6.3.7.7.3. Spezifikation Versicherter/Versicherung präzisiert:: id = Sozialversicherungsnummer des Patienten (SELF) ODER der Person, bei der der Patient mitversichert ist (FAMDEP)
2.05	19.11.2014	4.6. ELGA Value Sets: Beschreibung verbessert 4.6.1. ELGA Value Binding angegeben: Es gilt grundsätzlich die aktuell als gültig publizierte Version
2.05	24.11.2014	7.1.4.1. Listen: StyleCode „none“ hinzugefügt
2.05	25.11.2014	6.2.12. Formulierung verstärkt, dass die setId sich von der clinicalDocument.id unterscheiden SOLL.
2.05	25.11.2014	Typos verbessert
Version 2.06
2.06	13.04.2015	Typos verbessert
2.06	10.09.2015	Buchstabendreher korrigiert für (richtig) POCD_MT000040
2.06	17.07.2015	In allen Strukturbeispielen <country>Österreich durch <country>AUT ersetzt
2.06	12.10.2015	Neu organisiert: Dokumententeninformation, Harmonisierung, Hinweise zur Nutzung des Leitfadens, Verbindlichkeit, Hinweis auf verwendete Grundlagen, Danksagung, Bedienungshinweise und Inhaltsverzeichnis
2.06	12.10.2015	1.2: Überarbeitung der Vorgehensweise bei der Erstellung und Revision der Leitfäden
2.06	12.10.2015	2.2 Kapitel zur Zielgruppe gelöscht (nun bereits in weiter vorne in den “Informationen über dieses Dokument”.
2.06	12.10.2015	2.5 Kapitel zur Verbindlichkeit der Leitfäden gelöscht (nun bereits in weiter vorne in den “Informationen über dieses Dokument”.
2.06	21.08.2015	4.4.1.1. Meldepflicht von selbst-definierten maschinenlesbaren Elementen: Hinweis auf die Markierung von zusätzlichen Elementen mit einem Plus-Zeichen im XDS-FormatCode
2.06	24.07.2015	4.6. ELGA Value Sets: Gültigkeitszeitraum durch "Gültig ab"-Datum ersetzt
2.06	23.10.2015	4.6. Hinweis auf den Leitfaden Terminologien hinzugefügt
2.06	23.10.2015	5.2.1 und 5.2.2. Spezifikation der Codierungs-Elemente: Erklärungstexte ergänzt und präzisiert
2.06	20.07.2015	5.2.1.2 Präzisiert und verdeutlicht: DisplayName ist nicht zur Anzeige vorgesehen.
2.06	21.08.2015	5.5.1. Namen-Elemente von Personen PN Präzisiert: Wenn mehrere Namen angegeben werden, MUSS das @use-Attribut gesetzt werden. 5.5.1.2.2. Spezifikation Namen-Elemente von Personen PN: In der Tabelle Reihenfolge korrigiert: given vor family. Verbesserte Beschreibung
2.06	17.07.2015	5.6. Adress-Elemente: Empfehlung für die Angabe des Staates den ISO 3 Ländercode (ISO-3166-1 Alpha 3) zu verwenden.
2.06	16.07.2015	5.6.2.2 Adresselemente Granularitätsstufe 2: Spezifikation von Bundesland <state> auf [O] herabgesetzt, Kardinalität 0..1
2.06	16.07.2015	5.6.3.2 Adresselemente Granularitätsstufe 3: Spezifikation von Bundesland <state> auf [R2] herabgesetzt, Kardinalität 0..1
2.06	16.07.2015	5.2.1.2. Spezifikation Codierter Elemente: Verweis auf höhere ICD-10 Version
2.06	17.04.2015	6.3.1.2.13. patient/birthPlace/place: DT von "patient/birthPlace/place" ist "POCD_MT000040.Place" (nicht Guardian)
2.06	10.08.2015	6.3.1.2.13. patient/birthPlace/place: die Adresse kann jederzeit in Granularitätsstufe 1 angegeben werden.
2.06	28.10.2015	6.3.2.2.1.1 assignedAuthor/representedOrganization: Mehrere id-Elemente sind erlaubt (Organisations-Element allgemein), nur erstes Element aus dem GDAI.
2.06	21.08.2015	6.3.2.3.1.6 Author.assignedAuthor/assignedPerson: Präzisiert: nur 1 Namen-Element erlaubt
2.06	29.09.2015	6.3.2.4. Datenerstellende Geräte als „author“: Text der Spezifikation präzisiert
2.06	20.04.2015	6.3.5.1.1. Beabsichtigter Empfänger Strukturbeispiel Kommentare verbessert
2.06	27.10.2015	6.3.5.2 Beabsichtigte Empfänger des Dokuments: Präzisierung der Verwendung ID (für Person nicht aus GDA-I)
2.06	17.07.2015	6.3.6.2.1. legalAuthenticator Element: Konformität [NP] für „automatisch erstellte Dokumente“ hinzugefügt.
2.06	14.08.2015	6.3.8.2. Fachlicher Ansprechpartner: Im Text ergänzt „…fachliche Auskünfte zum betreffenden Dokument…“
2.06	21.08.2015	6.3.8.2.2. Fachliche Ansprechperson: Spezifikation präzisiert: nur 1 Namen-Element erlaubt
2.06	21.08.2015	6.3.8.3.2. Einweisender/Zuweisender/Überweisender Arzt: Spezifikation präzisiert: nur 1 Namen-Element erlaubt
2.06	27.10.2015	6.3.8.3.2 Einweisender/Zuweisender/Überweisender Arzt: Präzisierung der Verwendung ID (für Person nicht aus GDA-I)
2.06	21.08.2015	6.3.8.4.2. Hausarzt: Spezifikation präzisiert: nur 1 Namen-Element erlaubt
2.06	27.10.2015	6.3.8.4.2 Hausarzt: Präzisierung der Verwendung ID (für Person nicht aus GDA-I)
2.06	21.08.2015	6.3.8.6.2. Angehörige: Spezifikation präzisiert: nur 1 Namen-Element erlaubt
2.06	23.11.2015	6.3.8.7.1. Strukturbeispiel 1 (Patient ist selbst der Versicherungsnehmer): Kommentartext geändert
2.06	23.11.2015	6.3.8.7.3. Spezifikation: Beschreibung verallgemeinert, fester Wert für SVNr entfernt.
2.06	20.08.2015	7.1.2.2.3. CDA Level 3: Beschreibung des Zusammenhangs zwischen narrativen Teil und Entries / Level 3 präzisiert.
2.06	20.07.2015	7.4.5.2.5. statusCode von Problemen/Bedenken: Beschreibungen der StatusCodes verbessert, in der Spezifikationstabelle wird nun auf das Value Set ELGA_ProblemStatusCode_VS verwiesen
2.06	20.07.2015	7.4.6.2.8. Problem (codiert oder uncodiert): Qualifier-Element hinzugefügt
2.06	20.07.2015	7.4.6.3. Diagnosesicherheit: Kapitel hinzugefügt
Version 2.06.1 (Nebenversion) x …betrifft Implementierung (erste Spalte)
	11.01.2016	1: Textkorrekturen
	21.01.2016	6.3.1.1. Strukturbeispiel Korrekter Text für bPK-GH ssigningAuthorityName "Österreichische Stammzahlenregisterbehörde"
x	05.01.2016	6.3.1.2.12. patient/guardian: Ein Sachwalter SOLL angegeben werden ([R2] statt [O])
x	04.01.2016	7.1.4.Textstrukturierung: Explizites Verbot von Markup bzw. Textstrukturierung, die nicht im Leitfaden genannt wird. Textkorrekturen.
x	04.01.2016	7.1.4.2. Tabellen: Hinweis hinzugefügt, dass die Anzahl der Spalten über eine ganze Tabelle gleich bleiben muss.
x	04.01.2016	7.1.7. Einbetten von Dokumenten/Multimedia-Dateien: Für Barrierefreiheit die Spezifikation ergänzt mit caption-Unterelement von renderMultiMedia-Element für die Angabe eines Alternativtextes. Grafiken mit Transparenzen sind NICHT ERLAUBT
x	04.01.2016	7.1.7.3. Zugelassene mediaType Attribut-Werte: Hinweis, dass Grafiken mit Transparenzen NICHT ERLAUBT sind.
	04.01.2016	7.3.1.3.5. Textbereich der Sektion: Keine Referenz auf das Brieflogo im narrativen Text notwendig.
x	27.01.2016	7.4.6.3. Diagnosesicherheit: „Ausgeschlossene Diagnosen“ dürfen nicht maschinenlesbar angegeben werden „Status Post Diagnosen“ sollen mit dem StatusCode des Problem/Bedenken-Entry ausgedrückt werden
Version 2.06.2 (Nebenversion)
	16.11.2016	„Bundesministerium für Gesundheit“ geändert in „Bundesministerium für Gesundheit und Frauen“, mehrere Stellen
	01.08.2016	Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
	01.08.2016	Kapitel Harmonisierung: Arbeitszeitraum der Arbeitsgruppen hinzugefügt
	04.11.2016	5.1.1.2. Spezifikation der Identifikations-Elemente in Datentpy II: Die Hexadezimalzahlen A-F der UUID sind un Großbuchstaben zu schreiben.
	16.11.2016	4.4.5. Kapitel hinzugefügt "Ausnahme: Fixierte Attribute" 4.4.7 Fußnote zum Umgang mit fixierten Attributen hinzugefügt
	16.11.2016	5.5.1.2.1. Strukturbeispiel für Namen-Elemente aktualisiert
	09.09.2016	6.2.1.2. Hinterlegung eines Stylesheets: Ausnahmen können für automatisiert erstellte Dokumente notwendig sein, diese müssen im allgemeinen und speziellen Leitfäden beschrieben werden.
	01.08.2016	6.2.2., 6.2.8.2., 4.4.1.1.: Korrektur der Großschreibung bei normativen Vorgaben
	16.11.2016	6.2.5.2. Verweis auf speziellen Implementierungsleitfaden: Formulierung verbessert
	16.11.2016	6.2.7.2. Verweis auf speziellen Implementierungsleitfaden: Formulierung verbessert
	22.07.2016	6.2.8 clinicalDocument.title: Datentyp richtiggestellt auf ST (war st)
	16.11.2016	6.2.12.2. Verweis auf Kapitel 6.6: Formulierung verbessert
	16.11.2016	6.3.1.2.2. id[3] bPK - inkonsistente Kardinalität des Root-Elements korrigert
	11.08.2016	6.3.1.2.12 patient/languageCommunication Komponente zur Strukturierung der Sprachfähigkeiten des Patienten hinzugefügt
	03.03.2016	6.3.2.4.1.3 assignedAuthoringDevice/manufacturerModelName: Datentyp richtiggestellt auf SC (war ST) 6.3.2.4.1.4 assignedAuthoringDevice/softwareName: Datentyp richtiggestellt auf SC (war ST)
	09.09.2016	6.3.6. Rechtlicher Unterzeichner („legalAuthenticator“): Beschreibung verbessert, Sonderfall „multidisziplinärer Befund“ ermöglicht das Weglassen des legalAuthenticator, sofern zwei Authenticator-Elemente angegeben werden
	09.09.2016	6.3.7. Weitere Unterzeichner (authenticator): Beschreibung verbessert
	03.08.2016	6.3.8.3. Einweisender/Zuweisender/Überweisender Arzt: Beschreibung des bereits im Laborbefund definierten Auftraggebers hinzugefügt.
	11.08.2016	6.3.8.9. Weitere Behandler: Kapitel neu hinzugefügt
	03.03.2016	7.1.4.10. Leerzeichen: Kapitel mit Hinweisen für den Umgang mit Whitespace / Leerraum („geschützte Leerzeichen“) hinzugefügt
	04.08.2016	7.3.4.3.2. Template IDs - Patientenverfügungen und andere juridische Dokumente: Beschreibung der TemplateId 1.3.6.1.4.1.19376.1.5.3.1.3.34 korrigiert auf „IHE PCC Advance Directives“
	09.09.2016	7.3.6.3.6. Vitalparameter - Maschinenlesbare Elemente der Sektion: Mehrere VitalparameterGruppe-Entry können angegeben werden (nicht nur 1)
	04.08.2016	7.4.4.1. ELGA Vitalparameter-Entry Strukturbeispiel korrigiert
	16.11.2016	7.4.6.3.2. Spezifikation Qualifier Diagnosesicherheit: inkonsistente Kardinalität des qualifier-Elements korrigert
	16.11.2016	7.4.6.4.2. Spezifikation Qualifier Seitenlokalisation: inkonsistente Kardinalität des qualifier-Elements korrigert
	25.07.2016	8.2. und 8.3: Korrektur des Beschreibungstextes für Schematron-Prüfungen; technisch können mit Schematron nicht alle im Leitfaden beschriebenen Geschäftsregeln geprüft werden.
	02.08.2016	5.3.3.2, 6,3.8.7.2, 5.7.1.2, 5.7.2.2.5.7.3.2, 6.2.12.2, 6.3.8.7.2, 7.1.4.2, 7.1.4.4, 7.3.3.1, 4.8, 5.6.1, 7.3.4.1, 7.3.6.3.5.1, 7.4.6.2, Korrektur der Großschreibung bei normativen Vorgaben
	15.11.2016	7.4.6.2.3. ID des Problem-Entry – soll sich von der ID des Problem/Bedenken-Entry unterscheiden
	09.09.2016	7.4.6.4 Seitenlokalisation: Kapitel zur Angabe der Seitenlokalisation hinzugefügt
	13.10.2016	Korrektur der LOINC OID in 7.1.2.2.2. CDA Level 2 und 7.1.2.2.3. CDA Level 3 von 2.16.840.1.113883.5.25 auf 2.16.840.1.113883.6.1
	04.01.2017	7.4.5.2.7. Problem (entryRelationship): In der Beschreibung die templateId korrigiert (richtig ist 1.2.40.0.34.11.1.3.6 statt 1.2.40.0.34.11.1.3.2)
Version 2.06.3 (Nebenversion)
	27.10.2021	Problem Entry 1.2.40.0.34.11.1.3.6: Drei weitere value.qualifier ergänzt: LKF Diagnose–Typ, LKF Diagnose–Art, LKF Diagnose – im stationären Aufenthalt erworben
Version 2.06.4 (Nebenversion)
	31.10.2023	Problem Entry 1.2.40.0.34.11.1.3.6: Entfernung des Constraints und des Asserts, die für den Entlassungsbrief Ärztlich regelten, dass für observation.value ein Code aus dem Value-Set ELGA_Problemkataloge zu wählen ist.
Version 2.06.5 (Nebenversion)
	30.11.2023	Basierend auf dem Ballot zur Terminologien für "Administratives Geschlecht" wurde die Beschreibung von administrativeGenderCode[@nullFlavor="UNK"] (siehe auch Geschlecht) angepasst. Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.

@@ Zeile 1: / Zeile 1: @@
-{{Underconstruction}}
+{{#seo:
+|title=Allgemeiner Implementierungsleitfaden
+|titlemode=append
+|keywords=Allgemeiner Implementierungsleitfaden,Allgemeiner Leitfaden, Datentypen, Konzept, CDA, CDA Dokumente, Allgemein
+|description= Der Allgemeine Implementierungsleitfaden dient als Basis für alle weiteren Leitfäden.
+}}
+{{#customtitle:Allgemeiner Implementierungsleitfaden}}
 <!--
           Implementierungsleitfaden "Allgemeiner Implementierungsleitfaden"
--->
+ -->
+{{#css:
+@media screen{
+.orange{
+   border: thin black solid;
+   background-color:#F4C789;
+   padding: 5px 5px 5px 5px;
+   margin-left:6px;
+   width:70%;
+}
+.violet{
+   border: thin black solid;
+   background-color:#E5D0EE;
+   padding: 5px 5px 5px 5px;
+   margin-left:6px;
+   width:70%;
+}
+.toc{
+    width: 20%;
+    float: right !important;
+    margin: 10px 0px 10px 30px !important;
+    border: 1px solid #AAA;
+    background-color: #F9F9F9;
+    display: table;
+    padding: 7px !important;
+}
+}
+}}
 {{Infobox Dokument
@@ Zeile 12: / Zeile 45: @@
 |Namespace = elga-cdaalf-2.06.2
 |Type      = Implementierungsleitfaden
-|Version   = 2.06.2
+|Version   = 2.06.5
 |Submitted = HL7 Austria
-|Date      = 20. März 2017
+|Date      = 30. November 2023
 |Copyright = 2017-2021
 |Status    = Entwurf
@@ Zeile 21: / Zeile 54: @@
 |Realm     = Österreich
 }}
 <!--
 {{Infobox Ballot Begin}}
+{{Ballot | Version = 01 | Date = 2013 | Status = Entwurf | Realm = Deutschland}}
 {{Infobox Ballot End}}
--->
+ -->
 <!--
@@ Zeile 33: / Zeile 65: @@
 {{Contributor | Logo = Logo.jpg | Name = Abc | Location = Hürth }}
 {{Infobox Contributors End}}
--->
+ -->
 =Informationen über dieses Dokument=
@@ Zeile 42: / Zeile 74: @@
 {{ILF:Danksagung}}
 {{ILF:Hinweise zur Nutzung des Leitfadens}}
 ==Revisionsliste==
-Diese Version ist eine Nebenversion zur Hauptversion 2.06 und ersetzt diese. Die durchgeführten Änderungen ersehen Sie der Revisionsliste in Kapitel 9.4.
+Diese Version ist eine Nebenversion zur Hauptversion 2.06 und ersetzt diese. Die durchgeführten Änderungen ersehen Sie der [[ILF:Allgemeiner Implementierungsleitfaden#Revisionsliste_2|Revisionsliste]].
 {{ILF:Weitere unterstützende Materialien}}
+<div class="inpdf" style="display:none">
 {{ILF:Bedienungshinweise}}
+</div>
 {{ILF:Impressum}}
 {{elga-cdaalf-2.06.2:Harmonisierung}}
+<!--Einleitung-->
+{{elga-cdaalf-2.06.2:Einleitung}}
+<!--Konzept und Begründung=-->
+{{elga-cdaalf-2.06.2:Konzept und Begründung}}
+<!--CDA Release 2.0 – Konzept und Modellbeschreibung=-->
+{{elga-cdaalf-2.06.2:Konzept und Modellbeschreibung}}
-=Einleitung=
+<!--Allgemeine Richtlinien-->
-{{elga-cdaalf-2.06.2:Ausgangssituation}}
+{{elga-cdaalf-2.06.2:Allgemeine Richtlinien}}
-{{elga-cdaalf-2.06.2:Vorgehensweise}}
-{{elga-cdaalf-2.06.2:Hierarchie der Implementierungsleitfäden}}
-=Konzept und Begründung=
+<!--Datentypen-->
-{{elga-cdaalf-2.06.2:Zweck}}
+{{elga-cdaalf-2.06.2:Datentypen}}
-{{elga-cdaalf-2.06.2:Grundlagen}}
-{{elga-cdaalf-2.06.2:Feststellung der Konformität}}
-{{elga-cdaalf-2.06.2:Zertifizierung}}
-=CDA Release 2.0 – Konzept und Modellbeschreibung=
+{{elga-cdaalf-2.06.2:Administrative Daten (CDA Header)}}
-{{elga-cdaalf-2.06.2:Dokumente im Gesundheitswesen}}
-{{elga-cdaalf-2.06.2:CDA Standard}}
-{{elga-cdaalf-2.06.2:Eigenschaften von CDA-Dokumenten}}
-{{elga-cdaalf-2.06.2:CDA Modellbeschreibung}}
-=Allgemeine Richtlinien=
+{{elga-cdaalf-2.06.2:Medizinische Inhalte (CDA Body)}}
-{{elga-cdaalf-2.06.2:Verwendung von Schlüsselwörtern und farblichen Hervorhebungen}}
-{{elga-cdaalf-2.06.2:Kardinalität}}
-{{elga-cdaalf-2.06.2:Legende der Optionalitäten}}
-{{elga-cdaalf-2.06.2:Maximum-Set}}
-{{elga-cdaalf-2.06.2:Umgang mit optionalen Elementen}}
-{{elga-cdaalf-2.06.2:ELGA Value Sets}}
-{{elga-cdaalf-2.06.2:PDF Format-Vorschrift}}
-{{elga-cdaalf-2.06.2:Größenbeschränkung von eingebetteten Objekten}}
-{{elga-cdaalf-2.06.2:Der nullFlavor}}
-{{elga-cdaalf-2.06.2:Verbot von CDATA}}
-=Datentypen=
-{{elga-cdaalf-2.06.2:Identifikations-Elemente}}
-{{elga-cdaalf-2.06.2:Codierungs-Elemente}}
-{{elga-cdaalf-2.06.2:Zeit-Elemente}}
-{{elga-cdaalf-2.06.2:Kontaktdaten-Elemente}}
-{{elga-cdaalf-2.06.2:Namen-Elemente}}
-{{elga-cdaalf-2.06.2:Adress-Elemente}}
-{{elga-cdaalf-2.06.2:Komplexe (zusammengesetzte) Elemente}}
-=Administrative Daten (CDA Header)=
-{{elga-cdaalf-2.06.2:Überblick}}
-{{elga-cdaalf-2.06.2:Dokumentenstruktur}}
-{{elga-cdaalf-2.06.2:Teilnehmende Parteien}}
-{{elga-cdaalf-2.06.2:Zuweisung und Ordermanagement}}
-{{elga-cdaalf-2.06.2:Dokumentation der Gesundheitsdienstleistung}}
-{{elga-cdaalf-2.06.2:Bezug zu vorgehenden Dokumenten}}
-{{elga-cdaalf-2.06.2:Einverständniserklärung}}
-{{elga-cdaalf-2.06.2:Informationen zum Patientenkontakt}}
-=Medizinische Inhalte (CDA Body)=
+<!--Technische Konformitätsprüfung=-->
-{{elga-cdaalf-2.06.2:Allgemeiner Aufbau des CDA Body}}
+{{elga-cdaalf-2.06.2:Technische Konformitätsprüfung}}
-{{elga-cdaalf-2.06.2:CDA Body in EIS „Basic“}}
-{{elga-cdaalf-2.06.2:Allgemeine Sektionen-Templates}}
-{{elga-cdaalf-2.06.2:Maschinenlesbare Elemente}}
-=Technische Konformitätsprüfung=
+<!--Anhang-->
-{{elga-cdaalf-2.06.2:Schema-Prüfung}}
+{{elga-cdaalf-2.06.2:Anhang}}
-{{elga-cdaalf-2.06.2:Schematron-Prüfung}}
-{{elga-cdaalf-2.06.2:Online-Validation von CDA-Dokumenten}}
-=Referenzen=
-{{elga-cdaalf-2.06.2:Referenzen}}

Allgemeiner Implementierungsleitfaden

Aktuelle Version vom 1. Dezember 2023, 10:28 Uhr

Inhaltsverzeichnis

1 Informationen über dieses Dokument

1.1 Allgemeines

1.2 Sprachliche Gleichbehandlung

1.3 Verbindlichkeit

1.4 Zielgruppe

1.5 Hinweis auf verwendete Grundlagen

1.6 Danksagung

1.7 Revisionsliste

1.8 Weitere unterstützende Materialien

1.9 Bedienungshinweise für die PDF-Version

1.10 Impressum

2 Harmonisierung

3 Einleitung

3.1 Ausgangssituation

3.2 Vorgehensweise

3.2.1 Vorgehensmodell

3.2.2 Revision der Leitfäden

3.3 Hierarchie der Implementierungsleitfäden

4 Konzept und Begründung

4.1 Zweck

4.2 Grundlagen

4.3 Feststellung der Konformität

4.3.1 CDA Levels

4.3.2 ELGA Interoperabilitätsstufen

4.4 Zertifizierung

4.5 Dokumente im Gesundheitswesen

4.6 CDA Standard

4.7 Version

4.8 Eigenschaften von CDA-Dokumenten

4.9 Bedingungen

4.10 CDA Levels

4.11 Konzept und Modellbeschreibung

4.11.1 Aufbau eines CDA-Dokument

4.11.2 CDA Header

4.11.3 CDA Body

5 Allgemeine Richtlinien

5.1 Verwendung von Schlüsselwörtern und farblichen Hervorhebungen

5.1.1 Farbliche Hervorhebungen und Hinweise

5.2 Kardinalität

5.3 Legende der Optionalitäten

5.4 Maximum-Set

5.4.1 Ausnahme: „entry“

5.4.1.1 Meldepflicht von selbst-definierten maschinenlesbaren Elementen

5.4.2 Ausnahme: „templateId“

5.4.3 Ausnahme: Verfasser von CDA-Sektionen

5.4.4 Ausnahme: Zusätzliche weitere Beteiligte

5.4.5 Ausnahme: Fixierte Attribute

5.4.6 Hinweis zur Implementierung weiterverarbeitender Software

5.4.7 Umgang mit Ausnahmen bei der Konformitätsprüfung

5.5 Umgang mit optionalen Elementen

5.6 ELGA Value Sets

5.6.1 Änderbarkeit von Value Sets

5.6.2 Value Set Binding

5.7 PDF Format-Vorschrift

5.8 Größenbeschränkung von eingebetteten Objekten

5.9 Der nullFlavor

5.10 Verbot von CDATA

6 Datentypen

6.1 Identifikations-Elemente

6.1.1 id-Element II

6.1.1.1 Strukturbeispiele

6.1.1.2 Spezifikation

6.1.1.3 Vorschriften für bereits definierte ID-Arten

6.1.1.3.1 ID aus dem GDA-Index

6.1.1.3.2 DVR-Nummer

6.1.1.3.2.1 Spezifikation

6.1.1.3.3 ATU Nummer

6.1.1.3.3.1 Spezifikation

6.1.1.3.4 Bankverbindung

6.1.1.3.4.1 Spezifikation: IBAN

6.1.1.3.4.2 Spezifikation: SWIFT-Adresse oder BIC

6.2 Codierungs-Elemente

6.2.1 code-Element CE CWE

6.2.1.1 Strukturbeispiele

6.2.1.1.1 Minimal-Variante um einen Code eindeutig darzustellen:

6.2.1.1.2 Gebräuchlichste Variante mit zusätzlichem Klartext für Code und Codesystem

6.2.1.1.3 Vollständige-Variante mit direkter Angabe des Textinhalts