ILF:Labor- und Mikrobiologiebefund (Version 3)

ELGA CDA
Implementierungsleitfäden

HL7 Implementation Guide for CDA^® R2:
Labor- und Mikrobiologiebefund

Zur Anwendung im österreichischen
Gesundheitswesen [1.2.40.0.34.7.4.9.3]

2021.xx.xx

3.0.0

Normativ

Dieses Dokument bildet den vollständigen Implementierungsleitfaden des Labor- und Mikrobiologiebefundes ab und richtet sich an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen, den zusammenfassenden Guide im Vorfeld zu lesen.

1 Zusammenfassung

Der Implementierungsleitfaden "Labor- und Mikrobiologiebefund" beschreibt die Inhalte, die für den Austausch von fertiggestellten, und fachärztlich vidierten Befunden innerhalb und zwischen Einrichtungen des österreichischen Gesundheitswesens, notwendig sind.

Der Leitfaden enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) und ist ein nationaler Standard der HL7 Austria.

Die Grundlage der Datenaustauschformate ist der internationale CDA-Standard, der sich in ELGA bewährt hat. Er erlaubt es Sender und Empfänger, sich ohne vorherige Absprache zu verstehen. Der Standard hat zum Ziel, einen umfassenden Austausch von semantisch interoperablen Informationen zwischen allen beteiligten Akteuren bei der Behandlung von Patienten zu ermöglichen. Der Datenaustausch findet hierbei nicht nur innerhalb einer Einrichtung, sondern auch zwischen kooperierenden Einrichtungen und über Sektorengrenzen hinaus statt. Die Empfänger der Dokumente sollen die Inhalte benutzen und weiterverwenden können, ohne sich vorher mit dem Ersteller absprechen zu müssen.

TODO: Standard XDLAB, FullSupport, status active/completed

Der "Labor- und Mikrobiologiebefund" basiert auf den Vorgaben des Allgemeinen Implementierungsleitfadens. Darin werden die notwendigen Datentypen, Dokument-Metadaten (Header), die Möglichkeiten der Textstrukturierung, grundlegende Vorgaben für die Anwendung von Terminologien, einige allgemein genutzten Inhaltsstrukturen (Sections) sowie Codebeispiele und praktische Implementierungshilfen gezeigt. Alle weiteren, für diesen Leitfaden benötigten Elemente werden hier erklärt. Die Notation der Spezifikation der Datenaustauschformate folgt der "Art-Decor"-Schreibweise, die auf einer eigenen Seite (Art-Decor-Tabellen verstehen) erläutert wird.

Der vorgesehene Ablauf des Datenaustausches wird im Kapitel Anwendungsfälle beschrieben.

Übersichtstabellen für Header und Body-Strukturen

• Übersichtstabelle der CDA Strukturen des Headers (administrative Daten)
• Übersichtstabelle der CDA Strukturen des Bodys (medizinische Inhalte)

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

2 Informationen über dieses Dokument

2.1 Impressum

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

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

Abbildungen: © ELGA GmbH

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

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

2.2 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.3 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.4 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.4.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.4.2 SNOMED CT

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.4.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)	Regenstrief Institute, Inc.
Unified Code for Units of Measure (UCUM)	Regenstrief Institute, Inc.
International Classification of Diseases (ICD)	World Health Organization (WHO)
ICD-10 BM*G*	Für Gesundheit zuständiges Bundesministerium www.sozialministerium.at
Anatomical Therapeutic Chemical Classification System (ATC)	World Health Organization (WHO)
Pharmazentralnummer (PZN)	ARGE Pharma im Fachverband der chemischen Industrie Österreichs (FCIO) der Wirtschaftskammern Österreichs (WKO)
EDQM-Codes	Europäisches Direktorat für die Qualität von Arzneimitteln
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. ,

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

2.5 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 gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert.

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 folgen dem Basisstandard HL7 Version 3 mit seinem Referenz-Informationsmodell (RIM). Dieser Leitfaden verwendet das HL7-Template-Austauschformat zur Definition der "Bausteine" (Templates) und ART-DECOR® als Spezifikationsplattform.

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

Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (www.HL7.at). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.

Der Labor- und Mikrobiologiebefund basiert auf den Vorgaben des Allgemeinen Implementierungsleitfadens (Version 3).

Für die Modellierung der technischen Spezifikation diente IHE XD-LAB 2019-08 [TODO].

• IHE Integrationsprofile Patient Care Coordination
• IHE Pharmacy Technical Framework Supplement Community Medication Administration (CMA) Rev. 1.1 – Trial Implementation
• HL7 CDA® R2 Implementation Guide: Personal Healthcare Monitoring Report, Release 1

TODO: Grafik anpassen + Referenz anpassen

2.6 Verbindlichkeit

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

Der Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" (M), "Required" (R) und "Fixed" (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

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

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

2.7 Wichtige unterstützende Materialien

Auf der Website Labor- und Mikrobiologiebefund Guide werden unter anderem folgende Materialien zur Verfügung gestellt:

• die PDF-Version dieses Leitfadens
• Beispieldokumente
• ein erweitertes CDA-Schema
• Schematron-Prüfregeln

Die im weiteren angeführten Templatespezifikationen wurden im Art-Decor Projektrepository Labor- und Mikrobiologiebefund erstellt und können dort eingesehen werden.

Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH (www.elga.gv.at/CDA) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

• Beispieldokumente
• Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
• CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
• Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
• Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
• Hinweise für die zu verwendenden Terminologien
• Leitfaden zur richtigen Verwendung von Terminologien

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

2.8 Bedienungshinweise

2.8.1 Farbliche Hervorhebungen und Hinweise

Themenbezogene Hinweise zur besonderen Beachtung:

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

Hinweis auf anderen Implementierungsleitfaden:

Verweis
Verweis auf den Allgemeinen Leitfaden:…

Themenbezogenes CDA Beispiel-Fragment im XML Format:

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

2.8.2 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

3 Einleitung

[TODO überarbeiten]

3.1 Ausgangslage und Motivation

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

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

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

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

3.2 Zweck des Dokuments

Das vorliegende Dokument enthält die Definition der Inhalte des "Laborbefundes" für das Österreichische Gesundheitswesen. Diese Spezifikation ist das Resultat einer Harmonisierungsarbeit mit dem Ziel medizinische Befunde, innerhalb der derzeit im Aufbau befindlichen österreichischen "Elektronischen Gesundheitsakte" (ELGA), als abgestimmte und einheitlich strukturierte Dokumente darzustellen. Das Dokument wurde von einer Arbeitsgruppe von Vertretern der Österreichischen Ärztekammer, von mehreren Krankenhausträgern und Spitälern, Universitäten und Fachgesellschaften, des österreichischen Normeninstitutes, von der Health Level 7 (HL7) Anwendergruppe Österreich, sowie Personen aus der Wirtschaft erstellt. Sowohl angestellte als auch niedergelassene Labormediziner waren massiv an der Erarbeitung beteiligt.

Die Abstimmung erfolgte gemeinsam mit anderen Arbeitsgruppen, die gleichzeitig an den Inhalten für den "Entlassungsbrief" und den "Befund bildgebende Diagnostik" arbeiten. Vor allem die Informationen über die betroffenen und handelnden Personen, Zeitangaben, Dokumentart und ähnliches im so genannten "Header" wurden eng abgestimmt und im Rahmen eines zentralen Dokumentes "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [OID Root 1.2.40.0.34.7.1]" [4] definiert.

Der Header enthält zum einen administrative Daten (allgemeine Angaben zum Dokument, Daten zum Patienten, usw.) und dient zum anderen zum Teil auch als Quelle für die Metadaten, die bei der Registrierung des Dokuments in ELGA verwendet werden. Der Header wurde über alle Anwendungsbereiche der ELGA einheitlich abgestimmt.

Die medizinisch relevanten Anteile sind im so genannten "Body" enthalten. Die vorliegende Spezifikation der laborspezifischen inkl. mikrobiologische Inhalte eines Labordokuments in ELGA wurde von der Expertengruppe beruhend auf einer Liste mit Vorgaben der österreichischen Gesellschaft für Labormedizin und klinische Chemie (ÖGLMKC) erstellt.

Als technische Basis dient das "Laboratory Technical Framework Volume 3 (LAB TF-3) Revision 3.0, 2011" ([3]) der "Integrating the Healthcare Enterprise" (IHE).

Das Verständnis eines "Laborbefundes" erstreckt sich in diesem Dokument über das gesamte Spektrum der laboranalytisch ermittelten Befunde. Die vorliegende Version definiert grundlegende Anforderungen für die Erstellung von Laborbefunden als CDA Dokumente. Insbesondere wurden Laborbefunde aus der Klinischen Chemie, Hämatologie, Immunchemie und Mikrobiologie/Bakteriologie in die Überlegungen mit einbezogen. Die gewählten Strukturen ermöglichen prinzipiell eine Übermittlung des gesamten Befundspektrums des Laborbereiches, jedoch sind die einzelnen Detailbereiche in folgenden Arbeiten detailliert zu analysieren, abzustimmen und für weitere Laborbefundarten zu definieren. Es existieren vielmehr auch dezidierte Bereiche - wie z.B. die Transfusionsmedizin – für die die Definitionen dieses Leitfadens aufgrund fehlender Strukturen und nicht definierter Codelisten nicht ausreichend sind. Dieser Leitfaden verwendet "Analysen" als Sammelbegriff für Laboruntersuchungen, Laborleistungen und Labormessgrößen.

3.3 Zielgruppe

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

4 Leitfadenerstellungs- und Harmonisierungsprozess

Für die Ausgestaltung der Inhalte von "CDA Implementierungsleitfäden" ist eine breite Beteiligung der Stakeholder wesentlich, um die praktische Nutzbarkeit und die Akzeptanz durch die ELGA-Benutzer sicherzustellen. Für diese interdisziplinären Expertengruppen stehen nicht die technischen, sondern vor allem medizinisch-inhaltliche Aspekte im Vordergrund. Die technischen Inhalte werden großteils von den Redaktionsteams beigetragen.

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

Weitere Details zum Vorgehensmodell sind im Allgemeiner Leitfaden - Kapitel Leitfadenerstellungs- und Harmonisierungsprozess - Vorgehensmodell zu finden.

Dieser Implementierungsleitfaden ist eine Weiterentwicklung des Laborbefundes 2.06.3 und entstand durch die Harmonisierungsarbeit der AG Labor- und Mikrobiologiebefund, die im Zeitraum von [TODO] Oktober 2020 bis November 2020 tagte. Die Teilnehmer der Arbeitsgruppe wurden durch ihre Organisation delegiert.

Die Arbeitsgruppe harmonisierte primär die inhaltlichen Vorgaben und soweit möglich die zu verwendenden Terminologien (Value Sets). Die Formulierung der technischen Spezifikation des CDA Implementierungsleitfadens Labor- und Mikrobiologiebefund erfolgte durch die ELGA GmbH parallel bzw. nach der inhaltlichen Festlegung.

Der Leitfaden wird in einem technischen Abstimmungsverfahren durch die HL7 Austria ("Ballot") zu einem österreichischen Standard. Die Verbindlichkeit zur Anwendung soll durch eine Novellierung des Gesundheitstelematikgesetzes 2012, BGBl.I Nr.111/2012 begründet werden.

4.1 Revision der Leitfäden

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

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

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

4.2 Autoren und Mitwirkende

Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der "Arbeitsgruppe Labor- und Mikrobiologiebefund" bestehend aus nachfolgend genannten Personen. Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht.

4.2.1 Autoren

Das Redaktionsteam bestand aus folgenden Personen:

Name	Organisation	Rolle
Mag. Dr. Stefan Sabutsch	ELGA GmbH, HL7 Austria	Autor, Herausgeber
Gabriel Kleinoscheg, MSc	ELGA GmbH	Autor
DI Andrea Klostermann	ELGA GmbH	Autor
DI Nikola Tanjga	ELGA GmbH	Autor
DI Oliver Kuttin	ELGA GmbH	Autor

Unter Mitwirkung von: Stephan Rainer-Sablatnig (ELGA GmbH), Nina Sjencic, B.A. (ELGA GmbH)

4.2.2 Mitwirkende

Teilnehmer der Arbeitsgruppe Labor- und Mikrobiologiebefund¹

Christoph Arndt (Roche), Christoph Aspöck (Landesklinikum St. Pölten, Institut für Hygiene und Mikrobiologie), Jeroen de Bruin (Medexter Healthcare GmbH), Christa Freibauer (Institut für Pathologie LK Mistelbach; ÖGPath), Joseph Gappmayer (medilab GmbH), Milo Halabi (Institut für klinische Pathologie, Mikrobiologie und molekulare Diagnostik Krankenhaus der Barmherzigen Schwestern Ried; ÖGPath), Alexander Haushofer (ÖGLMKC; Klinikum Wels-Grieskirchen), Markus Hell (Medilab - Laboratorium Dr. Mustafa, Dr. Richter OG), Günter Igler (Analyse BioLab; KH Elisabethinen Linz), Heidrun Kerschner (Analyse BioLab; KH Elisabethinen Linz), Gabriel Kleinoscheg (ELGA GmbH), Andrea Klostermann (ELGA GmbH), Christoph Koidl (MedUni Graz, Institut für Hygiene, Mikrobiologie und Umweltmedizin; BFG Med. Mikrobiologie und Hygiene), Kristiane Kousek (NÖ Landesklinken Holding), Johannes Möst (Österreichische Gesellschaft für Hygiene, Mikrobiologie und Präventivmedizin), Johannes Möst (Österreichische Gesellschaft für Hygiene, Mikrobiologie und Präventivmedizin), Hans Georg Mustafa (Labor Dr. Hans Georg Mustafa, BFG Med. u. Chem. Labordiagnostik, ÖGLMKC), Michael Nöhammer (ÖÄK), Tina Prager (NÖ Landesklinken Holding), Elisabeth Presterl (Universitätsklinik für Krankenhaushygiene & Infektionskontrolle, Medizinische Universität Wien), Stephan Rainer-Sablatnig (ELGA GmbH), Stefan Sabutsch (ELGA GmbH, HL7 Austria), Ulrich Sagel (Universitätsklinik für Hygiene und Mikrobiologie), Tamara Savic (KAGes, Institut für Krankenhaushygiene und Mikrobiologie), Carina Seerainer (ELGA GmbH), Nina Sjencic (ELGA GmbH), Nikola Tanjga (ELGA GmbH), Gerhard Weigl (Inst. f. Labormedizin – Klinik Penzing, Wien ), Birgit Willinger (AKH, MedUni Wien, Klin.Inst.f.Labormedizin) [TODO fehlen noch welche? auch die erwähnen, die per E-Mail mitgeholfen haben (z.B. bei Value Sets)?]

¹ Personen sind in alphabetischer Reihenfolge ohne Titel angegeben.

4.2.3 Autoren und Mitwirkende vergangener Leitfadenversionen

Die erste Version dieses Implementierungsleitfadens (2.06) entstand durch die Harmonisierungsarbeit der "Arbeitsgruppe Laborbefund" im Zeitraum zwischen 2008 und 2012, bestehend aus den unten genannten Personen².

Herausgeber, Editor, CDA Koordinator

Stefan Sabutsch (ELGA GmbH)

Autoren, Fachkoordinatoren und Moderatoren

Matthias Frohner (Fachhochschule Technikum Wien), Alexander Mense (Fachhochschule Technikum Wien, HL7 Austria), Stefan Sabutsch (ELGA GmbH, HL7 Austria), Stefan Sauermann (Fachhochschule Technikum Wien)

AG Teilnehmer

Bernhard Böhm (Vinzenz Gruppe Krankenhausbeteiligungs- und Management GmbH), Franz Burghuber (Kurienversammlung der niedergelassenen Ärzte der OÖ Ärztekammer), Christian Cebulla (KAV Wien, Generaldirektion), Georg Endler (Wilhelminenspital der Stadt Wien, Zentrallabor, KAV Wien), Manuela Födinger (KFJ – Sozialmed. Zentrum Süd, Institut für Laboratoriumsdiagnostik), Helmuth Gamper (Max management Consulting GmbH), Ferenc Gerbovics (Fachhochschule Technikum Wien), Bernhard Göbl (act Management Consulting GmbH), Andrea Griesmacher (Univ.Klin. Innsbruck, Zentralinst. Labordiagnostik), Walter-Michael Halbmayer (ÖQUASTA; KH Hietzing + NZ Rosenhügel, Institut f. Labordiagnostik), Susanne Hauptlorenz (LKH Vöcklabruck, Institut f. Med.Chem. Labordiagnostik u. Blutdepot), Alexander Haushofer (Österreichische Ärztekammer, KH St. Pölten, Inst. für Laboratoriumsmedizin), Jörg Hofmann (Österreichische Ärztekammer, Wiener KAV, Sozialmedizinisches Zentrum Ost - Donauspital, Institut für Labormedizin), Gerhard Holler (Österreichische Ärztekammer, ON-K 238), Konrad Hölzl (Wiener Krankenanstaltenverbund, KAV-IT), Wolfgang Hübl (KAV Wien, Wilhelminenspital, Zentrallabor, ÖGLMKC), Christof Jungbauer (Rotes Kreuz, Blutspendezentrale Wien), Christian Kampenhuber (GESPAG Gesundheitsinformatik-Bereichsleiter), Harald Kessler (Medizinische Universität Graz, Institut für Hygiene, Mikrobiologie und Umweltmedizin), Christian Kraml (Systema), Michael Krausenbaum (vision4health Deutschland GmbH & Co. KG), Walter Krugluger (Sozialmedizinisches Zentrum Ost), Thomas Leitha (Sozialmedizinisches Zentrum Ost), Herbert Matzenberger (Systema), Susanna Michalek (Initiative-ELGA), Helmut Mittermayer (Elisabethinen Linz), Georg Mustafa (Österreichische Ärztekammer, Bundesfachgruppe Labor), Georg Paucek (Medicon Medical Consulting), Johann Perné (Medizinisches Labor Perné), Gerald Regenfelder (KABEG), Dietmar Reiter (Tilak, Informationstechnologie/IT-Abteilung), Hans Richter (Labatech Handelsgesellschaft m.b.H.), Harald Rubey (LK Weinviertel Mistelbach, Laborinstitut, NÖ LK-Holding), Dieter Schwartz (Med. Uni. Wien, Klinik f. Blutgruppenserologie u. Transfusionsmedizin), Wolfgang Sischka (Assista Laborelectronics GmbH), Thomas Szekeres (Österreichische Ärztekammer), Beate Tiran (Kages Zentrallabor), Christoph Unfried (HCS, Health Communication Service), Philipp Urbauer (Fachhochschule Technikum Wien)

Patronanz, Akkordierung, Ergänzungen, Zustimmung

Clemens Auer (Bundesministerium für Gesundheit), Michael Danninger (Labene), Hubert Eisl (ELGA GmbH), Peter Fraunberger (Medizinisches Zentrallaboratorium GmbH), Josef Galler (Steiermärkische Krankenanstalten-ges.m.b.H.), Gerhard Gretzl (Solve Consulting), Ulrike Gruber-Mösenbacher (Landeskrankenhaus Feldkirch, Institut für Pathologie), Milo Halabi (Krankenhaus der Barmherzigen Schwestern Ried, Inst. f. Pathologie), Elisabeth Haschke-Becher (A.ö. Krankenhaus der Elisabethinen Linz, Institut für Medizinische und Chemische Labordiagnostik), Susanne Herbek (ELGA GmbH), Wolfgang Hiesl (Oö. Gesundheitsfonds / eHealth Management), Martin Hurch (ELGA GmbH), Stylianos Kapiotis (Med. Uni. Wien, Klinisches Institut für Medizinische und Chemische Labordiagnostik), Peter Konrath (B&S Zentrallabor), Oliver Kuttin (ELGA GmbH), Georg Lechleitner (Tilak, Abteilungsleiter Informationstechnologie/IT-Abteilung), Hubert Leitner (Steiermärkische Krankenanstalten-ges.m.b.H.), Helmut Lindorfer (Österreichische Agentur für Gesundheit und Ernährungssicherheit GmbH – AGES), Sabine Manhardt (Österreichische Ärztekammer, Sekretariat), Achim Mühlberger (GRZ IT Center Linz GmbH), Hans Georg Mustafa (Labor Dr. Hans Georg Mustafa, Fachgesellschaft Labormedizin), Michael Nebel (Gibodat EDV- und Organisationsberatungs GmbH), Susan Netzl (AUVA - Unfallkrankenhaus Meidling, Labor), Claudia Perndl (A.ö. Krankenhaus der Elisabethinen Linz, Institut für Medizinische und Chemische Labordiagnostik, EDV), Sven Plattner (BKH Hall in Tirol, EDV), Thomas Pöckl (NÖ Landeskliniken-Holding), Angelika Reiner-Concin (Sozialmedizinisches Zentrum Ost – Donauspital, Pathologisch-Bakteriologisches Institut), Alexander Schanner (NÖ Landesklinikenholding), Gerhard Schobesberger (Österreichische Ärztekammer, Labor Schobesberger), Peter Schöttel (Bartelt GmbH), Christian Schweiger (Medizinische Universität Wien / AKH Wien, klinische Abteilung für Medizinisch-chemische Labordiagnostik), Herbert Stekel (AKH Linz, Institut für Laboratoriumsmedizin), Romana Thiel (HCS, Health Communication Service), Peter Uher (Telekom Austria), Michael Weidenauer (Assista), Thomas Wrba (Medizinische Universität Wien)

Andere ELGA Arbeitsgruppen:

Entlassungsbrief Arzt und Pflege: Jürgen Brandstätter (CodeWerk Software Services and Development GmbH)

Befundbericht Radiologie: Andreas Lindner (Lindner TAC), Martin Weigl (AIMC)

AG Laborbefund 2017

Die Änderungen für Version 2.06.2 wurde von der AG Laborbefund am 12.1.2017 abgenommen. Teilnehmer der AG Laborbefund waren:

Maria Abzieher (Wiener Krankenanstaltenverbund), Robert Alscher (Humanomed IT Solutions Gmbh), Daniel Außerdorfer (Univ.Klin. Innsbruck, Zentralinstitut für Medizinische und Chemische Labordiagnostik (ZIMCL)), René Berger (Synlab), Barbara Dall (CGM), Zeljko Drljaca (Institut für medizinische und chemische Labordiagnostik Gesellschaft m.b.H), Daniela Eisner (Salzburger Landeskliniken ), Christian Fersterer (Salzburger Landeskliniken), Matthias Frohner (FH Technikum Wien), Josef Galler (Steiermärkische Krankenanstalten-ges. m.b.H.), Andrea Griesmacher (Univ.Klin. Innsbruck, Zentralinstitut für Medizinische und Chemische Labordiagnostik (ZIMCL)), Gernot Gruber (Institut für medizinische und chemische Labordiagnostik Gesellschaft m.b.H), Sylvia Handler (biomed austria - Österreichischer Berufsverband der Biomedizinischen AnalytikerInnen), Susanne Hauptlorenz (Salzkammergut-Klinikum Vöcklabruck, Institut für Med.Chem. Labordiagnostik und Blutdepot), Alexander Haushofer (ÖGLMKC; Klinikum Wels-Grieskirchen), Wolfgang Hießl (Oö. Gesundheitsfonds / eHealth Management), Michael Hubmann (Med. Zentrallaboratorium GmbH), Günter Igler (Analyse BioLab; KH Elisabethinen Linz), Sonja Jansen-Skoupy (KAV Wien, SMZ Süd), Michael Krausenbaum (CGM LAB Deutschland GmbH), Herwig Loidl (Carecenter Software GmbH), Birgit Luxbacher (biomed austria - Österreichischer Berufsverband der Biomedizinischen AnalytikerInnen), Clemens M. Sampl (BMGF), Herbert Matzenberger (CompuGroup Medical CEE GmbH), Alexander Mense (Fachhochschule Technikum Wien, HL7 Austria), Hans Georg Mustafa (Labor Dr. Hans Georg Mustafa, BFG Med. u. Chem. Labordiagnostik, ÖGLMKC), Stefan Mustafa (Labor Doz. Mag. DDr. Stefan Mustafa), Michael Nöhammer (Ärztekammer Österreich), Thomas Pöckl (NÖ Landeskliniken-Holding), Elisabeth Presterl (Universitätsklinik für Krankenhaushygiene & Infektionskontrolle, Medizinische Universität Wien), Sebastian Reimer (BMGF), Harald Rubey (LK Weinviertel Mistelbach, Laborinstitut, NÖ LK-Holding), Stefan Sabutsch (ELGA GmbH, HL7 Austria), Ulrich Sagel (Universitätsklinik für Hygiene und Mikrobiologie), Karin Salzmann (Univ. Klinik für Innere Medizin Innsbruck), Stefan Sauermann (FH Technikum Wien, Interoperabilitätsforum Österreich), Peter Schöttel (Bartelt GmbH), Christian Schweiger (Medizinische Universität Wien / AKH Wien, klinische Abteilung für Medizinisch-chemische Labordiagnostik), Carina Seerainer (ELGA GmbH), Josef Seier (Klinikum Wels-Grieskirchen), Wolfgang Sischka (Assista Laborelectronics GmbH), Herbert Stekel (Kepler Universitätsklinikum GmbH), Michael Svizak (AUVA Hauptstelle - Ärztliche Direktion), Gerhard Weigl (Inst. f. Labormedizin – Otto-Wagner-Spital Wien)

² Personen sind in alphabetischer Reihenfolge ohne Titel angegeben.

5 Technischer Hintergrund

Der technische Hintergrund soll im allgemeinen Leitfaden nachgelesen werden.

6 Allgemeine Richtlinien für ELGA CDA-Implementierungsleitfäden

Die allgemeinen Richtlinien für CDA-Implementierungsleitfäden sollen beachtet werden.

7 Konformitätsprüfung

Ein zu diesem Implementierungsleitfaden konformes CDA-Dokument ist zunächst ein valides CDA Release 2.0 XML-Dokument mit Header und Body. Darüber hinaus erfüllt es alle in diesem Leitfaden festgelegten "Geschäftsregeln".

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

Hinweis: Nicht alle Geschäftsregeln können mit Schema oder Schematron geprüft werden (etwa Inhalte von Multimedia-Attachments, Dokumentengröße). Zusätzliche Validierungsschritte sind gegebenenfalls notwendig, um alle Regeln zu überprüfen zu können.

Die Kapitel zu den technischen Konformitätsprüfungen von CDA-Dokumenten, gemäß diesem Dokumentleitfadens mittels Schema und Schematron, sind im allgemeinen Leitfaden unter den folgenden Links zu finden:

• Schema-Prüfung
• Schematron-Prüfung
• Online-Validation von CDA-Dokumenten
• Hinweise zur Konformitätsprüfung
• Abnahmeprüfung für ELGA e-Befunde
• Zertifizierung

8 Datentypen

Im Kapitel Datentypen des allgemeinen Leitfadens werden nur die Datentypen beschrieben, die in ELGA CDA-Dokumenten wie diesem zur Anwendung kommen. Für weiterführende Informationen wird auf den zugrundeliegenden Standard Health Level Seven Version 3 (V3), Normative Edition verwiesen.

9 Vorgaben zum medizinischen Inhalt

9.1 Allgemeiner Laborbefund

Die inhaltlichen Definitionen beruhen auf den Mindestvorgaben der österreichischen Gesellschaft für Labormedizin und klinischen Chemie (ÖGLMKC) und wurden weiter verfeinert. Tabelle 1 zeigt einen Überblick über die inhaltlich abzubildenden medizinisch relevanten Daten.

Feld	Beschreibung	Bereich
Allgemeine Befundinformationen
Zeitpunkt der Auftragserfassung	Datum und Zeitpunkt, an dem das analysierende Labor die Anforderung vom Zuweiser in der Labor EDV erfasst hat	Header
Auftragsdiagnose (Zuweiserdiagnose)	Vom Auftraggeber bestimmte und dem Labor übermittelte Verdachtsdiagnose	Body
Überweisungsgrund	Vom Auftraggeber übermittelter Überweisungsgrund/Fragestellung	Body
Befundtext	Kommentar zum gesamten Befund	Body
Spezimeninformation
Zeitpunkt der Spezimengewinnung	Damit ist jenes Datum und Zeitpunkt gemeint, an dem das Spezimen zur Analyse gewonnen wurde. Die Dokumentation des Zeitpunkts der Spezimengewinnung ist in der Verantwortung der entnehmenden Person, die in vielen Fällen mit dem Befundersteller nicht identisch ist, da meist Spezimen zur Analyse an Labors versendet werden. Daher ist der Zeitpunkt vielfach im Labor nicht feststellbar.	Body
Zeitpunkt des Einlangens des Spezimen	Datum und Zeit der Probenannahme im Labor	Body
Art des Spezimens (Specimen Type)	Art der Probe (=Materialart)	Body
Entnahmeort	Angabe der Körperstelle, von der das Spezimen stammt	Body
Entnahmeart (SpecimenCollectionProcedure)	Art der Gewinnung	Body
Specimen ID	Eindeutige Nummer des Spezimen	Body
Entnehmende Person (Performer)	Person, welche die Entnahme der Probe durchgeführt hat	Body
Kommentar zum Spezimen	Präanalytik pro Spezimen zur Spezimenqualität	Body
Allgemeine Anmerkungen des Labors zur Spezimenqualität	Textinformationen zur Spezimenqualität	Body
Allgemeine Laborergebnisse
Gruppierung / Befundgruppen (Organizer)	Analysengruppierung	Body
ID des Tests	Eindeutige Codierung des Tests	Body
Analysenbezeichnung	Bezeichnung der Analyse (aus dem Value Set ELGA_Laborparameter)	Body
Ergebnis		Body
Einheit		Body
Referenzbereiche	Für die Beurteilung relevante Referenzwerte. Die Angabe mehrerer Referenzbereiche zu einem Test ist möglich.	Body
Befundinterpretation	Codierte Bewertung des Ergebnisses	Body
Deltacheck	Tendenzielle Veränderung zu Vorwerten	Body
Ergebniskommentar	Kommentar des Labors zu einem einzelnen Testergebnis	Body
Externes Labor	Kennzeichen ob ein Ergebnis extern ermittelt wurde	Body

Tabelle 1: Im Laborbefund abzubildende medizinische Daten

9.1.1 Bereiche (Specialities)

Jeder CDA–Laborbefund ist laut vorliegender Headerdefinition als "Multidisciplinary Report" ausgewiesen (vgl. Kapitel 5.1.2), kann jedoch mehrere unterschiedliche Teilbefunde aus verschiedenen Bereichen im Body des Dokumentes beinhalten (z.B. Hämatologie oder Bakteriologie oder beide Arten gemeinsam). D.h. diese Teilbefunde bilden die erste Gliederungsebene des Bodys - die "Bereiche" oder - in Anlehnung an die Definitionen der "IHE" – "Specialities" (vgl. [3]). zeigt die mögliche Gliederung auf der ersten Ebene innerhalb des Bodys.

Abbildung 1: Gliederung nach Bereiche /Specialities

Die derzeit für den österreichischen Laborbefund definierten Specialities werden im Rahmen des hierarchisch organisierten Value Sets "ELGA_Laborstruktur" definiert, wobei für Bereiche nur Einträge der Ebene 0 und 1 verwendet werden dürfen. gibt einen auszugsweisen Überblick über die derzeit festgelegten Specialities. Die Anwendung der Bereiche ist optional. Es können auch alle Untersuchungen in einer Section unter dem Bereich "Allgemeiner Laborbefund" zusammengefasst werden. Bei Verwendung der Bereiche ist die Reihenfolge gem. Value Set verpflichtend einzuhalten.

Für EIS "Enhanced" ist die Codierung der Bereiche (als unterschiedliche section-Elemente) zwingend vorgeschrieben.

Code	Bereich (Speciality)
100	Blutgruppenserologie
200	Blutgasanalytik
300	Hämatologie
400	Gerinnung/Hämostaseologie
…	…

Tabelle 2: Liste der Bereiche, auszugsweise gem. ELGA Value Set "ELGA_Laborstruktur", die sich auch in ELGA_Laborparameter widerspiegelt.

9.1.2 Gruppen (Befundgruppen)

Innerhalb dieser Bereiche erfolgt in der Regel eine Strukturierung und Gliederung der Ergebnisse zur besseren Lesbarkeit und Auffindbarkeit in "Befundgruppen". Das ELGA Value Set "ELGA_Laborstruktur" definiert zulässige Befundgruppen. Es besteht jedoch auch die Möglichkeit Ergebnisse ohne Befundgruppenstrukturierung zu übermitteln. zeigt die möglichen Gliederungsarten.

Abbildung 2: Strukturierungsmöglichkeiten Body

und zeigen Ausschnitte aus Beispielen zu Laborbefunden mit Befundgruppen und den entsprechenden medizinischen Inhalten. Der "Allgemeine Laborbefund" enthält die Bereiche "Hämatologie" und "Hämostaseologie" mit darunter liegenden Befundgruppen; der "Bakteriologische Befund" enthält ein Bespiel für die Darstellung eines Antibiogrammes.

Abbildung 3: Ausschnitt Beispielbefund

Bereiche (Specialities) und Gruppen werden in CDA Level 3 in entsprechende Klassen umgesetzt und gemäß des hierarchischen Value Sets "ELGA_Laborstruktur" codiert. Die Codierung der Bereiche erfolgt durch Elemente der ersten und zweiten Ebene (0 bzw. 1) und die der Befundgruppen durch Elemente der drittenValue Set Ebene (2). Die Reihenfolge der Bereiche bzw. Gruppen gem. Value Set ist verpflichtend einzuhalten.

Abbildung 4: Ausschnitt Bakteriologie Beispielbefund

9.2 Mikrobiologische Befunde

Unter den Analysen eines Laborbefunds finden sich viele aus dem Bereich der Mikrobiologie. Dieser Teil des Leitfadens beschäftigt sich mit den mikrobiologischen Methoden und Analysen im Labor, die sich nicht über die "klassische" Struktur eines Laborbefundes darstellen lassen. Dies betrifft hauptsächlich die Bakteriologie zum Nachweis von Bakterien, z.B. mit der Darstellung von Keimwachstum, Koloniebeschreibung und Antibiogrammen. Die Strukturierung des mikrobiologischen Befundes folgt einem bestimmten Muster, das den Untersuchungsverlauf widerspiegelt: Beschreibung des entnommenen Materials (z.B. Mittelstrahlharn), die direkt untersuchten Eigenschaften des Materials (z.B. Farbe), mikroskopische Untersuchung des Materials (z.B. Erythrozyten, Leukozyten, grampositive Bakterien). Falls Bakterienwachstum festgestellt wird, folgt eine Beschreibung der Kulturen, eine Benennung der Reinkulturen (Isolate) mit Nennung der taxonomischen Bestimmung der Mikroorganismen (z.B. Streptococcus pyogenes) ggf. mit Angabe des Serovars/Pathovars. Meist wird ein Antibiogramm angefügt. Es kann auch eine minimale Hemmkonzentration (MHK) enthalten sein.

Dementsprechend ist folgende hierarchische Struktur abzubilden:

Tabelle 3 zeigt einen Überblick über die inhaltlich abzubildenden medizinisch relevanten Daten für den mikrobiologischen Befund.

Feld	Beschreibung	Bereich
Allgemeine Befundinformationen
Zeitpunkt der Auftrags-erfassung	Datum und Zeitpunkt, an dem das analysierende Labor die Anforderung vom Zuweiser in der Labor EDV erfasst hat	Header
Auftragsdiagnose (Zuweiserdiagnose)	Vom Auftraggeber bestimmte und dem Labor übermittelte Verdachtsdiagnose	Body
Überweisungsgrund	Vom Auftraggeber übermittelter Überweisungsgrund/Fragestellung	Body
Angeforderte Untersuchungen	Vom Auftraggeber angeforderte Untersuchungen bzw. das angeforderte Analysespektrum	Body
Befundtext	Kommentar zum gesamten Befund	Body
Spezimeninformation
Zeitpunkt der Spezimengewinnung	Damit ist jenes Datum und Zeitpunkt gemeint, an dem das Spezimen zur Analyse gewonnen wurde. Die Dokumentation des Zeitpunkts der Spezimengewinnung ist in der Verantwortung der entnehmenden Person, die in vielen Fällen mit dem Befund­ersteller nicht identisch ist, da meist Spezimen zur Analyse an Labors versendet werden. Daher ist der Zeitpunkt vielfach im Labor nicht feststellbar.	Body
Zeitpunkt des Einlangens des Spezimen	Datum und Zeit der Probenannahme im Labor	Body
Art des Spezimens (Specimen Type)	Art der Probe (=Materialart)	Body
Entnahmeort	Angabe der Körperstelle, von der das Spezimen stammt	Body
Entnahmeart (SpecimenCollectionProcedure)	Art der Gewinnung	Body
Specimen ID	Eindeutige Nummer des Spezimen	Body
Entnehmende Person (Performer)	Person, welche die Entnahme der Probe durchgeführt hat	Body
Kommentar zum Spezimen	Präanalytik pro Spezimen zur Spezimenqualität	Body
Allgemeine Anmerkungen des Labors zur Spezimenqualität	Textinformationen zur Spezimenqualität	Body
Mikrobiologische Laborergebnisse
Makroskopie	Allgemeine Information über die Materialbeschaffenheit	Body
Mikroskopie	Mikroskopiesche Beobachtungen betreffend des Materials/Spezimen	Body
Kultureller Erregernachweis	Angabe von Ergebnissen, welche mit Hilfe von Kulturen erlangt werden	Body
Antibiogramm	Angaben zur Empfindlichkeit bzw. Resistenz von mikrobiellen Krankheitserregern gegenüber Antibiotika	Body
Minimale Hemmkonzentration	Angaben zur minimalen Hemmkonzentration bezüglich der Empfindlichkeit bzw. Resistenz von mikrobiellen Krankheitserregern gegenüber Antibiotika	Body
Molekularer Erregernachweis	Ergebnisse von molekularen Erregernachweisen	Body
Infektionsserologie	Ergebnisse von infektionsserologisch relevanten Analysen	Body

Tabelle 3: Im mikrobiologischen Befund abzubildende medizinische Daten

10 Funktionale Anforderungen

10.1 Voraussetzungen für den Zugriff auf e-Befunde in ELGA

Der ELGA GDA ist in ELGA angemeldet, berechtigt und besitzt eine gültige Kontaktbestätigung für den Patienten. Der Patient ist ELGA-Teilnehmer und hat keinen generellen, partiellen oder situativen Widerspruch hinsichtlich ELGA eingelegt.

10.2 Anwendungsfälle des Dokumentenmanagements

Die folgenden Kapiteln aus dem allgemeinen Leitfaden stellen eine Zusammenfassung der Inhalte der ELGA-Gesamtarchitektur, des Leitfadens XDS Metadaten und Usability Styleguides zum Thema e-Befunde dar. Detailinformationen sind in den entsprechenden Dokumenten nachzulesen (verfügbar auf der Homepage der ELGA GmbH). Die wesentlichen Anwendungsfälle sind

• Schreiben und Einbringen von Dokumenten
• Versionierung von Dokumenten
• Stornierung von Dokumenten
• Filtern und Suchen von Dokumenten
• Lesen von Dokumenten

10.2.1 Dokument-Metadaten (XDS-Metadaten) Einschränkung

TODO: Anpassen, derzeit TME!

XDS-Mapping	Optio- nalität	CDA-Element clinicalDocument.	Beispiel	Erklärung
formatCode	R	.templateId/@extension	@extension="XDSdocumentEntry.formatCode ^urn:hl7-at:telemon-epi:2020" @isplayName= "HL7 Austria Telemonitoring Episodenbericht 2020"	Version des Implementierungsleitfaden Telemonitoring Episodenbericht mit XDSdocumentEntry.formatCode als Extension. Das templateId-Element mit einer Extension beginnend mit "XDSdocumentEntry.formatCode^" wird ins XDS-Attribut formatCode gemappt (ohne Präfix XDSdocumentEntry.formatCode^).
typeCode	R	.code	@code="75497-8" @displayName="Telehealth Progress note" @codeSystem="2.16.840.1.113883.6.1"	Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des "Telemonitoring Zwischen-Episodenbericht" ein vorgegebenes "code"-Element.
			@code="75498-6" @displayName="Telehealth Summary note" @codeSystem="2.16.840.1.113883.6.1"	Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des "Telemonitoring Entlassungs-Episodenbericht" ein vorgegebenes "code"-Element.
classCode	R	.code.translation	@code="75496-0" @displayName="Telehealth note" @codeSystem="2.16.840.1.113883.6.1"	Bezeichnet die "Dokumentklasse" in dem untergeordneten "translation"-Element. Einzig zulässige Wert für den telemonitoring Episodenbericht ist Telehealth note (75496-0).
title	R	.title	Bsp.: "Zwischenbericht Herz-Mobil Steiermark (23.3.2020-30.4.2020)"	Für den Telemonitoring Episodenbericht mit dem LOINC Code 75497-8 (Telehealth Progress note) muss der Titel mit "Zwischenbericht" beginnen. Danach soll das Telegesundheitsdienste-System angegeben werden und mit dem Zeitraum der in dem Dokument vorhandenen Daten enden.
			Bsp.: "Entlassungsbericht Herz-Mobil Tirol (5.2020)"	Für den Telemonitoring Episodenbericht mit dem LOINC Code 75498-6 (Telehealth Summary note) muss der Titel mit "Entlassungsbericht" beginnen. Danach soll das Telegesundheitsdienste-System angegeben werden und mit dem Zeitraum der in dem Dokument vorhandenen Daten enden.
eventCodeList	R	.documentationOf .serviceEvent.code	@code="719858009" @displayName="Telehealth monitoring (regime/therapy)" @codeSystem="2.16.840.1.113883.6.96" @codeSystemName="SNOMED CT"	Code der Gesundheitsdienstleistung.
serviceStartTime	R	.documentationOf.serviceEvent .effectiveTime.low	Zeitpunkt des Behandlungsbeginns (erster medizinisch relevanter Behandlungstag dieser dokumentierter Gesundheitsdienstleistung)	Beginn der Gesundheitsdienstleistung.
serviceStopTime	R	.documentationOf.serviceEvent .effectiveTime.high	Zeitpunkt des Behandlungsendes (letzter medizinisch relevanter Behandlungstag dieser dokumentierter Gesundheitsdienstleistung, muss sich von Behandlungsbeginn unterscheiden)	Ende der Gesundheitsdienstleistung.

11 Anwendungsfälle

Die Einsatzszenarien für dieses Datenaustauschformat werden in Form von Anwendungsfälle beschrieben, um dem Leser den Hintergrund zu vermitteln. Diese Beschreibung der Anwendungsfälle ist nicht normativ und keine Vorentscheidung für die tatsächliche Umsetzung.

TODO: Die Definition in passendes Kapitel verschieben.

Definition: Der Laborbefund wurde für die Arbeit an diesem Leitfaden wie folgt definiert:

Ein Laborbefund (aus dem Bereich der med. u. chem. Labordiagnostik) ist der fachärztlich vidierte, kommentierte/interpretierte Befund morphologischer, biologischer, chemischer, molekularer, physikalischer und spezieller immunologischer Untersuchungsverfahren aus Körpersäften, der Beurteilung ihrer morphologischen Bestandteile sowie von ab- und ausgeschiedenem Untersuchungsmaterial zur Erkennung physiologischer Eigenschaften, krankhafter Zustände, zu Verlaufskontrollen und zur Gesundheitsvorsorge/Prophylaxe.

ELGA Laborbefunde umfassen u. a. klinische Chemie und Immunchemie, Hämatologie (Erkrankungen des Blutes) und Hämostaseologie (Störungen der Blutgerinnung), Proteinchemie, Serologie, molekulare Diagnostik, Toxikologie, Drugmonitoring, Mikrobiologie, Infektionsserologie, Zytologie, Untersuchungen und die Hilfestellung für andere Fächer im Rahmen von Therapievorschlägen bei Gerinnungsstörungen, Antikoagulanzientherapien, der Impfkontrolle, Vorsorgediagnostik und Risikostratifizierung.

Untersuchungen des Sonderfaches "Blutgruppenserologie und Transfusionsmedizin" werden in einer gesonderten ELGA Dokumentenklasse (geplant) abgehandelt.

Sofern keine andere Regelung zutrifft, obliegt die Entscheidung ob ein Befund in ELGA gestellt wird dem Befundersteller.

Im ELGA Laborbefund dürfen nur dann Ergebnisse aus genetischen Analysen enthalten sein, wenn ihre Dokumentation in Übereinstimmung mit dem Gentechnikgesetz (GTG § 71a, BGBl. I Nr. 127/2005) erfolgt.

Der in diesem Leitfaden beschriebene Laborbefund dient also zum Austausch von fertiggestellten, und fachärztlich vidierten Befunden innerhalb und zwischen Einrichtungen des Gesundheitswesens. Ein wesentlicher Nutzer der Befunde ist auch der Patient selbst, der die Befunde über das ELGA Bürgerportal einsehen wird.

Der in diesem Leitfaden beschriebene Laborbefund ist zur Dokumentation und Kommunikation (vollständig) fertiggestellter Laborbefunde gedacht.

Der hier beschriebene Laborbefund ist nicht vorgesehen um Zwischenergebnisse und Nachrichten über einzelne Prozessschritte zu kommunizieren, wie etwa

• die Anforderung von Laboruntersuchungen
• das Einlangen einer Probe im Labor
• den Beginn, Stornierung oder die Fertigstellung einzelner Untersuchungen

Ergänzungen und Korrekturen von Laborbefunden werden unterstützt

11.1 Anwendungsfall LAB01: "Laboruntersuchung eines niedergelassenen Labors"

Typischerweise entstehen Laborbefunde in medizinischen Labors. Einerseits sind das niedergelassene Labors, die als selbständige Unternehmen Laboruntersuchungen anbieten. Diese werden vielfach auf Zuweisung von Patienten durch praktische Ärzte im niedergelassenen Bereich tätig. Die Entstehung eines Laborbefundes beginnt mit einer Überweisung durch einen niedergelassenen Arzt, oder mit einer Anforderung innerhalb eines Spitals. Entweder wird das Spezimen am Patienten gleichzeitig entnommen, und dann ins Labor geschickt oder der Patient muss das Labor aufsuchen, und das Spezimen wird dann erst dort entnommen. Nach Abschluss der Untersuchung wird der Befund dem zuweisenden Arzt und/oder dem Patienten in Papierform übermittelt.

Laboruntersuchungen im Rahmen ambulanter Aufenthalte in einem Spital fallen ebenso unter diesen Anwendungsfall.

11.2 Anwendungsfall LAB02: "Laboruntersuchung im Rahmen eines stationären Aufenthalts in einem Spital"

Im Rahmen von stationären Aufenthalten von Patienten in Spitälern kommt es in der Regel zu einer Reihe von Laboruntersuchungen, die in der internen Krankengeschichte (meistens auch elektronisch) abgelegt werden. Relevante Befunde werden dem einweisenden Arzt bzw. dem Patienten im Zuge der Entlassungsdokumentation mit übermittelt. Dieses passiert oftmals als Teil des Entlassungsbriefes. Welche Werte und welche Befunde entsprechende Relevanz haben um weitergeleitet zu werden, entscheidet das jeweilige ärztliche Fachpersonal in der Klinik.

11.3 Anwendungsfall LAB03: "Teilweise externe Vergabe von Laboruntersuchungen"

In vielen Fällen kommt es zu Kooperationen zwischen Laborbefund erstellenden Organisationen. Folgende Fälle seien angeführt:

• Spitäler kooperieren mit niedergelassenen Labors. Zum Teil verfügen nicht alle Spitäler über eigene Labors, andererseits werden auch Spezialuntersuchungen, die das Spitalslabor nicht durchführt, an niedergelassene Labors vergeben.
• Niedergelassene Labors verfügen nicht über das volle Leistungsspektrum und senden Laboruntersuchungen an Spitallabors, welche spezielle Parameter messen können.
• Es bestehen Kooperationen zwischen mehreren Spitälern. Einerseits sind das oft Spitäler, die dem gleichen Spitalsträger angehören. Teilweise bestehen auch Kooperationen zwischen Spitälern unterschiedlicher Träger, die durch die örtliche Nähe leicht Proben austauschen können.

In allen Fällen werden einzelne Labortests nicht selbst durchgeführt sondern diese Tests an ein externes kooperierendes Labor vergeben. Das externe Labor führt dann den Test durch, und übermittelt die Ergebnisse an das ursprünglich für die Untersuchungen zuständige Labor. Dort werden dann die vom externen Labor ermittelten Testergebnisse in den eigenen Laborbefund eingefügt. Das ursprünglich zuständige Labor, das den Befund erstellt, muss in diesem Fall die extern erbrachten Testergebnisse als solche erkennbar kennzeichnen.

11.4 Anwendungsfall LAB04: "Update von Laborbefunden"

Ein fertiggestellter Laborbefund wird korrigiert oder ergänzt, um

• die Inhalte des Befundes zu korrigieren (etwa das Ergebnis einer Analyse),
• einzelne (fehlerhafte) Analysen nachträglich aus dem Befund zu stornieren oder
• fehlende Analysen zu ergänzen (etwa besonders lang dauernde Analysen).

Änderungen sollen im Text für den Leser klar kenntlich gemacht werden (eine codierte Angabe kann im narrativen Text mit Revisionsmarken erfolgen).

Eine Korrekturversion MUSS in ELGA immer alle zum Befund gehörigen Analysen enthalten, da die Vorversion als veraltet (deprecated) gekennzeichnet wird. Stornierte Analysen sind explizit mit dem entsprechenden StatusCode zu kennzeichnen.

Für den Leser/Empfänger gilt: Eine neue Version ersetzt die alte Version des Befundes, alle Analysen sollen beim Import ersetzt bzw. überschrieben werden. Sollte eine Analyse in der neuen Version fehlen, soll diese als "storniert" interpretiert werden.

12 Dataset des Labor- und Mikrobiologiebefunds

Das Dataset (auch "Datenarten" oder "Konzepte") listet alle mit der Arbeitsgruppe abgestimmten Inhalte des Leitfadens auf. Es enthält Beschreibungen der Elemente mit Synonymen.

Dataset-Elemente können auf das CDA Datenmodell gemappt werden. In den Metadaten eines Templates sind alle assoziierten Konzepte auf einen Blick ersichtlich. Im Template-Body wird das assoziierte Konzept beim entsprechenden Datenelement angezeigt.

Die Live-Version des Datasets in Art-Decor kann unter folgendem Link betrachtet werden.

13 Technische Spezifikation

Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben.

Der Header entspricht mit Ausnahme der erwähnten Abweichungen den bisherigen ELGA CDA-Leitfäden ("Allgemeiner Leitfaden"). Der Body enthält die tatsächlichen (medizinischen) Inhalte des Dokuments. Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.

13.1 Übersichtstabelle der CDA Strukturen des Headers

Dieses Kapitel gibt einen Überblick über die Elemente des CDA Headers und den Vorgaben bezüglich Kardinalität und Konformität.

Die jeweiligen Links in der letzten Spalte zeigen auf die einzelnen Header Elemente im allgemeinen Leitfaden.

Der aktuelle Leitfaden ist für den ELGA Kontext entwickelt worden, kann jedoch auch für andere Zwecke, welche als eHealth zusammengefasst werden, verwendet werden.

Element	Kard/Konf ELGA	Kard/Konf eHealth	Bedeutung / Link zum Kapitel
realmCode	1..1 M	1..1 M	Hoheitsbereich des Dokuments
typeId	1..1 M	1..1 M	Kennzeichnung CDA R2
templateId	3..* M	3..* M	Kennzeichnung von Strukturvorschriften
id	1..1 M	1..1 M	Dokumenten-Id
code   translation	1..1 M   1..1 M	1..1 M   0..* R	Klassifikation des Dokuments (fein und grob)
title	1..1 M	1..1 M	Titel des Dokuments
sdtc:statusCode	0..1 C	0..1 O	Status des Dokuments
hl7at:terminologyDate	1..1 M	0..1 O	Terminologie-Datum des Dokuments
hl7at:formatCode	1..1 M	0..1 O	FormatCode des Dokuments
hl7at:practiceSettingCode	1..1 M	0..1 O	Fachliche Zuordnung des Dokuments
effectiveTime	1..1 M	1..1 M	Erstellungsdatum des Dokuments (medizinisch relevantes Datum)
confidentialityCode	1..1 M	1..1 M	Vertraulichkeitscode
languageCode	1..1 M	1..1 M	Sprachcode des Dokuments
setId versionNumber	1..1 M 1..1 M	1..1 M 1..1 M	Versionierung des Dokuments
recordTarget	1..1 M	0..1 C	Patient
recordTarget de-identified	0..0 NP	0..1 C	Anonymer oder pseudonymisierter Patient
author	1..* M	1..* M	Verfasser des Dokuments
dataEnterer	0..1 O	0..1 O	Personen der Dateneingabe
informant	0..* O	0..* O	Informant
custodian	1..1 M	1..1 M	Verwahrer des Dokuments
informationRecipient	0..* O	0..* O	Beabsichtigte Empfänger des Dokuments
legalAuthenticator	0..* C	0..* C	Rechtlicher Unterzeichner, wird im speziellen Leitfaden definiert.
authenticator	0..* O	0..* O	Weitere Unterzeichner
participant	0..* O	0..* O	Weitere Beteiligte (nähere Unterscheidung im entsprechenden Leitfaden)
inFulfillmentOf	0..* O	0..* O	Zuweisung und Ordermanagement
documentationOf   serviceEvent	0..* O   1..1 M	0..* O   1..1 M	Gesundheitsdienstleistungen
relatedDocument	0..1 O	0..1 O	Bezug zu vorgehenden Dokumenten
authorization	0..0 NP	0..* O	Einverständniserklärung
componentOf   encompassingEncounter	0..1 O   1..1 M	0..1 O   1..1 M	Patientenkontakt (Aufenthalt)

:Übersichtstabelle der CDA Strukturen des Headers

13.2 Übersichtstabelle der Header-Elemente für dokumenten-relevante Zeitpunkte/Zeitspannen

Dieses Kapitel gibt einen Überblick über die Elemente des CDA Headers mit Zeitangaben und ihre Zusammenhänge.

Die jeweiligen Links in der letzten Spalte zeigen auf die einzelnen Header Elemente im allgemeinen Leitfaden.

Der aktuelle Leitfaden ist für den ELGA Kontext entwickelt worden, kann jedoch auch für andere Zwecke, welche als eHealth zusammengefasst werden, verwendet werden.

Element	Kard/Konf ELGA	Kard/Konf eHealth	Bedeutung	Link zum Kapitel
hl7at:terminologyDate	1..1 M	0..1 O	Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird hier angegeben.	Terminologie-Datum des Dokuments
effectiveTime	1..1 M	1..1 M	Das letzte medizinisch relevante Datum, an welchem das Dokument medizinische Inhalte hinzugefügt worden sind. Kann im speziellen Leitfaden anders definiert werden.	Erstellungsdatum des Dokuments
recordTarget   birthTime	1..1 M   1..1 R	0..1 C   1..1 R	Der Geburtstag des Patienten.	Patient
recordTarget   deceasedTime	1..1 M   0..1 O	0..1 C   1..1 R	Das Sterbedatum des Patienten.	Patient
author   time	1..* M   0..1 R	1..* M   0..1 R	Das jeweilige Datum, an welche der jeweilige Autor neue medizinische Informationen hinzugefügt hat.	Verfasser des Dokuments
dataEnterer   time	0..1 O   0..1 R	0..1 O   0..1 R	Das Datum, an welchem eine Schreibkraft die Informationen aus einem Medium in das CDA Dokument überträgt, ohne weitere fachliche Informationen hinzuzufügen.	Personen der Dateneingabe
legalAuthenticator   time	0..* C   1..1 R	0..* C   1..1 R	Die Zeitpunkte, an welchem das Dokument von den einzelnen berechtigten Personen vidiert wurde. Diese Personen sind die Hauptunterzeichner. Ist im jeweiligen speziellen Implementierungsleitfaden genauer vorgeschrieben. Dieser Zeitpunkt, wenn vorhanden, sollte nach author.time und dataenterer.time liegen.	Rechtlicher Unterzeichner
authenticator   time	0..* O   1..1 R	0..* O   1..1 R	Die Zeitpunkte, an welchem das Dokument von den einzelnen berechtigten Personen vidiert wurde. Diese Personen sind die weiteren Unterzeichner.	Weitere Unterzeichner
Notfallkontakt / Auskunftsberechtigte Person participant [templateId[@root='1.2.40.0.34.6.0.11.1.27']]   time	0..* O   0..1 O	0..* O   0..1 O	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.	Weitere Beteiligte
Versicherter/Versicherungparticipant participant [templateId[@root='1.2.40.0.34.6.0.11.1.26']]   time	0..* O   0..1 O	0..* O   0..1 O	Gültigkeitszeitraum der Versicherungspolizze.	Weitere Beteiligte
documentationOf   serviceEvent     effectiveTime	0..* O   1..1 M     1..1 M	0..* O   1..1 M     1..1 M	Zeitraum der durchgeführten Gesundheitsdienstleistung. Ist im jeweiligen speziellen Implementierungsleitfaden genauer vorgeschrieben.	Gesundheitsdienstleistungen
componentOf   encompassingEncounter     effectiveTime	0..1 O   1..1 M     1..1 M	0..1 O   1..1 M     1..1 M	Zeitraum des Patientenkontakts.	Patientenkontakt (Aufenthalt)

:Übersichtstabelle der Header-Elemente für Zeitpunkte/Zeitspannen

13.3 Übersichtstabelle der CDA Strukturen des Bodys

Die folgende Tabelle gibt die im ELGA Labor- und Mikrobiologiebefund verwendeten Sektionen und Entries wieder. Angaben über die Verwendung einzelner Elemente können - sofern nicht in dieser Tabelle aufgeführt - in den jeweiligen Sektions- oder Entry-Spezifikationen gefunden werden (aus Gründen der Übersichtlichkeit wurde auf die Darstellung aller Ebenen verzichtet).

Sektion bzw. Entry				OID	Kard/Konf	Kapitel
Brieftext				1.2.40.0.34.6.0.11.2.69	0..1 O	Link
Überweisungsgrund - optional kodiert				1.2.40.0.34.6.0.11.2.6	0..1 O	Link
Angeforderte Untersuchung - optional kodiert				1.2.40.0.34.6.0.11.2.15	0..1 O	Link
Probeninformation (Specimen Section)				1.2.40.0.34.6.0.11.2.93	0..1 C	Link
	Probeninformation (Specimen Entry)			1.2.40.0.34.6.0.11.3.160	1..1 M	Link
		Specimen Collection		1.2.40.0.34.6.0.11.3.161	1..* M TODO: wenn Mikrobiologiebefund, dann nur ein Spezimen	Link
			Specimen Received	1.2.40.0.34.6.0.11.3.161	0..1 O	Link
Laboratory Specialty Section				1.2.40.0.34.6.0.11.2.102	1..* M TODO: vielleicht nur 1..* R?	Link
	Laboratory Report Data Processing Entry			1.2.40.0.34.6.0.11.3.25	1..1 M	Link
		Von den folgenden Elementen MUSS zumindest eines vorkommen:
		Specimen Collection		1.2.40.0.34.6.0.11.3.161	0..* C TODO: wenn Mikrobiologiebefund, dann nur ein Spezimen	Link
			Specimen Received	1.2.40.0.34.6.0.11.3.161	0..1 O	Link
		Notification Organizer		1.2.40.0.34.6.0.11.3.165	0..* O	Link
			Von den folgenden Elementen MUSS zumindest eines vorkommen:
			Notifiable Condition	1.2.40.0.34.6.0.11.3.166	0..* O	Link
			TODO? Case Identification		0..* O
			TODO? Outbreak Identification		0..* O
		Laboratory Isolate Organizer		1.2.40.0.34.6.0.11.3.166	0..* O	Link
			Von den folgenden Elementen MUSS zumindest eines vorkommen:
			Laboratory Battery Organizer	1.2.40.0.34.6.0.11.3.26	0..* O	Link
			Laboratory Observation	1.2.40.0.34.6.0.11.3.27	0..* O	Link
			TODO? Eingebettetes Objekt Entry
			Comment Entry	1.2.40.0.34.6.0.11.3.11	0..* O	Link
		Laboratory Battery Organizer		1.2.40.0.34.6.0.11.3.26	0..* O	Link
			TODO? Specimen Collection
			Laboratory Observation	1.2.40.0.34.6.0.11.3.27	0..* O	Link
			Eingebettetes Objekt Entry	1.2.40.0.34.6.0.11.3.19	0..* O	Link
			Comment Entry	1.2.40.0.34.6.0.11.3.11	0..* O	Link
		Laboratory Observation		1.2.40.0.34.6.0.11.3.27	0..* O	Link
			Comment Entry	1.2.40.0.34.6.0.11.3.11	0..* O	Link
		Eingebettetes Objekt Entry		1.2.40.0.34.6.0.11.3.19	0..* O	Link
		Comment Entry		1.2.40.0.34.6.0.11.3.11	0..* O	Link
	Befundbewertung			1.2.40.0.34.6.0.11.2.103	0..* O	Link
		Comment Entry		1.2.40.0.34.6.0.11.3.11	1..1 R	Link
	Beilagen			1.2.40.0.34.6.0.11.2.71	0..* O	Link
	Abschließende Bemerkung			1.2.40.0.34.6.0.11.2.70	0..* O	Link

:Übersichtstabelle der CDA Strukturen des Bodys

13.4 CDA Templates

13.4.1 Document Level Templates

Derzeit gibt es für die Abbildung eines Labor- und Mikrobiologiebefundes in CDA von Seiten der ELGA nur eine Ausprägung. Daher ist auch nur ein Document Level Template definiert.

Id	1.2.40.0.34.6.0.11.0.11	Gültigkeit	2020‑08‑25 14:35:13
Status	Aktiv	Versions-Label	3.0.0+20211214
Name	atlab_document_Laborbefund	Bezeichnung	Laborbefund
Beschreibung Der Laborbefund erlaubt es, beliebige Befundbereiche, Befundgruppen und deren Ergebnisse im Rahmen eines Dokumentes zu übermitteln. Dabei kann es vorkommen, dass der Befund auch nur einen bestimmten Befundbereich (z.B. Hämatologie) oder verschiedene Befundbereiche enthält. Diesem Umstand wird durch die Angabe der enthaltenen Befundbereiche bei der Registrierung des Laborbefundes in den XDS-Metadaten Rechnung getragen. Durch die Registrierung der in dem Laborbefund enthaltenen Befundbereiche über die serviceEvents in den XDS-Metadaten ("eventCodeList") sind auch Detailbefunde in der ELGA einfach auffindbar.
Kontext	Pfadname /
Klassifikation	CDA Document Level Template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt	Benutzt 42 Templates Benutzt als Name Version 1.2.40.0.34.6.0.11.1.10 Inklusion Document Realm (1.0.1+20230717) DYNAMIC 1.2.40.0.34.6.0.11.1.30 Inklusion Document TypeId (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.1 Inklusion Document Id (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.45 Inklusion Document StatusCode (1.0.1+20210624) DYNAMIC 1.2.40.0.34.6.0.11.1.46 Inklusion Document TerminologyDate (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.44 Inklusion Document PracticeSettingCode (1.1.0+20210303) DYNAMIC 1.2.40.0.34.6.0.11.1.11 Inklusion Document Effective Time (1.0.1+20230717) DYNAMIC 1.2.40.0.34.6.0.11.1.12 Inklusion Document Confidentiality Code (1.0.2+20230717) DYNAMIC 1.2.40.0.34.6.0.11.1.13 Inklusion Document Language (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.15 Inklusion Document Set Id and Version Number (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.3 Inklusion Record Target (1.2.1) DYNAMIC 1.2.40.0.34.6.0.11.1.2 Inklusion Author (1.0.3+20230717) DYNAMIC 1.2.40.0.34.6.0.11.1.22 Inklusion Data Enterer (1.0.1+20230717) DYNAMIC 1.2.40.0.34.6.0.11.1.4 Inklusion Custodian (1.0.1+20211213) DYNAMIC 1.2.40.0.34.6.0.11.1.24 Inklusion Information Recipient (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.5 Inklusion Legal Authenticator (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.49 Inklusion Laboratory Results Validator (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.1.42 Inklusion Participant Auftraggeber / Ordering Provider (1.1.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.1.20 Inklusion Participant Fachlicher Ansprechpartner (1.0.2+20210803) DYNAMIC 1.2.40.0.34.6.0.11.1.23 Inklusion Participant Hausarzt (1.0.1+20210803) DYNAMIC 1.2.40.0.34.6.0.11.1.27 Inklusion Participant Auskunftsberechtigte Person (Notfallkontakt) (1.0.2+20210803) DYNAMIC 1.2.40.0.34.6.0.11.1.25 Inklusion Participant Angehoerige (1.0.1+20210803) DYNAMIC 1.2.40.0.34.6.0.11.1.26 Inklusion Participant Versicherung (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.29 Inklusion Participant Betreuungsorganisation (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.28 Inklusion Participant Weitere Behandler (1.0.0+20210219) DYNAMIC 1.2.40.0.34.6.0.11.1.9 Inklusion In Fulfillment Of (1.0.1+20210628) DYNAMIC 1.2.40.0.34.6.0.11.1.48 Inklusion Documentation Of Service Event - Labor und Mikrobiologie (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.1.14 Inklusion Document Replacement - Related Document (1.0.1+20210628) DYNAMIC 1.2.40.0.34.6.0.11.1.50 Inklusion Component Of - Encompassing Encounter with id (1.0.1+20230717) DYNAMIC 1.2.40.0.34.6.0.11.2.69 Containment Brieftext (1.0.1+20210628) DYNAMIC 1.2.40.0.34.6.0.11.2.6 Containment Überweisungsgrund - codiert (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.114 Containment Überweisungsgrund - uncodiert (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.109 Containment Anamnese - Labor und Mikrobiologie - codiert (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.111 Containment Anamnese - Labor und Mikrobiologie - uncodiert (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.15 Containment Angeforderte Untersuchungen - codiert (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.112 Containment Angeforderte Untersuchungen - uncodiert (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.93 Containment Probeninformation (Specimen Section) (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.102 Containment Laboratory Specialty Section (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.103 Containment Befundbewertung (1.0.0+20211213) DYNAMIC 1.2.40.0.34.6.0.11.2.71 Containment Beilagen (1.0.2+20230717) DYNAMIC 1.2.40.0.34.6.0.11.2.70 Containment Abschließende Bemerkung (1.0.1+20210628) DYNAMIC 1.2.40.0.34.6.0.11.9.33 Inklusion Stylesheet Test eBefund (1.0.1+20210628) DYNAMIC
Item DT Kard Konf Beschreibung Label hl7:ClinicalDocument (atl...und) @classCode cs 0 … 1 F DOCCLIN @moodCode cs 0 … 1 F EVN   Constraint Entsprechend den Vorgaben des IHE Frameworks für Labor sind für Personen und Organisationen die Angabe eines Namens ("name"-Element), einer Adresse ("addr"-Element) und einer Telekom-Verbindung ("telecom"-Element) verpflichtend. Diese können jedoch mit einem nullFlavor versehen werden. Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.10 Document Realm (DYNAMIC) hl7:realmCode CS 1 … 1 M Hoheitsbereich des Dokuments. Fester Wert: @code = AT (aus Value Set „ELGA_RealmCode“) (atl...und) @code 1 … 1 F AT Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.30 Document TypeId (DYNAMIC) hl7:typeId II 1 … 1 M Dokumentformat CDA R2 (atl...und) @root uid 1 … 1 F 2.16.840.1.113883.1.3 @extension st 1 … 1 F POCD_HD000040 hl7:templateId II 1 … 1 M Fixe OID für alle Dokumente, die in der Governance-Gruppe "eHealth Austria" abgestimmt werden und von einem zentralen Art-Decor-Repository abgeleitet werden (AT-CDA-BBR). (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.0.1 hl7:templateId II 1 … 1 M OID des Implementierungsleitfadens "Labor- und Mikrobiologiebefund" (Dokument-OID). Dient als informative Referenz. (atl...und) @root uid 1 … 1 F 1.2.40.0.34.7.4.9.3 hl7:templateId II 1 … 1 M OID des Art-Decor-Templates für das Dokument "Laborbefund" (Document Level Template für Schematron) (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.0.11 hl7:templateId II NP IHE PalM TF3 Rev.10, 6.3.2.3 templateId Im Grunde folgt dieser Leitfaden den Vorgaben der IHE. Die Codierung der "Laboratory Specialty Section" erfolgt allerdings nicht nach den von IHE vorgegebenen LOINC-Codes. Deshalb darf diese templateID nicht angegeben werden. (atl...und) wo [@root='1.3.6.1.4.1.19376.1.3.3'] @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3 Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.1 Document Id (DYNAMIC) hl7:id II 1 … 1 M Dokumenten-Id des CDA-Dokuments. Es MUSS eine gültige und innerhalb des ID-Pools eindeutige Dokumenten-ID angegeben werden. Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen. (atl...und) @root uid 1 … 1 R hl7:code CE 1 … 1 M Für den Laborbefund ist sowohl als Dokumententyp (/ClinicalDocument/code) als auch als Dokumentenklasse (/ClinicalDocument/code/translation) "11502-2 - Laboratory report" anzugeben. ↔ Hinweis zum XDS-Mapping: Das code-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.typeCode übernommen. Das translation-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.classCode übernommen. (atl...und) @codeSystemName st 0 … 1 F LOINC @code CONF 1 … 1 F 11502-2 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) @displayName 1 … 1 F Laboratory report hl7:translation CD 1 … 1 M Fixe Dokumentenklasse "11502-2 - Laboratory report" (atl...und) @codeSystemName st 0 … 1 F LOINC @code CONF 1 … 1 F 11502-2 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) @displayName 1 … 1 F Laboratory report hl7:title ST 1 … 1 M Der Titel des CDA Dokuments für den lesenden Empfänger. MUSS die Art des Dokuments (Dokumenttyp) widerspiegeln. Zum Beispiel "Laborbefund". (atl...und) Eingefügt 0 … 1 C von 1.2.40.0.34.6.0.11.1.45 Document StatusCode (DYNAMIC)   Constraint Labor- und Mikrobiologiebefunde sind grundsätzlich abgeschlossene bzw. "fertige" Dokumente - in diesen Fällen erübrigt sich die Angabe eines Status. Befunde, in denen die Ergebnisse bestimmter Analysen noch ausständig sind ("Wert folgt"), MÜSSEN den Dokumentenstatus "active" erhalten und das Ergebnis der ausständigen Analyse MUSS den SNOMED CT Code "255599008 - Incomplete (qualifier value)" erhalten. sdtc:statusCode CS 0 … 1 C Status eines Dokuments. e-Befunde sind grundsätzlich abgeschlossene bzw. "fertige" ("completed") Dokumente, daher entfällt die Angabe eines Status. In folgenden Ausnahmen SOLL der Status eines Dokuments wie folgt angegeben werden: “active”: z.B. wenn bekannt ist, dass Updates folgen werden: Etwa für "vorläufige ärztliche Entlassungsbriefe" oder Laborbefunde, für die noch Ergebnisse einzelner Analysen ausständig sind “nullified”: z.B. für Dokumente, die gemäß Anwendungsfall "Storno von ELGA-Dokumenten" storniert werden, wobei zusätzlich ein letztes Dokument mit Storniert-Status in der Versionskette registriert wird. ↔ Hinweis zum XDS-Mapping: Der Status wird nicht in die XDS-Metadaten übernommen! (atl...und)   Constraint Zulässige Werte für sdtc:statusCode/@code sind "active" und "nullified"   CONF @code muss "nullified" sein oder @code muss "active" sein Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.46 Document TerminologyDate (DYNAMIC) hl7at:terminologyDate TS.DATE.FULL 1 … 1 M Das Terminologie-Datum des Dokumentes Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird hier angegeben. (atl...und)   Constraint Das Datum der letzten Terminologie-Aktualisierung MUSS entsprechend klassischer HL7 V3 Notation im Format "YYYYMMDD" angegeben werden. Beispiel: 20200527 hl7at:formatCode CD 1 … 1 M ↔ Hinweis zum XDS-Mapping:  @code wird in das XDS-Attribut XDSDocumentEntry.formatCode übernommen. (atl...und) @codeSystemName st 0 … 1 F ELGA_FormatCode @code CONF 1 … 1 F urn:hl7-at:lab:3.0.0+20211214 @codeSystem 1 … 1 F 1.2.40.0.34.5.37 @displayName 1 … 1 F HL7 Austria Labor- und Mikrobiologiebefund 3.0.0+20211214 Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.44 Document PracticeSettingCode (DYNAMIC) hl7at:practiceSettingCode CD 1 … 1 M Die fachliche Zuordnung des Dokumentes (atl...und) @displayName 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.75 ELGA_PracticeSetting (DYNAMIC) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.11 Document Effective Time (DYNAMIC) Angabe des medizinisch zutreffendsten Datums - in der Regel das Abnahmedatum/-zeit des Untersuchungsmaterials. Sollte dieses nicht vorliegen, kann auf andere möglichst passende Zeitpunkte zurückgegriffen werden: Auftragszeitpunkt, Laboreingangszeitpunkt, Vidierungszeitpunkt, etc. hl7:effectiveTime TS.AT.TZ 1 … 1 M Relevantes Datum des Dokuments. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (atl...und)   at-cda-bbr-data​element-11  Erstellungsdatum  Dataset A Allgemeiner Leitfaden Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.12 Document Confidentiality Code (DYNAMIC) hl7:confidentialityCode CE 1 … 1 M Vertraulichkeitscode des Dokuments aus Value Set „ELGA_Confidentiality“.  (atl...und)   at-cda-bbr-data​element-13  Vertraulichkeitscode  Dataset A Allgemeiner Leitfaden @codeSystemName st 1 … 1 F HL7:Confidentiality   Constraint Für ELGA-Dokumente ist ausschließlich "N" erlaubt! Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.13 Document Language (DYNAMIC) hl7:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments. (atl...und)   at-cda-bbr-data​element-14  Sprachcode  Dataset A Allgemeiner Leitfaden @code cs 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.10 ELGA_LanguageCode (DYNAMIC)   Constraint Fü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ügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.15 Document Set Id and Version Number (DYNAMIC) hl7:setId II 1 … 1 M 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. (atl...und) hl7:versionNumber INT.​NONNEG 1 … 1 M Versionsnummer 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. (atl...und) @value int 1 … 1 R Versionsnummer als positive ganze Zahl. Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.3 Record Target (DYNAMIC) hl7:recordTarget 1 … 1 M Komponente für die Patientendaten. (atl...und)   at-cda-bbr-data​element-64  Patient  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F RCT @context​Control​Code cs 0 … 1 F OP hl7:patientRole 1 … 1 M Patientendaten. (atl...und) @classCode cs 0 … 1 F PAT hl7:id II 2 … * R Patientenidentifikatoren (atl...und)   at-cda-bbr-data​element-193  EKVK  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-65  LokaleID  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-66  SVNr  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-67  bPK-GH  Dataset A Allgemeiner Leitfaden   Constraint Hinweis: 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 technisch der Zuordnung der elektronischen Identität und darf daher weder angezeigt werden noch am Ausdruck erscheinen noch in allfälligen Downloads enthalten sein (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 <id root="1.2.40.0.34.4.21" extension="123456789^1100-OEGK^800400010016^20251231"/>   Beispiel EKVK Beispiel-Min <id root="1.2.40.0.34.4.21" extension="123456789"/> hl7:addr 0 … 2 R 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) (atl...und)   at-cda-bbr-data​element-68  Adresse  Dataset A Allgemeiner Leitfaden   Constraint Werden mehrere gleichartige address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein. hl7:telecom TEL.AT 0 … * R Kontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (atl...und)   at-cda-bbr-data​element-72  Kontaktdaten  Dataset A Allgemeiner Leitfaden @value url 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom-Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“ @use cs 0 … 1   Bedeutung des angegebenen Kontakts (z.B Heim, Arbeitsplatz), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:patient 1 … 1 M Name des Patienten. Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden! Grundsätzlich sind die Vorgaben gemäß „Namen-Elemente von Personen PN“ zu befolgen. (atl...und)   at-cda-bbr-data​element-70  Name  Dataset A Allgemeiner Leitfaden Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Namen-Element (Person) (atl...und) @use cs 0 … 1   Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“. Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“. Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“). hl7:prefix ENXP 0 … * Beliebig viele Präfixe zum Namen, z.B. Akademische Titel Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen! (atl...und) @qualifier cs 0 … 1   Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“. Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".   CONF Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC) hl7:family ENXP 1 … * M Mindestens ein Hauptname (Nachname). (atl...und) @qualifier cs 0 … 1   Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“. Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.   CONF Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC) hl7:given ENXP 1 … * M Mindestens ein Vorname (atl...und) @qualifier cs 0 … 1   Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“). Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“   CONF Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC) hl7:suffix ENXP 0 … * Beliebig viele Suffixe zum Namen (atl...und) @qualifier cs 0 … 1   Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“). Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.   CONF Der Wert von @qualifier muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC) Auswahl 1 … 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'] hl7:administrative​Gender​Code CE 0 … 1 (atl...und) wo [not(@nullFlavor)]   at-cda-bbr-data​element-74  Geschlecht  Dataset A Allgemeiner Leitfaden @displayName st 1 … 1 R @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.1 @codeSystemName st 0 … 1 F HL7:AdministrativeGender   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC) hl7:translation CD 0 … * 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 (atl...und) @displayName st 1 … 1 R   Beispiel Beispiel für eine SNOMED CT Angabe <translation code="772004004" codeSystem="2.16.840.1.113883.6.96" displayName="Non-binary gender"/> hl7:administrative​Gender​Code CE 0 … 1 Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein. (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … 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'] hl7:birthTime TS.AT.VAR 0 … 1 (atl...und)   at-cda-bbr-data​element-75  Geburtsdatum  Dataset A Allgemeiner Leitfaden hl7:birthTime TS.AT.VAR 0 … 1 (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK sdtc:deceasedInd BL 0 … 1 R Kennzeichen, dass die Person verstorben ist. Kann alternativ zum Todesdatum angegeben werden, v.a. wenn der Todeszeitpunkt nicht bekannt ist. (atl...und)   at-cda-bbr-data​element-192  Verstorben-Kennzeichen  Dataset A Allgemeiner Leitfaden sdtc:deceasedTime TS.AT.TZ 0 … 1 R Todesdatum der Person. (atl...und)   at-cda-bbr-data​element-191  Todesdatum  Dataset A Allgemeiner Leitfaden hl7:marital​Status​Code CE 0 … 1 R Codierung des Familienstands des Patienten. Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“ (atl...und)   at-cda-bbr-data​element-98  Familienstand  Dataset A Allgemeiner Leitfaden @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.2 @codeSystemName st 1 … 1 F HL7:MaritalStatus @displayName st 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC) hl7:religious​Affiliation​Code CE 0 … 1 R Codierung des Religionsbekenntnisses des Patienten. Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“ (atl...und)   at-cda-bbr-data​element-99  Religionsbekenntnis  Dataset A Allgemeiner Leitfaden @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.2.16.1.4.1 @codeSystemName st 1 … 1 F HL7.AT:ReligionAustria @displayName st 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC) hl7:raceCode NP Rasse des Patienten. Darf nicht verwendet werden! (atl...und) hl7:ethnic​Group​Code NP Ethnische Zugehörigkeit des Patienten. Darf nicht verwendet werden! (atl...und) hl7:guardian 0 … * R Gesetzlicher Vertreter: Vorsorgebevollmächtigte/r (Bevollmächtigte/r durch Vorsorgevollmacht) Gewählte/r ErwachsenenvertreterIn Gesetzliche/r ErwachsenenvertreterIn 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. (atl...und)   at-cda-bbr-data​element-88  Gesetzlicher Vertreter  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F GUARD hl7:addr 0 … 1 R 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) (atl...und) hl7:telecom TEL.AT 0 … * R Beliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (atl...und) @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom-Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (z.B. Heim, Arbeitsplatz) Bsp: WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 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) hl7:guardian​Person 0 … 1 Name 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) (atl...und) hl7:guardian​Person 0 … 1 Name 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) (atl...und) hl7:guardian​Organization 0 … 1 R Name des gesetzlichen Vertreters (Organisation) Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) (atl...und) hl7:birthplace 0 … 1 R Geburtsort des Patienten. (atl...und)   at-cda-bbr-data​element-76  Geburtsort  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F BIRTHPL hl7:place 1 … 1 M (atl...und) @classCode cs 0 … 1 F PLC @determiner​Code cs 0 … 1 F INSTANCE Auswahl 1 … 1 Elemente 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) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional. Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) (atl...und) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts, struktuiert. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) hl7:language​Communication 0 … * R Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten. (atl...und)   at-cda-bbr-data​element-100  Sprachfähigkeit  Dataset A Allgemeiner Leitfaden hl7:language​Code CS 1 … 1 M Sprache, 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). (atl...und)   at-cda-bbr-data​element-101  Sprache  Dataset A Allgemeiner Leitfaden @code cs 1 … 1 R Zulä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) hl7:modeCode CE 0 … 1 C Ausdrucksform der Sprache. Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“ (atl...und) @code cs 1 … 1 R @displayName st 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.60 @codeSystemName st 0 … 1 F HL7:LanguageAbilityMode   Constraint Bei 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) hl7:proficiency​Level​Code CE 0 … 1 R Grad der Sprachkenntnis in der Sprache. Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“ (atl...und)   at-cda-bbr-data​element-102  Grad der Sprachkenntnis  Dataset A Allgemeiner Leitfaden @code cs 1 … 1 R @displayName st 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.61 @codeSystemName st 0 … 1 F HL7:LanguageAbilityProficiency   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC) hl7:preference​Ind BL 0 … 1 R Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird. (atl...und)   at-cda-bbr-data​element-103  Sprachpräferenz  Dataset A Allgemeiner Leitfaden   Schematron assert role  error     test not(hl7:id[1]/@nullFlavor)     Meldung Die Verwendung von id/@nullFlavor ist an dieser Stelle NICHT ERLAUBT.     Schematron assert role  error     test not(hl7:id[2]/@nullFlavor) or (hl7:id[2][@nullFlavor='UNK'] or hl7:id[2][@nullFlavor='NI'])     Meldung Zugelassene nullFlavor sind "NI" und "UNK"   Eingefügt 1 … * M von 1.2.40.0.34.6.0.11.1.2 Author (DYNAMIC) hl7:author 1 … * M Verfasser des Dokuments. (atl...und) @typeCode cs 0 … 1 F AUT @context​Control​Code cs 0 … 1 F OP hl7:functionCode CE (extensible) 0 … 1 R Funktionscode des Verfassers des Dokuments, z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“. Eigene Codes und Bezeichnungen können verwendet werden. (atl...und) @code cs 1 … 1 R @codeSystem oid 1 … 1 R @displayName st 1 … 1 R Auswahl 1 … 1 Der Zeitpunkt, zu dem das Dokument verfasst bzw. inhaltlich fertiggestellt wurde. Elemente in der Auswahl: hl7:time[not(@nullFlavor)] hl7:time[@nullFlavor='UNK'] hl7:time TS.AT.TZ 0 … 1 (atl...und) wo [not(@nullFlavor)] hl7:time TS.AT.TZ 0 … 1 (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:assignedAuthor 1 … 1 M (atl...und) @classCode cs 0 … 1 F ASSIGNED Auswahl 1 … * 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']   Constraint Zugelassene nullFlavor: NI  ….... Person hat keine ID / Gerät/Software hat keine ID  UNK  … Person hat eine ID, diese ist jedoch unbekannt / Gerät/Software hat eine ID, diese ist jedoch unbekannt hl7:id II 0 … * Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software. ODER Identifikation des/der datenerstellenden Gerätes/Software.  (atl...und) wo [not(@nullFlavor)] hl7:id II 0 … 1 (atl...und) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:code CE 0 … 1 R 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. (atl...und) @codeSystem oid 1 … 1 R @displayName st 1 … 1 R @code cs 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC) hl7:telecom TEL.AT 0 … * Kontaktdaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 1 Elemente 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) hl7: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) (atl...und) hl7:assigned​Authoring​Device 0 … 1 Datenerstellende/s Software/Gerät Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) (atl...und) hl7:represented​Organization 1 … 1 M Organisation, 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) (atl...und)   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“ Ausnahme: Wenn als Author ein/e Software/Gerät fungiert und keine OID aus dem GDA-I angegeben werden kann, MÜSSEN die Angaben der Organisation des Geräte-/Software-Betreibers oder Herstellers entsprechen.   Schematron assert role  error     test count(hl7:author/hl7:assignedAuthor/hl7:assigned​Person)>0     Meldung Es MUSS immer zumindest eine Person als Autor angeführt sein.   Eingefügt 0 … 1 von 1.2.40.0.34.6.0.11.1.22 Data Enterer (DYNAMIC) hl7:dataEnterer 0 … 1 z.B. Schreibkraft, Medizinische Dokumentationsassistenz (atl...und)   at-cda-bbr-data​element-16  Schreibkraft  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F ENT @context​Control​Code cs 0 … 1 F OP hl7:time TS.AT.TZ 0 … 1 R Der Zeitpunkt zu dem die Daten dokumentiert wurden. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (atl...und) wo [not(@nullFlavor)]   at-cda-bbr-data​element-17  Zeitpunkt des Schreibens  Dataset A Allgemeiner Leitfaden hl7:assignedEntity 1 … 1 M Beinhaltet 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC) (atl...und) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.4 Custodian (DYNAMIC) hl7:custodian 1 … 1 M Verwahrer des Dokuments. (atl...und)   at-cda-bbr-data​element-24  Verwahrer  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M (atl...und) @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M (atl...und) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 1 … * M Identifikation des Verwahrers des Dokuments. Wenn dieser im GDA-I angeführt ist, ist die entsprechende OID zu verwenden. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. (atl...und) hl7:name ON 1 … 1 M Name des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen. (atl...und) hl7:telecom TEL.AT 0 … * Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 1 … 1 M Adresse 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) (atl...und) Eingefügt 0 … * von 1.2.40.0.34.6.0.11.1.24 Information Recipient (DYNAMIC) hl7:information​Recipient 0 … * Beabsichtiger Empfänger des Dokuments.  (atl...und)   at-cda-bbr-data​element-26  Empfänger  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1   Typ des Informationsempfängers, z.B: PRCP „Primärer Empfänger“. Werden mehrere Empfänger angegeben, MUSS der primäre Empfänger über den typeCode definiert werden. Hinweis: Das ist relevant, wenn Funktionen aus dem gerichteten Befundversand oder für den Briefdruck auf das Dokument angewendet werden.   CONF Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.29 ELGA_InformationRecipientType (DYNAMIC)   at-cda-bbr-data​element-27  Empfänger Typ  Dataset A Allgemeiner Leitfaden hl7:intended​Recipient 1 … 1 M (atl...und) @classCode cs 0 … 1   Auswahl 1 … * Elemente in der Auswahl: hl7:id[not(@nullFlavor)] hl7:id[@nullFlavor='NI'] hl7:id[@nullFlavor='UNK'] hl7:id II 0 … * 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. (atl...und) wo [not(@nullFlavor)]   at-cda-bbr-data​element-28  ID des Empfängers  Dataset A Allgemeiner Leitfaden hl7:id II 0 … 1 NI … Person hat keine ID (atl...und) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 UNK ... Person hat eine ID, diese ist jedoch unbekannt (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … 1 Personendaten des beabsichtigten Empfängers. Empfehlung: Der Name des Empfängers und die Organisation, der er angehört, sollen in möglichst hoher Granularität angegeben werden. Aufgrund der gängigen Praxis kann als minimale Information für den Empfänger der unstrukturierte Name angegeben werden. Grundsätzlich sind die Vorgaben gemäß Kapitel „Personen-Element“ zu befolgen. Elemente in der Auswahl: hl7:information​Recipient[hl7: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) hl7:information​Recipient  … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)=0]]   at-cda-bbr-data​element-29  Name  Dataset A Allgemeiner Leitfaden hl7:information​Recipient  … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)!=0]] hl7:received​Organization 0 … 1 R Organisation, der der beabsichtigte Empfänger angehört, z.B.: „Ordination des empfangenden Arztes“. Grundsätzlich sind die Vorgaben gemäß Kapitel „Organisations-Element“ zu befolgen. (atl...und)   at-cda-bbr-data​element-30  Organisation  Dataset A Allgemeiner Leitfaden Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … * Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (atl...und) wo [not(@nullFlavor)] hl7:name ON 1 … 1 M Name 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. (atl...und) hl7:telecom TEL.AT 0 … * Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.5 Legal Authenticator (DYNAMIC) "Medizinischer Validator" oder der laborverantwortliche Arzt hl7:legalAuthenticator 1 … 1 M Hauptunterzeichner, Rechtlicher Unterzeichner (atl...und)   at-cda-bbr-data​element-1  Rechtlicher Unterzeichner  Dataset A Allgemeiner Leitfaden @context​Control​Code cs 0 … 1 F OP @typeCode cs 0 … 1 F LA Auswahl 1 … 1 Der Zeitpunkt, an dem das Dokument unterzeichnet wurde. Elemente in der Auswahl: hl7:time[not(@nullFlavor)] hl7:time[@nullFlavor='UNK'] hl7:time TS.AT.TZ 0 … 1 (atl...und) wo [not(@nullFlavor)]   at-cda-bbr-data​element-5  Zeitpunkt der Unterzeichnung  Dataset A Allgemeiner Leitfaden hl7:time TS.AT.TZ 0 … 1 (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:signatureCode CS 1 … 1 M Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde. (atl...und)   at-cda-bbr-data​element-6  Signatur  Dataset A Allgemeiner Leitfaden @code CONF 1 … 1 F S hl7:assignedEntity 1 … 1 M Personendaten des rechtlichen Unterzeichners. Für den Namen ist verpflichtend Granularitätsstufe 2 ("strukturierte Angabe des Namens") anzuwenden! Beinhaltet 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC) (atl...und) Eingefügt 0 … * von 1.2.40.0.34.6.0.11.1.49 Laboratory Results Validator (DYNAMIC) Validator (Authenticator) hl7:authenticator 0 … * (Weitere) validierende Person (=Mitunterzeichner), die das Dokument inhaltlich (medizinisch und technisch) freigibt. Es können mehrere Validatoren angegeben werden. Einer davon kann auch ident mit dem "rechtlichen Unterzeichner" (/ClinicalDocument/legalAuthenticator) sein. (atl...und) @typeCode cs 0 … 1 F AUTHEN hl7:templateId II 1 … 1 M Laboratory Results Validator (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.49 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.10, 6.3.2.16 Laboratory Results Validator (atl...und) @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.5 Auswahl 1 … 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'] hl7:time TS.AT.TZ 0 … 1 (atl...und) wo [not(@nullFlavor)] hl7:time TS.AT.TZ 0 … 1 (atl...und) wo [@nullFlavor='UNK'] hl7:signatureCode CS 1 … 1 M (atl...und) @code CONF 1 … 1 F S hl7:assignedEntity 1 … 1 M Personendaten des weiteren Unterzeichners. Beinhaltet 1.2.40.0.34.6.0.11.9.41 Assigned Entity with id, name, addr and telecom (DYNAMIC) (atl...und) Auswahl 1 … 1 Auftraggeber / Ordering Provider Elemente in der Auswahl: hl7:participant eingefügt vom Template 1.2.40.0.34.6.0.11.1.42 Participant Auftraggeber / Ordering Provider (DYNAMIC) hl7:participant[@typeCode='REF'][@nullFlavor] Eingefügt 0 … 1 von 1.2.40.0.34.6.0.11.1.42 Participant Auftraggeber / Ordering Provider (DYNAMIC) hl7:participant 0 … 1 (atl...und) @typeCode cs 1 … 1 F REF @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M Participant Auftraggeber / Ordering Provider (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.42 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.10, 6.3.2.17 Ordering Provider (atl...und) @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.6 Auswahl 1 … 1 Das Auftragsdatum ist das Datum/Zeit, an dem der Auftrag vom Auftraggeber abgesendet wird. Das Auftragsdatum wird als "time"-Element beim Auftraggeber ausgeführt und ist verpflichtend anzugeben. Bei einer manuellen Erfassung eines Auftrags im Labor kann dieses als @nullFlavor="NA" ausgeführt werden. Elemente in der Auswahl: hl7:time[not(@nullFlavor)] hl7:time[@nullFlavor='NA'] hl7:time IVL_TS 0 … 1 R (atl...und) wo [not(@nullFlavor)] hl7:time IVL_TS 0 … 1 R (atl...und) wo [@nullFlavor='NA'] hl7:associated​Entity 1 … 1 M (atl...und) @classCode cs 1 … 1 F PROV   Healthcare provider - Gesundheitsdienstanbieter hl7:id II 1 … 1 M ID des Auftraggebers (atl...und) Auswahl 1 … 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'] hl7:addr AD 0 … 1 R Adresse des Auftraggebers Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] hl7:addr AD 0 … 1 (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … * Elemente in der Auswahl: hl7:telecom[not(@nullFlavor)] hl7:telecom[@nullFlavor='UNK'] hl7:telecom TEL.AT 0 … * R Beliebig viele Kontaktdaten des Auftraggebers (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:telecom TEL.AT 0 … 1 (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK   Schematron assert role  error     test not(hl7:telecom[not(@nullFlavor)]) or not(hl7:telecom[@nullFlavor='UNK'])     Meldung telecom[@nullFlavor="UNK"] darf NUR angegeben werden, wenn KEIN befülltes "telecom"-Element vorhanden ist.   Auswahl 1 … 1 Name des Auftraggebers. 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.11 Person Name Compilation G2 M (DYNAMIC) hl7:associated​Person[@nullFlavor] hl7:associated​Person 0 … 1 R Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)!=0]] hl7:associated​Person 0 … 1 (atl...und) wo [@nullFlavor] @nullFlavor cs 1 … 1 F UNK hl7:scoping​Organization 0 … 1 R Organisation, der der Auftraggeber angehört (mit Adresse und Kontaktdaten der Organisation). Grundsätzlich sind die Vorgaben für "Organisations-Element" zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) (atl...und) hl7:participant 0 … 1 Auftraggeber nicht bekannt (atl...und) wo [@typeCode='REF'] [@nullFlavor] @typeCode cs 1 … 1 F REF @nullFlavor cs 1 … 1 F UNK   Beispiel Auftraggeber nicht bekannt <participant typeCode="REF" nullFlavor="UNK">   <associatedEntity classCode="PROV"/></participant> hl7:associated​Entity 1 … 1 M (atl...und) @classCode cs 1 … 1 F PROV hl7:participant NP Die Verwendung des ELGA participant-Elements, das den einweisenden/zuweisenden/überweisenden Arzt repräsentiert mit templateId 1.2.40.0.34.6.0.11.1.21 ist im Laborbefund NICHT ERLAUBT. (atl...und) wo [@typeCode='REF'] [hl7:templateId/@root='1.2.40.0.34.6.0.11.1.21'] Eingefügt 0 … 1 R von 1.2.40.0.34.6.0.11.1.20 Participant Fachlicher Ansprechpartner (DYNAMIC) Fachlicher Ansprechpartner Es ist EMPFOHLEN, den fachlichen Ansprechpartner (Callback contact) im Labor- und Mikrobiologiebefund anzugeben. hl7:participant 0 … 1 R Fachlicher Ansprechpartner (atl...und) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.20']] @typeCode cs 1 … 1 F CALLBCK   Callback contact @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M Template ID zur Identifikation dieser Art von Beteiligten (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.20 hl7: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. (atl...und) @code cs 1 … 1 R @codeSystem oid 1 … 1 R @displayName st 1 … 1 R hl7:associated​Entity 1 … 1 M (atl...und) @classCode cs 1 … 1 F PROV   Healthcare provider - Gesundheitsdiensteanbieter hl7:code CE 0 … 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. (atl...und) @codeSystem oid 1 … 1 R @displayName st 1 … 1 R @code cs 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC) hl7:addr AD 0 … 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) (atl...und) wo [not(@nullFlavor)] hl7:telecom TEL.AT 1 … * M Beliebig viele Kontaktdaten des Beteiligten. (atl...und) @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Es MUSS mindestens eine Telefonnummer angegeben werden. Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:associated​Person 0 … 1 R Name der Person Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (atl...und) hl7:scoping​Organization 0 … 1 R Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation). Grundsätzlich sind die Vorgaben für "Organisations-Element" zu befolgen. (atl...und) Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … * Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (atl...und) wo [not(@nullFlavor)] hl7:name ON 1 … 1 M Name 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. (atl...und) hl7:telecom TEL.AT 0 … * Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)]   Schematron assert role  error     test not(hl7:participant[@typeCode='CALLBCK'][@nullFlavor])     Meldung @nullFlavor ist für den fachlichen Ansprechpartner (participant[@typeCode='CALLBCK']) NICHT ERLAUBT. Sollten keine Informationen vorliegen, soll das Element entfallen.   Eingefügt 0 … 1 von 1.2.40.0.34.6.0.11.1.23 Participant Hausarzt (DYNAMIC) hl7:participant 0 … 1 Beteiligter (Hausarzt). (atl...und) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.23']] @typeCode cs 1 … 1 F IND   In indirektem Bezug. @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M Template ID zur Identifikation dieser Art von Beteiligten (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.23 hl7:functionCode CE 1 … * M Funktionscode des Beteiligten (atl...und) @code cs 1 … 1 F PCP @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.88 @codeSystemName st 1 … 1 F HL7:ParticipationFunction hl7:associated​Entity 1 … 1 M Beschreibung der Entität. (atl...und) @classCode cs 1 … 1 F PROV   Healthcare provider - Gesundheitsdiensteanbieter. Auswahl 0 … * 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 hl7:id II 0 … * (atl...und) wo [not(@nullFlavor)] hl7:id II 0 … 1 (atl...und) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:addr AD 0 … 1 Adresse des Hausarztes Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] hl7:telecom TEL.AT 0 … * Beliebig viele Kontaktdaten des Hausarztes. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 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) hl7:associated​Person 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)=0]] hl7:associated​Person 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)!=0]] hl7:scoping​Organization 0 … 1 R Arztpraxis oder Ordination. Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen. (atl...und) Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … * Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (atl...und) wo [not(@nullFlavor)] hl7:name ON 1 … 1 M Name 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. (atl...und) hl7:telecom TEL.AT 0 … * Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] Eingefügt 0 … * von 1.2.40.0.34.6.0.11.1.27 Participant Auskunftsberechtigte Person (Notfallkontakt) (DYNAMIC) hl7:participant 0 … * Beteiligter (Notfallkontakt / Auskunftsberechtigte Person) (atl...und) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.27']] @typeCode cs 1 … 1 F IND   In indirektem Bezug. @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M Template ID zur Identifikation dieser Art von Beteiligten (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.27 hl7:time IVL_TS 0 … 1 Zeitraum, in dem der angegebene Kontakt den Notfall-Kontakt darstellt. Wird nur angegeben, wenn der Kontakt bereits absehbar nur in einem eingeschränkten Zeitraum zur Verfügung steht. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC) (atl...und) hl7:associated​Entity 1 … 1 M Beschreibung der Entität. (atl...und) @classCode cs 1 … 1 F ECON   Emergency contact - Notfall-Kontakt hl7:code CE 0 … 1 Verwandtschaftsverhältnis des Beteiligten zum Patienten, z.B. DAU („daughter“), wenn die Beteiligte die Tochter des Patienten ist. (atl...und) wo [not(@nullFlavor)] @code cs 1 … 1 R Zulässige Werte gemäß Value-Set „ELGA_PersonalRelationship“ @displayName st 0 … 1   @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.111 @codeSystemName st 1 … 1 F HL7:RoleCode   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC) hl7:addr AD 0 … 1 Adresse des Beteiligten Grundsätzlich sind die Vorgaben gemäß „Adress-Elemente“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] Auswahl 0 … * Beliebig viele Kontaktdaten des Beteiligten. Elemente in der Auswahl: hl7:telecom[not(@nullFlavor)] hl7:telecom[@nullFlavor='UNK']   Constraint Es SOLL mindestens eine Telefonnummer angegeben werden. hl7:telecom TEL.AT 0 … * R (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1     Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:telecom TEL.AT 0 … 1 Die Kontaktadresse ist unbekannt. nullFlavor "UNK" (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … 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) hl7:associated​Person 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)=0]] hl7:associated​Person 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)!=0]] hl7:scoping​Organization 0 … 1 R Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation). Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen. (atl...und) Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … * Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (atl...und) wo [not(@nullFlavor)] hl7:name ON 1 … 1 M Name 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. (atl...und) hl7:telecom TEL.AT 0 … * Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] Eingefügt 0 … * von 1.2.40.0.34.6.0.11.1.25 Participant Angehoerige (DYNAMIC) hl7:participant 0 … * Beteiligter (Angehöriger) (atl...und) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.25']] @typeCode cs 1 … 1 F IND   In indirektem Bezug. @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M Template ID zur Identifikation dieser Art von Beteiligten (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.25 hl7:associated​Entity 1 … 1 M Beschreibung der Entität. (atl...und) @classCode cs 1 … 1 F PRS   Personal relationship - In persönlicher Beziehung hl7:code CE 1 … 1 M Verwandtschaftsverhältnis des Beteiligten zum Patienten. Beispiel: DAU („daughter“), wenn die Beteiligte die Tochter des Patienten ist oder NBOR für Nachbar. (atl...und) @code cs 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC) @displayName st 0 … 1   @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.111 @codeSystemName st 1 … 1 F HL7:RoleCode   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC) hl7:addr AD 0 … 1 Adresse des Beteiligten Grundsätzlich sind die Vorgaben gemäß „Adress-Elemente“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] hl7:telecom TEL.AT 0 … * Beliebig viele Kontaktdaten des Beteiligten. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 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) hl7:associated​Person 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)=0]] hl7:associated​Person 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (atl...und) wo [hl7:name [count(child::*)!=0]] hl7:scoping​Organization 0 … 1 R Beinhaltet 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) (atl...und) Eingefügt 0 … * von 1.2.40.0.34.6.0.11.1.26 Participant Versicherung (DYNAMIC) hl7:participant 0 … * Beteiligter (Versicherter/Versicherung). (atl...und) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.26']] @typeCode cs 1 … 1 F HLD @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M Template ID zur Identifikation dieser Art von Beteiligten (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.26 hl7:time IVL_TS 0 … 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) (atl...und) hl7:associated​Entity 1 … 1 M (atl...und) @classCode cs 1 … 1 F POLHOLD   Policy holder - Halter einer Versicherungspolizze Auswahl 1 … 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 hl7:id II 0 … 1 (atl...und) wo [not(@nullFlavor)] hl7:id II 0 … 1 (atl...und) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (atl...und) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:code CE 1 … 1 M Versicherungsverhältnis codiert Beispiele: SELF, wenn der Patient selbst der Versicherte ist. FAMDEP, wenn der Patient bei einem Familienmitglied mitversichert ist. (atl...und) @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.111 @codeSystemName st 1 … 1 F HL7:RoleCode   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.9 ELGA_InsuredAssocEntity (DYNAMIC) hl7:addr AD 0 … 1 Adresse des Beteiligten. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] hl7:telecom TEL.AT 0 … * Beliebig viele Kontaktdaten des Beteiligten. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:associated​Person 0 … 1 C Name des Beteiligten. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (atl...und)   Constraint Wenn das Versicherungsverhältnis "familienversichert" ("FAMDEP“) ist, MUSS eine associatedPerson angegeben sein, M [1..1], sonst kann sie komplett entfallen, O [0..1] hl7:scoping​Organization 1 … 1 M Versicherungsgesellschaft. Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen. (atl...und) Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … * Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (atl...und) wo [not(@nullFlavor)] hl7:name ON 1 … 1 M Name 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. (atl...und) hl7:telecom TEL.AT 0 … * Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)]   Schematron assert role  error     test not(hl7:code[@code='FAMDEP']) or hl7:associated​Person     Meldung Wenn das Versicherungsverhältnis "familienversichert" ist, dann muss eine associatedPerson angegeben sein.   Eingefügt 0 … 1 von 1.2.40.0.34.6.0.11.1.29 Participant Betreuungsorganisation (DYNAMIC) hl7:participant 0 … 1 Beteiligter (Betreuende Organisation) (atl...und) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.29']] @typeCode cs 1 … 1 F IND @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M Template ID zur Identifikation dieser Art von Beteiligten (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.29 hl7:associated​Entity 1 … 1 M Beschreibung der Entität. (atl...und) @classCode cs 1 … 1 F CAREGIVER   Betreuer hl7:scoping​Organization 1 … 1 M Betreuende Organisation (atl...und) Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … * Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (atl...und) wo [not(@nullFlavor)] hl7:name ON 1 … 1 M Name 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. (atl...und) hl7:telecom TEL.AT 0 … * Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] Eingefügt 0 … * von 1.2.40.0.34.6.0.11.1.28 Participant Weitere Behandler (DYNAMIC) hl7:participant 0 … * Beteiligter (Weitere Behandler) (atl...und) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.28']] @typeCode cs 1 … 1 F CON @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M Template ID zur Identifikation dieser Art von Beteiligten (atl...und) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.28 hl7:functionCode CE (extensible) 0 … 1 Funktionscode des Behandlers z.B: „Facharzt für Neurologie“ Eigene Codes und Bezeichnungen dürfen verwendet werden. (atl...und) wo [not(@nullFlavor)] @code cs 1 … 1 R @codeSystem oid 1 … 1 R @displayName st 1 … 1 R   CONF Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC) hl7:associated​Entity 1 … 1 M Beschreibung der Entität. (atl...und) @classCode cs 1 … 1 F PROV   Gesundheitsdiensteanbieter. hl7:addr AD 0 … 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) (atl...und) wo [not(@nullFlavor)] hl7:telecom TEL.AT 0 … * Beliebig viele Kontaktdaten des Beteiligten. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.) Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Bsp: tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 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. hl7:associated​Person 1 … 1 M 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) (atl...und) hl7:scoping​Organization 0 … 1 R Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation). Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen. (atl...und) Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … * Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (atl...und) wo [not(@nullFlavor)] hl7:name ON 1 … 1 M Name 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. (atl...und) hl7:telecom TEL.AT 0 … * Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (atl...und) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“ Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (atl...und) wo [not(@nullFlavor)] Eingefügt 1 … * M von 1.2.40.0.34.6.0.11.1.9 In Fulfillment Of (DYNAMIC)   Constraint Da die Referenz auf einen Auftrag im Labor eine wesentliche Information darstellt, ist dieses Element VERPFLICHTEND anzugeben. hl7:inFulfillmentOf 1 … * M Komponente zur Dokumentation des Auftrags. (atl...und)   at-cda-bbr-data​element-42  Auftrag  Dataset A Allgemeiner Leitfaden @typeCode cs 1 … 1 F FLFS hl7:order 1 … 1 M Auftrag. (atl...und) @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F RQO hl7:id II 1 … 1 M Auftragsnummer, Anforderungsnummer. Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen. (atl...und)   at-cda-bbr-data​element-43  ID  Dataset A Allgemeiner Leitfaden Eingefügt 1 … * M von 1.2.40.0.34.6.0.11.1.48 Documentation Of Service Event - Labor und Mikrobiologie (DYNAMIC) hl7:documentationOf 1 … * M Komponente für die Gesundheitsdienstleistung. (atl...und) @typeCode cs 0 … 1 F DOC hl7:serviceEvent 1 … 1 M Die serviceEvents in den ELGA Labor- und Mikrobiologiebefunden MÜSSEN die "section/code"-Elemente als auch die "section/templateId"-Elemente wiedergeben. Diese Informationen werden über eine Mapping-Vorschrift in die XDS-Metadaten übernommen und ermöglichen einem ELGA-Teilnehmer zu erkennen, welche Sections beinhaltet sind und in welchem Codierungsgrad diese vorliegen. Daher muss für jede Section, welche medizinische Information enthält (Ausnahmen sind "Brieftext" und "Abschließende Bemerkungen"), ein documentationOf/serviceEvent codiert werden. (atl...und) @classCode cs 0 … 1 F ACT @moodCode cs 0 … 1 F EVN hl7:id II 0 … 1 C (atl...und) @extension st 0 NP NP/nicht anwesend @root uid 1 … 1 R In das serviceEvent/id[@root] MUSS die section/templateId[@root] geschrieben werden. Im Fall von mehreren "section/templateId"-Elementen MUSS jenes gewählt werden, dessen @id-Attribut in dem OID-Bereich 1.2.40.0.34.6.0.11.2.X zu finden ist.   Constraint Grundsätzlich MUSS serviceEvent/id angegeben werden. Die serviceEvent/id IST NICHT ERLAUBT für das zusätzliche serviceEvent mit dem Code "18725-2 - Microbiology studies (set)" für Mikrobiologiebefunde bzw. Laborbefunde, die mikrobiologische Ergebnisse beinhalten.   Schematron assert role  error     test hl7:code[@code='18725-2'][@codeSystem='2.16.840.1.113883.6.1'] or hl7:id     Meldung serviceEvent/id MUSS angegeben werden     Schematron assert role  error     test not(hl7:code[@code='18725-2'][@codeSystem='2.16.840.1.113883.6.1'] and hl7:id)     Meldung serviceEvent/id DARF NICHT angegeben werden   hl7:code CE 1 … 1 M Code der Gesundheitsdienstleistung. ↔ Hinweis zum XDS-Mapping: Dieses Element wird in das XDS-Attribut "eventCodeList" gemappt. (atl...und) @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 0 … 1   @displayName st 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.22 ELGA_ServiceEventsLabor (DYNAMIC) hl7:effectiveTime IVL_TS 1 … 1 M Angabe des zeitlichen Erbringungsintervalls effectiveTime mit einer Start- "low" und Endzeit "high" (verpflichtend). Startzeitpunkt: Datum und Zeitpunkt, an dem das analysierende Labor die Anforderung vom Zuweiser in der Labor EDV erfasst hat. Falls nicht vorhanden, sind Datum und Uhrzeit des Starts des Auftrags in der Labor EDV anzugeben. Endzeit: Datum und Zeitpunkt des Abschlusses des Auftrags, welche in der Regel mit der medizinischen Freigabe des Auftrags ident ist. ↔ Hinweis zum XDS-Mapping: Dieses Element wird in die XDS-Attribute "serviceStartTime" und "serviceStopTime" gemappt. Für die automatisierte Datenübernahme aus dem CDA-Dokument in die XDS-Dokumentmetadaten ist stets ein Zeitintervall anzugeben. ACHTUNG: Die Zeitangaben der jeweils ersten Gesundheitsdienstleistung (erstes "documentationOf/serviceEvent"-Element) werden in die Dokument-Metadaten übernommen! Die Bedeutung der Dokument-Metadaten-Elemente lautet daher wie folgt: serviceStartTime: Beginn des ersten documentationOf/serviceEvent-Elements serviceStopTime: Ende des ersten documentationOf/serviceEvent-Elements Beinhaltet 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC) (atl...und) hl7:performer 0 … * C Erbringer der Gesundheitsdienstleistung (Labor mit seinem Leiter). Beinhaltet 1.2.40.0.34.6.0.11.9.24 Performer - Laboratory (DYNAMIC) (atl...und)   Constraint Wurde der Befund nur von einem Labor erstellt, MUSS dieses in "/ClinicalDocument/documentationOf[1]/serviceEvent/performer" dokumentiert werden. Sind mehrere Labors an der Erstellung beteiligt, MUSS das Labor im "structuredBody" entweder auf "entry"-Ebene oder im Rahmen eines "organizer"-Elementes oder direkt bei der Analyse ("observation"-Element) angegeben werden. Angaben in tieferen Ebenen (z.B. "observation"-Ebene) überschreiben solche auf höheren Ebenen (z.B. "organizer"-Ebene). Für den Fall, dass Analysen von einem externen Labor durchgeführt wurden, MUSS assignedEntity/code mit @code="E", @codeSystem="2.16.840.1.113883.2.16.1.4.9", @codeSystemName="HL7.at.Laborkennzeichnung" und @displayName="EXTERN" angegeben werden. Eingefügt 0 … 1 C von 1.2.40.0.34.6.0.11.1.14 Document Replacement - Related Document (DYNAMIC)   Constraint Wird ein Befund aktualisiert, weil z.B. zuvor noch Analyseergebnisse ausständig waren, MUSS dieses Element angegeben werden. hl7:relatedDocument 0 … 1 C (atl...und)   at-cda-bbr-data​element-15  Bezug zu vorgehenden Dokumenten  Dataset A Allgemeiner Leitfaden @typeCode cs 1 … 1 R Art des Bezugs zum Vordokument.   Constraint Erlaubte @typeCodes: RPLC - replaces: Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "deprecated" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar. APND - append: Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert. XFRM - transformed: Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen. Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden. Es ist nicht auszuschließen, dass die Transformation in lokalen Affinity Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall. hl7:parentDocument 1 … 1 M Vorhergehendes Dokument. (atl...und) @classCode cs 0 … 1 F DOCCLIN @moodCode cs 0 … 1 F EVN hl7:id II 1 … 1 M Dokumenten-Id des vorgehenden Dokuments. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. (atl...und)   Schematron assert role  error     test not(hl7:relatedDocument) or hl7:relatedDocument[@typeCode='RPLC']     Meldung Wird /ClinicalDocument/relatedDocument angegeben, MUSS relatedDocument[@typeCode='RPLC'] sein.   Eingefügt 0 … 1 von 1.2.40.0.34.6.0.11.1.50 Component Of - Encompassing Encounter with id (DYNAMIC) hl7:componentOf 0 … 1 Komponente für den Patientenkontakt. (atl...und)   at-cda-bbr-data​element-33  Patientenkontakt  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F COMP hl7:encompassing​Encounter 1 … 1 M Patientenkontakt. (atl...und) @classCode cs 0 … 1 F ENC @moodCode cs 0 … 1 F EVN Auswahl 1 … 1 Elemente in der Auswahl: hl7:id[not(@nullFlavor)] hl7:id[@nullFlavor='UNK'] hl7:id II 0 … 1 Identifikationselement zur Aufnahme der Aufenthaltszahl (atl...und) wo [not(@nullFlavor)]   at-cda-bbr-data​element-34  ID  Dataset A Allgemeiner Leitfaden @extension st 1 … 1 R Aufenthaltszahl, z.B.: Az123456 @root uid 1 … 1 R OID der Liste der Aufenthaltszahlen der Organisation @assigningAuthorityName st 0 … 1   Name der Stelle, welche die ID zugewiesen hat, z.B.: "Amadeus Spital". hl7:id II 0 … 1 (atl...und) wo [@nullFlavor='UNK'] hl7:code CE 1 … 1 M Codierung des Patientenkontakts. (atl...und)   at-cda-bbr-data​element-39  Art des Aufenthalts  Dataset A Allgemeiner Leitfaden @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 0 … 1 F HL7:ActCode @displayName st 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.5 ELGA_ActEncounterCode (DYNAMIC) hl7:effectiveTime IVL_TS 1 … 1 M Zeitraum des Patientenkontakts. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC) (atl...und)   at-cda-bbr-data​element-37  Beginn des Patientenkontaktes  Dataset A Allgemeiner Leitfaden   Constraint Der 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. hl7:responsible​Party 0 … 1 R Komponente für die verantwortliche Person. (atl...und)   at-cda-bbr-data​element-40  Verantwortliche Person  Dataset A Allgemeiner Leitfaden hl7:assignedEntity 1 … 1 M Entität der verantwortlichen Person. Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC) (atl...und) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.8 Encounter Location (DYNAMIC) Die Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand, MUSS verpflichtend angegeben werden (z.B.: die entlassende Krankenanstalt mit Abteilung). hl7:location 1 … 1 M (atl...und) @typeCode cs 0 … 1 F LOC hl7:health​Care​Facility 1 … 1 M (atl...und) @classCode cs 0 … 1 F SDLOC hl7:code CE 1 … 1 M Der Code zur Klassifizierung des GDA repräsentiert die Art der Einrichtung, in der die Tätigkeit stattfand, die zur Erzeugung des Dokuments führte. Zum Beispiel sollten Dokumente, die während eines ambulanten Falls in einem Krankenhaus entstehen, mit dem healthcareFacilityTypeCode für „Krankenhaus“ gekennzeichnet werden.  Zulässige Werte gemäß Value-Set „ELGA_HealthcareFacilityTypeCode“ Für ELGA SOLL der Code dem Eintrag "GDA Rollenname" oder, wenn der GDA Rollenname nicht verfügbar ist, der "Aggregierten Rolle" im GDA-I entsprechen. ↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut XDSDocumentEntry.healthcareFacilityTypeCode gemappt. Zu berücksichtigen sind jeweils die Attribute @code, @codeSystem und @displayName. (atl...und) @displayName st 1 … 1 R hl7:service​Provider​Organization 1 … 1 M Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand. Beinhaltet 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) (atl...und) hl7:component 1 … 1 M (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:structuredBody 1 … 1 M (atl...und) @classCode cs 0 … 1 F DOCBODY @moodCode cs 0 … 1 F EVN hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.69 Brieftext (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true Auswahl 0 … 1 Elemente in der Auswahl: hl7:component welches enthält Template 1.2.40.0.34.6.0.11.2.6 Überweisungsgrund - codiert (DYNAMIC) hl7:component welches enthält Template 1.2.40.0.34.6.0.11.2.114 Überweisungsgrund - uncodiert (DYNAMIC) hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.6 Überweisungsgrund - codiert (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.114 Überweisungsgrund - uncodiert (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true Auswahl 0 … 1 Elemente in der Auswahl: hl7:component welches enthält Template 1.2.40.0.34.6.0.11.2.109 Anamnese - Labor und Mikrobiologie - codiert (DYNAMIC) hl7:component welches enthält Template 1.2.40.0.34.6.0.11.2.111 Anamnese - Labor und Mikrobiologie - uncodiert (DYNAMIC) hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.109 Anamnese - Labor und Mikrobiologie - codiert (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.111 Anamnese - Labor und Mikrobiologie - uncodiert (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true Auswahl 0 … 1 Elemente in der Auswahl: hl7:component welches enthält Template 1.2.40.0.34.6.0.11.2.15 Angeforderte Untersuchungen - codiert (DYNAMIC) hl7:component welches enthält Template 1.2.40.0.34.6.0.11.2.112 Angeforderte Untersuchungen - uncodiert (DYNAMIC) hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.15 Angeforderte Untersuchungen - codiert (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.112 Angeforderte Untersuchungen - uncodiert (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:component 0 … 1 C Beinhaltet 1.2.40.0.34.6.0.11.2.93 Probeninformation (Specimen Section) (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true   Constraint Die Dokumentation des Untersuchungsmaterials kann auf zwei Arten erfolgen: Enthält ein Befund nur einen Befundbereich ("Laboratory Specialty Section"), so kann die Codierung innerhalb der einen Section erfolgen. ODER Bei Verwendung von mehreren Befundbereichen in einem Befund kann es zu Überschneidungen der Untersuchungsmaterialien kommen (ein spezielles Untersuchungsmaterial kann in zwei Befundbereichen analysiert werden). Die CDA Level 3 Codierung eines Untersuchungsmaterials darf jedoch nur einmal im gesamten Befund erfolgen. Daher sind die Informationen zu den Untersuchungsmaterialien in einer eigenen, führenden "Probeninformation (Specimen Section)" zu codieren. hl7:component 1 … * M Beinhaltet 1.2.40.0.34.6.0.11.2.102 Laboratory Specialty Section (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.103 Befundbewertung (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:component 0 … 1 ELGA Labor- und Mikrobiologiebefunde können alle Kriterien erfüllen, die für Befundberichte von der Akkreditierung für medizinische Laboratorien (ISO 15189:2012) gefordert sind. Ein Anhängen des PDF-Befundes ist NICHT erforderlich! Für die vollständige Erfüllung aller Akkreditierungsanforderungen an Befundberichte ist das erstellende Labor verantwortlich; die Akkreditierung wird von der Abt. Akkreditierung Austria im Bundesministerium für Digitalisierung und Wirtschaftsstandort durchgeführt. Mit Rücksicht auf eine einfache Verwendbarkeit der Befunde durch die Benutzer (z.B. niedergelassene Ärzte), die häufig mit einer großen Anzahl von Laborbefunden eines Patienten konfrontiert sind, ist eine Duplizierung der Daten durch Anhängen einer PDF-Ansicht daher nicht gestattet. Beinhaltet 1.2.40.0.34.6.0.11.2.71 Beilagen (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:component 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.2.70 Abschließende Bemerkung (DYNAMIC) (atl...und) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true Eingefügt von 1.2.40.0.34.6.0.11.9.33 Stylesheet Test eBefund (DYNAMIC)   Schematron assert role  error     test matches(//processing-instruction('xml-stylesheet'), '[^\w]ELGA_Stylesheet_v1.0.xsl[^\w]')     Meldung (xml-processing-instr): Es muss ein xml-stylesheet-Prologattribut anwesend sein mit dem Wert für @href=ELGA_Stylesheet_v1.0.xsl

13.4.2 Header Level Templates

Die Header Level Templates wurden aus dem bestehenden "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" übernommen. Diese sind unter Allgemeiner Leitfaden - Kapitel Administrative Daten (CDA Header) - Dokumentenstruktur zu finden.

Wichtiger Hinweis: Header-Element welche spezifisch für den Labor- und Mikrobiologiebefund angepasst wurden, sind der Spezifikation im Kapitel Document Level Template zu entnehmen.

Diese angepassten Elemente umfassen: TODO

• ClincialDocument/templateId
• ClincialDocument/code
• ClinicalDocument/title
• ClinicalDocument/formatCode
• ClinicalDocument/documentationOf/serviceEvent

13.4.3 Section Level Templates

13.4.3.1 Brieftext

Id	1.2.40.0.34.6.0.11.2.69 ref at-cda-bbr-	Gültigkeit	2021‑06‑28 11:19:35 Andere Versionen mit dieser Id: atcdabbr_section_Brieftext vom 2021‑02‑19 11:44:10 atcdabbr_section_Brieftext vom 2019‑04‑02 15:48:06
Status	Aktiv	Versions-Label	1.0.1+20210628
Name	atcdabbr_section_Brieftext	Bezeichnung	Brieftext
Beschreibung Ein am Anfang des Briefes formulierter Freitext für eine Anrede oder Begrüßung. Z.B. „Sehr geehrte Kollegin…“ Die Angabe von medizinisch / fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT. Es ist EMPFOHLEN, redundante Angaben von Patientennamen oder Aufenthaltsdaten des Patienten in dieser Section zu vermeiden.
Kontext	Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.69
Klassifikation	CDA Section level template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz at-cda-bbr-data​element-55  Brieftext  Dataset A Allgemeiner Leitfaden
Benutzt	Benutzt 4 Templates Benutzt als Name Version 1.2.40.0.34.6.0.11.9.36 Containment Author Body (1.0.1+20230717) DYNAMIC 1.2.40.0.34.6.0.11.9.3 Containment Informant Body (1.0.1+20211213) DYNAMIC 1.2.40.0.34.6.0.11.3.53 Containment Logo Entry (1.0.1+20210628) DYNAMIC 1.2.40.0.34.6.0.11.2.8 Containment Übersetzung (1.0.2+20230717) DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.6.0.11.2.69 Brieftext (2021‑02‑19 11:44:10) ref at-cda-bbr- Version: Template 1.2.40.0.34.6.0.11.2.69 Brieftext (2019‑04‑02 15:48:06) ref at-cda-bbr-
Beispiel	Strukturbeispiel <section classCode="DOCSECT">   <templateId root="1.2.40.0.34.6.0.11.2.69"/>  <code code="BRIEFT" displayName="Brieftext" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  <!-- Titel der Section Brieftext wird vom ELGA Referenz-Stylesheet nicht angezeigt! -->   <title>Brieftext</title>  <!-- Textbereich der Section -->   <text>Sehr geehrte Kollegen </text>  <!-- Maschinenlesbare Elemente der Section (optionales Logo) -->   <entry>     <!-- template 1.2.40.0.34.6.0.11.3.53 'Logo Entry' (2020-01-09T12:00:13) -->   </entry></section>
Item DT Kard Konf Beschreibung Label hl7:section Container zur Angabe des Brieftexts. (atc...ext)   at-cda-bbr-data​element-55  Brieftext  Dataset A Allgemeiner Leitfaden @moodCode cs 0 … 1 F EVN @classCode cs 0 … 1 F DOCSECT hl7:templateId II 1 … 1 M (atc...ext) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.2.69 hl7:id II 0 … 1 Eindeutige ID der Section (atc...ext) wo [not(@nullFlavor)] hl7:code CE 1 … 1 M Code der Section. (atc...ext) @codeSystemName st 0 … 1 F ELGA_Sections @code CONF 1 … 1 F BRIEFT @codeSystem 1 … 1 F 1.2.40.0.34.5.40 hl7:title ST 1 … 1 M (atc...ext)   CONF Elementinhalt muss "Brieftext" sein hl7:text SD.TEXT 1 … 1 M Information für den menschlichen Leser. Achtung: Wird ein Logo als maschinenlesbares Element angegeben, darf keine Referenz darauf im narrativen Text-Bereich angegeben werden (<renderMultiMedia referencedObject="…"/>). (atc...ext) hl7:author 0 … * R Beinhaltet 1.2.40.0.34.6.0.11.9.36 Author Body (DYNAMIC) (atc...ext) hl7:informant 0 … * R Beinhaltet 1.2.40.0.34.6.0.11.9.3 Informant Body (DYNAMIC) (atc...ext) hl7:entry 0 … 1 R Es KANN zusätzlich ein Logo als maschinenlesbares Element angegeben werden. Maschinenlesbares Element gemäß Template „ELGA Logo-Entry“ . Beinhaltet 1.2.40.0.34.6.0.11.3.53 Logo Entry (DYNAMIC) (atc...ext) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind cs 0 … 1 F true hl7:component 0 … * Optionale Subsections zur Angabe von Übersetzungen des text-Elements in andere Sprachen. Beinhaltet 1.2.40.0.34.6.0.11.2.8 Übersetzung (DYNAMIC) (atc...ext) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind cs 0 … 1 F true

TODO

13.4.3.2 Beilagen

Id	1.2.40.0.34.6.0.11.2.71 ref at-cda-bbr-	Gültigkeit	2023‑04‑05 13:40:58 Andere Versionen mit dieser Id: atcdabbr_section_Beilagen vom 2021‑06‑28 11:22:40 atcdabbr_section_Beilagen vom 2021‑02‑19 11:43:44 atcdabbr_section_Beilagen vom 2020‑01‑09 09:53:16
Status	Aktiv	Versions-Label	1.0.2+20230717
Name	atcdabbr_section_Beilagen	Bezeichnung	Beilagen
Beschreibung Sonstige Beilagen, außer denjenigen Dokumenten, die in „Willenserklärungen und andere juridische Dokumente“ angegeben sind. Achtung: Da einzelne e-Befunde vom Bürger ausgeblendet oder gelöscht werden können, ist ein Referenzieren bzw. Verweisen auf andere e-Befunde nicht zuverlässig und daher NICHT ERLAUBT. Inhalte, die unmittelbar zum e-Befund gehören, sollen daher als Beilage eingebettet werden.
Kontext	Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.71
Klassifikation	CDA Section level template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz at-cda-bbr-data​element-58  Beilagen  Dataset A Allgemeiner Leitfaden
Benutzt	Benutzt 4 Templates Benutzt als Name Version 1.2.40.0.34.6.0.11.9.36 Containment Author Body (1.0.1+20230717) DYNAMIC 1.2.40.0.34.6.0.11.9.3 Containment Informant Body (1.0.1+20211213) DYNAMIC 1.2.40.0.34.6.0.11.3.19 Containment Eingebettetes Objekt Entry (1.0.2+20230717) DYNAMIC 1.2.40.0.34.6.0.11.2.8 Containment Übersetzung (1.0.2+20230717) DYNAMIC
Beziehung	Spezialisierung: Template 1.2.40.0.34.6.0.11.2.71 Beilagen (2021‑06‑28 11:22:40) ref at-cda-bbr- Version: Template 1.2.40.0.34.6.0.11.2.71 Beilagen (2021‑02‑19 11:43:44) ref at-cda-bbr- Version: Template 1.2.40.0.34.6.0.11.2.71 Beilagen (2020‑01‑09 09:53:16) ref at-cda-bbr-
Beispiel	Strukturbeispiel <section>   <templateId root="1.2.40.0.34.6.0.11.2.71"/>  <!-- Code der Section -->   <code code="BEIL" displayName="Beilagen" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  <!-- Titel der Section -->   <title>Beilagen</title>  <!-- Textbereich der Section -->   <text>     <table>       <thead>         <tr>           <th styleCode="xELGA_colw:1">Titel des Dokuments</th>          <th styleCode="xELGA_colw:1">Erstellungsdatum</th>          <th styleCode="xELGA_colw:1">Dokument</th>        </tr>      </thead>      <tbody>         <tr>           <td>Laborbefund</td>          <td>05.11.2019</td>          <td>             <renderMultiMedia referencedObject="Beilage-1"/>          </td>        </tr>      </tbody>    </table>  </text>  <!-- Maschinenlesbare Elemente der Section -->   <entry>     <!-- template 1.2.40.0.34.6.0.11.3.19 'Eingebettetes Objekt Entry' (2019-05-29T11:59:07) -->   </entry></section>
Item DT Kard Konf Beschreibung Label hl7:section Container zur Angabe der Beilagen. (atc...gen)   at-cda-bbr-data​element-58  Beilagen  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F DOCSECT @moodCode cs 0 … 1 F EVN hl7:templateId II 1 … 1 M (atc...gen) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.2.71 hl7:id II 0 … 1 Eindeutige ID der Section (atc...gen) wo [not(@nullFlavor)] hl7:code CE 1 … 1 M (atc...gen) @displayName st 0 … 1 F Beilagen @codeSystemName st 0 … 1 F ELGA_Sections @code CONF 1 … 1 F BEIL @codeSystem 1 … 1 F 1.2.40.0.34.5.40 hl7:title ST 1 … 1 M (atc...gen)   CONF Elementinhalt muss "Beilagen" sein hl7:text SD.TEXT 1 … 1 M Information für den menschlichen Leser. Es SOLLEN der Titel des Dokuments, sowie das Erstellungsdatum angegeben werden. (atc...gen) hl7:author 0 … * R Beinhaltet 1.2.40.0.34.6.0.11.9.36 Author Body (DYNAMIC) (atc...gen) hl7:informant 0 … * R Beinhaltet 1.2.40.0.34.6.0.11.9.3 Informant Body (DYNAMIC) (atc...gen) hl7:entry 1 … * M Maschinenlesbares Element. Die Beilagen MÜSSEN als maschinenlesbare Elemente angegeben werden. Beinhaltet 1.2.40.0.34.6.0.11.3.19 Eingebettetes Objekt Entry (DYNAMIC) (atc...gen) @typeCode cs 1 … 1 F DRIV   DRIV (is derived from) deutet an, dass der section.text aus den Level 3 Entries gerendert wurde und keinen medizinisch relevanten Inhalt enthält, der nicht aus den Entries stammt. @context​Conduction​Ind cs 0 … 1 F true hl7:component 0 … * Optionale Subsections zur Angabe von Übersetzungen des text-Elements in andere Sprachen. Beinhaltet 1.2.40.0.34.6.0.11.2.8 Übersetzung (DYNAMIC) (atc...gen) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind cs 0 … 1 F true

13.4.3.3 Abschließende Bemerkung

Id	1.2.40.0.34.6.0.11.2.70 ref at-cda-bbr-	Gültigkeit	2021‑06‑28 11:25:03 Andere Versionen mit dieser Id: atcdabbr_section_AbschliessendeBemerkung vom 2021‑02‑19 11:27:16 atcdabbr_section_AbschliessendeBemerkung vom 2020‑01‑09 09:53:27
Status	Aktiv	Versions-Label	1.0.1+20210628
Name	atcdabbr_section_AbschliessendeBemerkung	Bezeichnung	Abschließende Bemerkung
Beschreibung Ein am Ende des Briefes formulierter Freitext entsprechend einer Grußformel. z.B. Abschließende Worte, Gruß. Die Angabe von medizinisch / fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT. Es ist EMPFOHLEN, redundante Angaben von Patientennamen oder Aufenthaltsdaten des Patienten in dieser Section zu vermeiden.
Kontext	Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.70
Klassifikation	CDA Section level template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz at-cda-bbr-data​element-56  Abschließende Bemerkungen  Dataset A Allgemeiner Leitfaden
Benutzt	Benutzt 4 Templates Benutzt als Name Version 1.2.40.0.34.6.0.11.9.36 Containment Author Body (1.0.1+20230717) DYNAMIC 1.2.40.0.34.6.0.11.9.3 Containment Informant Body (1.0.1+20211213) DYNAMIC 1.2.40.0.34.6.0.11.3.19 Containment Eingebettetes Objekt Entry (1.0.2+20230717) DYNAMIC 1.2.40.0.34.6.0.11.2.8 Containment Übersetzung (1.0.2+20230717) DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.6.0.11.2.70 Abschließende Bemerkung (2021‑02‑19 11:27:16) ref at-cda-bbr- Version: Template 1.2.40.0.34.6.0.11.2.70 Abschließende Bemerkung (2020‑01‑09 09:53:27) ref at-cda-bbr- Version: Template 1.2.40.0.34.11.1.2.2 AbschliessendeBemerkung (2012‑07‑14) ref elgabbr-
Beispiel	Strukturbeispiel <section>   <templateId root="1.2.40.0.34.6.0.11.2.70"/>  <!-- Code der Section -->   <code code="ABBEM" displayName="Abschließende Bemerkungen" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  <!-- Titel der Section Abschließende Bemerkungen wird vom ELGA Referenz-Stylesheet nicht angezeigt! -->   <title>Abschließende Bemerkungen</title>  <!-- Textbereich der Section -->   <text>Freundliche Grüße</text></section>
Item DT Kard Konf Beschreibung Label hl7:section Container zur Angabe der abschließenden Bemerkungen. (atc...ung)   at-cda-bbr-data​element-56  Abschließende Bemerkungen  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F DOCSECT @moodCode cs 0 … 1 F EVN hl7:templateId II 1 … 1 M (atc...ung) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.2.70 hl7:code CE 1 … 1 M (atc...ung) @codeSystemName st 0 … 1 F ELGA_Sections @code CONF 1 … 1 F ABBEM @codeSystem 1 … 1 F 1.2.40.0.34.5.40 hl7:title ST 1 … 1 M (atc...ung)   CONF Elementinhalt muss "Abschließende Bemerkungen" sein hl7:text SD.TEXT 1 … 1 M (atc...ung) hl7:author 0 … * R Beinhaltet 1.2.40.0.34.6.0.11.9.36 Author Body (DYNAMIC) (atc...ung) hl7:informant 0 … * R Beinhaltet 1.2.40.0.34.6.0.11.9.3 Informant Body (DYNAMIC) (atc...ung) hl7:entry 0 … * R Beinhaltet 1.2.40.0.34.6.0.11.3.19 Eingebettetes Objekt Entry (DYNAMIC) (atc...ung) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind cs 0 … 1 F true hl7:component 0 … * Optionale Subsections zur Angabe von Übersetzungen des text-Elements in andere Sprachen. Beinhaltet 1.2.40.0.34.6.0.11.2.8 Übersetzung (DYNAMIC) (atc...ung) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind cs 0 … 1 F true

13.4.4 Entry Level Template

13.4.5 Weitere CDA Fragmente

13.5 Terminologien

Die erforderlichen Terminologien sind im Folgenden aufgelistet.

Falls Werte in den definierten Value-Sets fehlen, dann bitten wir um die Meldung mit einem Vorschlag an cda@elga.gv.at.

14 Anhang

14.1 Abbildungen

14.2 Tabellen

14.3 Referenzen