ILF:ENDS 2

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche



Inhaltsverzeichnis

1 Zusammenfassung

Der gegenständliche Implementierungsleitfaden beschreibt und spezifiziert die Dokumentenstruktur als auch das Export-Format im Allgemeinen, welches für den österreichischen Exportnormdatensatz angewendet werden soll. Ziel ist es ein gemeinsames Format zu definieren welches es den Ärzten erlaubt die Informationen im Arztpraxisinformationssystem im Rahmen einer

  • Patientenauskunft,
  • eines anstehenden Wechsels des Arztpraxisinformationssystems, oder
  • zum Zwecke der Archivierung der Patientendaten nach Ende der ärztlichen Tätigkeit,

zu exportieren. Das Export-Format basiert auf dem IHE Profil XDM. Dieses Profil definiert eine Ordnerstruktur als auch die notwendigen Dateien für die Abspeicherung der Metadaten (maschinen- als auch menschenlesbar). Hinsichtlich der Dateiformate, welche für die Kommunikation der weiteren Informationen (medizinische Daten, Personendaten, Terminologien, etc.) ist dieses IHE Profil agnostisch. Somit wird im gegenständlichen Leitfaden festgehalten welche Dateiformate (HL7 CDA, IHE SVS, JSON, etc.) für die zu exportierenden Arztpraxissystemdaten genutzt werden soll. Die Harmonisierung und die Ergebnisse in Form dieses Leitfadens basierend auf Projektworkshops, zu denen die österreichische Ärztekammer geladen hat. Als Basis für die Spezifikationsarbeiten diente der bestehende Export-NormDatenSatz der österreichischen Ärztekammer in Version IX, Stand 6.5.2008.

Auf der Diskussionsseite werden die Fehler und Änderungswünsche an dieser Version dokumentiert.

Hier kommen Sie zu der Section-Templates Übersicht

2 Informationen über dieses Dokument

2.1 Haftungsausschluss

Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht und über ein öffentliches Kommentierungsverfahren kontrolliert. Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die Autoren, Herausgeber oder Mitwirkenden erhoben und/oder abgeleitet werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls nicht beabsichtigt und von den Erstellern des Dokumentes nicht gewünscht.

2.2 Sprachliche Gleichbehandlung

Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten 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.

2.3 Lizenzinformationen

Die von HL7 Austria erarbeiteten Standards und die Bearbeitungen der Standards von HL7 International stellen Werke im Sinne des österreichischen Urheberrechtsgesetzes dar und unterliegen daher urheberrechtlichem Schutz.

HL7 Austria genehmigt die Verwendung dieser Standards für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen.

Die vollständige oder teilweise Veröffentlichung der Standards (zum Beispiel in Spezifikationen, Publikationen oder Schulungsunterlagen) ist nur mit einer ausdrücklichen Genehmigung der HL7 Austria gestattet. Mitglieder von HL7 Austria sind berechtigt, die Standards vollständig oder in Auszügen ausschließlich organisationsintern zu publizieren, zu vervielfältigen oder zu verteilen. Die Veröffentlichung eigener Anpassungen der HL7-Spezifikationen (im Sinne von Lokalisierungen) oder eigener Leitfäden erfordert eine formale Vereinbarung mit der HL7 Austria.

HL7® und CDA® sind die eingetragenen Marken von Health Level Seven International. Die vollständigen Lizenzinformationen finden sich unter https://hl7.at/nutzungsbedingungen-und-lizenzinformationen/. Die Lizenzbedingungen von HL7 International finden sich unter http://www.HL7.org/legal/ippolicy.cfm

2.3.1 Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")

Third Party Intellectual Property

Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass HL7 Austria nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)").
Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich.
Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.


2.3.2 SNOMED CT

Wichtige Information zur SNOMED CT Lizenz

Dieser Leitfaden enthält Material, das durch SNOMED International urheberrechtlich geschützt ist. Jede Verwendung von SNOMED CT in Österreich erfordert eine aufrechte Affiliate Lizenz oder eine Sublizenz. Die entsprechende Lizenz ist kostenlos, vorausgesetzt die Verwendung findet nur in Österreich statt und erfüllt die Bedingungen des Affiliate License Agreements. Affiliate Lizenzen können über das Member Licensing and Distribution Service (MLDS) direkt beim jeweiligen NRC beantragt werden: MLDS für Österreich.

2.3.3 Weitere Terminologien

Im Folgenden finden Sie eine nicht-exhaustive Liste von weiteren Terminologien, die eine solche separate Lizenz erfordern können:

Terminologie Eigentümer, Kontaktinformation
Logical Observation Identifiers Names & Codes (LOINC) [1] Regenstrief Institute, Inc. [2]
Unified Code for Units of Measure (UCUM) [3] Regenstrief Institute, Inc. [2]
International Classification of Diseases (ICD) [4] World Health Organization (WHO) [5]
ICD-10 BM*G*[6] Für Gesundheit zuständiges Bundesministerium www.sozialministerium.at
Anatomical Therapeutic Chemical Classification System (ATC) [7] World Health Organization (WHO)[5]
Pharmazentralnummer (PZN) ARGE Pharma im Fachverband der chemischen Industrie Österreichs (FCIO) der Wirtschaftskammern Österreichs (WKO) [8]
EDQM-Codes Europäisches Direktorat für die Qualität von Arzneimitteln [9]
Medical Device Communications (MDC) vom ISO/IEEE 11073 Standard MDC wird als Substandard 10101 "Nomenclature" in "Health informatics - Medical / health device communication standards", kurz 11073, geführt und werden mit einem Copyright bei IEEE SA am österreichischen Termserver bereitgestellt. [10], [11]

Die Terminologien werden am österreichischen Terminologieserver zur Verfügung gestellt.

2.4 Verwendete Grundlagen und Bezug zu anderen Standards

Grundlage dieses Implementierungsleitfadens ist der internationale Standard "HL7 Clinical Document Architecture, Release 2.0" (CDA ©), für die das Copyright © von Health Level Seven International[12] gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert[13].

CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen. Das Datenmodell von CDA und seine Abbildung in XML[14] folgen dem Basisstandard HL7 Version 3[15] mit seinem Referenz-Informationsmodell (RIM). Dieser Leitfaden verwendet das HL7-Template-Austauschformat zur Definition der "Bausteine" (Templates) und ART-DECOR® [16] als Spezifikationsplattform.

  • HL7 Clinical Document Architecture (CDA) [17]
  • HL7 Referenz-Informationsmodell (RIM)[18]
  • HL7 V3 Datentypen [19]
  • HL7 Template-Austauschformat Specification and Use of Reusable Information Constraint Templates, Release 1[20]

Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)[21], 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.

2.5 Bedienungshinweise

2.5.1 PDF-Navigation

Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

  • Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
  • Seitenweise blättern: "Bild" Tasten
  • Scrollen: Pfeil nach oben bzw. unten
  • Zoomen: Strg + Mouserad drehen
  • Suchen im Dokument: Strg + F
</div>

3 Einleitung

3.1 Ausgangslage und Motivation

Die Daten welche Ärzte in ihren Arztpraxisinformationssystemen generieren, sind in den Datenformaten und Strukturen des jeweiligen Arztpraxisinformationssystems in Datenbanken abgelegt. Diese Datenformate und Strukturen, welche von einem Arztsoftwarehersteller Anwendung finden, entsprechen im Regelfall nicht den Formaten und Strukturen eines anderen Arztsoftwareherstellers. Möchte nun ein Arzt sein bestehendes Arztpraxisinformationssystem gegen ein anderes tauschen besteht die Notwendigkeit die historischen Daten aus dem Altsystem in das neue System zu migrieren. Ein gemeinsames Exportformat (für Export und anschließenden Import) wäre wünschenswert. Hierzu gibt es die Definition eines Exportdatensets der österreichischen Ärztekammer, in welchem die häufigsten Datenarten und deren Qualität (Datentyp, Codeliste) definiert sind. Die letzten Jahre haben gezeigt, dass diese Spezifikation nicht mehr zeitgemäß ist und daher ein neuer Exportnormdatensatz spezifiziert werden müsste. Unter Berücksichtigung der gegenwärtigen Arbeiten im Rahmen der ELGA an HL7 CDA Dokumenten, sollte der neue Exportnormdatensatz ebenfalls auf HL7 CDA basieren. Dies soll es den Arztsoftwareherstellern ermöglichen strukturelle bzw. funktionale Inhalten, welche für ELGA schon umzusetzen sind/waren auch im Kontext des Exportnormdatensatzes wieder zu verwenden.

4 Harmonisierung

4.1 Autoren

Das Redaktionsteam bestand aus folgenden Personen:

Name Organisation Rolle
FH-Prof. Matthias Frohner PhD, MSc Fachhochschule Technikum Wien Autor
FH-Prof. DI Dr. Stefan Sauermann Fachhochschule Technikum Wien Moderation
Nikolaus Krondraf, BSc Technikum Wien GmbH Autor
Mag. Dr. Stefan Sabutsch ELGA GmbH, HL7 Austria Moderation

4.2 Mitwirkende

Teilnehmer der Arbeitsgruppe ENDS21: Baumgartner Michael, Bayer Dietmar, Beiglböck Friedrich, Brieger Jens, Burkhard Walla, Determann Claudius, Gal Güter, Hagenbichler Edgar, Heuschmann David, Kelin Johannes, Keplinger Martin, Keprt Berhard, Klein Dominik, Klemen Silke, Kornfeil Harald Kristoffer, Kornfeind Milan, Kressnik Paul, Loidl Herwig, Marvillo Adnam, Michalek Susane, Moussa Amir, Muigg Domenik, Nicolics Jan, Nöhammer Michael, Petzer Christian, Prünster Egon, Rath Leopold, Rinner Christoph, Romirer Roland, Sabutsch Stefan, Schneider Gerald, Schriefl Michael, Schwaiger Jürgen, Sodeyfi Hamayoun, Stekel Herbert, Stimac Gerhard, Unfried Christoph, Woisetschläger Thomas, Wutscher Edgar, Ziegler Wolfgang

1 Personen sind ohne Titel angegeben

5 Anwendungsfälle

Die folgenden Anwendungsfälle wurden von Seiten des Auftraggebers definiert und zusätzlich in den Workshops noch diskutiert bzw. konkretisiert. In den folgenden Kapiteln sind zuerst die ‚‘High Level Use Cases‘‘ angeführt. Diese sollen die Anwendungsfälle aus User-sicht skizzieren, welche die Basis für den gegenständlichen Implementierungsleitfanden bildeten. In dem nachfolgenden Kapitel ‚‘Detail Use Case‘‘ werden die notwendigen einzelnen Schritte der Exportnormdatensatzerstellung dargestellt und mit den jeweiligen Kapiteln in dieser Spezifikation verknüpft

5.1 High Level Use Case

5.1.1 Ende der ärztlichen Tätigkeit (z.B. Pension)

Aus derzeitiger Sicht kann mit dem gegenständlichen Normdatensatz keine vollständige Backup-Möglichkeit geliefert werden. Auf Grund der Tatsache, dass sich die Softwarelösungen der einzelnen Hersteller in den einzelnen Details stark unterscheiden (Qualität als auch Quantität der genutzten und gespeicherten Daten), kann somit keine vollständige Abbildung der Daten angestrebt werden. Es ist möglich den Exportdatensatz somit zur Archivierung von den hier definierten Daten zu nutzen. Des Weiteren besteht die Möglichkeit, eigene Datenstrukturen zu definieren und für den Export zu nutzen. Es empfiehlt sich, dass der Aufbau der eigenen Datenstrukturen in einem zusätzlichen Dokument beschrieben wird um zu einem beliebigen Zeitpunkt Hilfestellung bei der Rekonstruktion der Daten zu erhalten.

Schritte

  • Auswahl der zu exportierenden Patient*innendaten. Im Regelfall wird man im Zuge dieses Use Cases sämtliche Daten aller Patient*innen exportieren
  • Auswahl der softwarespezifischen oder praxisspezifischen verwendeten Codes und Abkürzungen welche exportiert werden sollen. Im Regelfall wird man im Zuge dieses Use Cases alle software- oder praxisspezifischen Codes und Abkürzungen exportieren
  • Auswahl der Systemdaten (Daten welche nicht einem Patienten zugeordnet werden, wie z.B. Formulare) welche exportiert werden sollen
  • Erstellung des Exportdatensatzes

5.1.2 Systemwechsel zu einer anderen Arztsoftware

Der im ersten Schritt notwendige Export basiert auf dem Use Case Ende der ärztlichen Tätigkeit (z.B. Pension). Der erstellte Exportnormdatensatz kann dann in das neue Zielsystem eingespielt/importiert werden. Sollten im Zuge des Exports eigene zusätzliche Datenstrukturen, welche nicht in diesem Implementierungsleitfaden spezifiziert wurden, Anwendung gefunden haben ist dies ebenfalls im Zuge des Imports zu berücksichtigen

Schritte

5.1.3 Auskunft an PatientInnen (lt. DSGVO) oder Arztwechsel

Sollte ein Patient/eine Patientin Auskunft über seine/ihre gespeicherten Daten erfragen, kann ein Datensatz mit patient*innenspezifischen Daten generiert werden. Es mag hilfreich sein, dass diese generierten Daten vor der Übergabe auf einem physikalischen Medium noch gezippt und verschlüsselt werden. Das Passwort zum Entschlüsseln ist dem Patienten/der Patientin zu übergeben.

Schritte

  • Auswahl des Patienten/der Patientin
  • Auswahl der softwarespezifischen oder praxisspezifischen verwendeten Codes und Abkürzungen welche bei den Patientendaten vorkommen
  • Datensatz erstellen.
  • Datensatz auf ein geeignetes Medium spielen (USB-Stick, CD, DVD). Hierbei ist ein Formatierungsformat zu wählen welches aktuell verbreitet in Verwendung ist.
  • EMPFEHLUNG: Die Daten auf dem Trägermedium sollten noch mit einem symmetrischen Schlüssel verschlüsselt werden. Der Schlüssel wird dem Patienten/der Patientin zusätzlich ausgehändigt (z.B. Ausdruck)

5.2 Detail Use Case

Der folgende Ablauf stellt die einzelnen Schritte dar, welche im Zuge eines Exports vollzogen werden. Diese Schritte sind Teil des oben angeführten High Level Use Cases. Der Fokus wird in diesem Fall auf den Export von Patientendaten gelegt. Die folgenden Schritte unterscheiden sich nicht ob Daten von nur einem oder von mehreren Patienten exportiert werden.

Schritte

  • Benutzer (meist der Arzt) wählt die zu exportierenden Daten aus. Dies inkludiert primär die Entscheidung ob Patientendaten oder Systemdaten exportiert werden sollen. Im Falle eines Exports von Patientendaten muss der oder die zu exportierenden Patienten gewählt werden.
  • Patientendaten, welche primär medizinischer Natur sind oder medizinische Dienstleistungen beschreiben, werden in ein CDA Dokument übergeführt. Die Spezifikation für dieses Dokument ist in dem Kapitel Dokumenten Spezifikation ersichtlich.
  • Patientendaten, welche nicht medizinischer Natur sind, werden in verschiedenen Dateiformaten erfasst. Termindaten von einem Patienten werden zum Beispiel im iCalendar Format abgelegt.
  • EMPFEHLUNG: Im Falle einer Beauskunftung im Sinne der DSGVO, eines Wechsels des Patienten zu einem anderen Arzt oder im Falle des Endes der ärztlichen Tätigkeit wird empfohlen, dass eine zusätzliche Darstellung der exportierten Daten in PDF-Form erstellt wird. Dies bedeutet, dass das CDA mittels Transformation in ein PDF übergeführt wird, als auch eine einfache Darstellung der in z.B. iCal oder JSON erfassten Daten in PDF. Dies soll es dem Patienten oder einem etwaigen Betrachter der Daten erleichtern, die Informationen zu erlangen.
  • Sollte im CDA oder in den anderen Dateiformaten Abkürzungen oder Codes verwendet werden, welche nicht in diesem Leitfaden aufgelistet sind (siehe Kapitel Liste der verwendeten Terminologien), müssen diese in einer eigenständigen Codeliste hinterlegt und dem XDM Datenpaket hinzugefügt werden. Information hierzu ist in Kapitel Eigene Codesysteme zu finden.
  • Die generierten Dateien (CDA, andere Dateiformate, Codelisten) müssen basierend auf der in Kapitel IHE XDM Struktur für den Exportnormdatensatz ersichtlichen Ordnerstruktur in ein Zip Archiv eingebunden werden.
  • Für jeden Patientenordner (Submission Set) ist eine Metadata.xml zu erstellen. Allgemeine Informationen zu den IHE XD* - Metadaten sind in dem Leitfaden zum Metadaten-Mapping von ELGA ersichtlich (XDS Metadaten), spezielle Anforderungen im Falle der XDM Metadaten für den Exportnormdatensatz sind in Kapitel IHE XDM angeführt.
  • Für jeden Patientenordner ist eine INDEX.HTM Datei anzulegen, welche als Einstiegspunkt für eine manuelle Recherche auf Patientenebene dienen soll. Informationen hierzu sind in Kapitel INDEX.HTM eines Patientenverzeichnisses ersichtlich.
  • Im Wurzelverzeichnis ist eine INDEX.HTM Datei anzulegen, welche als Einstiegspunkt für eine manuelle Recherche dient. Informationen hierzu sind in Kapitel INDEX.HTM im Wurzelverzeichnis ersichtlich.
  • Im Wurzelverzeichnis wird eine README.TXT angelegt, welche Informationen zu den am Export beteiligten Personen und Softwareprodukten beinhaltet. Informationen hierzu sind in Kapitel README.TXT ersichtlich.
  • Das XDM Datenpaket wird gezippt auf ein Trägermedium überspielt (z.B. USB Datenstick, CD, DVD).
  • EMPFEHLUNG: Sollte das XDM Datenpaket dem Patienten ausgehändigt werden (Beauskunftung laut DSGVO, oder Arztwechsel), so wird empfohlen, das XDM Datenpaket mit einem symmetrischen Schlüssel zu verschlüsseln und den Schlüssel dem Patienten gesondert zu überreichen (z.B. Ausdruck).

6 Technischer Hintergrund

6.1 IHE XDM

Vorgeschriebene Verzeichnisstruktur laut IHE-ITI Vol2b, Transaction ITI-32[22]

Für den Export der beschlossenen Normdaten wird als Basis das IHE XDM (Cross-Enterprise Document Media Interchange) Profile herangezogen. Dieses Profile ist in den IHE Technical Frameworks IT-Infrastructur definiert (IHE-ITI Vol1[23] und IHE-ITI Vol2b[22]). Das XDM Profil definiert wie Daten abseits einer technischen Infrastruktur geteilt werden können, es definiert also den Austausch von Daten über Datenträger (z.B. USB-Speicherstick, CD/DVD). Hierzu wird in XDM eine Verzeichnisstruktur vorgegeben. Betreffend der verspeicherten Fileformate ist das Profil jedoch agnostisch. Das bedeutet, dass mithilfe von XDM nicht nur CDA (XML) Dokumente übertragen werden können, sondern auch die anderen geforderten Dokumentenklassen wie z.B.: iCalender, .json. Anzumerken ist, dass IHE XDM für die Datei- und Ordnerbezeichnungen den ISO9660 Standard vorschreibt. Dies bedeutet, dass für die Benennung die "8.3" Konvention zu verwenden ist. Im Zuge dieses Leitfadens und basierend auf der Anforderung, dass .json Dateien verwendet werden können, wird bewusst gegen die ISO9660 und somit IHE XDM verstoßen (es gibt keine Dateiextension für .json mit nur 3 Zeichen).

In der nachfolgenden Tabelle werden die einzelnen Inhaltselemente des METADATA.XML-Files aufgelistet. Hinsichtlich des Konformanzkriteriums wird zwischen Stable Documents (SD) und On-Demand Documents (ODD) unterschieden. Erstere sind Dokumente, welche im klassischen Sinne von einem Autor erzeugt wurden. Als Beispiel hierzu zählen im Kontext des Exportnormdatensatzes die ELGA eBefunde. On-Demand Documents sind Dokumente, welche im Zuge der Generierung des Exportnormdatensatzes automatisch erstellt werden. Beispiele hierzu sind das „Datenbankexport“-CDA selbst oder auch JSON-Files welche Abrechnungsdaten beinhalten.

Die Konformanzkriterien basieren auf den Anforderungen der IHE und weichen bei manchen Elementen von den Anforderungen der ELGA-XDS Metadaten ab. Dies ist Aufgrund der Tatsache erklärbar, dass ELGA den Fokus auf den ungerichteten Dokumentenaustausch mittels IHE XDS legt und der gegenständliche Leitfaden den trägermediumgebundenen (CDA, USB Speicherstick) Austausch auf Basis von IHE XDM beschreibt. Zudem werden in ELGA nur CDA Dokumente mittels IHE XDS verfügbar gemacht und im Kontext des Exportnormdatensatzes können auch andere Dateiformate inkludiert sein. Hinsichtlich der Vorschriften des Mappings von CDA-Headerelementen zu den XDS-Metadaten werden die Spezifikationen von ELGA angewendet. Diese Vorschriften betreffen die einzelnen DocumentEntries. Informationen zum übergeordneten SubmissionSet sind in der Tabelle ersichtlich.

Code Bedeutung
M Das Element MUSS mit einem korrekten "echten" Wert angegeben werden.

"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ("required").

R Das Element SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ("required if known").
O Optional
NP Das Element ist NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] ("prohibited")


Ebene Element Konformanz Kommentar
SD ODD
SubmissionSet author R [1..1] Angaben des Authors (Mensch oder Maschine)
SubmissionSet availabilityStatus O [0..1] fixer Wert: "Approved"
SubmissionSet comments O [0..1] Kommentare zum SubmissionSet
SubmissionSet contentTypeCode NP [0..0] contentTypeCode beschreibt die medizische Dienstleistung welche der Generierung des XDM Datensatzes zu Grunde liegt. Aufgrund der Tatsache, dass der Export NICHT auf einer medizischen Dienstleistung beruht, wird der contentTypeCode NICHT im Kontext von EXNDS verwendet.
SubmissionSet entryUUID R [1..1] UUID des SubmissionSets in den Metadaten
SubmissionSet homeCommunityId O [0..0] Laut ELGA wäre dieser Eintrag verpflichtend. Laut IHE für XDM optional. Weil nicht jeder (Fach)Arzt an einer Community teilnehmen muss, ist hier die Verpflichtung abgeändert.
SubmissionSet intendedRecipient R [0..1] Sollte der Patient Auskunft darüber geben für wen der Export gemacht wird (Patient, anderer Arzt) soll dies in diesem Element vermerkt werden
SubmissionSet patientId R [0..1] ID des Patienten innerhalb der Affinity Domain. Sollte diese nicht vorhanden sein, kann auch die lokale PatientenId angegeben werden
SubmissionSet sourceId R [1..1] ID des Systems welches das SubmissionSet erstellt hat
SubmissionSet submissionTime R [1..1] Zeitstempel wann das SubmissionSet erstellt wurde
SubmissionSet title O [0..1] Title des SubmissionSets
SubmissionSet uniqueId R [1..1] ID des SubmissionSets
Die folgenden Einträge beschreiben die XDS Metadaten für das DocumentEntry. Diese sind auch von ELGA für CDA Dokumente definert worden. Wenn möglich sollen die ELGA Spezifikationen übernommen werden (für CDA und nicht-CDA-Dokumente)
DocumentEntry author R [0..1] R [0..1] siehe ELGA Metadaten
DocumentEntry classCode R [0..1] R [0..1] wird nur für CDA-Dokumente verwendet, ansonsten weggelassen
DocumentEntry confidentialityCode R [1..1] R [0..1] Value Set "ELGA_Confidentiality", empfohlener Wert "normal"
DocumentEntry creationTime R [1..1] R [0..1] Zeitpunkt der Dokumentenerstellung
DocumentEntry entryUUID R [1..1] R [1..1] ID des Metadateneintrages für das Dokument
DocumentEntry eventCodeList O [0..1] O [0..1] für das Datenbankexport-CDA wird dieser Eintrag weggelassen, da hier keine medizinischen Dienstleistungen (sondern der Export) stattgefunden haben. Für andere CDA siehe ELGA Leitfaden zu den Metadaten
DocumentEntry formatCode R [0..1] R [0..1] Value Set "exnds_FormatCodes_VS" (für nicht CDA Dokumente) oder "ELGA_FormatCodes_VS" (für CDA Dokumente). Sollte kein passender Code gefunden werden kann auch ein Code aus einer eigenen Codeliste verwendet werden.
DocumentEntry hash R [1..1] R [1..1] Hash Wert des Dokuments
DocumentEntry healthcareFacilityTypeCode R [0..1] R [0..1] Value Set "ELGA_ HealthcareFacilityTypeCode"
DocumentEntry homeCommunityId O [0..1] O [0..1] Angabe der HomeCommunityId (kann ELGA Bereich entsprechen). Nachdem nicht jeder Arzt einem ELGA Bereich zugeordnet sein muss, ist dieses Feld optional
DocumentEntry languageCode R [0..1] R [0..1] Value Set, empfohlener Wert für Deutsch "de-AT"
DocumentEntry legalAuthenticator R [0..1] O [0..1] Person welche das Dokument rechtlich unterzeichnet. Fällt in der Regel bei ODD weg
DocumentEntry mimeType R [1..1] R [1..1] Value Set "IANA Mime Type" (Teilmenge), weitere Werte siehe RFC 2045 bis RFC 2049. Beispiele: DICOM "application/dicom", für JSON "application/json", für iCal "text/calendar" ...
DocumentEntry objectType R [1..1] R [1..1] Unterscheidung zwischen "Stable Document" und "On-Demand Document". Das "Datenbankexport"-CDA wäre als ODD zu führen, andere CDA-Reports (eBefunde) wären als SD zu führen.
DocumentEntry patientId R [0..1] R [0..1] ID des Patienten innerhalb der Affinity Domain. Sollte diese nicht vorhanden sein, kann auch die lokale PatientenId angegeben werden
DocumentEntry practiceSettingCode R [0..1] R [0..1] Value Set "ELGA_PracticeSetting_VS"
DocumentEntry referenceIdList O [0..1] O [0..1] siehe ELGA Spezifikation
DocumentEntry serviceStartTime R [0..1] R [0..1] Beginn-Datum der Gesundheitsdienstleistung. Bei dem Datenbankexport-CDA wäre hier der Exportzeitpunkt anzugeben
DocumentEntry serviceStopTime R [0..1] R [0..1] End-Datum der Gesundheitsdienstleistung. Bei dem Datenbankexport-CDA wäre hier der Exportzeitpunkt anzugeben
DocumentEntry size R [1..1] R [1..1] Größe des Dokuments in byte
DocumentEntry sourcePatientId R [0..1] R [0..1] Patienten-ID des lokalen Systems
DocumentEntry sourcePatientInfo R [0..1] R [0..1] Demographische Daten des Patienten
DocumentEntry title O [0..1] O [0..1] Titel des Dokuments
DocumentEntry typeCode R [0..1] R [0..1] wird nur für CDA-Dokumente verwendet, ansonsten weggelassen
DocumentEntry uniqueId R [1..1] R [1..1] ID des Dokuments
DocumentEntry URI R [1..1] R [1..1] relativer Pfad zu dem Dokument

6.1.1 IHE XDM Struktur für den Exportnormdatensatz

Die nachfolgende Tabelle zeigt die Struktur welche von XDM gefordert wird. Die Elemente in der ersten Spalte sind hinsichtlich ihrer Verschachtelung nach rechts eingerückt. Die Tabelle zeigt die notwendigen Inhalte (siehe Spalte Verpflichtung), nutzt jedoch gleichzeitig Beispieldaten um die Struktur zu verdeutlichen.

Elementname Datei/Ordner Verpflichtung Hinweis Verweise
README.TXT Datei M Die Readme Datei muss Hinweise zu den am Export beteiligten Akteuren (Software, Arzt) enthalten Link
INDEX.HTM Datei M Die INDEX.HTM muss eine Übersicht über die exportierten Patienten ermöglichen Link
IHE_XDM Ordner M Dies ist der root-Ordner für XDM Anwendungen. Er kann eine unbestimmte Anzahl an Submission Sets enthalten.

Im Kontext des Exportnormdatensatzes wird für jeden exportierten Patienten ein Submission Set erstellt.

Zudem soll es ein übergreifendes Submission Set geben, welches z.B. die benötigten Codelisten enthält

PAT0001 Ordner M (Name beispielhaft) Submission Set für den ersten Patienten. Als Ordnername soll der systeminterne Patientenidentifier genutzt werden
INDEX.HTM Datei M Die INDEX.HTM auf Patientenebene ermöglicht eine Übersicht über die patientenspezifischen Dokumente Link
METADATA.XML Datei M Das METADATA.XML enthält die maschinenlesbaren Metainformationen zu den enthaltenen Dokumenten Link
PAT0001.XML Datei M (Name beispielhaft) Dies ist das Datenbankexport CDA für den ersten Patienten. Die Spezifikation dieses CDA Dokuments ist Gegenstand dieses Leitfadens Link
CDAStylesheet.XSL Datei M (Name beispielhaft) Ein Stylesheet um das Datenbankexport CDA anzuzeigen. Das ELGA Referenzstylesheet kann genutzt werden
TERMIN001.ICS Datei Beispiel Beispieldatei: Ein patientenspezifischer Termineintrag Link
PAT0002 Ordner M (Name beispielhaft) Submission Set für den zweiten Patienten. Als Ordnername soll der systeminterne Patientenidentifier genutzt werden
INDEX.HTM Datei M Die INDEX.HTM auf Patientenebene ermöglicht eine Übersicht über die patientenspezifischen Dokumente Link
METADATA.XML Datei M Das METADATA.XML enthält die maschinenlesbaren Metainformationen zu den enthaltenen Dokumenten Link
PAT0002.XML Datei M (Name beispielhaft) Dies ist das Datenbankexport CDA für den zweiten Patienten. Die Spezifikation dieses CDA Dokuments ist Gegenstand dieses Leitfadens Link
Labbef01.XML Datei Beispiel Beispieldatei: ein CDA Laborbefund
CDAStylesheet.XSL Datei M (Name beispielhaft) Ein Stylesheet um das Datenbankexport CDA anzuzeigen. Das ELGA Referenzstylesheet kann genutzt werden
BERICHT01.PDF Datei Beispiel Beispieldatei: ein Bericht in PDF Form
PAT0002.PDF Datei R (Name beispielhaft) Beispieldatei: ein PDF rendering des Datenbankexport CDAs. Dieses PDF wird empfohlen, wenn der Export an den Patienten übergeben wird.
ALLGEMEIN Ordner R Submission Set für allgemeine Daten
METADATA.XML Datei M Das METADATA.XML enthält die maschinenlesbaren Metainformationen zu den enthaltenen Dokumenten Link
Codeliste1.XML Datei R (Name beispielhaft) Beispieldatei: Codeliste mit systeminternen Codes Link
Abkürzungen1.XML Datei R (Name beispielhaft) Beispieldatei: Codeliste mit systeminternen Abkürzungen Link

6.1.2 README.TXT

Laut IHE Profile XDM ist zwingend eine README.TXT Datei in der Ordnerstruktur zu führen. Nach [22] MUSS diese Datei folgende Informationen beinhalten:

  • Kontaktinformationen über das dokumenterstellende Institut
  • Informationen über das Softwareprodukt welches an der Erstellung beteiligt war
    • Name und Version
    • Kontaktinformationen zum Softwareprodukthersteller
  • Information über die Struktur des XDM Datenset

Es ist anzumerken, dass das README.TXT File von der transportierten klinischen Information unabhängig ist. Somit kann die gleiche README.TXT in verschiedenen Exporten vorkommen.

Erzeugt von:
Arztpraxis Dr. Meier
Mozartgasse 1-7
5350 St.Wolfgang, Salzburg

Für Unterstützung:
Arztpraxis Dr. Meier (stellt Kontakt her)
+43 6138 3453446 122

Erzeugt durch xy GmbH - Arztsoftware (Version 8.123, www.xy-arztsoftware.at), basierend auf der Spezifikation des Exportnormdatensatzes mit der OID 1.2.40.0.34.7.25.1

Der IHE_XDM Ordner enhält für jeden Patienten/jede Patientin einen eigenen Unterordner. Der Name des Unterordners ist die PatientenID aus dem Quellsystem.

Zur Darstellung der Inhalte können folgende Softwareprodukte genutzt werden:
- Für CDA Dokumente (.XML): Browser und ELGA-Referenzstylesheet, bzw. ENDS2-Importtool
- Für iCalender Dateien (.ICS): Kalenderapplikation, bzw. ENDS2-Importtool
- Für JSON Dateien (.JSON): Texteditor, bzw. ENDS2-Importtool

6.1.3 INDEX.HTM im Wurzelverzeichnis

Die folgende INDEX.HTM liegt im Wurzelverzeichnis der IHE Daten und dient zur Übersicht aller vorhandenen Patienten. Sie stellt dabei die folgenden Informationen dar:

  • Kontaktinformationen über den Ersteller der Dokumente
  • Pro Patient
    • Name
    • Vorname
    • Geburtsdatum
    • Link zu dessen Dokumentenübersicht
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
  <title>XDM</title>
  <style type="text/css">
    table, th, td {
      border: 1px solid black;
    }
  </style>
</head>

<body>
  <h1>XDM Patientenübersicht:</h1>
  <p>
    Erzeugt von:<br />
    Amadeus Spital - Urologische Ambulanz<br />
    Mozartgasse 1-7<br />
    5350 St. Wolfgang
  </p>
  <table>
    <tr>
      <th>Name</th>
      <th>Vorname</th>
      <th>Geburtsdatum</th>
      <th>Dokumentenübersicht</th>
    </tr>
    <tr>
      <td>TEST0000000036</td>
      <td>Maximilian</td>
      <td>26.08.2001</td>
      <td><a href="00000036/INDEX.HTM">00000036/INDEX.HTM</a></td>
    </tr>
  </table>
</body>
</html>

6.1.4 INDEX.HTM eines Patientenverzeichnisses

Die folgende INDEX.HTM dient als Übersicht der vorhandenen Patientendaten. Eine entsprechend angepasste Version befindet sich in jedem Patientenverzeichnis und stellt dabei die folgenden Informationen dar:

  • Kontaktdaten zum Ersteller der Dokumente
  • Patientendaten
    • Name
    • ID im System
    • Geschlecht
    • Geburtsdatum
    • Postadresse
  • Dokumentendaten
    • Art/Bezeichnung des Dokuments
    • Datum
    • Link zur Datei
    • MIME Type
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
  <title>XDM - klinische Dokumente für Maximilian TEST0000000036</title>
  <style type="text/css">
    table, th, td {
      border: 1px solid black;
    }
  </style>
</head>

<body>
  <h1>XDM Dokumente:</h1>
  <p>
    Erzeugt von:<br />
    Amadeus Spital - Urologische Ambulanz<br />
    Mozartgasse 1-7<br />
    5350 St. Wolfgang
  </p>
  <p>
    Name des Patienten: Maximilian TEST0000000036<br />
    Pat-ID: 36<br />
    Geschlecht: M<br />
    Geburtsdatum: 26.08.2001<br />
    STR0000000036<br />
    0036 WIEN0000000036
  </p>

  <h2>Dokumente:</h2>
  <table>
    <tr>
      <th>Dokumentart</th>
      <th>Datum</th>
      <th>Link</th>
      <th>MIME Type</th>
    </tr>
    <tr>
      <td>NDS (CDA)</td>
      <td>12.12.2018</td>
      <td><a href="00000036.XML">Exportdaten</a></td>
      <td>text/xml</td>
    </tr>
    <tr>
      <td>Termin</td>
      <td>08.10.2018</td>
      <td><a href="TERMIN001.ICS">Termin Verbandswechsel</a></td>
      <td>text/calendar</td>
    </tr>
    <tr>
      <td>Laborbefund</td>
      <td>15.4.2018</td>
      <td><a href="LAB01.XML">Allgemeiner Laborbefund</a></td>
      <td>text/xml</td>
    </tr>
</body>
</html>

7 Spezifikationen abseits von CDA

Neben dem CDA Dokument, welches primär medizinische Daten des zu exportierenden Patienten oder der zu exportierenden Patienten beinhaltet, gibt es noch weitere Dateiformate. Die Daten, welche in diesen Dateien enthalten sind, könnten nicht ohne weiteres in einem HL7 CDA Dokument codiert werden. Daher fiel die Entscheidung für nicht-medizinische Daten andere, besser geeignete Dateiformate zu nutzen. Die folgenden Kapitel stellen diese vor und legen Einschränkungen fest.

Aus derzeitiger Sicht wird die korrekte Implementierung dieser Dateiformate nicht durch Prüfregeln automatisiert prüfbar sein. Die zur Verfügung gestellten Prüfregeln umfassen nur die Schematron-Regeln für das CDA Dokument.

7.1 iCalendar

Um Termine abbilden zu können, wird das iCalendar Format verwendet. Das folgende Beispiel basiert dabei auf den Spezifikationen RFC 5545 und RFC 7986. Es wurde mit einem Validator geprüft und deckt die definierten Anforderungen ab.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:http://www.example.com/calendarapplication/
METHOD:PUBLISH
BEGIN:VEVENT
UID:461092315540@example.com
ORGANIZER;CN="Dr. Max Mustermann":MAILTO:max.mustermann@example.com
CONTACT:Herr Theodor Test, Patient ID 012345
LOCATION:Praxis Dr. Mustermann, Raum 01
SUMMARY:Verbandswechsel
DESCRIPTION:Verbandswechsel Hr. Tester
RESOURCES:Dr. Mustermann, Assistent
CATEGORIES:Nachbehandlung
CLASS:PUBLIC
COLOR:green
DTSTART:20190910T090000Z
DTEND:20190910T091500Z
DTSTAMP:20190903T130000Z
END:VEVENT
END:VCALENDAR

7.2 JSON

Daten, für die die Darstellung als CDA nicht geeignet ist, werden im JSON-Format dargestellt. Dies gilt für

  • Geldflussdaten,
  • Formulare,
  • Stammdaten und
  • Lagerstände.

Die unten angegebenen Strukturbeispiele sind informativ zu verstehen und können je nach Bedarf flexibel erweitert werden. Daher sind nicht alle Beispiele vollständig angeführt (z.B. "Stammdaten"), da sie lediglich als Grundlage für die individuelle Entwicklung dienen sollen.

Die folgenden Tabellen listen die benötigten Elemente sowie deren Eigenschaften auf. In den Strukturbeispielen werden die zu verwendeten Datentypen wie folgt dargestellt:

  • String: "" (Leerstring)
  • Numerisch: 0
  • Datum: String im ISO-8601-Format
  • Code: dabei handelt es sich um keinen JSON Datentyp. Diese Angabe soll verdeutlichen, dass bei diesen Werten aus einem eingeschränkten Wertevorrat gewählt werden muss. Technisch gesehen wird der Wert in der Regel als Datentyp "String" behandelt, in gewissen Fällen wäre auch "Numerisch" denkbar.

7.2.1 Geldflussdaten

Die angegebenen Element- und Attribute Namen sind verpflichtend einzuhalten.

Attribut Kardinalität Datentyp Hinweis
Geldflussdaten 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Text 0..1 String
Betrag 1..1 Numerisch
Mehrwertsteuer-Satz 1..1 Numerisch
Zahlungsart 0..1 Code Zulässige Werte: "Bar", "Scheck", "Kreditkarte", "Bankomat"

Strukturbeispiel:

{
  "Geldflussdaten": [
    {
      "Text": "Erstbehandlung",
      "Betrag": 120,
      "Mehrwertsteuer-Satz": 20,
      "Zahlungsart": "Kreditkarte"
    }
  ]
}

7.2.2 Formulardaten

Die angegebenen Element- und Attribute Name sind verpflichtend einzuhalten.

Attribut Kardinalität Datentyp Hinweis
Formular 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Klasse 1..1 String/Code Im Falle, dass Codes verwendet werden müssen diese in einer Codeliste, welche dem XDM inkludiert wird, angeführt werden.
Erstellungsdatum 0..1 Datum
Formular/Feld 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Name 1..1 String
Typ 1..1 String/Code Im Falle, dass Codes verwendet werden müssen diese in einer Codeliste, welche dem XDM inkludiert wird, angeführt werden.
Inhalt 0..1 String
Reihenfolge 0..1 Numerisch

Strukturbeispiel:

{
  "Formular": [
    {
      "Klasse": 1,
      "Erstellungsdatum": "2020-10-08T07:17:51.876Z",
      "Feld": [
        {
          "Name": "Sozialversicherungsnummer",
          "Typ": "numerisch",
          "Inhalt": "",
          "Reihenfolge": 4
        }
      ]
    }
  ]
}

7.2.3 Stammdaten

Die angegebenen Element- und Attribute Namen sind verpflichtend einzuhalten. Weitere Attribute, die nicht in dieser Tabelle aufgeführt sind, können nach Bedarf ergänzt werden (siehe Strukturbeispiel).

Attribut Kardinalität Datentyp Hinweis
Stammdaten 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Leistungen 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Code 1..1 Code Die verwendeten Codes müssen in einer Codeliste, welche im XDM inkludiert wird, angeführt werden.
Bezeichnung 1..1 String
Einzelpreis brutto 1..1 Numerisch
Einzelpreis netto 1..1 Numerisch
Umsatzsteuer Prozent 1..1 Numerisch
Krankenkasse 0..1 String
Diagnosen 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Bezeichnung 1..1 String/Code Im Falle, dass Codes verwendet werden, müssen diese in einer Codeliste, welche dem XDM inkludiert wird, angeführt werden.
Beschreibung 0..1 String

Strukturbeispiel:

{
  "Stammdaten": [
    {
      "Leistungen": [
        {
          "Code": 1,
          "Bezeichnung": "Erstbehandlung",
          "Einzelpreis brutto": 144,
          "Einzelpreis netto": 120,
          "Umsatzsteuer Prozent": 20,
          "Krankenkasse": ""
        }
      ],
      "Diagnosen": [
        {
          "Bezeichnung": "Myokardinfarkt",
          "Beschreibung": "Einengung oder Verlegung der Koronararterie oder einer ihrer Nebenäste"
        }
      ],
      "Medikamente": [],
      "Allergien": [],
      "Textblöcke": [],
      "Zuweiser": "",
      "Terminarten": []
    }
  ]
}

7.2.4 Lagerstand

Attribut Kardinalität Datentyp Hinweis
Lager 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Medikamente 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Pharmazentralnummer 1..1 Numerisch
Lagerstand 1..1 Numerisch
Meldung ab 0..1 Datum
Nachbestellen bis 0..1 Datum
Zusatzartikel 1..1 Array fasst die folgenden Attribute als JSON-Objekte zusammen
Bezeichnung 1..1 String
Lagerstand 1..1 Numerisch

Strukturbeispiel:

{
  "Lager": [
    {
      "Medikamente": [
        {
          "Pharmazentralnummer": 533363,
          "Lagerstand": 90,
          "Meldung ab": "2020-10-08T07:38:13.700Z",
          "Nachbestellen bis": "2020-10-08T07:38:13.700Z"
        }
      ],
      "Zusatzartikel": [
        {
          "Bezeichnung": "Einmalhandschuhe",
          "Lagerstand": 200
        }
      ]
    }
  ]
}

7.3 Verrechnungsdaten

7.3.1 Rechnungen

Prinzipiell werden nur patientenbezogene Rechnungen exportiert. Je nach Anwendungsfall kommen die folgenden Formate dafür in Frage:

7.3.2 Registrierkassendaten

  • Datenerfassungsprotokoll (DEP)

7.3.3 Buchhaltungsdaten

  • Formate der DATEV GmbH

7.4 Eigene Codesysteme

Es ist davon auszugehen, dass Informationen über Patienten oder Systemparameter in Arztpraxissystemen benutzerspezifische Abkürzungen oder Codes enthalten. Diese benutzerspezifischen Abkürzungen oder Codes könnten vom Arzt vergeben worden sein, für ein spezifisches Arztpraxisinformationsystem vom Hersteller im Zuge einer Konfiguration vergeben worden sein oder für alle Arztpraxisinformationssysteme von einem Hersteller gelten. In allen Fällen MUSS im Zuge des Exports auch die Bedeutung der benutzerspezifischen Abkürzungen und Codes exportiert werden um die Bedeutung dieser auch erfassbar zu machen. Hierzu MUSS dem XDM Datenpaket zumindest ein Codesystem hinzugefügt werden, welches die verwendeten Abkürzungen auflöst. Dem Hersteller bzw. Arzt soll es überlassen sein, ob im Zuge eines Exports von Patientendaten sämtliche Abkürzungen und Codes, welche in dem Arztpraxissystem Verwendung finden, exportiert werden oder nur diejenigen, welche tatsächlich in den exportierten Daten verwendet werden. Das Exportformat für die Codes und Abkürzungen ist IHE Sharing Value Sets (SVS). Dieses wird auch vom österreichischen Terminologieserver als Dateiformat für Codelisten und Valuesets genutzt. Dieses XML-basierte Format für den Austausch von Terminologien basiert auf einer flachen Liste der einzelnen Konzepte (entspricht einer Abkürzung oder einem Code). Die nachfolgenden Tabellen zeigen die notwendigen Strukturen in einer minimalen Variante.

Dem Hersteller ist es überlassen ob es mehrere SVS Dateien gibt (z.B. thematisch separiert) oder ob es nur eine SVS Datei gibt, in der sämtliche Konzepte enthalten sind (unabhängig vom Verwendungszweck). In jedem Fall muss sichergestellt werden, dass innerhalb einer SVS Datei die Konzepte eindeutig auf eine Beschreibung mappen und dass die Zuordnung von Abkürzungen und Codes zwischen Verwendungsort und Codeliste eindeutig ist. Zwei gesonderte Codelisten sind dann zu empfehlen, wenn zwischen eigens definierten Codes und Abkürzungen sowie Codes und Abkürzungen, welche aus einem bestehenden Codesystem entliehen wurden, unterschieden werden soll.

Der Struktur dieser XML-Datei sieht wie folgt aus:

<!-- Dieses Element beinhaltet Attribute, welche das Valueset/Codeliste beschreiben. 
Weiters enthält diese Element genau ein conceptList-Element -->
<valueSet name='ASW_HerstellerX_WeitereDaten' displayName='Weitere Daten von Hersteller X' effectiveDate='2017-01-26' id='1.2.40.0.34.99.111' statusCode='final'  beschreibung=''>
  <!-- Dieses Element beinhaltet eine unbestimmte Menge an concept-Elementen -->
  <conceptList> 
    <!-- Jedes dieser Elemente beinhaltet die Informationen zu einem Konzept -->
    <concept code='ImpfSch' codeSystem='1.2.40.0.34.99.111' displayName='Impfschaden' level='0' type='L' conceptStatusDate='2017-01-26'/>
    <concept code='BevOrth' codeSystem='1.2.40.0.34.99.111' displayName='Bevorzugter Orthopäde' level='0' type='L' conceptStatusDate='2017-01-26'/>
  </conceptList>
</valueSet>

Nachfolgende Tabelle zeigt die Attribute des valueSet-Elements

Name des Attributes Beschreibung
name Name der Codeliste, der sich auch in dem Dateinamen der Codeliste widerspiegeln soll
displayName Klartextbezeichnung des Codesystems
effectiveDate Relevantes Datum der Terminologien

Es sollte das Datum des Exports gewählt werden. Die Darstellung soll dem Format YYYY-MM-DD entsprechen.

id Die OID des Codesystems

Es wird empfohlen, dass die OID des Gesundheitsdienstanbieters als Basis genutzt und um einen weiteren Knotenpunkt erweitert wird

statusCode Status des Codesystems

fixer Wert "final"

beschreibung Beschreibung des Codesystems

Es wird empfohlen, dass in diesem Element festgehalten wird, dass dieses Codesystem im Zuge des Exportnormdatensatzes erstellt wurde.

Beispiel hierzu wäre: beschreibung="Konzepte von Arztpraxis XXX, erstellt im Zuge eines Datenexports"

Nachfolgende Tabelle zeigt die Attribute des concept-Elements

Name des Attributes Beschreibung
code Verwendeter Code oder Abkürzung
codeSystem gleicher Code wie valueSet@id

ODER

OID des Parent Code Systems (wenn der Code oder die Abkürzung aus einem vorhandenen Codesystem entliehen wurde

displayName Klartextrepräsentation des Codes oder der Abkürzung
level Angabe zur Hierarchiestufe des Codes (in einer flachen Liste können alle Konzepte den Wert level="0" haben)
type Angabe zu Type des Codes im Hierarchiebaum (in einer flachen Liste können alle Konzepte den Wert type="L" haben
conceptStatusDate Angabe des Datums ab wann dieser Code gültig wurde. Im Kontext des Exportnormdatensatzes kann hier das Exportdatum gewählt werden.

8 Dokumenten Spezifikation

Information über die Inhalte des CDA-Headers (Administrative Information) kann direkt aus der Spezifikation auf Dokumenten Ebene im nachfolgenden Kapitel gewonnen werden. Informationen über die Inhalte des CDA-Bodies (Medizinische Information) kann aus der Übersichtstabelle in Kapitel Section-Templates Übersicht gewonnen werden.

8.1 Dokumenten Ebene

Id1.2.40.0.34.6.0.11.0.6Gültigkeit2019‑06‑12 09:18:44
StatusKgreen.png AktivVersions-Label1.0.0+20210310
Nameexnds_document_exportNormdatensatzBezeichnungExport-Normdatensatz
KontextPfadname /
KlassifikationCDA Document Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Benutzt
Benutzt 42 Templates
Benutzt als NameVersion
1.2.40.0.34.6.0.11.1.10InklusionKgreen.png Document Realm (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.30InklusionKgreen.png Document TypeId (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.46InklusionKgreen.png Document TerminologyDate (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.47InklusionKgreen.png Document FormatCode (1.1.0+20210303)DYNAMIC
1.2.40.0.34.6.0.11.1.44InklusionKgreen.png Document PracticeSettingCode (1.1.0+20210303)DYNAMIC
1.2.40.0.34.6.0.11.1.11InklusionKgreen.png Document Effective Time (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.12InklusionKgreen.png Document Confidentiality Code (1.0.1+20210628)DYNAMIC
1.2.40.0.34.6.0.11.1.13InklusionKgreen.png Document Language (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.15InklusionKgreen.png Document Set Id and Version Number (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.3InklusionKgreen.png Record Target (1.2.0+20210303)DYNAMIC
1.2.40.0.34.6.0.11.1.2InklusionKgreen.png Author (1.0.1+20210303)DYNAMIC
1.2.40.0.34.6.0.11.1.4InklusionKgreen.png Custodian (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.24InklusionKgreen.png Information Recipient (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.5InklusionKgreen.png Legal Authenticator (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.6InklusionKgreen.png Authenticator (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.20InklusionKgreen.png Participant Fachlicher Ansprechpartner (1.0.1+20210630)DYNAMIC
1.2.40.0.34.6.0.11.1.23InklusionKgreen.png Participant Hausarzt (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.27InklusionKgreen.png Participant Auskunftsberechtigte Person (Notfallkontakt) (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.25InklusionKgreen.png Participant Angehoerige (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.26InklusionKgreen.png Participant Versicherung (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.29InklusionKgreen.png Participant Betreuungsorganisation (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.1.28InklusionKgreen.png Participant Weitere Behandler (1.0.0+20210219)DYNAMIC
2.16.840.1.113883.10.12.109InklusionKgreen.png CDA inFulfillmentOfDYNAMIC
1.2.40.0.34.6.0.11.1.7InklusionKgreen.png Component Of - Encompassing Encounter (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.2.66ContainmentKgreen.png EXNDS Weitere Patienteninformation - Administrativ (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.67ContainmentKgreen.png EXNDS Weitere Patienteninformation - Medizinisch (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.99ContainmentKgreen.png EXNDS Cave - kodiert (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.96ContainmentKgreen.png Diagnose - kodiert (1.1.1+20210304)DYNAMIC
1.2.40.0.34.6.0.11.2.30ContainmentKgreen.png EXNDS Familienanamnese (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.32ContainmentKgreen.png EXNDS Behandlungsschein (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.33ContainmentKgreen.png EXNDS Behandlungen (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.34ContainmentKgreen.png EXNDS Karteineintragungen (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.35ContainmentKgreen.png EXNDS Laborparameter (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.104ContainmentKgreen.png EXNDS Speciality-Section Container (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.101ContainmentKgreen.png EXNDS Verordnungen (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.1ContainmentKgreen.png Impfungen - kodiert (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.2.2ContainmentKgreen.png Impfempfehlungen - kodiert (1.0.0+20210219)DYNAMIC
1.2.40.0.34.6.0.11.2.40ContainmentKgreen.png EXNDS Befund (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.37ContainmentKgreen.png EXNDS eCard Konsultationsdaten (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.38ContainmentKgreen.png EXNDS ABS-Daten (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.36ContainmentKgreen.png EXNDS Attachments (1.0.0+20210310)DYNAMIC
1.2.40.0.34.6.0.11.2.39ContainmentKgreen.png EXNDS Krankenstand (1.0.0+20210310)DYNAMIC
ItemDTKardKonfBeschreibungLabel
hl7:ClinicalDocument
1 … 1M(exn...atz)
Treetree.png@classCode
cs0 … 1FDOCCLIN
Treetree.png@moodCode
cs0 … 1FEVN
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.10 Document Realm (DYNAMIC)
Treetree.pnghl7:realmCode
CS1 … 1M Hoheitsbereich des Dokuments.

Fester Wert: @code = AT
(aus ValueSet „ELGA_RealmCode“)
(exn...atz)
Treeblank.pngTreetree.png@code
1 … 1FAT
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.30 Document TypeId (DYNAMIC)
Treetree.pnghl7:typeId
II1 … 1MDokumentformat CDA R2
(exn...atz)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.1.3
Treeblank.pngTreetree.png@extension
st1 … 1FPOCD_HD000040
Treetree.pnghl7:templateId
II1 … 1M(exn...atz)
wo [@root='1.2.40.0.34.6.0.11.0.1']
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.0.1
Treetree.pnghl7:templateId
II1 … 1M(exn...atz)
wo [@root='1.2.40.0.34.7.25.1']
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.7.25.1
Treetree.pnghl7:templateId
II1 … 1M(exn...atz)
wo [@root='1.2.40.0.34.6.0.11.0.6']
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.0.6
Treetree.pnghl7:id
II1 … 1M(exn...atz)
Treetree.pnghl7:code
CE1 … 1MVerpflichtende Angabe des Dokumententyps und der Dokumentenklasse(exn...atz)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.36 exnds_DocumentType_VS (DYNAMIC)
Treeblank.pngTreetree.pnghl7:translation
CD1 … 1M(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1FDatenbankexportEXNDS
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F1.2.40.0.34.5.195
Treeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1FDatenbankexport EXNDS
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FEXNDS_Concepts
Treetree.pnghl7:title
ST1 … 1M(exn...atz)
 CONF
Elementinhalt muss "Datenbankexport" sein
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.46 Document TerminologyDate (DYNAMIC)
Treetree.pnghl7at:terminologyDate
TS.DATE.FULL1 … 1MDas Terminologie-Datum des Dokumentes
Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird hier angegeben.
(exn...atz)
 ConstraintDas Datum der letzten Terminologie-Aktualisierung MUSS entsprechend klassischer HL7 V3 Notation im Format "YYYYMMDD" angegeben werden.
Beispiel: 20200527
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.47 Document FormatCode (DYNAMIC)
Treetree.pnghl7at:formatCode
CD1 … 1Mdie genaue Version des XDS FormatCode(exn...atz)
Treeblank.pngTreetree.png@code
cs1 … 1RSiehe https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.61 ELGA_Formatcode (DYNAMIC)
Treeblank.pngTreetree.png@codeSystem
oid1 … 1F1.2.40.0.34.5.37
Treeblank.pngTreetree.png@displayName
st1 … 1R
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.44 Document PracticeSettingCode (DYNAMIC)
Treetree.pnghl7at:practiceSettingCode
CD1 … 1MDie fachliche Zuordnung des Dokumentes(exn...atz)
Treeblank.pngTreetree.png@displayName
1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.75 atcdabbr_PracticeSetting_VS (DYNAMIC)
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.11 Document Effective Time (DYNAMIC)
Angabe des Zeitpunkts wann der Export aus dem Primärsystem stattgefunden hat.
Treetree.pnghl7:effectiveTime
TS.AT.TZ1 … 1M
Relevantes Datum des Dokuments.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-11Kyellow.png Erstellungsdatum Kyellow.png Dataset A 2019
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.12 Document Confidentiality Code (DYNAMIC)
Treetree.pnghl7:confidentialityCode
CE1 … 1MVertraulichkeitscode des Dokuments aus ValueSet „ELGA_Confidentiality“. 
(exn...atz)
 
Target.png
at-cda-bbr-data​element-13Kyellow.png Vertraulichkeitscode Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7:Confidentiality
 ConstraintFür ELGA-Dokumente ist ausschließlich "N" erlaubt!
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.13 Document Language (DYNAMIC)
Treetree.pnghl7:language​Code
CS.LANG1 … 1MSprachcode des Dokuments.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-14Kyellow.png Sprachcode Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@code
cs1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.10 atcdabbr_LanguageCode (DYNAMIC)
 ConstraintFür ELGA ist in @code für CDA und Ableitungen in die XDSDocumentEntry-Metadaten derzeit ausschließlich der Wert "de-AT" zulässig.
Für eHealth und zukünftige Versionen der ELGA Leitfäden können weitere Sprachcodes erlaubt werden.
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.15 Document Set Id and Version Number (DYNAMIC)
Treetree.pnghl7:setId
II1 … 1M
Eindeutige Id des Dokumentensets. Diese bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten).
Die setId SOLL unterschiedlich zur clinicalDocument.id sein.
↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut referenceIdList ("urn:elga:iti:xds:2014:ownDocument_setId") gemappt.
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.
(exn...atz)
Treetree.pnghl7:versionNumber
INT.​NONNEG1 … 1MVersionsnummer des Dokuments, wird bei neuen Dokumenten mit 1 festgelegt.
Die versionNumber ist eine natürliche Zahl für die fortlaufende Versionszählung. Mit einer neuen Version wird diese Zahl hochgezählt, während die setId gleich bleibt.
(exn...atz)
Treeblank.pngTreetree.png@value
int1 … 1RVersionsnummer als positive ganze Zahl.
Auswahl1 … 1
Im Falle eines Export von patientenzentrierten Daten MUSS ein gültiges recordTarget-Element vorhanden sein. Im Falle des Export der Systemparameter MUSS das recordTarget-Element mit dem nullFlavor "NA" (not applicable) geführt werden.
Elemente in der Auswahl:
  • hl7:recordTarget eingefügt vom Template 1.2.40.0.34.6.0.11.1.3 Record Target (DYNAMIC)
  • hl7:recordTarget
Eingefügt0 … 1R von 1.2.40.0.34.6.0.11.1.3 Record Target (DYNAMIC)
Treeblank.pngTreetree.pnghl7:recordTarget
0 … 1RKomponente für die Patientendaten.(exn...atz)
 
Target.png
at-cda-bbr-data​element-64Kyellow.png Patient Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FRCT
Treeblank.pngTreeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreeblank.pngTreetree.pnghl7:patientRole
1 … 1MPatientendaten.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPAT
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II2 … *RPatientenidentifikatoren(exn...atz)
 
Target.png
at-cda-bbr-data​element-66Kyellow.png SVNr Kyellow.png Dataset A 2019
at-cda-bbr-data​element-65Kyellow.png LokaleID Kyellow.png Dataset A 2019
at-cda-bbr-data​element-67Kyellow.png bPK-GH Kyellow.png Dataset A 2019
at-cda-bbr-data​element-193Kyellow.png EKVK Kyellow.png Dataset A 2019
 ConstraintHinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!

*id[1] Identifikation des Patienten im lokalen System (1..1 M)
↔ Hinweis zum XDS-Mapping: Das Element id[1] wird ins XDS-Attribut sourcePatientId gemappt.

*id[2] Sozialversicherungsnummer des Patienten (1..1 R):
   - @root: OID der Liste aller österreichischen Sozialversicherungen, fester Wert: 1.2.40.0.10.1.4.3.1 (1..1 M)
   - @extension: Vollständige Sozialversicherungsnummer des Patienten (10 Stellen) (1..1 M)
   - @assigningAuthorityName: Fester Wert: Österreichische Sozialversicherung (0..1 O)

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

*id[@root="1.2.40.0.10.2.1.1.149"] Bereichsspezifisches Personenkennzeichen (0..1 O):
   - @root: OID der österreichischen bPK, fester Wert: 1.2.40.0.10.2.1.1.149 (1..1 M)
   - @extension: bPK des Patienten: concat(Bereichskürzel, ":", bPK) (Base64,28 Zeichen). Typischerweise bPK-GH (Gesundheit). Kann im Zusammenhang mit E-ID auch andere Bereichskürzel tragen.
Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen (1..1 M)
   - @assigningAuthorityName: Fester Wert: Österreichische Stammzahlenregisterbehörde (0..1 O)

*id[@root="1.2.40.0.34.4.21"] Europäische Krankenversicherungskarte (0..1 O):
   - @root: OID der EKVK, fester Wert: 1.2.40.0.34.4.21 (1..1 M)
   - @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennummer" angegeben sein MUSS (1..1 M). Die übrigen Datenfelder sind optional (0..1 O). In Feld 9 MUSS die Datumsangabe im Format YYYMMDD erfolgen.
   - @assigningAuthorityName: Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.
 Beispiel
EKVK Beispiel-Max
<!-- Beispiel einer EKVK Maximum-Variante -->
<id root="1.2.40.0.34.4.21" extension="123456789^1100-OEGK^800400010016^20251231"/>
 Beispiel
EKVK Beispiel-Min
<!-- Beispiel einer EKVK Minimum-Variante -->
<id root="1.2.40.0.34.4.21" extension="123456789"/>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
0 … 2R
Adresse des Patienten.
Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass mehr als eine Adresse unterstützt werden muss.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
 
Target.png
at-cda-bbr-data​element-68Kyellow.png Adresse Kyellow.png Dataset A 2019
 Constraint
Werden mehrere gleichartige address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *RKontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-72Kyellow.png Kontaktdaten Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
url1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom-Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
cs0 … 1 
Bedeutung des angegebenen Kontakts (z.B Heim, Arbeitsplatz), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:patient
1 … 1MName des Patienten.
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben gemäß „Namen-Elemente von Personen PN“ zu befolgen.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-70Kyellow.png Name Kyellow.png Dataset A 2019
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1MNamen-Element (Person)(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
cs0 … 1 
Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.
Zulässige Werte gemäß Value-Set „ELGA_EntityNameUse“.
Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *
Beliebig viele Präfixe zum Namen, z.B. Akademische Titel
Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
cs0 … 1 
Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.
Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier".
 CONF
Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
ENXP1 … *MMindestens ein Hauptname (Nachname).(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
cs0 … 1 
Bedeutung eines family-Elements, z.B Angabe eines Geburtsnamen mit „BR" für „Birth“.
Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier“.
 CONF
Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
ENXP1 … *MMindestens ein Vorname(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
cs0 … 1 
Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier“
 CONF
Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
ENXP0 … *Beliebig viele Suffixe zum Namen(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
cs0 … 1 Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value-Set „ELGA_EntityNamePartQualifier“.
 CONF
Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (DYNAMIC)
Auswahl1 … 1
Das "administrative Geschlecht" ist das soziale oder gesellschaftliche Geschlecht ("Gender"). Das administrative Geschlecht ist daher grundsätzlich getrennt von den biologischen Merkmalen der Person zu sehen. Grundsätzlich soll das administrative Geschlecht dem im Zentralen Melderegister (ZMR) eingetragenen Geschlecht entsprechen.
Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.:
  • Biologisches Geschlecht
  • Geschlecht in der Sozialversicherung
  • Geschlecht für die Stations-/Bettenbelegung im Krankenhaus
Codierung des Geschlechts des Patienten aus ValueSet "ELGA_AdministrativeGender".
Elemente in der Auswahl:
  • hl7:administrative​Gender​Code[not(@nullFlavor)]
  • hl7:administrative​Gender​Code[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE0 … 1(exn...atz)
wo [not(@nullFlavor)]
 
Target.png
at-cda-bbr-data​element-74Kyellow.png Geschlecht Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.1
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7:AdministrativeGender
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:translation
CD0 … *RÜber ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.: Biologisches Geschlecht, Geschlecht in der Sozialversicherung, Geschlecht für die Stations-/Bettenbelegung im Krankenhaus(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 Beispiel
Beispiel für eine SNOMED CT Angabe
<translation code="772004004" codeSystem="2.16.840.1.113883.6.96" displayName="Non-binary gender"/>
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Auswahl1 … 1
Geburtsdatum des Patienten.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
Elemente in der Auswahl:
  • hl7:birthTime
  • hl7:birthTime[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.AT.VAR0 … 1(exn...atz)
 
Target.png
at-cda-bbr-data​element-75Kyellow.png Geburtsdatum Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.AT.VAR0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pngsdtc:deceasedInd
BL0 … 1RKennzeichen, dass die Person verstorben ist. Kann alternativ zum Todesdatum angegeben werden, v.a. wenn der Todeszeitpunkt nicht bekannt ist.(exn...atz)
 
Target.png
at-cda-bbr-data​element-192Kyellow.png Verstorben-Kennzeichen Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pngsdtc:deceasedTime
TS.AT.TZ0 … 1RTodesdatum der Person.(exn...atz)
 
Target.png
at-cda-bbr-data​element-191Kyellow.png Todesdatum Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:marital​Status​Code
CE0 … 1RCodierung des Familienstands des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“
(exn...atz)
 
Target.png
at-cda-bbr-data​element-98Kyellow.png Familienstand Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7:MaritalStatus
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:religious​Affiliation​Code
CE0 … 1RCodierung des Religionsbekenntnisses des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“
(exn...atz)
 
Target.png
at-cda-bbr-data​element-99Kyellow.png Religionsbekenntnis Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.2.16.1.4.1
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7.AT:ReligionAustria
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:raceCode
NPRasse des Patienten.
Darf nicht verwendet werden!
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:ethnic​Group​Code
NPEthnische Zugehörigkeit des Patienten.
Darf nicht verwendet werden!
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian
0 … *R
Gesetzlicher Vertreter:
  1. Vorsorgebevollmächtigte/r (Bevollmächtigte/r durch Vorsorgevollmacht)
  2. Gewählte/r ErwachsenenvertreterIn
  3. Gesetzliche/r ErwachsenenvertreterIn
  4. Gerichtliche/r ErwachsenenvertreterIn (Sachwalter)
Der gesetzliche Vetreter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein.
Beim Patienten können optional ein oder mehrere gesetzliche Vetreter angegeben werden. Wenn ein gesetzliche Vetreter bekannt ist, SOLL diese Information auch angegeben werden.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-88Kyellow.png Gesetzlicher Vertreter Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FGUARD
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
0 … 1R
Die Adresse des gesetzlichen Vertreters oder der Organisation.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *RBeliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation.
Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom-Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (z.B. Heim, Arbeitsplatz) Bsp: WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Auswahl1 … 1
Angabe des gesetzlichen Vertreters als Person (guardianPerson in Granularitätsstufe 1 oder 2) ODER als Organisation (guardianOrganization)
Elemente in der Auswahl:
  • hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
  • hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
  • hl7:guardian​Organization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
0 … 1Name des gesetzlichen Vertreters: Angabe in Granularitätsstufe 1
Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
0 … 1Name des gesetzlichen Vertreters: Angabe in Granularitätsstufe 2
Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Organization
0 … 1RName des gesetzlichen Vertreters (Organisation)
Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthplace
0 … 1RGeburtsort des Patienten.(exn...atz)
 
Target.png
at-cda-bbr-data​element-76Kyellow.png Geburtsort Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FBIRTHPL
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:place
1 … 1M(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPLC
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC)
  • hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional.

Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Die Adresse des Geburtsorts, struktuiert.
Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Communication
0 … *R
Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-100Kyellow.png Sprachfähigkeit Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Code
CS1 … 1MSprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).

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.

Die Gebärdensprache ist als eigene Sprache inkl. Ländercode anzugeben, mit der Ergänzung des Länder-/Regional-Codes (z.B. sgn-at), die Ausdrucksweise (MoodCode) wird in diesem Fall nicht angegeben (denn expressed / received signed wären redundant).
(exn...atz)
 
Target.png
at-cda-bbr-data​element-101Kyellow.png Sprache Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1RZulässige Werte gemäß Value-Set „ELGA_HumanLanguage“ aus Code-System „HL7:HumanLanguage 2.16.840.1.113883.6.121“
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.
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.173 ELGA_HumanLanguage (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:modeCode
CE0 … 1CAusdrucksform der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.60
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7:LanguageAbilityMode
 ConstraintBei Strukturierung einer Gebärdensprache ist dieses Element NICHT ERLAUBT, NP [0..0] und MUSS daher komplett entfallen
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:proficiency​Level​Code
CE0 … 1RGrad der Sprachkenntnis in der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“
(exn...atz)
 
Target.png
at-cda-bbr-data​element-102Kyellow.png Grad der Sprachkenntnis Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.61
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7:LanguageAbilityProficiency
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:preference​Ind
BL0 … 1RKennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.(exn...atz)
 
Target.png
at-cda-bbr-data​element-103Kyellow.png Sprachpräferenz Kyellow.png Dataset A 2019
 Schematron assertrole error 
 testnot(hl7:id[1]/@nullFlavor) 
 MeldungDie Verwendung von id/@nullFlavor ist an dieser Stelle NICHT ERLAUBT. 
 Schematron assertrole error 
 testnot(hl7:id[2]/@nullFlavor) or (hl7:id[2][@nullFlavor='UNK'] or hl7:id[2][@nullFlavor='NI']) 
 MeldungZugelassene nullFlavor sind "NI" und "UNK" 
Treeblank.pngTreetree.pnghl7:recordTarget
0 … 1(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNA
Eingefügt1 … *M von 1.2.40.0.34.6.0.11.1.2 Author (DYNAMIC)
Es können beliebig viele Autoren angeführt werden. Dies mag notwendig sein im Falle einer Gruppenpraxis, wenn mehrere Ärzte/Ärztinnen ein Betreuungsverhältnis mit dem Patienten/der Patientin gehabt haben.
Treetree.pnghl7:author
1 … *MVerfasser des Dokuments.
(exn...atz)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:functionCode
CE (extensible)0 … 1R
Funktionscode des Verfassers des Dokuments, z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“.
Eigene Codes und Bezeichnungen können verwendet werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Auswahl1 … 1
Der Zeitpunkt an dem das Dokument verfasst, bzw. inhaltlich fertiggestellt wurde.
Elemente in der Auswahl:
  • hl7:time[not(@nullFlavor)]
  • hl7:time[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1M(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Auswahl1 … *
Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.
ODER Identifikation des/der datenerstellenden Gerätes/Software. 
Elemente in der Auswahl:
  • hl7:id[not(@nullFlavor)]
  • hl7:id[@nullFlavor='NI']
  • hl7:id[@nullFlavor='UNK']
 ConstraintZugelassene 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
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *
Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.
ODER Identifikation des/der datenerstellenden Gerätes/Software. 
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [@nullFlavor='NI']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNI
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1R
Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung), z.B: „Facharzt/Fachärztin 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.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:assigned​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
  • hl7:assigned​Authoring​Device welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
0 … 1
Personendaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen, name-Element ist hier Mandatory.

Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
0 … 1Datenerstellendes Gerät
Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
1 … 1MOrganisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. 

Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" -->  "Wien AKH" bzw "Wien AKH - Augenambulanz" 


Beinhaltet 1.2.40.0.34.6.0.11.9.5 Organization Compilation with id, name (DYNAMIC)
(exn...atz)
 Constraint
  • id MUSS der OID der Organisation aus dem GDA-Index entsprechen.
  • name SOLL der Kurzbezeichnung im GDA-I entsprechen (sofern vorhanden)
  • Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden., z.B.: „Amadeus Spital, Chirurgische Abteilung“
Treetree.pnghl7:dataEnterer
NPDas DataEnterer-Element hat für das Datenbankexport CDA keine Relevanz, da das Dokument nicht von einer Person "geschrieben" wird (wie z.B. im Sinne einer Transkription)(exn...atz)
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.4 Custodian (DYNAMIC)
Treetree.pnghl7:custodian
1 … 1MVerwahrer des Dokuments.(exn...atz)
 
Target.png
at-cda-bbr-data​element-24Kyellow.png Verwahrer Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCST
Treeblank.pngTreetree.pnghl7:assignedCustodian
1 … 1M(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *MIdentifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen.(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
Eingefügt0 … * von 1.2.40.0.34.6.0.11.1.24 Information Recipient (DYNAMIC)
Im Falle einer Datenauskunft (basierend auf DSGVO) KANN hier der Patient/die Patientin als primärer/primäre Empfänger/Empfängerin angeführt werden.
Treetree.pnghl7:information​Recipient
0 … *Beabsichtiger Empfänger des Dokuments. 
(exn...atz)
 
Target.png
at-cda-bbr-data​element-26Kyellow.png Empfänger Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@typeCode
cs0 … 1 Typ des Informationsempfängers, z.B: PRCP „Primärer Empfänger“.

Werden mehrere Empfänger angegeben, MUSS der primäre Empfänger über den typeCode definiert werden.
Hinweis: Das ist relevant, wenn Funktionen aus dem gerichteten Befundversand oder für den Briefdruck auf das Dokument angewendet werden.
 CONF
Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.29 ELGA_InformationRecipientType (DYNAMIC)
 
Target.png
at-cda-bbr-data​element-27Kyellow.png Empfänger Typ Kyellow.png Dataset A 2019
Treeblank.pngTreetree.pnghl7:intended​Recipient
1 … 1M(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1 
Auswahl1 … *Elemente in der Auswahl:
  • hl7:id[not(@nullFlavor)]
  • hl7:id[@nullFlavor='NI']
  • hl7:id[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Identifikation des beabsichtigten Empfängers (Person).
Empfohlene Information für einen Empfänger ist die ID aus dem GDA-Index.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
 
Target.png
at-cda-bbr-data​element-28Kyellow.png ID des Empfängers Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1NI … Person hat keine ID (exn...atz)
wo [@nullFlavor='NI']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNI
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1UNK ... Person hat eine ID, diese ist jedoch unbekannt (exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Auswahl1 … 1
Personendaten des beabsichtigten Empfängers.
Empfehlung: Der Name des Empfängers und die Organisation, der er angehört, sollen in möglichst hoher Granularität angegeben werden. Aufgrund der gängigen Praxis kann als minimale Information für den Empfänger der unstrukturierte Name angegeben werden.
Grundsätzlich sind die Vorgaben gemäß Kapitel „Personen-Element“ zu befolgen.
Elemente in der Auswahl:
  • hl7:information​Recipient[hl7:name[count(child::*)=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
  • hl7:information​Recipient[hl7:name[count(child::*)!=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:information​Recipient
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)(exn...atz)
wo [hl7:name [count(child::*)=0]]
 
Target.png
at-cda-bbr-data​element-29Kyellow.png Name Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:information​Recipient
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)(exn...atz)
wo [hl7:name [count(child::*)!=0]]
Treeblank.pngTreeblank.pngTreetree.pnghl7:received​Organization
0 … 1ROrganisation, der der beabsichtigte Empfänger angehört, z.B.: „Ordination des empfangenden Arztes“.
Grundsätzlich sind die Vorgaben gemäß Kapitel „Organisations-Element“ zu befolgen.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-30Kyellow.png Organisation Kyellow.png Dataset A 2019
Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation. Bei Organisationen, die im GDA-Index angegeben sind, soll deren Kurzbezeichnung verwendet werden.
Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.5 Legal Authenticator (DYNAMIC)
Treetree.pnghl7:legalAuthenticator
1 … 1MHauptunterzeichner, Rechtlicher Unterzeichner
(exn...atz)
 
Target.png
at-cda-bbr-data​element-1Kyellow.png Rechtlicher Unterzeichner Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.png@typeCode
cs0 … 1FLA
Auswahl1 … 1
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Elemente in der Auswahl:
  • hl7:time[not(@nullFlavor)]
  • hl7:time[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(exn...atz)
wo [not(@nullFlavor)]
 
Target.png
at-cda-bbr-data​element-5Kyellow.png Zeitpunkt der Unterzeichnung Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreetree.pnghl7:signatureCode
CS1 … 1MSignaturcode gibt an, dass das Originaldokument unterzeichnet wurde.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-6Kyellow.png Signatur Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreetree.png@code
CONF1 … 1FS
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1MPersonendaten des rechtlichen Unterzeichners.
Für den Namen ist verpflichtend Granularitätsstufe 2 ("strukturierte Angabe des Namens") anzuwenden!
Beinhaltet 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC)
(exn...atz)
Eingefügt0 … * von 1.2.40.0.34.6.0.11.1.6 Authenticator (DYNAMIC)
Treetree.pnghl7:authenticator
0 … *Weitere Unterzeichner.(exn...atz)
 
Target.png
at-cda-bbr-data​element-31Kyellow.png Weitere Unterzeichner Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUTHEN
Auswahl1 … 1
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Grundsätzlich sind die Vorgaben gemäß für „Zeit-Elemente“ zu befolgen.
Elemente in der Auswahl:
  • hl7:time[not(@nullFlavor)]
  • hl7:time[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(exn...atz)
wo [not(@nullFlavor)]
 
Target.png
at-cda-bbr-data​element-105Kyellow.png Zeitpunkt der Unterzeichnung Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreetree.pnghl7:signatureCode
CS1 … 1M(exn...atz)
 
Target.png
at-cda-bbr-data​element-106Kyellow.png Signatur Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreetree.png@code
CONF1 … 1FS
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1M
Personendaten des weiteren Unterzeichners.
Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
(exn...atz)
Eingefügt von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Auswahl1 … *
Mindestens eine ID der Person der Entität
Elemente in der Auswahl:
  • hl7:id[not(@nullFlavor)]
  • hl7:id[@nullFlavor='NI']
  • hl7:id[@nullFlavor='UNK']
 Constraint
Zugelassene nullFlavor:
  • NI … Die Person der Entität hat keine Identifikationsnummer
  • UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [@nullFlavor='NI']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNI
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Auswahl0 … 1
Elemente in der Auswahl:
  • hl7:addr[not(@nullFlavor)] welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
  • hl7:addr[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
0 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Beliebig viele Kontakt-Elemente der Person der Entität.
Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
url1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.).
Es gelten die ELGA Formatkonventionen für Telekom-Daten, z.B. tel:+43.1.1234567
Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP.
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige "telecom"-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M
Personendaten der Person der Entität.
Grundsätzlich sind die Vorgaben gemäß „Personen-Element“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1R
Organisationsdaten der Entität.
Grundsätzlich sind die Vorgaben gemäß „Organisations-Element“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
(exn...atz)
Eingefügt1 … 1R von 1.2.40.0.34.6.0.11.1.20 Participant Fachlicher Ansprechpartner (DYNAMIC)
Treetree.pnghl7:participant
1 … 1RFachlicher Ansprechpartner
(exn...atz)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.20']]
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCALLBCK
 Callback contact
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MTemplate ID zur Identifikation dieser Art von Beteiligten
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.1.20
Treeblank.pngTreetree.pnghl7:functionCode
CE (extensible)0 … 1
Optionale Angabe eines Funktionscodes des fachlichen Ansprechpartners, z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“.
Eigene Codes und Bezeichnungen können verwendet werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1M(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FPROV
 
Healthcare provider - Gesundheitsdiensteanbieter
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1
Optionale Angabe der Fachrichtung des fachlichen Ansprechpartners („Sonderfach“ gem. Ausbildungsordnung), z.B: „Facharzt/Fachärztin für Gynäkologie“.
Wenn ein fachlicher Ansprechpartner mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben für "Adress-Elemente" zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT1 … *MBeliebig viele Kontaktdaten des Beteiligten.(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintEs MUSS mindestens eine Telefon-Nummer angegeben werden. Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
0 … 1R
Name der Person

Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1R

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

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

(exn...atz)
Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation. Bei Organisationen, die im GDA-Index angegeben sind, soll deren Kurzbezeichnung verwendet werden.
Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Eingefügt0 … 1 von 1.2.40.0.34.6.0.11.1.23 Participant Hausarzt (DYNAMIC)
Treetree.pnghl7:participant
0 … 1Beteiligter (Hausarzt).(exn...atz)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.23']]
Treeblank.pngTreetree.png@typeCode
cs1 … 1FIND
  In indirektem Bezug.
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MTemplate ID zur Identifikation dieser Art von Beteiligten
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.1.23
Treeblank.pngTreetree.pnghl7:functionCode
CE1 … *M
Funktionscode des Beteiligten
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1FPCP
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.88
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7:ParticipationFunction
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FPROV
  Healthcare provider - Gesundheitsdiensteanbieter.
Auswahl0 … *
Identifikation des Beteiligten (Person) aus dem GDA-Index.
Elemente in der Auswahl:
  • hl7:id[not(@nullFlavor)]
  • hl7:id[@nullFlavor='NI']
  • hl7:id[@nullFlavor='UNK']
 Constraint
Zugelassene nullFlavor:
  • NI … Organisation hat keine ID
  • UNK … Organisation hat eine ID, diese ist jedoch unbekannt
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [@nullFlavor='NI']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNI
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse des Hausarztes
Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … * Beliebig viele Kontaktdaten des Hausarztes.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Auswahl1 … 1
Name des Hausarztes.
Elemente in der Auswahl:
  • hl7:associated​Person[hl7:name[count(child::*)=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
  • hl7:associated​Person[hl7:name[count(child::*)!=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)(exn...atz)
wo [hl7:name [count(child::*)=0]]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)(exn...atz)
wo [hl7:name [count(child::*)!=0]]
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1R
Arztpraxis oder Ordination.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(exn...atz)
Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation. Bei Organisationen, die im GDA-Index angegeben sind, soll deren Kurzbezeichnung verwendet werden.
Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Eingefügt0 … * von 1.2.40.0.34.6.0.11.1.27 Participant Auskunftsberechtigte Person (Notfallkontakt) (DYNAMIC)
Treetree.pnghl7:participant
0 … *Beteiligter (Notfallkontakt / Auskunftsberechtigte Person)
(exn...atz)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.27']]
Treeblank.pngTreetree.png@typeCode
cs1 … 1FIND
  In indirektem Bezug.
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MTemplate ID zur Identifikation dieser Art von Beteiligten
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.1.27
Treeblank.pngTreetree.pnghl7:time
IVL_TS0 … 1
Zeitraum, in dem der angegebene Kontakt den Notfall-Kontakt darstellt.
Wird nur angegeben, wenn der Kontakt bereits absehbar nur in einem eingeschränkten Zeitraum zur Verfügung steht.

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

Beinhaltet 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC)
(exn...atz)
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FECON
 Emergency contact - Notfall-Kontakt
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1Verwandtschaftsverhältnis des Beteiligten zum Patienten, z.B. DAU („daughter“), wenn die Beteiligte die Tochter des Patienten ist. (exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1RZulässige Werte gemäß Value-Set „ELGA_PersonalRelationship“
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.111
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7:RoleCode
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse des Beteiligten

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

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Auswahl0 … *
Beliebig viele Kontaktdaten des Beteiligten.
Elemente in der Auswahl:
  • hl7:telecom[not(@nullFlavor)]
  • hl7:telecom[@nullFlavor='UNK']
 ConstraintEs SOLL mindestens eine Telefon-Nummer angegeben werden.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *R(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … 1 Die Kontaktadresse ist unbekannt. nullFlavor "UNK" (exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Auswahl1 … 1
Name des Beteiligten.
Elemente in der Auswahl:
  • hl7:associated​Person[hl7:name[count(child::*)=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
  • hl7:associated​Person[hl7:name[count(child::*)!=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)(exn...atz)
wo [hl7:name [count(child::*)=0]]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)(exn...atz)
wo [hl7:name [count(child::*)!=0]]
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1R
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(exn...atz)
Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation. Bei Organisationen, die im GDA-Index angegeben sind, soll deren Kurzbezeichnung verwendet werden.
Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Eingefügt0 … * von 1.2.40.0.34.6.0.11.1.25 Participant Angehoerige (DYNAMIC)
Treetree.pnghl7:participant
0 … *Beteiligter (Angehöriger)
(exn...atz)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.25']]
Treeblank.pngTreetree.png@typeCode
cs1 … 1FIND
  In indirektem Bezug.
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MTemplate ID zur Identifikation dieser Art von Beteiligten
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.1.25
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FPRS
 Personal relationship - In persönlicher Beziehung
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE1 … 1MVerwandtschaftsverhältnis des Beteiligten zum Patienten. Beispiel: DAU („daughter“), wenn die Beteiligte die Tochter des Patienten ist oder NBOR für Nachbar.(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.111
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7:RoleCode
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse des Beteiligten

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

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … * Beliebig viele Kontaktdaten des Beteiligten.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Auswahl1 … 1
Name des Beteiligten.
Elemente in der Auswahl:
  • hl7:associated​Person[hl7:name[count(child::*)=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
  • hl7:associated​Person[hl7:name[count(child::*)!=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)(exn...atz)
wo [hl7:name [count(child::*)=0]]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)(exn...atz)
wo [hl7:name [count(child::*)!=0]]
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1RBeinhaltet 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)(exn...atz)
Eingefügt0 … * von 1.2.40.0.34.6.0.11.1.26 Participant Versicherung (DYNAMIC)
Treetree.pnghl7:participant
0 … *Beteiligter (Versicherter/Versicherung).(exn...atz)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.26']]
Treeblank.pngTreetree.png@typeCode
cs1 … 1FHLD
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MTemplate ID zur Identifikation dieser Art von Beteiligten
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.1.26
Treeblank.pngTreetree.pnghl7:time
IVL_TS0 … 1
Gültigkeitszeitraum der Versicherungspolizze.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC)
(exn...atz)
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1M(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FPOLHOLD
 Policy holder - Halter einer Versicherungspolizze
Auswahl1 … 1
Sozialversicherungsnummer des Patienten (SELF) oder der Person, bei der der Patient mitversichert ist (FAMDEP)
Elemente in der Auswahl:
  • hl7:id[not(@nullFlavor)]
  • hl7:id[@nullFlavor='NI']
  • hl7:id[@nullFlavor='UNK']
 Constraint
Zugelassene nullFlavor:
  • NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …)
  • UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [@nullFlavor='NI']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNI
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(exn...atz)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE1 … 1M
Versicherungsverhältnis codiert
Beispiele:
  • SELF, wenn der Patient selbst der Versicherte ist.
  • FAMDEP, wenn der Patient bei einem Familienmitglied mitversichert ist.

(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.111
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7:RoleCode
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.9 ELGA_InsuredAssocEntity (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse des Beteiligten.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … * Beliebig viele Kontaktdaten des Beteiligten.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
0 … 1CName des Beteiligten.
Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
(exn...atz)
 ConstraintWenn das Versicherungsverhältnis "familienversichert" ("FAMDEP“) ist, MUSS eine associatedPerson angegeben sein, M [1..1], sonst kann sie komplett entfallen, O [0..1]
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
1 … 1M
Versicherungsgesellschaft.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(exn...atz)
Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation. Bei Organisationen, die im GDA-Index angegeben sind, soll deren Kurzbezeichnung verwendet werden.
Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
 Schematron assertrole error 
 testnot(hl7:code[@code='FAMDEP']) or hl7:associated​Person 
 MeldungWenn das Versicherungsverhältnis "familienversichert" ist, dann muss eine associatedPerson angegeben sein. 
Eingefügt0 … 1 von 1.2.40.0.34.6.0.11.1.29 Participant Betreuungsorganisation (DYNAMIC)
Treetree.pnghl7:participant
0 … 1Beteiligter (Betreuende Organisation)(exn...atz)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.29']]
Treeblank.pngTreetree.png@typeCode
cs1 … 1FIND
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MTemplate ID zur Identifikation dieser Art von Beteiligten
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.1.29
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FCAREGIVER
 Betreuer
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
1 … 1MBetreuende Organisation(exn...atz)
Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation. Bei Organisationen, die im GDA-Index angegeben sind, soll deren Kurzbezeichnung verwendet werden.
Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Eingefügt0 … * von 1.2.40.0.34.6.0.11.1.28 Participant Weitere Behandler (DYNAMIC)
Treetree.pnghl7:participant
0 … *Beteiligter (Weitere Behandler)(exn...atz)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.28']]
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCON
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MTemplate ID zur Identifikation dieser Art von Beteiligten
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.1.28
Treeblank.pngTreetree.pnghl7:functionCode
CE (extensible)0 … 1Funktionscode des Behandlers z.B: „Facharzt für Neurologie“
Eigene Codes und Bezeichnungen dürfen verwendet werden.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FPROV
  Gesundheitsdiensteanbieter.
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1
Adresse des Beteiligten.
Grundsätzlich sind die Vorgaben gemäß „Adress-Elemente“ zu befolgen

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Beliebig viele Kontaktdaten des Beteiligten.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.)
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …)
Bsp: WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“

Bei Angabe mehrerer Telefonnummern ist jeweils das Attribut @use anzugeben.
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
1 … 1M
Beteiligte Person
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1R
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(exn...atz)
Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation. Bei Organisationen, die im GDA-Index angegeben sind, soll deren Kurzbezeichnung verwendet werden.
Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden.
(exn...atz)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(exn...atz)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(exn...atz)
wo [not(@nullFlavor)]
Eingefügt0 … 1 von 2.16.840.1.113883.10.12.109 CDA inFulfillmentOf (DYNAMIC)
Treetree.pnghl7:inFulfillmentOf
0 … 1(exn...atz)
Treeblank.pngTreetree.png@typeCode
0 … 1FFLFS
Treeblank.pngTreetree.pnghl7:order
1 … 1(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FACT
Treeblank.pngTreeblank.pngTreetree.png@moodCode
1 … 1FRQO
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R(exn...atz)
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1(exn...atz)
 CONF
muss aus der Konzeptdomäne "ActCode" gewählt werden
Treeblank.pngTreeblank.pngTreetree.pnghl7:priorityCode
CE0 … 1(exn...atz)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.16866 ActPriority (DYNAMIC)
Treetree.pnghl7:documentationOf
NPDas documentationOf/serviceEvent Konstrukt findet im Datenbankexport des Exportnormdatensatzes keine Anwendung, da es sich bei dem Datenbankexport um keine medizinische Dienstleistung handelt. (exn...atz)
Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.1.7 Component Of - Encompassing Encounter (DYNAMIC)
Treetree.pnghl7:componentOf
1 … 1MKomponente für den Patientenkontakt.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-33Kyellow.png Patientenkontakt Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreetree.pnghl7:encompassing​Encounter
1 … 1MPatientenkontakt.
(exn...atz)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FENC
Treeblank.pngTreeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1Identifikationselement zur Aufnahme der Aufenthaltszahl
(exn...atz)
wo [not(@nullFlavor)]
 
Target.png
at-cda-bbr-data​element-34Kyellow.png ID Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1RAufenthaltszahl, z.B.: Az123456
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1ROID der Liste der Aufenthaltszahlen der Organisation
 Constraint
  • @assigningAuthorityName [0..1]: Name der Stelle, welche die ID zugewiesen hat, z.B.: „Amadeus Spital“.
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE1 … 1MCodierung des Patientenkontakts.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-39Kyellow.png Art des Aufenthalts Kyellow.png Dataset A 2019
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1RZulässige Werte gemäß Value-Set „ELGA_ActEncounterCode“
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.4
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7:ActCode
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.5 ELGA_ActEncounterCode (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS1 … 1M
Zeitraum des Patientenkontakts.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC)
(exn...atz)
 
Target.png
at-cda-bbr-data​element-37Kyellow.png Beginn des Patientenkontaktes Kyellow.png Dataset A 2019
 ConstraintDer Zeitraum des Patientenkontaktes muss die Vorgaben der speziellen Implementierungsleitfäden einhalten. Dabei gilt allgemein:
  • Der Zeitraum besteht aus dem Zeitpunkt der administrativen Aufnahme in die Behandlung und dem Zeitpunkt der administrativen Entlassung aus der Behandlung.
  • Der Entlassungszeitpunkt kann „unbekannt“ sein, wenn die administrative Entlassung noch nicht erfolgt ist. (nullFlavor UNK beim effectiveTime.high)
  • Hinweis: Als Zeitpunkt der Aufnahme/Entlassung SOLL der Zeitpunkt der administrativen Aufnahme/Entlassung angegeben werden. Wenn der Zeitpunkt der administrativen Aufnahme/Entlassung nicht vorhanden ist, darf auch der Zeitpunkt der medizinischen Aufnahme/Entlassung angegeben werden.
Treeblank.pngTreeblank.pngTreetree.pnghl7:responsible​Party
0 … 1R
Komponente für die verantwortliche Person.
(exn...atz)
 
Target.png
at-cda-bbr-data​element-40Kyellow.png Verantwortliche Person Kyellow.png Dataset A 2019
Treeblank.png