This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. This article was last edited by Sabutsch(talk| contribs) 6 years ago.Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. This article was last edited by Sabutsch(talk| contribs) 6 years ago.
HL7 Implementation Guide for CDA® R2: Patient Summary
Zur Anwendung im österreichischen Gesundheitswesen [1.2.40.0.34.7.16.1]
09. Jänner 2018
V0.4
Ballot-Version
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
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 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.
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 Implementierungsleitfaden, 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 Rechtordnung 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)
Review-Beiträge von:
- noch keine Reviews -
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.
Die Vorgaben für das Österreichische Patient Summary wurden weitgehend aus dem HL7 Leitfaden für das Internationale Patient Summary entlehnt (HL7 IPS).
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.
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
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 sich 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 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. Diese Übersicht wurde automatisch von einem Computerprogramm zusammengestellt, dabei wurden nur 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
Dieser Dokument spezifiziert eine HL7 CDA R2 Implementierung, ist aber in den Grundzügen kompatibel mit dem 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 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 Mindeststruktur, 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, ... ) 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 nicht genutzt. 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 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
die Information nicht mit den im Leitfaden zugelassenen Terminologien (Value Sets) dargestellt werden kann oder
die Information in keiner bekannten Terminologie enthalten ist.
Diese erste Situation wird mit dem folgenden Beispiel verdeutlicht.
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:
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 de coding strength CNE (coded no extensions) angegeben ist, wird der nullFlavor "OTH" verwendet; bei coding strength CWE (coded with extensions) der nullFlavor "NI".
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.
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
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.
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, ...) 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.
Datum und Uhrzeit mit Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM
Ist nur eine 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 2013 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:
ELGA TemplateId für den Allgemeinen Implementierungsleitfaden
(Hea...sPS)
@root
uid
1 … 1
F
1.2.40.0.34.11.1
hl7:templateId
II
1 … 1
M
ELGA TemplateId für das ELGA Patient Summary
(Hea...sPS)
@root
uid
1 … 1
F
1.2.40.0.34.11.13
hl7:id
II
1 … 1
M
DokumentenId. Für jedes Dokument und jede Version eines Dokumentsets eindeutig.
(Hea...sPS)
hl7:code
CD (extensible)
1 … 1
M
Klassifikation des Dokuments
(Hea...sPS)
@code
CONF
1 … 1
F
60591-0
@codeSystem
1 … 1
F
2.16.840.1.113883.6.1 (Logical Observation Identifier Names and Codes)
@codeSystemName
1 … 1
F
LOINC
@displayName
1 … 1
F
Patient Summary
hl7:title
ST
1 … 1
M
Dokumententitel
(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_TS
1 … 1
M
(Hea...sPS)
hl7:confidentialityCode
CE (extensible)
1 … 1
M
Klassifizierung der Vertraulichkeit
(Hea...sPS)
@code
CONF
1 … 1
F
N
@codeSystem
1 … 1
F
2.16.840.1.113883.5.25 (Confidentiality)
@codeSystemName
1 … 1
F
HL7:Confidentiality
@displayName
1 … 1
F
normal
hl7:languageCode
CS (erforderlich)
1 … 1
M
Sprachcode des Dokuments
(Hea...sPS)
@code
CONF
1 … 1
F
de-AT
hl7:setId
II
1 … 1
M
Eindeutige Id des Dokumentensets
(Hea...sPS)
hl7:versionNumber
INT
1 … 1
M
Versionsnummer des Dokuments
(Hea...sPS)
@value
int
1 … 1
R
Versionsnummer als positive ganze Zahl
7.1.3 Patient (recordTarget)
Id
1.2.40.0.34.11.20001
Gültigkeit
gültig ab 2017‑07‑20Es gibt Versionen von Templates mit dieser Id:
HeaderRecordTarget vom 2017‑07‑20
HeaderRecordTarget vom 2017‑03‑27
HeaderRecordTarget vom 2013‑10‑08
Status
Entwurf
Versions-Label
Name
HeaderRecordTarget
Anzeigename
HeaderRecordTarget
Beschreibung
Das RecordTarget-Element enthält den Patienten: Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw über deren Gesundheitsdaten im Dokument berichtet wird.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 2 Templates, Benutzt 1 Template
<recordTargettypeCode="RCT"contextControlCode="OP"> <patientRoleclassCode="PAT"> <!-- lokale Patienten ID vom System --> <idroot="1.2.40.0.34.99.111.1.2"extension="4711"assigningAuthorityName="Amadeus Spital"/><!-- Sozialversicherungsnummer des Patienten --> <idroot="1.2.40.0.10.1.4.3.1"extension="1111241261"assigningAuthorityName="Österreichische Sozialversicherung"/><!-- Adresse des Patienten --> <addruse="H"> <streetName>Musterstraße</streetName><houseNumber>13a</houseNumber><postalCode>7000</postalCode><city>Eisenstadt</city><state>Burgenland</state><country>AUT</country></addr><!-- Kontaktdaten des Patienten--> <telecomvalue="tel:+43.1.40400"use="H"/><telecomvalue="tel:+43.664.1234567"use="MC"/><telecomvalue="mailto:herbert.mustermann@provider.at"/><!-- Name des Patienten --> <patientclassCode="PSN"determinerCode="INSTANCE"> <name> <prefixqualifier="AC">Dipl.Ing.</prefix><given>Herbert</given><given>Hannes</given><family>Mustermann</family><familyqualifier="BR">VorDerHeirat</family><suffixqualifier="AC">BSc</suffix><suffixqualifier="AC">MBA</suffix></name><!-- Geschlecht des Patienten --> <administrativeGenderCodecode="M"displayName="Male"codeSystem="2.16.840.1.113883.5.1"codeSystemName="HL7:AdministrativeGender"/><!-- Geburtsdatum des Patienten --> <birthTimevalue="19701224"/><!-- Familienstand des Patienten --> <maritalStatusCodecode="D"displayName="Divorced"codeSystem="2.16.840.1.113883.5.2"/><!-- Religionszugehörigkeit des Patienten --> <religiousAffiliationCodecode="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)--> <telecomuse="H"value="tel:+43.2236.2928"/><telecomuse="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) --> <telecomuse="MC"value="tel:+43.676.1234567"/><telecomuse="H"value="tel:+43.316.717.653.9939"/><telecomuse="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
<recordTargettypeCode="RCT"contextControlCode="OP"> <patientRoleclassCode="PAT"> <!-- lokale Patienten ID vom System --> <idroot="1.2.40.0.34.99.111.1.2"extension="4711"/><!-- Name des Patienten --> <patientclassCode="PSN"determinerCode="INSTANCE"> <name> <given>Herbert</given><family>Mustermann</family></name><!-- Geschlecht des Patienten --> <administrativeGenderCodecode="M"codeSystem="2.16.840.1.113883.5.1"/><!-- Geburtsdatum des Patienten --> <birthTimevalue="19701224"/></patient></patientRole></recordTarget>
Beispiel
Minimalbeispiel 2
<recordTarget> <patientRole> <!-- lokale Patienten ID --> <idroot="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 --> <administrativeGenderCodenullFlavor="UNK"/><!-- Geburtsdatum des Patienten --> <birthTimenullFlavor="UNK"/></patient></patientRole></recordTarget>
bPK-GH des Patienten: Bereichskürzel + bPK (Base64,28 Zeichen)
<idroot="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-->
hl7:addr
AD
0 … 1
Adresse des Patienten.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...get)
hl7:streetAddressLine
0 … 1
(Hea...get)
hl7:streetName
0 … 1
(Hea...get)
hl7:houseNumber
0 … 1
(Hea...get)
Schematron assert
role
error
test
hl7:streetAddressLine or (hl7:streetName and hl7:houseNumber)
Meldung
Granularitätsstufen Adresse beachten: streetAddressLine oder streetName+houseNumber
hl7:postalCode
1 … 1
M
(Hea...get)
hl7:city
1 … 1
M
(Hea...get)
hl7:state
0 … 1
C
(Hea...get)
hl7:country
1 … 1
M
(Hea...get)
hl7:additionalLocator
0 … 1
(Hea...get)
hl7:telecom
TEL.AT
0 … *
Kontaktdaten des Patienten.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...get)
hl7:patient
0 … 1
(Hea...get)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name des Patienten.
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea...get)
hl7:prefix
0 … *
(Hea...get)
hl7:given
1 … *
M
(Hea...get)
hl7:family
1 … *
M
(Hea...get)
hl7:suffix
0 … *
(Hea...get)
hl7:administrativeGenderCode
CE
1 … 1
R
Codierung des Geschlechts des Patienten.
Zugelassene nullFlavor: UNK
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)
hl7:birthTime
TS.DATE.MIN
1 … 1
R
Geburtsdatum des Patienten.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
Zugelassene nullFlavor: UNK
(Hea...get)
hl7:maritalStatusCode
CE
0 … 1
Codierung des Familienstands des Patienten.
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC)
hl7:religiousAffiliationCode
CE
0 … 1
Codierung des Religionsbekenntnisses des Patienten.
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC)
hl7:raceCode
NP
Rasse des Patienten
Darf nicht verwendet werden!
(Hea...get)
hl7:ethnicGroupCode
NP
Ethnische Zugehörigkeit des Patienten. Darf nicht verwendet werden!
Die Adresse des gesetzlichen Vertreters oder der Organisation.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
(Hea...get)
hl7:telecom
TEL.AT
0 … *
Beliebig viele Kontaktdatendes gesetzlichen Vertreters oder der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(Hea...get)
Auswahl
1 … 1
Elemente in der Auswahl:
hl7:guardianPerson
hl7:guardianOrganization
hl7:guardianPerson
… 1
Name des des gesetzlichen Vertreters (Person).
(Hea...get)
hl7:name
PN
1 … 1
M
Name der Person.
(Hea...get)
hl7:guardianOrganization
… 1
Name des des gesetzlichen Vertreters (Organisation).
(Hea...get)
hl7:name
ON
1 … 1
M
Name der Organisation.
(Hea...get)
hl7:birthplace
0 … 1
Geburtsort des Patienten.
(Hea...get)
hl7:place
1 … 1
M
(Hea...get)
hl7:addr
AD
1 … 1
M
Die Adresse des Geburtsorts.
Grundsätzlich sind die Vorgaben
gemäß „Adress-Elemente“ für
Granularitätsstufe 1 zu befolgen.
Granularitätsstufe 2 oder 3 ist auch bei EIS Enhanced und Full Support nicht erforderlich.
(Hea...get)
Eingefügt
von 1.2.40.0.34.11.90017 Language Communication (DYNAMIC)
hl7:languageCommunication
0 … *
Komponente zur Angabe der Sprachfähigkeiten des Patienten.
(Hea...get)
hl7:languageCode
CS
0 … 1
Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.173 ELGA_HumanLanguage (DYNAMIC)
hl7:modeCode
CE
0 … 1
Ausdrucksform der Sprache. @codeSystem Fester Wert: 2.16.840.1.113883.5.60
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)
hl7:proficiencyLevelCode
CE
0 … 1
Grad der Sprachkenntnis in der Sprache. @codeSystem Fester Wert: 2.16.840.1.113883.5.61
(Hea...get)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC)
hl7:preferenceInd
BL
0 … 1
Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.
(Hea...get)
7.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.
Mit der Assoziation documentationOf/serviceEvent werden dem Vorschlag vom IPS folgend die für das Wohl des Patienten vollständig oder teilweise zuständigen GDAs aufgelistet. Im Fall eines manuell erstellten CDAs kann der aktuelle Patientenkontakt angegeben werden.
Klassifikation
CDA Header Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 1 Template
<documentationOftypeCode="DOC"> <serviceEventclassCode="PCPR"moodCode="EVN"> <effectiveTime> <lowvalue="20171108204616"/><highvalue="20171108204616"/></effectiveTime><performertypeCode="cs"> <functionCode/><time> <lowvalue="20171108204616"/></time><assignedEntity> <!-- include template 1.2.40.0.34.11.90003 'AssignedEntityElements' (dynamic) .. O --> </assignedEntity></performer></serviceEvent></documentationOf>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:documentationOf
0 … *
Dem Vorschlag vom IPS folgend dokumentiert dieses Element die für das Wohl des Patienten vollständig oder teilweise zuständigen GDAs
(Hea..._PS)
@typeCode
cs
1 … 1
F
DOC
hl7:serviceEvent
1 … 1
M
Das serviceEvent enthält die Art der Gesundheitsdienstleistung, im Fall des Patient Summary eine allgemeine Gesundheitsdienstleistung als festem Wert
(Hea..._PS)
@classCode
cs
0 … 1
F
PCPR
@moodCode
cs
0 … 1
F
EVN
hl7:effectiveTime
IVL_TS
1 … 1
M
Zeitraum des Patientenkontakts, z.B. Aufnahme - Entlassung
(Hea..._PS)
hl7:low
TS
1 … 1
M
(Hea..._PS)
hl7:high
TS
1 … 1
M
(Hea..._PS)
hl7:performer
1 … *
M
Der GDA, der an der aktuellen oder fortbestehenden Betreuung des Patienten beteiligt ist.
(Hea..._PS)
@typeCode
cs
1 … 1
R
CONF
Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.43 ELGA_ServiceEventPerformer (DYNAMIC)
hl7:functionCode
CE (extensible)
0 … 1
R
Funktionscode des GDA
(Hea..._PS)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
hl7:time
IVL_TS
0 … 1
Zeitraum des Patientenkontakts für diesen performer, wenn unterschiedlich zur effectiveTime außen Ist kein Zeitraum angegeben, wird angenommen, dass die Zeiten gleich sind.
(Hea..._PS)
hl7:assignedEntity
1 … 1
M
(Hea..._PS)
Eingefügt
von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
hl7:id
II
1 … *
R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea..._PS)
hl7:addr
AD
0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea..._PS)
hl7:telecom
TEL.AT
0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea..._PS)
hl7:assignedPerson
1 … 1
M
Persondendaten der validierenden Person.
(Hea..._PS)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend
Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Hea..._PS)
hl7:representedOrganization
0 … 1
Organistationsdaten der validierenden Person.
(Hea..._PS)
Eingefügt
von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
Diese Sektion enthält relevante Allergien oder Intoleranzen des Patienten. Angegeben werden die Art der Reaktion (Hautausschlag, Anaphylaxie, Erbrechen, ...), vorzugsweise die auslösende Substanz, 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.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.1
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 3 Templates
Elementinhalt muss "Allergien und Intoleranzen" sein
hl7:text
SD.TEXT
1 … 1
M
Der Text enthält relevante Allergien oder Intoleranzen des Patienten in tabellarischer Darstellung.
(All...ten)
hl7:author
0 … *
Author der enthaltenen Information (GDA) Beinhaltet 1.2.40.0.34.11.13.3.16 Author (Body) PS (DYNAMIC)
(All...ten)
hl7: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)
hl7:entry
1 … *
R
Enthä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)
wo [hl7:act [hl7:templateId [@root='1.2.40.0.34.11.13.3.1']]]
@typeCode
cs
0 … 1
F
DRIV
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-0: 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.
Hinweis: Man könnte den Umgang mit codierten Diagnosen in Norwegen oder Dänemark recherchieren und daraus lernen
Id
1.2.40.0.34.11.13.2.2
Gültigkeit
gültig ab 2017‑01‑26 13:50:54
Status
Entwurf
Versions-Label
0.1
Name
GesundheitsproblemeRisiken
Anzeigename
Gesundheitsprobleme 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.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.2
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 3 Templates
2.16.840.1.113883.6.1 (Logical Observation Identifier Names and Codes)
@codeSystemName
1 … 1
F
LOINC
@displayName
1 … 1
F
Problem list
hl7:title
ST
1 … 1
M
(Ges...ken)
Constraint
Fixer Wert: Gesundheitsprobleme und Risiken
hl7:text
1 … 1
M
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.
wo [hl7:act [hl7:templateId [@root='1.2.40.0.34.11.13.3.6']]]
@typeCode
cs
0 … 1
F
DRIV
7.2.4 Medikationsliste
Diese Sektion entspricht inhaltlich der Medikationsliste der eMedikation, sie soll allerdings noch weiter komprimiert werden, indem werden. Bei der verkürzten Darstellung werden die Abschnitte für Abgabe und Verordnung zusammengefasst und immer NUR der neueste Eintrag (nur wenn eine Abgabe nicht erfolgte die Verordnung). Die maschinenlesbaren Elemente sind dieselben wie in der eMedikation.
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.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.16
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 4 Templates
wo [hl7:substanceAdministration [hl7:templateId [@root='1.2.40.0.34.11.8.1.3.1'] and hl7:templateId [@root='2.16.840.1.113883.10.20.1.24'] and hl7:templateId [@root='1.3.6.1.4.1.19376.1.5.3.1.4.7'] and hl7:templateId [@root='1.3.6.1.4.1.19376.1.9.1.3.2'] and hl7:templateId [@root='1.3.6.1.4.1.19376.1.9.1.3.6']]]
wo [hl7:supply [hl7:templateId [@root='1.2.40.0.34.11.8.2.3.1'] and hl7:templateId [@root='2.16.840.1.113883.10.20.1.34'] and hl7:templateId [@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.3'] and hl7:templateId [@root='1.3.6.1.4.1.19376.1.9.1.3.4']]]
@typeCode
cs
0 … 1
F
DRIV
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, Lokation, Hadnelsname, Hersteller, Chargennummer.
Die Codierung der medizinischen Gerätetypen ist noch nicht fixiert, soll dem EU UDI System (EU Medical Device Regulations) entsprechen.
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.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.4
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 3 Templates
Keine Information über medizinische Geräte oder Implantate
<section> <templateIdroot="1.2.40.0.34.11.13.2.4"/><idroot="1.2.3.999"extension="--example only--"/><codecode="46264-8"codeSystem="2.16.840.1.113883.6.1"/><title>Medizinische Geräte und Implantate</title><text> <table> <tbody> <trID="al-3"> <tdcolspan="4"> <contentstyleCode="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>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:section
1 … 1
M
(Imp...ate)
hl7:templateId
II
1 … 1
M
(Imp...ate)
@root
uid
1 … 1
F
1.2.40.0.34.11.13.2.4
hl7:id
II
1 … 1
R
(Imp...ate)
hl7:code
CE (extensible)
1 … 1
M
(Imp...ate)
@code
CONF
1 … 1
F
46264-8
@codeSystem
1 … 1
F
2.16.840.1.113883.6.1 (Logical Observation Identifier Names and Codes)
@codeSystemName
1 … 1
F
LOINC
@displayName
1 … 1
F
History of medical device use
hl7:title
ST
1 … 1
M
(Imp...ate)
CONF
Elementinhalt muss "Medizinische Geräte und Implantate" sein
hl7:text
SD.TEXT
1 … 1
M
Dieses Element enthält die intra- und extrakorporale Medizinprodukte oder Medizingeräte, von denen der Gesundheitszustand des Patienten direkt abhängig ist, in tabellarischer Darstellung.
wo [hl7:substanceAdministration [hl7:templateId [@root='1.2.40.0.34.11.13.3.9']]]
@typeCode
cs
0 … 1
F
DRIV
7.2.7 Durchgeführte Eingriffe und Therapien
Die Sektion "Durchgeführte Eingriffe und Therapien" wird derzeit nicht als prioritär erachtet – weil sowohl medizinisch aussagekräftige Terminologien und valide Quellen für die automatisierte Übernahme fehlen. Provisorisch wird die Vorgabe aus dem IPS ohne Änderung direkt übernommen.
Diskussion der möglichen Datenquellen:
Klinikum Graz und im AKH Wien: hier liegen durchgängig ICPM codierte Leistungen vor
LKF-Daten (MEL Codes) Zugriff auf den zentralen Datenbestand muss technisch und juristisch geprüft werden (wo? Hauptverband, BMGF..)
Datenmodell ist ebenfalls zu prüfen
Zukünftig MEL und ICPM in Entlassungsbrief und Outpatient Report zulassen
„OP-Berichte“ (als eHealth-Dokumente) könnten harmonisiert und als Datenquelle herangezogen werden.
Eingriff / Therapie
Datum
Code
GDA
Zusatzinformation
brusterhaltende. Operation/ (Teil-)Exzision
2015-03-14
MEL 2176
Amadeus-Spital Salzburg
Id
1.2.40.0.34.11.13.2.3
Gültigkeit
gültig ab 2017‑01‑28 14:16:09
Status
Entwurf
Versions-Label
0.1
Name
DurchgefuehrteEingriffe
Anzeigename
Durchgeführte Eingriffe und Therapien
Beschreibung
Diese Sektion enthält relevante Eingriffe und Therapien wie Operationen und konservative Behandlungen.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.3
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 3 Templates
<section> <templateIdroot="1.2.40.0.34.11.13.2.12"/><codecode="47420-5"displayName="Functional status assessment"codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC"/><title>Beeinträchtigungen</title><text> (Optionaler Abschnitt)<br/><br/><list> <item>Taubheit linkes Ohr</item><item>Taubheitsgefühl und Sensitivitätsstärungen linker Arm</item></list></text></section>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:section
1 … 1
M
(Bee...gen)
hl7:templateId
II
1 … 1
M
(Bee...gen)
@root
uid
1 … 1
F
1.2.40.0.34.11.13.2.12
hl7:code
CE (extensible)
1 … 1
M
(Bee...gen)
@code
CONF
1 … 1
F
47420-5
@codeSystem
1 … 1
F
2.16.840.1.113883.6.1 (Logical Observation Identifier Names and Codes)
@codeSystemName
1 … 1
F
LOINC
@displayName
1 … 1
F
Functional status assessment
Beispiel
<codecode="47420-5"displayName="Functional status assessment"codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC"/>
hl7:title
ST
1 … 1
R
(Bee...gen)
CONF
Elementinhalt muss "Beeinträchtigungen" sein
hl7:text
SD.TEXT
1 … 1
R
In diesem Element werden Informationen über dauernde Beeinträchtigung der körperlichen und/oder geistigen Leistungsfähigkeit, Art und Grad von Behinderungen hinterlegt.
Diese Sektion dient zur Aufnahme von diagnostischen Resultaten und Messwerten. Ein Beispiel zur Darstellung:
Analyse
Ergebnis
Einheit
Referenzbereiche
Interpretation
Blutgruppenbestimmung
A Rh pos.
Blutgruppen-Antikörper
Anti-Kell positiv
*
CYP2D6
Poor Metabolizer
*1)
1) BESONDERE VORSICHT beim Verschreiben von Medikamenten, die über dieses entsprechende Enzym metabolisiert (aktiviert – PRODRUG) werden, oder die entsprechenden Enzyme aktivieren oder hemmen. Eine geänderte Dosierung, bzw der Einsatz von entsprechenden Medikamenten, die einen alternativen Abbauweg beschreiten, sollte in Erwägung gezogen werden, siehe Link
Id
1.2.40.0.34.11.13.2.10
Gültigkeit
gültig ab 2017‑03‑12 12:10:30
Status
Entwurf
Versions-Label
0.1
Name
DiagnostischeResultate
Anzeigename
Diagnostische Resultate
Beschreibung
Diagnostische Resultate und Messwerte, die dauerhaft von Bedeutung sind wie Größe, Gewicht, Blutgruppe, transfusionsrelevante Antikörper, pharmakogenetische Informationen, genetische Testresultate (z.B. HLA-B27, Thalassämie) etc.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.10
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 3 Templates
2.16.840.1.113883.6.1 (Logical Observation Identifier Names and Codes)
@codeSystemName
1 … 1
F
LOINC
@displayName
1 … 1
F
Relevant diagnostic tests/laboratory data
hl7:title
ST
1 … 1
M
diagnostische Resultate wie die Blutgruppe und relevante Laborwerte
(Dia...ate)
CONF
Elementinhalt muss "Diagnostische Resultate" sein
hl7:text
SD.TEXT
1 … 1
M
Diagnostische Resultate, die dauerhaft von Bedeutung sind wie Größe, Gewicht, Blutgruppe, Transfusions-relevante Antikörper, pharmakogenetische Informationen etc. in tabellarischer Darstellung.
wo [hl7:organizer [hl7:templateId [@root='1.2.40.0.34.11.13.3.26']]]
@typeCode
cs
0 … 1
F
DRIV
7.2.10 Schwangerschaften
Aktuelle Schwangerschaft
Errechneter Geburtstermin: 2.3.2018
Schwangerschaften gesamt
5
Lebendgeburten
2
Spontanabortus
1
Id
1.2.40.0.34.11.13.2.9
Gültigkeit
gültig ab 2017‑03‑11 18:04:25
Status
Entwurf
Versions-Label
0.1
Name
Schwangerschaften
Anzeigename
Schwangerschaften
Beschreibung
Die Sektion Schwangerschaften enthält Informationen über vergangene Schwangerschaften, Geburten und Abortus sowie aktuelle Schwangerschaft und erwarteten Geburtstermin.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.9
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 4 Templates
2.16.840.1.113883.6.1 (Logical Observation Identifier Names and Codes)
@codeSystemName
1 … 1
F
LOINC
@displayName
1 … 1
F
History of pregnancies
hl7:title
ST
1 … 1
M
Schwangerschaften
(Sch...ten)
CONF
Elementinhalt muss "Schwangerschaften" sein
hl7:text
SD.TEXT
1 … 1
M
Die Sektion Schwangerschaft enthält Informationen über vergangene Schwangerschaften, Geburten und Abortus sowie aktuelle Schwangerschaft und erwarteten Geburtstermin.
In diesem Entry ist dokumentiert, ob aktuell eine Schwangerschaft vorliegt. Falls ja, können auch Angaben zum erwarteten Geburtstermin gemacht werden. Beinhaltet 1.2.40.0.34.11.13.3.10 Aktuelle Schwangerschaft (DYNAMIC)
(Sch...ten)
wo [@typeCode='COMP'] [hl7:observation [hl7:templateId [@root='1.2.40.0.34.11.13.3.10']]]
@typeCode
cs
1 … 1
F
COMP
hl7:entry
0 … 1
R
Dieses Entry dokumentiert Daten zu bisher aufgetretenen Schwangerschaften wie z.B. die Anzahl an Lebendgeburten. Beinhaltet 1.2.40.0.34.11.13.3.23 Bisherige Schwangerschaften (DYNAMIC)
(Sch...ten)
wo [hl7:observation [hl7:templateId [@root='1.2.40.0.34.11.13.3.23']]]
@typeCode
cs
0 … 1
F
COMP
7.2.11 Lebensstil
Lebensstilfaktor
Alkohol
2 Gläser pro Tag
Nikotin
Nichtraucher
Id
1.2.40.0.34.11.13.2.8
Gültigkeit
gültig ab 2017‑03‑12 11:13:38
Status
Entwurf
Versions-Label
0.1
Name
Lebensstil
Anzeigename
Lebensstil
Beschreibung
Diese Sektion dient der Erfassung von Lebensstil-Faktoren, wie Alkoholkonsum oder Rauchen.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.8
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 4 Templates
<section> <templateIdroot=" 1.2.40.0.34.11.13.2.15"/><!-- Code der Sektion --> <codecode="PFSOZV"displayName="Soziale Umstände und Verhalten"codeSystem="1.2.40.0.34.5.40"codeSystemName="ELGA_Sections"/><!-- Titel der Sektion --> <title>Soziale Umstände und Verhalten</title><!-- Textbereich der Sektion --> <text> ... Lesbarer Textbereich ... </text></section>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:section
(Soz..._PS)
hl7:templateId
II
1 … 1
R
(Soz..._PS)
@root
uid
1 … 1
F
1.2.40.0.34.11.13.2.15
hl7:code
CE (extensible)
1 … 1
M
(Soz..._PS)
@code
CONF
1 … 1
F
PFSOZV
@codeSystem
1 … 1
F
1.2.40.0.34.5.40
@codeSystemName
1 … 1
F
ELGA_Sections
@displayName
1 … 1
F
Soziale Umstände und Verhalten
Beispiel
<codecode="PFSOZV"displayName="Soziale Umstände und Verhalten"codeSystem="1.2.40.0.34.5.40"codeSystemName="ELGA_Sections"/>
hl7:title
ST
1 … 1
M
(Soz..._PS)
CONF
Elementinhalt muss "Soziale Umstände und Verhalten" sein
hl7:text
1 … 1
M
(Soz..._PS)
hl7:author
0 … *
Author der enthaltenen Information (GDA) Beinhaltet 1.2.40.0.34.11.13.3.16 Author (Body) PS (DYNAMIC)
(Soz..._PS)
hl7:informant
0 … *
Quelle für die enthaltene Information
Name der Person und ihre Beziehung zum Patienten (Patient oder Angehöriger, Auskunftsperson - nicht-GDA)
von 1.2.40.0.34.11.30032 Risiken Hilfsmittel Ressourcen (DYNAMIC)
hl7:component
0 … 1
Beinhaltet 1.2.40.0.34.11.1.2.8 Risiken (DYNAMIC)
(Soz..._PS)
wo [hl7:section [hl7:templateId [@root='1.2.40.0.34.11.1.2.8']]]
@typeCode
0 … 1
F
COMP
@contextConductionInd
0 … 1
F
true
hl7:component
0 … 1
Beinhaltet 1.2.40.0.34.11.1.2.9 Hilfsmittel und Ressourcen (DYNAMIC)
(Soz..._PS)
wo [hl7:section [hl7:templateId [@root='1.2.40.0.34.11.1.2.9']]]
@typeCode
0 … 1
F
COMP
@contextConductionInd
0 … 1
F
true
7.2.13 Willenserklärungen und andere juridische Dokumente
Anmerkung: Wäre "Willenserklärungen und andere rechtswirksame Dokumente" ein besserer Titel?
Datum
Dokument
Verwahrung/Quelle
23.02.2004
Transplantationswiderspruch
Quelle: Widerspruchsregister
04.03.2015
Patientenverfügung
Quelle: Patientenverfügungsregister
Id
1.2.40.0.34.11.13.2.11
Gültigkeit
gültig ab 2017‑08‑04 11:56:28
Status
Entwurf
Versions-Label
0.1
Name
Willenserklaerungen
Anzeigename
Willenserklärungen
Beschreibung
Alle Patientenverfügungen und diejenigen juridischen Dokumente, welche für weitere Behandlungen als relevant erachtet werden. Die Aufstellung soll narrativ in tabellarischer Form erfolgen und die Art des vorliegenden Dokuments, sowie den Hinweis, wo dieses verwahrt wird, enthalten. Beispiel: „Testament“ – „liegt bei Tochter auf“.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.11
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 2 Templates
Informationen und Hinweise, die sonst in keine Kategorie passen, wie z.B. "Patient ist bezüglich des Risikos einer Ruptur des Aortenaneurysmas aufgeklärt".
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.14.2.2
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 2 Templates
Ordination Dr. Angelikus Oberzalek,Giselakai5, 5020Salzburg
2004-06-19
Amadeus-Spital Salzburg, Chirurgie
2015-03-10
2015-03-18
3
Amadeus-Spital Salzburg, Onkologie-Ambulanz
2016-02-08
2
Ordination Dr. Angelikus Oberzalek Giselakai5, 5020Salzburg
2016-06-01
Ordination Dr. Angelikus Oberzalek,Giselakai5, 5020Salzburg
2017-07-17
1
Id
1.2.40.0.34.11.13.2.13
Gültigkeit
gültig ab 2017‑09‑07 15:22:40
Status
Entwurf
Versions-Label
0.1
Name
GDAListe
Anzeigename
Liste der behandelnden GDA
Beschreibung
Diese Sektion dient der Aufnahme einer (menschenlesbaren) Liste der behandelnden Gesundheitsdiensteanbieter (GDA).
Die maschinenlesbaren Informationen finden sich als Liste der Gesundheitsdienstleistungen im CDA Header („ServiceEvents“), deshalb gibt es in dieser Sektion auch keine Entries.
In von GDA erstellten Patient Summary Dokumenten („human curated“) wird diese Sektion nicht erwartet.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.2.13
Klassifikation
CDA Section level template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 1 Template, Benutzt 2 Templates
Benutzt von
als
Name
Version
1.2.40.0.34.11.13
Containment
CDA ELGA Patient Summary (0.1)
2016‑08‑30 16:19:25
Benutzt
als
Name
Version
1.2.40.0.34.11.13.3.16
Containment
Author (Body) PS
DYNAMIC
1.2.40.0.34.11.13.3.20
Containment
Informant (Body) PS (0.1)
DYNAMIC
Beispiel
Beispiel
<section> <templateIdroot="1.2.40.0.34.11.13.2.13"/><codecode="LISTGDA"displayName="Liste der behandelnden GDA"codeSystem="1.2.40.0.34.5.40"codeSystemName="ELGA_SECTIONS"/><title>Liste der behandlenden GDA</title><text> (Ermittelt aus Kontaktbestätigungsservice, wird automatisch über Stylesheet angezeigt aus Element documentationOf.serviceEvent) <table> <thead> <tr> <thstyleCode="xELGA_colw:70">GDA</th><thstyleCode="xELGA_colw:15">Datum von</th><thstyleCode="xELGA_colw:15">bis</th></tr></thead><tbody> <trID="gda-3"> <td> <contentstyleCode="bold"> Ordination Dr. Angelikus Oberzalek <br/>Giselakai 5, 5020 Salzburg</content></td><td>2004-06-19</td><td/></tr><trID="gda-3"> <td> <contentstyleCode="bold">Amadeus-Spital Salzburg, Chirurgie</content></td><td>2015-03-10</td><td>2015-03-18</td></tr><trID="gda-3"> <td> <contentstyleCode="bold">Amadeus-Spital Salzburg, Onkologie-Ambulanz</content></td><td>2016-02-08</td><td/></tr><trID="gda-3"> <td> <contentstyleCode="bold"> Ordination Dr. Angelikus Oberzalek <br/>Giselakai 5, 5020 Salzburg</content></td><td>2016-06-01</td><td/></tr><trID="gda-3"> <td> <contentstyleCode="bold"> Ordination Dr. Angelikus Oberzalek <br/>Giselakai 5, 5020 Salzburg</content></td><td>2017-07-17</td><td/></tr></tbody></table></text></section>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:section
1 … 1
M
(GDA...ste)
hl7:templateId
II
1 … 1
M
(GDA...ste)
@root
uid
1 … 1
F
1.2.40.0.34.11.13.2.13
hl7:code
CE (extensible)
1 … 1
M
(GDA...ste)
@code
CONF
1 … 1
F
LISTGDA
@codeSystem
1 … 1
F
1.2.40.0.34.5.40
@codeSystemName
1 … 1
F
ELGA_Sections
@displayName
1 … 1
F
Liste der behandelnden GDA
hl7:title
ST
1 … 1
R
(GDA...ste)
CONF
Elementinhalt muss "Liste der behandelnden GDA" sein
hl7:text
1 … 1
R
Dieses Element enthält die tabellarische Darstellung der behandelnden GDA.
Der Autor (author) ist der Verfasser bzw. geistige Urheber eines bestimmten Inhalts. In der Regel ist das eine Person oder mehrere Personen, es kann aber auch ein "Gerät" - ein Programm oder Software den Inhalt automatisiert erstellen. Element für Sections und Entries.
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 26 Templates, Benutzt 1 Template
<relatedEntityclassCode="PRS"> <!-- Verwandtschaftsverhältnis des Angehörigen zum Patienten --> <codecode="MTH"displayName="mother"codeSystem="1.2.40.0.34.10.17"codeSystemName="ELGA_PersonalRelationship"/></relatedEntity>
Klassifikation des GDA, der als Informant in Erscheinung tritt
(Inf...yPS)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
hl7:addr
AD
0 … *
(Inf...yPS)
hl7:telecom
TEL
0 … *
(Inf...yPS)
hl7:assignedPerson
0 … 1
(Inf...yPS)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend
Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Inf...yPS)
hl7:representedOrganisation
0 … 1
(Inf...yPS)
@classCode
cs
0 … 1
F
ORG
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:id
II
1 … *
M
(Inf...yPS)
hl7:name
ON
1 … 1
M
(Inf...yPS)
hl7:telecom
TEL
0 … *
(Inf...yPS)
hl7:addr
AD
0 … 1
(Inf...yPS)
hl7:relatedEntity
(Inf...yPS)
@classCode
cs
1 … 1
F
PRS
hl7:code
CE (extensible)
0 … 1
(Inf...yPS)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.17 ELGA_PersonalRelationship (DYNAMIC)
hl7:addr
AD
0 … *
(Inf...yPS)
hl7:telecom
TEL
0 … *
(Inf...yPS)
hl7:relatedPerson
0 … 1
(Inf...yPS)
Eingefügt
von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
@classCode
cs
0 … 1
F
PSN
@determinerCode
cs
0 … 1
F
INSTANCE
hl7:name
PN
1 … 1
M
Name der Person
Für den Namen ist verpflichtend
Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(Inf...yPS)
7.3.3 Allergien und Intoleranzen Entry
Hierarchisches Diagramm
Entry
Allergien und Intoleranzen Entry (1.2.40.0.34.11.13.3.1)
Entry
Author (Body) PS (1.2.40.0.34.11.13.3.16)
Header
PersonElements (1.2.40.0.34.11.90001)
Entry
Informant (Body) PS (1.2.40.0.34.11.13.3.20)
Header
PersonElements (1.2.40.0.34.11.90001)
Header
PersonElements (1.2.40.0.34.11.90001)
Entry
Problem Entry Allergien (1.2.40.0.34.11.13.3.2)
Entry
Participant Allergie (1.2.40.0.34.11.13.3.3)
Entry
Problem Entry Allergien-Reaktion (1.2.40.0.34.11.13.3.15)
Entry
Severity Observation (1.2.40.0.34.11.13.3.21)
Entry
Criticality Observation (1.2.40.0.34.11.13.3.18)
Entry
Certainty Observation (1.2.40.0.34.11.13.3.19)
Entry
Allergy Status Observation (1.2.40.0.34.11.13.3.14)
Entry
ELGA ExternalDocument (1.2.40.0.34.11.13.3.17)
Allergien und Intoleranzen Entry
Id
1.2.40.0.34.11.13.3.1
Gültigkeit
gültig ab 2016‑11‑06 16:32:31
Status
Entwurf
Versions-Label
0.1
Name
AllergienUnvertraeglichkeitenEntry
Anzeigename
Allergien und Intoleranzen Entry
Beschreibung
Entry für die codierte Angabe von Allergien und Intoleranzen. Es besteht aus einem "Bedenken" (Concern-Entry) mit mindestens einem darin liegendem "Problem"-Entry mit der Angabe der Überempfindlichkeit. Das Concern-Entry gibt an, ob ein Bedenken besteht und der Zeitraum, in dem es besteht oder bestanden hat. Ein Bedenken kann mehrere Probleme (Allergien und Intoleranzen) umfassen, empfohlen wird ein Problem pro Bedenken. Die Zustände es sind "keine Information über Überempfindlichkeiten verfügbar" und es bestehen bekanntlich "keine Überempfindlichkeiten" können maschinenlesbar ausgedrückt werden.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.3.1
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 2 Templates, Benutzt 4 Templates
"active": Die Bedingungen für das Bedenken gelten noch und werden auch immer noch (vom Author) beobachtet "completed": Die Allergie macht keine Bedenken mehr, das Bedenken wird nicht mehr verfolgt und Auswirkungen des Bedenkens sind nicht zu erwarten.
(All...try)
CONF
@code muss "active" sein
oder
@code muss "completed" sein
hl7:effectiveTime
IVL_TS
1 … 1
R
Erstes und letztes Auftreten des Bedenkens. Low element muss vorhanden sein. Ein High-Element ist nur erforderlich, wenn das Bedenken den Status "completed" hat.
(All...try)
hl7:low
IVXB_TS
1 … 1
R
Beginn des Auftretens des Bedenkens Erlaubter nullFlavor = UNK
(All...try)
hl7:high
IVXB_TS
0 … 1
C
Zeitpunkt des Endes des Bedenkens
(All...try)
Constraint
Wenn statusCode = completed, dann ist die Angabe dieses Elements verpflichtend. Ist dieser Zeitpunkt nicht bekannt, ist effectiveTime.high mit nullFlavor "UNK" anzugeben.
Schematron assert
role
error
test
not(../hl7:statusCode[@code='completed']) or hl7:high
Meldung
Wenn statusCode/@code = completed, dann muss die effectiveTime ein high-Element enthalten.
Dieses Entry dient der codierten Darstellung einer konkreten Allergie oder Intoleranz. Es kann nicht ohne Einbettung in ein Bedenken-Entry angegeben werden (Allergien und Intoleranzen Entry). Die Zeitspanne, in der die Überempfindlichkeit besteht oder bestanden hat, wird hier angegeben.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.3.2
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 3 Templates, Benutzt 5 Templates
Dieses Element enthält die Art der beobachteten Allergie oder nicht-allergischen Intoleranz .
(All...try)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.177 ELGA_AllergyOrIntolerance (DYNAMIC)
hl7:text
0 … 1
R
Falls vorhanden, enthält dieses Element eine Referenz auf die narrative Beschreibung im Section-Text.
(All...try)
hl7:reference
TEL
1 … 1
M
(All...try)
@value
1 … 1
R
Referenz auf die narrative Beschreibung im Section-Text
hl7:statusCode
CS (erforderlich)
1 … 1
M
(All...try)
@code
CONF
1 … 1
F
completed
hl7:effectiveTime
IVL_TS
1 … 1
R
Dieses Element enthält die medizinisch relevante Zeit des Bestehens des Problems entsprechend den bekannten Informationen bzw. der Aussage des Patienten. Das Zeitintervall (der low- und high-Wert) sollten so genau wie möglich angegeben werden.
(All...try)
hl7:low
IVXB_TS
1 … 1
R
Datum des Beginns des Problems.
(All...try)
hl7:high
IVXB_TS
0 … 1
C
Datum des Endes des Problems. Bei nicht abgeschlossenen Problemen entfällt die Angabe des high-Werts. Bei nicht mehr bestehenden Problemen und unbekanntem Ende-Datum wird im Wert der null-Flavor 'UNK' verwendet werden.
(All...try)
hl7:value
0 … 1
C
Das value Element wird zur Angabe "Keine bekannten Allergien" oder "Keine Information über Allergien oder Intoleranzen verfügbar" verwendet. Die Angabe erfolgt codiert mit Werten aus dem Value Set ELGA_AbsentOrUnknownAllergies Bei Vorliegen einer Allergie oder Intoleranz entfällt dieses Element.
(All...try)
@xsi:type
cs
1 … 1
F
CD
xsi:type='CD' muss immer angegeben werden. Entweder es folgt die Angabe eines Codes mit geeignetem CodeSystem oder aber es ist gar kein Code angegeben.
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.178 ELGA_AbsentOrUnknownAllergies (DYNAMIC)
hl7:originalText
ED
0 … 1
Dieses Feld enthält den anzuzeigenden Text auf deutsch.
(All...try)
hl7:participant
0 … 1
C
In diesem Element wird das Allergen angegeben. Wenn das observation.value Element vorhanden und codiert ist, entfällt die Angabe des participant. Beinhaltet 1.2.40.0.34.11.13.3.3 Participant Allergie (DYNAMIC)
(All...try)
wo [@typeCode='CSM']
Schematron assert
role
error
test
hl7:value[@code] or hl7:participant/hl7:participantRole
Meldung
IF the observation/value element is present and coded then the observation/participant element SHALL be omitted.
hl7:entryRelationship
0 … *
In diesem EntryRelationship wird die Reaktion, mit der sich die Allergie oder Intoleranz manifestiert, erfasst.
Beinhaltet 1.2.40.0.34.11.13.3.15 Problem Entry Allergien-Reaktion (DYNAMIC)
(All...try)
wo [@typeCode='MFST'] [hl7:observation [hl7:templateId [@root='1.2.40.0.34.11.13.3.15']]]
@inversionInd
cs
1 … 1
F
true
@typeCode
cs
1 … 1
F
MFST
hl7:entryRelationship
0 … 1
R
Dieses EntryRelationship stellt den Schweregrad der Allergie oder Intoleranz dar. Wenn vorhanden, enthält es eine Observation zur Beschreibung der Kritizität.
Code für die Art der Reaktion, die Verwendung "Problem" ist empfohlen.
Anmerkung: Das Value Set ELGA_Problemarten wird abgelöst, in neuen Dokumenten ist ELGA_Problemarten_2018 zu verwenden.
(Pro...ion)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.35 ELGA_Problemarten (DYNAMIC)
hl7:text
ED
0 … 1
R
Falls vorhanden, enthält dieses Element einen Verweis auf die Allergie-Reaktion im narrativen Teil.
(Pro...ion)
hl7:reference
TEL
1 … 1
M
(Pro...ion)
@value
1 … 1
R
Verweis auf die Allergie-Reaktion im narrativen Teil
hl7:statusCode
CS (erforderlich)
1 … 1
M
(Pro...ion)
@code
CONF
1 … 1
F
completed
hl7:effectiveTime
IVL_TS
1 … 1
R
Angabe der Zeitspanne, in der die Reaktion aufgetreten ist. Ist die Zeitspanne nicht bekannt, so ist nur der low-Wert mit nullFlavor 'UNK' zu verwenden.
(Pro...ion)
hl7:value
1 … 1
R
Das Attribut @code enthält den Code für die Reaktion. erlaubte nullFlavor: NI in diesem Fall ist die Textreferenz <originalText> verpflichtend
(Pro...ion)
@xsi:type
1 … 1
F
CD
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.181 ELGA_AllergyReaction (DYNAMIC)
hl7:originalText
ED
0 … 1
C
(Pro...ion)
hl7:reference
TEL
Verweist auf die Stelle im narrativen Textbereich, in dem das Problem beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).
(Pro...ion)
Constraint
Wenn @code=NI, muss originalText.reference vorhanden sein
hl7:translation
CE (extensible)
0 … *
Dieses Feld wird verwendet, wenn codes aus einem abweichenden ValueSet angegeben werden. z.B. für Übersetzungen in alternative Codesysteme oder wenn kein geeigneter code im vorgegebene VS vorhanden ist.
(Pro...ion)
hl7:entryRelationship
0 … 1
R
Schweregrad In dem enthaltenen entry wird der Schweregrad der allergischen Reaktion oder Intoleranz beschrieben. Beinhaltet 1.2.40.0.34.11.13.3.21 Severity Observation (DYNAMIC)
(Pro...ion)
wo [@typeCode='SUBJ'] [hl7:observation [hl7:templateId [@root='1.2.40.0.34.11.13.3.21']]]
@typeCode
cs
1 … 1
F
SUBJ
@inversionInd
bl
1 … 1
F
true
7.3.7 Severity Observation Entry
Id
1.2.40.0.34.11.13.3.21
Gültigkeit
gültig ab 2017‑08‑20 12:08:35
Status
Entwurf
Versions-Label
0.1
Name
SeverityObservation
Anzeigename
Severity Observation
Beschreibung
Observation zur Angabe des Schweregrads der allergischen Reaktion.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.3.21
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 9 Templates, Benutzt 0 Templates
Problem Entry Gesundheitsproblem (1.2.40.0.34.11.13.3.7)
Entry
Severity Observation (1.2.40.0.34.11.13.3.21)
Entry
Certainty Observation (1.2.40.0.34.11.13.3.19)
Entry
Problem Status Observation (1.2.40.0.34.11.13.3.13)
Entry
ELGA ExternalDocument (1.2.40.0.34.11.13.3.17)
Gesundheitsproblem Bedenken Entry
Id
1.2.40.0.34.11.13.3.6
Gültigkeit
gültig ab 2017‑01‑26 14:29:54
Status
Entwurf
Versions-Label
0.2
Name
GesundheitsproblemBedenkenEntry
Anzeigename
Gesundheitsproblem Bedenken Entry
Beschreibung
Dieses Entry stellt ein relevantes Gesundheitsproblem des Patienten codiert dar. Es wird mit Status und Datum, sofern bekannt, dokumentiert, weiters mit dem Datum der Erfassung der Diagnose.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.3.6
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 2 Templates, Benutzt 4 Templates
"active": Die Bedingungen für das Bedenken gelten noch und werden auch immer noch (vom Author) beobachtet.
"completed": Die Gesundheitsproblem oder das Risiko macht keine Bedenken mehr, das Bedenken wird nicht mehr verfolgt und Auswirkungen des Bedenkens sind nicht zu erwarten.
Ist nicht bekannt, ob das Bedenken noch besteht, ist von "active" auszugehen.
(Ges...try)
CONF
@code muss "active" sein
oder
@code muss "completed" sein
hl7:effectiveTime
IVL_TS
1 … 1
R
Erstes und letztes Auftreten des Bedenkens.
(Ges...try)
hl7:low
IVXB_TS
1 … 1
R
Beginn des Auftretens des Bedenkens.
(Ges...try)
hl7:high
IVXB_TS
0 … 1
C
Zeitpunkt des Endes des Bedenkens. Ist dieser Zeitpunkt nicht bekannt, ist effectiveTime.high mit nullFlavor "UNK" anzugeben.
(Ges...try)
Constraint
Wenn statusCode=completed ist, dann ist die Angabe dieses Werts erforderlich.
Schematron assert
role
error
test
hl7:act/hl7:statusCode[@code="completed"] and hl7:act/hl7:effectiveTime/hl7:high
Meldung
if statusCode = completed effectiveTime.high may not be empty
Mit dieser Observation wird ein bekanntes relevantes Gesundheitsproblem des Patienten codiert dargestellt.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.777.2.10.1
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 3 Templates, Benutzt 5 Templates
Benutzt von
als
Name
Version
1.2.40.0.34.11.13.3.6
Containment
Gesundheitsproblem Bedenken Entry (0.2)
2017‑01‑26 14:29:54
1.2.40.0.34.11.13.2.2
Gesundheitsprobleme und Risiken (0.1)
2017‑01‑26 13:50:54
1.2.40.0.34.11.13
CDA ELGA Patient Summary (0.1)
2016‑08‑30 16:19:25
Benutzt
als
Name
Version
1.2.40.0.34.11.13.3.20
Containment
Informant (Body) PS (0.1)
DYNAMIC
1.2.40.0.34.11.13.3.21
Containment
Severity Observation (0.1)
DYNAMIC
1.2.40.0.34.11.13.3.19
Containment
Certainty Observation
DYNAMIC
1.2.40.0.34.11.13.3.13
Containment
Problem Status Observation (0.1)
DYNAMIC
1.2.40.0.34.11.13.3.17
Containment
ELGA ExternalDocument (0.1)
DYNAMIC
Item
DT
Kard
Konf
Beschreibung
Label
hl7:observation
1 … 1
R
(Pro…yPS)
@classCode
cs
1 … 1
F
OBS
@moodCode
cs
1 … 1
F
EVN
hl7:templateId
II
1 … 1
M
(Pro…yPS)
@root
uid
1 … 1
F
1.2.40.0.34.777.2.10.1
hl7:templateId
II
1 … 1
R
(Pro…yPS)
@root
uid
1 … 1
F
1.2.40.0.34.11.1.3.6
hl7:id
0 … *
R
(Pro…yPS)
hl7:code
CE
1 … 1
M
Das Element <code> enthält die Art des beschriebenen Gesundheitsproblems. Falls eine Unterscheidung nicht klar gefordert ist, wird die Verwendung von 'Finding' (404684003) empfohlen.
(Pro…yPS)
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.35 ELGA_Problemarten (DYNAMIC)
hl7:text
ED
0 … 1
R
Wenn vorhanden, enthält das <text> Element einen Verweis auf die Beschreibung der Problems im narrativen Teil.
(Pro…yPS)
hl7:reference
TEL
1 … 1
M
(Pro…yPS)
@value
st
1 … 1
R
Verweis auf die Beschreibung des Problems im narrativen Teil
hl7:statusCode
CS
1 … 1
M
Fixer Wert: completed
(Pro…yPS)
@code
CONF
1 … 1
F
completed
hl7:effectiveTime
IVL_TS
1 … 1
M
(Pro…yPS)
hl7:low
IVXB_TS
1 … 1
R
Zeitpunkt des Beginns des Gesundheitsproblems (für den Patienten)
(Pro…yPS)
hl7:high
IVXB_TS
0 … 1
C
Im <high>Element ist der Zeitpunkt anzugeben, an dem das Gesundheitsproblem gelöst wurde. Ist dieser Zeitpunkt nicht bekannt, ist effectiveTime.high mit nullFlavor "UNK" anzugeben,
(Pro…yPS)
Constraint
Das <high> Element ist dann anzugeben, wenn das Gesundheitsproblem nicht mehr besteht.
hl7:value
CDCNE
1 … 1
M
Angabe des Gesundheitsproblems:
Uncodierte Angabe: xsi:type='CD', originalText.reference enthält den Verweis auf die narrative Beschreibung des Problems
Keine Gesundheitsprobleme: @code enthält den entsprechenden Wert aus ELGA_AbsentOrUnknownProblems
Keine Information über Gesundheitprobleme: @code enthält den entsprechenden Wert aus ELGA_AbsentOrUnknownProblems
Codierte Angabe: @code enthält den Code des Gesundheitsproblems aus ELGA_Problems
(Pro…yPS)
@xsi:type
1 … 1
F
CD
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.179 ELGA_AbsentOrUnknownProblems (DYNAMIC)
oder
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.201 ELGA_Problems (DYNAMIC)
hl7:originalText
ED
1 … 1
R
(Pro…yPS)
hl7:reference
TEL
0 … 1
R
Verweis auf die Darstellung des Gesundheitsproblems im narrativen Teil.
(Pro…yPS)
hl7:translation
CE
0 … *
Dieses Feld wird verwendet, wenn codes aus einem abweichenden ValueSet angegeben werden.
z.B. für Übersetzungen in alternative Codesysteme oder wenn kein geeigneter code im vorgegebene VS vorhanden ist.
(Pro…yPS)
hl7:informant
0 … *
In diesem Element können eine oder mehrere Quellen für die Informationen angeführt werden
Der Name der Person und ihre Beziehung zum Patienten (Patient oder Angehöriger, Auskunftsperson - nicht-GDA) können angegeben werden.
Der Code klassifiziert die Art der Versorgung. Im Fall eines Implantats ist ein fixer code anzugeben. In allen anderen Fällen entfällt das code-Element.
Elemente in der Auswahl:
hl7:code[(@code='71861002' and @codeSystem='2.16.840.1.113883.6.96')]
hl7:code
hl7:code
CE (extensible)
1 … 1
M
(ELG...ice)
@code
CONF
1 … 1
F
71861002
@codeSystem
1 … 1
F
2.16.840.1.113883.6.96 (SNOMED Clinical Terms)
hl7:code
CE (extensible)
NP
(ELG...ice)
hl7:text
ED
0 … 1
R
Dieses Element enthält nur einen Verweise auf die Informationen für dieses Gerät im narrativen Teil
(ELG...ice)
hl7:reference
TEL
1 … 1
M
(ELG...ice)
@value
1 … 1
R
Verweis auf die Informationen für dieses Gerät im narrativen Teil.
hl7:effectiveTime
IVL_TS
1 … 1
R
Dieses Element enthält den Zeitpunkt der Versorgung des Patienten. Im Fall eines Implantats ist hier Datum und Zeit der Implantation anzugeben. Da nur aktuelle verwendete Geräte oder Implantate anzugeben sind, entfällt die Angabe des high-Wertes.
(ELG...ice)
hl7:low
IVXB_TS
1 … 1
R
Dieses Element enthält den Zeitpunkt der Versorgung des Patienten. Im Fall eines Implantats ist hier Datum und Zeit der Implantation anzugeben. Erlaubter NullFlavor: UNK
In diesem Element wird das konkrete Gerät oder Implantat angegeben.
(ELG...ice)
@typeCode
cs
1 … 1
F
DEV
hl7:participantRole
1 … 1
R
(ELG...ice)
@classCode
cs
1 … 1
F
MANU
hl7:id
0 … *
R
Angabe der Identifikationnummer, z.B. Seriennummer, des Geräts oder Implantats, falls bekannt.
(ELG...ice)
hl7:playingDevice
1 … 1
R
(ELG...ice)
@classCode
cs
1 … 1
F
DEV
@determinerCode
cs
1 … 1
F
INSTANCE
hl7:code
CE (extensible)
1 … 1
R
Der Geräte-Code beschreibt den Typ des Geräts oder Implantats (zum Beispiel Armprothese, arterieller Stent).
Hat der Patient kein medizinisches Gerät oder Implantat: Wert aus ELGA_AbsentOrUnknownDevices
Liegen keine Informationen bezüglich Geräten oder Implantaten vor: Wert aus ELGA_AbsentOrUnknownDevices
Ist keine codierte Angabe für das medizinische Gerät oder Implantat möglich, wird im Element <originalText> der Verweis auf den narrativen Teil angegeben.
ansonsten: Wert aus ELGA_MedicalDevices
(ELG...ice)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.192 ELGA_AbsentOrUnknownDevices (DYNAMIC)
oder
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.190 ELGA_MedicalDevices (DYNAMIC)
Beispiel
Kein medizinisches Gerät oder Implantat
<participanttypeCode="DEV"> <participantRoleclassCode="MANU"> <playingDevice> <codecode="xxxx"codeSystem="xxx"displayName="No implant in situ (situation)"/></playingDevice><scopingEntity> <idroot="2.16.840.1.113883.3.3719"/></scopingEntity></participantRole></participant>
Beispiel
Keine Information bezüglich Geräten oder Implantaten
<participanttypeCode="DEV"> <participantRoleclassCode="MANU"> <playingDevice> <codecode="xxxx"codeSystem="xxxx"displayName="Presence of implanted device not known (situation)"/></playingDevice><scopingEntity> <idroot="2.16.840.1.113883.3.3719"/></scopingEntity></participantRole></participant>
Verweis auf die Angabe des medizinischen Geräts oder Implantats im narrtiven Teil.
(ELG...ice)
hl7:translation
CD
0 … 1
Dieses Feld wird verwendet, wenn Codes aus einem abweichenden Value Set angegeben werden.
z.B. für Übersetzungen in alternative Codesysteme oder wenn kein geeigneter Code im vorgegebene Value Set vorhanden ist.
(ELG...ice)
hl7:reference
0 … 1
Hier werden Verweise auf externe Dokumente zu den medizinischen Geräten oder Implantaten angegeben. Beinhaltet 1.2.40.0.34.11.13.3.17 ELGA ExternalDocument (DYNAMIC)
(ELG...ice)
7.3.19 Impfungsentry
Id
1.2.40.0.34.11.13.3.9
Gültigkeit
gültig ab 2017‑03‑11 18:41:40
Status
Entwurf
Versions-Label
0.1
Name
Impfungsentry
Anzeigename
Impfungsentry
Beschreibung
Codierte Angabe einer Impfung
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.3.9
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 2 Templates, Benutzt 4 Templates
Benutzt von
als
Name
Version
1.2.40.0.34.11.13.2.7
Containment
Impfungen (0.1)
2017‑03‑11 18:38:41
1.2.40.0.34.11.13
CDA ELGA Patient Summary (0.1)
2016‑08‑30 16:19:25
Benutzt
als
Name
Version
1.2.40.0.34.11.13.3.22
Containment
Impfstoff
DYNAMIC
1.2.40.0.34.11.13.3.16
Containment
Author (Body) PS
DYNAMIC
1.2.40.0.34.11.13.3.20
Containment
Informant (Body) PS (0.1)
DYNAMIC
1.2.40.0.34.11.13.3.17
Containment
ELGA ExternalDocument (0.1)
DYNAMIC
Beispiel
Beispiel
<substanceAdministrationtypeCode="SBADM"moodCode="EVN"negationInd="true|false"> <templateIdroot="2.16.840.1.113883.10.20.1.24"/><templateIdroot="1.3.6.1.4.1.19376.1.5.3.1.4.12"/><idroot=""extension=""/><codecode="IMMUNIZ"codeSystem="1.3.5.1.4.1.19376.1.5.3.2"codeSystemName="IHEActCode"/><text> <referencevalue="#xxx"/></text><statusCodecode="completed"/><effectiveTimevalue=""/><!-- The reasonCode would normally provide a reason why the immunization was not performed. It isn't supported by CDA R2, and so comments will have to suffice. <reasonCode code= codeSystem= codeSystemName='ActNoImmunizationReasonIndicator'/> --> <routeCodecode=""codeSystem=""codeSystemName="RouteOfAdministration"/><doseQuantityvalue=""units=""/><consumabletypeCode="CSM"> <manufacturedProductclassCode="MANU"> <manufacturedMaterialclassCode="MMAT"determinerCode="KIND"> <codecode=""codeSystem=""codeSystemName=""> <originalText> <referencevalue="#yyy"/></originalText></code></manufacturedMaterial></manufacturedProduct></consumable><!-- An optional entry relationship that provides prescription activity --> <entryRelationshiptypeCode="REFR"> <templateIdroot="1.3.6.1.4.1.19376.1.5.3.1.4.7.3"/><!-- ... --> </entryRelationship><!-- An optional entry relationship that identifies the immunization series number --> <entryRelationshiptypeCode="SUBJ"> <observationclassCode="OBS"moodCode="EVN"> <templateIdroot="2.16.840.1.113883.10.20.1.46"/><codecode="30973-2"displayName="Dose Number"codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC"/><statusCodecode="completed"/><valuexsi:type="INT"value=""/></observation></entryRelationship><entryRelationshipinversionInd="false"typeCode="CAUS"> <observationclassCode="OBS"moodCode="EVN"> <templateIdroot="2.16.840.1.113883.10.20.1.28"/><templateIdroot="1.3.6.1.4.1.19376.1.5.3.1.4.5"/><templateIdroot="2.16.840.1.113883.10.20.1.54"/><idroot=""extension=""/></observation></entryRelationship><!-- Optional <entryRelationship> element containing comments --> </substanceAdministration>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:substanceAdministration
R
Eine Impfung wird mittels SubstanceAdministration (entspricht einer Medikamentenverordnung) dargestellt. In einem solchen Entry kann auch dargestellt werden, warum eine bestimmte Impfung nicht durchgeführt wurde (negationInd=true)
... aus dem epSOS entry: An immunization is a substance administration event. An immunization entry may be a record of why a specific immunization was not performed. In this case, negationInd shall be set to "true", otherwise, it shall be false.
(Imp...try)
@classCode
cs
1 … 1
F
SBADM
@moodCode
cs
1 … 1
F
EVN
hl7:templateId
II
1 … 1
M
(Imp...try)
@root
uid
1 … 1
F
1.2.40.0.34.11.13.3.9
hl7:id
II
0 … *
(Imp...try)
hl7:code
CE (extensible)
1 … 1
M
(Imp...try)
@code
CONF
1 … 1
F
IMMUNIZ
@codeSystem
1 … 1
F
2.16.840.1.113883.5.4 (Act Code)
hl7:statusCode
CS (erforderlich)
1 … 1
M
Fester Wert: "completed"
(Imp...try)
@code
CONF
1 … 1
F
completed
hl7:effectiveTime
1 … 1
R
Dieses Element enthält den Zeitpunkt der Impfung.
Erlaubter NullFlavor: UNK
(Imp...try)
hl7:consumable
1 … 1
M
Codierte Angabe des Impfstoffs. Codierte Angabe, dass keine Impfungen vorliegen oder dass keine Informationen bezüglich Impfungen vorliegen. Beinhaltet 1.2.40.0.34.11.13.3.22 Impfstoff (DYNAMIC)
(Imp...try)
wo [hl7:manufacturedProduct [hl7:templateId [@root='1.2.40.0.34.11.13.3.22']]]
Codierte Darstellung des Impfstoffes. Alternativ wird angegeben, dass keine Impfungen erfolgt sind oder dass keine Information über verabreichte Impfungen vorliegt.
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 3 Templates, Benutzt 1 Template
Ein Code zur Beschreibung des Eingriffs oder der Behandlung.
Kann kein Code angegeben werden, wird nur über das Element <orginalText> auf den narrativen Teil verwiesen.
Liegen keine Eingriffe oder sonstige Behandlungen vor, enthält @value den entsprechenden Wert aus dem ValueSet ELGA_AbsentOrUnknownProcedures
Liegen keine Informationen vor, enthält @value den entsprechenden Wert aus dem ValueSet ELGA_AbsentOrUnknownProcedures.
Angabe eines Codes aus dem ValueSet ELGA_Procedures
(ELG...ure)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.194 ELGA_Procedures (DYNAMIC)
oder
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.193 ELGA_AbsentOrUnknownProcedures (DYNAMIC)
hl7:originalText
ED
0 … 1
R
(ELG...ure)
hl7:reference
TEL
1 … 1
M
(ELG...ure)
hl7:translation
CE (extensible)
0 … 1
Dieses Feld wird verwendet, wenn Codes aus einem abweichenden ValueSet angegeben werden,
z.B. für Übersetzungen in alternative Codesysteme oder wenn kein geeigneter Code im vorgegebene ValueSet vorhanden ist.
(ELG...ure)
hl7:statusCode
CS (erforderlich)
0 … 1
Status der Procedure: Erlaubte Werte sind: completed | active | aborted | cancelled
Anmerkung: Allgemein für Procedures in ELGA werden alle 4 status-Werte sinnvoll und notwendig sein. Im Context des PS Einschränkugn auf completed und active ? VS für ELGA definiert ?
(ELG...ure)
hl7:effectiveTime
IVL_TS
0 … 1
Stellt die Zeit dar, zu der die Procedure stattfand (@moodCode=EVN) oder zu der die Procedure geplant ist (@moddCode=INT)
(ELG...ure)
hl7:methodCode
CE (extensible)
0 … *
Angewandte Methode
(ELG...ure)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.195 ELGA_ProceduresMethod (DYNAMIC)
hl7:approachSiteCode
CE (extensible)
0 … *
Anatomische Herangehensweise
(ELG...ure)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.197 ELGA_ProcedureApproachSite (DYNAMIC)
hl7:targetSiteCode
CE (extensible)
0 … *
Anatomische Bezeichnung für das Ziel des Eingriffes
(ELG...ure)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.196 ELGA_ProcedureTargetSite (DYNAMIC)
Das Code-Element dient zur Angabe der Art des erfassten diagnostischen Resultats. Kein definiertes Value Set, Code aus CodeSystem 2.16.840.1.113883.6.1 (LOINC)
(ELG...ion)
@codeSystem
CONF
0 … 1
F
2.16.840.1.113883.6.1 (Logical Observation Identifier Names and Codes)
@codeSystemName
0 … 1
F
LOINC
hl7:statusCode
CS (erforderlich)
1 … 1
M
(ELG...ion)
@code
CONF
1 … 1
F
completed
hl7:effectiveTime
IVL_TS
1 … 1
R
Zeitpunkt der Erfassung
(ELG...ion)
Auswahl
1 … 1
Das Element value dient zur Angabe des diagnostischen Resultats. Folgende Möglichkeiten bestehen:
hl7:value[@xsi:type='CD'] Angabe eines Codes
hl7:value[@xsi:type='PQ'] Angabe einer physikalischen Größe unter Angabe der Maßeinheit
beliebige Angabe
Elemente in der Auswahl:
hl7:value
hl7:value
hl7:value
hl7:value
0 … 1
R
(ELG...ion)
@xsi:type
1 … 1
F
CD
hl7:value
0 … 1
R
(ELG...ion)
@xsi:type
0 … 1
F
PQ
@value
int
0 … 1
@unit
cs
0 … 1
Constraint
Wird eine physikalische Größe angeben, so ist auch die entsprechende Maßeinheit anzugeben.
hl7:value
ANY
0 … 1
R
(ELG...ion)
hl7:interpretationCode
CE (extensible)
0 … 1
R
(ELG...ion)
CONF
Der Wert von @code sollte gewählt werden aus dem Value Set 1.2.40.0.34.10.13 ELGA_ObservationInterpretation (DYNAMIC)
Angegeben wird ein Kennzeichen (ja/nein). Liegt eine aktuelle Schwangerschaft vor (ja), kann auch der voraussichtliche Geburtstermin angegeben werden (Schätzung oder Berechnung nach letzter Regelblutung oder Eisprung) sowie das Datum der Schätzung/Berechnung.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.3.10
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 2 Templates, Benutzt 4 Templates
Angegeben wird ein Kennzeichen (ja/nein). Liegt eine aktuelle Schwangerschaft vor (ja), kann auch der voraussichtliche Geburtstermin angegeben werden (Schätzung oder Berechnung nach letzter Regelblutung oder Eisprung) sowie das Datum der Schätzung/Berechnung.
Kontext
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.3.24
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 3 Templates, Benutzt 3 Templates
Elternknoten des Template-Element mit Id 1.2.40.0.34.11.13.3.11
Klassifikation
CDA Entry Level Template
Offen/Geschlossen
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 2 Templates, Benutzt 3 Templates
Benutzt von
als
Name
Version
1.2.40.0.34.11.13.2.8
Containment
Lebensstil (0.1)
2017‑03‑12 11:13:38
1.2.40.0.34.11.13
CDA ELGA Patient Summary (0.1)
2016‑08‑30 16:19:25
Benutzt
als
Name
Version
1.2.40.0.34.11.13.3.16
Containment
Author (Body) PS
DYNAMIC
1.2.40.0.34.11.13.3.20
Containment
Informant (Body) PS (0.1)
DYNAMIC
1.2.40.0.34.11.13.3.17
Containment
ELGA ExternalDocument (0.1)
DYNAMIC
Beispiel
Beispiel
<observationclassCode="OBS"moodCode="EVN"> <templateIdroot="1.2.40.0.34.11.13.3.11"/><idroot="1.2.3.999"extension="--example only--"/><codecode="229819007"codeSystem="2.16.840.1.113883.6.96"/><statusCodecode="completed"/><effectiveTme> <lowvalue="20170909164932"/></effectiveTme><valuexsi:type="CE"code="449868002"displayName="Current every day smoker"codeSystem="2.16.840.1.113883.6.96"/></observation>
Item
DT
Kard
Konf
Beschreibung
Label
hl7:observation
1 … 1
M
(Leb...try)
@classCode
cs
1 … 1
F
OBS
@moodCode
cs
1 … 1
F
EVN
hl7:templateId
II
1 … 1
M
(Leb...try)
@root
uid
1 … 1
F
1.2.40.0.34.11.13.3.11
hl7:id
II
0 … *
(Leb...try)
hl7:code
CE (extensible)
1 … 1
M
(Leb...try)
@code
CONF
1 … 1
F
229819007
@codeSystem
1 … 1
F
2.16.840.1.113883.6.96 (SNOMED Clinical Terms)
hl7:statusCode
CS (erforderlich)
1 … 1
M
(Leb...try)
@code
CONF
1 … 1
F
completed
hl7:effectiveTme
IVL_TS
1 … 1
M
(Leb...try)
hl7:value
1 … 1
M
Codierte Angabe des aktuelles Raucher-Status
(Leb...try)
@xsi:type
cs
1 … 1
F
CD
CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.204 ELGA_CurrentSmokingStatus (DYNAMIC)
Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt von / Benutzt
Benutzt von 0 Transactions und 24 Templates, Benutzt 2 Templates
Benutzt von
als
Name
Version
1.2.40.0.34.11.3.2.10
Inklusion
Schmerz
2017‑08‑25 10:05:14
1.2.40.0.34.11.3.2.10
Inklusion
Schmerz
2011‑12‑19
1.2.40.0.34.11.3.2.11
Inklusion
Orientierung und Bewusstseinslage
2017‑08‑25 10:05:50
1.2.40.0.34.11.3.2.11
Inklusion
Orientierung und Bewusstseinslage
2011‑12‑19
1.2.40.0.34.11.3.2.12
Inklusion
Soziale Umstände und Verhalten
2017‑08‑25 10:06:25
1.2.40.0.34.11.3.2.12
Inklusion
Soziale Umstände und Verhalten
2013‑10‑10
1.2.40.0.34.11.3.2.13
Inklusion
Kommunikation
2017‑08‑25 10:06:59
1.2.40.0.34.11.3.2.13
Inklusion
Kommunikation
2011‑12‑19
1.2.40.0.34.11.3.2.14
Inklusion
Rollenwahrnehmung und Sinnfindung
2017‑08‑25 10:07:45
1.2.40.0.34.11.3.2.14
Inklusion
Rollenwahrnehmung und Sinnfindung
2011‑12‑19
1.2.40.0.34.11.3.2.3
Inklusion
Mobilität
2017‑08‑25 09:59:59
1.2.40.0.34.11.3.2.3
Inklusion
Mobilität
2011‑12‑19
1.2.40.0.34.11.3.2.4
Inklusion
Körperpflege und Kleiden
2017‑08‑25 10:01:44
1.2.40.0.34.11.3.2.4
Inklusion
Körperpflege und Kleiden
2011‑12‑19
1.2.40.0.34.11.3.2.5
Inklusion
Ernährung
2017‑08‑25 10:02:29
1.2.40.0.34.11.3.2.5
Inklusion
Ernährung
2011‑12‑19
1.2.40.0.34.11.3.2.6
Inklusion
Ausscheidung
2017‑08‑25 10:03:03
1.2.40.0.34.11.3.2.6
Inklusion
Ausscheidung
2011‑12‑19
1.2.40.0.34.11.3.2.7
Inklusion
Hautzustand
2017‑08‑25 10:03:35
1.2.40.0.34.11.3.2.7
Inklusion
Hautzustand
2011‑12‑19
1.2.40.0.34.11.3.2.8
Inklusion
Atmung
2017‑08‑25 10:04:09
1.2.40.0.34.11.3.2.8
Inklusion
Atmung
2011‑12‑19
1.2.40.0.34.11.3.2.9
Inklusion
Schlaf
2017‑08‑25 10:04:42
1.2.40.0.34.11.3.2.9
Inklusion
Schlaf
2015‑05‑06
Benutzt
als
Name
Version
1.2.40.0.34.11.1.2.8
Containment
Risiken
DYNAMIC
1.2.40.0.34.11.1.2.9
Containment
Hilfsmittel und Ressourcen
DYNAMIC
Item
DT
Kard
Konf
Beschreibung
Label
hl7:component
0 … 1
Beinhaltet 1.2.40.0.34.11.1.2.8 Risiken (DYNAMIC)
(Ris...cen)
wo [hl7:section [hl7:templateId [@root='1.2.40.0.34.11.1.2.8']]]
@typeCode
0 … 1
F
COMP
@contextConductionInd
0 … 1
F
true
hl7:component
0 … 1
Beinhaltet 1.2.40.0.34.11.1.2.9 Hilfsmittel und Ressourcen (DYNAMIC)
(Ris...cen)
wo [hl7:section [hl7:templateId [@root='1.2.40.0.34.11.1.2.9']]]
@typeCode
0 … 1
F
COMP
@contextConductionInd
0 … 1
F
true
8 Technische Konformitätsprüfung
Die Prüfung einer XML-Instanz gegenüber Konformität zu diesem Leitfaden erfolgt gemäß den entsprechenden Kapitel im "Allgemeinen Implementierungsleitfaden".
Diese Erstversion ist erst im Entstehen. Änderungen können Sie in der Versionsgeschichte dieser Seite einsehen.
10.6 Impressum
Medieneigentümer, Herausgeber, Hersteller, Verleger:
ELGA GmbH, Treustraße 35-43, Wien Österreich
Geschäftsführer: DI Dr. Günter Rauchegger.
Email: cda@elga.gv.at
Redaktion, Projektleitung, Koordination:
Mag. Dr. Stefan Sabutsch, stefan.sabutsch@elga.gv.at
Nutzung: Das Dokument enthält geistiges Eigentum der Health Level Seven Int. und HL7 Austria, Eggenberger Allee 11, 8020 Graz; www.hl7.at. Die Nutzung ist zum Zweck der Erstellung medizinischer Dokumente ohne Lizenz- und Nutzungsgebühren ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.