Laborbefund Version 2.06.03

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche





Inhaltsverzeichnis

1 Informationen über dieses Dokument

1.1 Allgemeines

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

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

1.2 Sprachliche Gleichbehandlung

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

1.3 Verbindlichkeit

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

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

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

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

1.4 Zielgruppe

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

1.5 Hinweis auf verwendete Grundlagen

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

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

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

1.6 Danksagung

Die ELGA GmbH weist auf das Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen“ hin, welches vom Verband der Hersteller von IT-Lösungen für das Gesundheitswesen (VHitG) herausgegeben wurde. Einige Ausführungen in dem genannten Dokument wurden in das vorliegende Dokument übernommen. Das Urheberrecht an dem Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen“, wird im vollen Umfang respektiert.


1.7 Revisionsliste

Diese Version ist eine Nebenversion zur Hauptversion 2.06 und ersetzt diese. Die durchgeführten Änderungen ersehen Sie der Revisionsliste.

1.8 Weitere unterstützende Materialien

Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH [1] weitere Dateien und Dokumente zur Unterstützung bereitgestellt: Beispieldokumente, zu verwendende Codes, Vorgaben zur Registrierung von CDA-Dokumenten, das Referenz-Stylesheet zur Darstellung von CDA-Dokumenten, Algorithmen zur Prüfung der Konformität von CDA-Dokumenten etc.


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

1.9 Bedienungshinweise für die PDF-Version

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

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

1.10 Impressum

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

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

Abbildungen: © ELGA GmbH

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

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

2 Harmonisierung

Erarbeitung des Implementierungsleitfadens
Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der „Arbeitsgruppe Laborbefund“ im Zeitraum zwischen 2008 und 2012, bestehend aus den unten genannten Personen.

Autoren
Kürzel Organisation Person1
Herausgeber, Editor, CDA Koordinator
SSA ELGA GmbH Stefan Sabutsch
Autoren, Fachkoordinatoren und Moderatoren
SS Fachhochschule Technikum Wien Stefan Sauermann
AM Fachhochschule Technikum Wien, HL7 Austria Alexander Mense
SSA ELGA GmbH, HL7 Austria Stefan Sabutsch
MF Fachhochschule Technikum Wien Matthias Frohner
Autoren
Organisation Person1
Begleitung, Fachliche Beratung
Medicon Medical Consulting Georg Paucek
Ärztliche Vertreter
Kurienversammlung der niedergelassenen Ärzte der OÖ Ärztekammer Franz Burghuber
Österreichische Ärztekammer, KH St. Pölten, Inst. für Laboratoriumsmedizin Alexander Haushofer
Österreichische Ärztekammer, Wiener KAV, Sozialmedizinisches Zentrum Ost - Donauspital, Institut für Labormedizin Jörg Hofmann
Österreichische Ärztekammer, ON-K 238 Gerhard Holler
Rotes Kreuz, Blutspendezentrale Wien Christof Jungbauer
Sozialmedizinisches Zentrum Ost Walter Krugluger, Thomas Leitha
Elisabethinen Linz Helmut Mittermayer
Initiative-ELGA Susanna Michalek
Medizinisches Labor Perné Johann Perné
Österreichische Ärztekammer, Bundesfachgruppe Labor Georg Mustafa
Österreichische Ärztekammer Thomas Szekeres
Krankenhausträger
Vinzenz Gruppe Krankenhausbeteiligungs- und Management GmbH Bernhard Böhm
KAV Wien, Generaldirektion Christian Cebulla
Wilhelminenspital der Stadt Wien, Zentrallabor, KAV Wien Georg Endler
KFJ – Sozialmed. Zentrum Süd, Institut für Laboratoriumsdiagnostik Manuela Födinger
Univ.Klin. Innsbruck, Zentralinst. Labordiagnostik Andrea Griesmacher
ÖQUASTA; KH Hietzing + NZ Rosenhügel, Institut f. Labordiagnostik Walter-Michael Halbmayer
LKH Vöcklabruck, Institut f. Med.Chem. Labordiagnostik u. Blutdepot Susanne Hauptlorenz
Wiener Krankenanstaltenverbund, KAV-IT Konrad Hölzl
KAV Wien,, Wilhelminenspital, Zentrallabor, ÖGLMKC Wolfgang Hübl
GESPAG Gesundheitsinformatik-Bereichsleiter Christian Kampenhuber
KABEG (LKH Klagenfurt, Wolfsberg, Lass und Hermagor) Gerald Regenfelder
Tilak, Informationstechnologie/IT-Abteilung Dietmar Reiter
LK Weinviertel Mistelbach, Laborinstitut, NÖ LK-Holding Harald Rubey
Med. Uni. Wien, Klinik f. Blutgruppenserologie u. Transfusionsmedizin Dieter Schwartz
Kages Zentrallabor Beate Tiran
Softwarehersteller / Befundprovider
Max management Consulting GmbH Helmuth Gamper
act Management Consulting GmbH Bernhard Göbl
Systema Christian Kraml, Herbert Matzenberger
vision4health Deutschland GmbH & Co. KG Michael Krausenbaum
Labatech Handelsgesellschaft m.b.H. Hans Richter
Assista Laborelectronics GmbH Wolfgang Sischka
HCS, Health Communication Service Christoph Unfried
Universitäten / Fachhochschulen
Fachhochschule Technikum Wien Ferenc Gerbovics, Philipp Urbauer
Medizinische Universität Graz, Institut für Hygiene, Mikrobiologie und Umweltmedizin Harald Kessler
Patronanz, Akkordierung, Ergänzungen, Zustimmung
Organisation Person1
Bundesministerium für Gesundheit Clemens Auer
ELGA GmbH Hubert Eisl, Susanne Herbek, Martin Hurch, Oliver Kuttin
Medizinisches Zentrallaboratorium GmbH Peter Fraunberger
Steiermärkische Krankenanstalten-ges. m.b.H. Josef Galler
Solve Consulting Gerhard Gretzl
Landeskrankenhaus Feldkirch, Institut für Pathologie Ulrike Gruber-Mösenbacher
Krankenhaus der Barmherzigen Schwestern Ried, Inst. f. Pathologie Milo Halabi
A.ö. Krankenhaus der Elisabethinen Linz, Institut für Medizinische und Chemische Labordiagnostik Elisabeth Haschke-Becher
Oö. Gesundheitsfonds / eHealth Management Wolfgang Hiesl
Med. Uni. Wien, Klinisches Institut für Medizinische und Chemische Labordiagnostik Stylianos Kapiotis
B&S Zentrallabor Peter Konrath
Tilak, Abteilungsleiter Informationstechnologie/IT-Abteilung Georg Lechleitner
Steiermärkische Krankenanstalten-ges. m.b.H. Hubert Leitner
Österreichische Agentur für Gesundheit und Ernährungssicherheit GmbH - AGES Helmut Lindorfer
Österreichische Ärztekammer, Sekretariat Sabine Manhardt
Labor Dr. Hans Georg Mustafa, Fachgesellschaft Labormedizin Hans Georg Mustafa
GRZ IT Center Linz GmbH Achim Mühlberger
Gibodat EDV- und Organisationsberatungs GmbH Michael Nebel
AUVA - Unfallkrankenhaus Meidling, Labor Susan Netzl
A.ö. Krankenhaus der Elisabethinen Linz, Institut für Medizinische und Chemische Labordiagnostik, EDV Claudia Perndl
BKH Hall in Tirol, EDV Sven Plattner
NÖ Landeskliniken-Holding Thomas Pöckl
Sozialmedizinisches Zentrum Ost – Donauspital, Pathologisch-Bakteriologisches Institut Angelika Reiner-Concin
NÖ Landesklinikenholding Alexander Schanner
Österreichische Ärztekammer, Labor Schobesberger Gerhard Schobesberger
Medizinische Universität Wien / AKH Wien, klinische Abteilung für Medizinisch-chemische Labordiagnostik Christian Schweiger
Bartelt GmbH Peter Schöttel
AKH Linz, Institut für Laboratoriumsmedizin Herbert Stekel
HCS, Health Communication Service Romana Thiel
Labene Michael Danninger
Telekom Austria Peter Uher
Assista Michael Weidenauer
Medizinische Universität Wien Thomas Wrba
Andere ELGA Arbeitsgruppen
Entlassungsbrief Arzt und Pflege CodeWerk Software Services and Development GmbH Jürgen Brandstätter
Befundbericht Radiologie AIMC
Lindner TAC
Martin Weigl
Andreas Lindner

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

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


1 Personen ohne Titel

3 Einleitung

3.1 Ausgangssituation

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

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

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

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

3.2 Zweck

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

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

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

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

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

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

3.3 Vorgaben zum medizinischen Inhalt

3.3.1 Allgemeiner Laborbefund

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

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

Tabelle 1: Im Laborbefund abzubildende medizinische Daten

3.3.1.1 Bereiche (Specialities)

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

Abbildung 3: Gliederung nach Bereiche /Specialities
Abbildung 1: Gliederung nach Bereiche /Specialities

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

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

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

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

3.3.1.2 Gruppen (Befundgruppen)

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

Strukturierungsmöglichkeiten Body.
Abbildung 2: Strukturierungsmöglichkeiten Body

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

Ausschnitt Beispielbefund.
Abbildung 3: Ausschnitt Beispielbefund

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

Ausschnitt Bakteriologie Beispielbefund.
Abbildung 4: Ausschnitt Bakteriologie Beispielbefund

3.3.2 Mikrobiologische Befunde

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

Dementsprechend ist folgende hierarchische Struktur abzubilden:
Mikrobiologischer Befund.jpg

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

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

Tabelle 3: Im mikrobiologischen Befund abzubildende medizinische Daten

Zur Kennzeichnung des Mikrobiologiebefundes über die ServiceEvents siehe Kapitel 5.4.1.1.

3.4 IHE Konformität

3.4.1 Referenz

Der vorliegende Leitfaden baut auf den Definitionen des „Laboratory Technical Framework Volume 3 (LAB TF-3) Revision 3.0, 2011“ [3] auf, welche durch diesen Leitfaden weiter eingeschränkt werden. Dadurch erhalten die entsprechenden Templates ihre Gültigkeit und sind aus Konformitätsgründen bei Komponenten, welche über eine entsprechende Definition verfügen, auch anzugeben.

3.4.2 Angabe der Adresse und Telefonnummer

Entsprechend den Vorgaben des IHE Frameworks für Labor sind für Personen und Organisationen die Angabe einer Adresse (addr-Element) und Telekom Verbindung (telecom-Element) verpflichtend. Diese können jedoch mit einem nullFlavor versehen werden.

4 Anwendungsfälle

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

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

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

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

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

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

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

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

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

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

Ergänzungen und Korrekturen von Laborbefunden werden unterstützt

4.1 Anwendungsfall LAB01: „Laboruntersuchung eines niedergelassenen Labors“

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

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

4.2 Anwendungsfall LAB02: „Laboruntersuchung im Rahmen eines stationären Aufenthalts in einem Spital“

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

4.3 Anwendungsfall LAB03: „Teilweise externe Vergabe von Laboruntersuchungen“

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

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

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

4.4 Anwendungsfall LAB04: „Update von Laborbefunden“

Ein fertiggestellter Laborbefund wird korrigiert oder ergänzt, um

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

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

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

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

5 Administrative Daten (CDA Header)

Dieses Kapitel basiert auf dem entsprechenden Kapitel im „Allgemeinen Implementierungsleitfaden“ [4] und beschreibt die laborspezifischen Implementierungen bzw. über die Basisdefinitionen hinausgehenden Spezifikationen zum Thema „Laborbefund“.

Feld Element Opt Kapitel
Daten zum Dokument
Realm Code ClinicalDocument/realmCode M Link
Dokumentenformat ClinicalDocument/typeId M Link
Dokumenten-ID ClinicalDocument/id M Link
Vertraulichkeitscode ClinicalDocument/confidentialityCode M Link
Sprachcode ClinicalDocument/languageCode M Link
Template ClinicalDocument/templateId M Link
Dokumenttitel ClinicalDocument/title M Link
Dokumentenklasse ClinicalDocument/code M Link
Dokumentdatum ClinicalDocument/effectiveTime M Link
Versionierung des Dokuments ClinicalDocument/setId
ClinicalDocument/versionNumber
M Link
Teilnehmende Parteien
Patient ClinicalDocument/recordTarget M Link
Verwalter des originalen Dokuments ClinicalDocument/custodian M Link
Rechtlicher Unterzeichner ClinicalDocument/legalAuthenticator M
[1..1]
Link
Verfasser des Dokuments ClinicalDocument/author M
[1..*]
Link
Vorgesehener Empfänger ClinicalDocument/informationRecipient O
[0..*]
Link
Validatoren ClinicalDocument/authenticator O
[0..*]
Link
Referenz zum Auftrag
Auftraggeber (IHE „Ordering Provider“) ClinicalDocument/participant@typeCode=“REF“ R
[1..1]
Link
Auftragsidentifikation ClinicalDocument/inFulfillmentOf/order M
[1..1]
Link
Dokumentation der Gesundheitsdienstleistung
Service Events ClinicalDocument/documentationOf/serviceEvent M
[1..*]
Link
Durchführende Labors ClinicalDocument/documentationOf/serviceEvent/performer O
[0..*]
Link
Informationen zum Patientenkontakt
Encounter ClinicalDocument/componentOf/encompassingEncounter O
[0..1]
Link

Tabelle 4: Überblick administrative Daten (Header)

5.1 Dokumentenstruktur

5.1.1 Elemente ohne spezielle Vorgaben

  • XML Metainformationen
  • Wurzelelement
  • Hoheitsbereich („realmCode“)
  • Dokumentformat („typeId“)
  • Dokumenten-Id („id”)
  • Erstellungsdatum des Dokuments („effectiveTime“)
  • Vertraulichkeitscode („confidentialityCode“)
  • Sprachcode des Dokuments („languageCode“)

Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.


Auszug aus dem Allgemeinen Implementierungsleitfaden

5.1.2 XML Metainformationen

5.1.2.1 Zeichencodierung

CDA-Dokumente MÜSSEN mit UTF-8 (8-Bit Universal Character Set Transformation Format, nach RFC 3629 / STD 63 (2003)) codiert werden.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”?>
<ClinicalDocument xmlns="urn:hl7-org:v3">
:


5.1.2.2 Hinterlegung eines Stylesheets

Um ein CDA-Dokument in einem Webbrowser anzeigen zu können, muss es nach HTML tranformiert werden. Das kann durch eine XSLT-Transformation (ein so genanntes „Stylesheet“) geschehen. Ist das Stylesheet im angegebenen Pfad erreichbar, wird dieses beim Öffnen des CDA-Dokuments mit einem Browser üblicherweise automatisch auf das CDA-Dokument angewandt und die Darstellung gerendert.

ELGA stellt zur einheitlichen Darstellung von CDA-Dokumenten ein „Referenz-Stylesheet“ zur Verfügung (Download ist von der ELGA Website http://www.elga.gv.at/cda möglich). Da der Zugriff auf XSLT-Programme von den meisten Browsern eingeschränkt ist, wird kein absoluter Pfad auf eine Webressource angegeben.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”?>
<?xml-stylesheet type="text/xsl" href="ELGA_Stylesheet_v1.0.xsl"?>
<ClinicalDocument xmlns="urn:hl7-org:v3">
:

Das Stylesheet „ELGA_Stylesheet_v1.0.xsl“ MUSS angegeben werden [M]. Die Angabe eines Pfades ist NICHT ERLAUBT. Ausnahmen können für automatisiert erstellte Dokumente notwendig sein, diese müssen im allgemeinen und speziellen Leitfäden beschrieben werden.

5.1.3 Wurzelelement

Der XML-Namespace für CDA Release 2.0 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser MUSS in geeigneter Weise in jeder CDA XML Instanz genannt werden. In speziellen Leitfäden können weitere namespace-Präfixe angegeben werden.

Für ELGA CDA-Dokumente MUSS der Zeichensatz UTF-8 verwendet werden.

CDA-Dokumente beginnen mit dem Wurzelelement ClinicalDocument, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.

<ClinicalDocument xmlns="urn:hl7-org:v3">
   <!-- CDA Header -->
      … siehe Beschreibung CDA R2 Header …
   <!-- CDA Body -->
   <component>
      <structuredBody>
         … siehe Beschreibung CDA R2 Body …
      </structuredBody>
   </component>
</ClinicalDocument>

5.1.4 Hoheitsbereich des Dokuments („realmCode“)

Dieses Element kennzeichnet, dass das Dokument aus dem Hoheitsbereich Österreich (bzw. Bereich der HL7 Affiliate Austria, Code „AT“) stammt.

5.1.4.1 Strukturbeispiel

<realmCode code="AT'"/>


5.1.4.2 Spezifikation

Element/Attribut DT Kard Konf Beschreibung
realmCode CS
CNE
1..1 M Hoheitsbereich des Dokuments

Fester Wert: @code = AT
(aus ValueSet „ELGA_RealmCode“)

5.1.5 Dokumentformat („typeId“)

Dieses Element kennzeichnet, dass das Dokument im Format CDA R2 vorliegt.

5.1.5.1 Strukturbeispiel

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>


5.1.5.2 Spezifikation

Element/Attribut DT Kard Konf Beschreibung
typeId II 1..1 M Dokumentformat CDA R2
Feste Werte:
@root = 2.16.840.1.113883.1.3'
@extension = POCD_HD000040

5.1.6 Dokumenten-Id („id”)

Die Dokumenten-Id eines CDA-Dokuments ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit eindeutig und für alle Zeit identifiziert. Ein CDA-Dokument hat genau eine Id.

5.1.6.1 Strukturbeispiel

<id
  root="1.2.40.0.34.99.111.1.1"
  extension="134F989"
  assigningAuthorityName="Amadeus Spital"/>

5.1.6.2 Spezifikation

Es MUSS eine gültige und innerhalb des ID-Pools eindeutige Dokumenten-ID angegeben werden.

Element/Attribut DT Kard Konf Beschreibung
id II 1..1 M Dokumenten-Id

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

5.1.7 Erstellungsdatum des Dokuments („effectiveTime“)

5.1.7.1 Spezifikation

Id1.2.40.0.34.11.90008
ref
elgabbr-
Gültigkeit2016‑07‑21
Andere Versionen mit dieser Id:
  • Kblank.png CDeffectiveTime vom 2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDeffectiveTimeAnzeigenameCD effectiveTime
Beschreibung

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

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

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-8Kyellow.png Erstellungsdatum Kyellow.png Datensatz
BeziehungVersion: Template 1.2.40.0.34.11.90008 CD effectiveTime (2016‑07‑21)
ref
elgabbr-
Beispiel
Nur Datum: Zeitpunkt als Datum (ohne Zeit) im Format YYYYMMDD
<effectiveTime value="20081224"/>
Beispiel
Datum, Zeit und Zeitzone: Zeitpunkt als Datum mit Zeit und Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM
<effectiveTime value="20081224082015+0100"/>
ItemDTKardKonfBeschreibungLabel
hl7:effectiveTime
TS.AT.TZ1 … 1M
Erstellungsdatum des Dokuments.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(CDe...ime)
 
Target.png
elgagab-data​element-8Kyellow.png Erstellungsdatum Kyellow.png Datensatz

5.1.8 Vertraulichkeitscode („confidentialityCode“)

5.1.8.1 Spezifikation

Id1.2.40.0.34.11.90009
ref
elgabbr-
Gültigkeit2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDconfidentialityCodeAnzeigenameCD confidentialityCode
Beschreibung

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

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

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

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-266Kyellow.png Vertraulichkeitscode Kyellow.png Datensatz
BeziehungVersion: Template 1.2.40.0.34.11.90009 CD confidentialityCode (2013‑11‑07)
ref
elgabbr-
Beispiel
Beispiel
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25" displayName="normal"/>
ItemDTKardKonfBeschreibungLabel
hl7:confidentialityCode
CE1 … 1M(CDc...ode)
 
Target.png
elgagab-data​element-266Kyellow.png Vertraulichkeitscode Kyellow.png Datensatz
Treetree.png@code
CONF1 … 1FN
Treetree.png@codeSystem
1 … 1F2.16.840.1.113883.5.25 (Confidentialty (HL7))
Treetree.png@displayName
1 … 1Fnormal

5.1.9 Sprachcode des Dokuments („languageCode“)

5.1.9.1 Spezifikation

Id1.2.40.0.34.11.90010
ref
elgabbr-
Gültigkeit2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDlanguageCodeAnzeigenameCD languageCode
Beschreibung

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

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

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-265Kyellow.png Sprachcode Kyellow.png Datensatz
BeziehungVersion: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07)
ref
elgabbr-
Beispiel
Beispiel
<languageCode code="de-AT"/>
ItemDTKardKonfBeschreibungLabel
hl7:language​Code
CS.LANG1 … 1MSprachcode des Dokuments.(CDl...ode)
 
Target.png
elgagab-data​element-265Kyellow.png Sprachcode Kyellow.png Datensatz
Treetree.png@code
CONF1 … 1Fde-AT


5.1.10 Elemente mit spezielle Vorgaben

5.1.10.1 Template („ClinicalDocument/templateId“)

Das Template definiert die Summe der Einschränkungen dieser Spezifikation in Bezug auf den CDA R2 Standard. Eine templateID für den ELGA Laborbefund ist anzugeben. Ein Dokument, welches dem vorliegenden Implementierungsleitfaden folgt, muss auch dem übergeordneten „Allgemeinen Implementierungsleitfaden“ folgen. Als templateID für CDA Labordokumente gemäß diesem Leitfaden ist 1.2.40.0.34.11.4 zu verwenden.

5.1.10.1.1 Strukturbeispiel
<ClinicalDocumentxmlns="urn:hl7-org:v3">
  : 	
  <!-- ELGA CDA Dokumente -->
  <templateId root="1.2.40.0.34.11.1"/>
  <!-- ELGA CDA Laborbefund -->
  <templateId root="1.2.40.0.34.11.4"/>

  <!--   In Abhängigkeit von der ELGA Interoperabilitätsstufe (EIS) -->
  <!-- EIS „Basic“ -->
  <templateId root="1.2.40.0.34.11.4.0.1"/>
  ... oder ...
  <!-- EIS „Enhanced“ -->
  <templateId root="1.2.40.0.34.11.4.0.2"/>
  ... oder ...
  <!-- EIS „Full support“ -->
  <templateId root="1.2.40.0.34.11.4.0.3"/>
  :
</ClinicalDocument>
5.1.10.1.2 Spezifikation
Element/Attribut DT Kard Konf Beschreibung
templateId II 1..1 M ELGA TemplateId für den Allgemeinen Implementierungsleitfaden
Fester Wert: @root = 1.2.40.0.34.11.1
templateId II 1..1 M ELGA TemplateId für den speziellen Implementierungsleitfaden Laborbefund
Fester Wert: @root = .2.40.0.34.11.4
--- zusätzlich eine der folgenden templateIds ---
Im Falle von EIS „Basic“

(Das Dokument enthält entweder unstrukturierten oder eingebetteten Inhalt (z.B. PDF) oder enthält strukturierten Inhalt, wobei jedoch nicht alle Sektionen den Vorgaben von EIS „Enhanced“ oder höher folgen)

templateId II 1..1 M ELGA CDA Laborbefund
Fester Wert @root = 1.2.40.0.34.11.4.0.1
--- oder ---
Im Falle von EIS „Enhanced“
(Alle Sections folgen ausnahmelos den Vorgaben von EIS „Enhanced“ oder höher, aber nicht alle Sections folgen den Vorgaben von EIS „Full support“)
templateId II 1..1 M ELGA CDA Laborbefund in EIS „Enhanced“
Fester Wert @root = 1.2.40.0.34.11.4.0.2
--- oder ---
Im Falle von EIS „Full support“:

(Alle Sektionen folgen ausnahmslos den Vorgaben von EIS „Full support“)

templateId II 1..1 M ELGA CDA Laborbefund in EIS „Full support“
Fester Wert @root = 1.2.40.0.34.11.4.0.3

5.1.10.2 Dokumentenklasse (“ClinicalDocument/code”)

Die zur Anwendung kommende Dokumentenklasse wird durch den LOINC Code 11502-2 für einen allgemeinen Laborbefund („multidisciplinary laboratory report“) abgebildet. Im Falle eines reinen mikrobiologischen Befundes wird der LOINC Code 18725-2 (Microbio-logy studies) zur Codierung der Dokumentenklasse verwendet.

Diese Codierung stellt einen allgemeinen Laborbefund dar, der es erlaubt beliebige Befundarten und Ergebnisse im Rahmen eines Dokumentes zu übermitteln, auch wenn der Befund nur eine bestimmte Befundart (wie z.B. Hämatologie) enthält. Diesem Umstand wird jedoch durch die Angabe der enthaltenen Laborbefundarten bei der Registrierung eines Labordokumentes in der Registry Rechnung getragen. Durch die Registrierung der in einem Labordokument enthaltenen Befundkategorien über die Service-Event-Metadaten („eventCodeList“) sind auch Detailbefunde in der ELGA einfach auffindbar.

5.1.10.3 Strukturbeispiel

<ClinicalDocumentxmlns="urn:hl7-org:v3">
	:
	<!-- —Dokumentenklasse für den allgemeinen Laborbefund (welcher event. auch
    mikrobiologische Ergebnisse enthalten kann) -->
<code code="11502-2" codeSystem="2.16.840.1.113883.6.1"
 codeSystemName="LOINC"
 displayName="Laboratory report"/>
	
	<!-- Titel des Dokuments -->
	<title>Allgemeiner Laborbefund</title>
	
<!--  ODER  -->:

 <!—Dokumentenklasse für den mikrobiologischen Befund -->
<code code="18725-2" codeSystem="2.16.840.1.113883.6.1"
 codeSystemName="LOINC"
 displayName="Microbiology studies"/>
	
	<!-- Titel des Dokuments -->
	<title></title>

</ClinicalDocument>
5.1.10.3.1 Spezifikation
Element/Attribut DT Kard Konf Beschreibung
code CE
CWE
1..1 M Code des Dokuments
@code cs 1..1 M Fester Wert für den allgemeinen Laborbefund: 11502-2
ODER
Fester Wert für den mikrobiologischen Befund:
18725-2
@displayName st 0..1 R2 Fester Wert für den allgemeinen Laborbefund: Laboratory report
ODER
Fester Wert für den mikrobiologischen Befund:
Microbiology studies
@codeSystem uid 1..1 M Fester Wert: 2.16.840.1.113883.6.1
@codeSystemName ADXP 0..1 R2 Fester Wert: LOINC

5.1.10.4 Dokumenttitel („ClinicalDocument/title“)

Der Titel des Dokumentes ist verpflichtend anzugeben, vom Ersteller frei zu vergeben und beschreibt die Art des Dokumentes näher. Der Titel des Dokuments ist für den lesenden Do-kumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title. Der Sinn der Be-nennung ist jedoch gemäß der Dokumentenklassen zu wählen. Im allgemeinen Fall wird die Bezeichnung „Laborbefund“ verwendet bzw. die Bezeichnung „Mikrobiologischer Befund“ für mikrobiologische Befunde.

5.1.10.4.1 Strukturbeispiel
<ClinicalDocumentxmlns="urn:hl7-org:v3">
	:
	<!-- Dokumentenklasse -->
        <code code="11502-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Laboratory report"/>
	
	<!-- Titel des Dokuments -->
	<title>Allgemeiner Laborbefund</title>
	:
</ClinicalDocument>
5.1.10.4.2 Spezifikation
Element/Attribut DT Kard Konf Beschreibung
title ST 1..1 M Dokumententitel
Der Sinn der Benennung MUSS mit der Dokumentenklasse übereinstimmen.

5.1.10.5 Versionierung des Dokuments („setId“ und „versionNumber“)

Für alle Dokumente ist gemäß den Vorgaben des „Allgemeinen Implementierungsleitfadens“ eine Versionierung verpflichtend vorzusehen. Für Detailinformationen wird auf dieses Dokument verwiesen.

<ClinicalDocument xmlns="urn:hl7-org:v3">
	:
	<!-- Versionierung des Dokuments -->
	<setId root="2.2.40.0.34.99.111.1.1" extension="AAAAAAAAAAAAAAAAAAA"/>
	<versionNumber value="1"/>
	:
</ClinicalDocument>

5.2 Teilnehmende Parteien

5.2.1 IHE LAB TF-3 Konformität

Gem. [3] sind für Angaben zu Personen und Organisationen die Elemente name, addr und telecom verpflichtend. Ausgenommen sind Elemente definiert in Elemente ohne spezielle Vorgaben.

5.2.2 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

  • Patient (recordTarget/patientRole)
  • Personen bei der Dateneingabe (dataEnterer)
  • Verwahrer des Dokuments (custodian)
  • Beabsichtigte Empfänger des Dokuments(informationRecipient)

Verweis auf Allgemeinen Leitfaden:
Die Elemente erfordern keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.


Auszug aus dem Allgemeinen Implementierungsleitfaden

5.2.3 Patient („recordTarget/patientRole“)

Im CDA-Header wird mindestes eine Patientenrolle beschrieben, die zu genau einer Person zugehörig ist. Die recordTarget Beziehung weist auf die Patient-Klasse und gibt an, zu welchem Patienten dieses Dokument gehört.

Auszug aus dem R-MIM:

Abbildung 7: Klassen rund um den Patienten.

5.2.3.1 Spezifikation

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

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

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

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

Die Adresse des Geburtsorts.

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

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


5.2.3.1.1 id
Element/Attribut DT Kard Konf Beschreibung
id[1] II 1..1 M Identifikation des Patienten im lokalen System
Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.
id[2] II 1..1 R Sozialversicherungsnummer des Patienten
Zugelassene nullFlavor:
  • NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …)
  • UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
@root uid 1..1 M OID der Liste aller österreichischen Sozialversicherungen
Fester Wert: 1.2.40.0.10.1.4.3.1
@extension st 1..1 M Vollständige Sozialversicherungsnummer des Patienten (alle 10 Stellen)
@assigningAuthorityName st 0..1 O Fester Wert: Österreichische Sozialversicherung
id[3] II 0..1 O Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit)
@root uid 1..1 M OID der österreichischen bPK
Fester Wert: 1.2.40.0.10.2.1.1.149
@extension st 1..1 M bPK-GH des Patienten: Bereichskürzel + bPK (Base64, 28 Zeichen) (insg. 31 Stellen)
Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen
@assigningAuthorityName st 0..1 O Fester Wert: Österreichische Stammzahlenregisterbehörde

Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!

5.2.3.1.2 addr

Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass auch mehr als eine Adresse unterstützt werden muss.

5.2.3.1.3 patient/languageCommunication

In der Klasse languageCommunication können Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform (z.B. gesprochen oder geschrieben) des Patienten angegeben werden.

Dieser Leitfaden schränkt die möglichen Werte für die Sprache auf Werte aus dem Value Set ELGA_HumanLanguage ein. Gemäß IETF / RFC 3066 enthält es ein bestimmtes Subset von Codes aus ISO 639-1 und ISO 639-2 (also zwei- und dreistellige Sprachcodes). Gemäß RFC 3066 ist es zulässig, eine Angabe der landestypischen Ausprägung der Sprache nach einem Bindestrich anzufügen. Das Land wird dabei nach ISO 3166-1 Alpha 2 angegeben. Dies MUSS bei der Auswertung des languageCodes berücksichtigt und toleriert werden.

5.2.3.1.4 patient/guardian

In der Klasse guardian können Informationen bezüglich eines Vormunds/Sachwalters des Patienten angegeben werden. Begriffsdefinition:

  • Ein Vormund kann existieren, wenn die Person noch nie geschäftsfähig war
    • z.B. Kinder
  • Ein Sachwalter kann existieren, wenn die Person schon geschäftsfähig war, die Geschäftsfähigkeit aber entzogen wurde
    • z.B. Alte Personen

Vormund/Sachwalter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein. Beim Patient können optional ein oder mehrere Vormund/Sachwalter Element(e) angegeben werden. Wenn ein Sachwalter bekannt ist, SOLL diese Information auch angegeben werden.

5.2.4 Personen der Dateneingabe („dataEnterer“)

5.2.4.1 Spezifikation

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

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

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

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

Name der Person

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

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

5.2.5 Verwahrer des Dokuments („custodian“)

Auszug aus dem R-MIM:

Abbildung 9: Klassen rund um die das Dokument verwaltende Organisation.

5.2.5.1 Spezifikation

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

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

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

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


5.2.5.1.1 id
Element/Attribut DT Kard Konf Beschreibung
id II 1..1 R Identifikation des Verwahrers des Dokuments aus dem GDA-Index.

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

  • NI … Organisation hat keine ID aus dem GDA-Index
  • UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt
Wirdgeaendert.png In der nächsten Version des Leitfadens wird die Konformität entsprechend dem CDA-Standard auf [M] erhöht, Null Flavors sind dann nicht mehr erlaubt.

5.2.6 Beabsichtigte Empfänger des Dokuments („informationRecipient“)

Auszug aus dem R-MIM:

Abbildung 10: Klassen rund um die beabsichtigten Empfänger des Dokuments.

5.2.6.1 Spezifikation

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

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

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

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

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

Typ des Informationsempfängers.

Bsp: PRCP „Primärer Empfänger“

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

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

Zugelassene nullFlavor:

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

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

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

Name der Person

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

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

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

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


5.2.7 Verfasser des Dokuments („ClinicalDocument/author“)

Der Autor ist grundsätzlich der „das Dokument verfassende Arzt“. Damit sind diejenigen Personen gemeint, welche das Dokument „inhaltlich“ verfassen (z.B.: diktieren, erheben, messen). Der Autor kann entweder eine Person, ein Software System oder beides sein. Gemäß [3] MUSS mindestens eine Person als Autor angegeben werden, mehrere Autoren sind zulässig.

5.2.8 Medizinischer Validator („ClinicalDocument/legalAuthenticator“)

Das verpflichtende legalauthenticator-Element MUSS angegeben werden und repräsentiert den rechtlichen Unterzeichner (typischerweise der „Medizinische Validator“ oder der laborverantwortliche Arzt).

Im ELGA Referenz-Stylesheet wird der rechtliche Unterzeichner als „Unterzeichnet von“ dargestellt.

5.2.9 Validator („ClinicalDocument/authenticator“)

Ein authenticator-Element repräsentiert einen Validator, der das Dokument inhaltlich freigibt (zusätzliche medizinische und technische Validatoren). Es können mehrere Validatoren angegeben werden. Einer davon kann auch ident mit dem „rechtlichen Unterzeichner“ („ClinicalDocument/legalAuthenticator“) sein.

Aufgrund der Konformität zu IHE [3] ist die Angabe von name, addr und telecom verpflichtend. Der „Validator“ ist weiters mit der templateId „1.3.6.1.4.1.19376.1.3.3.1.5“ zu kennzeichnen.

5.2.9.1 Spezifikation

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

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

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

Name der Person

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

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


5.2.10 Weitere Beteiligte („participant“)

Die Kardinalitäten/Konformitäten der Beteiligten sind wie folgt geändert:

Kard Konf Art des Beteiligten
0..1 [R2] Fachlicher Ansprechpartner

Es ist EMPFOHLEN, die fachliche Ansprechperson (Callback contact) im Laborbefund anzugeben.

5.3 Referenz zum Auftrag

5.3.1 Einweisender/Zuweisender/Überweisender Arzt

Aufgrund der Tatsache, dass IHE in dem Laboratory Technical Framework den Auftraggeber als participant mit dem typeCode=“REF“ führt und ELGA den einweisenden/zuweisenden/überweisenden Arzt ebenfalls als participant mit dem typeCode=“REF“ definiert, sich diese Elemente jedoch strukturell unterscheiden ist die Verwendung des ELGA Elements (mit templateId 1.2.40.0.34.11.1.1.2) NICHT ERLAUBT.

Die Verwendung dieses ELGA participant-Elements mit templateId 1.2.40.0.34.11.1.1.2 ist im Labor NICHT ERLAUBT.


5.3.2 Auftraggeber/„Ordering Provider“

Der Auftraggeber (bzw „ordering provider“, ClinicaDocument/participant@typeCode=“REF““) ist die Organisation oder der Arzt, welche/welcher den Auftrag erstellt hat. Der Auftraggeber wird als participant mit dem typeCode=“REF“ (referrer) ausgeführt und ist [R] verpflichtend anzugeben. Die Verwendung von NullFlavor ist möglich.

Der Auftraggeber ist des Weiteren mit der templateId "1.3.6.1.4.1.19376.1.3.3.1.6" zu kenn-zeichnen (die templateId entfällt bei Verwendung des NullFlavors).

5.3.2.1 Spezifikation

Id1.3.6.1.4.1.19376.1.3.3.1.6
ref
elgabbr-
Gültigkeit2016‑07‑05
StatusKyellow.png EntwurfVersions-Label2016
NameIHEOrderingProviderAnzeigenameOrdering Provider
Beschreibung
KontextElternknoten des Template-Element mit Id 1.3.6.1.4.1.19376.1.3.3.1.6
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
BeziehungVersion: Template 1.3.6.1.4.1.19376.1.3.3.1.6 Ordering Provider (2016‑07‑05)
ref
elgabbr-

Spezialisierung: Template 2.16.840.1.113883.10.12.108 CDA participant (2005‑09‑07)
ref
ad1bbr-
Beispiel
Strukturbeispiel
<participant typeCode="REF">
  <templateId root="1.3.6.1.4.1.19376.1.3.3.1.6"/>  <time value="20121201071500+0100"/>  <associatedEntity classCode="PROV">
    <id root="2.16.840.1.113883.2.16.1.99.3.1" extension="DFRANK"/>    <addr>
      <streetName>Mozartgasse</streetName>      <houseNumber>1-7</houseNumber>      <postalCode>5350</postalCode>      <city>St.Wolfgang</city>      <state>Salzburg</state>      <country>AUT</country>    </addr>
    <telecom use="WP" value="tel:+43.6138.3453446.2222"/>    <associatedPerson>
      <name>
        <prefix qualifier="AC">Dr.</prefix>        <family>Frank</family>        <given>Dieter</given>      </name>
    </associatedPerson>
    <scopingOrganization>
      <id extension="SampleGDA99" root="2.16.840.1.113883.2.16.1.99.3.1"/>      <name>Krankenhaus der Barmherzigen Brüder</name>      <telecom use="WP" value="tel: 01.47110815"/>      <addr nullFlavor="UNK"/>    </scopingOrganization>
  </associatedEntity>
</participant>
Beispiel
Strukturbeispiel, wenn der Auftraggeber nicht verfügbar ist:
<!-- ordering provider -->
<participant nullFlavor="UNK" typeCode="REF">
  <associatedEntity classCode="PROV"/></participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
0 … *
Auftraggeber (Überweiser)
Zugelassene nullFlavor:
  • UNK … Auftraggeber ist unbekannt oder wurde nicht angegeben

(IHE...der)
Treetree.png@typeCode
cs1 … 1FREF
 EN-US.png

In particular, when the ordering provider of the order (or group of orders) fulfilled by this laboratory report is present in the CDA, it SHALL be documented as a participant with the attribute typeCode valued “REF” (referrer).

Treetree.pnghl7:templateId
II1 … 1MEN-US.png

The templateId element identifies this participant as an ordering physician. The templateId SHALL have root="1.3.6.1.4.1.19376.1.3.3.1.6".

(IHE...der)
Treeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.6
Treetree.pnghl7:associated​Entity
1 … 1R(IHE...der)
Treeblank.pngTreetree.pnghl7:addr
AD1 … *REN-US.png

ClinicalDocument/participant(s) MAY be present. When present, this element SHALL be in accordance with the HL7 CDA R2 standard with a time element and further constrained by this specification to require the presence of addr.

(IHE...der)
Treeblank.pngTreetree.pnghl7:telecom
TEL1 … *REN-US.png

ClinicalDocument/participant(s) MAY be present. When present, this element SHALL be in accordance with the HL7 CDA R2 standard with a time element and further constrained by this specification to require the presence of telecom.

(IHE...der)
Treeblank.pngTreetree.pnghl7:associated​Person
0 … 1EN-US.png

ClinicalDocument/participant(s) MAY be present. When present, this element SHALL be in accordance with the HL7 CDA R2 standard with a time element and further constrained by this specification to require the presence of name.

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

Name der Person

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

Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
(IHE...der)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1EN-US.png

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

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


5.3.2.2 Auftragsdatum („ClinicalDocument/participant@typeCode="REF"/time“)

Das Auftragsdatum ist das Datum/Zeit an dem der Auftrag vom Auftraggeber abgesendet wird. Das Auftragsdatum wird als time-Element beim Auftraggeber ausgeführt (siehe Kapitel Auftraggeber/Ordering Provider), und ist verpflichtend anzugeben. Bei einer manuellen Erfassung eines Auftrags im Labor kann dieses als nullFlavor=“NA“ ausgeführt werden.

5.3.3 Auftragsidentifikation („ClinicalDocument/inFulfillmentOf/order“)

Das Element beschreibt die Referenz auf den Auftrag auf der Auftraggeberseite. Es ist das id-Element für die Auftragsnummer auf Auftraggeberseite anzuführen.

Da die Referenz auf einen Auftrag im Labor eine wesentliche Information darstellt, ist das Element in Änderung zur Definition gem. „Allgemeinen Implementierungsleitfaden“ verpflichtend anzugeben.

5.3.3.1 Spezifikation

Id1.2.40.0.34.11.20009
ref
elgabbr-
Gültigkeit2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeaderInFulfillmentOfAnzeigenameHeaderInFulfillmentOf
Beschreibung
Das Element “inFulfillmentOf” ermöglicht die Referenz zum ursprünglichen Auftrag des Auftraggebers.
Dies kann zum Beispiel eine Auftrags- oder Anforderungsnummer sein. Das Element erlaubt genau ein order Unterelement.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.20009 HeaderInFulfillmentOf (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel
<inFulfillmentOf typeCode="FLFS">
  <order classCode="ACT" moodCode="RQO">
    <id root="2.16.840.1.113883.2.16.1.99.3.1" extension="081201-004"/>  </order>
</inFulfillmentOf>
ItemDTKardKonfBeschreibungLabel
hl7:inFulfillmentOf
Komponente zur Dokumentation des Auftrags.
(Hea...tOf)
Treetree.png@typeCode
cs1 … 1FFLFS
Treetree.pnghl7:order
1 … 1MAuftrag.
(Hea...tOf)
Treeblank.pngTreetree.png@classCode
cs1 … 1FACT
Treeblank.pngTreetree.png@moodCode
cs1 … 1FRQO
Treeblank.pngTreetree.pnghl7:id
II1 … 1MAuftragsnummer, Anforderungsnummer.
Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.
(Hea...tOf)

5.4 Dokumentation der Gesundheitsdienstleistung

5.4.1 Service Events („ClinicalDocument/documentationOf/serviceEvent“)

In diesem Element erfolgt die Dokumentation der wesentlichen Untersuchungsinhalte, die in einem CDA Laborbefund enthalten sind. D.h. bei der Einbringung des Dokuments in die Registry sind die serviceEvents-Elemente die einzige Möglichkeit medizinische Informationen einzubringen. Es können beliebig viele serviceEvent-Elemente angegeben werden, es ist jedoch zumindest ein serviceEvent zu codieren.

Verweis auf Allgemeinen Leitfaden (mit Anpassungen):
Das Element ist grundsätzlich gemäß den Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“ anzugeben, es sind jedoch spezielle Vorgaben vorgeschrieben.


Auszug aus dem Allgemeinen Implementierungsleitfaden

5.5 Dokumentation der Gesundheitsdienstleistung

5.5.1 Service Events („documentationOf/serviceEvent“)

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

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

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

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

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

Auszug aus dem R-MIM:

Abbildung 15: Klassen rund um die Gesundheitsdienstleistung.

5.5.1.1 Spezifikation

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

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

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

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

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

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

Id1.2.40.0.34.11.20010
ref
elgabbr-
Gültigkeit2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeaderServiceEventAnzeigenameHeaderServiceEvent
Beschreibung
Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z. B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-145Kyellow.png Gesundheitsdienstleistung Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90003InklusionKgreen.png AssignedEntityElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20010 (2017‑07‑21 11:18:58)
ref
?

Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel Koloskopie
<documentationOf typeCode="DOC">
  <serviceEvent>
    <code code="KOL" displayName="Koloskopie" codeSystem="2.16.840.1.2.3.4.5.6.7.8.9" codeSystemName="Name des Codesystems"/>    <effectiveTime>
      <low value="20081224082015+0100"/>      <high value="20081225113000+0100"/>    </effectiveTime>
    <performer typeCode="PRF">
      <assignedEntity> : </assignedEntity>    </performer>
  </serviceEvent>
</documentationOf>
Beispiel
Strukturbeispiel Hämatologie
<documentationOf typeCode="DOC">
  <serviceEvent>
    <code code="300" codeSystem="1.2.40.0.34.5.11" codeSystemName="ELGA_LaborparameterErgaenzung" displayName="Hämatologie"/>    <effectiveTime>
      <low value="20121201061325+0100"/>      <high value="20121201161500+0100"/>    </effectiveTime>
  </serviceEvent>
</documentationOf>
ItemDTKardKonfBeschreibungLabel
hl7:documentationOf
Komponente für die Gesundheitsdienstleistung.
(Hea...ent)
 
Target.png
elgagab-data​element-145Kyellow.png Gesundheitsdienstleistung Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FDOC
Treetree.pnghl7:serviceEvent
1 … 1MGesundheitsdienstleistung.
(Hea...ent)
Treeblank.pngTreetree.png@classCode
cs0 … 1FACT
Treeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreetree.pnghl7:code
CE1 … 1RCode der Gesundheitsdienstleistung.
Zugelassene nullFlavor: UNK

Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.
(Hea...ent)
Treeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS1 … 1M
Zeitraum der Gesundheitsdienstleistung.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
TS1 … 1M(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
TS1 … 1M(Hea...ent)
Treeblank.pngTreetree.pnghl7:performer
0 … *Durchführende Entität(en) der Gesundheitsdienstleistung.
(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assignedEntity
1 … 1M(Hea...ent)
Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1MPersondendaten der validierenden Person.
(Hea...ent)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

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


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


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


5.5.1.2 Spezielle Vorgaben

Für den Laborbefund sind alle im Befund enthaltenen Befundarten als serviceEvent mit der entsprechenden Codierung anzuführen. Als Codierung wird das ELGA Value Set „ELGA_ServiceEventsLabor“ vorgegeben. Die Auswahl der zu codierenden Events erfolgt durch die im Rahmen des Laborauftrags enthaltenen Parameter. Diese unterliegen über das hierarchische Value Set „ELGA_Laborparameter“ einer Hierarchie durch die sich die auf der obersten Ebene zu codierenden serviceEvent-Elemente ergeben. Die nachfolgende Abbildung zeigt einen Auszug der Liste. Enthält nun z.B. der Laborauftrag den Parameter 26515-7 „Thrombozyten“ so ist gem. Hierarchie auf der obersten Ebene der Eintrag 300 „Hämatologie“ zu finden, welcher als serviceEvent codiert wird.

Abbildung 2: Auszug aus der Liste "ELGA_LaborParameter"
Abbildung 5: Auszug aus der Liste "ELGA_LaborParameter"

Der Mikrobiologiebefund ist in den ServiceEvents zusätzlich mit dem Code 18725-2 (Microbi-ology studies) anzugeben.

Ein Befund kann als Mikrobiologiebefund angegeben werden, wenn eine oder mehrere der Sektionen Bakteriologie, Kultureller Erregernachweis, Antibiogramm, Minimale Hemmkonzentration oder Molekularer Erregernachweis enthalten sind.

Die Angabe eines zeitlichen Erbringungsintervalls effectiveTime mit einer Start- low und Endzeit high ist verpflichtend. Optional kann der Erbringer der Leistung angegeben werden.

Feld Element
Service Event codiert documentationOf/serviceEvent/code
Intervall der Erbringung documentationOf/serviceEvent/effectiveTime
Leistungserbringende Stellen documentationOf/serviceEvent/performer

Tabelle 5: Überblick Elemente ServiceEvent

5.5.1.3 Spezifikation

Id1.2.40.0.34.11.20010
ref
elgabbr-
Gültigkeit2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeaderServiceEventAnzeigenameHeaderServiceEvent
Beschreibung
Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z. B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-145Kyellow.png Gesundheitsdienstleistung Kyellow.png Datensatz
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.90003InklusionKgreen.png AssignedEntityElementsDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20010 (2017‑07‑21 11:18:58)
ref
?

Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel Koloskopie
<documentationOf typeCode="DOC">
  <serviceEvent>
    <code code="KOL" displayName="Koloskopie" codeSystem="2.16.840.1.2.3.4.5.6.7.8.9" codeSystemName="Name des Codesystems"/>    <effectiveTime>
      <low value="20081224082015+0100"/>      <high value="20081225113000+0100"/>    </effectiveTime>
    <performer typeCode="PRF">
      <assignedEntity> : </assignedEntity>    </performer>
  </serviceEvent>
</documentationOf>
Beispiel
Strukturbeispiel Hämatologie
<documentationOf typeCode="DOC">
  <serviceEvent>
    <code code="300" codeSystem="1.2.40.0.34.5.11" codeSystemName="ELGA_LaborparameterErgaenzung" displayName="Hämatologie"/>    <effectiveTime>
      <low value="20121201061325+0100"/>      <high value="20121201161500+0100"/>    </effectiveTime>
  </serviceEvent>
</documentationOf>
ItemDTKardKonfBeschreibungLabel
hl7:documentationOf
Komponente für die Gesundheitsdienstleistung.
(Hea...ent)
 
Target.png
elgagab-data​element-145Kyellow.png Gesundheitsdienstleistung Kyellow.png Datensatz
Treetree.png@typeCode
cs0 … 1FDOC
Treetree.pnghl7:serviceEvent
1 … 1MGesundheitsdienstleistung.
(Hea...ent)
Treeblank.pngTreetree.png@classCode
cs0 … 1FACT
Treeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreetree.pnghl7:code
CE1 … 1RCode der Gesundheitsdienstleistung.
Zugelassene nullFlavor: UNK

Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.
(Hea...ent)
Treeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS1 … 1M
Zeitraum der Gesundheitsdienstleistung.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
TS1 … 1M(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
TS1 … 1M(Hea...ent)
Treeblank.pngTreetree.pnghl7:performer
0 … *Durchführende Entität(en) der Gesundheitsdienstleistung.
(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assignedEntity
1 … 1M(Hea...ent)
Eingefügt von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R
Mindestens eine Id der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1
Ein Adress-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Mindestens ein Telecom-Element der validierenden Person.
Zugelassene nullFlavor: UNK
(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1MPersondendaten der validierenden Person.
(Hea...ent)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

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

Der Startzeitpunkt ist - sofern vorhanden - jenes Datum und jener Zeitpunkt, an dem das analysierende Labor die Anforderung vom Zuweiser in der Labor EDV erfasst hat. Anderenfalls sind Datum und Uhrzeit des Starts des Auftrags in der Labor EDV anzugeben. Die Endzeit ist die Abschlusszeit des Auftrags, welche in der Regel mit der medizinischen Freigabe des Auftrags ident ist.

5.5.2 Durchführende Labors („ClinicalDocument/documentationOf/serviceEvent/performer“)

Optional können die, die Laboruntersuchungen durchführenden, Labors dokumentiert werden. Nach [3] können diese an mehreren Stellen des Befundes angegeben werden. Wurde der Befund nur von einem Labor erstellt so ist dieses im Rahmen von ClinicalDocument/documentationOf/serviceEvent/performer anzugeben. Sind mehrere Labors an der Erstellung beteiligt so MUSS das Labor im structuredBody entweder auf entry-Ebene oder im Rahmen eines organizer oder direkt bei der Einzeluntersuchung (observation) angegeben werden.

Wird dieser Eintrag angeführt, so ist das Labor mit seinem Leiter angeführt. Gemäß [3] sind time, sowie name, telecom und addr VERPFLICHTEND anzugeben. Im Element time wird der Zeitpunkt oder die Zeitdauer angegeben, in der das Labor mit der Ausführung der Dienstleistung beschäftigt war. Weiters entspricht die Definition dem Template mit templateId „1.3.6.1.4.1.19376.1.3.3.1.7“, welche anzuführen ist.

5.5.2.1 Spezifikation

Id1.3.6.1.4.1.19376.1.3.3.1.7
ref
elgabbr-
Gültigkeit2014‑05‑26
StatusKgreen.png AktivVersions-Label
NameLaboratoryPerformerAnzeigenameLaboratory Performer
Beschreibung
KontextGeschwisterknoten des Template-Element mit Id 1.3.6.1.4.1.19376.1.3.3.1.7
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
BeziehungVersion: Template 1.3.6.1.4.1.19376.1.3.3.1.7 Laboratory Performer (2014‑05‑26)
ref
elgabbr-
Beispiel
Strukturbeispiel
<documentationOf typeCode="DOC">
  <serviceEvent>
    <code code="300" codeSystem="1.2.40.0.34.5.11" codeSystemName="ELGA_LaborparameterErgaenzung" displayName="Hämatologie"/>    <effectiveTime>
      <low value="20121201061325+0100"/>      <high value="20121201161500+0100"/>    </effectiveTime>
    <performer typeCode="PRF">
      <templateId root="1.3.6.1.4.1.19376.1.3.3.1.7"/>      <time>
        <low value="20121201061325+0100"/>        <high value="20121201161500+0100"/>      </time>
      <assignedEntity>
        <id nullFlavor="NA"/>        <addr>
          <streetAddressLine>Laborplatz 1 </streetAddressLine>          <city>Wien</city>          <postalCode>1210</postalCode>        </addr>
        <telecom use="WP" value="tel:+43.1.12345678"/>        <assignedPerson>
          <name>
            <prefix qualifier="PR">OA</prefix>            <prefix qualifier="AC">Dr.</prefix>            <given>Larissa</given>            <family>Laborleiter</family>          </name>
        </assignedPerson>
        <representedOrganization>
          <id root="1.2.40.0.34.3.1.999"/>          <name>Zentrallabor</name>          <telecom use="WP" value="tel:+43.1.12345678"/>          <addr>
            <streetAddressLine>Labplatz 1</streetAddressLine>            <city>Wien</city>            <postalCode>1200</postalCode>          </addr>
        </representedOrganization>
      </assignedEntity>
    </performer>
  </serviceEvent>
</documentationOf>
ItemDTKardKonfBeschreibungLabel
@typeCode
1 … 1R
 CONF
Der Wert von @typeCode muss gewählt werden aus dem Value Set 1.2.40.0.34.10.43 ELGA_ServiceEventPerformer (DYNAMIC)
hl7:templateId
1 … 1M(Lab...mer)
Treetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.7
hl7:time
IVL_TS0 … 1RZeitraum, in der der Performer diese Gesundheitsdienstleistung ausgeführt hat(Lab...mer)
hl7:assignedEntity
1 … 1M(Lab...mer)
Treetree.pnghl7:id
II1 … 1R(Lab...mer)
Treetree.pnghl7:code
CE0 … 1R(Lab...mer)
 Beispiel<code code="E" codeSystem="2.16.840.1.113883.2.16.1.4.9" codeSystemName="HL7.at.Laborkennzeichnung" displayName="EXTERN"/>
Treetree.pnghl7:addr
AD1 … 1M(Lab...mer)
Treetree.pnghl7:telecom
TEL.AT1 … *M(Lab...mer)
Auswahl1 … 
Angabe von Personenname oder Organisationsname ist verpflichtend.
Elemente in der Auswahl:
  • hl7:assigned​Person
  • hl7:represented​Organization
Treeblank.pngTreetree.pnghl7:assigned​Person
 … 1(Lab...mer)
Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M

Name der Person

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

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

Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“

Änderung zum Allgemeinen Implementierungsleitfaden Aufgrund des verwendeten IHE Template ist die Angabe der Element assignedEntity/addr, asignedEntity/telecom, sowie assignedEntity/assignedPerson/name verpflichtend


5.6 Informationen zum Patientenkontakt

5.6.1 Encounter (“componentOf/encompassingEncounter”)

Gemäß [3] ist die Angabe von Informationen zum Patientenkontakt im Rahmen des componentOf/encompassingEncounter-Elementes möglich. Da im Regelfall bei einer Laborleistung keine dementsprechende zu dokumentierende Leistung existiert, ist die Angabe dieser Information im österreichischen Laborbefund optional.

6 Medizinische Inhalte im Body

6.1 Fachlicher Inhalt in den ELGA Interoperabilitätsstufen (EIS)

6.1.1 Fachlicher Inhalt in EIS „Basic“ und „Structured“

Enthält das Dokument entweder unstrukturierten oder eingebetteten Inhalt (z.B. PDF) oder strukturierten Inhalt3 , wobei jedoch nicht alle Sektionen den Vorgaben von EIS „Enhanced“ oder „Full Support“ folgen, dann liegt das Dokument in ELGA Interoperabilitätsstufe (EIS) „Basic“ vor. Die Sektionen MÜSSEN jedenfalls in der von diesem Leitfaden definierten Reihenfolge vorliegen, damit die erforderliche ELGA Interoperabilitättstufe „Structured“ erreicht wird.

Die Verwendung von EIS Basic ist in ELGA nicht mehr zulässig.


3 Ensprechend den CDA Body Choices „NonXMLBody“ und „StructuredBody“, unconstrained CDA specification („CDA Level One“)

6.1.2 Fachlicher Inhalt in EIS „Enhanced“ oder „Full support“

Ein Dokument liegt in der ELGA Interoperabilitätsstufe (EIS) „Enhanced“ oder „Full support“ vor, wenn das Dokument strukturierten Inhalt enthält und alle Sections den Vorgaben von EIS „Enhanced“ oder höher folgen.

  • EIS „Enhanced“
    • Alle Sections folgen ausnahmelos den Vorgaben von EIS „Enhanced“ oder höher, aber nicht alle Sections folgen den Vorgaben von EIS „Full support“.
  • EIS „Full support“
    • Alle Sections folgen ausnahmelos den Vorgaben von EIS „Full support“.

6.2 Aufbau des CDA Body Allgemein

Dieser Leitfaden spezifiziert Inhaltselemente für den klassischen Laborbefund als auch für den mikrobiologischen Befund. In den folgenden Kapitel wird festgehalten welche CDA-Bereiche (Sektions) für die beiden Laborbefundausprägungen verpflichtent bzw optional zu verwenden sind. Mithilfe dieses Leitfadens können folgende Befundausprägungen für ELGA erstellt werden:

  • Klassischer Laborbefund
  • Mikrobiologischer Befund

Die Sektionen welche für die Erstellung eines ELGA Laborbefundes der unterschiedlichen Ausprägungen zur Verfügung stehen sind in nachfolgenden Kapitel vollständig aufgelistet.

Tabellarische Darstellung der Sektionen

Sektion / Titel Konformanz für Kapitel
Labor µBio
Brieftext [O] [O] 6.5.1
Überweisungsgrund [O] [O] 6.5.2
Angeforderte Untersuchungen [O] [O] 6.5.3
Spezimen / Probeninformation* [M] [M] 6.5.4
Laborergebnisse [M] [NP] 4.5.5
Makroskopie [O] [O] 4.5.6
Mikroskopie [O] [O] 4.5.7
Kultureller Erregernachweis [O] [O] 4.5.8
Antibiogramm (+ MHK) [O] [O] 4.5.9
Molekularer Erregernachweis [NP]** [O] 4.5.10
Infektionsserologie [NP]** [O] 4.5.11
Befundbewertung [O] [O] 4.5.12
Beilagen [O] [O] 4.5.13
Abschließende Bemerkungen [O] [O] 4.5.14


*Hinweise für die Sektion Spezimen / Probeninformation

  • Spezimen / Probeninformation

Für diese Sektion gelten spezielle Richtlinien welche die Reihenfolge bzw. die Verwendung der Sektionen weiter einschränken. Hinweise sind in dem zugehörigen Kapitel zu finden.

**Hinweis für die Sektionen molekularer Erregernachweis und Infektionsserologie

Diese Sektionen dürfen im allgemeinen Laborbefund nicht verwendet werden, da Angaben bezüglich eines molekularen Erregernachweises und Angaben zu Infektionsserologie innerhalb der Sektion Laborergebnis abgebildet werden.


6.2.1 Zusätzliche medizinische Informationen

Unter Umständen ist es von Bedeutung und Interesse in dem Befund zusätzliche medizinische Informationen anzugeben. Dies betrifft z.B. die Aufnahmediagnose oder die medizinische Fragestellung bei der Auftragserteilung an das Labor. Diese Informationen können parallel zu den Befundarten als eigene Sections im CDA-Dokument angegeben werden. Die Codierung der Informationen innerhalb dieser Sections hat jedoch gemäß den Vorgaben des IHE „Patient Care Coordination“ Framework (PCC) [6] zu erfolgen!

6.2.2 Harmonisierung des Befundaufbaus – Value Set „ELGA_Laborparameter“

Im Rahmen der Arbeiten zum vorliegenden Dokument wurde in der Expertengruppe die grundsätzliche Übereinkunft getroffen, auch die Befundgruppen und die damit verbundene Testzuordnung entsprechend österreichweit abzustimmen. Die Strukturierung eines Laborbefundes wurde in Form des hierarchischen Value Sets „ELGA_Laborparameter“ festgelegt.

Strukturierung, Reihenfolge der Parameter sowie die Bezeichnung der Parameter sind durch das Value Set ELGA Laborparameter verpflichtend vorgegeben!

Eine Hilfestellung zum Mapping der lokalen Codes auf die vorgeschriebenen Codes des Value Sets bietet der „Leitfaden zur Verwendung von LOINC® im ELGA CDA® R2 Laborbefund“ [9].

6.3 Spezifikation der Befunddarstellung Level 2 für den Laborbefund

6.3.1 Überblick

Die nachfolgende Tabelle gibt einen Überblick über die im lesbaren Text anzugebenden und in Level 2 (unter component/section) zu anzugebenden medizinischen Inhalte. Die Optionalität bezieht sich auf die Darstellung des jeweiligen Elements in der Tabelle. Die Befüllung ergibt sich aus den Vorgaben für Level 3 (z.B. ist die „Bemerkung Labor“ in dieser Übersicht mit [R] angegeben, d.h. das Tabellenelement ist verpflichtend anzugeben, befüllt muss es nur werden, wenn tatsächlich eine Bemerkung vorhanden ist).

Die Reihenfolge der Elemente innerhalb einer Gruppe ist zu beachten.

Die Angabe der Sektion Brieftext ist im Laborbefund ERLAUBT (Siehe Allgem. Leitfaden [4] TemplateID: 1.2.40.0.34.11.1.2.1).

Feld Opt Darstellung Details
Befundbereiche <section/title>Name des Befundbereichs</section/title>

Der Name des Befundbereichs wird in <section/title> codiert und nicht innerhalb des <section/text> Elements

<Component/section/text> Inhalt
Auftragsdiagnose (Zuweiser-diagnose) <text> Freitextdarstellung ohne speziellen Richtlinien und Vorgaben
Überweisungsgrund <text> Freitextdarstellung ohne speziellen Richtlinien und Vorgaben
Befundtext <text> Freitextdarstellung ohne speziellen Richtlinien und Vorgaben
Spezimeninformation < table> pro Spezimen eine Zeile < tr> </ tr>

Sollte ein Befund aus mehreren Sections bestehen, wird die Spezimeninformation ausschließlich in einer eigenen Section angegeben und als erste Section geführt.Generell gilt, dass die Angabe von Informationen zu Proben/Spezimen/Material vorgeschrieben ist.

1 Material-ID O <td></td> Identifikator der Probe
2 Probenentnahme R <td></td> Zeitpunkt der Probebentnahme, muss nicht angegeben werden bzw darf „unbekannt“ sein. Format: dd.MM.yyyy hh24:mi
3 Untersuchtes Material R <td></td> Materialart [R] und Entnahmeort [O] (Freitext ist zulässig)
4 Probenentnahme durch O <td></td> Für Probenentnahme zuständige Person und ggf Organisation [O]
5 Probeneingang R <td></td> Probeneingang im Labor, Format: dd.MM.yyyy hh24:mi
6 Bemerkung Labor R <td></td> Allfällige Bemerkungen zur Probenqualität sollen angegeben werden
Befundgruppen <paragraph styleCode="xELGA_h3"> Name der Gruppe</paragraph>
Gruppierung / Befundgruppen (Organizer)
Ergebnistabelle (Observations)4 < table>
je Test eine Zeile <tr></tr>
1 Analyse M <td></td> Bezeichnung der Analyse (entsprechen dem displayName in Value Set ELGA-Laborparameter)
2 Ergebnis M <td></td> Ergebnis der Analyse5
3 Einheit M <td></td> Einheit (UCUM printName)
4 Referenzbereiche R2 <td></td> Mehrere Referenzbereiche können angegeben werden, getrennt durch Zeilenumbruch im Text6
5 Interpretation R2 <td></td> Codiert! Siehe 6.3.5.4 sowie Kapitel Tabelle 7 und Tabelle 8
6 Externes Labor R2 <td></td> Angabe von „E“, wenn die Analyse von einem externen Dienstleister gemessen wurde

Tabelle 6: Übersicht Medizinische Inhalte Level 2


4 Spezialuntersuchungen, die nicht in das angegebene Schema passen (z.B Molekulare Diagnostik, Allergiediagnostik etc.), können bei Bedarf auch anders dargestellt werden. Ensprechende Beispieldokumente stehen zur Verfügung.
5 Es wird EMPFOHLEN, bei Dezimalzahlen einen Punkt als Dezimaltrennzeichen zu verwenden – gleich wie im maschinenlesbaren Teil.
6 Es wird EMPFOHLEN, bei Dezimalzahlen einen Punkt als Dezimaltrennzeichen zu verwenden – gleich wie im maschinenlesbaren Teil

6.3.2 Level 2 Befundstruktur

Bei der Darstellung der Befunde ist die Struktur gemäß Abbildung 6 verpflichtend abzubilden.

Spezimen Bereich Spezimen Section: enthält Tabelle mit Spezimen in <text>
Befundbereich (Section) Befundgruppe Befundgruppenbezeichnung
Ergebnistabelle Befundgruppe
Bemerkung zur Befundgruppe
Befundgruppe Befundgruppenbezeichnung
Ergebnistabelle Befundgruppe
Bemerkung zur Befundgruppe
.. ..
Befundbereich (Section) Befundgruppe Befundgruppenbezeichnung
Ergebnistabelle Befundgruppe
Bemerkung zur Befundgruppe
Befundgruppe Befundgruppenbezeichnung
Ergebnistabelle Befundgruppe
Bemerkung zur Befundgruppe
.. ..
.. ...
Befund Bemerkung Bereich Befundbemerkung Section enthält: Bemerkung zu Befund in <text>

Abbildung 6: Befundstruktur Level 2 mit mehreren Sections

Enthält ein Befund nur genau einen Bereich (Section) kann eine vereinfachte Darstellung mit folgender Befundstruktur verwendet werden:

Tabelle mit Spezimen
Befundgruppe Befundgruppenbezeichnung
Ergebnistabelle Befundgruppe
Bemerkung zur Befundgruppe
Befundgruppe Befundgruppenbezeichnung
Ergebnistabelle Befundgruppe
Bemerkung zur Befundgruppe
... ...
Bemerkung zur Befundart

Abbildung 7: Befundstruktur Level 2 mit einer Section

6.4 Spezifikation der Befunddarstellung Level 2 für den mikrobiologischen Befund

6.4.1 Überblick

Nachfolgende Tabelle 6 gibt einen Überblick über die im lesbaren Text anzugebenden und in Level 2 (unter component/section) zu anzugebenden medizinischen Inhalte des mikrobiologischen Befundes. Die Optionalität bezieht sich auf die Darstellung des jeweiligen Elements in der Tabelle. Die Befüllung ergibt sich aus den Vorgaben für Level 3 (z.B. ist die „Bemerkung Labor“ in dieser Übersicht mit [R] angegeben, d.h. das Tabellenelement ist verpflichtend anzugeben, befüllt muss es nur werden, wenn tatsächlich eine Bemerkung vorhanden ist).

Die Reihenfolge der Elemente innerhalb einer Gruppe ist zu beachten.

Die Angabe der Sektion Brieftext ist im Laborbefund ERLAUBT (Siehe Allgem. Leitfaden [4] TemplateID: 1.2.40.0.34.11.1.2.1).

Feld Opt Darstellung Details
Befundbereiche <section/title>Name des Befundbereichs</section/title>

Der Name des Befundbereichs wird in <section/title> codiert und nicht innerhalb des <section/text> Elements

<Component/section/text> Inhalt
Auftragsdiagnose (Zuweiser-diagnose) <text> Freitextdarstellung ohne speziellen Richtlinien und Vorgaben
Überweisungsgrund <text> Freitextdarstellung ohne speziellen Richtlinien und Vorgaben
Befundtext <text> Freitextdarstellung ohne speziellen Richtlinien und Vorgaben


Spezimeninformation < table> pro Spezimen eine Zeile < tr> </ tr>

Sollte ein Befund aus mehreren Sections bestehen, wird die Spezimeninformation ausschließlich in einer eigenen Section angegeben und als erste Section geführt.Generell gilt, dass die Angabe von Informationen zu Proben/Spezimen/Material vorgeschrieben ist.

1 Material-ID O <td></td> Identifikator der Probe
2 Probenentnahme R <td></td> Zeitpunkt der Probebentnahme, muss nicht angegeben werden bzw darf „unbekannt“ sein. Format: dd.MM.yyyy hh24:mi (6.4.5.3.3.4)
3 Untersuchtes Material R <td></td> Materialart [R] (6.4.5.3.3.7) und Entnahmeort [O] (6.4.5.3.3.5) (Freitext ist zulässig)
4 Probenentnahme durch O <td></td> Für Probenentnahme zuständige Person und ggf Organisation [O] (6.4.5.3.3.6)
5 Probeneingang R <td></td> Probeneingang im Labor, Format: dd.MM.yyyy hh24:mi
6 Bemerkung Labor R <td></td> Allfällige Bemerkungen zur Probenqualität sollen angegeben werden
Makroskopie <text> Freitextdarstellung ohne speziellen Richtlinien und Vorgaben
Mikroskopie Wenn mikroskopische Beobachtungen auch maschinenlesbar codiert sind (entry-Element vorhanden) dann soll die menschlich lesbare Information in tabellarischer Form aufbereitet werden. Sonst Freitext
1 Eigenschaft M
[1..1]
<td></td>
2 Ergebnis M
[1..1]
<td></td>
3 Einheit O
[0..1]
<td></td>
Kultureller Erregernachweis < table> pro Erreger eine Zeile<tr></tr>
1 Erreger M
[1..1]
<td></td>
2 Methode R2
[0..1]
<td></td> Mögliche Werte vgl. Tabelle 12: Beispiele für Codes für Erregernachweis-Methodik
3 Keimzahl M
[1..1]
<td></td>
Antibiogramm < table> je Antibiotikum Zeile <tr></tr>
1 Name des Erregers M
[1..1]
<th></th> Darstellung als Spaltenüberschriften
2 Wirkstoff M <td></td> Antibiotischer Wirkstoff
3 Resistenzkennung inkl. Optionaler Angabe der minimalen Hemmkonzentration M <td></td> Codiert! Siehe Tabelle 13. (Am Schnittpunkt von Erreger (Spalte) und Wirkstoff (Zeile))
Testergebnisse / Molekularer Erregernachweis < table> je Analyse/Erreger eine Zeile <tr></tr>
1 Analyse / Erreger / Methode M
[1..1]
<td></td>
2 Ergebnis M <td></td>
3 Einheit O
[0..1]
<td></td>
4 Referenzbereich / Nachweisgrenze / Linearitätsbereich O
[0..1]
<td></td>
5 Interpretation R2 <td></td> Codiert: Siehe Tabelle 7 und Tabelle 8
Infektionsserologie < table> je Analyse/Erreger eine Zeile <tr></tr>
1 Analyse / Erreger / Methode M
[1..1]
<td></td>
2 Ergebnis M <td></td>
3 Einheit O
[0..1]
<td></td>
4 Referenzbereich / Nachweisgrenze / Linearitätsbereich O
[0..1]
<td></td>

Tabelle 7: Übersicht Medizinische Inhalte Level 2 für den mikrobiologischen Befund

6.5 Sektionen für den Laborbefund und den mikrobiologischen Befund

In den folgenden Kapiteln werden die einzelnen Sektionen spezifiziert welche sowohl für den Laborbefund als auch für den mikrobiologischen Befund verwendet werden.

6.5.1 Brieftext

6.5.1.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.1.2.1
Parent Template ID -
Titel der Sektion Brieftext
Definition Ein am Anfang des Briefes formulierter Freitext für eine Anrede oder Begrüßung. Die Angabe von medizinisch fachlich relevan-ter Information in diesem Abschnitt ist NICHT ERLAUBT.

Bsp: „Danke für die Zuweisung ...“

Codierung ELGA: BRIEFT, „Brieftext“
Konformität [O] [O]
Konformität Level 3 [O] [O]


Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.


Mehrere Logos (zB wenn zusätzlich ein Akkreditierungs-Logo angegeben werden soll) sind in eine Grafikdatei zusammenzufassen (siehe Kapitel 4.5.11).


6.5.2 Überweisungsgrund

Der Überweisungsgrund enthält die dem Labor übermittelte Auftrags- oder Verdachtsdiagnose bzw. Fragestellung.Die Angabe erfolgt in einer Section im Body des CDA-Dokuments.

6.5.2.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.4
Parent Template ID -
Titel der Sektion Überweisungsgrund
Definition Der Grund für eine Gesundheitsdienstleistung (hier: Laborbefund). Enthält eine narrative Beschreibung des Grundes für den Auftrag (Beschreibung aus der Sicht des Gesundheitsdiensteanbieters) und/oder die eigene Beschreibung des Patienten (z.B. Hauptsymptom des Patienten)
Codierung LOINC: 46239-0, „Chief complaint+Reason for visit“
Konformität [O] [O]
Konformität Level 3 [NP] [NP]

6.5.2.2 Spezifikation

Id1.2.40.0.34.11.4.2.4
ref
elgabbr-
Gültigkeit2015‑09‑24
StatusKgreen.png AktivVersions-Label
NameUeberweisungsgrundAnzeigenameÜberweisungsgrund
Beschreibung
Der Grund für eine Gesundheitsdienstleistung. Enthält eine narrative Beschreibung des Grundes für den Auftrag (Beschreibung aus der Sicht des Gesundheitsdiensteanbieters) und/oder die eigene Beschreibung des Patienten (z.B. Hauptsymptom des Patienten)
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.4.2.4
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.4.2.4 Überweisungsgrund (2015‑09‑24)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.4.2.4"/>  <!-- Code der Sektion -->
  <code code="46239-0" displayName="Chief complaint+Reason for visit" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Überweisungsgrund</title>  <!-- Textbereich der Sektion -->
  <text> ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Ueb...und)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Ueb...und)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.4.2.4
Treetree.pnghl7:code
CE1 … 1M(Ueb...und)
Treeblank.pngTreetree.png@code
CONF1 … 1F46239-0
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Ueb...und)
 CONF
Elementinhalt muss "Überweisungsgrund" sein
Treetree.pnghl7:text
SD.TEXT1 … 1MInformation für den menschlichen Leser.
(Ueb...und)


6.5.3 Angeforderte Untersuchungen

6.5.3.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.5
Parent Template ID -
Titel der Sektion Angeforderte Untersuchungen
Definition Diese Sektion enthält die vom Auftraggeber angeforderten Untersuchungen bzw. das angeforderte Analysespektrum.

Beispiele: „Kultur und Resistenz“, „Pilzkultur“, „Kultur auf spezielle Erreger“, „MRSA-Screening“

Codierung ELGA: ANGEFUNTERS, „Angeforderte Untersuchungen“
Konformität [NP] [O]
Konformität Level 3 [NP] [NP]

6.5.3.2 Spezifikation

1.2.40.0.34.11.4.2.5/dynamic

6.5.4 Spezimen / Probeninformation

6.5.4.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.1
Parent Template ID -
Titel der Sektion Probeninformation
Definition Der Inhalt dieser Sektion enthält sämtliche Information über das zu befundende Material, inklusive, soweit sinnvoll, der Lokalisation, der Entnahmeart, des Entnahmegeräts, der Person, welche die Entnahme durchgeführt hat, sowie Zeitpunkt der Materialentnahme und der Materialannahme.
Codierung ELGA_LaborparameterErgaenzung: 10, „Probeninformation“
Konformität [C]
Diese Sektion ist verpflichtend, wenn Inhalte mehrere ELGA Bereiche im Laborbefund enthalten sind [M]
Wenn nur Inhalte eines ELGA Laborbereichs im Befund enthalten sind kann die Information zum Spezimen innerhalb des ELGA Laborbereichs angeführt werden [O]
[M]
Konformität Level 3 [C]
Level 3 Codierung ist optional für allgemeine Laborbefunde der EIS „Structured“ und „Enhanced“ [O]
Level 3 Codierung ist verpflichtent für allgemeine Laborbefunde der EIS „Full Support“ [M]
[R]
Level 3 Codierung muss vorhanden sein für mikrobiologische Befunde [R]. Wenn nicht bekannt ist ein NullFlavor zu verwenden

Hinweis für mikrobiologische Befunde:
Derzeit werden mikrobiologische Befunde mit mehreren Proben nicht unterstützt! Dies bedeutet, dass in einem mikrobiologischen Befund nur eine Proben / Material / Spezimen geführt werden darf!


Probeninformation, vollständig.
Abbildung 8: Probeninformation, vollständig.

Probeninformation, minimal.
Abbildung 9: Probeninformation, minimal.

In der Spalte „Bemerkung Labor“ können Beurteilung betreffend der Material- / Proben- / Spezimenqualität zum Zeitpunkt des Probeneingangs festgehalten werden. Die detailierte Beschreibung des Materials kann gegebenenfalls in der Sektion Makroskopie (siehe Kapitel 6.5.6) erfolgen.


Menschenlesbare Informationen zum Spezimen MÜSSEN angegeben werden, wenn bekannt.

In dem folgenden Strukturbeispiel ist die Codierung der Informationen in einer Tabelle ersichtlich. Die einzelnen Zeilen, welche jeweils ein Spezimen codieren, können mit Identifikatoren gekennzeichnet werden um auf diese im weiteren CDA Befund referenzieren zu können. Die Optimierung der Spaltenbreiten kann im ELGA Referenz-Stylesheet durch die ELGA-Stylecodes „xELGA_colw:nn“ erfolgen.

1.2.40.0.34.11.4.2.2000/dynamic

Die Abbildung der Spezimeninformation kann auf zwei Arten erfolgen:

  1. Enthält ein Befund nur einen Bereich, so kann die Codierung gemäß IHE LAB TF-3 innerhalb der einen Befundsektion erfolgen

ODER

  1. Bei Verwendung von mehreren Bereichen (vgl. Anforderung) in einem Laborbefund kann es zu Überschneidungen der Spezimeninformationen kommen (ein spezielles Spezimen kann in zwei Bereichen analysiert werden). Die Level 3 Codierung eines Spezimens darf jedoch nur einmal im gesamten Laborbefund erfolgen. Daher sind die Informationen zu den Spezimen in einer eigenen führenden Probeninformation Section mit dem Code „10“ und der TemplateID 1.2.40.0.34.11.4.2.1 zu codieren.

6.5.5 Laborergebnisse

6.5.5.1 Überblick

Labor Mikrobiologie
Template ID IHE: 1.3.6.1.4.1.19376.1.3.3.2.1
Parent Template ID -
Titel der Sektion Der Titel dieser Sektion ist für den jeweiligen Bereich (siehe Kapitel 1.3.1.1) passend zu wählen. Zulässige Werte sind im ELGA Value Set „ELGA_Laborstruktur“ zu finden.
Definition Diese Sektion umfasst die Laborergebnisse eines jeweiligen Bereichs (z.B.: Blutgasanalytik, oder Hämatologie). Die Laborergebnisse werden weiters in Gruppen (siehe Kapitel 1.3.1.2) untergliedert.
Codierung Der Code der Sektion ist für den jeweiligen Bereich passen zu wählen. Zulässige Codes sind im ELGA Value Set „ELGA_Laborstruktur“ zu finden.
Konformität [M] [NP]
Konformität Level 3 [M] [NP]

6.5.5.2 Vorgaben zur Darstellung einzelner Elemente

6.5.5.2.1 Analysen

Analysen (bzw Laborwerte, Laborleistungen oder Labormessgrößen) MÜSSEN in der einheitlichen Schreibweise angegeben sein, die im Value Set „ELGA_Laborparameter“ vorgegeben wird („Begriff“ bzw „display name“ im Value Set). Das erleichtert das Lesen und speziell für Patienten die Recherche von Laborwerten im Gesundheitsportal (www.gesundheit.gv.at). Siehe dazu auch den „Leitfaden zur Verwendung von LOINC® im ELGA CDA® R2 Laborbefund“ [9].

Ein Beispiel zur Darstellung findet sich in Abbildung 12. Die Tabelle besteht aus mindestens fünf und maximal sechs Spalten. Für jede Gruppe wird ein Block angelegt, Bereichsüberschriften entsprechen Kapitelüberschriften. Zusätzlich kann eine Spalte mit „Extenes Labor“ notwendig sein. Sollen genauere Angaben zur Methode gemacht werden, als durch den Namen der Analysen bereits hervorgeht, soll dies über einen Analysenkommentar umgesetzt werden (siehe 6.3.8.1).

Beispiel einer ausführlichen Laborwerte-Ergebnistabelle.
Abbildung 10: Beispiel einer ausführlichen Laborwerte-Ergebnistabelle

6.5.5.2.2 Ergebnis

Dieses Element enthält ein numerisches, nominales, ordinales oder narratives Ergebnis der Analyse zu diesem Testcode. Da in der Definition des CDA-Schemas keinerlei Längenbeschränkung vorgegeben ist, kann dieses Feld auch größere Textmengen fassen um große verbale Beurteilungen zu ermöglichen.

6.5.5.2.3 Einheit

Zu jedem Ergebnis MUSS eine passende Einheit angegeben werden. Bevorzugt zu verwenden sind die Einheiten, die im Value Set „ELGA_Laborparameter“ vorgeschlagen werden.

Es wird EMPFOHLEN, anstelle von Einheitenpräfixen („Giga“, „Mega“, „Milli“, „Mikro“ etc.) eine Potenzschreibweise zu wählen, vor allem, wenn die Groß/Klein-Schreibung eine Rolle spielt und Verwechslungen möglich sind (z.B. „G/L“=Giga pro Liter vs. „g/L“=Gramm/Liter). Also '10^6 ' statt 'M' (Mega), '10^9 ' statt 'G ' (Giga) usw.

6.5.5.2.4 Befundinterpretation

Es ist in Laborbefunden üblich, eine codierte Bewertung zu jedem Ergebnis anzugeben. Häufig wird eine Notierung mit +/- verwendet.

Folgende Tabelle 7 ist ein Auszug aus dem Value Set „ELGA_ObservationInterpretation“ und zeigt die normative Befundinterpretation für numerische Ergebnisse, Tabelle 8 (ebenfalls aus dem gleichen Value Set) die Kennzeichnung für nicht numerische Ergebnisse.

Darstellung Level 2 Codierung Level 3 Beschreibung
++ HH Oberhalb des Referenzbereiches und über einer oberen Warngrenze
+ H Oberhalb des Referenzbereiches
N Normal (innerhalb des Referenzbereiches)
- L Unterhalb des Referenzbereiches
-- LL Unterhalb des Referenzbereiches und unter einer unteren Warngrenze

Tabelle 8: Befundinterpretation numerischer Ergebnisse

Darstellung Level 2 Codierung Level 3 Beschreibung
N Normal (innerhalb des Referenzbereiches)
* A Abnormal
** AA Abnormal Warngrenze

Tabelle 9: Befundinterpretation nicht numerischer Ergebnisse (nominal, ordinal, narrativ)

Zur Interpretation von Ergebnissen der Allergiediagnostik wurden zusätzlich RAST-Klassen als Klassifikation erlaubt, siehe Kapitel Empfehlungen für die Darstellung der Allergiediagnostik.

6.5.5.2.5 Empfehlungen für die Darstellung der Allergiediagnostik

In der Allergiediagnostik gibt es gegebenenfalls Abweichungen zur normalen Struktur des Laborbefundes. Die Angabe der getesteten Allergene bei Globalmarkern oder die zusätzliche Angabe von RAST-Klassen machen eine alternative Darstellung notwendig.

Folgende Darstellung wird dazu EMPFOHLEN:

Empfohlene Darstellung von Globalmarkern und Angabe der RAST-Klasse als Interpretation eines numerischen Ergebnisses. Sofern die RAST-Klasse angegeben wird, ist Option 3 empfohlen.
Abbildung 11: Empfohlene Darstellung von Globalmarkern und Angabe der RAST-Klasse als Interpretation eines numerischen Ergebnisses. Sofern die RAST-Klasse angegeben wird, ist Option 3 empfohlen.

Folgendes Codebeispiel zeigt die Befunddarstellung der Globalmarker im narrativen Text:

	<table>
		<thead>
			<tr>
				<th styleCode="xELGA_colw:80">Analyse</th>
				<th styleCode="xELGA_colw:10">Ergebnis</th>
				<th styleCode="xELGA_colw:10">Interpretation</th>
			</tr>
		</thead>
		<tbody>
			<tr ID="OBS-1-1">
				<td>sx1 Inhalatives Screening<br/>
				<content styleCode="italics">Lieschgras, Roggen, Birke, Beifuß, Dermatophagoides pteronyssinus, 
                                Katzenschuppen, Hundeschuppen, Cladosporium herbarum</content>
				</td>
				<td>negativ</td>
				<td></td>
			</tr>
			<tr ID="OBS-1-2" styleCode="xELGA_red">
				<td>mx1 Schimmelpilzemix 1<br/>
				<content styleCode="italics">Alternaria alternata, Aspergillus fumigatus, Cladosporium herbarum, 
                                Penicillium notatum</content></td>
				<td>positiv</td>
				<td>A</td>
			</tr>
		</tbody>
	</table>

6.5.6 Bemerkungen/Kommentare

Es gibt vier Arten von Bemerkungen:

  • zu einem einzelnen Analyseergebnis
  • zu einer Befundgruppe
  • zu einem Bereich
  • zum gesamten Befund, über alle Bereiche

6.5.6.1 Bemerkungen zu Analysen oder Analyseergebnissen

Existiert zu einer Analyse oder einem Analyseergebnis eine Bemerkung (z.B. um die Analyse oder das Ergebnis näher zu beschreiben), so wird die Analyse oder das Ergebnis mit einer Fußnotenreferenz versehen und die eigentliche Bemerkung im Footer der Ergebnistabelle dargestellt.

Darstellung einer Bemerkung zu einer Analyse.
Abbildung 12: Darstellung einer Bemerkung zu einer Analyse

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

<table>
<thead>
        ...
</thead>
<tfoot>
  <tr>
    <td>
      <footnote ID="fn1">
        <sup>1)</sup>INR nur gültig bei oraler Antikoagulation
      </footnote>
    </td>
  </tr>
</tfoot>
<tbody>
   ...
  <tr ID="OBS-2-2" styleCode="xELGA_red">
    <td>INR<sup>1)</sup></td>
    <td>1.0</td>
    <td></td>
    <td ID="OBSREF-2-2">2.0-3.5</td>
    <td>-</td>
  </tr>
 ...
<tbody>
</table>

6.5.6.2 Bemerkungen zu Befundgruppen

Bemerkungen zu Befundgruppen werden als eigener Absatz (paragraph-Element) nach der entsprechenden Ergebnistabelle codiert. Um den Text der Bemerkung aus Level 3 referenzierbar zu machen, MUSS dieser von einem content-Tag mit einer eindeutigen ID eingeschlossen werden (vgl. Kapitel Referenz von Level 3 auf Level 2).

<!-- Befundgruppe Blutbild -->
<caption styleCode="xELGA_h2">Blutbild</caption>
<table>
   ...
</table>
<paragraph>
  <content ID="BB_Comment">Das ist eine Bemerkung für die Gruppe 
  Blutbild</content>
</paragraph>

6.5.6.3 Bemerkungen zu einem Befundbereich

Bemerkungen zu einer Befundart werden am Ende der Codierung des Befundbereichs(Speciality) als Tabelle codiert. Um den Text der Bemerkung aus Level 3 referenzierbar zu machen, MUSS dieser von einem content-Tag mit einer eindeutigen ID eingeschlossen werden (vgl. Referenz von Level 3 auf Level 2).

<table>
	<thead>
	  <tr>
	    <th>Befundbewertung</th>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td><paragraph><content ID="commonComment1">Das ist die Bewertung für den
         "Allgemeinen Laborbefund". Diese kann auch sehr lange ausfallen.
         </content></paragraph>
     </td>
	  </tr>
	</tbody>
</table>	

6.5.6.4 Bemerkung zum gesamten Befund über alle Bereiche

Bemerkungen oder Kommentare, welche für den gesamten Befund von Bedeutung sind, werden in einer eigenen Sektion am Befundende geführt. Der menschenlesbare Text im <text> Element ist mit einer ID zu versehen, um auf diesen Text im Level 3 entry-Element referenzieren zu können. Die Spezifikation dieses Elements ist in Kapitel Bereichsübergreifende Befundbewertung ersichtlich.

Befundbewertung.
Abbildung 13: Befundbewertung

6.5.7 Makroskopie

Die Sektion „Makroskopie“ enthält allgemeine Informationen über die Materialbeschaffenheit, z.B. Stuhlkonsistenz.

6.5.7.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.6
Parent Template ID -
Titel der Sektion Makroskopie
Definition Diese Sektion beschreibt die Beschaffenheit des eingesendeten Materials, die mit bloßem Auge (ohne Zuhilfenahme eines Mikroskops) festgestellt wurde. Präparate werden in ihrer Zahl, Größe, Gewicht, Form und etwaigen Besonderheiten dokumentiert. Das Ergebnis wird als Freitext dokumentiert.
Codierung LOINC: 74574-5, „Macroscopic observation“
Konformität [O] [O]
Konformität Level 3 [O] [NP]

6.5.7.2 Spezifikation

1.2.40.0.34.11.4.2.6/dynamic

6.5.8 Mikroskopie

6.5.8.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.7
Parent Template ID -
Titel der Sektion Eigenschaften des Materials / Mikroskopie
Definition Diese Sektion beschreibt Eigenschaften des zu befundenden Materials welche mit Hilfe eines Lichtmikroskops ermittelt wurden. Es können sowohl qualitativ als auch quantitative Eigenschaften festgehalten werden.
Codierung SNOMED-CT: 395538009, „Microscopic specimen observation (finding)“
Konformität [O] [O]
Konformität Level 3 [O] [O]

Die Tabellendarstellung zeigt eine Eigenschaft des zu untersuchenden Materials mit dem zugehörigen Ergebnis sowie, wenn anwendbar, einer physikalischen Einheit. Neben der Darstellung von Informationen in tabellarischer Form kann diese auch in Freitextform erfolgen.

Eigenschaften des Materials-Mikroskopie.png
Abbildung 14: Eigenschaften des Materials/Mikroskopie

Wenn mikroskopische Ergebnisse auch in Level 3 codiert werden müssen die Ergebnisse als Tabelle angegeben werden.


6.5.8.2 Spezifikation

Id1.2.40.0.34.11.4.2.3
ref
elgabbr-
Gültigkeit2014‑12‑06
StatusKgreen.png AktivVersions-Label
NameMikroskopieSektionAnzeigenameSektion Mikroskopie
BeschreibungEigenschaften des Materials/Mikroskopie
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.4.2.3
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.4.2.3 Sektion Mikroskopie (2014‑12‑06)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section classCode="DOCSECT">
  <templateId root="1.2.40.0.34.11.4.2.3"/>  <id root="1.2.3.999" extension="--example only--"/>  <code code="104157003" codeSystem="2.16.840.1.113883.6.96" displayName="Light microscopy (procedure)"/>  <title>Eigenschaften des Materials / Mikroskopie</title>  <text>
    <table>
      <thead>
        <tr>
          <th>Eigenschaft</th>          <th>Ergebnis</th>          <th>Einheit</th>        </tr>
      </thead>
      <tbody>
        <tr ID="OBS-1-1">
          <td>Farbe</td>          <td>strohgelb</td>          <td/>        </tr>
         :       </tbody>
    </table>
  </text>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Mik...ion)
Treetree.png@classCode
cs1 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Mik...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.4.2.3
Treetree.pnghl7:id
II0 … 1Angabe einer Identifikation auf der Basis eines lokalen Nummernkreises.
Grundsätzlich sind die Vorgaben gemäß Kapitel 5.1 „Identifikations-Elemente“ des Allgemeinen Leitfadens zu befolgen.
(Mik...ion)
Treetree.pnghl7:code
CE1 … 1M(Mik...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F104157003
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.96 (Snomed-CT)
Treeblank.pngTreetree.png@displayName
1 … 1FLight microscopy (procedure)
Treetree.pnghl7:title
ST1 … 1M(Mik...ion)
 CONF
Elementinhalt muss "Eigenschaften des Materials / Mikroskopie" sein
Treetree.pnghl7:text
ST1 … 1MInformation für den menschlichen Leser. Information zum Format des Inhalts siehe Tabelle 6.(Mik...ion)
Treetree.pnghl7:entry
NPKeine codierte Information zur Mikroskopie vorgesehen.(Mik...ion)


Info.png
Achtung
Daten ändern sich noch, da mit SNOMED-CT codiert wird

6.5.9 Kultureller Erregernachweis

6.5.9.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.8
Parent Template ID -
Titel der Sektion Kultureller Erregernachweis
Definition Der Erregernachweis enthält Ergebnisse, welche mit Hilfe von Kulturen erlangt werden, und repräsentiert diese als Tabelle. Jede Zeile dieser Tabelle enthält die Bezeichnung des Erregers, die Methodik der Untersuchungsdurchführung sowie die Keimzahl. Vorgeschlagene Methodiken wären zum Beispiel:
  • Kultur (nach Bedarf anaerob/aerob)
  • Pilzkultur
Codierung SNOMED-CT: 446394004, “Microbial culture finding (finding)”
Konformität [O] [O]
Konformität Level 3 [O] [R]

Kultureller Erregernachweis.png
Abbildung 15: Kultureller Erregernachweis

6.5.9.2 Spezifikation

1.2.40.0.34.11.4.2.8/dynamic

6.5.9.2.1 Vorgaben und Empfehlung zur Gestaltung des Textbereichs
  • Vorgaben
    • Die Angabe zur Keimzahl hat über die displayNames des ELGA Value Sets „ELGA_LabQant“ zu erfolgen.
    • Sollte kein Erreger nachweisbar sein (ggf. aber apathogene Keime), wird folgende Formulierung EMPFOHLEN: „Erreger nicht nachweisbar“.
    • Sollten gar keine Keime (oder Mikroorganismen) nachweisbar sein, wird wird folgende Formulierung EMPFOHLEN: „Keime (oder Mikroorganismen) nicht nachweisbar“.
  • Empfehlung
    • Bei Bedarf kann die Tabelle in mehrere Teile mit Unterüberschriften geteilt werden (z.B. Keime, Pilze, MRSA-Screening
    • Optionale 1. Spalte: Fortlaufende Nummerierung für Angabe in Antibiogramm
    • Optionale 4. Spalte: Angaben für multiresistente Erreger (MRGN) - Resistenzeigenschaft. Die maschinenlesbare Abbildung dieser Information wird über ein Kommentar zur Analyse erreicht.

6.5.10 Antibiogramm und minimale Hemmkonzentration

Diese Sektion erlaubt Angaben zur Antibiotika Resistenz in Form eines Antibiogramms. Dieses Antibiogramm kann auch Angaben zur minimalen Hemmkonzentration enthalten.

6.5.10.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.9
Parent Template ID -
Titel der Sektion Antibiogramm
Definition Die Section Antibiogramm enthält Angaben über die Bestimmung der Empfindlichkeit bzw. Resistenz von mikrobiellen Krankheitserregern gegenüber Antibiotika. Das Antibiogramm wird im Befund als Matrix tabellarisch dargestellt, um die Empfindlichkeit mehrerer Erreger gegen mehrere Antibiotika übersichtlich zu gestalten. Die Empfindlichkeit oder Resistenz wird mit Buchstaben ausgedrückt. Neben den Buchstaben kann auch die jeweilige minimale Hemmkonzentration (MHK) numerisch angegeben werden.
Codierung LOINC: 18769-0, „Microbial susceptibility tests Set “
Konformität [O] [O]
Konformität Level 3 [O] [R]

Antibiogramm.png
Abbildung 16: Antibiogramm

Antibiogramm, alternative Darstellung mit Referenznummern.png
Abbildung 17: Antibiogramm, alternative Darstellung mit Referenznummern

6.5.10.2 Spezifikation

1.2.40.0.34.11.4.2.9/dynamic

6.5.10.2.1 Vorgaben und Empfehlung zur Gestaltung des Textbereichs
  • Vorgaben
    • Neben der Angabe der Resistenz gemeinsam mit der minimalen Hemmkonzentration besteht auch die Möglichkeit nur die Resistenz bzw. nur die minimale Hemmkonzentration anzugeben.
    • Die Legende der Tabelle soll die Erklärung der Sesistenzkennzeichen (R, S, I) und der MHK enthalten, sowie weitere Erklärungen
    • Wenn eine minimale Hemmkonzentration angegeben wird, ist dieser Wert im entsprechenden Feld neben der codierten Empfindlichkeit in eckigen Klammern festzuhalten.
  • Empfehlung
    • Bei mehreren Keimen kann in der Überschrift anstelle des Keimnamens auch eine fortlaufende Nummer angegeben werden. Diese Nummer wird in der Sektion „Kultureller Erregernachweis“ (siehe 4.5.8.3.1) definiert .

6.5.11 Molekularer Erregernachweis

6.5.11.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.10
Parent Template ID -
Titel der Sektion Molekularer Erregernachweis
Definition Die Section Molekularer Erregernachweis enthält Ergebnisse welche im Gegensatz zu klassischen Laborergebnissen die Angabe der Methodik als auch der/des Nachweisgrenze/Linearitätsbereichs.

Sollten Ergebnisse eines molekularen Erregernachweises in einem allgemeinen Laborbefund festgehalten werden, so sind diese als normale Laborergbnisse zu codieren (siehe Kapitel 4.5.5)

Codierung //TODO Code auf Section Ebene suchen für µBioBefunde
Konformität [NP] [O]
Konformität Level 3 [NP] [R]

Molekularer Erregernachweis.png
Abbildung 18:Testergebnisse/Molekularer Erregernachweis

6.5.11.2 Spezifikation

1.2.40.0.34.11.4.2.10/dynamic

6.5.11.2.1 Vorgaben und Empfehlung zur Gestaltung des Textbereichs
  • Vorgaben
    • Die Angabe des molekularen Erregernachweises hat in tabellarischer Form zu erfolgen
  • Empfehlung
    • -

6.5.12 Infektionsserologie

6.5.12.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.11
Parent Template ID -
Titel der Sektion Infektionsserologie
Definition Angaben zur Infektinosserologie

Sollten Ergebnisse eines molekularen Erregernachweises in einem allgemeinen Laborbefund festgehalten werden, so sind diese als normale Laborergbnisse zu codieren (siehe Kapitel 4.5.5)

Codierung //TODO code suchen
Konformität [NP] [O]
Konformität Level 3 [NP] [R]

6.5.12.2 Spezifikation

1.2.40.0.34.11.4.2.11/dynamic

6.5.12.2.1 Vorgaben und Empfehlung zur Gestaltung des Textbereichs
  • Vorgaben
    • Die Angabe von serologischen Ergebnissen hat in tabellarischer Form zu erfolgen
  • Empfehlung
    • -

6.5.13 Befundbewertung

6.5.13.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.4.2.2
Parent Template ID -
Titel der Sektion Befundbewertung
Definition Im Falle einer Gliederung eines Laborbefundes in zwei Hierarchieebenen (Bereiche und Befundgruppen) besteht die Notwendigkeit einer bereichsübergreifenden Befundbewertung/eines Befundkommentars. Die Abbildung derartiger bereichsübergreifender Befundbewertungen erfolgt über eine eigene Annotation Section (siehe [4]).
Codierung ELGA_LaborparameterErgaenzung: 20, „Befundbewertung“
Konformität [O] [O]
Konformität Level 3 [O] [O]

6.5.13.2 Spezifikation

Id1.2.40.0.34.11.4.2.2
ref
elgabbr-
Gültigkeit2013‑02‑10
Andere Versionen mit dieser Id:
  • Kblank.png LaboratoryReportCommentSection vom 2012‑01‑07
StatusKgreen.png AktivVersions-Label
NameLaboratoryReportCommentSectionAnzeigenameBereichsübergreifende Befundbewertung (Laboratory Report Comment Section)
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.4.2.2
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.4.3.2ContainmentKgreen.png Befundtext (Anmerkungen und Kommentare)DYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.4.2.2 Bereichsübergreifende Befundbewertung (Laboratory Report Comment Section) (2013‑02‑10)
ref
elgabbr-
Beispiel
Strukturbeispiel
<!--
Beispiel Befundbewertung Section
-->
<section classCode="DOCSECT">
  <templateId root="1.2.40.0.34.11.4.2.2"/>  <code code="20" codeSystem=" 1.2.40.0.34.5.11" codeSystemName=" ELGA_LaborparameterErgaenzung" displayName="Befundbewertung"/>  <title>Befundbewertung</title>  <text>
    <paragraph>
      <content ID="commonComment1">Zur Bestätigung des Befundes neuerliche Untersuchung in zwei Wochen empfohlen. </content>    </paragraph>
  </text>
  <entry>
    <act classCode="ACT" moodCode="EVN">
      <templateId root="1.2.40.0.34.11.4.3.2"/>      <templateId root="2.16.840.1.113883.10.20.1.40"/>      <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.2"/>      <code code="48767-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Annotation Comment"/>      <text>
        <reference value="#commonComment1"/>      </text>
      <statusCode code="completed"/>    </act>
  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
Laboratory Report Comment Section
Diese Section ist für Befunde, welche mehrere Bereiche enthalten, notwendig. Die Section ist die letzte Section im structuredBody.

(Lab...ion)
Treetree.png@classCode
cs1 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Lab...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.4.2.2
Treetree.pnghl7:code
CE1 … 1M(Lab...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F20
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.40.0.34.5.11
Treetree.pnghl7:title
ST1 … 1M(Lab...ion)
 CONF
Elementinhalt muss "Befundbewertung" sein
Treetree.pnghl7:text
ST1 … 1M(Lab...ion)
Treetree.pnghl7:entry
1 … 1RBeinhaltet 1.2.40.0.34.11.4.3.2 Befundtext (Anmerkungen und Kommentare) (DYNAMIC)(Lab...ion)


6.5.14 Beilagen

6.5.14.1 Überblick

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


Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.


6.5.15 Abschließende Bemerkungen

6.5.15.1 Überblick

Labor Mikrobiologie
Template ID ELGA: 1.2.40.0.34.11.1.2.2
Parent Template ID -
Titel der Sektion Abschließende Bemerkungen
Definition Ein am Ende des Briefes formulierter Freitext entsprechend ei-ner Grußformel.

Die Angabe von medizinisch fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT.

z.B. Abschließende Worte, Gruß

Codierung ELGA: ABBEM, „Abschließende Bemerkungen“
Konformität [O] [O]
Konformität Level 3 [NP] [NP]


Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.


6.5.16 Meldepflichtige Erreger

6.5.16.1 Überblick

Labor Mikrobiologie
Template ID ELGA: TODO
Parent Template ID -
Titel der Sektion Meldepflichtige Erreger
Definition In dieser Sektion ist die Angabe von meldepflichtigen Erregerns (Significant Pathogens) möglich. Diese Angabe wird in Form einer Liste empfohlen. Eine Liste der meldepflichtigen Erreger enthält das ELGA Value Set „ELGA_SignificantPathogens“. Für die Sektion muss der zugehörige DisplayName aus dem Value Set verwendet werden.

z.B.: folgende Meldepflichtigen Keime wurden nachgewiesen:

- Brucella spp.

Codierung ELGA: TODO
Konformität [O] [O]
Konformität Level 3 [O] [O]

6.6 Hinweise für akkreditierte Laboratorien gem. ISO 15189:2012

Die Vorgaben dieses Implementierungsleitfadens erlauben die Erzeugung von Befunden gemäß ISO 15189:2012 "Medizinische Laboratorien - Anforderungen an die Qualität und Kompetenz" [10], speziell in Hinblick auf die dort angegebenen Kapitel 5.8 (Befundberichte) und 5.9 (Freigabe der Ergebnisse). Für akkreditierte Laboratorien sind neben [10] folgende Hinweise zu beachten:

6.6.1 Angabe des Akkreditierungs-Logos

Das Akkreditierungs-Logo kann neben dem Logo des Labors angegeben werden. Technisch erfolgt das über die Section Brieftext, das Logo ist ggf. gemeinsam mit dem Logo des Labors in einer Grafikdatei anzugeben (6.2.2).

Angabe des Akkreditierungs-Logos im Briefkopf.
Abbildung 21: Angabe des Akkreditierungs-Logos im Briefkopf

Ein Labor muss nicht zwingend für alle Analysen, die es durchführen kann, akkreditiert sein. Das Akkreditierungs-Logo kann angegeben werden, sobald es akkreditierte Analysen gibt; wenn „nicht akkreditierte Analysen“ am Befund erscheinen, soll bei diesen angegeben werden können, dass das Labor für diese Analyse nicht akkreditiert ist. Für die entsprechend Markierung wird die Verwendung von Anmerkungszeichen (wie z.B. *) und Endnoten empfohlen.

6.6.2 Angabe des Untersuchungs- bzw Messverfahrens

Wenn der Name der Analysen keinen Rückschluss auf die Methode erlaubt, aber Untersuchungs- bzw Messverfahren dennoch angegeben werden sollen ([10], Vorgabe 5.8.3 a)), soll dies als Kommentar zur Analyse erfolgen (siehe Bemerkungen zu Analysen oder Analyseergebnissen).

6.6.3 Vorgaben für den Befunddruck

Einige Vorgaben von ISO 15189:2012 beziehen sich auf Qualitätsmerkmale für gedruckte Befunde ([10], Vorgabe 5.8.3 d „Identifizierung des Patienten und den Aufenthaltsort des Patienten auf jeder Seite“ und Vorgabe 5.8.3 p „Seitenzahl zur Gesamtzahl der Seiten“). Dieser Leitfaden definiert ein elektronisches Format, das diese Anforderungen grundsätzlich unterstützt. Am ELGA-Portal (Zugriff für Bürger) werden Tools zur Darstellung eingesetzt, die diese Vorgaben unterstützen. Diese Tools werden auch von der ELGA GmbH zum Download bereigestellt (Referenzstylesheet, CDA2PDF auf http://www.elga.gv.at/CDA).

6.7 Maschinenlesbare Elemente

Feld Opt Darstellung Details
Allgemeine Befundinformationen
Auftragsdiagnose und Fragestellung ClinicalDocument/component/structuredBody/component/section/.. O
[0..*]
Link
Spezimeninformation
../entry/act/entryRelationship/procedure <template root=”1.3.6.1.4.1.19376.1.3.1.2”> R2
[0..*]
Link
../entry/act/entryRelationship/procedure/entryRelationship/act <template root=”1.3.6.1.4.1.19376.1.3.1.3”> R2
[0..*]
Link
Befundgruppen
Befundgruppen (Laboratory Battery Organizer) ../entry/act/entryRelationship/organizer O
[0..*]
Link
Laborergebnisse (Laboratory Observation) ../entry/act/entryRelationship/organizer/component/observation/ <templateId root="1.3.6.1.4.1.19376.1.3.1.6">
Analyse: Identifikation/Codierung ../id und ../code M
[1..1]
Link
Ergebnis und Einheit ../value M
[1..1]
Link
Referenzbereiche ../referenceRange R2
[0..*]
Link
Befundinterpretation ../interpretationCode R2
[0..*]
Link
Kommentar zu einer Analyse ../entryRelationship/act 0
[0..1]
Link
Externes Labor ../performer C
[0..1]
Link
Kultureller Erregernachweis ../entry/act/entryRelationship/organizer
Erregernachweis mit Definition der Methodik ../component/observation R2
[0..*]
Link
Antibiogramm und minimale Hemmkonzentration ../entry/act/entryRelationship/organizer
Antibiogramm und minimale Hemmkonzentration ../component/organizer R2
[0..*]
Link, Link
Testergebnisse / Molekularer Erregernachweis ../entry/act/entryRelationship/organizer
Testergebnisse und Molekularer Erregernachweis ../component/observation R2
[0..*]
Link
Significant Pathogens ../entry/act/entryRelationship/organizer
Significant Pathogens ../component/organizer C
[0..1]
Link

6.7.1 ELGA Logo-Entry

Dieses Element wird verwendet wenn das Logo der befunderstellenden Organization angeführt werden soll.

Template ID ELGA: 1.2.40.0.34.11.1.3.2
Parent Template ID -
Verwendet von folgender/folgenden Sektion(en) Brieftext (siehe Kapitel 4.4)


Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.


6.7.2 Probeninformation Entry (Specimen-Section)

Template ID ELGA: 1.2.40.0.34.11.4.3.1
Parent Template ID -
Verwendet von folgender/folgenden Sektion(en) Spezimen / Probeninformation (siehe Kapitel 4.5.44.4)

6.7.2.1 Überblick

In der aktuellen Version des „Laboratory Technical Framework Volume 3 – Revision 3.0“ (LAB TF-3) wurde die Vorgangsweise zur Codierung des Spezimen grundlegend geändert. Die zum Teil noch verbreitete Variante der Spezimen-Codierung laut „Laboratory Technical Framework Volume 3 – Revision 2.1“ sah vor, dass man ein oder mehrere Specimen/Proben mittels des specimen-Elementes innerhalb des Specimen-Act codieren konnte. In Version 3.0 des LAB TF-3 kann ein Spezimen/Probe nur über ein entryRelationship als Specimen-Collection angegeben werden.

Die Codierung von Informationen zum Spezimen ist für Befunde der ELGA Interoperabilitäts Stufe „Full support“ als auch bei mikrobiologischen Befunden verpflichtend. Diese Codierung erfolgt bei Befunden, welche aus mehreren Bereichen bestehen in einer eigenen Sektion „Probeninformation“. Bei Befunden, welche nur aus einer Sektion bestehen kann die Codierung der Information zum Spezimen auch in dieser Sektion geschehen.

Abnahmeinformationen werden analog zu den Vorgaben der IHE ([3]) als „Specimen Collection“ Block unter dem Spezimen-Act codiert. Die Darstellung erfolgt über ein act-Element, welches über eine entryRelationship Verbindung mit dem Spezimen-Act verbunden ist (../entry/act/entryRelationship/act).

Informationen zur Probenannahme werden analog zu den Vorgaben der IHE ([3]) als „Specimen Received“ Block unter dem Spezimen-Act codiert. Die Darstellung erfolgt über ein act-Element, welches über eine entryRelationship Verbindung mit dem Spezimen-Act verbunden ist (../entry/act/entryRelationship/act).


Hinweis für mikrobiologische Befunde:
Derzeit werden mikrobiologische Befunde mit mehreren Proben nicht unterstützt! Dies bedeutet, dass in einem mikrobiologischen Befund nur eine Proben / Material / Spezimen geführt werden darf!


6.7.2.2 Spezifikation

Id1.2.40.0.34.11.4.3.1
ref
elgabbr-
Gültigkeit2013‑02‑10
Andere Versionen mit dieser Id:
  • Kblank.png LaboratorySpecimenEntry vom 2012‑01‑07
StatusKgreen.png AktivVersions-Label
NameLaboratorySpecimenEntryAnzeigenameLaboratory Specimen Entry
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.4.3.1
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.11.30021ContainmentKgreen.png Abnahmeinformationen (Specimen Collection)DYNAMIC
ItemDTKardKonfBeschreibungLabel
hl7:act
(Lab...try)
Treetree.png@classCode
1 … 1FACT
Treetree.png@moodCode
1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1(Lab...try)
Treeblank.pngTreetree.png@root
1 … 1F1.2.40.0.34.11.4.3.1
Treetree.pnghl7:code
CE1 … 1M(Lab...try)
Treeblank.pngTreetree.png@code
CONF1 … 1F10
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.40.0.34.5.11
Treetree.pnghl7:statusCode
CS0 … 1(Lab...try)
Treeblank.pngTreetree.png@code
CONF0 … 1Fcompleted
Treetree.pnghl7:entryRelationship
1 … *MBeinhaltet 1.2.40.0.34.11.30021 Abnahmeinformationen (Specimen Collection) (DYNAMIC)(Lab...try)
Treeblank.pngTreetree.png@typeCode
1 … 1FCOMP


6.7.3 Mikroskopie Entry

Template ID IHE: 1.3.6.1.4.1.19376.1.3.1
Parent Template ID -
Verwendet von folgender/folgenden Sektion(en) Mikroskopie (siehe Kapitel 4.5.74.4)

6.7.3.1 Spezifikation

1.3.6.1.4.1.19376.1.3.1/dynamic

6.7.4 Laboratory Report Data Processing Entry

Die Angabe eines entry-Eintrages im Rahmen der Codierung einer Befundart ist Pflicht. Dieses Element wird gem. [3] als „Laboratory Report Data Processing Entry“ bezeichnet und folgt einem spezifischen Template.

<templateId root="1.3.6.1.4.1.19376.1.3.1"
extension="Lab.Report.Data.Processing.Entry"/>

Der entry-Eintrag ist mit dem Attribute typeCode=“DRIV“ zu versehen, um anzuzeigen, dass der Level 2 vollständig aus dem Level 3 erzeugt werden kann.

Das entry-Element enthält genau ein act-Subelement – den sogenannten „Spezimen-Act“.

6.7.5 Der Spezimen-Act

Wie bereits in Kapitel 1.1.14. angeführt, erfolgt die Codierung der Ergebnisse zu einer Befundart immer auf oberster Ebene unter genau einem act-Element – dem „Spezimen–Act“. Damit befindet sich unter dem component/section/entry-Element immer genau ein Unterelement. Alle weiteren Elemente - sowohl Spezimen als auch Befundgruppen, Untersuchungen etc. - werden in der Hierarchie unter dem Spezimen-Act codiert. Der Act MUSS zumindest eine Untersuchung beinhalten.

6.7.5.1 Spezifikation

Id1.2.40.0.34.11.30020
ref
elgabbr-
Gültigkeit2017‑02‑22
Andere Versionen mit dieser Id:
  • Kblank.png SpezimenActEntryAllgemein vom 2017‑02‑20
  • Kblank.png SpezimenActEntryAllgemein vom 2015‑04‑30
  • Kblank.png SpezimenActEntryAllgemein vom 2014‑03‑04
  • Kblank.png SpezimenActEntryAllgemein vom 2012‑01‑07
StatusKyellow.png EntwurfVersions-Label
NameSpezimenActEntryAllgemeinAnzeigenameELGA Spezimen-Act-Entry Allgemein
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 8 Templates
Benutzt als NameVersion
1.2.40.0.34.11.30021ContainmentKgreen.png Abnahmeinformationen (Specimen Collection)DYNAMIC
1.3.6.1.4.1.19376.1.3.1.4ContainmentKyellow.png Befundgruppen (Laboratory Battery Organizer)DYNAMIC
1.3.6.1.4.1.19376.1.3.1.6ContainmentKyellow.png Laborergebnisse (Laboratory Observation)DYNAMIC
1.2.40.0.34.11.4.3.4ContainmentKyellow.png Laborergebnisse aktiv (Laboratory Observation Active)DYNAMIC
1.2.40.0.34.11.30025ContainmentKyellow.png Kultureller Keimnachweis (Laboratory Isolate Organzier)DYNAMIC
1.2.40.0.34.11.4.3.2ContainmentKgreen.png Befundtext (Anmerkungen und Kommentare)DYNAMIC
1.3.6.1.4.1.19376.1.3.1.1ContainmentKgreen.png Notification OrganizerDYNAMIC
1.2.40.0.34.11.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.30020 ELGA Spezimen-Act-Entry Allgemein (2017‑02‑22)
ref
elgabbr-
ItemDTKardKonfBeschreibungLabel
hl7:act
(Spe...ein)
Treetree.png@classCode
cs1 … 1FACT
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:code
CE1 … 1MAngabe der Befundart.
(Spe...ein)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.47 ELGA_Laborstruktur (DYNAMIC)
Treetree.pnghl7:statusCode
CS1 … 1MNachdem in ELGA nur abgeschlossene Befunde abgelegt werden ist dieses Attribut  fix mit „completed“ zu belegen.
(Spe...ein)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Auswahl1 … Elemente in der Auswahl:
  • hl7:entryRelationship welches enthält Template 1.2.40.0.34.11.30021 Abnahmeinformationen (Specimen Collection) (DYNAMIC)
  • hl7:entryRelationship welches enthält Template 1.3.6.1.4.1.19376.1.3.1.4 Befundgruppen (Laboratory Battery Organizer) (DYNAMIC)
  • hl7:entryRelationship welches enthält Template 1.3.6.1.4.1.19376.1.3.1.6 Laborergebnisse (Laboratory Observation) (DYNAMIC)
  • hl7:entryRelationship welches enthält Template 1.2.40.0.34.11.4.3.4 Laborergebnisse aktiv (Laboratory Observation Active) (DYNAMIC)
  • hl7:entryRelationship welches enthält Template 1.2.40.0.34.11.30025 Kultureller Keimnachweis (Laboratory Isolate Organzier) (DYNAMIC)
  • hl7:entryRelationship welches enthält Template 1.2.40.0.34.11.4.3.2 Befundtext (Anmerkungen und Kommentare) (DYNAMIC)
  • hl7:entryRelationship welches enthält Template 1.3.6.1.4.1.19376.1.3.1.1 Notification Organizer (DYNAMIC)
  • hl7:entryRelationship[hl7:observationMedia] welches enthält Template 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)
Treeblank.pngTreetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.2.40.0.34.11.30021 Abnahmeinformationen (Specimen Collection) (DYNAMIC)(Spe...ein)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treeblank.pngTreetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.3.6.1.4.1.19376.1.3.1.4 Befundgruppen (Laboratory Battery Organizer) (DYNAMIC)(Spe...ein)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treeblank.pngTreetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.3.6.1.4.1.19376.1.3.1.6 Laborergebnisse (Laboratory Observation) (DYNAMIC)(Spe...ein)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treeblank.pngTreetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.2.40.0.34.11.4.3.4 Laborergebnisse aktiv (Laboratory Observation Active) (DYNAMIC)(Spe...ein)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treeblank.pngTreetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.2.40.0.34.11.30025 Kultureller Keimnachweis (Laboratory Isolate Organzier) (DYNAMIC)(Spe...ein)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treeblank.pngTreetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.2.40.0.34.11.4.3.2 Befundtext (Anmerkungen und Kommentare) (DYNAMIC)(Spe...ein)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treeblank.pngTreetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.3.6.1.4.1.19376.1.3.1.1 Notification Organizer (DYNAMIC)(Spe...ein)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treeblank.pngTreetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Spe...ein)
wo [hl7:observationMedia]
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP


6.7.6 Befundgruppen (Laboratory Battery Organizer)

6.7.6.1 Überblick

Innerhalb einer Befundart kann auf zweiter Ebene die Strukturierung nach Befundgruppen erfolgen. Diese werden in Form von Laboratory Battery Organizer (vgl. [3]), welche eine Gruppierung von Ergebnissen ermöglichen, dargestellt. Die Implementierung erfolgt über einen organizer, welcher mittels entryRelationship mit dem Spezimen-Act verbunden ist. Die Struktur entspricht einem Template, welches verpflichtend anzugeben ist.

<templateId root="1.3.6.1.4.1.19376.1.3.1.4"/>

Die Untersuchungsergebnisse werden als component unter dem Organizer abgebildet.

Für die Codierung des code-Elementes sind Codes der Ebene 2 der hierarchischen Liste „ELGA_Laborstruktur“ zu verwenden.

6.7.6.2 Spezifikation

Id1.3.6.1.4.1.19376.1.3.1.4
ref
elgabbr-
Gültigkeit2017‑02‑23
Andere Versionen mit dieser Id:
  • Kblank.png LaboratoryBatteryOrganizer vom 2013‑09‑09
StatusKyellow.png EntwurfVersions-Label
NameLaboratoryBatteryOrganizerAnzeigenameBefundgruppen (Laboratory Battery Organizer)
KontextElternknoten des Template-Element mit Id 1.3.6.1.4.1.19376.1.3.1.4
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 4 Templates
Benutzt als NameVersion
1.3.6.1.4.1.19376.1.3.1.6ContainmentKyellow.png Laborergebnisse (Laboratory Observation)DYNAMIC
1.2.40.0.34.11.4.3.4ContainmentKyellow.png Laborergebnisse aktiv (Laboratory Observation Active)DYNAMIC
1.2.40.0.34.11.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
1.2.40.0.34.11.4.3.2ContainmentKgreen.png Befundtext (Anmerkungen und Kommentare)DYNAMIC
BeziehungVersion: Template 1.3.6.1.4.1.19376.1.3.1.4 Befundgruppen (Laboratory Battery Organizer) (2017‑02‑23)
ref
elgabbr-
Beispiel
Strukturbeispiel
<organizer classCode="BATTERY" moodCode="EVN">
  <templateId root="1.3.6.1.4.1.19376.1.3.1.4"/>  <code code="301" codeSystem="1.2.40.0.34.5.11" codeSystemName="ELGA_LaborparameterErgaenzung" displayName="Blutbild">
    <originalText>
      <reference value="hem1"/>    </originalText>
  </code>
  <statusCode code="completed"/>  <component typeCode="COMP">
    <observation classCode="OBS" moodCode="EVN"> ... </observation>  </component>
  <component typeCode="COMP">
    <observation classCode="OBS" moodCode="EVN"> ... </observation>  </component>
   .. </organizer>
ItemDTKardKonfBeschreibungLabel
hl7:organizer
Die Befundgruppe als maschinenlesbares Element ist optional.
(Lab...zer)
Treetree.png@classCode
cs1 … 1FBATTERY
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1R(Lab...zer)
Treeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.1.4
Treetree.pnghl7:code
CE1 … 1M(Lab...zer)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.47 ELGA_Laborstruktur (DYNAMIC)
Treetree.pnghl7:statusCode
CS1 … 1M(Lab...zer)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:effectiveTime
IVL_TS0 … 1Fertigstellungszeitpunkt der enthaltenen Tests: Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.(Lab...zer)
Treeblank.pngTreetree.pnghl7:low
TS.​DATE.​MIN1 … 1M(Lab...zer)
Treeblank.pngTreetree.pnghl7:high
TS.​DATE.​MIN1 … 1M(Lab...zer)
Treetree.pnghl7:component
0 … *Ein Battery Organizer enthält nur dann KEIN Laborergebnis (Observation) wenn der Test abgebrochen wurde. In allen anderen Fällen ist mindestens ein Ergebnis anzuführen.
Beinhaltet 1.3.6.1.4.1.19376.1.3.1.6 Laborergebnisse (Laboratory Observation) (DYNAMIC)
(Lab...zer)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treetree.pnghl7:component
0 … *Beinhaltet 1.2.40.0.34.11.4.3.4 Laborergebnisse aktiv (Laboratory Observation Active) (DYNAMIC)(Lab...zer)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treetree.pnghl7:component
0 … *Beinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Lab...zer)
wo [hl7:observationMedia]
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treetree.pnghl7:component
0 … *Beinhaltet 1.2.40.0.34.11.4.3.2 Befundtext (Anmerkungen und Kommentare) (DYNAMIC)(Lab...zer)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP


6.7.7 Laborergebnisse (Laboratory Observation)

6.7.7.1 Überblick

Ergebnisse einer Laboruntersuchung werden als observation-Block codiert. Jede Observation stellt das Ergebnis zu genau einer Laboruntersuchung dar; entweder als Einzeluntersuchung direkt unter dem Spezimen-Act oder als Teil einer Befundgruppe (Laboratory Battery Organizer 4.7.64.4.6). Dies entspricht einem spezifischen Template welches verpflichtend als Element anzuführen ist.

<templateId root="1.3.6.1.4.1.19376.1.3.1.6"/>

6.7.7.2 Spezifikation

Id1.3.6.1.4.1.19376.1.3.1.6
ref
elgabbr-
Gültigkeit2020‑06‑15 08:50:28
Andere Versionen mit dieser Id:
  • Kblank.png LaboratoryObservation vom 2015‑03‑26
  • Kblank.png LaboratoryObservation vom 2014‑12‑06
  • Kblank.png LaboratoryObservation vom 2014‑03‑04
  • Kblank.png LaboratoryObservation vom 2013‑11‑07
StatusKyellow.png EntwurfVersions-Label
NameLaboratoryObservationAnzeigenameLaborergebnisse (Laboratory Observation)
KontextElternknoten des Template-Element mit Id 1.3.6.1.4.1.19376.1.3.1.6
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.40.0.34.11.4.3.2ContainmentKgreen.png Befundtext (Anmerkungen und Kommentare)DYNAMIC
1.2.40.0.34.11.4.3.3ContainmentKgreen.png Laboratory Performer 2DYNAMIC
BeziehungVersion: Template 1.3.6.1.4.1.19376.1.3.1.6 Laborergebnisse (Laboratory Observation) (2015‑03‑26)
ref
elgabbr-
Beispiel
Strukturbeispiel Laborergebnis (Laboratory Observation)
<ClinicalDocument>
  <observation classCode="OBS" moodCode="EVN">
    <!-- TemplateId für Laboratory Observation -->
    <templateId root="1.3.6.1.4.1.19376.1.3.1.6"/>    <!-- Testidentifikation -->
    <id extension="OBS-1-4" root="2.16.840.1.113883.2.16.1.99.3.1"/>    <!-- Analyse/Testcode -->
    <code code="26464-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Leukozyten"/>    <!-- Verweis auf den narrativen Text -->
    <text>
      <reference value="#OBS-1-4"/>    </text>
    <!-- Status des Laborergebnisses -->
    <statusCode code="completed"/>    <!-- medizinisch relevanter Zeitpunkt -->
    <effectiveTime>
      <low value="20131201073406+0100"/>      <high nullFlavor="UNK"/>    </effectiveTime>
    <!-- Ergebnis der Analyse / des Tests -->
    <value unit="g/dL" value="16.0" type="PQ"/>    <!-- Bewertung des Ergebnisses -->
    <interpretationCode code="N" codeSystemName="HL7:ObservationInterpretation" codeSystem="2.16.840.1.113883.5.83" displayName="normal"/>    <!-- Validator -->
    <participant typeCode="AUTHEN"> : </participant>    <!-- Durchführende Instanz / externes Labor -->
    <performer typeCode="PRF"> : </performer>  </observation>
</ClinicalDocument>
Beispiel
Strukturbeispiel für ein Laborergebnis mit Cut-off-Wert (Datentyp IVL_PQ)
<!--So kann ein Wert von > 500 mg/dl dargestellt und bewertet werden:-->
<ClinicalDocument>
  <value type="IVL_PQ">
    <low value="500" unit="mg/dl" inclusive="false"/>    <high nullFlavor="PINF"/>  </value>
  <interpretationCode code=" >" displayName="High off scale" codeSystem="2.16.840.1.113883.5.83 "/></ClinicalDocument>
Beispiel
Strukturbeispiel für ein in Arbeit befindliches Laborergebnis („Wert folgt“)
<!--Angabe von Parametern mit ausständigem Ergebnis:-->
<ClinicalDocument>
  <!--Angabe von Parametern mit ausständigem Ergebnis:-->
  <!--Laboratory Observation, Ergebnis noch nicht verfügbar (Wert folgt)-->
  <observation classCode="OBS" moodCode="EVN">
    <templateId root="1.3.6.1.4.1.19376.1.3.1.6"/>    <id extension="OBS-2-6" root="2.16.840.1.113883.2.16.1.99.3.1"/>    <code code="10704-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Wurmeier Stuhl"/>    <text>
      <reference value="#OBS-2-6"/>    </text>
    <!-- Status des Laborergebnisses -->
    <statusCode code="active"/>    <effectiveTime nullFlavor="UNK"/>    <value type="ST">Wert folgt</value>    <!-- Bewertung des Ergebnisses wird nicht angegeben [NP] -->
  </observation>
</ClinicalDocument>
ItemDTKardKonfBeschreibungLabel
hl7:observation
(Lab...ion)
Treetree.png@classCode
cs1 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1R(Lab...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.1.6
Treetree.pnghl7:id
II0 … 1Identifikation des Tests nach einer internen Codierung. Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.
(Lab...ion)
Treetree.pnghl7:code
CE1 … 1RCodierung der Analyse / des Tests. 
(Lab...ion)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.44 ELGA_Laborparameter (DYNAMIC)
 Schematron assertrole error 
 testnot(@nullFlavor) or not(@nullFlavor='OTH') or hl7:translation 
 MeldungWenn code/@nullFlavor=OTH dann MUSS entweder code/translation anwesend sein. 
Treetree.pnghl7:text
ED0 … 1
Der Text zum Laborergebnis wird verwendet, um einen Verweis zum narrativen Text herzustellen, Verwendung siehe 6.2.9.2 
(Lab...ion)
Treetree.pnghl7:statusCode
CS1 … 1MStatuscode.

Auswahl:
completed“ für einen abgeschlossenen Test.
aborted“ für einen stornierten Test (konnte nicht durchgeführt werden)
active“ für einen ausständigen Test („Wert folgt“)

(Lab...ion)
 CONF
@code muss "completed" sein
oder
@code muss "aborted" sein
Treetree.pnghl7:effectiveTime
IVL_TS1 … 1RMedizinisch relevantes Datum und Zeit. In der Regel Abnahmedatum/-zeit des Spezimen.
(Lab...ion)
Auswahl0 … 1Elemente in der Auswahl:
  • hl7:value[@xsi:type='PQ']
  • hl7:value[@xsi:type='IVL_PQ']
  • hl7:value[@xsi:type='INT']
  • hl7:value[@xsi:type='IVL_INT']
  • hl7:value[@xsi:type='BL']
  • hl7:value[@xsi:type='ST']
  • hl7:value[@xsi:type='CV']
  • hl7:value[@xsi:type='TS']
  • hl7:value[@xsi:type='CD']
  • hl7:value[@xsi:type='RTO']
  • hl7:value[@xsi:type='RTO_QTY_QTY']
  • hl7:value[@xsi:type='RTO_PQ_PQ']
 ConstraintKonditionale Konformität:
  • Bei EIS "Basic" 1..1 R2 Codierung der Einheit erforderlich (im Element translation)
  • Bei EIS "Enhanced" 1..1 M Codierung der Einheit nach UCUM erforderlich
Datentyp eingeschränkt auf PQ, IVL_PQ, INT, IVL_INT, BL, ST, CV, TS, CD, RTO, RTO_QTY_QTY, RTO_PQ_PQ
Treeblank.pngTreetree.pnghl7:value
PQCErgebnis der Analyse codiert entsprechend dem Datentyp.
Kann bei stornierten Analysen entfallen.

Unterelemente können je nach Datentyp notwendig sein, z.B. high/low für IVL oder numerator/denominator für RTO.
(Lab...ion)
wo [@xsi:type='PQ']
Treeblank.pngTreeblank.pngTreetree.pnghl7:translation
PQR0 … 1Alternative Repräsentation derselben physikalischen Größe, mit unterschiedlicher Einheit in @code und @codeSystem und einem möglicherweise unterschiedlichen Wert.(Lab...ion)
Treeblank.pngTreetree.pnghl7:value
IVL_PQC(Lab...ion)
wo [@xsi:type='IVL_PQ']
Treeblank.pngTreetree.pnghl7:value
INTC(Lab...ion)
wo [@xsi:type='INT']
Treeblank.pngTreetree.pnghl7:value
IVL_INTC(Lab...ion)
wo [@xsi:type='IVL_INT']
Treeblank.pngTreetree.pnghl7:value
BLC(Lab...ion)
wo [@xsi:type='BL']
Treeblank.pngTreetree.pnghl7:value
STC(Lab...ion)
wo [@xsi:type='ST']
Treeblank.pngTreetree.pnghl7:value
CVC(Lab...ion)
wo [@xsi:type='CV']
Treeblank.pngTreetree.pnghl7:value
TSC(Lab...ion)
wo [@xsi:type='TS']
Treeblank.pngTreetree.pnghl7:value
CDC(Lab...ion)
wo [@xsi:type='CD']
Treeblank.pngTreetree.pnghl7:value
RTOC(Lab...ion)
wo [@xsi:type='RTO']
Treeblank.pngTreetree.pnghl7:value
RTO_QTY_QTYC(Lab...ion)
wo [@xsi:type='RTO_QTY_QTY']
Treeblank.pngTreetree.pnghl7:value
RTO_PQ_PQC(Lab...ion)
wo [@xsi:type='RTO_PQ_PQ']
 Schematron assertrole error 
 testnot(hl7:value/@nullFlavor) 
 MeldungDie Verwendung von value/@nullFlavor ist nicht erlaubt 
Treetree.pnghl7:interpretationCode
CE0 … *Codierte Bewertung des Ergebnisses. Wird sowohl für Referenzbereichbewertungen als auch für die Codierung der RAST-Klassen verwendet.
(Lab...ion)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.13 ELGA_ObservationInterpretation (DYNAMIC)
 Schematron assertrole error 
 testnot(hl7:referenceRange) or hl7:interpretationCode 
 MeldungWenn zu einem Laborergebnis Referenzwerte mit observation/referenceRange angeführt werden MUSS auch eine Befundinterpretation in observation/interpretationCode erfolgen. 
Treetree.pnghl7:entryRelationship
0 … *Beinhaltet 1.2.40.0.34.11.4.3.2 Befundtext (Anmerkungen und Kommentare) (DYNAMIC)(Lab...ion)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treetree.pnghl7:participant
0 … 1Validierende Person.
(Lab...ion)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FAUTHEN
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1R(Lab...ion)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.5
Treeblank.pngTreetree.pnghl7:time
IVL_TS1 … 1R(Lab...ion)
Treeblank.pngTreetree.pnghl7:participantRole
(Lab...ion)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1M(Lab...ion)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1R(Lab...ion)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT1 … *R(Lab...ion)
Treeblank.pngTreeblank.pngTreetree.pnghl7:playingEntity
1 … 1M(Lab...ion)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Lab...ion)
Treetree.pnghl7:referenceRange
0 … *Es können mehrere Referenzbereiche angegeben werden.
(Lab...ion)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FREFV
 Beispiel
43.0% - 49.0% (im zugehörigen Section.text steht der entsprechende Text)
<referenceRange typeCode="REFV">
  <observationRange classCode="OBS" moodCode="EVN.CRT">
    <text>
      <reference value="#ref1"/>    </text>
    <value type="IVL_PQ">
      <low value="43.0" unit="%"/>      <high value="49.0" unit="%"/>    </value>
    <interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83" codeSystemName="HL7.ObservationInterpretation"/>  </observationRange>
</referenceRange>
 Beispiel
> 40.0% (im zugehörigen Section.text steht der entsprechende Text)
<referenceRange typeCode="REFV">
  <observationRange classCode="OBS" moodCode="EVN.CRT">
    <text>
      <reference value="#ref2"/>    </text>
    <value type="IVL_PQ">
      <low value="40.0" unit="%" inclusive="false"/>    </value>
    <interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83" codeSystemName="HL7.ObservationInterpretation"/>  </observationRange>
</referenceRange>
 Beispiel
Phase 1: 43.0 - 49.0 Phase 2: 45.0 – 55.0 1835 Phase 3: 49.0 – 63.0 (im zugehörigen Section.text steht der entsprechende Text)
<referenceRange typeCode="REFV">
  <observationRange classCode="OBS" moodCode="EVN.CRT">
    <text>
      <reference value="#ref3"/>    </text>
    <interpretationCode code="H" codeSystem="2.16.840.1.113883.5.83"/>  </observationRange>
</referenceRange>
 Beispiel
> 40.0% (im zugehörigen Section.text steht der entsprechende Text)
<referenceRange typeCode="REFV">
  <observationRange classCode="OBS" moodCode="EVN.CRT">
    <text>
      <reference value="#ref4"/>    </text>
    <value type="IVL_PQ">
      <low value="40.0" unit="%" inclusive="false"/>      <high nullFlavor="PINF"/>    </value>
  </observationRange>
</referenceRange>
 Beispiel
150 - 360 G/L (im zugehörigen Section.text steht der entsprechende Text)
<referenceRange typeCode="REFV">
  <observationRange classCode="OBS" moodCode="EVN.CRT">
    <text>
      <reference value="#ref5"/>    </text>
    <value type="IVL_PQ">
      <low value="150" unit="G/L"/>      <high value="360" unit="G/L"/>    </value>
    <interpretationCode code="N" codeSystemName="HL7:ObservationInterpretation" codeSystem="2.16.840.1.113883.5.83" displayName="normal"/>  </observationRange>
</referenceRange>
Treeblank.pngTreetree.pnghl7:observationRange
1 … 1M(Lab...ion)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FOBS
Treeblank.pngTreeblank.pngTreetree.png@moodCode
cs1 … 1FEVN.CRT
Treeblank.pngTreeblank.pngTreetree.pnghl7:text
ED1 … 1M(Lab...ion)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:reference
TEL1 … 1M(Lab...ion)
Treeblank.pngTreeblank.pngTreetree.pnghl7:value
IVL_PQ0 … 1(Lab...ion)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@xsi:type
1 … 1FIVL_PQ
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:low[not(@nullFlavor)]
  • hl7:low[@nullFlavor='NA']
  • hl7:low[@nullFlavor='NINF']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
PQ0 … 1(Lab...ion)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
PQ0 … 1(Lab...ion)
wo [@nullFlavor='NA']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNA
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
PQ0 … 1(Lab...ion)
wo [@nullFlavor='NINF']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png