Patient Summary

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
[Markierung ausstehend][Markierung ausstehend]
(Zeitangaben)
 
Zeile 83: Zeile 83:
 
{{EndBlueBox70}}
 
{{EndBlueBox70}}
  
* [[elga-cdaps-2.06.2:Patient_Summary#.C3.9Cbersichtstabelle_administrative_Daten|Übersichtstabelle der administrativen Daten des Patient Summary]]
+
* [[ILF:Patient_Summary#.C3.9Cbersichtstabelle_administrative_Daten|Übersichtstabelle der administrativen Daten des Patient Summary]]
* [[elga-cdaps-2.06.2:Patient_Summary#.C3.9Cbersichtstabelle_der_Sections|Übersichtstabelle der medizinischen Inhalte des Patient Summary]]
+
* [[ILF:Patient_Summary#.C3.9Cbersichtstabelle_der_Sections|Übersichtstabelle der medizinischen Inhalte des Patient Summary]]
  
 
==Zweck==
 
==Zweck==

Aktuelle Version vom 19. November 2018, 20:40 Uhr






Wichtige 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 Urheber- 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, vervielfältigen oder 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.
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

Urheberrechte und Nutzungsrechte von anderen Quellen (“Third Party IP”): 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 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.

Im Folgenden finden Sie eine Liste von Terminologien (ohne Anspruch auf Vollständigkeit), die eine solche separate Lizenz erfordern können:

Terminologie Eigentümer, Kontaktinformation
SNOMED CT International Healthcare Terminology Standards Development Organization (IHTSDO) info@ihtsdo.org
Logical Observation Identifiers Names & Codes (LOINC) Regenstrief Institute, Inc. www.regenstrief.org loinc.org
Unified Code for Units of Measure (UCUM) Regenstrief Institute, Inc. www.regenstrief.org unitsofmeasure.org
International Classification of Diseases (ICD) World Health Organization (WHO)
International Classification of Diseases (ICD-10) BMGF Bundesministerium für Gesundheit und Frauen www.bmgf.gv.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 https://www.edqm.eu/

Inhaltsverzeichnis

1 Übersicht

Das ist der Implementierungsleitfaden für das Österreichische Patient Summary Dokument. Die Vorgaben beruhen auf dem HL7 Leitfaden für das Internationale Patient Summary (HL7 IPS) und sind kompatibel mit den Vorgaben für das EU-Patient Summary für den grenzüberschreitenden Datenaustausch (EU eHealth Network).

2 Einleitung

2.1 Definition

Was ist ein Patient Summary?
Ein Patient Summary ist eine standardisierte Zusammenfassung von grundlegenden medizinischen Informationen zu einem Patienten, um Angehörigen von Gesundheitsberufen einen schnellen Überblick über die wesentlichen Fakten zum Gesundheitszustand des Patienten zu verschaffen.

Das Patient Summary soll zur sicheren und zuverlässigen Gesundheitsversorgung beitragen, sowohl im Fall von unerwarteten oder ungeplanten Behandlungen (Unfall, Notfall), als auch bei geplanten Behandlungen und bei der grenzüberschreitenden Gesundheitsversorgung.

Ein Patient Summary enthält allgemeine demografische Daten des Patienten (z.B. Name, Geburtsdatum, Geschlecht), eine Zusammenfassung der für die weitere medizinische Behandlung wesentlichen Erkenntnisse und Inhalte aus den Krankenakten des Patienten (z.B. aktuelle medizinische Probleme, Allergien, größere chirurgische Eingriffe, medizinische Implantate) sowie die aktuelle Medikation.

2.2 Zweck

Ziel des Patient Summary ist es

  • dem GDA einen schnellen Überblick über die (in ELGA) verfügbaren Informationen zu einem Patienten zu ermöglichen
  • die wesentlichen Gesundheitsinformationen eines Patienten eindeutig und hochstrukturiert zu dokumentieren und in andere Sprachen übersetzbar zu machen

2.3 Umfang

Das Patient Summary ist

  • ein minimaler und nicht-vollständiger Datensatz,
  • geeignet für alle medizinischen Fachrichtungen und Gesundheitseinrichtungen,
  • unabhängig von der aktuellen Situation des Patienten,
  • für die grenzüberschreitende Gesundheitsversorgung vorgesehen.

Das Patient Summary ist daher keine vollständige Krankenakte, sondern eine Zusammenfassung. "Minimaler und nicht-vollständiger Datensatz" bedeutet, dass nur ein Teil der Krankengeschichte im Patient Summary dokumentiert wird. Es soll den eigentlichen Gesundheitszustand des Patienten repräsentieren und nicht die Historie abbilden. Es ist unabhängig von der medizinischen Fachrichtung oder dem Typ der Gesundheitseinrichtung.

2.4 Zielgruppe

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

2.5 Beziehung zu anderen Projekten und Leitfäden

Das Österreichische Patient Summary soll über die Elektronische Gesundheitsakte ELGA zur Verfügung stehen [www.elga.gv.at]. Für Bürger, die auch ELGA-Teilnehmer sind, kann ein Patient Summary erzeugt werden und über das ELGA-Portal angesehen werden. Ihre behandelnden ELGA-Gesundheitsdiensteanbieter sollen darauf zugreifen dürfen.

Das Österreichische Patient Summary soll auch für den grenzüberschreitenden Datenaustausch zur Verfügung stehen, wenn der ELGA-Teilnehmer dies möchte (EU eHealth Network). Das EU-Projekt "eHealth Digital Service Infrastructure" (eHDSI) hat zum Ziel, dass EU Bürger ihre "Patient Summaries" und "ePrescriptions" (elektronische Rezepte) auch in anderen Ländern der EU verwenden können. Österreich soll ab 2020 an dieses Netzwerk angeschlossen werden.

Die Vorgaben dieses Leitfaden beruhen auf dem HL7 Leitfaden für das Internationale Patient Summary (HL7 IPS) sowie auf den allgemeinen Vorgaben für ELGA CDA Dokumente (Allgemeiner Implementierungsleitfaden). Wo das möglich war, wurden auch Vorgaben aus anderen bestehenden ELGA CDA Implementierungsleitfäden, wie dem Leitfaden für den Ärztlichen Entlassungsbrief, den Pflegerischen Entlassungsbrief und der e-Medikation wiederverwendet.

2.6 Hinweise zur Verwendung

Dieser Leitfaden ist derzeit ein Abstimmungsdokument, d.h. er wird technisch und inhaltlich noch abgestimmt. Kommentare können an office@hl7.at gesendet werden.

Geben Sie bitte eine exakte Beschreibung des Problems und die Stelle im Dokument an. Dazu gibt es in der PDF-Version am linken Seitenrand eine Skale, die Sie mit der Kapitel- und Seitennummer angeben.

3 Informationen über dieses Dokument

3.1 Allgemeines

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

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

3.2 Sprachliche Gleichbehandlung

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

3.3 Verbindlichkeit

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

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

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

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

3.4 Harmonisierung

Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der "Arbeitsgruppe Patient Summary", die im Zeitraum von September 2016 bis August 2017 tagte. Die Teilnehmer der Arbeitsgruppe sind delegiert durch ihre Organisation und vertreten diese.

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 Patient Summary erfolgte im Auftrag der ELGA GmbH parallel bzw. nach der inhaltlichen Festlegung.

Der Leitfaden wird in einem technischen Abstimmungsverfahren durch die HL7 Austria ("Ballot") zu einem österreichischen Standard. Eine Verordnung des Bundesministeriums kann eine Verbindlichkeit zur Anwendung begründen.

3.5 Autoren und Mitwirkende

3.5.1 Autoren

Das Redaktionsteam bestand aus folgenden Personen:

Name Organisation
Mag. Dr. Stefan Sabutsch ELGA GmbH, HL7 Austria Herausgeber, Autor
DI Sonja Leder Sigma Software Solutions OG Autor
DI Silvia Winker, MSc. Sigma Software Solutions OG Autor

3.5.2 Mitwirkende

Teilnehmer der Arbeitsgruppe Patient Summary Im Zeitraum 2016-2017: Dr. Gabriele Aicher (AKH Wien), Mag.Johannes Ambros (Humanomed IT Solutions Gmbh), Karl Blauensteiner (Gesundheitsverbund WGKK), Dr. Klaus Buttinger (Gespag), Adis Buturovic (AKH Wien), Christian Chvosta (Vinzenz Gruppe), Dr. Christoph Dachs (ÖGAM), Veronika Daxner (ITH Icoserve), Dr. Stefan Dorner, MBA (Wiener Krankenanstaltenverbund (KAV)), DI Reinhard Egelkraut (CGM Clinical Österreich GmbH), Dr. Brigitte Erlacher (Vinzenz Gruppe), Ingrid Fehervary (Wiener Krankenanstaltenverbund (KAV)), Ing. Mag. Udo Feyerl (OÖ Gebietskrankenkasse), Bernd Fischer (ITH Icoserve), Ing. Victor Emanuel Grogger (KAGES), Helga Gruber (ÖÄK), Dr. Ludwig Gruber (ÄK Tirol), Josef Hamedinger (Gespag), DI Sandra Heissenberger (Stadt Wien, Magistratsdirektion), Emmanuel Helm MSc (FH Oberösterreich), Dr. Susanne Herbek (ELGA GmbH), Ing. Wolfgang Hießl, MSc, MBA (OÖGesFonds), Florian Hoffmann (VAEB Institut für Gesundheitsförderung und Prävention GmbH (IfGP) ), Karl Holzer (CGM), Mag. Konrad Hölzl (KAV Wien), Michael Hubich (Barmh. Schwestern), Dr. Christian Husek (Initiative ELGA), Dr. Silvester Hutgrabner (ÖÄK), Reinhold Igler (AKH Wien), Dr. Christina Kastner-Frank (AKH Wien), Dietmar Keimel (CAS), Alexander Keller (Vinzenz Gruppe), Mag. Martin Keplinger (ÖÄK), DI Andrea Klostermann (ELGA GmbH), Dr. Harald Kornfeil (Ordination Dr. Kornfeil), Brigitte Lagler, MSc (Herz-Jesu Krankenhaus; ÖGKV), Cornelia Lahnsteiner (ELGA GmbH), Assoc.Prof.PD.Dr. Felix Langer (AKH Wien), DI Sonja Leder (SigmaSoft), DI Christian Ledl (A1 Telekom Austria ), Cornelia Lindner (ELGA GmbH), Mag. Herwig Loidl, MBA MSc (CareCenter Software GmbH), Patrick Mangesius (ITH Icoserve), Dr. Stefan Marlovits (PremiQaMed), DI Alexander Mense (HL7 Austria), Ing. Mag. (FH) Jan Nicolics (A1 Telekom Austria ), DI Michael Nöhammer (ÖÄK), Roland Novak (SALK), DI Dr. Markus Pedevilla, MSc (KAGES), Lucas Pflanzl, BSc (Institut für Gesundheitsförderung und Prävention GmbH), Mag. Theresa Philippi (ELGA GmbH), Mag. Barbara Philipp-Jaschek, MBA (AKH Wien), Dr. Susanne Rabady (ÖGAM), Dr. Günter Rauchegger (ELGA GmbH), DI Dr. Stefan Rausch-Schott (Vinzenz Gruppe), Dr. Stefan Sabutsch (ELGA GmbH), Dr. Stefan Sauermann (FH Technikum Wien), Michaela Schaller (ÖGKV), Ing. Eduard Schebesta (HCS), Dr. Christian Scheibböck (AKH Wien), DI Herbert Scheiber (Humanomed IT Solutions Gmbh), Markus Schell (Wiener Krankenanstaltenverbund (KAV)), Dr. Michael Schriefl (ÖÄK), Univ.-Prof. Dr.med. Stefan Schulz (MedUni Graz), Dipl.-Ing. Hans-Jörg Seeburger (Atos), Carina Seerainer (ELGA GmbH), DI Dr. Peter Seifter (HL7 / FH Joanneum), Dr.Adolf Sonnleitner (Fabasoft Austria Gmbh), Ing. Mag. (FH) Mag. Christian Stark (Tirol-Kliniken), OA Mag. Dr.med. Günther Stark (Kages), Dr. Lukas Stärker (Österr. Ärztekammer), Doris Steiner (CGM Arztsysteme Österreich), Friederike Stewig (GÖG), Gerhard Stimac (CGM), Mag. Elisabeth Strahser (WKO Fachverband Unternehmensberatung), Univ. Prof. Dr. Zsolt Szépfalusi (MedUni Wien), DI Herlinde Toth (KAV Wien), Dipl.-Ing. (FH) Kathrin Trunner, MSc (BMGF), Ing. Christoph Unfried (HCS), Dr. Burkhard Walla (ÖÄK), Ing. Norbert Weber (WEBMED, Weber GmbH & Co KG), Dr. Irina Weik (BMGF), DI Silvia Winkler, MSc (SigmaSoft), Dr. Petra Ziegelmayer (ÖGAI, Allergiezentrum Wien West)


3.6 Hinweis auf verwendete Grundlagen

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

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

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


3.7 Weitere unterstützende Materialien

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.

4 Technischer Hintergrund

4.1 Hierarchie der Implementierungsleitfäden

Der vorliegende Implementierungsleitfaden basiert auf der grundlegenden Implementierungsvorschrift für alle CDA Dokumente im österreichischen Gesundheitswesen.
Das CDA Dokument "Patient Summary" hat grundsätzlich beiden aufeinander aufbauenden Implementierungsleitfäden zu folgen.

"Zusammenspiel der Implementierungsleitfäden"
[Abbildung 1]

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


Für die Verwendung dieses Implementierungsleitfadens sind zusätzlich die Vorgaben aus

"HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" [OID Root 1.2.40.0.34.7.1]
in der jeweils aktuellen Version vorausgesetzt.


4.2 Weitere Inhalte

5 Funktionale Anforderungen und Anwendungsfälle

5.1 Funktionale Anforderungen

Ein Patient Summary soll alle relevanten Fakten zum Gesundheitszustand eines Patienten enthalten. Es kann daher Informationen aus einer oder mehreren Krankenakten enthalten und mehrere Behandlungsepisoden zusammenfassen. Es soll weitgehend unabhängig von technischen Infrastrukturen und Diensten eingesetzt werden können. Alle Informationen sollen auch maschinenlesbar (codiert) eingebettet werden können.

Dieser Leitfaden beschränkt sich auf das Endprodukt: das Dokument "Patient Summary" selbst mit seinen Inhalten. Die Frage der Erzeugung, wer oder was ein Patient Summary mit welchen Hilfsmitteln oder Algorithmen erstellt, wurde bewusst weitgehend ausgeklammert.

5.1.1 Darstellung

Dieser Leitfaden definiert ein CDA-Dokument, das mit den gängigen CDA-Stylesheets in HTML konvertiert und in einem Browser dargestellt werden kann. Eine optimierte Darstellung erfolgt - wie für alle CDA-Dokumente, die auf dem Allgemeinen Implementierungsleitfaden beruhen - mit dem ELGA Referenz-Stylesheet. Für den Ausdruck wird eine PDF-Konvertierung mit der ELGA CDA2PDF-Suite empfohlen. Zukünftig kann ein alternatives Stylesheet notwendig werden, das speziell auf mehrsprachige und/oder durchgängig codierte Patient Summaries zugeschnitten ist.

5.1.2 Verwendung in ELGA

Das Patient Summary ist ein Dokument, das über ELGA verfügbar gemacht werden kann. Es ist möglich, Patient Summary Dokumente über ELGA abzurufen.

5.1.2.1 Versionierung

Es gibt immer nur eine gültige - aktuelle - Version eines Patient Summary. Durch die Erstellung einer neuen Version des Patient Summary wird die davor erstellte Version obsolet, unabhängig vom Ersteller der jeweiligen Versionen oder vom verwendeten Mechanismus der Erstellung (software-assembled oder human-curated). Die technische Abbildung dieser Vorgabe ist noch zu klären.

5.1.3 Mehrsprachigkeit und grenzüberschreitender Austausch

Das österreichische Patient Summary wird grundsätzlich in deutscher Sprache erstellt. Es ist möglich, den Inhalt zusätzlich in weiteren Sprachen im Dokument anzugeben. Dokumente mit durchgängig maschinenlesbaren Inhalten können prinzipiell auch automatisiert übersetzt werden. Das Patient Summary soll auch für den grenzüberschreitenden Austausch von Gesundheitsdaten eingesetzt werden können.

5.2 Anwendungsfälle

Da die Anwendungsfälle mit der technischen Umsetzung und der Erstellung eines Patient Summary Dokumentes zusammenhängen, sind die angegebenen Anwendungsfälle daher als Vorschlag zu sehen.

5.2.1 Lesender Zugriff

Der Hauptanwendungsfall für das Patient Summary sind alle Situationen, in denen eine Statuserhebung des Gesundheitszustandes eines Patienten erforderlich ist. Das betrifft primär den Erstkontakt, grundsätzlich aber jede Konsultation eines GDA (stationär/ambulant, geplant und ungeplant, präoperativer Anästhesiecheck etc.), auch Notfallaufnahmen und das Notarztwesen; ebenso in der grenzüberschreitenden Gesundheitsversorgung.

Zugriff auf das Patient Summary sollen alle behandelnden Ärzte und Ärztinnen entsprechend ihrer Berechtigung in ELGA haben. Auch andere „gehobene Gesundheitsberufe“ (z.B. gehobener Dienst für Gesundheits- und Krankenpflege) sollten Zugriff erhalten.

Es ist möglich, Inhalte des Patient Summaries zu extrahieren und in Krankenakten zu übernehmen. Teile des Patient Summaries können in EHR-S (elektronischen Krankenakten, z.B. Krankenhaus- oder Arztpraxis-Informationssysteme) integriert und dargestellt werden.

5.2.2 Erstellung (schreibender Zugriff)

Ein Patient Summary kann jederzeit erstellt werden, unabhängig vom aktuellen Zustand der Person oder von einem eventuellen Behandlungsverlauf. Es kann von einer Person editiert und freigegeben oder von einer Software automatisch zusammengestellt werden. Für die Vertrauenswürdigkeit und Verlässlichkeit eines Patient Summary-Dokuments ist das ein substanzieller Unterschied. Damit diese wichtige Kontextinformation für den Empfänger transparent wird, wird wie folgt differenziert:

5.2.2.1 Erstellung durch einen GDA

"human-curated" Die Erstellung erfolgt durch einen GDA (Arzt), wobei die Inhalte bereits von einem System (Krankenhaus- oder Arztpraxis-Informationssystem) vorgeschlagen werden und vom Arzt nachbearbeitet und ergänzt werden können. Der Arzt scheint als rechtlicher Unterzeichner des Patient Summary auf. --> "Patient Summary".

5.2.2.2 Erstellung durch eine Software

"software-assembled" Die Erstellung erfolgt vollautomatisch und regelbasiert anhand der in ELGA oder in einer oder mehreren anderen (lokalen) elektronischen Krankenakten verfügbaren Informationen. "(Automatische) Patientenübersicht" / "(ELGA) Quick View". Der Titel eines ausschließlich aus ELGA-Daten automatisiert durch Software erstellten Dokuments muss "Automatische ELGA-Übersicht" lauten. Die unterschiedlichen Erstellungsarten sollen bereits in den Metadaten des Dokuments und in der XDS-Registry klar erkennbar sein. Zuvor 'human-curated' erstellte Patient Summary Versionen können und sollen ebenfalls als Quelle für ein 'software-assembled' Patient Summary herangezogen werden. Idealerweise werden die Prämissen und Regeln für eine automatische Zusammenstellung transparent und nachvollziehbar gemacht.

Vorgeschlagener Hinweistext für eine "Automatische ELGA-Übersicht":

Die Automatische ELGA-Übersicht ist eine Orientierungshilfe in ELGA und bietet einen Überblick über jene Gesundheitsdaten, die zum Zeitpunkt der Erstellung der Übersicht verfügbar waren. Für diese automatisch von einem Computerprogramm zusammengestellte Übersicht wurden bereits vorliegende Einzelinformationen (maschinenlesbare Elemente, codierte Daten) aus verschiedenen Quellen (eBefunde, eMedikation etc) übernommen. Es kann daher nicht garantiert werden, dass alle relevanten Gesundheitsinformationen enthalten sind.
Die ELGA-Übersicht ist kein Medizinprodukt. Die Verwendung erfolgt auf eigene Gefahr.
Die folgenden, beispielhaft aufgezählten diagnostischen oder therapeutischen Handlungen erfolgen in alleiniger Verantwortung der jeweiligen Behandler/innen:
  • Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten,
  • Erkennung, Überwachung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinderungen,
  • Untersuchung, Veränderung von oder Verordnung von Behelfen zum Ersatz des anatomischen Aufbaus oder physiologischer Vorgänge
  • Maßnahmen zur Empfängnisregelung

6 Grundsätze und Regeln

6.1 Allgemeines

Dieses Dokument spezifiziert eine HL7 CDA R2 Implementierung, ist aber in den Grundzügen kompatibel mit dem in Entwicklung befindlichen FHIR-Standard. In einigen Fällen folgt es eher der FHIR Stilistik, um Konzepte zu repräsentieren und weicht daher von der in CDA bzw HL7 Version 3 üblichen Art ab. Das betrifft hauptsächlich die Mechanismen für Negation, unbekannte und fehlende Informationen (NullFlavors).

Um grenzüberschreitend austauschbar und verständlich zu sein, muss sich das Patient Summary so weit wie möglich auf strukturierte Daten und mehrsprachige internationale Referenzterminologien stützen, die für das Patient Summary ohne Kosten für die globale Nutzung lizenziert werden.

Im Falle von SNOMED CT wird erwartet, dass die IHTSDO (SNOMED International) und die Republik Österreich, vertreten durch das Bundesministerium für Gesundheit und Frauen, eine Vereinbarung treffen werden, um den Einsatz von SNOMED CT für den Einsatz in Österreich zu ermöglichen. In diesem Sinne wird SNOMED CT als bevorzugte Terminologie und für die Mehrheit der Wertmengen (Value Sets) verwendet.

Andere bevorzugte Terminologien, die in dieser Spezifikation verwendet werden, sind LOINC für Beobachtungen (z.B. Labortests) und Dokumentabschnitte (Sections), UCUM für Maßeinheiten und EDQM für Dosisformen und Einnahmearten.

Diese Spezifikation verwendet das HL7-Template-Austauschformat [1] und ART-DECOR® [www.art-decor.org] als Spezifikationsplattform. Nutzer dieses Leitfadens können die IPS-Projektseite in ART-DECOR® besuchen, um die Template-Spezifikationen zu durchsuchen und Beispiele zu überprüfen.

6.2 Annahmen

Dieser Implementierungsleitfaden wurde von der Arbeitsgruppe unter folgenden Annahmen erstellt:

  • Der Leitfaden spezifiziert das "Endprodukt", ein Patient Summary Dokument, das in Österreich allgemein und speziell in ELGA verwendet werden kann und alle Daten und Strukturen enthält, um es auch für den grenzüberschreitenden Austausch von Gesundheitsdaten zu nutzen.
  • Die Erstellung des Patient Summary Dokuments wurde bewusst weitgehend ausgeklammert.
  • Fragen der Finanzierung der Umsetzung wurden nicht betrachtet.
  • Das Patient Summary definiert eine Struktur, die notwendig ist, um Daten elektronisch und automatisch in anderen GDA-IT-Systemen weiterzuverarbeiten, zu aggregieren und zu übersetzen. Die Arbeitsgruppe hat die Vorgaben im Bewusstsein definiert, dass die notwendigen Quelldaten nicht immer vorliegen, und wenn sie vorliegen, nicht immer in der erforderlichen Struktur und Detailgenauigkeit. Das Patient Summary dient als "Leuchtturm", um künftige Dokumentationen entsprechend diesem Mindeststandard anzupassen.
  • Der Leitfaden bezieht sich auf die allgemeinen ELGA-Richtlinien für Dokumente (Allgemeiner CDA-Implementierungsleitfaden). Damit werden die Mechanismen für den Austausch, das Dokumentenmanagement und die Darstellung definiert.
  • Der Leitfaden nutzt soweit möglich bereits in anderen Leitfäden definierte strukturierte Inhaltselemente ("Templates")
  • Die in diesem Leitfaden definierten Templates sollen baugleich in anderen Dokumenten verwendet werden.
  • Die Templates werden in Art-Decor unter Nutzung des internationalen Template Standards modelliert, Prüfregeln ("Schematron") können direkt aus Art-Decor abgeleitet werden.

6.3 Umgang mit codierten Informationen und Terminologien

6.3.1 Codierte Information

Eine Prämisse des Patient Summary-Leitfadens ist eine durchgängige Maschinenlesbarkeit der einzelnen medizinischen Informationen. Dazu ist es notwendig, die Informationen mit codierten Konzepten auszudrücken ("Codierung"). Codierte Informationen erlauben eine Übersetzung in andere Sprachen ("Translation") und eine Überführung in andere Terminologien oder Codesysteme ("Transcodierung"). Die Datentypen für codierte Informationen werden in Allgemeiner Leitfaden: Codierte Elemente beschrieben. Wenn die erwünschten Informationen nicht vorliegen oder nicht mit codierten Konzepten ausgedrückt werden können, kommen die im Folgenden vorgestellten Methoden zum Einsatz.

6.3.2 Unbekannte und keine Information

Nicht immer können für bestimmte erwünschte Inhalte (Erkrankungen, Zustände, Eigenschaften, etc.) auch tatsächlich Angaben gemacht werden. Der Leitfaden unterscheidet dabei zwischen zwei Situationen:

  • Der erwünschte Inhalt ist unbekannt (z.B. wenn die Medikation eines Patienten unbekannt ist)
  • Der erwünschte Inhalt liegt bekanntlich nicht vor (z.B. wenn der Patient tatsächlich keine Medikamente einnimmt)

Spezifischere Formen abwesender Information oder Negation wurden nicht als relevant erachtet, wie zum Beispiel die Abwesenheit einer Allergie auf ein bestimmtes Antigen, der Ausschluss einer bestimmten Krankheit oder die Tatsache, dass eine bestimmte Impfung nicht durchgeführt wurde.

Für die semantische Repräsentation dieser Situationen werden SNOMED-CT-Codes verwendet; die sonst in CDA üblichen Mechanismen (nullFlavor, negationInd) werden hier weitgehend vermieden. So sollen die Inhalte unabhängig von einem bestimmten technischen Standard ausgedrückt werden, die Implementierungen robuster und einfacher gemacht sowie die Transformation in andere Standards wie z.B. FHIR erleichtert werden.

In einigen Fällen fehlen zum Zeitpunkt der Erstellung des Leitfadens die benötigten SNOMED-CT-Konzepte, z. B. "Allergische Disposition nicht bekannt (Situation)". Diese Konzepte wurden bereits beantragt und harren der Aufnahme in eine zukünftige Version von SNOMED CT International Edition. Zwischenzeitlich werden diese Konzepte durch temporäre Platzhalter-Codes dargestellt, die alle mit 'X-' beginnen (z.B. X-AllergicDispositionNotKnown).

6.3.2.1 Darstellung von unbekannter und bekannt fehlender Information im Text

Unbekannte und fehlende Information soll auch im menschenlesbaren Text (section.text) einheitlich dargestellt werden. Folgende Textbausteine sind VERPFLICHTEND zu verwenden:

  • Es liegt keine Information über [X] vor (Bedeutung: die Informationen über [X] wurden nicht erhoben, können nicht erhoben werden oder sind nicht verfügbar)
  • Keine [X] (Bedeutung: Es gibt tatsächlich keine Informationen über [X] oder [X] liegt nachweislich nicht vor.)
6.3.2.1.1 Anwendungsbeispiele

Es liegt keine Information über Allergien oder Intoleranzen vor:

Es liegt keine Information über Allergien oder Intoleranzen vor
Es wurden keine Impfungen durchgeführt:
Es wurden keine Impfungen durchgeführt

6.3.2.1.2 Codebeispiel für den lesbaren Text

Tabellarische Darstellung gilt auch für unbekannte und fehlende Informationen, zusätzlich soll die Nicht-Information optisch hervorgehoben werden (Stylecode).

 <title>Allergien und Intoleranzen</title>
 <text>
  <table>
   <tbody>
    <tr ID="al-1">
     <td>
      <content styleCode="xELGA_blue">Es liegt keine Information über Allergien oder Intoleranzen vor</content>
     </td>
    </tr>
   </tbody>
  </table>
 </text>

6.3.3 Uncodierte Information

Bei der Erstellung des Dokumentes können möglicherweise bestimmte Informationen vorliegen, die nicht codiert werden können, weil

  1. die Information nicht mit den im Leitfaden zugelassenen Terminologien (Value Sets) dargestellt werden kann oder
  2. die Information in keiner bekannten Terminologie enthalten ist, beziehungsweise der Inhalt nicht codiert wurde.

Diese erste Situation wird mit dem folgenden Beispiel verdeutlicht.

<code codeSystem="1.2.40.0.34.5.174" nullFlavor="OTH">
  <originalText>
    <reference value="#ref1"/>
  </originalText>
</code>

Für die Information ist kein geeigneter Code im vorgegebenen Codesystem vorhanden (im Beispiel ICD-10 BMGF 2018). Der konkrete Inhalt wird im Section-Text angegeben und vom Code-Element nur referenziert (value im reference-Element). Diese Variante kann für coding strength CNE (coded no extensions) eingesetzt werden. Der Elementname kann auch anders sein, zB Value.

Hinweis: Mit den zugrunde liegenden Datentypen (HL7 V3 Data Types R1) kann nicht angegeben werden, dass Codes zwar im Codesystem, aber nicht im referenzierten Value Set verfügbar sind. Spätere Versionen dieses Leitfadens können gegebenenfalls auf Data Types R2 aufbauen, um diese Angabe zu unterstützen.

Das folgende Beispiel bezieht sich auf die zweite Situation:

<value xsi:type="CD" nullFlavor="NI">
  <originalText>
    <reference value="#ref1"/>
  </originalText>
</value>

Im zweiten Beispiel wird der allgemeinste NullFlavor "NI" (No Information) verwendet; es gilt sowohl für coding strength CNE (coded no extensions) and CWE (coded with extensions). Wie im ersten Beispiel wird der konkrete Inhalt im Section-Text angegeben und vom Code-Element nur referenziert (value im reference-Element).

Die zweite Variante ist die häufiger eingesetzte Variante.

Hinweis: Der geeignetste NullFlavor wäre eigentlich "UNC" (Uncoded), aber dieser NullFlavor ist in der RIM-Version, auf der HL7 CDA Rel.2 aufbaut, nicht verfügbar. Daher muss der allgemeinere NullFlavor "NI" (No Information) verwendet werden.

6.3.4 Nicht zugeordnete codierte Information

Bei der Erstellung des Dokumentes können möglicherweise bestimmte Informationen codiert in der Quelldokumentation vorliegen, aber die Codes sind nicht in den im Leitfaden zugelassenen Terminologien (Value Sets) verfügbar.

Wenn das codierte Element mit der coding strength CNE (coded no extensions) angegeben ist, wird der nullFlavor "OTH" verwendet; bei coding strength CWE (coded with extensions) der nullFlavor "NI".


<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH"> 
  [
    <originalText>
      <reference value="#ref1"/>
    </originalText>
  ] 
  <translation code="A02.9" codeSystem="1.2.40.0.34.5.174"
    displayName="Salmonelleninfektion, nicht näher bezeichnet"/>
</value>

Die eckigen Klammern deuten an, dass Elemente optional sind. Hinweis: Mit den zugrunde liegenden Datentpyen (HL7 V3 Data Types R1) kann nicht angegeben werden, dass Codes zwar im Codesystem, aber nicht im referenzierten Value Set verfügbar sind. Spätere Versionen dieses Leitfadens können gegebenenfalls auf Data Types R2 aufbauen, um diese Angabe zu unterstützen.

Im Falle der coding strength CWE (coded with extensions) wird der nullFlavor "NI" vorgeschlagen und ebenso die Angabe des korrekten Codes im <translation>-Teilelement. Dies ermöglicht die Angabe, dass eine Zuordnung zu dem Referenz-Value Set versucht wurde, aber keine geeigneten Zielcodes identifiziert wurden.

<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor="NI"> 
  [
    <originalText>
      <reference value="#ref1"/>
    </originalText>
  ] 
  <translation code="A02.9" codeSystem="1.2.40.0.34.5.174"
    displayName="Salmonelleninfektion, nicht näher bezeichnet"/>
</value>

Die eckigen Klammern deuten an, dass Elemente optional sind.

6.3.5 Zugeordnete codierte Information (Übersetzung)

Es kann vorkommen, dass bestimmte Informationen codiert in der Quelldokumentation vorliegen, aber in einer anderen Terminologie als vom Leitfaden zugelassen. Wenn die codierten Konzepte korrekt von der einen in die andere Terminologie zugeordnet werden können (also "übersetzt" oder "gemappt"), ist es erlaubt, auch die originalen Codes zusätzlich anzugeben.

1. Fall: Ein einzelner lokaler Code wird auf einen Code im Referenz-Value Set gemappt

<value xsi:type="CD" code="42338000" codeSystem="2.16.840.1.113883.6.96"
  displayName="Salmonella gastroenteritis">
  [
    <originalText>
      <reference value="#ref1"/>
    </originalText>
  ] 
  <translation code="003.0" codeSystem="2.16.840.1.113883.6.103"
    displayName="Gastroenterite da Salmonella"/>
</value>

Die eckigen Klammern deuten an, dass Elemente optional sind.

2. Fall: Mehrere lokale Codes werden auf das Referenz-Value Set gemappt

<value xsi:type="CD" code="C50.9" codeSystem="1.2.40.0.34.5.171"
  codeSystemName="ICD-10 BMGF"
  displayName="Bösartige Neubildung: Brustdrüse, nicht näher bezeichnet">
  [
    <originalText>
       <reference value="#problem4name"/>
    </originalText>
  ]
  <translation code="code-example" codeSystem="1.999.999"
    codeSystemName="this is only an example"
    displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
    <translation code="174.9" codeSystem="2.16.840.1.113883.6.103"
      codeSystemName="ICD-9CM"
      displayName="Malignant neoplasm of breast (female), unspecified"/>
    <translation code="C50.919" codeSystem="2.16.840.1.113883.6.90"
      codeSystemName="ICD-10-CM"
      displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
 </translation>
    <translation code="422479008" codeSystem="2.16.840.1.113883.6.96"
      codeSystemName="SNOMED CT"
      displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2"/>
 </translation>
</value>

Die eckigen Klammern deuten an, dass Elemente optional sind.

3. Fall: Ein lokaler Code entstammt derselben Terminologie wie das Referenz-Value Set, besitzt aber eine unterschiedliche Granularität.

<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"
  codeSystemName="LOINC" displayName="Patient Summary">
  <translation code="60592-3" codeSystem="2.16.840.1.113883.6.1"
    displayName="Patient summary unexpected contact"/>
</code>

Hinweis: Die R1 Datentyp-Definition versteht die <translation> nur als Mapping zwischen unterschiedlichen Codesystemen ("a set of other concept descriptors that translate this concept descriptor into other code systems"). Es hat sich aber die Interpretation durchgesetzt, dass auch dasselbe Konzept in mehreren Repräsentationen ausgedrückt werden kann, wie es einige Codesysteme (z.B. SNOMED CT) erlauben.

6.4 Mehrsprachigkeit

Codierte Informationen können einfach in unterschiedlichen Sprachen ausgedrückt werden. Für einen zuverlässigen und sicheren grenzüberschreitenden Datenaustausch (EU eHealth Network) ist dies eine funktionelle Notwendigkeit.

Der zugrunde liegende Standard HL7 CDA Rel. 2 hat mit Bordmitteln keine Möglichkeit, um einen Anzeigetext zu einem codierten Konzept in mehreren Sprachen anzugeben. Dieser Leitfaden übernimmt daher als optionales Element die Erweiterung (extension) 'ips:designation', die im HL7 IPS Leitfaden dafür vorgeschlagen wird.

Beispiel 1: Ohne Code-Mapping

<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"
  codeSystemName="LOINC" displayName="Patient Summary">
  <ips:designation lang="it-IT" value="Profilo Sanitario Sintetico"/> 
  <ips:designation lang="fr-FR" value="Patient Summary"/>
  <ips:designation lang="en" value="Patient Summary"/>
</code>

Beispiel 1: Mit Code-Mapping

<value xsi:type="CD" code="42338000" codeSystem="2.16.840.1.113883.6.96"
  displayName="Salmonella-gastroenteritis">
  <ips:designation lang="da-DK" value=" Salmonella-gastroenteritis"/> 
  <ips:designation lang="en" value="Salmonella gastroenteritis (disorder)" type="FSN"/> 
  [
    <originalText>
      <reference value="#ref1"/>
    </originalText>
  ]
  <translation code="003.0" codeSystem="2.16.840.1.113883.6.103"
    displayName="Gastroenterite da Salmonella"/>
</value>

Die eckigen Klammern deuten an, dass Elemente optional sind.

6.4.1 Übersetzung des narrativen Textes

Bei einer Übersetzung eines Dokuments muss vor allem der lesbare Text in anderen Sprachen dargestellt werden können. Die Übersetzung muss dazu bereits im Dokument vorhanden sein, wobei die Übersetzung von einer Person durchgeführt werden kann oder aber automatisch aus den maschinenlesbaren Elementen abgeleitet werden kann. Bei der Darstellung muss (a) die Sprache der Ausgabe identifiziert werden und (b) angegeben werden, ob es sich um das Original handelt oder die Übersetzung. Außerdem sollte die Quelle (Freitext, maschinenlesbare Elemente) und Art der Übersetzung (Übersetzer, automatisch, etc.) angegeben werden.

Die hier verwendete Methode enthält das Original im <text>-Element der Section und die optionalen Übersetzungen in einem <text>-Element einer Subsection, wobei pro Übersetzung eine Subsection angegeben wird. (specified in template 2.16.840.1.113883.10.22.3.15)

Beispiel:

<section>
  <templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
   <id root="..." extension="..."/>
   <code code="48765-2" codeSystem="2.16.840.1.113883.6.1"
      displayName="Allergies and adverse reactions"/>
   <title>Allergies and Intolerances</title>
   <text>No known Allergies</text>
   <!-- omissions -->
   <component>
      <section>
        <!--  subordinate section carrying a translation of the parent section -->
        <title>Allergie ed Intolleranze</title>
        <text>Nessuna Allergia Nota</text>
        <languageCode code="it-IT"/>
      </section>
    </component>
</section>

6.5 Herkunft der Information

Die Angabe der Quelle einer Information kann für die klinische Bewertung dieser Information maßgeblich sein, besonders wenn ein Dokument aus mehreren Quellen (automatisch) zusammengestellt wurde. Daher erlaubt dieser Leitfaden eine systematische und durchgängige Angabe der Herkunft der elektronischen Daten.

6.5.1 Herkunftsangabe auf Dokument-Ebene

Der Autor des Patient Summary-Dokuments MUSS verpflichtend im Header angegeben werden. Dabei kann es sich um eine Person ("human curated") oder um eine Software ("software assembled") handeln.

6.5.2 Herkunftsangabe auf Section-Ebene

Für jeden Dokumentationsabschnitt (Section) können jeweils mehrere Autoren und Informanten angegeben werden. Da die Zuordnung der Einzelinformation bei Angabe mehrerer Autoren und Informanten uneindeutig ist, wird empfohlen, die Herkunft auf Entry-Ebene anzugeben.

  • Autor (Gesundheits-Fachperson, die die Information erstellt hat mit Name und Organisation).
  • Informant (Person, auf deren Angabe die Information beruht: der Patient selbst oder eine dem Patienten verwandte oder bekannte Person)

6.5.3 Herkunftsangabe auf Entry-Ebene

  • Autor (Gesundheits-Fachperson, die die Information erstellt hat mit Name und Organisation)
  • Informant (Person, auf deren Angabe die Information beruht: der Patient selbst oder eine dem Patienten verwandte oder bekannte Person)
  • Dokumentverweis (externalDocument): für jedes Entry kann eine ID angegeben werden, die auf ein externes Dokument verweist, aus dem die Information stammt.

6.6 Zeitangaben

Gemäß Allgemeinem CDA-Leitfaden dürfen Zeitpunkte nur auf zweierlei Arten angegeben werden:

  • Datum im Format YYYYMMDD
  • Datum und Uhrzeit mit Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM

Ist nur eine weniger genaue Zeitangabe verfügbar, sind die fehlenden Stellen mit der Ziffer Null aufzufüllen. Also zum Beispiel ist für "September 2017" die Zeichenfolge 20170900 anzugeben. Die HL7 V3 Datentypen interpretieren Datumswerte so, als ob alle möglichen, aber nicht angegebenen Stellen mit 0 befüllt wären.

Achtung bei Zeitintervallen: Ein Datum, das mit yyyymmdd angegeben wurde, wird standardgemäß interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1. Dezember 2017 angegeben werden soll, MUSS das so erfolgen:

  <low value="20171201"/> 
  <high value="20171202"/>

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

  <low value="20171201000000+0100"/> 
  <high value="20171201235959+0100"/>

7 Technische Spezifikation (Templates)

7.1 Administrative Daten (CDA Header)

7.1.1 Übersichtstabelle administrative Daten

Inhalt Optionalität
Dokumententitel M Link
Klassifikation des Dokuments M Link
Dokumenten-ID M Link
Versionsnummer, SetID M Link
Patient M Link
Verfasser des Dokuments M Link
Dateneingebende Personen O Link
Verwahrer des Dokuments M Link
Empfänger O Link
Unterzeichner O Link
Weitere Unterzeichner O Link
Hausarzt O Link
Notfallkontakt O Link
Angehörige O Link
Versicherung O Link
Betreuungsorganisation O Link
Gesundheitsdienstleistungen O Link
Patientenkontakt O Link


7.1.2 Spezifische Headerelemente

Id1.2.40.0.34.11.13.1.3Gültigkeit2017‑08‑13 13:58:18
StatusKyellow.png EntwurfVersions-Label0.1
NameHeaderCommonsPSAnzeigenameHeaderCommonsPS
BeschreibungAllgemeine Header-Elemente für das ELGA Patient Summary
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Beispiel
Beispiel
<realmCode code="AT"/><typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/><templateId root="1.2.40.0.34.11.1"/><templateId root="1.2.40.0.34.11.13"/><id root="1.2.3.999" extension="--example only--"/><code code="60591-0" codeSystem="2.16.840.1.113883.6.1"/><title/><effectiveTime>
  <low value="20170917162806"/></effectiveTime>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/><languageCode code="de-AT"/><setId root="1.2.3.999" extension="--example only--"/><versionNumber value="1"/>
ItemDTKardKonfBeschreibungLabel
hl7:realmCode
CS (erforderlich)1 … 1MHoheitsbereich des Dokuments(Hea...sPS)
Treetree.png@code
CONF1 … 1FAT
hl7:typeId
II1 … 1MDokumentformat CDA R2.
(Hea...sPS)
Treetree.png@root
uid1 … 1F2.16.840.1.113883.1.3
Treetree.png@extension
st1 … 1FPOCD_HD000040
hl7:templateId
II1 … 1MELGA TemplateId für den Allgemeinen Implementierungsleitfaden(Hea...sPS)
Treetree.png@root
uid1 … 1F1.2.40.0.34.11.1
hl7:templateId
II1 … 1MELGA TemplateId für das ELGA Patient Summary(Hea...sPS)
Treetree.png@root
uid1 … 1F1.2.40.0.34.11.13
hl7:id
II1 … 1MDokumentenId. Für jedes Dokument und jede Version eines Dokumentsets eindeutig.
(Hea...sPS)
hl7:code
CD (extensible)1 … 1MKlassifikation des Dokuments(Hea...sPS)
Treetree.png@code
CONF1 … 1F60591-0
Treetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
hl7:title
ST1 … 1MDokumententitel(Hea...sPS)
 Constraint
Der Titel muss der Dokumentenklasse entsprechen.
Ein möglicher Dokumententitel ist zum Beispiel "Patient Summary"
Einem Kompromiss in der AG folgend sind verschiedene Dokumententitel möglich: zum Beispiel "ELGA Übersicht" für das automatisch erstellte PS oder "Patient Summary" bei händisch gepflegten Dokumenten.
hl7:effectiveTime
IVL_TS1 … 1M(Hea...sPS)
hl7:confidentialityCode
CE (extensible)1 … 1MKlassifizierung der Vertraulichkeit(Hea...sPS)
Treetree.png@code
CONF1 … 1FN
Treetree.png@codeSystem
1 … 1F2.16.840.1.113883.5.25 (Confidentialty (HL7))
hl7:language​Code
CS (erforderlich)1 … 1MSprachcode des Dokuments
(Hea...sPS)
Treetree.png@code
CONF1 … 1Fde-AT
hl7:setId
II1 … 1MEindeutige Id des Dokumentensets(Hea...sPS)
hl7:versionNumber
INT1 … 1MVersionsnummer des Dokuments(Hea...sPS)
Treetree.png@value
int1 … 1RVersionsnummer als positive ganze Zahl

7.1.3 Patient (recordTarget)

Id1.2.40.0.34.11.20001
ref
elgabbr-
Gültigkeit2017‑07‑20
Andere Versionen mit dieser Id:
  • Kblank.png Header​Record​Target vom 2018‑10‑18 14:23:51
  • Kblank.png Header​Record​Target vom 2017‑03‑27
  • Kblank.png Header​Record​Target vom 2013‑10‑08
  • Kblank.png Header​Record​Target vom 2013‑02‑10
  • Kblank.png Header​Record​Target vom 2011‑12‑19
StatusKyellow.png EntwurfVersions-Label
NameHeader​Record​TargetAnzeigenameHeader​Record​Target
Beschreibung
Das RecordTarget-Element enthält den Patienten: Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw über deren Gesundheitsdaten im Dokument berichtet wird.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-9Kyellow.png Patient Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90017InklusionKyellow.png Language CommunicationDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20001 Header​Record​Target (2017‑03‑27)
ref
elgabbr-
Beispiel
Vollständiges Beispiel
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <!-- lokale Patienten ID vom System -->
    <id root="1.2.40.0.34.99.111.1.2" extension="4711" assigningAuthorityName="Amadeus Spital"/>    <!-- Sozialversicherungsnummer des Patienten -->
    <id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>    <!-- Adresse des Patienten -->
    <addr use="H">
      <streetName>Musterstraße</streetName>      <houseNumber>13a</houseNumber>      <postalCode>7000</postalCode>      <city>Eisenstadt</city>      <state>Burgenland</state>      <country>AUT</country>    </addr>
    <!-- Kontaktdaten des Patienten-->
    <telecom value="tel:+43.1.40400" use="H"/>    <telecom value="tel:+43.664.1234567" use="MC"/>    <telecom value="mailto:herbert.mustermann@provider.at"/>    <!-- Name des Patienten -->
    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <prefix qualifier="AC">Dipl.Ing.</prefix>        <given>Herbert</given>        <given>Hannes</given>        <family>Mustermann</family>        <family qualifier="BR">VorDerHeirat</family>        <suffix qualifier="AC">BSc</suffix>        <suffix qualifier="AC">MBA</suffix>      </name>
      <!-- Geschlecht des Patienten -->
      <administrativeGenderCode code="M" displayName="Male" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>      <!-- Geburtsdatum des Patienten -->
      <birthTime value="19701224"/>      <!-- Familienstand des Patienten -->
      <maritalStatusCode code="D" displayName="Divorced" codeSystem="2.16.840.1.113883.5.2"/>      <!-- Religionszugehörigkeit des Patienten -->
      <religiousAffiliationCode code="101" displayName="Römisch-Katholisch" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria"/>      <!-- Vormund/Sachwalter des Patienten "Organisation"-->
      <guardian>
        <!--Eine Organisation als Guardian, hier als Strukturbeispiel-->
        <addr>
          <streetAddressLine>Kinderdorfstraße 1</streetAddressLine>          <postalCode>2371</postalCode>          <city>Hinterbrühl</city>          <state>Niederösterreich</state>          <country>AUT</country>        </addr>
        <!-- Kontaktdaten des Vormunds/Sachwalters (Organisation)-->
        <telecom use="H" value="tel:+43.2236.2928"/>        <telecom use="WP" value="tel:+43.2236.9000"/>        <guardianOrganization>
          <!-- Name der Vormund/Sachwalter-Organisation-->
          <name>SOS Kinderdorf Hinterbrühl</name>        </guardianOrganization>
      </guardian>
      <!-- Vormund/Sachwalter des Patienten "Person" -->
      <guardian>
        <!-- Adresse des Vormunds/Sachwalters (Person) -->
        <addr>
          <streetAddressLine>Musterstraße 1234</streetAddressLine>          <postalCode>8011</postalCode>          <city>Graz</city>          <state>Steiermark</state>          <country>AUT</country>        </addr>
        <!-- Kontaktdaten des Vormunds/Sachwalters (Person) -->
        <telecom use="MC" value="tel:+43.676.1234567"/>        <telecom use="H" value="tel:+43.316.717.653.9939"/>        <telecom use="WP" value="tel:+43.316.608.271.9000"/>        <guardianPerson>
          <!-- Name der Vormund/Sachwalter-Organisation -->
          <name>
            <given>Susi</given>            <family>Sorgenvoll</family>          </name>
        </guardianPerson>
      </guardian>
      <!-- Geburtsort des Patienten -->
      <birthplace>
        <place>
          <addr>Graz</addr>        </place>
      </birthplace>
    </patient>
  </patientRole>
</recordTarget>
Beispiel
Minimalbeispiel 1
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <!-- lokale Patienten ID vom System -->
    <id root="1.2.40.0.34.99.111.1.2" extension="4711"/>    <!-- Name des Patienten -->
    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Herbert</given>        <family>Mustermann</family>      </name>
      <!-- Geschlecht des Patienten -->
      <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>      <!-- Geburtsdatum des Patienten -->
      <birthTime value="19701224"/>    </patient>
  </patientRole>
</recordTarget>
Beispiel
Minimalbeispiel 2
<recordTarget>
  <patientRole>
    <!-- lokale Patienten ID -->
    <id root="1.2.40.0.34.99.111.1.2" extension="4711"/>    <!-- Name des Patienten -->
    <patient>
      <name>
        <given>Herbert</given>        <family>Mustermann</family>      </name>
      <!-- Geschlecht des Patienten -->
      <administrativeGenderCode nullFlavor="UNK"/>      <!-- Geburtsdatum des Patienten -->
      <birthTime nullFlavor="UNK"/>    </patient>
  </patientRole>
</recordTarget>
ItemDTKardKonfBeschreibungLabel
hl7:recordTarget
Komponente für die Patientendaten.
(Hea...get)
 
Target.png
elgagab-data​element-9Kyellow.png Patient Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FRCT
Treetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treetree.pnghl7:patientRole
1 … 1RPatientendaten.
(Hea...get)
Treeblank.pngTreetree.png@classCode
cs0 … 1FPAT
 Beispiel<patientRole classCode="PAT">
  <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>  <patient classCode="PSN" determinerCode="INSTANCE">
    <!-- ... -->
  </patient>
</patientRole>
 Schematron assertrole error 
 teststring-length(hl7:id[1]/@root)>0 
 Meldung patientRole id[1] MUSS als lokale Patienten ID vom System vorhanden sein 
 Schematron assertrole error 
 testhl7:id[2]/@root = '1.2.40.0.10.1.4.3.1' or hl7:id[2]/@nullFlavor='NI' or hl7:id[2]/@nullFlavor='UNK' 
 Meldung patientRole id[2] MUSS Sozialversicherungsnummer des Patienten sein (1.2.40.0.10.1.4.3.1) oder @nullFlavor 'NI' oder 'UNK' ist angegeben 
Treeblank.pngTreetree.pnghl7:id
II2 … *Rid[1] Identifikation des Patienten im lokalen System.
id[2] 
Sozialversicherungsnummer des Patienten
Zugelassene nullFlavor:
  • NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …)
  • UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
id[3] Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit)

(Hea...get)
 Beispiel
lokale Patienten ID vom System, notwendig für XDS
<id root="1.2.40.0.34.99.111.1.2" extension="4711" assigningAuthorityName="Amadeus Spital"/>
 Beispiel
Patienten SV Nummer
<id root="1.2.40.0.10.1.4.3.1" extension="1234241270" assigningAuthorityName="Österreichische Sozialversicherung"/>
 Beispiel
bPK-GH des Patienten: Bereichskürzel + bPK (Base64,28 Zeichen)
<id root="1.2.40.0.10.2.1.1.149" extension="GH:XNV5ThCj5OwJR0oOcWmK4WUs5p4=" assigningAuthorityName="Österreichische Stammzahlenregisterbehörde"/><!--Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen-->
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Adresse des Patienten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:streetAddressLine
0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:streetName
0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:houseNumber
0 … 1(Hea...get)
 Schematron assertrole error 
 testhl7:streetAddressLine or (hl7:streetName and hl7:houseNumber) 
 MeldungGranularitätsstufen Adresse beachten: streetAddressLine oder streetName+houseNumber 
Treeblank.pngTreeblank.pngTreetree.pnghl7:postalCode
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:city
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:state
0 … 1C(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:country
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:additionalLocator
0 … 1(Hea...get)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten des Patienten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...get)
Treeblank.pngTreetree.pnghl7:patient
0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M
Name des Patienten.
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
0 … *(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
1 … *M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
1 … *M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
0 … *(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE1 … 1R
Codierung des Geschlechts des Patienten.
Zugelassene nullFlavor: UNK
(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.​DATE.​MIN1 … 1R
Geburtsdatum des Patienten.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

Zugelassene nullFlavor: UNK
(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:marital​Status​Code
CE0 … 1Codierung des Familienstands des Patienten.
(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:religious​Affiliation​Code
CE0 … 1Codierung des Religionsbekenntnisses des Patienten.
(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:raceCode
NP
Rasse des Patienten
Darf nicht verwendet werden!
(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:ethnic​Group​Code
NPEthnische Zugehörigkeit des Patienten.
Darf nicht verwendet werden!
(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:guardian
0 … *Gesetzlicher Vertreter: Erwachsenenvertreter, Vormund, Obsorgeberechtigter(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1
Die Adresse des gesetzlichen Vertreters oder der Organisation.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Beliebig viele Kontaktdatendes gesetzlichen Vertreters oder der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...get)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:guardian​Person
  • hl7:guardian​Organization
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
 … 1Name des des gesetzlichen Vertreters (Person).
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1MName der Person.
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Organization
 … 1Name des des gesetzlichen Vertreters (Organisation).
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation.(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthplace
0 … 1Geburtsort des Patienten.
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:place
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1M

Die Adresse des Geburtsorts.

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

Granularitätsstufe 2 oder 3 ist auch bei EIS Enhanced und Full Support nicht erforderlich.
(Hea...get)
Eingefügt von 1.2.40.0.34.11.90017 Language Communication (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:language​Communication
0 … *
Komponente zur Angabe der Sprachfähigkeiten des Patienten.
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Code
CS0 … 1Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).
(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.173 ELGA_HumanLanguage (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:modeCode
CE0 … 1Ausdrucksform der Sprache.
@codeSystem Fester Wert: 2.16.840.1.113883.5.60
(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:proficiency​Level​Code
CE0 … 1Grad der Sprachkenntnis in der Sprache.
@codeSystem Fester Wert: 2.16.840.1.113883.5.61
(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:preference​Ind
BL0 … 1Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.
(Hea...get)

7.1.4 Verfasser des Dokuments (author - generisch)

Der Autor MUSS angegeben werden

  • "software-assembled": der Verfasser ist eine Software
  • "human-curated": der Verfasser ist eine Person

Für den Fall, dass eine Software die Inhalte vorschlägt und eine Person die Inhalte unverändert abzeichnet, gilt das Dokument als "software-assembled", der Unterzeichner wird als Rechtlicher Unterzeichner eingetragen.

Sind mehrere Autoren beteiligt MUSS die erste Person auch der inhatlich Hauptverantwortliche sein, denn diese Person wird in den XDS-Metadaten aufscheinen.

Verfasser einzelner Sektionen: siehe Section-Author


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

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

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

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-48Kyellow.png Autor Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20002 HeaderAuthor (2015‑05‑09)
ref
elgabbr-
Beispiel
Strukturbeispiel für eine Person als „author“
<author typeCode="AUT" contextControlCode="OP">
  <!-- Funktionscode -->
  <functionCode code="OA" displayName="Diensthabender Oberarzt" codeSystem="1.2.40.0.34.99.111.2.1" codeSystemName="Amadeus Spital Funktionen"/>  <!-- Zeitpunkt der Erstellung -->
  <time value="20081224082015+0100"/>  <assignedAuthor classCode="ASSIGNED">
    <!-- Identifikation des Verfassers des Dokuments -->
    <id root="1.2.40.0.34.99.111.1.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>    <!-- Fachrichtung des Verfassers des Dokuments -->
    <code code="107" displayName="Fachärztin/Facharzt für Chirurgie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>    <!-- Kontaktdaten des Verfassers des Dokuments -->
    <telecom value="tel:+43.1.40400"/>    <telecom value="mailto:herbert.mustermann@organization.at"/>    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      <!-- Name des Verfassers des Dokuments -->
      <name>
        <prefix qualifier="AC">Univ.-Prof. Dr.</prefix>        <given>Isabella</given>        <family>Stern</family>      </name>
    </assignedPerson>
    <!-- Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat -->
    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <!-- Name der Organisation -->
      <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      <!-- Kontaktdaten der Organisation -->
      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>
    </representedOrganization>
  </assignedAuthor>
</author>
Beispiel
Strukturbeispiel für datenerstellende Geräte als „author“
<author>
  <!-- Zeitpunkt der Erstellung -->
  <time value="20081224082015+0100"/>  <assignedAuthor>
    <!-- Geräte Identifikation (oder nullFlavor) -->
    <id root="86562fe5-b509-4ce9-b976-176fd376e477"/>    <!-- Geräte Beschreibung -->
    <assignedAuthoringDevice>
      <manufacturerModelName>Good Health System</manufacturerModelName>      <softwareName>Best Health Software Application</softwareName>    </assignedAuthoringDevice>
    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <!-- Name der Organisation -->
      <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      <!-- Kontaktdaten der Organisation -->
      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>
    </representedOrganization>
  </assignedAuthor>
</author>
ItemDTKardKonfBeschreibungLabel
hl7:author
Verfasser des Dokuments.
(Hea...hor)
 
Target.png
elgagab-data​element-48Kyellow.png Autor Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FAUT
Treetree.png@context​Control​Code
cs0 … 1FOP
Treetree.pnghl7:functionCode
CE0 … 1
Funktionscode des Verfassers des Dokuments
z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …
Eigene Codes und Bezeichnungen können verwendet werden. 

Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.
(Hea...hor)
Treetree.pnghl7:time
TS.AT.TZ1 … 1R

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

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

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

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

Zugelassene nullFlavor:

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

(Hea...hor)
Treeblank.pngTreetree.pnghl7:code
CE0 … 1

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

Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.

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

(Hea...hor)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...hor)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:assigned​Person
  • hl7:assigned​Authoring​Device
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
 … 1
Personendaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...hor)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
 … 1(Hea...hor)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FDEV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:manufacturer​Model​Name
SC1 … 1RHersteller und Modellbezeichnung des datenerstellenden Gerätes.
(Hea...hor)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:softwareName
SC1 … 1RBezeichnung (und ggf Version) der datenerstellenden Software.
(Hea...hor)
Treeblank.pngTreetree.pnghl7:represented​Organization
1 … 1MOrganisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.
(Hea...hor)
 Beispiel<representedOrganization classCode="ORG" determinerCode="INSTANCE">
  <id root="1.2.40.0.34.99.111.1.3" extension="1111"/>  <name>
    <!-- ... -->
  </name>
</representedOrganization>
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *MDie OID der Organisation aus dem GDA-Index.

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

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

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

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

(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...hor)

7.1.5 Personen bei der Dateneingabe (dataEnterer - generisch)

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

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

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-65Kyellow.png Schreibkraft Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90003InklusionKgreen.png AssignedEntityElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20003 HeaderDataEnterer (2013‑02‑10)
ref
elgabbr-
Beispiel
Beispiel
<dataEnterer>
  <!-- Zeitpunkt des Schreibens -->
  <time value="20081224082015+0100"/>  <assignedEntity>
    <!-- Die das Dokument schreibende Person -->
    <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>    <telecom value="tel:+43.1.40400.4711"/>    <telecom value="mailto:eva.musterfrau@amadeusspital.at"/>    <assignedPerson>
      <name>DiplKrSr. Eva Musterfrau</name>    </assignedPerson>
  </assignedEntity>
</dataEnterer>
ItemDTKardKonfBeschreibungLabel
hl7:dataEnterer
Person der Dateneingabe.
(Hea...rer)
 
Target.png
elgagab-data​element-65Kyellow.png Schreibkraft Kyellow.png Datensatz
Treetree.pnghl7:time
TS.AT.TZ0 … 1
Der Zeitpunkt an dem das Dokument geschrieben wurde.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(Hea...rer)
Treetree.pnghl7:assignedEntity
1 … 1R
Personendaten der schreibenden Person
Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen.

(Hea...rer)
Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
Treeblank.pngTreetree.pnghl7:id
II1 … *R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...rer)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1MPersondendaten der validierenden Person.
(Hea...rer)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...rer)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1Organistationsdaten der validierenden Person.
(Hea...rer)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...rer)

7.1.6 Verwahrer des Dokuments (custodian - generisch)

Id1.2.40.0.34.11.20004
ref
elgabbr-
Gültigkeit2015‑05‑28
Andere Versionen mit dieser Id:
  • Kblank.png HeaderCustodian vom 2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeaderCustodianAnzeigenameHeaderCustodian
Beschreibung
Der „Verwahrer des Dokuments“ ist diejenige Organisation, die „für die Verwahrung/Verwaltung des Dokuments verantwortlich ist“.
Beispiele:

Das erstellende Krankenhaus ist selbst der Verwalter des Dokuments.
Der übergeordnete Krankenhausträger ist der Verwalter des Dokuments.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-73Kyellow.png Verwahrer Kyellow.png Datensatz
BeziehungVersion: Template 1.2.40.0.34.11.20004 HeaderCustodian (2015‑05‑28)
ref
elgabbr-

Version: Template 1.2.40.0.34.11.20004 HeaderCustodian (2011‑12‑19)
ref
elgabbr-
Beispiel
Vollständiges Beispiel
<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <id root="1.2.3.999" extension="--example only--" assigningAuthorityName="GDA-Index"/>      <name>Amadeus Spital</name>      <telecom value="tel:+43.(0)50.55460-0"/>      <addr>
        <streetName>Hafenstraße</streetName>        <houseNumber>47-51</houseNumber>        <postalCode>4020</postalCode>        <city>Linz</city>        <state>Oberösterreich</state>        <country>AUT</country>      </addr>
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
Beispiel
Minimalbeispiel
<custodian>
  <assignedCustodian>
    <representedCustodianOrganization>
      <id root="1.2.3.999" extension="--example only--"/>      <name>Amadeus Spital</name>      <addr>
        <streetAddressLine>Hafenstraße 47-51</streetAddressLine>        <postalCode>4020</postalCode>        <city>Linz</city>        <country>AUT</country>      </addr>
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
ItemDTKardKonfBeschreibungLabel
hl7:custodian
Verwahrer des Dokuments.
(Hea...ian)
 
Target.png
elgagab-data​element-73Kyellow.png Verwahrer Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FCST
Treetree.pnghl7:assignedCustodian
1 … 1M(Hea...ian)
Treeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1R
Identifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

Zugelassene nullFlavor:
  • NI … Organisation hat keine ID aus dem GDA-Index
  • UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt
(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
1 … 1M Name des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen.
(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … 1Kontaktdaten des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1M Adresse des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...ian)

7.1.7 Empfänger (informationRecipient - generisch)

Id1.2.40.0.34.11.20005
ref
elgabbr-
Gültigkeit2011‑12‑19
StatusKyellow.png EntwurfVersions-Label
NameHeader​Information​RecipientAnzeigenameHeader​Information​Recipient
Beschreibung

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

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

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

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-259Kyellow.png Empfänger Kyellow.png Datensatz
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20005 Header​Information​Recipient (2011‑12‑19)
ref
elgabbr-
Beispiel
Beabsichtigter Empfänger ist eine bekannte Person
<informationRecipient typeCode="PRCP">
  <intendedRecipient>
    <!-- Identifikation des beabsichtigten Empfängers -->
    <id nullFlavor="UNK"/>    <!-- Personendaten des beabsichtigten Empfängers -->
    <informationRecipient>
      <name>
        <prefix qualifier="AC"> Dr.</prefix>        <given>Robert</given>        <family>Empfänger</family>      </name>
    </informationRecipient>
    <!-- Organisation, der der beabsichtigte Empfänger angehört -->
    <receivedOrganization>
      <!-- Name der Organisation des beabsichtigten Empfängers -->
      <name>Ordination Dr. Empfänger</name>      <!-- Kontaktdaten der Organisation des beabsichtigten Empfängers -->
      <telecom value="tel:0512.1234567"/>      <telecom value="fax:0512.1234567.11"/>      <telecom value="mailto:office@ordination-empfaenger.at"/>      <telecom value="http://www.ordination-empfaenger.at"/>      <telecom value="me:12345678791"/>      <!-- Adresse der Organisation des beabsichtigten Empfängers -->
      <addr>
        <streetName>Musterstraße</streetName>        <houseNumber>27/1/13</houseNumber>        <postalCode>6020</postalCode>        <city>Innsbruck</city>        <country>AUT</country>      </addr>
    </receivedOrganization>
  </intendedRecipient>
</informationRecipient>
Beispiel
Beabsichtigter Empfänger ist eine unbekannte Person („An den Hausarzt“)
<informationRecipient typeCode="PRCP">
  <intendedRecipient>
    <id nullFlavor="UNK"/>    <informationRecipient>
      <name>Hausarzt</name>    </informationRecipient>
  </intendedRecipient>
</informationRecipient>
Beispiel
Beabsichtigter Empfänger ist der Patient selbst
<informationRecipient typeCode="PRCP">
  <intendedRecipient>
    <!-- Der Patient besitzt keine ID -->
    <id nullFlavor="NI"/>    <!-- Hinweis auf den Patienten -->
    <informationRecipient>
      <name>Ergeht an den Patienten Dr. Herbert Mustermann</name>    </informationRecipient>
  </intendedRecipient>
</informationRecipient>
<!--Eine erneute Angabe der Adresse des Patienten ist nicht erforderlich.-->
ItemDTKardKonfBeschreibungLabel
hl7:information​Recipient
Beabsichtiger Empfänger des Dokuments.
(Hea...ent)
 
Target.png
elgagab-data​element-259Kyellow.png Empfänger Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1 

Typ des Informationsempfängers.

Bsp: PRCP „Primärer Empfänger“

Wird das Attribut weggelassen, gilt der Empfänger als primärer Empfänger.
 CONF
Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.29 ELGA_InformationRecipientType (DYNAMIC)
Treetree.pnghl7:intended​Recipient
1 … 1M(Hea...ent)
Treeblank.pngTreetree.pnghl7:id
II1 … *R

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

Zugelassene nullFlavor:

  • NI … Person hat keine ID
  • UNK ... Person hat eine ID, diese ist jedoch unbekannt
(Hea...ent)
 Beispiel<id nullFlavor="UNK" assigningAuthorityName="GDA Index"/>
Treeblank.pngTreetree.pnghl7:information​Recipient
1 … 1M

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

(Hea...ent)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ent)
Treeblank.pngTreetree.pnghl7:received​Organization
0 … 1

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

(Hea...ent)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ent)

7.1.8 Hauptunterzeichner (legalAuthenticator - generisch)

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

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

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

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

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

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 2 Konzepte
IdNameDatensatz
elgagab-data​element-79Kyellow.png Rechtlicher Unterzeichner Kyellow.png Datensatz
elgagab-data​element-87Kyellow.png Rechtlicher Unterzeichner Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90003InklusionKgreen.png AssignedEntityElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20006 HeaderLegalAuthenticator (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel
<legalAuthenticator>
  <!-- Zeitpunkt der Unterzeichnung -->
  <time value="20130324082015+0100"/>  <!-- Signaturcode -->
  <signatureCode code="S"/>  <!-- Personen- und Organisationsdaten des Rechtlichen Unterzeichners des Dokuments -->
  <assignedEntity>
    <!-- Identifikation des Rechtlichen Unterzeichners des Dokuments -->
    <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>    <!-- Kontaktdaten des Rechtlichen Unterzeichners des Dokuments -->
    <telecom use="WP" value="tel:+43.6138.3453446.2222"/>    <!-- Personendaten des Rechtlichen Unterzeichners des Dokuments -->
    <assignedPerson>
      <!-- Name des Rechtlichen Unterzeichners des Dokuments -->
      <name>
        <prefix>Univ.-Prof.Dr.</prefix>        <given>Sigrid</given>        <family>Kollmann</family>      </name>
    </assignedPerson>
    <!-- Organisation, in deren Auftrag der Rechtlichen Unterzeichners des Dokuments die Dokumentation unterzeichnet hat -->
    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <name>Amadeus Spital - Chirurgische Abteilung</name>      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="fax:+43.6138.3453446.4674"/>      <telecom value="mailto:info@amadeusspital.at"/>      <telecom value="http://www.amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>
    </representedOrganization>
  </assignedEntity>
</legalAuthenticator>
ItemDTKardKonfBeschreibungLabel
hl7:legalAuthenticator
Rechtlicher Unterzeichner.
(Hea...tor)
 
Target.png
elgagab-data​element-79Kyellow.png Rechtlicher Unterzeichner Kyellow.png Datensatz
elgagab-data​element-87Kyellow.png Rechtlicher Unterzeichner Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FLA
Treetree.pnghl7:time
TS.​DATE.​MIN1 … 1R
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

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

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

Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
(Hea...tor)
Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
Treeblank.pngTreetree.pnghl7:id
II1 … *R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1MPersondendaten der validierenden Person.
(Hea...tor)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...tor)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1Organistationsdaten der validierenden Person.
(Hea...tor)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...tor)

7.1.9 Weitere Unterzeichner (authenticator - generisch)

Id1.2.40.0.34.11.20007
ref
elgabbr-
Gültigkeit2011‑12‑19
Andere Versionen mit dieser Id:
  • Kblank.png HeaderAuthenticator vom 2018‑10‑18 14:33:54
StatusKyellow.png EntwurfVersions-Label
NameHeaderAuthenticatorAnzeigenameHeaderAuthenticator
Beschreibung
Dokumente können neben dem verpflichtenden legalAuthenticator („rechtlichen Unterzeichner“, Hauptunterzeichner) auch beliebig viele weitere Mitunterzeichner beinhalten.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-86Kyellow.png Weitere Unterzeichner Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90003InklusionKgreen.png AssignedEntityElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20007 HeaderAuthenticator (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel
<authenticator>
  <!-- Zeitpunkt der Unterzeichnung -->
  <time value="20130324081915+0100"/>  <!-- Signaturcode -->
  <signatureCode code="S"/>  <!-- Personen- und Organisationsdaten des Weiteren Unterzeichners des Dokuments -->
  <assignedEntity>
    <id root="1.2.40.0.34.99.111.1.3" extension="3333" assigningAuthorityName="Amadeus Spital"/>    <telecom use="WP" value="tel:+43.6138.3453446.3333"/>    <assignedPerson>
      <!-- Name des Weiteren Unterzeichners des Dokuments -->
      <name>
        <prefix>Dr.</prefix>        <given>Walter</given>        <family>Hummel</family>      </name>
    </assignedPerson>
    <!-- Organisation, in deren Auftrag der Weiteren Unterzeichner des Dokuments die Dokumentationunterzeichnet hat -->
    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      <name>Amadeus Spital - Chirurgische Abteilung</name>      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="fax:+43.6138.3453446.4674"/>      <telecom value="mailto:info@amadeusspital.at"/>      <telecom value="http://www.amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>
    </representedOrganization>
  </assignedEntity>
</authenticator>
Beispiel
Strukturbeispiel Laborbefund
<authenticator>
  <templateId root="1.3.6.1.4.1.19376.1.3.3.1.5"/>  <time value="20121201155300+0100"/>  <signatureCode code="S"/>  <assignedEntity>
    <id nullFlavor="NA"/>    <addr nullFlavor="NA"/>    <telecom value="tel: +43.1.12345678"/>    <assignedPerson>
      <name>
        <prefix qualifier="AC">Dr.</prefix>        <given>Otto</given>        <family>Rotadilav</family>      </name>
    </assignedPerson>
    <representedOrganization>
      <id root="1.2.40.0.34.3.1.999" assigningAuthorityName="EHSREG"/>      <name>Zentrallabor</name>      <telecom value="tel: +43.1.12345678"/>      <addr>
        <streetAddressLine>Laborplatz 1</streetAddressLine>        <city>Wien</city>        <postalCode>1200</postalCode>        <country>AUT</country>      </addr>
    </representedOrganization>
  </assignedEntity>
</authenticator>
ItemDTKardKonfBeschreibungLabel
hl7:authenticator
Weitere Unterzeichner.(Hea...tor)
 
Target.png
elgagab-data​element-86Kyellow.png Weitere Unterzeichner Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FAUTHEN
Treetree.pnghl7:time
TS.​DATE.​MIN1 … 1R
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Grundsätzlich sind die Vorgaben gemäß für „Zeit-Elemente“ zu befolgen.

Zugelassene nullFlavor: UNK
(Hea...tor)
Treetree.pnghl7:signatureCode
CS1 … 1M(Hea...tor)
Treeblank.pngTreetree.png@code
CONF1 … 1FS
Treetree.pnghl7:assignedEntity
1 … 1MPersonendaten des weiteren Unterzeichners.
Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen.

(Hea...tor)
Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
Treeblank.pngTreetree.pnghl7:id
II1 … *R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...tor)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1MPersondendaten der validierenden Person.
(Hea...tor)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...tor)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1Organistationsdaten der validierenden Person.
(Hea...tor)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...tor)

7.1.10 Hausarzt (participant - generisch)

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

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

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

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

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

(Hea...rzt)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...rzt)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation), zB die Arztpraxis oder Ordination.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.

(Hea...rzt)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...rzt)

7.1.11 Notfallkontakt (participant - generisch)

Id1.2.40.0.34.11.1.1.4
ref
elgabbr-
Gültigkeit2013‑11‑13
Andere Versionen mit dieser Id:
  • Kblank.png HeaderParticipantNotfallkontakt vom 2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantNotfallkontaktAnzeigenameHeaderParticipant Notfallkontakt
BeschreibungNotfall-Kontakt / Auskunftsberechtigte Person
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-105Kyellow.png Notfall-Kontakt Kyellow.png Datensatz
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.1.1.4 HeaderParticipant Notfallkontakt (2013‑11‑13)
ref
elgabbr-
Beispiel
Strukturbeispiel Notfallkontakt
<participant typeCode="IND">
  <templateId root="1.2.40.0.34.11.1.1.4"/>  <time>
    <low value="20170721102547"/>  </time>
  <associatedEntity classCode="ECON">
    <!-- Verwandtschaftsverhältnis des Notfallkontakts zum Patienten -->
    <code code="DAU" displayName="Natural daughter" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7:RoleCode"/>    <!-- Adresse des Notfall-Kontakts -->
    <addr>Heimstrasse 1, 1220 Wien</addr>    <!-- Kontaktdaten des Notfallkontakts -->
    <telecom value="tel:0660.1234567"/>    <associatedPerson>
      <!-- Name des Notfallkontakts -->
      <name>Julia Tochter</name>    </associatedPerson>
    <!-- Organisation des Notfallkontakts (z.B.: Behörde) -->
    <scopingOrganization>
      <name>Mustermann Installationen GmbH</name>    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Notfallkontakt / Auskunftsberechtigte Person).
(Hea...akt)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.4']]
 
Target.png
elgagab-data​element-105Kyellow.png Notfall-Kontakt Kyellow.png Datensatz
Treetree.png@typeCode
cs1 … 1FIND
Treetree.pnghl7:templateId
II1 … 1M(Hea...akt)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.4
Treetree.pnghl7:time
IVL_TS0 … 1

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


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


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

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

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

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

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

(Hea...akt)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...akt)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...akt)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...akt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...akt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...akt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...akt)

7.1.12 Angehörige (participant - generisch)

Id1.2.40.0.34.11.1.1.5
ref
elgabbr-
Gültigkeit2016‑07‑21
Andere Versionen mit dieser Id:
  • Kblank.png HeaderParticipantAngehoerige vom 2013‑11‑13
  • Kblank.png HeaderParticipantAngehoerige vom 2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantAngehoerigeAnzeigenameHeaderParticipant Angehörige
BeschreibungAls Angehörige sind in Österreich jene Personen anzusehen, welche in einem Verwandtschaftsverhältnis zum Patienten stehen, aber nicht unter die Gruppe der „Auskunftsberechtigten Personen“ fallen.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.1.1.5 HeaderParticipant Angehörige (2016‑07‑21)
ref
elgabbr-
Beispiel
Strukturbeispiel Angehörige
<participant typeCode="IND">
  <templateId root="1.2.40.0.34.11.1.1.5"/>  <associatedEntity classCode="PRS">
    <!-- Verwandtschaftsverhältnis des Angehörigen zum Patienten -->
    <code code="MTH" displayName="mother" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7: RoleCode"/>    <!-- Kontaktdaten des Angehörigen -->
    <addr/>    <telecom value="tel:0660.1234567"/>    <associatedPerson>
      <name>Herta Mutter</name>    </associatedPerson>
    <scopingOrganization/>  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Angehöriger).
(Hea...ige)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.5']]
Treetree.png@typeCode
cs1 … 1FIND
Treetree.pnghl7:templateId
II1 … 1M(Hea...ige)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.5
Treetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(Hea...ige)
Treeblank.pngTreetree.png@classCode
cs1 … 1FPRS
Treeblank.pngTreetree.pnghl7:code
CE1 … 1M

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

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

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


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

(Hea...ige)
Treeblank.pngTreetree.pnghl7:associated​Person
1 … 1MBeteiligte Person.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...ige)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ige)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1
Organisation, der der Beteiligte angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.

(Hea...ige)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...ige)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ige)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...ige)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ige)

7.1.13 Versicherung (participant - generisch)

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

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

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

Zugelassene nullFlavor:

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

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

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

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

(Hea...ung)
Treeblank.pngTreetree.pnghl7:associated​Person
0 … 1
Name des Beteiligten.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.
(Hea...ung)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ung)
 Schematron assertrole error 
 testhl7:code/@code!='FAMDEP' or count(hl7:associated​Person)=1 
 MeldungWenn das Versicherungsverhältnis "familienversichert" ist, dann muss eine associatedPerson angegeben sein 
Treeblank.pngTreetree.pnghl7:scoping​Organization
1 … 1R
Versicherungsgesellschaft.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...ung)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ung)

7.1.14 Betreuungsorganisation (participant - generisch)

Id1.2.40.0.34.11.1.1.7
ref
elgabbr-
Gültigkeit2013‑10‑16
StatusKgreen.png AktivVersions-Label
NameHeaderParticipantBetreuorgAnzeigenameHeaderParticipant Betreuungsorganisation
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-251Kyellow.png Betreuende Organisation Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.1.1.7 HeaderParticipant Betreuungsorganisation (2013‑10‑16)
ref
elgabbr-
Beispiel
Strukturbeispiel Betreuende Organisation
<participant typeCode="IND">
  <templateId root="1.2.40.0.34.11.1.1.7"/>  <associatedEntity classCode="CAREGIVER">
    <!-- Betreuende Organisation -->
    <scopingOrganization>
      <!-- Name der betreuenden Organisation -->
      <name>Altenpflegeheim Sorgenfrei</name>      <!-- Kontaktdaten der betreuenden Organisation -->
      <telecom value="tel:+43.1.3453446.0"/>      <telecom value="fax:+43.1.3453446.4674"/>      <telecom value="mailto:info@altenpflegeheim-sorgenfrei.at"/>      <telecom value="http://www.altenpflegeheim-sorgenfrei.at"/>      <!-- Adresse der betreuenden Organisation -->
      <addr>
        <streetName>Im schönen Walde</streetName>        <houseNumber>24</houseNumber>        <postalCode>2500</postalCode>        <city>Baden</city>        <state>Niederösterreich</state>        <country>AUT</country>      </addr>
    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Beteiligter (Betreuende Organisation).
(Hea...org)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.11.1.1.7']]
 
Target.png
elgagab-data​element-251Kyellow.png Betreuende Organisation Kyellow.png Datensatz
Treetree.png@typeCode
cs1 … 1FIND
Treetree.pnghl7:templateId
II1 … 1M(Hea...org)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.1.7
Treetree.pnghl7:associated​Entity
1 … 1MBeschreibung der Entität.
(Hea...org)
Treeblank.pngTreetree.png@classCode
cs1 … 1FCAREGIVER
Treeblank.pngTreetree.pnghl7:scoping​Organization
1 … 1M
Betreuende Organisation.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...org)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...org)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...org)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...org)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...org)

7.1.15 Gesundheitsdienstleistungen (Service Events)

Id1.2.40.0.34.11.13.1.2Gültigkeit2017‑07‑04 20:54:27
StatusKyellow.png EntwurfVersions-Label0.1
NameHeaderServiceEvent_PSAnzeigenameHeaderServiceEvent PS
Beschreibung
Mit dem Element documentationOf/serviceEvent werden normalerweise Gesundheitsdienstleistungen dokumentiert, die direkt mit dem Dokument in Zusammenhang stehen.
Das Patient Summary ist ein Übersichtsdokument, die relevante Gesundheitsdienstleistung ist die Erstellung des Patient Summary. Es wird hier dementsprechend ein fixer Wert eingetragen.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungAdaptation: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19)
ref
elgabbr-
Beispiel
Beispiel
<documentationOf typeCode="DOC">
  <serviceEvent classCode="PCPR" moodCode="EVN">
    <effectiveTime>
      <low value="20171108204616"/>      <high value="20171108204616"/>    </effectiveTime>
    <performer typeCode="cs">
      <functionCode/>      <time>
        <low value="20171108204616"/>      </time>
      <assignedEntity>
        <!-- include template 1.2.40.0.34.11.90003 'AssignedEntityElements' (dynamic) .. O -->
      </assignedEntity>
    </performer>
  </serviceEvent>
</documentationOf>
ItemDTKardKonfBeschreibungLabel
hl7:documentationOf
0 … *(Hea..._PS)
Treetree.png@typeCode
cs1 … 1FDOC
Treetree.pnghl7:serviceEvent
1 … 1MDas serviceEvent enthält die Art der Gesundheitsdienstleistung, im Fall des Patient Summary eine allgemeine Gesundheitsdienstleistung als festem Wert(Hea..._PS)
Treeblank.pngTreetree.png@classCode
cs0 … 1FPCPR
Treeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreetree.pnghl7:code
CE1 … 1MFixer Wert für die Gesundheitsdienstleistung(Hea..._PS)
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1FPATSUM
Treeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1FZusammenfassung von Patientendaten
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F1.2.40.0.34.10.208
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FELGA_ServiceEventPS_VS
Treeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS1 … 1MZeitraum der dokumentierten Gesundheitsdaten: 
  • Im "software-assembled" Patient Summary: die Zeitspanne vom ältesten Dokument bis zum jüngsten erfassten Dokument
  • Im "human curated" Patient Summary: die Zeitspanne, über die Informationen vorliegen.

(Hea..._PS)
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
TS1 … 1M(Hea..._PS)
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
TS1 … 1M(Hea..._PS)
Treeblank.pngTreetree.pnghl7:performer
NPEs wird hier keine durchführende Entität der Gesundheitsdienstleistung angegeben   (Hea..._PS)

7.1.16 Patientenkontakt (EncompassingEncounter - generisch)

Id1.2.40.0.34.11.20013
ref
elgabbr-
Gültigkeit2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeader​Encompassing​EncounterAnzeigenameHeader​Encompassing​Encounter
Beschreibung
Diese Klasse repräsentiert Informationen, in welchem Rahmen der Patientenkontakt, der dokumentiert wird, stattgefunden hat. Dokumente werden nicht notwendigerweise immer während eines Patientenkontakts erstellt, sondern ggf. auch zu einem späteren Zeitpunkt, wenn beispielsweise ein Arzt wegen eines pathologischen Laborwertes den Patienten vergeblich versucht zu erreichen und dennoch seine Verlaufsdokumentation fortführt.

Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, muss die Information in dieser Klasse mitgegeben werden, inklusive der Dauer des Aufenthalts (hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) und der Einrichtung, wo der Patientenaufenthalt stattfand.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-156Kyellow.png Patientenkontakt Kyellow.png Datensatz
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.40.0.34.11.90003InklusionKgreen.png AssignedEntityElementsDYNAMIC
1.2.40.0.34.11.90006InklusionKgreen.png Encounter Location 1DYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20013 Header​Encompassing​Encounter (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel
<componentOf>
  <encompassingEncounter>
    <!-- Aufenthaltszahl -->
    <id root="1.2.40.0.34.99.111.1.4" extension="Az123456" assigningAuthorityName="Amadeus Spital"/>    <!-- Codierung des Patientenkontakts -->
    <code code="IMP" displayName="Inpatient encounter" codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7:ActCode"/>    <!-- Zeitraum des Patientenkontakts -->
    <effectiveTime>
      <low value="20081224082015+0100"/>      <high value="20081225113000+0100"/>    </effectiveTime>
    <!-- Verantwortliche Person für den Patientenkontakt -->
    <responsibleParty>
      <assignedEntity>
        <!-- Identifikation der Verantwortlichen Person für den Patientenkontakt-->
        <id root="1.2.40.0.34.99.111.1.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>        <!-- Kontaktdaten der Verantwortlichen Person für den Patientenkontakt -->
        <telecom use="WP" value="tel:+43.6138.3453446.2222"/>        <!-- Personendaten der Verantwortlichen Person für den Patientenkontakt -->
        <assignedPerson>
          <!-- Name der Verantwortlichen Person für den Patientenkontakt -->
          <name>
            <prefix>Univ.-Prof.Dr.</prefix>            <given>Sigrid</given>            <family>Kollmann</family>          </name>
        </assignedPerson>
      </assignedEntity>
    </responsibleParty>
    <!-- Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand -->
    <location>
      <healthCareFacility>
        <serviceProviderOrganization>
          <!-- ID der Organisation aus dem GDA Index -->
          <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>          <!-- Name der Organisation -->
          <name>Amadeus Spital - Chirurgische Abteilung</name>          <!-- Kontaktdaten der Organisation -->
          <telecom value="tel:+43.6138.3453446.0"/>          <telecom value="fax:+43.6138.3453446.4674"/>          <telecom value="mailto:info@amadeusspital.at"/>          <telecom value="http://www.amadeusspital.at"/>          <!-- Adresse der Organisation -->
          <addr>
            <streetName>Mozartgasse</streetName>            <houseNumber>1-7</houseNumber>            <postalCode>5350</postalCode>            <city>St.Wolfgang</city>            <state>Salzburg</state>            <country>AUT</country>          </addr>
        </serviceProviderOrganization>
      </healthCareFacility>
    </location>
  </encompassingEncounter>
</componentOf>
ItemDTKardKonfBeschreibungLabel
hl7:componentOf
Komponente für den Patientenkontakt.
(Hea...ter)
 
Target.png
elgagab-data​element-156Kyellow.png Patientenkontakt Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FCOMP
Treetree.pnghl7:encompassing​Encounter
1 … 1RPatientenkontakt.
(Hea...ter)
Treeblank.pngTreetree.png@classCode
cs0 … 1FENC
Treeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreetree.pnghl7:id
II0 … 1Identifikationselement zur Aufnahme der Aufenthaltszahl.(Hea...ter)
Treeblank.pngTreetree.pnghl7:code
CE1 … 1MCodierung des Patientenkontakts.
(Hea...ter)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.5 ELGA_ActEncounterCode (DYNAMIC)
Treeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS1 … 1M
Zeitraum des Patientenkontakts.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(Hea...ter)
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
TS.​DATE.​MIN1 … 1R(Hea...ter)
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
TS.​DATE.​MIN0 … 1(Hea...ter)
Treeblank.pngTreetree.pnghl7:responsible​Party
0 … 1
Komponente für die verantwortliche Person.
(Hea...ter)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assignedEntity
1 … 1M
Entität der verantwortlichen Person.
Grundsätzlich sind die Vorgaben für „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
(Hea...ter)
Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1MPersondendaten der validierenden Person.
(Hea...ter)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1Organistationsdaten der validierenden Person.
(Hea...ter)
Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ter)
Eingefügt1 … 1M von 1.2.40.0.34.11.90006 Encounter Location 1 (DYNAMIC)
Treeblank.pngTreetree.pnghl7:location
1 … 1MKomponente Organisation.
(Hea...ter)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FLOC
 Beispiel<location typeCode="LOC">
  <healthCareFacility classCode="SDLOC">
    <!-- ... -->
  </healthCareFacility>
</location>
Treeblank.pngTreeblank.pngTreetree.pnghl7:health​Care​Facility
1 … 1M(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FSDLOC
 Beispiel<healthCareFacility classCode="SDLOC">
  <location classCode="PLC" determinerCode="INSTANCE">
    <!-- ... -->
  </location>
  <serviceProviderOrganization classCode="ORG" determinerCode="INSTANCE">
    <!-- ... -->
  </serviceProviderOrganization>
</healthCareFacility>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:service​Provider​Organization
1 … 1M
Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand.
Grundsätzlich sind die Vorgaben für „Organisations-Element“ zu befolgen.
(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
 Beispiel<serviceProviderOrganization classCode="ORG" determinerCode="INSTANCE">
  <name/>  <addr>
    <!-- ... -->
  </addr>
</serviceProviderOrganization>
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT1 … *M(Hea...ter)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1M(Hea...ter)

7.2 Fachlicher Inhalt (Sections)

7.2.1 Übersichtstabelle der Sections

Verwendete Abkürzungen
ÄB Ärztlicher Befund (generisch) (dieser Leitfaden)
ALF Allgemeiner Implementierungsleitfaden
EBÄ Entlassungsbrief Ärztlich
LAB Laborbefund
PS Patient Summary


Sektion bzw. Untersektion Optionalität Codierte Inhalte Codierte Daten dieser Sektion weitere Verwendung Kapitel
human curated software-assembled
Allergien und Intoleranzen [M] [M] [M] Link
Gesundheitsprobleme und Risiken [M] [M] [M] Link
Medikationsliste [M] [M] [M] Link
Medizinische Geräte und Implantate [M] [M] [M] Link
Impfungen [R] [R] [R] Link
Durchgeführte Eingriffe und Therapien [O] [R] [R] Link
Beeinträchtigungen [O] [O] [O] Link
Diagnostische Resultate [O] [O] [O] Link
Schwangerschaften [O] [R2] [O] Link
Lebensstil [O] [R2] [O] Link
Soziale Umstände und Verhalten [O] [NP] [NP] Link
Willenserklärungen und andere juridische Dokumente [O] [O] [O] Link
Weitere Informationen [O] [NP] [NP] Link
Liste der behandelnden GDA [O] [O] in ServiceEvents [O] in ServiceEvents Link


7.2.2 Allergien und Intoleranzen

Darstellungsbeispiel:

Auslösende Substanz Überempfindlichkeit
Metamizol Allergie
  • Bekannt seit 2013-04
  • Reaktion: Larynxödem (Schweregrad: mittel)
  • Lebensbedrohlich
  • Diagnosesicherheit: bestätigt
  • klinischer Status: bestehend
  • Informant: Eigenangabe des Patienten
  • Quelle: Ärztlicher Entlassungsbrief 2015-03-18 Amadeus Spital Salzburg
Erdnuss (Arachis hypogaea) Intoleranz
  • Bekannt seit 2002-12
  • Reaktion: Durchfall (Schweregrad: mittel)
  • Reaktion: Urtikaria (Schweregrad: schwer)
  • Nicht Lebensbedrohlich
  • Diagnosesicherheit: bestätigt
  • klinischer Status: bestehend
  • Informant: Eigenangabe des Patienten
  • Quelle: Ärztlicher Entlassungsbrief 2015-03-18 Amadeus Spital Salzburg
Pilze Überempfindlichkeit (keine weiteren Details)
Id1.2.40.0.34.11.13.2.1
ref
elgabbr-
Gültigkeit2016‑11‑10 20:39:16
StatusKyellow.png EntwurfVersions-Label0.1
NameAllergienUnvertraeglichkeitenAnzeigenameAllergien und Intoleranzen
Beschreibung
Diese Sektion enthält relevante Allergien oder Intoleranzen des Patienten.
Angegeben werden vorzugsweise die auslösende Substanz, die Art der Reaktion (Hautausschlag, Anaphylaxie, Erbrechen, ...), die Kritikalität sowie eine Angabe, wie gesichert die Information ist. Grundsätzlich sollen nur relevante Allergien und Intoleranzen angeführt werden. 
Wenn keine relevanten Allergien oder Intoleranzen vorliegen oder keine Information verfügbar ist, soll das klar erkennbar dokumentiert werden. Nicht relevante Intoleranzen oder Allergien sollen nicht angegeben werden. 
Alle enthaltenen Informationen MÜSSEN auch maschinenlesbar verfügbar sein, wenn keine Informationen vorliegen, ist das ebenfalls mit einem Code auszudrücken.
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.1
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 4 Templates
Benutzt als NameVersion
1.2.40.0.34.11.13.3.16ContainmentKyellow.png Author (Body) PSDYNAMIC
1.2.40.0.34.11.13.3.20ContainmentKyellow.png Informant (Body) PS (0.1)DYNAMIC
1.2.40.0.34.11.13.3.1ContainmentKyellow.png Allergien und Intoleranzen Entry (0.1)DYNAMIC
1.2.40.0.34.11.13.2.18ContainmentKyellow.png Übersetzung (0.1)DYNAMIC
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.13.2.1"/>  <code code="48765-2" codeSystem="2.16.840.1.113883.6.1"/>  <title>Allergien und Intoleranzen</title>  <text/>  <author>
    <!-- template 1.2.40.0.34.11.13.3.16 'Author (Body) PS' (dynamic) -->
  </author>
  <informant>
    <!-- template 1.2.40.0.34.11.13.3.20 'Informant (Body) PS' (dynamic) -->
  </informant>
  <entry typeCode="DRIV">
    <!-- template 1.2.40.0.34.11.13.3.1 'Allergien und Unverträglichkeiten Entry' (dynamic) -->
  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(All...ten)
Treetree.pnghl7:templateId
II1 … 1M(All...ten)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.13.2.1
Treetree.pnghl7:id
II0 … 1Eindeutige ID der Sektion (optional)(All...ten)
Treetree.pnghl7:code
CE (extensible)1 … 1M(All...ten)
Treeblank.pngTreetree.png@code
CONF1 … 1F48765-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(All...ten)
 CONF
Elementinhalt muss "Allergien und Intoleranzen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1MDer Text enthält relevante Allergien oder Intoleranzen des Patienten in tabellarischer Darstellung. (All...ten)
Treetree.pnghl7:author
0 … *Author der enthaltenen Information (GDA)
Beinhaltet 1.2.40.0.34.11.13.3.16 Author (Body) PS (DYNAMIC)
(All...ten)
Treetree.pnghl7:informant
0 … *Quelle der Information. Name der Person und ihre Beziehung zum Patienten (Patient oder Angehöriger, Auskunftsperson - nicht-GDA)
Beinhaltet 1.2.40.0.34.11.13.3.20 Informant (Body) PS (DYNAMIC)
(All...ten)
Treetree.pnghl7:entry
1 … *REnthält die codierte Angabe der Allergien und Intoleranzen
Beinhaltet 1.2.40.0.34.11.13.3.1 Allergien und Intoleranzen Entry (DYNAMIC)
(All...ten)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FDRIV
Treetree.pnghl7:component
0 … *Optionale Subsections zur Angabe von Übersetzungen des <text>  Elements </text>
Beinhaltet 1.2.40.0.34.11.13.2.18 Übersetzung (DYNAMIC)
(All...ten)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreetree.png@context​Conduction​Ind
cs0 … 1Ftrue

7.2.3 Gesundheitsprobleme und Risiken

In der Sektion werden relevante Gesundheitsprobleme des Patienten dokumentiert, die im Falle einer medizinischen Behandlung zu bedenken sind. Probleme umfassen Diagnosen, Symptome, Krankheiten und Risiken.

Art der Darstellung des lesbaren Textes: Tabellarische Darstellung ist vorgeschrieben. Vorschlag: 2-3 Spalten, eine Spalte ist der Name des Problems ("Orginaltext", zB der Diagnosetext, erwartet wird die bestmögliche Beschreibung, d.h. es muss nicht buchstabengetreu mit dem DisplayName des Codes übereinstimmen), in der zweiten Spalte werden alle dokumentierten Attribute aufgelistet, der Code selbst entweder in Spalte 2 oder in einer eigenen Spalte "Code". Die Angabe des Codesystems ist notwendig, da unterschiedliche Codesysteme gleichzeitig zum Einsatz kommen können.

Problem Zusatzinformation Code
Hitzewallungen (postmenopausal) ICD-10: N95.1
Invasiv duktales Karzinom der Brustdrüse, Stage II, ohne Anzeichen eines erneuten Auftretens nach Behandlung (Freitext)
  • Bekannt seit 2015-02
  • wird noch beobachtet
  • klin. Status: in Remission
  • Diagnosesicherheit: bestätigt
  • Schweregrad: schwerwiegend
ICD-O: 8500/3

Verwendung von Codes: Keiner oder einer bis viele Codes können pro Problem angegeben werden, siehe elga-cdaps-2.06.2: Grundsätze und Regeln . Im internationalen Austausch von PS kann nur der Code selbst übersetzt werden.

Risiken: Bisher war es nicht möglich, eine Liste mit relevanten Gesundheitsproblemen oder Risiko-Informationen österreichweit zu harmonisieren, dieser Punkt wird daher nicht weiter betrachtet.


Id1.2.40.0.34.11.13.2.2
ref
elgabbr-
Gültigkeit2017‑01‑26 13:50:54
StatusKyellow.png EntwurfVersions-Label0.1
NameGesundheitsproblemeRisikenAnzeigenameGesundheitsprobleme und Risiken
Beschreibung
Diese Sektion enthält alle zum Zeitpunkt der Erstellung bekannten relevanten Gesundheitsprobleme der Patienten. Dies umfasst akute Diagnosen, Dauerdiagnosen, Infektionskrankheiten sowie Risiken.
Eine Ausnahme bilden Allergien und Intoleranzen, diese MÜSSEN separat in der Sektion "Allergien_und_Intoleranzen" dokumentiert werden.
Status post-Diagnosen können ebenfalls in dieser Sektion erfasst werden, sofern sie für weitere Behandler relevant sind.
Gesundheitsprobleme & Risiken werden mit ihrem Status und Datum, sofern bekannt, dokumentiert, weiters mit dem Datum der Erfassung der Diagnose.
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.2
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 4 Templates
Benutzt als NameVersion
1.2.40.0.34.11.13.3.16ContainmentKyellow.png Author (Body) PSDYNAMIC
1.2.40.0.34.11.13.3.20ContainmentKyellow.png Informant (Body) PS (0.1)DYNAMIC
1.2.40.0.34.11.13.3.6ContainmentKyellow.png Gesundheitsproblem Bedenken Entry (0.2)DYNAMIC
1.2.40.0.34.11.13.2.18ContainmentKyellow.png Übersetzung (0.1)DYNAMIC
BeziehungAbgeleitet: Template 1.2.40.0.34.11.2.2.3 Entlassungsdiagnose (full support) (2015‑10‑15)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.13.2.2"/>  <code code="11450-4" codeSystem="2.16.840.1.113883.6.1"/>  <title>Gesundheitsprobleme und Risiken</title>  <text/>  <author>
    <!-- template 1.2.40.0.34.11.13.3.16 'Author (Body) PS' (dynamic) -->
  </author>
  <informant>
    <!-- template 1.2.40.0.34.11.13.3.20 'Informant (Body) PS' (dynamic) -->
  </informant>
  <entry typeCode="DRIV">
    <!-- template 1.2.40.0.34.11.13.3.6 'Gesundheitsproblem Bedenken Entry' (dynamic) -->
  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Ges...ken)
Treetree.pnghl7:templateId
II1 … 1M(Ges...ken)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.13.2.2
Treetree.pnghl7:id
II0 … 1Eindeutige ID der Sektion (optional)
(Ges...ken)
Treetree.pnghl7:code
CE (extensible)1 … 1M(Ges...ken)
Treeblank.pngTreetree.png@code
CONF1 … 1F11450-4
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Ges...ken)
 ConstraintFixer Wert: Gesundheitsprobleme und Risiken
Treetree.pnghl7:text
1 … 1M
Dieses Element enthält alle zum Zeitpunkt der Erstellung bekannten relevanten Gesundheitsprobleme der Patienten. Dies umfasst akute Diagnosen, Dauerdiagnosen, Infektionskrankheiten sowie Risiken in tabellarischer Darstellung.
Sie werden mit ihrem Status und Datum, sofern bekannt, dokumentiert, weiters mit dem Datum der Erfassung der Diagnose.
(Ges...ken)
Treetree.pnghl7:author
0 … *Autor der enthaltenen Information (GDA)

Beinhaltet 1.2.40.0.34.11.13.3.16 Author (Body) PS (DYNAMIC)
(Ges...ken)
Treetree.pnghl7:informant
0 … *
Quelle für die enthaltene Information
Name der Person und ihre Beziehung zum Patienten (Patient oder Angehöriger, Auskunftsperson - nicht-GDA)

Beinhaltet 1.2.40.0.34.11.13.3.20 Informant (Body) PS (DYNAMIC)
(Ges...ken)
Treetree.pnghl7:entry
1 … *MBeinhaltet 1.2.40.0.34.11.13.3.6 Gesundheitsproblem Bedenken Entry (DYNAMIC)(Ges...ken)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FDRIV
Treetree.pnghl7:component
Optionale Subsections zur Angabe von Übersetzungen des <text> Elements

Beinhaltet 1.2.40.0.34.11.13.2.18 Übersetzung (DYNAMIC)
(Ges...ken)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreetree.png@context​Conduction​Ind
cs0 … 1Ftrue

7.2.4 Medikationsliste

Diese Sektion entspricht inhaltlich der Medikationsliste der eMedikation, die Anzeige ist allerdings noch weiter komprimiert. Bei dieser verkürzten Darstellung werden die Abschnitte für Abgabe und Verordnung zusammengefasst und es wird immer NUR der neueste Eintrag angezeigt (immer die Abgabe, nur wenn eine Abgabe nicht erfolgte, die Verordnung). Die maschinenlesbaren Elemente sind dieselben wie in der eMedikation.

Arzneimittel Einnahme Dosierung Verordnet/Abgegeben Zusatzinformation Dauermedikation
Anastrozol 1 mg Tabletten täglich 1-0-0-0 zum Einnehmen D
Esomeprazol 40 mg magensaftresistente Tabletten täglich 1-0-1-0 01.05.2017 (Verordnung) zum Einnehmen
Cimicifugae racemosae radix (Trauben-Silberkerze - Extrakt) täglich 1-0-0-0 04.06.2017 (Abgabe) bei Bedarf
Id1.2.40.0.34.11.13.2.16
ref
elgabbr-
Gültigkeit2017‑11‑27 16:43:52
StatusKyellow.png EntwurfVersions-Label0.1
NameMedikationslistenSection_PSAnzeigenameMedikationsliste PS
Beschreibung
Die Medikationsliste enthält eine Zusammenfassung alle relevanten Informationen aus den „Verordnungen“, „Abgaben“ und „pharmazeutischen Empfehlungen“ der letzten 12 Monate.
Sie entspricht einer aggregierten Medikationsliste der ELGA e-Medikation mit den Daten über Medikament, Dosierung, Dauermedikation, Einnahmezeitraum.
Abgesetzte Medikamente sind nicht enthalten, diese Information kann aus der vollständigen Medikationsliste der e-Medikation entnommen werden. 
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.16
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 6 Templates
Benutzt als NameVersion
1.2.40.0.34.11.13.3.16ContainmentKyellow.png Author (Body) PSDYNAMIC
1.2.40.0.34.11.13.3.20ContainmentKyellow.png Informant (Body) PS (0.1)DYNAMIC
1.2.40.0.34.11.8.1.3.1ContainmentKyellow.png Medikation Verordnung Entry eMedikationDYNAMIC
1.2.40.0.34.11.8.2.3.1ContainmentKyellow.png Medikation Abgabe Entry eMedikationDYNAMIC
1.2.40.0.34.11.13.3.27ContainmentKyellow.png ELGA Medikationsstatement (0.1)DYNAMIC
1.2.40.0.34.11.13.2.18ContainmentKyellow.png Übersetzung (0.1)DYNAMIC
BeziehungAdaptation: Template 1.2.40.0.34.11.8.3.2.1 (2017‑08‑31 14:20:20)
ref
?
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.13.2.16"/>  <!-- Code der Sektion -->
  <code code="10160-0" codeSystem="2.16.840.1.113883.6.1"/>  <!-- Titel der Sektion -->
  <title>Medikationsliste</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text>  <!-- Maschinenlesbare Elemente -->
  <entry>
    <!-- ELGA MedikationVerordnung-Entry -->
    <templateId root="1.2.40.0.34.11.8.1.3.1"/>  </entry>
  <!-- und/oder -->
  <entry>
    <!-- ELGA MedikationAbgabe-Entry -->
    <templateId root="1.2.40.0.34.11.8.2.3.1"/>  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Med..._PS)
Treetree.pnghl7:templateId
II1 … 1M(Med..._PS)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.13.2.16
Treetree.pnghl7:id
II0 … 1(Med..._PS)
Treetree.pnghl7:code
CE (extensible)1 … 1M(Med..._PS)
Treeblank.pngTreetree.png@code
CONF1 … 1F10160-0
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Med..._PS)
 CONF
Elementinhalt muss "Medikationsliste" sein
Treetree.pnghl7:text
ED1 … 1MInformation für den menschlichen Leser.
(Med..._PS)
Treetree.pnghl7:author
0 … *Author der enthaltenen Information (GDA)
Beinhaltet 1.2.40.0.34.11.13.3.16 Author (Body) PS (DYNAMIC)
(Med..._PS)
Treetree.pnghl7:informant
0 … *
Quelle für die enthaltene Information
Name der Person und ihre Beziehung zum Patienten (Patient oder Angehöriger, Auskunftsperson - nicht-GDA)

Beinhaltet 1.2.40.0.34.11.13.3.20 Informant (Body) PS (DYNAMIC)
(Med..._PS)
Auswahl1 … *Elemente in der Auswahl:
  • hl7:entry welches enthält Template 1.2.40.0.34.11.8.1.3.1 Medikation Verordnung Entry eMedikation (DYNAMIC)
  • hl7:entry welches enthält Template 1.2.40.0.34.11.8.2.3.1 Medikation Abgabe Entry eMedikation (DYNAMIC)
  • hl7:entry welches enthält Template 1.2.40.0.34.11.13.3.27 ELGA Medikationsstatement (DYNAMIC)
  • hl7:component welches enthält Template 1.2.40.0.34.11.13.2.18 Übersetzung (DYNAMIC)
Treeblank.pngTreetree.pnghl7:entry
Beinhaltet 1.2.40.0.34.11.8.1.3.1 Medikation Verordnung Entry eMedikation (DYNAMIC)(Med..._PS)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FDRIV
Treeblank.pngTreetree.pnghl7:entry
Beinhaltet 1.2.40.0.34.11.8.2.3.1 Medikation Abgabe Entry eMedikation (DYNAMIC)(Med..._PS)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FDRIV
Treeblank.pngTreetree.pnghl7:entry
Beinhaltet 1.2.40.0.34.11.13.3.27 ELGA Medikationsstatement (DYNAMIC)(Med..._PS)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FDRIV
Treeblank.pngTreetree.pnghl7:component
0 … *Optionale Subsections zur Angabe von Übersetzungen des <text> Elements

Beinhaltet 1.2.40.0.34.11.13.2.18 Übersetzung (DYNAMIC)
(Med..._PS)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
cs0 … 1Ftrue

7.2.5 Medizinische Geräte und Implantate

Diese Sektion enthält alle relevanten Informationen zu medizinischen Geräten und Implantaten wie Gerätetyp, Datum der Einsetzung, Lokalisation, Handelsname, Hersteller, Chargennummer. Die Codierung der medizinischen Gerätetypen ist noch nicht fixiert, soll aber dem EU UDI System (EU Medical Device Regulations) entsprechen.

Gerät / Implantat Seit Seriennummer Zusatzinformation
Cochlea-Implantat 2015 UDI HIBCC: Serial# XYZ456789012345678, Lot# LOT123456789012345 Li
Endoprothese Mai 2017 Hemi-Endoprothese
Id1.2.40.0.34.11.13.2.4
ref
elgabbr-
Gültigkeit2017‑02‑26 11:36:47
StatusKyellow.png EntwurfVersions-Label0.1
NameImplantateAnzeigenameMedizinische Geräte und Implantate
Beschreibung
Diese Sektion enthält Informationen über intra- und extrakorporale Medizinprodukte oder Medizingeräte, von denen der Gesundheitszustand des Patienten direkt abhängig ist. Das umfasst z.B. Implantate, Prothesen, Pumpen, Herzschrittmacher etc. von denen ein GDA Kenntnis haben soll.
Heilbehelfe wie Gehhilfen, Rollstuhl etc sind nicht notwendigerweise anzuführen.
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.4
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgaps-data​element-12Kyellow.png Medizinische Geräte & Implantate Kyellow.png Patient Summary
Benutzt
Benutzt 4 Templates
Benutzt als NameVersion
1.2.40.0.34.11.13.3.16ContainmentKyellow.png Author (Body) PSDYNAMIC
1.2.40.0.34.11.13.3.20ContainmentKyellow.png Informant (Body) PS (0.1)DYNAMIC
1.2.40.0.34.11.13.3.8ContainmentKyellow.png ELGA Medical Device (0.1)DYNAMIC
1.2.40.0.34.11.13.2.18ContainmentKyellow.png Übersetzung (0.1)DYNAMIC
BeziehungAbgeleitet: Template 1.3.6.1.4.1.12559.11.10.1.3.1.2.4 Section Medical Devices Coded (2013‑12‑20)
ref
epsos-
Beispiel
Implantat vorhanden
<section>
  <templateId root="1.2.40.0.34.11.13.2.4"/>  <id root="1.2.3.999" extension="--example only--"/>  <code code="46264-8" codeSystem="2.16.840.1.113883.6.1"/>  <title>Medizinische Geräte und Implantate</title>  <text>
    <table>
      <thead>
        <tr>
          <th styleCode="xELGA_colw:30">Gerät / Implantat</th>          <th styleCode="xELGA_colw:10">Seit</th>          <th styleCode="xELGA_colw:30">Seriennummer</th>          <th>Zusatzinformation</th>        </tr>
      </thead>
      <tbody>
        <tr ID="al-1">
          <td>
            <content styleCode="xELGA_blue">Transgingiviales Implantat</content>          </td>
          <td>2015</td>          <td>UDI HIBCC: Serial# XYZ456789012345678, Lot# LOT123456789012345</td>          <td>M2 rechts oben</td>        </tr>
      </tbody>
    </table>
  </text>
  <author>
    <!-- template 1.2.40.0.34.11.13.3.16 'Author (Body) PS' (dynamic) -->
  </author>
  <informant>
    <!-- template 1.2.40.0.34.11.13.3.20 'Informant (Body) PS' (dynamic) -->
  </informant>
  <entry>
    <!-- template 1.2.40.0.34.11.13.3.8 'ELGA Medical Device' (dynamic) -->
  </entry>
</section>
Beispiel
Keine medizinischen Geräte oder Implantate
<section>
  <templateId root="1.2.40.0.34.11.13.2.4"/>  <id root="1.2.3.999" extension="--example only--"/>  <code code="46264-8" codeSystem="2.16.840.1.113883.6.1"/>  <title>Medizinische Geräte und Implantate</title>  <text>
    <table>
      <tbody>
        <tr ID="al-3">
          <td>
            <content styleCode="Bold">Kein medizinisches Gerät / kein Implantat in Situ</content>          </td>
        </tr>
      </tbody>
    </table>
  </text>
  <author>
    <!-- template 1.2.40.0.34.11.13.3.16 'Author (Body) PS' (dynamic) -->
  </author>
  <informant>
    <!-- template 1.2.40.0.34.11.13.3.20 'Informant (Body) PS' (dynamic) -->
  </informant>
  <entry>
    <!-- template 1.2.40.0.34.11.13.3.8 'ELGA Medical Device' (dynamic) -->
  </entry>
</section>
Beispiel
Keine Information über medizinische Geräte oder Implantate
<section>
  <templateId root="1.2.40.0.34.11.13.2.4"/>  <id root="1.2.3.999" extension="--example only--"/>  <code code="46264-8" codeSystem="2.16.840.1.113883.6.1"/>  <title>Medizinische Geräte und Implantate</title>  <text>
    <table>
      <tbody>
        <tr ID="al-3">
          <td>
            <content styleCode="Bold">Keine Information über medizinische Geräte oder Implantate verfügbar</content>          </td>
        </tr>
      </tbody>
    </table>
  </text>
  <author>
    <!-- template 1.2.40.0.34.11.13.3.16 'Author (Body) PS' (dynamic) -->
  </author>
  <informant>
    <!-- template 1.2.40.0.34.11.13.3.20 'Informant (Body) PS' (dynamic) -->
  </informant>
  <entry>
    <!-- template 1.2.40.0.34.11.13.3.8 'ELGA Medical Device' (dynamic) -->
  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Imp...ate)
 
Target.png
elgaps-data​element-12Kyellow.png Medizinische Geräte & Implantate Kyellow.png Patient Summary
Treetree.pnghl7:templateId
II1 … 1M(Imp...ate)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.13.2.4
Treetree.pnghl7:id
II0 … 1Eindeutige ID der Sektion (optional)
(Imp...ate)
Treetree.pnghl7:code
CE (extensible)1 … 1M(Imp...ate)
Treeblank.pngTreetree.png@code
CONF1 … 1F46264-8
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Imp...ate)
 CONF
Elementinhalt muss "Medizinische Geräte und Implantate" sein
Treetree.pnghl7:text
SD.TEXT1 … 1MDieses Element enthält die intra- und extrakorporale Medizinprodukte oder Medizingeräte, von denen der Gesundheitszustand des Patienten direkt abhängig ist, in tabellarischer Darstellung. (Imp...ate)
Treetree.pnghl7:author
0 … *Author der enthaltenen Information (GDA)

Beinhaltet 1.2.40.0.34.11.13.3.16 Author (Body) PS (DYNAMIC)
(Imp...ate)
Treetree.pnghl7:informant
0 … *
Quelle für die enthaltene Information
Name der Person und ihre Beziehung zum Patienten (Patient oder Angehöriger, Auskunftsperson - nicht-GDA)

Beinhaltet 1.2.40.0.34.11.13.3.20 Informant (Body) PS (DYNAMIC)
(Imp...ate)
Treetree.pnghl7:entry
1 … *RBeinhaltet 1.2.40.0.34.11.13.3.8 ELGA Medical Device (DYNAMIC)(Imp...ate)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FDRIV
Treetree.pnghl7:component
0 … *Optionale Subsections zur Angabe von Übersetzungen des <text> Elements

Beinhaltet 1.2.40.0.34.11.13.2.18 Übersetzung (DYNAMIC)
(Imp...ate)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreetree.png@context​Conduction​Ind
cs0 … 1Ftrue

7.2.6 Impfungen

Bekannte Impfungen des Patienten.

Darstellungsvorschlag:

Impfung Teilimpfung Datum der letzten Verabreichung Impfstoff-Handelsname & Chargennummer Datenquelle
Poliomyelitis-Impfstoff Unbekannt Patientenangabe
Masern, Mumps, Röteln-Impfstoff Unbekannt Patientenangabe
FMSE-Impfstoff 1987 FSME-IMMUN Patientenangabe
Tollwut (Rabies)-Impfstoff 2014-11-05 Rabipur eImpfpass
Typhus-Impfstoff 2017-07-17 Typherix (GSK) ChargenNr. 2349043057 eImpfpass
Gelbfieber-Impfstoff 2016-05-07 Stamaril ChargenNr: AD978987623-37 eImpfpass
Impfstoff aus Value Set # Datum der Verabreichung [O] Präparat und ChargenNr Datenquelle - Informant

Anmerkung:

  • Darstellung des Teilimpfungsvermerks?
  • Es sollen die Daten aus dem e-Impfpass übernommen werden können.


Id1.2.40.0.34.11.13.2.7Gültigkeit2017‑03‑11 18:38:41
StatusKyellow.png EntwurfVersions-Label0.1
NameImpfungenAnzeigenameImpfungen
Beschreibung
Diese Sektion enthält eine Beschreibung der Impfungen, die dem Patienten bisher verabreicht wurden. 
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.7
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 2 Konzepte
IdNameDatensatz
elgagab-data​element-199Kyellow.png Impfungen Kyellow.png Datensatz
elgaps-data​element-13Kyellow.png Impfungen Kyellow.png Patient Summary
Benutzt
Benutzt 4 Templates
Benutzt als NameVersion
1.2.40.0.34.11.13.3.16ContainmentKyellow.png Author (Body) PSDYNAMIC
1.2.40.0.34.11.13.3.20ContainmentKyellow.png Informant (Body) PS (0.1)DYNAMIC
1.2.40.0.34.11.13.3.9ContainmentKyellow.png Impfungsentry (0.1)DYNAMIC
1.2.40.0.34.11.13.2.18ContainmentKyellow.png Übersetzung (0.1)DYNAMIC
BeziehungAbgeleitet: Template 2.16.840.1.113883.10.20.1.6 (DYNAMIC)
Abgeleitet: Template 1.3.6.1.4.1.19376.1.5.3.1.3.23 (2013‑12‑20)
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.13.2.7"/>  <id root="1.2.3.999" extension="--example only--"/>  <code code="11369-6" codeSystem="2.16.840.1.113883.6.1"/>  <title>Impfungen</title>  <text/>  <author>
    <!-- template 1.2.40.0.34.11.13.3.16 'Author (Body) PS' (dynamic) -->
  </author>
  <informant>
    <!-- template 1.2.40.0.34.11.13.3.20 'Informant (Body) PS' (dynamic) -->
  </informant>
  <entry typeCode="DRIV">
    <!-- template 1.2.40.0.34.11.13.3.9 'Impfungsentry' (dynamic) -->
  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Imp...gen)
 
Target.png
elgagab-data​element-199Kyellow.png Impfungen Kyellow.png Datensatz
elgaps-data​element-13Kyellow.png Impfungen Kyellow.png Patient Summary
Treetree.pnghl7:templateId
II1 … 1M(Imp...gen)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.13.2.7
Treetree.pnghl7:id
II0 … 1Eindeutige ID der Sektion (optional)
(Imp...gen)
Treetree.pnghl7:code
CE (extensible)1 … 1M(Imp...gen)
Treeblank.pngTreetree.png@code
CONF1 … 1F11369-6
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1MImpfungen(Imp...gen)
 CONF
Elementinhalt muss "Impfungen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1MIn diesem Element erfolgt die narrative Beschreibung der Impfungen, die der Patient erhalten hat in tabellarischer Form.(Imp...gen)
Treetree.pnghl7:author
0 … *Author der enthaltenen Information (GDA)

Beinhaltet 1.2.40.0.34.11.13.3.16 Author (Body) PS (DYNAMIC)
(Imp...gen)
Treeblank.png wo [hl7:assignedAuthor]
Treetree.pnghl7:informant
0 … *
Quelle für die enthaltene Information
Name der Person und ihre Beziehung zum Patienten (Patient oder Angehöriger, Auskunftsperson - nicht-GDA)

Beinhaltet 1.2.40.0.34.11.13.3.20 Informant (Body) PS (DYNAMIC)
(Imp...gen)
Treetree.pnghl7:entry
0 … *Beinhaltet 1.2.40.0.34.11.13.3.9 Impfungsentry (DYNAMIC)(Imp...gen)
Treeblank.png wo [hl7:substanceAdministration [hl7:code [(@code = 'IMMUNIZ' and @codeSystem = '2.16.840.1.113883.5.4')]]]
Treeblank.pngTreetree.png@typeCode
cs0 … 1FDRIV
Treetree.pnghl7:component
0 … *Optionale Subsections zur Angabe von Übersetz