Befund bildgebende Diagnostik

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 offenen „Arbeitsgruppe Radiologiebefund“ in den Jahren 2008-2012, bestehend aus den unten genannten Personen.

Autoren
Kürzel Organisation Person1
Herausgeber, Projektleiter, CDA Koordinator
SSA ELGA GmbH Stefan Sabutsch
Autor, Fachkoordinator, Moderator und Co-Redaktion
MWE AIMC GmbH Martin Weigl
AOL Lindner TAC Andreas O. Lindner
AME Fachhochschule Technikum Wien Alexander Mense
CGR HL7 Austria Christian Gruber
Organisation Person1
Ärztliche Vertreter
Österreichische Ärztekammer Franz Frühwald, Hans Mosser, Martin Wehrschütz
Österreichische Röntgengesellschaft Werner Jaschke
AKH Linz Thomas Gitter
Sozialmedizinisches Zentrum Ost, Abt. f. Nuklearmedizin Thomas Leitha
Österreichische Röntgengesellschaft Thomas Löwe
KAV KH Hietzing Radiologie Thomas Rand
Unfallkrankenhaus Graz der AUVA Ulrike Schneider
Steiermärkische Krankenanstaltenges.m.b.H. Erich Sorantin
Krankenhausträger
Wiener Krankenanstaltenverbund Konrad Hölzl
Steiermärkische Krankenanstaltenges.m.b.H. Markus Pedevilla
Organisationen
Österreichische Ärztekammer Gerhard Holler
Bundesfachgruppe Radiologie der österr. Ärztekammer Brigitte Janisch
Softwarehersteller / Lösungsanbieter
D.A.T.A. Corporation Rainer Anzböck, Irene Klein
Philips Healthcare Walter Auer, R. Schachhuber, Christian Strondl
Systema Human Information Systems GmbH Thomas Bettstein
AGFA Health Care Mircea Girlasu
Siemens AG Österreich - Produktmanagement I.S.H.med Thomas Gitter
Lukas Software Alfred Lukas
Sustsol - Sustainable Solutions Karl Rössl
CAS Computer Anwendungssysteme GmbH Dietmar Ruzicka
Universitäten / Fachhochschulen
Fachhochschule Technikum Wien Matthias Frohner, F.Gerbovics, Philipp Urbauer
Patronanz, Akkordierung, Ergänzungen, Zustimmung
Organisation Person1
Bundesministerium für Gesundheit Clemens Auer
ELGA GmbH Susanne Herbek, Hubert Eisl, Martin Hurch, Oliver Kuttin
OÖ. Gesundheitsfonds Wolfgang Hießl
Österreichische Ärztekammer Sabine Manhardt
NÖ Landesklinik Holding Thomas Pöckl, Alexander Schanner
ITH icoserve technology for healthcare GmbH Thomas Schabetsberger
Ärztekompetenzzentrum Krems Andreas Stippler
Andere ELGA Arbeitsgruppen
Bereich Organisation Person1
Befundbericht Labor Fachhochschule Technikum Wien Stefan Sauermann
Entlassungsbrief Arzt und Pflege CodeWerk Software Services and Development GmbH Jürgen Brandstätter

1 Personen sind ohne Titel angegeben


3 Einleitung

3.1 Ausgangssituation

Die Elektronische Gesundheitsakte (ELGA) umfasst die relevanten multimedialen und gesundheitsbezogenen Daten und Informationen zu einer eindeutig identifizierten Person. Die Daten sind in einem oder mehreren computergestützten Informationssystemen gespeichert. Sie stehen allen berechtigten Personen entsprechend ihren Rollen und aller gesetzlichen Bedingungen in einer bedarfsgerecht aufbereiteten elektronischen Form online zur Verfügung.

Die zentrale Anwendung von ELGA ist die Bereitstellung von medizinischen Dokumenten 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, Zusammenfassungen generiert und weitere Informationen berechnet und kontextbezogen angezeigt werden. Um dieses Ziel zu ermöglichen, 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.

Der hier dargestellte Leitfaden für die Dokumentenklasse „Befund bildgebende Diagnostik“ ist ein konkreter Schritt einer harmonisierten, strukturierten und standardisierten Möglichkeit, medizinische Dokumente der bildgebenden Diagnostik zwischen Gesundheitsdiensten und Patienten auszutauschen.

Die Arbeitsgruppe ELGA CDA Radiologiebefund hat den bestehenden Implementierungs-leitfaden für Radiologiebefunde überarbeitet und ist dabei einheitlich zum Entschluss gekommen, die Dokumentenklasse als „Befund bildgebende Diagnostik“ zu präzisieren: Folgende Gründe haben zu diesem Schritt geführt:

  • Alle Befunde der bildgebenden Diagnostik sollen vom Leitfaden abgedeckt werden.
  • Der Leitfaden ermöglicht die Übertragung von Befunden für alle bildgebenden medizintechnischen Einrichtungen (z.B. Endoskopie, Nuklearmedizin usw.) und nicht nur für radiologische medizintechnische Einrichtungen.
  • Der international verwendete Titel entsprechender Leitfäden lautet “Diagnostic Imaging Report“.

3.2 Zweck

Im Rahmen der Kommunikation zwischen unterschiedlichen Medizinern ist der Befund als Ergebnis einer bildgebenden Untersuchung von sehr großer Bedeutung. Ein derartiger Befund der bildgebenden Diagnostik enthält die medizinisch relevanten Teile der Untersuchung(en) eines Patienten zu einem bestimmten Zeitpunkt und ist zur Übermittlung zwischen Gesundheitsdienstleistern gedacht.

Das Ziel dieses Dokuments ist eine detaillierte Beschreibung der standardisierten Struktur der Dokumentenklasse Befund “Bildgebende Diagnostik“ der Elektronischen Gesundheitsakte ELGA darzulegen.

Insbesondere behandelt das Dokument jene Strukturen, welche auf der Basis des Implementierungsleitfadens

HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [OID Root 1.2.40.0.34.7.1]

(in Folge „Allgemeiner Implementierungsleitfaden“) speziell für den

„Befund bildgebende Diagnostik“

gültig sind. Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA Elementen.

3.3 Hierarchie der Implementierungsleitfäden

Der vorliegende Implementierungsleitfaden basiert auf der grundlegenden Implementierungsvorschrift für alle CDA Dokumente im österreichischen Gesundheitswesen.

Der CDA Befund “Bildgebende Diagnostik“ hat grundsätzlich beiden aufeinander aufbauenden Implementierungsleitfäden zu folgen.

Abbildung 1: Zusammenspiel der Implementierungsleitfäden.

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

Für die Verwendung dieses Implementierungsleitfadens sind zusätzlich die Vorgaben aus
„HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente“ [OID Root 1.2.40.0.34.7.1]
in der Hauptversion 2 vorausgesetzt.

3.4 Fokus

Der Leserkreis dieses Dokuments sind Software-Entwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld der ELGA, insbesondere der ELGA Dokumentenklassen, betraut sind.

Die Spezifikation von Infrastrukturen, Workflow, Nachrichten, Prozeduren oder Protokollen zur Übermittlung des Befundes „Bildgebende Diagnostik“ ist nicht im Fokus dieses Dokuments.

3.5 Bezug zu DICOM Structured Report

Sollte für den Befund der bildgebenden Diagnostik ein CDA-Dokument aus einem vorhandenen DICOM Structured Report erzeugt (transformiert) werden, so wird auf den in Zusammenarbeit von HL7 und NEMA erstellten Implementierungsleitfaden „Implementation Guide for CDA Release 2: Imaging Integration. Levels 1, 2, and 3.“ [1] verwiesen, welcher dazu wesentliche zusätzliche Definitionen und Vorgaben beinhaltet.

Der Inhalt des vorliegenden Dokuments ist weitgehend aus den Definitionen von [1] abgeleitet und damit zu diesen kompatibel.

4 Anwendungsfälle

Dieses Kapitel beschreibt die Anwendungsfälle, welche für die Ermittlung der Anforderungen an die Struktur des im Implementierungsleitfaden beschriebenen Befundes „Bildgebende Diagnostik“, herangezogen wurden.

4.1 Anwendungsfall BEF01: „Einfache Untersuchung mit einer Modalität“

4.1.1 Allgemeines

Der Patient kommt zur Abklärung einer einfachen Fragestellung in die radiologische Praxis oder Abteilung. Nach Erfassung der demographischen Daten des Patienten wird entsprechend der Einweisung/Zuweisung und der durchgeführten Anamnese die Untersuchung durchgeführt.

4.1.2 Befund

Auf Basis von Einweisung/Zuweisung, Anamnese und entstandenem Bildmaterial wird ein Befund erstellt. Sollten relevante Voruntersuchungen vorliegen, werden diese bei der Erstellung des Befundes berücksichtigt.

4.1.3 Ergebnis

Der Patient und/oder der Zuweiser erhalten den geschriebenen Befund und das erstellte Bildmaterial. Im Fall der intramuralen Untersuchung verbleibt das Bildmaterial im Allgemeinen im Krankenhaus.

4.1.4 Akteure

  • Patient
  • Einweisender/Zuweisender/Überweisender Arzt
  • Empfang oder Leitstelle
  • Biomedizinische Analytiker/Radiologietechnologe
  • Radiologe
  • Schreibkraft

4.2 Anwendungsfall BEF02: „Komplexe Untersuchung mit mehreren Modalitäten“

4.2.1 Allgemeines

Der Patient kommt zur Abklärung einer „komplexen“ Fragestellung, die mehrere Modalitäten betrifft, in die radiologische Praxis oder Abteilung. Nach Erfassung der demographischen Daten des Patienten werden entsprechend der Einweisung/Zuweisung und der durch-geführten Anamnese die Untersuchungen unter Berücksichtigung etwaiger Einschränkungen bezüglich der Reihenfolge der anzuwendenden Modalitäten durchgeführt.

4.2.2 Befund

Auf Basis von Einweisung/Zuweisung, Anamnese und entstandenem Bildmaterial werden, sofern es sich um mehrere Fragestellungen handelt, mehrere Befunde erstellt. Handelt es sich um nur eine Fragestellung (z.B. Mammographie und zugehöriger Ultraschall), so wird der Befund trotz mehreren Modalitäten analog zu Anwendungsfall BEF01 erstellt. Sollten relevante Voruntersuchungen vorliegen, werden diese bei der Erstellung der Befunde berücksichtigt.

4.2.3 Ergebnis

Der Patient und/oder der Zuweiser erhalten den geschriebenen Befund und das erstellte Bildmaterial. Im Fall der intramuralen Untersuchung verbleibt das Bildmaterial im Allgemeinen im Krankenhaus.

4.2.4 Akteure

  • Patient
  • Einweisender/Zuweisender/Überweisender Arzt
  • Empfang oder Leitstelle
  • Biomedizinische Analytiker/Radiologietechnologe
  • Radiologe
  • Schreibkraft

5 Administrative Daten (CDA Header)

Dieses Kapitel basiert auf dem entsprechenden Kapitel im „Allgemeinen Implementierungsleitfaden“ und beschreibt die darüberhinausgehenden Spezifikationen zum Thema Befund „Bildgebende Diagnostik“.

5.1 Dokumentenstruktur

5.1.1 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

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

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
NameCDeffectiveTimeBezeichnungCD 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
NameCDconfidentialityCodeBezeichnungCD 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 (BasicConfidentialityKind)
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
NameCDlanguageCodeBezeichnungCD 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 Versionierung des Dokuments („setId“ und „versionNumber“)

5.1.10.1 Spezifikation

Es MÜSSEN immer beide Elemente (setID und versionNumber) angegeben werden.

Id1.2.40.0.34.11.90007
ref
elgabbr-
Gültigkeit2015‑09‑18
Andere Versionen mit dieser Id:
  • Kblank.png CDsetIdversionNumber vom 2015‑05‑29
  • Kblank.png CDsetIdversionNumber vom 2013‑11‑07
StatusKgreen.png AktivVersions-Label
NameCDsetIdversionNumberBezeichnungSetId VersionNumber
Beschreibung

Der CDA-Header repräsentiert ebenfalls die Beziehungen zu anderen Dokumenten mit Referenz auf die oben genannte Dokumenten-Identifikation.

Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden. Für ELGA-CDA-Dokumente MÜSSEN immer beide Elemente angegeben werden.

Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten). Die versionNumber ist eine natürliche Zahl für die fortlaufende Versionszählung. Mit einer neuen Version wird diese Zahl hochgezählt, die setId bleibt gleich.

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.90007 SetId VersionNumber (2015‑09‑18)
ref
elgabbr-
Beispiel
Beispiel für die 1.Version eines Dokuments
<!-- Die bei setId angegebene ID SOLLTE nicht gleich sein wie die id des Dokuments.-->
<art:placeholder>
  <id root="1.2.40.0.34.99.111.1.1" extension="AAAAAAAAAAAAAAA"/>  <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ"/>  <versionNumber value="1"/></art:placeholder>
Beispiel
Beispiel für die 2.Version eines Dokuments
<!--Die bei setId angegebene ID MUSS mit der setId der Vorversion übereinstimmen.-->
<art:placeholder>
  <id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBB"/>  <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ"/>  <versionNumber value="2"/></art:placeholder>
ItemDTKardKonfBeschreibungLabel
hl7:setId
II1 … 1M

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

Hinweis: Bestimmte Systeme, die bei der Übernahme der SetID in die XDS-Metadaten mit dem V2-Datentyp CX arbeiten, könnten ein Problem mit @Extension-Attributen haben, die länger als 15 Zeichen sind. Die SetID sollte unterschiedlich zur clinicalDocument.id sein.

(CDs...ber)
 Beispiel<setId extension="D1127" root="1.2.276.0.76.3.1.139.2.427"/>
hl7:versionNumber
INT.​NONNEG1 … 1M
Versionsnummer des Dokuments.
(CDs...ber)
 Beispiel<versionNumber value="1"/>

Für die setId sind grundsätzlich die Vorgaben gemäß Kapitel „id-Element II“ zu befolgen. Die versionNumber von neuen Dokumenten wird mit 1 festgelegt.

Anhänge oder Ersetzungen von Vordokumenten MÜSSEN ebenfalls diese zusätzlichen Angaben enthalten.

Der genaue Zusammenhang zwischen diesen Attributen finden Sie im „Bezug zu vorgehenden Dokumenten“.

Achtung: Manche Validatoren erkennen es als Fehler, wenn die SetID und ID gleich sind.

5.1.11 Elemente mit speziellen Vorgaben

5.1.11.1 ELGA Implementierungsleitfaden-Kennzeichnung („templateId“)

Mit Angabe dieses Elements wird ausgesagt, dass das vorliegende CDA-Dokument zu diesem Implementierungsleitfaden konform ist. Ein Dokument, welches dem vorliegenden Implementierungsleitfaden folgt, muss auch dem übergeordneten Allgemeinen Implementierungsleitfaden folgen.

5.1.11.1.1 Spezielle Vorgaben für den Befund „Bildgebende Diagnostik“

Die templateId-Elemente für diesen Implementierungsleitfaden sind anzugeben. Als Ergebnis der Arbeitsgruppe wird für den Befund bildgebende Diagnostik neben der ELGA Interoperabilitätsstufe (EIS) „Basic“/“Structured“ nur EIS „Full Support“ definiert.

5.1.11.1.2 Strukturbeispiel
<ClinicalDocument xmlns="urn:hl7-org:v3"> 
  :
   <!-- ELGA CDA Dokumente -->
   <templateId root="1.2.40.0.34.11.1"/> 
  
   <!-- ELGA CDA Befund „Bildgebende Diagnostik“ -->
   <templateId root="1.2.40.0.34.11.5"/>

   <!-- In Abhängigkeit von der ELGA Interoperabilitätsstufe (EIS) --> 
   <!-- EIS „Basic“ bzw. „Structured“ -->
   <templateId root="1.2.40.0.34.11.5.0.1"/>
     ... oder ...
   <!-- EIS „Full support“ -->
   <templateId root="1.2.40.0.34.11.5.0.3"/>
  :
</ClinicalDocument>
5.1.11.1.3 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 „Bildgebende Diagnostik“
Fester Wert: @root = 1.2.40.0.34.11.5
--- 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 Befund bildgebende Diagnostik in EIS „Basic“
Fester Wert @root = 1.2.40.0.34.11.5.0.1
--- oder ---
Im Falle von EIS „Full support“:

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

templateId II 1..1 M ELGA CDA Befund bildgebende Diagnostik in EIS „Full support“
Fester Wert @root = 1.2.40.0.34.11.5.0.3

5.1.11.2 Dokumentenklasse (“code”)

Gemäß dem Inhalt eines Dokuments erfolgt eine entsprechende Klassifizierung, welche im „code“ Element dargestellt wird. Die Klasseneinteilung, die beim Befund „Bildgebende Diagnostik“ zur Anwendung kommt, ist in der nachfolgenden Tabelle dargestellt. Dort ist zu sehen, dass sich unter der allgemeinen Klasse „Diagnostic imaging study“ mehrere, in der Regel modalitätenspezifische, Detailausprägungen gruppieren.

Die Klassifizierung eines Befunds „Bildgebende Diagnostik“ erfolgt mit dem für die durchgeführte Untersuchung zutreffendsten Code aus der untenstehenden Tabelle. Sollte kein spezifischer Code wählbar sein, so ist der übergeordnete Code für das Dokument zu wählen.

Bei der Registrierung des Dokuments in einer Registry wird in den XDS-Daten zum gewählten Code, der als „TypeCode“ abgebildet wird, immer auch der „übergeordnete Code“ als „ClassCode“ eingetragen.

Die Codierung der Dokumentenklasse erfolgt gemäß dem hierarchisch organisierten Value Set „ELGA_Dokumentenklassen(1.2.40.0.34.10.39) (LOINC Auszug), wobei für Dokumente entsprechend diesem Leitfaden nur der Eintrag „18748-4 Diagnostic imaging study“ und dessen Unterknoten verwendet werden dürfen.

In der nachfolgenden Tabelle sind zulässige Werte dargestellt. Die aktuell gültigen Codes sind immer dem entsprechenden Value Set zu entnehmen. Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert: https://termpub.gesundheit.gv.at/.

LOINC Code Display Name Beschreibung
18748-4 Diagnostic imaging study Befund bildgebende Diagnostik
25045-6 Unspecified body region CT Computertomographie-Befund
25056-3 Unspecified body region MRI Magnetresonanztomographie-Befund
25061-3 Unspecified body region US Ultraschall-Befund
49118-3 Unspecified body region Scan Nuklearmedizinischer Befund
44136-0 Unspecified body region PET Positronen-Emissions-Tomographie-Befund
18745-0 Cardiac catheterization study Herzkatheter-Befund
42148-7 Heart US Echokardiographie-Befund
18782-3 Radiology Study observation (narrative) Radiologie-Befund
18746-8 Colonoscopy study Kolonoskopie-Befund
18751-8 Endoscopy study Endoskopie-Befund
11525-3 Obstetrical ultrasound study Geburtshilfliche Ultraschalluntersuchung

Tabelle 1: Codes für die Dokumentenklasse, aktuell gültige Codes siehe Value Set „ELGA_Dokumentenklassen“

5.1.11.2.1 Spezielle Vorgaben für den Befund „Bildgebende Diagnostik“

Alle Befunde „Bildgebende Diagnostik“ werden abhängig von Inhalt oder verwendeter Untersuchungsmethode aus der obigen Tabelle codiert. Sollte eine Spezialisierung nicht möglich bzw. gewünscht sein, so ist folgender LOINC Code anzugeben:

18748-4, Diagnostic imaging study

5.1.11.2.2 Strukturbeispiel
<ClinicalDocument xmlns="urn:hl7-org:v3">
	:
  <code  code="18748-4"
         displayName="Diagnostic imaging study"
         codeSystem="2.16.840.1.113883.6.1"
         codeSystemName="LOINC" />
	:
</ClinicalDocument>
5.1.11.2.3 Spezifikation
Element/Attribut DT Kard Konf Beschreibung
code CE
CWE
1..1 M Code des Dokuments
@code cs 1..1 M Zugelassene Werte in Value Set „ELGA_Dokumentenklassen“:
„18748-4 Diagnostic imaging study“ und Unterknoten
@displayName st 1..1 M Displayname (englisch) zu @code
@codeSystem uid 1..1 M Fester Wert: 2.16.840.1.113883.6.1
@codeSystemName ADXP 1..1 M Fester Wert: LOINC

5.1.11.3 Titel des Dokuments („title“)

Dieses Element enthält den für den lesenden Dokumentempfänger gedachten Titel.

5.1.11.3.1 Spezielle Vorgaben für den Befund bildgebende Diagnostik

Der Titel des Dokuments kann frei vergeben werden, wobei der Titel nicht in Widerspruch zum Dokumenteninhalt stehen darf. Vorzugsweise wird ein „sprechender“ Titel verwendet (z.B. „MRT Knie links“). Der Titelvorschlag „Befund bildgebende Diagnostik“ kann für alle Dokumente verwendet werden.

Wenn z.B. bei der Übernahme der Information aus einem DICOM SR (Structured Report) kein Titel zur Verfügung steht, so ist die deutsche Bezeichnung des gewählten LOINC zur Befüllung heranzuziehen.

5.2 Teilnehmende Parteien

5.2.1 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

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

Verweis auf den 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.2 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.2.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​TargetBezeichnungHeader​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

Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.

(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.2.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.2.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.2.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.2.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.3 Verfasser des Dokuments („author“)

Auszug aus dem R-MIM:

Abbildung 8: Klassen rund um den Autor.

5.2.3.1 Spezifikation

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

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

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

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

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

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

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

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

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

Zugelassene nullFlavor:

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

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

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

Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.
Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

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

Name der Person

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

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

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

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

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

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

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


5.2.3.2 Spezifikation: Datenerstellende Geräte als „author“

Datenerstellende Geräte/Software (z.B.: das Service der e-Medikation, das die aktuelle Medikationsliste generiert). Siehe auch Rechtlicher Unterzeichner („legalAuthenticator“).

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
NameHeaderDataEntererBezeichnungHeaderDataEnterer
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
NameHeaderCustodianBezeichnungHeaderCustodian
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​RecipientBezeichnungHeader​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)



2 Der beabsichtigte Empfänger kann auch der Patient selbst sein.

5.2.7 Elemente mit speziellen Vorgaben

Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadensmit folgenden Änderungen:

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

Kard Konf Art des Beteiligten
1..1
0..0
[M]
[NP]
Rechtlicher Unterzeichner (legalAuthenticator) – MUSS im Regelfall angegeben werden
Ausnahme: Für multidisziplinäre Befunde3 ist die Angabe verboten, aber es müssen mindestens zwei weitere Unterzeichner angegeben werden
0..*
2..*
[O]
[M]
Weitere Unterzeichner (authenticator) – kann angegeben werden
Ausnahme: Bei multidisziplinären Befunden MÜSSEN mindestens zwei weitere Unterzeichner angegeben werden
1..1 [M] Fachlicher Ansprechpartner
0..1 [R2] Einweisender/Zuweisender/Überweisender Arzt
0..1 [O] Hausarzt
0..* [O] Notfall-Kontakt/Auskunftsberechtigte Person
0..* [O] Angehörige
0..1 [O] Versicherter/Versicherung
0..1 [O] Betreuende Organisation


3 Multidisziplinäre Befunde liegen vor, wenn mehrere Fachärzte mit unterschiedlicher Fachrichtung die Befunde gleichermaßen verantworten.

5.2.7.1 Rechtlicher Unterzeichner (legalAuthenticator)

Als rechtlicher Unterzeichner MUSS eine natürliche Person angegeben werden.

Für „multidisziplinäre Befunde“ KANN die Angabe des legalAuthenticator entfallen, wenn mindestens zwei authenticator-Elemente vorhanden sind. Multidisziplinäre Befunde liegen vor, wenn von mehreren Fachärzten mit unterschiedlicher Fachrichtung gleichermaßen an der Erstellung beteiligt sind und keiner dieser als Hauptunterzeichner eingetragen werden kann.

5.2.7.2 Weitere Beteiligte („participants“)

Im Befund „Bildgebende Diagnostik“ MUSS der „Fachliche Ansprechpartner“ (participant @typeCode='CALLBCK') mit vollständiger Kontaktadresse inklusive Telefonnummer angegeben werden.

Zweck dieser Information ist es, etwaige Anfragen der Dokumentempfänger an den Dokumentersteller zu kanalisieren. Es obliegt der Organisation des Dokumenterstellers, diese Information gemäß ihren eigenen Richtlinien zu befüllen.

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

Im klinischen Alltag werden medizinische Dokumente häufig an den Patienten gerichtet –dieser kann dann auch als InformationRecipient zusätzlich eingetragen werden. Ein Strukturbeispiel findet sich im Allgemeinen Implementierungsleitfaden.

5.3 Dokumentation der Gesundheitsdienstleistung

5.3.1 Service Events („documentationOf/serviceEvent“)

Da die angegebenen Gesundheitsdienstleistungen in die XDS-Metadaten übernommen werden, stellen sie die einzigen (rein) medizinischen Informationen zum Dokument im Dokumentenregister dar. Sie können daher in Folge für Suche und Filterung verwendet werden, und erleichtern mitunter die Navigation in der Krankengeschichte des Patienten.

Verweis auf den 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.4 Dokumentation der Gesundheitsdienstleistung

5.4.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.4.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
NameHeaderServiceEventBezeichnungHeaderServiceEvent
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
elgabbr-

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.4.1.2 Spezielle Vorgaben

Die Sinnhaftigkeit und der Nutzen von angegebenen Gesundheitsdienstleistungen hängen entscheidend von der eingesetzten Codeliste ab. Im Rahmen einer Arbeitsgruppe wurde von der BURA der APPC (Austrian PACS Procedure Code) entwickelt. Dieser ist ausschließlich für das Beschlagworten und dadurch rasche Auffinden von Befunden gedacht. Sofern zur Erstellung eines Befundes mehrere Modalitäten zum Einsatz kommen, sind auch entsprechend mehrere Codes anzugeben.

Für eine benutzerfreundliche Anwendung des APPC wird empfohlen, den APPC möglichst automatisiert aus bestehenden internen Codierungen zu verknüpfen/mappen.

Als Zeitangabe MUSS der Zeitraum der Untersuchung(en) (erste bis letzte Untersuchung) angegeben werden4. Die durchführende Organisationseinheit legt fest, welche Zeitpunkte der ersten bzw. letzten Untersuchung herangezogen werden. Wenn es sich um nur eine Untersuchung handelt, so sind Start- und Endzeitpunkt anzugeben.

Sind Datum und Uhrzeit bekannt, so ist beides anzugeben, anderenfalls reicht auch die Angabe des Datums (Formate gem. Allgemeinem Implementierungsleitfaden).

ACHTUNG: Diese Zeitangaben werden in die Dokument-Metadaten übernommen!

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

  • serviceStartTime: Beginn der ersten Untersuchung
  • serviceStopTime: Ende der letzten Untersuchung


4 Im ELGA-Portal werden in der Dokumentenliste die Zeitangaben der ersten durchgeführten Untersuchung entsprechend angezeigt

5.4.1.3 Strukturbeispiel

<documentationOf>
  <serviceEvent>
    <code code="1.4.0.4-2-3-1"
          displayName="Röntgen.unpaariges Organ.Prozedur nicht näher bestimmt.Appendix"
          codeSystem="1.2.40.0.34.5.38"
          codeSystemName="APPC" />
    <effectiveTime>
      <low value="20161124154500+0100"/>
      <high value="20161124154900+0100"/>
    </effectiveTime>
  </serviceEvent>
</documentationOf>

5.4.1.4 Spezifikation

Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadensmit folgenden Änderungen:

5.4.1.4.1 Änderung 1: documentationOf Element Allgemein

Konformität geändert auf [M].

Element/Attribut DT Kard Konf Beschreibung
documentationOf POCD_MT000040.DocumentationOf 1..* M Komponente für die Gesundheitsdienstleistung
serviceEvent POCD_MT000040.ServiceEvent 1..1 M Gesundheitsdienstleistung
5.4.1.4.2 Änderung 2: code

Im Code wird der der durchgeführten Untersuchung entsprechende APPC angegeben.

Als DisplayName ist eine freie, textliche Repräsentation der durchgeführten Untersuchung anzugeben (z.B. „Röntgen Appendix“). Diese textliche Repräsentation darf keinesfalls im Widerspruch zum gewählten APPC stehen. Bei automatischer Generierung des DisplayNames kann eine Konkatenation der Bezeichnungen der vier Achsen vorgenommen werden, z.B. für den APPC "3.4.0.5-3-3": "MRT.Unpaarig.Prozedur nicht näher bestimmt.Lendenwirbelsäule“.

Element/Attribut DT Kard Konf Beschreibung
code CE
CWE
1..1 M Code der Gesundheitsdienstleistung
@code cs 1..1 M Ein der Untersuchung entsprechender Code aus dem APPC (z.B.: 1.4.0.4-2-3-1)
@displayName st 1..1 M Freie textliche Repräsentation des APPC, darf nicht im Widerspruch zum Code liegen
@codeSystem uid 1..1 M Fester Wert: 1.2.40.0.34.5.38
@codeSystemName st 1..1 M Fester Wert: APPC
5.4.1.4.3 Änderung 3: effectiveTime

Als Zeitangabe MUSS der Zeitraum des Pflege- oder Betreuungsverhältnisses angegeben werden.

Der Zeitraum des Aufenthalts erstreckt sich vom

Zeitpunkt der ersten Untersuchung

bis zum

Zeitpunkt der letzten Untersuchung.

Hinweis: Der Zeitpunkt der Untersuchung ist durch die durchführende Organisation festzulegen, sinnvollerweise ist dies jeweils der Beginn der Untersuchungen. Auch wenn nur eine Untersuchung dokumentiert wird, MUSS an dieser Stelle ein Zeitintervall angegeben werden. Das kann z.B. durch Angabe von Beginn und Ende der Untersuchung geschehen.

5.4.1.4.4 Änderung 4: performer

Aus Gründen der Kompatibilität zur automatischen Überführung eines Befundes von DICOM SR in CDA kann eine durchführende Entität der Gesundheitsdienstleistung angegeben werden.

Element/Attribut DT Kard Konf Beschreibung
performer POCD_MT000040.Performer1 0..* R2 Durchführende Entität der Gesundheitsdienstleistung
@typeCode cs 1..1 M Zulässige Werte gemäß Value-Set „ELGA_ServiceEventPerformer“
time IVL_TS 0..0 NP Zeit, in der der performer mit der Gesundheitsdienstleistung beschäftigt war (wenn abweichend von EffectiveTime im Act)
assignedEntity POCD_MT000040.AssignedEntity 1..1 M Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens

5.5 Bezug zu vorgehenden Dokumenten

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

Achtung: bei der Erstellung von CDA Dokumenten aus DICOM SR liegt eine „Transformation“ vor, bei der im CDA Dokument der originale DICOM SR als „ParentDocument“ anzugeben ist. Dieser Anwendungsfall steht jedoch nicht im Fokus dieses Leitfadens und es sei hier ausdrücklich auf die Hinweise im Kapitel Bezug zu DICOM Structured Report verwiesen.


Auszug aus dem Allgemeinen Implementierungsleitfaden

5.6 Bezug zu vorgehenden Dokumenten

5.6.1 Allgemeines

Dieses Kapitel beschreibt die Versionsverwaltung von CDA-Dokumenten.

Der Bezug zu Vorgängerversionen von Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse (siehe Versionierung des Dokuments), spezifiziert.

Abbildung 16: Grundsätzlicher Aufbau eines CDA-Dokuments aus XML Sicht.

Der Bezug zum Vordokument wird dabei über die parentDocument Beziehung ausgedrückt, in dem der dazugehörige @typeCode einen Wert aus der Liste der gültigen @typeCodes in der relatedDocument-Beziehung erhält. Das Originaldokument, auf das sich das Dokument bezieht, bleibt dabei unverändert.

Liste der möglichen Werte der @typeCodes in der relatedDocument Beziehung:

code displayName Bedeutung
APND append Verwendung NICHT ERLAUBT
Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.
RPLC replaces Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "überholt" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.
XFRM transformed Verwendung NICHT ERLAUBT

Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen.

Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden.
Es ist nicht auszuschließen, dass die Transformation in lokalen Affiniy Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

Tabelle 4: Vokabel-Domäne relatedDocument.typeCode

5.6.1.1 Spezifikation

Id1.2.40.0.34.11.20011
ref
elgabbr-
Gültigkeit2014‑12‑06
Andere Versionen mit dieser Id:
  • Kblank.png HeaderRelatedDocument vom 2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeaderRelatedDocumentBezeichnungHeaderRelatedDocument
BeschreibungDer Bezug zu vorgehenden Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse, spezifiziert.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
elgagab-data​element-155Kyellow.png Bezug zu vorgehenden Dokumenten Kyellow.png Datensatz
BeziehungVersion: Template 1.2.40.0.34.11.20011 HeaderRelatedDocument (2014‑12‑06)
ref
elgabbr-
Beispiel
Strukturbeispiel
<relatedDocument typeCode="RPLC">
  <parentDocument>
    <id root="1.2.40.0.34.99.111.1.1" extension="134F989EAAE3F43B6AD"/>  </parentDocument>
</relatedDocument>
ItemDTKardKonfBeschreibungLabel
hl7:relatedDocument
Komponente für das vorgehende Dokument.(Hea...ent)
 
Target.png
elgagab-data​element-155Kyellow.png Bezug zu vorgehenden Dokumenten Kyellow.png Datensatz
Treetree.png@typeCode
cs1 … 1FRPLC
 Art des Bezugs zum Vordokument.
Treetree.pnghl7:parentDocument
1 … 1MVorhergehendes Dokument.(Hea...ent)
Treeblank.pngTreetree.png@classCode
cs0 … 1FDOCCLIN
Treeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreetree.pnghl7:id
II1 … 1MDokumenten-Id des vorgehenden Dokuments.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.
(Hea...ent)


5.7 Einverständniserklärung

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.8 Einverständniserklärung

5.8.1 Autorisierung („authorization“)

In dieser optionalen Klasse können die Einverständniserklärungen reflektiert werden, die mit dem Dokument verbunden sind. Dies kann ein Einverständnis für einen Eingriff oder die Verfügbarmachung der Informationen gegenüber Dritten beinhalten. Der Typ der Einverständniserklärung wird dabei in Consent.code angegeben.

Auszug aus dem R-MIM:

Abbildung 17: Consent Klasse.

5.8.1.1 Spezifikation

Id1.2.40.0.34.11.20012
ref
elgabbr-
Gültigkeit2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameHeaderAuthorizationBezeichnungHeaderAuthorization
Beschreibung

Der Einverständniserklärung ist derzeit ungenutzt. Dieses Element wird daher derzeit nicht angegeben.

In dieser optionalen Klasse können die Einverständniserklärungen reflektiert werden, die mit dem Dokument verbunden sind. Dies kann ein Einverständnis für einen Eingriff oder die Verfügbarmachung der Informationen gegenüber Dritten beinhalten. Der Typ der Einverständniserklärung wird dabei in Consent.code angegeben.

KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.20012 HeaderAuthorization (2011‑12‑19)
ref
elgabbr-
ItemDTKardKonfBeschreibungLabel
hl7:authorization
NPKomponente für die Einverständniserklärung.
Wird in ELGA nicht verwendet!
(Hea...ion)


5.9 Informationen zum Patientenkontakt

Verweis auf den 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.10 Informationen zum Patientenkontakt

5.10.1 Encounter („componentOf/encompassingEncounter“)

Diese Klasse repräsentiert Informationen, in welchem Rahmen der Patientenkontakt, der dokumentiert wird, stattgefunden hat. Dokumente werden nicht notwendigerweise immer während eines Patientenkontakts erstellt, sondern ggf. auch zu einem späteren Zeitpunkt, wenn beispielsweise ein Arzt wegen eines pathologischen Laborwertes den Patienten vergeblich versucht zu erreichen und dennoch seine Verlaufsdokumentation fortführt.

Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, muss die Information in dieser Klasse mitgegeben werden, inklusive der Dauer des Aufenthalts (hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) und der Einrichtung, wo der Patientenaufenthalt stattfand.

Auszug aus dem R-MIM:

Abbildung 18: EncompassingEncounter Klasse und Umgebung.

5.10.1.1 Spezifikation

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

Name der Person

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

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

Verweis auf speziellen Implementierungsleitfaden:
Ob der Patientenkontakt angegeben werden muss, und welche Bedeutung dieses Element hat ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

5.10.1.1.2 id

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

Verweis auf speziellen Implementierungsleitfaden:
Ob, und welche Identifikation eingetragen werden soll ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

5.10.1.1.3 code

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

Verweis auf speziellen Implementierungsleitfaden:
Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

5.10.1.1.4 effectiveTime

Verweis auf speziellen Implementierungsleitfaden:
Welche Start- und Endezeiten eingetragen werden sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

5.10.1.1.5 responsibleParty

Die verantwortliche Person für den Patientenkontakt (Aufenthalt) KANN optional angegeben werden.

Verweis auf speziellen Implementierungsleitfaden:
Die konkrete Bedeutung der verantwortlichen Person für den Patientenkontakt (Aufenthalt) und eine ggf. verpflichtende Angabe dieses Elements ergeben sich aus dem jeweiligen speziellen Implementierungsleitfaden.

5.10.1.1.6 location

Die Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand, MUSS verpflichtend angegeben werden (z.B.: die entlassende Krankenanstalt mit Abteilung).

Verweis auf speziellen Implementierungsleitfaden:
Die konkrete Bedeutung der Organisation, in deren Verantwortungsbereich der Patientenkontakt (Aufenthalt) stattfand, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.


6 Medizinische Inhalte (CDA Body)

Dieses Kapitel beschreibt die Sektionen des CDA Body, welche im „Befund Bildgebende Diagnostik“ vorkommen sollen bzw. müssen.

6.1 Überblick

6.1.1 Sektionen und Reihenfolge der CDA Body - Dokumentstruktur

Dieses Kapitel zeigt einen Überblick über die Sektionen der CDA Body - Dokumentstruktur.

Die Reihenfolge der Sektionen in einem CDA Body kann zwar prinzipiell frei gewählt werden, allerdings stellen die meisten Visualisierungsroutinen die Sektionen in genau der Reihenfolge dar, in der sie im CDA Body angeordnet sind. Daher ist die Reihenfolge der Sektionen zwar nicht „technisch“ aber „semantisch“ relevant.

Da die empfangenden GDAs die medizinischen Informationen in einer bestimmten Reihenfolge erwarten, ist diese erwartete Reihenfolge bereits in der CDA Struktur zu berücksichtigen.

Dieser Implementierungsleitfaden schreibt daher auch die Reihenfolge vor, in der die Sektionen im CDA angegeben werden MÜSSEN.

In diesem Kapitel sind die möglichen Sektionen in der vorgeschriebenen Reihenfolge dargestellt.

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

Enthält das Dokument entweder unstrukturierten oder eingebetteten Inhalt (z.B. PDF) oder strukturierten Inhalt5, 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 EIS „Structured“ erreicht wird.

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


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

6.1.3 Tabellarische Darstellung der Sektionen

Die nachfolgende Tabelle gibt einen Überblick über die möglichen Sektionen. Die Codierung der Sektionen erfolgt gemäß dem Value Set „ELGA_Sections“ (1.2.40.0.34.5.40).

Opt Sektion / Titel Code Kap Pos
[O] Brieftext BRIEFT Link 1
[M] Anforderung 55115-0 Link 2
[M] Anamnese 11329-0 Link 3
[R2] Indikation 18785-6 Link 4
[O] Patientenstatus / Patientenangaben 55108-5 Link 5
[R2 Aktuelle Untersuchung 55111-9 Link 6
[O] Frühere Untersuchungen 55114-3 Link 7
[O] Frühere Befunde 18834-2 Link 8
[O] Komplikationen 55109-3 Link 9
[M] Befund 18782-3 Link 10
[R2] Zusammenfassung / Ergebnis 55112-7 Link 11
[O] Verdachtsdiagnose 19005-8 Link 12
[O] Schlussfolgerung 55110-1 Link 13
[O] Empfehlung 18783-1 Link 14
[O] Abschließende Bemerkungen ABBEM Link 15

Tabelle 2: Überblick und Reihenfolge der Sektionen

In der obigen Tabelle sind die technischen Sektionen, die von einem System (RIS oder auch KIS) befüllt werden, grau hinterlegt.

Die orange hinterlegten Sektionen enthalten nur Informationen aus der Überweisung.

6.1.4 Web Access to DICOM Persistent Object (WADO)

Die Textelemente („<text>“) der einzelnen Sektionen können Referenzen für den Web Access to DICOM Persistent Objects (WADO) enthalten. Diese werden als <linkHtml> dar-gestellt wobei das @href-Element eine gültige WADO-URL darstellt und der textuelle Inhalt des <linkHTML> Elements den sichtbaren Teil des Hyperlinks.

Bei Angabe eines WADO-Links ist darauf zu achten, dass die Ressource auch für den Endkonsumenten des Dokumentes zugänglich ist.

Die exakte Definition der Verfügbarmachung von Bilddaten im Rahmen von ELGA ist noch durch die ELGA GmbH zu definieren. Das angeführte Code-Beispiel dient nur zu Demonstrationszwecken.

6.1.4.1 Strukturbeispiel

<text> 
   ... 
   <paragraph> 
   <caption>Source of Measurement</caption> 
   <linkHtml href="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/dicom">Chest_PA</linkHtml> 
   </paragraph> 
   ... 
</text>  

6.2 Sektionen aus Überweisung

Dieser erste Teil der medizinischen Sektionen behandelt die medizinischen Informationen, die seitens des zuweisenden Arztes gewünscht werden.

6.2.1 Anforderung

Der Inhalt dieser Sektion bildet ab, was der zuweisende Arzt überprüft/ausgeschlossen wissen will. Idealerweise kommt dieser Inhalt aus einer elektronischen Überweisung. Sollte die elektronische Überweisung ein Codierungsschema erhalten, so wurde in der Arbeitsgruppe die Möglichkeit eines für den Zweck von Überweisungen erweiterten APPC diskutiert.

6.2.1.1 Überblick

Titel der Sektion Anforderung
Definition Gewünschte Untersuchung (Organ, Methode)
Codierung LOINC: 55115-0
Requested imaging studies information
Konformität [M]

Die Sektion MUSS immer im Befund „Bildgebende Diagnostik“ enthalten sein.

Sind keine Informationen vorhanden, so wird dies als Standard-Text in der Sektion vermerkt (z.B.: „Anforderung wird nicht bekannt gegeben“).

6.2.1.2 Spezifikation

Id1.2.40.0.34.11.5.2.1
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameAnforderungBezeichnungAnforderung
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.1
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.1 Anforderung (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.1"/>  <!-- Code der Sektion -->
  <code code="55115-0" displayName="Requested imaging studies information" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Anforderung</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Anf...ung)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Anf...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.1
Treetree.pnghl7:code
CE1 … 1M(Anf...ung)
Treeblank.pngTreetree.png@code
CONF1 … 1F55115-0
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FRequested imaging studies information
Treetree.pnghl7:title
ST1 … 1M(Anf...ung)
 CONF
Elementinhalt muss "Anforderung" sein
Treetree.pnghl7:text
ED1 … 1MSollten keine Information vorhanden sein, so kann ein Standardtext eingefügt werden (z.B.: „Anforderung wird nicht bekannt gegeben“).(Anf...ung)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Anf...ung)


6.2.2 Anamnese

In dieser Sektion wird die klinische Symptomatik bzw. die relevanten anamnestischen Angaben und Vorbefunde, wie sie in der Überweisung angegeben wurden, dargestellt.

6.2.2.1 Überblick

Titel der Sektion Anamnese
Definition Klinische Symptomatik, relevante anamnestische Angaben, Vorbefunde
Codierung LOINC: 11329-0
History general
Konformität [M]

Die Sektion MUSS immer im Befund „Bildgebende Diagnostik“ enthalten sein.

Eine Codierung in Level 3 ist nicht vorgesehen.

Sind keine Informationen vorhanden, so wird dies als Standard-Text in der Sektion vermerkt (z.B.: „Anamnese wird nicht bekannt gegeben“).

6.2.2.2 Spezifikation

Id1.2.40.0.34.11.5.2.2
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameAnamneseBildgebendeDiagnostikBezeichnungAnamnese (BildgebendeDiagnostik)
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.2 Anamnese (BildgebendeDiagnostik) (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.2"/>  <!-- Code der Sektion -->
  <code code="11329-0" displayName="History general" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Anamnese</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Ana...tik)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Ana...tik)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.2
Treetree.pnghl7:code
CE1 … 1M(Ana...tik)
Treeblank.pngTreetree.png@code
CONF1 … 1F11329-0
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FHistory general
Treetree.pnghl7:title
ST1 … 1M(Ana...tik)
 CONF
Elementinhalt muss "Anamnese" sein
Treetree.pnghl7:text
ED1 … 1MSollten keine Information vorhanden sein, so kann ein Standardtext eingefügt werden (z.B.: „Anamnese wird nicht bekannt gegeben“).(Ana...tik)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Ana...tik)


6.2.3 Indikation

In dieser Sektion wird die ausführliche Formulierung der Fragestellung des Einweisers/Zuweisers aus der Überweisung übernommen.

6.2.3.1 Überblick

Titel der Sektion Indikation
Definition Konkrete Fragestellung des Zuweisers oder Wunsch nach Bestätigung einer Verdachtsdiagnose
Codierung LOINC: 18785-6
Reason for study
Konformität [R2]

Da es sich bei dieser Sektion um eine rein verbale Darstellung der Anforderungen des Zuweisers handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.2.3.2 Spezifikation

Id1.2.40.0.34.11.5.2.3
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameIndikationBezeichnungIndikation
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.3
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.3 Indikation (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.3"/>  <!-- Code der Sektion -->
  <code code="18785-6" displayName="Reason for study" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Indikation</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Ind...ion)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Ind...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.3
Treetree.pnghl7:code
CE1 … 1M(Ind...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F18785-6
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FReason for study
Treetree.pnghl7:title
ST1 … 1M(Ind...ion)
 CONF
Elementinhalt muss "Indikation" sein
Treetree.pnghl7:text
ED1 … 1M(Ind...ion)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Ind...ion)

6.3 Sektionen der Untersuchung

In diesen Sektionen werden die Aktivitäten der untersuchenden Einheit bzw. herangezogene Vorstudien beschrieben.

6.3.1 Patientenstatus/Patientenangaben

Diese Sektion enthält anamnestische Angaben, wie sie in der durchführenden Organisationseinheit durch eigenes Personal erhoben werden. Diese Angaben können durchaus vom Text der Überweisung (wegen Irrtums, Schreibfehler, …) abweichen.

6.3.1.1 Überblick

Titel der Sektion Patientenstatus/Patientenangaben
Definition Anamnese, erhoben in der durchführenden Einheit (kann von der Anamnese in der Überweisung abweichen)
Codierung LOINC: 55108-5
Clinical presentation
Konformität [O]

Da es sich bei dieser Sektion um eine rein verbale Darstellung der Patientenangaben handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.3.1.2 Spezifikation

Id1.2.40.0.34.11.5.2.4
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NamePatientenStatusAngabenBezeichnungPatientenstatus / Patientenangaben
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.4
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.4 Patientenstatus / Patientenangaben (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.4"/>  <!-- Code der Sektion -->
  <code code="55108-5" displayName="Clinical presentation" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Patientenstatus / Patientenangaben</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Pat...ben)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Pat...ben)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.4
Treetree.pnghl7:code
CE1 … 1M(Pat...ben)
Treeblank.pngTreetree.png@code
CONF1 … 1F55108-5
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FClinical presentation
Treetree.pnghl7:title
ST1 … 1M(Pat...ben)
 CONF
Elementinhalt muss "Patientenstatus / Patientenangaben" sein
Treetree.pnghl7:text
ED1 … 1M(Pat...ben)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Pat...ben)


6.3.2 Aktuelle Untersuchung

Diese Sektion beschreibt in möglichst kurzer Form die zur Untersuchung angewandten Techniken und/oder Eingriffe.

6.3.2.1 Überblick

Titel der Sektion Aktuelle Untersuchung
Definition Kurzbeschreibung sämtlicher zur Erstellung des Befundes angewandten Techniken, Eingriffe oder sonstige Maßnahmen sowie Parameter zur Dokumentation der Patientendosis
Codierung LOINC: 55111-9
Current imaging procedure descriptions
Konformität [R2]
Konformität Level 3 [O]

Eine Kurzbeschreibung sämtlicher zur Erstellung des Befundes angewandten Techniken, Eingriffe oder sonstige Maßnahmen ist für alle Modalitäten optional.

Die Dokumentation der Patientendosis für Computertomographie-, Radiologie-, Nuklearmedizinische Befunde gemäß der Strahlenschutzrichtlinie 2013/59/EU Art. 58b SOLL in dieser Sektion erfolgen. Der Befund MUSS dann die Informationen zur Ermittlung der Patientendosis beinhalten und die Dosisparameter sind mindestens in Level 2 darzustellen.

Da es sich bei dieser Sektion um eine rein verbale Darstellung der „technischen“ Vorgänge der Untersuchung handelt, ist eine Codierung in Level 3 nicht vorgesehen. Eine Ausnahme bildet hier die Dokumentation der Patientendosis bei Röntgenaufnahmen, der Computertomographie, Durchleuchtung, Interventionellen Radiologie, Mammographie und Nuklearmedizin.

Bei Röntgenaufnahmen, Durchleuchtungen und interventionelle Untersuchungen erfolgt eine Dokumentation des Dosisflächenprodukts im Befund. Im Bereich der Mammografie SOLL die mittlere Parenchymdosis und die Eingangsdosis dokumentiert werden. Für die Computertomographie MUSS das Dosislängenprodukt und für die Nuklearmedizin die applizierte Aktivität im Befund aufgenommen werden. Sofern möglich, SOLL bei allen Modalitäten mit ionisierender Strahlung eine Dokumentation der berechneten effektiven Dosis des Patienten im Befund „Bildgebende Diagnostik“ erfolgen.

In der nachfolgenden Tabelle sind zulässige Werte zur Level 3 Codierung dargestellt. Die aktuell gültigen Codes sind immer dem am Terminologieserver publizierten Codesystem zu entnehmen. Einheit für das Dosisflächenprodukt (DAP): Da in der Praxis von unterschiedlichen Modalitäten unterschiedliche Einheiten verwendet werden, wird Gycm² als bevorzugte Einheit vorgeschlagen (wie auch im DICOM-Standard vorgesehen). Damit die Systeme nicht durch eine Einheitenumrechnung unter die Definition eines Medizinproduktes6 fallen, ist die Angabe des DAP in der originalen Einheit zulässig, sofern in UCUM ausgedrückt: 1 Gym² = 10.000 Gycm² = 1.000.000 cGycm² = 1.000.000 µGym².

DICOM Code Display Name Beschreibung Einheit
113507 Administered activity Applizierte Aktivität MBq
111636 Entrance Exposure at RP Eingangsdosis mGy (bevorzugte Einheit, andere UCUM Einheiten sind hier erlaubt )
111637 Accumulated Average Glandular Dose Mittlere Parenchymdosis (AGD) mGy (bevorzugte Einheit, andere UCUM Einheiten sind hier erlaubt )
113722 Dose Area Product Total Dosisflächenprodukt (DAP) Gym² (bevorzugte Einheit, andere UCUM Einheiten sind hier erlaubt)
113813 CT Dose Length Product Total Dosislängenprodukt (DLP) mGycm (bevorzugte Einheit, andere UCUM Einheiten sind hier erlaubt)
113839 Effective Dose Effektive Dosis mSv

Tabelle 3: Codes für Dosisparameter zur Ermittlung der Patientendosis aus DICOM Context ID CID 10050 „Summary Radiation Exposure Quantities“ (Value Set ELGA_Dosisparameter_VS).


6 Es ist möglich, die Einheitenumrechnung in ein separates Modul auszulagern, das nur die Umrechnung durchführt. Dieses kann dann viel einfacher als Medizinprodukt ausgewiesen werden.

6.3.2.2 Spezifikation

Id1.2.40.0.34.11.5.2.5
ref
elgabbr-
Gültigkeit2019‑07‑30 14:22:46
Andere Versionen mit dieser Id:
  • Kblank.png AktuelleUntersuchung vom 2015‑09‑24
  • Kblank.png AktuelleUntersuchung vom 2012‑01‑12
StatusKyellow.png EntwurfVersions-Label
NameAktuelleUntersuchungBezeichnungAktuelle Untersuchung
Beschreibung
Kurzbeschreibung sämtlicher zur Erstellung des Befundes angewandten Techniken, Eingriffe oder sonstige Maßnahmen sowie Parameter zur Dokumentation der Patientendosis oder auch Kontrastmittelgabe (Präparat und Menge).
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.5
KlassifikationCDA Section 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.5.3.3ContainmentKgreen.png Strahlenexposition EntryDYNAMIC
1.2.40.0.34.11.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.5 Aktuelle Untersuchung (2015‑09‑24)
ref
elgabbr-

Version: Template 1.2.40.0.34.11.5.2.5 Aktuelle Untersuchung (2015‑09‑24)
ref
elgabbr-
Beispiel
Strukturbeispiel (ohne Level 3)
<section>
  <templateId root="1.2.40.0.34.11.5.2.5"/>  <!-- Code der Sektion -->
  <code code="55111-9" displayName="Current imaging procedure descriptions" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Aktuelle Untersuchung</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
Beispiel
Strukturbeispiel Aufnahme der Patientendosis
<section>
  <templateId root="1.2.40.0.34.11.5.2.5"/>  <!-- Code der Sektion -->
  <code code="55111-9" displayName="Current imaging procedure descriptions" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Aktuelle Untersuchung</title>  <!-- Textbereich der Sektion -->
  <text>
     ... Lesbarer Textbereich ...     <paragraph> Informationen zur Patientendosis </paragraph>    <table>
      <thead>
        <tr>
          <th>Parameter</th>          <th>Ergebnis</th>          <th>Einheit</th>        </tr>
      </thead>
      <tbody>
        <tr ID="OBS-1">
          <td>Dosislängenprodukt</td>          <td>230</td>          <td>mGycm</td>        </tr>
        <tr ID="OBS-2">
          <td>Effektive Dosis</td>          <td>2.5</td>          <td>mS</td>        </tr>
      </tbody>
    </table>
  </text>
  <!-- Maschinenlesbare Elemente der Sektion -->
  <!-- entry fuer Codierung der Angaben zur Patientendosis -->
  <entry typeCode="DRIV">
    <!-- Dosislängenprodukt -->
    <observation classCode="OBS" moodCode="EVN">
      <templateId root="2.16.840.1.113883.10.20.6.2.14"/>      <templateId root="1.2.40.0.34.11.5.3.3"/>      <code code="113813" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="CT Dose Length Product Total"/>      <text>
        <reference value="#OBS-1"/>      </text>
      <statusCode code="completed"/>      <effectiveTime value="20130823073406+0200"/>      <value xsi:type="PQ" value="230" unit="mGy.cm"/>    </observation>
  </entry>
  <entry typeCode="DRIV">
    <!-- Effektive Dosis -->
    <observation classCode="OBS" moodCode="EVN">
      <templateId root="2.16.840.1.113883.10.20.6.2.14"/>      <templateId root="1.2.40.0.34.11.5.3.3"/>      <code code="113839" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Effective Dose"/>      <text>
        <reference value="#OBS-2"/>      </text>
      <statusCode code="completed"/>      <effectiveTime value="20130823073406+0200"/>      <value xsi:type="PQ" value="2.5" unit="mSv"/>    </observation>
  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Akt...ung)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Akt...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.5
Treetree.pnghl7:code
CE1 … 1M(Akt...ung)
Treeblank.pngTreetree.png@code
CONF1 … 1F55111-9
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FCurrent imaging procedure descriptions
Treetree.pnghl7:title
ST1 … 1M(Akt...ung)
 CONF
Elementinhalt muss "Aktuelle Untersuchung" sein
Treetree.pnghl7:text
ED1 … 1MDer Befundtext sollte in Abschnitte (<paragraph>) gegliedert sein. Vorgegebene Struktur für die Angaben zur Patientendosis über das medizinisch-radiologische Verfahren: Die effektive Dosis oder Parameter zur Patientendosis MÜSSEN im Textteil als Tabelle enthalten sein.</paragraph> (Akt...ung)
Treetree.pnghl7:entry
0 … *Im Falle eines Befundes für Röntgenaufnahmen, Computertomographie, Durchleuchtung, Interventionelle Radiologie, Mammographie oder Nuklearmedizin: Unabhängig von der Modalität zur Codierung des Dosisparameters nach DCM in Level 3.
Beinhaltet 1.2.40.0.34.11.5.3.3 Strahlenexposition Entry (DYNAMIC)
(Akt...ung)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Akt...ung)


6.3.2.3 Strahlenexposition-Entry

Spezifikation der Entry Elemente für die medizinische Strahlenexposition.

Id1.2.40.0.34.11.5.3.3
ref
elgabbr-
Gültigkeit2015‑09‑24
StatusKgreen.png AktivVersions-Label
NameStrahlenexpositionentryBezeichnungStrahlenexposition Entry
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.3.3
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.5.3.3 Strahlenexposition Entry (2015‑09‑24)
ref
elgabbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
Quantity Measurement Observation.(Str...try)
Treetree.png@classCode
cs1 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1R(Str...try)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.20.6.2.14
Treetree.pnghl7:templateId
II1 … 1R(Str...try)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.3.3
Treetree.pnghl7:code
CE1 … 1M(Str...try)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.166 ELGA_Dosisparameter (DYNAMIC)
Treetree.pnghl7:text
ED1 … 1M(Str...try)
Treeblank.pngTreetree.pnghl7:reference
1 … 1M@value: Referenz auf Id des Ergebnisses im section.text.(Str...try)
Treetree.pnghl7:statusCode
CS1 … 1M(Str...try)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:effectiveTime
TS1 … 1MEs gelten die Richtlinien des entsprechenden Kapitels im Allgemeinen Leitfaden.(Str...try)
Treetree.pnghl7:value
PQ1 … 1M(Str...try)
Treeblank.pngTreetree.png@unit
cs1 … 1RPhysikalische Einheit des Messwertes entsprechend der Vorgabe in ELGA_Dosisparameter
Treeblank.pngTreetree.png@value
real1 … 1RGröße des Messwertes.


6.3.3 Frühere Untersuchungen

In dieser Sektion werden alle früheren Untersuchungen mit Bildmaterial bzw. älteres Bildmaterial alleine aufgelistet, welche(s) zur Erstellung des gegenständlichen Befundes herangezogen wurden.

6.3.3.1 Überblick

Titel der Sektion Frühere Untersuchungen
Definition Aufzählung früherer Untersuchungen, deren Ergebnis (bzw. Bildmaterial) bei der Erstellung des vorliegenden Befundes herangezogen bzw. berücksichtigt wurde.
Codierung LOINC: 55114-3
Prior imaging procedure descriptions
Konformität [O]

Da es sich bei dieser Sektion um eine rein verbale Auflistung der Vorbefunde bzw. des älteren Bildmaterials handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.3.3.2 Spezifikation

Id1.2.40.0.34.11.5.2.6
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameFruehereUntersuchungenBezeichnungFrühere Untersuchungen
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.6
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.6 Frühere Untersuchungen (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.6"/>  <!-- Code der Sektion -->
  <code code="55114-3" displayName="Prior imaging procedure descriptions" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Frühere Untersuchungen</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Fru...gen)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Fru...gen)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.6
Treetree.pnghl7:code
CE1 … 1M(Fru...gen)
Treeblank.pngTreetree.png@code
CONF1 … 1F55114-3
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FPrior imaging procedure descriptions
Treetree.pnghl7:title
ST1 … 1M(Fru...gen)
 CONF
Elementinhalt muss "Frühere Untersuchungen" sein
Treetree.pnghl7:text
ED1 … 1M(Fru...gen)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Fru...gen)


6.3.4 Frühere Befunde

In dieser Sektion werden alle früheren, nur als Text zur Verfügung stehenden, Befunde, welche zur Erstellung des gegenständlichen Befundes herangezogen wurden, aufgelistet.

6.3.4.1 Überblick

Titel der Sektion Frühere Befunde
Definition Aufzählung früherer Befunde (ohne Bildmaterial), deren Ergebnis bei der Erstellung des vorliegenden Befundes herangezogen bzw. berücksichtigt wurde.
Codierung LOINC: 18834-2
Comparison.study
Konformität [O]

Da es sich bei dieser Sektion um eine rein verbale Auflistung der Vorbefunde handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.3.4.2 Spezifikation

Id1.2.40.0.34.11.5.2.7
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameFruehereBefundeBezeichnungFrühere Befunde
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.7
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.7 Frühere Befunde (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.7"/>  <!-- Code der Sektion -->
  <code code="18834-2" displayName="Comparison.study" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Frühere Befunde</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Fru...nde)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Fru...nde)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.7
Treetree.pnghl7:code
CE1 … 1M(Fru...nde)
Treeblank.pngTreetree.png@code
CONF1 … 1F18834-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FComparison.study
Treetree.pnghl7:title
ST1 … 1M(Fru...nde)
 CONF
Elementinhalt muss "Frühere Befunde" sein
Treetree.pnghl7:text
ED1 … 1M(Fru...nde)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Fru...nde)


6.3.5 Komplikationen

6.3.5.1 Überblick

Titel der Sektion Komplikationen
Definition Beschreibt Komplikationen, die während der bildgebenden Untersuchung aufgetreten sind.
Codierung LOINC: 55109-3
Complications
Konformität [O]

Da es sich bei dieser Sektion um eine rein verbale Darstellung von etwaigen Komplikationen handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.3.5.2 Spezifikation

Id1.2.40.0.34.11.5.2.8
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameKomplikationenBezeichnungKomplikationen
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.8
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.8 Komplikationen (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root=" 1.2.40.0.34.11.5.2.8 "/>  <!-- Code der Sektion -->
  <code code="55109-3" displayName="Complications" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Komplikationen</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Kom...nen)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Kom...nen)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.8
Treetree.pnghl7:code
CE1 … 1M(Kom...nen)
Treeblank.pngTreetree.png@code
CONF1 … 1F55109-3
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FComplications
Treetree.pnghl7:title
ST1 … 1M(Kom...nen)
 CONF
Elementinhalt muss "Komplikationen" sein
Treetree.pnghl7:text
ED1 … 1M(Kom...nen)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Kom...nen)

6.4 Ergebnissektionen

In diesen Sektionen wird das Ergebnis der bildgebenden Untersuchung abgebildet.

6.4.1 Befund

Diese Sektion bildet das Ergebnis der „Bildgebenden Diagnostik“ ab. Hier wird in ausführlicher Form das Resultat der Untersuchung beschrieben.

In dieser Sektion dürfen auch alle anderen Details einer „Bildgebenden Diagnostik“ beschrieben werden, sofern eine fein strukturierte Darstellung, wie sie mit Hilfe der definierten Sektionen vorgeschrieben wird, möglich ist.

Im Sinne einer vergleichbaren Darstellung SOLL dieser „Gesamtbefund“ sich dann aber zumindest an die durch die Reihenfolge der Sektionen vorgegebene Struktur halten.

6.4.1.1 Überblick

Titel der Sektion Befund
Definition Text, der das Ergebnis der „Bildgebenden Diagnostik“ darstellt
Codierung LOINC: 18782-3
Study observation
Konformität [M]
Konformität Level 3 [R2] gilt nur für Mammographie (MG, US, MRI)

Die Sektion MUSS immer im Befund „Bildgebende Diagnostik“ enthalten sein. Diese Sektion enthält den primären, beschreibenden Text des Befundes. Es ist dringend gefordert, dass in dieser Sektion nur der Befund-relevante Text enthalten ist und Themen wie Fragestellung (Überweisungsgrund), Anamnese, Aktuelle Untersuchung (Prozeduren), Empfehlung (weitere empfohlene Maßnahmen) und Addendum (Termine, Kontrollen, Wiederbestellung) in eigenen Sektionen dargestellt werden.

In Fällen, in denen die Quelle des Befundtextes eine derartige Trennung nicht zulässt, ist die Sektion Befund heranzuziehen und in den anderen, verpflichtenden Sektionen der Hinweis „Informationen im Abschnitt Befund“ anzugeben.

Da es sich bei dieser Sektion um eine rein verbale Darstellung des Befundes handelt, ist eine Codierung in Level 3 nicht vorgesehen.

Eine Ausnahme bildet hier die Mammographie, unabhängig von der angewandten Technik wie MG, US oder MRI. Sollte in dieser Sektion des Befundes die Klassifikation nach BIRADS®7 angegeben werden, so ist dieser Wert sowohl in Form einer Tabelle im Textbereich darzustellen, als auch als Level 3 Element in dieser Sektion zu codieren.

Eine allfällige Klassifizierung gemäß dem ACR Index ist ebenfalls als Tabelle im Textteil abzubilden. Eine Level 3 Codierung ist im Moment nicht vorgesehen.


7 BI-RADS® ist eine eingetragene Marke des American College of Radiology

6.4.1.2 Spezifikation

Id1.2.40.0.34.11.5.2.9
ref
elgabbr-
Gültigkeit2022‑11‑16 09:13:25
Andere Versionen mit dieser Id:
  • Kblank.png Befund vom 2012‑01‑12
StatusKyellow.png EntwurfVersions-Label
NameBefundBezeichnungBefund
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.9
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 3 Templates
Benutzt als NameVersion
1.2.40.0.34.11.5.3.2ContainmentKgreen.png Kodierung des BefundtextesDYNAMIC
1.2.40.0.34.11.5.3.1ContainmentKgreen.png BI-RADS® KlassifikationDYNAMIC
1.2.40.0.34.11.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.9 Befund (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel Allgemein
<section>
  <templateId root="1.2.40.0.34.11.5.2.9"/>  <!-- Code der Sektion -->
  <code code="18782-3" displayName="Study observation" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Befund</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
Beispiel
Strukturbeispiel Mammographie mit BI-RADS® Klassifikation
<ClinicalDocument>
  <section>
    <templateId root="1.2.40.0.34.11.5.2.9"/>    <!-- Code der Sektion -->
    <code code="18782-3" displayName="Study observation" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>    <!-- Titel der Sektion -->
    <title>Befund</title>    <!-- Textbereich der Sektion -->
    <text>
      <paragraph>
        <content ID="finding-1"> Parenchymasymmetrie. Verkalkte Ölcyste li. Sonst unauffälliger Befund bei Zustand nach Reduktionsplastik bds., derzeit kein Malignomhinweis. </content>      </paragraph>
      <table>
        <thead>
          <tr>
            <th>Klassifikation</th>            <th>Wert</th>          </tr>
        </thead>
        <tbody>
          <tr>
            <td>BI-RADS</td>            <td ID="birads">4A</td>          </tr>
          <tr>
            <td>ACR</td>            <td ID="acr">2</td>          </tr>
        </tbody>
      </table>
    </text>
    <!-- Maschinenlesbare Elemente der Sektion -->
    <!-- Entry fuer die Codierung des Befundtextes -->
    <entry>
      <observation classCode="OBS" moodCode="EVN">
        <!-- Text Observation -->
        <templateId root="1.2.40.0.34.11.5.3.2"/>        <templateId root="2.16.840.1.113883.10.20.6.2.12"/>        <code code="121071" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Finding"/>        <value type="ED">
          <reference value="#finding-1"/>        </value>
      </observation>
    </entry>
    <!-- entry fuer ELGA BI-RADS® Codierung -->
    <entry>
      <observation classCode="OBS" moodCode="EVN">
        <!-- Mammography Observation -->
        <templateId root="1.2.40.0.34.11.5.3.1"/>        <code code="36625-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Breast Mammogram"/>        <text>
          <reference value="#birads"/>        </text>
        <statusCode code="completed"/>        <effectiveTime value="20110830103000+02"/>        <value type="CD" code="MA.II.A.5.4A" codeSystem="1.2.40.0.34.5.49" codeSystemName="ELGA_MammogramAssessment"/>      </observation>
    </entry>
  </section>
</ClinicalDocument>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Befund)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Befund)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.9
Treetree.pnghl7:code
CE1 … 1M(Befund)
Treeblank.pngTreetree.png@code
CONF1 … 1F18782-3
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FStudy observation
Treetree.pnghl7:title
ST1 … 1M(Befund)
 CONF
Elementinhalt muss "Befund" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M
Befundtext sollte in Abschnitte (<paragraph>) gegliedert sein. Vorgegebene Struktur für Mammographie: Klassifikationen nach BI-RADS® oder nach ACR Index MÜSSEN im Textteil als Tabelle enthalten sein.
Empfohlen wird die Angabe der BI-RADS® Klassen in arabischen Ziffern.
(Befund)
Treetree.pnghl7:entry
Beinhaltet 1.2.40.0.34.11.5.3.2 Kodierung des Befundtextes (DYNAMIC)(Befund)
Treetree.pnghl7:entry
Beinhaltet 1.2.40.0.34.11.5.3.1 BI-RADS® Klassifikation (DYNAMIC)(Befund)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Befund)


6.4.1.3 Spezifikation des Entry Elements für Codierung des Befundtextes

Id1.2.40.0.34.11.5.3.2
ref
elgabbr-
Gültigkeit2014‑03‑24
StatusKgreen.png AktivVersions-Label
NameBefundtextKodierungBezeichnungKodierung des Befundtextes
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.3.2
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.5.3.2 Kodierung des Befundtextes (2014‑03‑24)
ref
elgabbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
(Bef...ung)
Treetree.png@classCode
cs1 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1R(Bef...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.3.2
Treetree.pnghl7:templateId
II1 … 1R(Bef...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.20.6.2.12
Treetree.pnghl7:code
CE1 … 1M(Bef...ung)
Treeblank.pngTreetree.png@code
CONF1 … 1F121071
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.840.10008.2.16.4 (DCM)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FDCM
Treeblank.pngTreetree.png@displayName
1 … 1FFinding
Auswahl1 … 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='RTO']
  • hl7:value[@xsi:type='RTO_QTY_QTY']
  • hl7:value[@xsi:type='RTO_PQ_PQ']
  • hl7:value[@nullFlavor]
  • hl7:value[@xsi:type='CD']
  • hl7:value[@xsi:type='ED'][not(@nullFlavor)]
 ConstraintDatentyp eingeschränkt auf PQ, IVL_PQ, INT, IVL_INT, BL, ST, CV, TS, CD, RTO, RTO_QTY_QTY, RTO_PQ_PQ, ED
Treeblank.pngTreetree.pnghl7:value
PQC(Bef...ung)
wo [@xsi:type='PQ']
Treeblank.pngTreetree.pnghl7:value
IVL_PQC(Bef...ung)
wo [@xsi:type='IVL_PQ']
Treeblank.pngTreetree.pnghl7:value
INTC(Bef...ung)
wo [@xsi:type='INT']
Treeblank.pngTreetree.pnghl7:value
IVL_INTC(Bef...ung)
wo [@xsi:type='IVL_INT']
Treeblank.pngTreetree.pnghl7:value
BLC(Bef...ung)
wo [@xsi:type='BL']
Treeblank.pngTreetree.pnghl7:value
STC(Bef...ung)
wo [@xsi:type='ST']
Treeblank.pngTreetree.pnghl7:value
CVC(Bef...ung)
wo [@xsi:type='CV']
Treeblank.pngTreetree.pnghl7:value
TSC(Bef...ung)
wo [@xsi:type='TS']
Treeblank.pngTreetree.pnghl7:value
RTOC(Bef...ung)
wo [@xsi:type='RTO']
Treeblank.pngTreetree.pnghl7:value
RTO_QTY_QTYC(Bef...ung)
wo [@xsi:type='RTO_QTY_QTY']
Treeblank.pngTreetree.pnghl7:value
RTO_PQ_PQC(Bef...ung)
wo [@xsi:type='RTO_PQ_PQ']
Treeblank.pngTreetree.pnghl7:value
C(Bef...ung)
wo [@nullFlavor]
Treeblank.pngTreetree.pnghl7:value
CDC(Bef...ung)
wo [@xsi:type='CD']
Treeblank.pngTreetree.pnghl7:value
ED1 … 1M(Bef...ung)
wo [@xsi:type='ED']
Treeblank.pngTreeblank.pngTreetree.pnghl7:reference
1 … 1M@value: Referenz auf die Level 2 Id des Befundtextes.(Bef...ung)


6.4.1.4 Spezifikation des Entry Elements für BI-RADS® Klassifikation

Id1.2.40.0.34.11.5.3.1
ref
elgabbr-
Gültigkeit2014‑03‑24
Andere Versionen mit dieser Id:
  • Kblank.png KlassifikationBIRADS vom 2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameKlassifikationBIRADSBezeichnungBI-RADS® Klassifikation
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.3.1
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.5.3.1 BI-RADS® Klassifikation (2014‑03‑24)
ref
elgabbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
(Kla...ADS)
Treetree.png@classCode
cs1 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1R(Kla...ADS)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.3.1
Treetree.pnghl7:code
CE1 … 1M(Kla...ADS)
Treeblank.pngTreetree.png@code
CONF1 … 1F36625-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FBreast Mammogram
Treetree.pnghl7:text
ED1 … 1M(Kla...ADS)
Treeblank.pngTreetree.pnghl7:reference
1 … 1M@value: Referenz auf Id des Ergebnisses im section.text.(Kla...ADS)
Treetree.pnghl7:statusCode
CS1 … 1M(Kla...ADS)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:effectiveTime
TS1 … 1MEs gelten die Richtlinien des entsprechenden Kapitels im Allgemeinen Leitfaden.(Kla...ADS)
Auswahl1 … 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='RTO']
  • hl7:value[@xsi:type='RTO_QTY_QTY']
  • hl7:value[@xsi:type='RTO_PQ_PQ']
  • hl7:value[@nullFlavor]
  • hl7:value[@xsi:type='CD'][not(@nullFlavor)]
 ConstraintDatentyp 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
PQC(Kla...ADS)
wo [@xsi:type='PQ']
Treeblank.pngTreetree.pnghl7:value
IVL_PQC(Kla...ADS)
wo [@xsi:type='IVL_PQ']
Treeblank.pngTreetree.pnghl7:value
INTC(Kla...ADS)
wo [@xsi:type='INT']
Treeblank.pngTreetree.pnghl7:value
IVL_INTC(Kla...ADS)
wo [@xsi:type='IVL_INT']
Treeblank.pngTreetree.pnghl7:value
BLC(Kla...ADS)
wo [@xsi:type='BL']
Treeblank.pngTreetree.pnghl7:value
STC(Kla...ADS)
wo [@xsi:type='ST']
Treeblank.pngTreetree.pnghl7:value
CVC(Kla...ADS)
wo [@xsi:type='CV']
Treeblank.pngTreetree.pnghl7:value
TSC(Kla...ADS)
wo [@xsi:type='TS']
Treeblank.pngTreetree.pnghl7:value
RTOC(Kla...ADS)
wo [@xsi:type='RTO']
Treeblank.pngTreetree.pnghl7:value
RTO_QTY_QTYC(Kla...ADS)
wo [@xsi:type='RTO_QTY_QTY']
Treeblank.pngTreetree.pnghl7:value
RTO_PQ_PQC(Kla...ADS)
wo [@xsi:type='RTO_PQ_PQ']
Treeblank.pngTreetree.pnghl7:value
C(Kla...ADS)
wo [@nullFlavor]
Treeblank.pngTreetree.pnghl7:value
CD1 … 1M(Kla...ADS)
wo [@xsi:type='CD']
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.55 ELGA_MammogramAssessment (DYNAMIC)


6.4.2 Zusammenfassung/Ergebnis

In dieser Sektion wird das Ergebnis der „Bildgebenden Diagnostik“ in kurzer Form dargestellt. Die Sektion entspricht der typischen Schlussdarstellung heutiger Papierbefunde.

6.4.2.1 Überblick

Titel der Sektion Zusammenfassung/Ergebnis
Definition Kurze Zusammenfassung der klaren Befundergebnisse
Codierung LOINC: 55112-7
Document summary
Konformität [R2]

Da es sich bei dieser Sektion um eine rein verbale Darstellung des Ergebnisses handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.4.2.2 Strukturbeispiel

Id1.2.40.0.34.11.5.2.10
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameZusammenfassungErgebnisBezeichnungZusammenfassung / Ergebnis
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.10
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.10 Zusammenfassung / Ergebnis (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.10"/>  <!-- Code der Sektion -->
  <code code="55112-7" displayName="Document summary" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Zusammenfassung / Ergebnis</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Zus...nis)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Zus...nis)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.10
Treetree.pnghl7:code
CE1 … 1M(Zus...nis)
Treeblank.pngTreetree.png@code
CONF1 … 1F55112-7
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FDocument summary
Treetree.pnghl7:title
ST1 … 1M(Zus...nis)
 CONF
Elementinhalt muss "Zusammenfassung / Ergebnis" sein
Treetree.pnghl7:text
ED1 … 1M(Zus...nis)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Zus...nis)


6.4.3 Verdachtsdiagnose

In dieser Sektion werden Verdachtsdiagnosen, also Diagnosen die nicht zu 100% durch die gegenständliche Untersuchung abgesichert werden konnten, dargestellt.

6.4.3.1 Überblick

Titel der Sektion Verdachtsdiagnose
Definition Beschreibt Verdachtsdiagnose(n)
Codierung LOINC: 19005-8
Impression
Konformität [O]

Achtung, der LOINC 19005-8 wird hier im Sinne des Eindrucks (Impression) interpretiert. Dies geht auf eine Festlegung der DICOM WG 20 zurück, welche den DICOM Code 121072 (Bedeutung: Impression) mit LOINC 19005-8 gleichsetzt.

Da es sich bei dieser Sektion um eine rein verbale Darstellung der Verdachtsdiagnose handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.4.3.2 Spezifikation

Id1.2.40.0.34.11.5.2.11
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameVerdachtsdiagnoseBezeichnungVerdachtsdiagnose
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.11
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.11 Verdachtsdiagnose (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.11"/>  <!-- Code der Sektion -->
  <code code="19005-8" displayName="Impression" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Verdachtsdiagnose</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Ver...ose)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Ver...ose)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.11
Treetree.pnghl7:code
CE1 … 1M(Ver...ose)
Treeblank.pngTreetree.png@code
CONF1 … 1F19005-8
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FImpression
Treetree.pnghl7:title
ST1 … 1M(Ver...ose)
 CONF
Elementinhalt muss "Verdachtsdiagnose" sein
Treetree.pnghl7:text
ED1 … 1M(Ver...ose)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Ver...ose)


6.4.4 Schlussfolgerung

In dieser Sektion beschreibt der Befundende seine Schlüsse aus den Vorstudien und dem aktuellen Bildmaterial.

Keinesfalls sind in dieser Sektion daraus abgeleitete Empfehlungen zu formulieren, diese gehören in ihre eigene Sektion (siehe Kapitel Empfehlung).

6.4.4.1 Überblick

Titel der Sektion Schlussfolgerung
Definition Keine Empfehlung, die gehört in die Sektion Empfehlung
Codierung LOINC: 55110-1
Conclusions
Konformität [O]

Da es sich bei dieser Sektion um eine rein verbale Darstellung der Schlussfolgerung handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.4.4.2 Spezifikation

Id1.2.40.0.34.11.5.2.12
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameSchlussfolgerungBezeichnungSchlussfolgerung
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.12
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.12 Schlussfolgerung (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.12"/>  <!-- Code der Sektion -->
  <code code="55110-1" displayName="Conclusions" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Schlussfolgerung</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Sch...ung)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Sch...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.12
Treetree.pnghl7:code
CE1 … 1M(Sch...ung)
Treeblank.pngTreetree.png@code
CONF1 … 1F55110-1
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FConclusions
Treetree.pnghl7:title
ST1 … 1M(Sch...ung)
 CONF
Elementinhalt muss "Schlussfolgerung" sein
Treetree.pnghl7:text
ED1 … 1M(Sch...ung)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Sch...ung)


6.4.5 Empfehlung

In dieser Sektion werden die vom Befund abzuleitenden Empfehlungen formuliert. Diese können sowohl weitere Untersuchungen als auch in Betracht zu ziehende Behandlungen sein.

Auch etwaige Medikationen wären hier darzustellen.

6.4.5.1 Überblick

Titel der Sektion Empfehlung
Definition Empfehlungen als Ergebnis der radiologischen bzw. nuklearmedizinischen Untersuchung. Behandlung, weitere Abklärung, Medikation, OP, Biopsie, usw.
Codierung LOINC: 18783-1
Study recommendation
Konformität [O]

Die Sektion darf explizit keine Termine von Wiederbestellungen, geplante Kontrollen, etc. enthalten.

Da es sich bei dieser Sektion um eine rein verbale Darstellung der Schlussfolgerung handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.4.5.2 Spezifikation

Id1.2.40.0.34.11.5.2.13
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameEmpfehlungBezeichnungEmpfehlung
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.13
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.13 Empfehlung (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.13"/>  <!-- Code der Sektion -->
  <code code="18783-1" displayName="Study recommendation" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Empfehlung</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Emp...ung)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Emp...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.13
Treetree.pnghl7:code
CE1 … 1M(Emp...ung)
Treeblank.pngTreetree.png@code
CONF1 … 1F18783-1
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FStudy recommendation
Treetree.pnghl7:title
ST1 … 1M(Emp...ung)
 CONF
Elementinhalt muss "Empfehlung" sein
Treetree.pnghl7:text
ED1 … 1M(Emp...ung)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Emp...ung)


6.4.6 Addendum

Diese Sektion beinhaltet all jene verbalen Informationen, welche in keiner der anderen Sektionen sinnhaft dargestellt werden können. Dazu zählen beispielhaft Nebenbefunde und persönliche Anmerkungen an den Einweiser/Zuweiser.

6.4.6.1 Überblick

Titel der Sektion Addendum
Definition Zusätze, Nebenbefunde, Anmerkungen, etc.
Codierung LOINC: 55107-7
Addendum
Konformität [O]

Da es sich bei dieser Sektion um eine rein verbale Darstellung handelt, ist eine Codierung in Level 3 nicht vorgesehen.

6.4.6.2 Spezifikation

Id1.2.40.0.34.11.5.2.14
ref
elgabbr-
Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameAddendumBezeichnungAddendum
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.5.2.14
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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.5.2.14 Addendum (2012‑01‑12)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.11.5.2.14"/>  <!-- Code der Sektion -->
  <code code="55107-7" displayName="Addendum" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title>Addendum</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Add...dum)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Add...dum)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.5.2.14
Treetree.pnghl7:code
CE1 … 1M(Add...dum)
Treeblank.pngTreetree.png@code
CONF1 … 1F55107-7
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FAddendum
Treetree.pnghl7:title
ST1 … 1M(Add...dum)
 CONF
Elementinhalt muss "Addendum" sein
Treetree.pnghl7:text
ED1 … 1M(Add...dum)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Add...dum)

6.5 Einleitende und abschließende Sektionen

Dieses Kapitel behandelt Sektionen für einleitende Bemerkungen, die in der Regel in einem Befund „Bildgebende Diagnostik“ angegeben werden (Grußformeln, persönliche Anrede, etc.). Auch automatisch erzeugte Sektionen werden hier beschrieben.

  • DICOM Object Catalog
  • Brieftext
  • Schlüsselbilder

6.5.1 DICOM Object Catalog

Diese Sektion ist rein technischer Natur. Sie enthält eine Liste aller in dem gegenständlichen Befund referenzierten DICOM Objekte und die sie enthaltenden Serien bzw. Studien. Sie enthält auch all jene Informationen, welche zum Zugriff auf die Objekte von Nöten sind.

Die exakte Definition der Verfügbarmachung von Bilddaten und der zugehörigen Uniform Resource Locators (URL) im Rahmen von ELGA ist noch durch die ELGA GmbH zu definieren. Die Arbeitsgruppe hat sich hier für eine eigene, technische Arbeitsgruppe ausgesprochen. Im angeführten Code-Beispiel sind zu Demonstrationszwecken allgemeingültige URL verwendet.

6.5.1.1 Überblick

Titel der Sektion -
Definition Listet alle referenzierten Objekte und die sie enthaltenden Serien und/oder Studien sowie all jene DICOM Attribute, die für den Zugriff auf die Objekte nötig sind.
Codierung 121181 aus DICOM (Context Group CID 7001)
DICOM Object Catalog
Konformität [R2]

Diese Sektion MUSS, sofern angegeben, die erste im Body sein.

Da diese Sektion ausschließlich maschinenlesbare Information enthält und auch nicht zur Anzeige gedacht ist, darf sie weder ein section/title -Element noch ein section/text -Element enthalten. In dieser Sektion sind nur Level 3 Elemente enthalten.

6.5.1.2 Spezifikation

6.5.1.2.1 DICOM
Id2.16.840.1.113883.10.20.6.1.1Gültigkeit2014‑03‑24
Andere Versionen mit dieser Id:
  • Kblank.png DOCS vom 2012‑01‑12
StatusKyellow.png EntwurfVersions-Label
NameDOCSBezeichnungDICOM Object Catalog Sektion Allgemein
BeschreibungDICOM Object Catalog section. Muss angeführt werden wenn das Dokument Referenzen auf DICOM Bilder aufweist. Des Weiteren muss diese Sektion die erste Sektion des Dokuments sein.
KontextElternknoten des Template-Element mit Id 2.16.840.1.113883.10.20.6.1.1
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
2.16.840.1.113883.10.20.6.2.6ContainmentKgreen.png Study ActDYNAMIC
Beispiel
Strukturbeispiel
<section classCode="DOCSECT">
  <templateId root="2.16.840.1.113883.10.20.6.1.1"/>  <code code="121181" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="DICOM Object Catalog"/>  <entry>
    <!-- ************ Study *************** -->
    <act classCode="ACT" moodCode="EVN">
      <templateId root="2.16.840.1.113883.10.20.6.2.6"/>      <id root="1.2.840.113619.2.62.994044785528.114289542805"/>      <code code="113014" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Study"/>      <!-- ************ Series*************** -->
      <entryRelationship typeCode="COMP">
        <act classCode="ACT" moodCode="EVN">
          <id root="1.2.840.113619.2.62.994044785528.20060823223142485051"/>          <code code="113015" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Series">
            <qualifier>
              <name code="121139" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Modality"/>              <value code="CR" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Computed Radiography"/>            </qualifier>
          </code>
          <!-- ************ SopInstance UID *************** -->
          <!-- 2 References (chest PA and LAT) -->
          <!--reference to image 1 (PA) -->
          <entryRelationship typeCode="COMP">
            <observation classCode="DGIMG" moodCode="EVN">
              <templateId root="2.16.840.1.113883.10.20.6.2.8"/>              <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>              <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage"/>              <text mediaType="application/dicom">
                <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/dicom"/>              </text>
              <effectiveTime value="20060823223232"/>            </observation>
          </entryRelationship>
          <!--reference to image 2 (LAT) -->
          <entryRelationship typeCode="COMP">
            <observation classCode="DGIMG" moodCode="EVN">
              <templateId root="2.16.840.1.113883.10.20.6.2.8"/>              <id root="1.2.840.113619.2.62.994044785528.20060823.200608232231422.3"/>              <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage"/>              <text mediaType="application/dicom">
                <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232231422.3&contentType=application/dicom"/>              </text>
              <effectiveTime value="20060823223142"/>            </observation>
          </entryRelationship>
        </act>
      </entryRelationship>
    </act>
  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
DICOM Object Catalog section. MUSS angeführt werden, wenn das Dokument Referenzen auf DICOM Bilder aufweist. Des Weiteren MUSS diese Sektion die erste Sektion des Dokuments sein.
(DOCS)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(DOCS)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.20.6.1.1
Treetree.pnghl7:code
CE1 … 1M(DOCS)
Treeblank.pngTreetree.png@code
CONF1 … 1F121181
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.840.10008.2.16.4 (DCM)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FDCM
Treeblank.pngTreetree.png@displayName
1 … 1FDICOM Object Catalog
Treetree.pnghl7:title
NPDieses Element ist NICHT ERLAUBT.
(DOCS)
Treetree.pnghl7:text
NPDieses Element ist NICHT ERLAUBT.
(DOCS)
Treetree.pnghl7:entry
1 … *MJeder Entry Knoten bildet eine Studie ab.

Beinhaltet 2.16.840.1.113883.10.20.6.2.6 Study Act (DYNAMIC)
(DOCS)


6.5.1.2.2 Study Act
Id2.16.840.1.113883.10.20.6.2.6Gültigkeit2014‑03‑24
Andere Versionen mit dieser Id:
  • Kblank.png StudyAct vom 2013‑10‑03
  • Kblank.png StudyAct vom 2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameStudyActBezeichnungStudy Act
KontextElternknoten des Template-Element mit Id 2.16.840.1.113883.10.20.6.2.6
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.30031ContainmentKgreen.png Series ActDYNAMIC
BeziehungVersion: Template 2.16.840.1.113883.10.20.6.2.6 Study Act (2014‑03‑24)
ref
elga-
ItemDTKardKonfBeschreibungLabel
hl7:act
(Stu...Act)
Treetree.png@classCode
cs1 … 1FACT
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1R(Stu...Act)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.20.6.2.6
Treetree.pnghl7:id
II1 … 1R(Stu...Act)
Treeblank.pngTreetree.png@root
uid1 … 1ROID der Studien UID.
Treeblank.pngTreetree.png@extension
st0NPNP/nicht anwesend
 Dieses Attribut darf nicht vorkommen, da DICOM Studien IDs nur durch eine OID gekennzeichnet sind [1].
Treetree.pnghl7:code
CE1 … 1M(Stu...Act)
Treeblank.pngTreetree.png@code
CONF1 … 1F113014
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.840.10008.2.16.4 (DCM)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FDCM
Treeblank.pngTreetree.png@displayName
1 … 1FDICOM Study
Treetree.pnghl7:text
ST0 … 1Optionale Beschreibung der Studie.
(Stu...Act)
Treetree.pnghl7:effectiveTime
TS0 … 1Zeitpunkt an dem die Studie gestartet wurde. Es gelten die Vorgaben des entsprechenden Kapitels des Implementierungs-leitfadens „CDA Dokumente für das österreichische Gesundheitswesen“ [1.2.40.0.34.11.1]
(Stu...Act)
Treetree.pnghl7:entryRelationship
1 … *MBeinhaltet 1.2.40.0.34.11.30031 Series Act (DYNAMIC)(Stu...Act)
wo [hl7:act [hl7:code [@code='113015']]]


6.5.1.2.3 Series Act
Id1.2.40.0.34.11.30031Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameSeriesActBezeichnungSeries Act
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
2.16.840.1.113883.10.20.6.2.8ContainmentKgreen.png SopInstance (DICOM Service Object Pair)DYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.30031 Series Act (2012‑01‑12)
ref
elga-
Beispiel
Beispiel
<!-- Entry fuer die Codierung des Befundtextes -->
<observation classCode="OBS" moodCode="EVN">
  <templateId root="1.2.40.0.34.11.5.3.2"/>  <templateId root="2.16.840.1.113883.10.20.6.2.12"/>  <code code="121071" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Finding"/>  <value type="CD">
    <reference value="#finding1"/>  </value>
</observation>
ItemDTKardKonfBeschreibungLabel
hl7:act
Series Act
Zulässige NullFlavor: NAV 
(vorübergehend nicht verfügbar)
(Ser...Act)
Treetree.png@classCode
cs1 … 1FACT
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:id
II1 … 1R(Ser...Act)
Treeblank.pngTreetree.png@root
uid1 … 1ROID der Series UID.
Treeblank.pngTreetree.png@extension
st0NPNP/nicht anwesend
 Dieses Attribut darf nicht vorkommen, da DICOM Series IDs nur durch eine OID gekennzeichnet sind [1].
Treetree.pnghl7:code
CD1 … 1M(Ser...Act)
Treeblank.pngTreetree.png@code
CONF1 … 1F113015
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.840.10008.2.16.4 (DCM)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FDCM
Treeblank.pngTreetree.png@displayName
1 … 1FDICOM Series
Treeblank.pngTreetree.pnghl7:qualifier
CR1 … 1M(Ser...Act)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
CD1 … 1M(Ser...Act)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
CONF1 … 1F121139
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
1 … 1F1.2.840.10008.2.16.4 (DCM)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
1 … 1FDCM
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
1 … 1FModality
Treeblank.pngTreeblank.pngTreetree.pnghl7:value
CD1 … 1M(Ser...Act)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
CONF1 … 1F1.2.840.10008.2.16.4 (DCM)
Treetree.pnghl7:text
ST0 … 1Optionale Beschreibung der Series.
(Ser...Act)
Treetree.pnghl7:effectiveTime
IVL_TS0 … 1Zeitpunkt an dem die Studie gestartet wurde. Es gelten die Vorgaben des entsprechenden Kapitels des Implementierungs-leitfadens „CDA Dokumente für das österreichische Gesundheitswesen“ [1.2.40.0.34.11.1]
(Ser...Act)
Treetree.pnghl7:entryRelationship
1 … *MBeinhaltet 2.16.840.1.113883.10.20.6.2.8 SopInstance (DICOM Service Object Pair) (DYNAMIC)(Ser...Act)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP


6.5.1.2.4 SopInstance (DICOM Service Object Pair)
Id2.16.840.1.113883.10.20.6.2.8Gültigkeit2012‑01‑12
StatusKgreen.png AktivVersions-Label
NameSopInstanceBezeichnungSopInstance (DICOM Service Object Pair)
KontextElternknoten des Template-Element mit Id 2.16.840.1.113883.10.20.6.2.8
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungVersion: Template 2.16.840.1.113883.10.20.6.2.8 SopInstance (DICOM Service Object Pair) (2012‑01‑12)
ref
elga-
ItemDTKardKonfBeschreibungLabel
hl7:observation
SopInstance observation.
Zulässige NullFlavor: NAV 
(vorübergehend nicht verfügbar)
(Sop...nce)
Treetree.png@classCode
cs1 … 1FDGIMG
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1R(Sop...nce)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.20.6.2.8
Treetree.pnghl7:id
II1 … 1RDICOM SOP Instance UID.
(Sop...nce)
Treeblank.pngTreetree.png@root
uid1 … 1ROID der „DICOM SOP Instance UID“.
Treeblank.pngTreetree.png@extension
st0NPNP/nicht anwesend
Treetree.pnghl7:code
CD1 … 1MSOP UID (SOP Class).
(Sop...nce)
Treeblank.pngTreetree.png@codeSystem
CONF1 … 1F1.2.840.10008.2.6.1 (DICOM UID)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FDCMUID
Treetree.pnghl7:text
ED0 … 1@value: WADO Referenz als URI(Sop...nce)
Treeblank.pngTreetree.png@mediaType
st1 … 1Fapplication/dicom
Treeblank.pngTreetree.pnghl7:reference
1 … 1M(Sop...nce)
Treetree.pnghl7:effectiveTime
TS0 … 1@value: Zeitpunkt wird unter value codiert und nicht mittels high/low Elementen.
(Sop...nce)


6.5.2 Brieftext

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

HINWEIS: Mit Hilfe dieser Sektion kann das Logo der Organisationseinheit im Befund übermittelt werden. Die Angabe von medizinisch fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT


Auszug aus dem Allgemeinen Implementierungsleitfaden

6.5.3 Brieftext

6.5.3.1 Überblick

EIS „Enhanced“ und „Full Support“
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 relevanter Information in diesem Abschnitt ist NICHT ERLAUBT.

Bsp: „Danke für die Zuweisung …“

Codierung ELGA: BRIEFT, „Brieftext“
Konformität [O]
Konformität Level 3 [O] (falls ein Logo angegeben wird)

6.5.3.2 Spezifikation

6.5.3.2.1 Sektion Allgemein
Id1.2.40.0.34.11.1.2.1
ref
elgabbr-
Gültigkeit2011‑12‑19
StatusKgreen.png AktivVersions-Label
NameBrieftextBezeichnungBrieftext
BeschreibungEin am Anfang des Briefes formulierter Freitext für eine Anrede oder Begrüßung. Die Angabe von medizinisch fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT.
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.1.2.1
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.1.3.2ContainmentKgreen.png Logo EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.1.2.1 Brieftext (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section classCode="DOCSECT">
  <!-- ELGA EIS „Basic“ und “Full support” -->
  <templateId root="1.2.40.0.34.11.1.2.1"/>  <!-- Titel der Sektion Brieftext wird vom ELGA Referenz-Stylesheet nicht angezeigt! -->
  <code code="BRIEFT" displayName="Brieftext" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  <!-- Titel der Sektion Brieftext wird vom ELGA Referenz-Stylesheet nicht angezeigt! -->
  <title>Brieftext</title>  <!-- Textbereich der Sektion -->
  <text/>  <!-- Maschinenlesbare Elemente der Sektion (optionales Logo) -->
  <entry>
    <templateId root="1.2.40.0.34.11.1.3.2"/>  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
Container zur Angabe des Brieftexts.(Bri...ext)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.pnghl7:templateId
II1 … 1R(Bri...ext)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.2.1
Treetree.pnghl7:code
CE1 … 1MCode der Sektion.(Bri...ext)
Treeblank.pngTreetree.png@code
CONF1 … 1FBRIEFT
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.40.0.34.5.40
Treeblank.pngTreetree.png@displayName
1 … 1FBrieftext
Treetree.pnghl7:title
ST1 … 1R(Bri...ext)
 CONF
Elementinhalt muss "Brieftext" sein
Treetree.pnghl7:text
1 … 1RInformation für den menschlichen Leser.
Achtung: Wird ein Logo als maschinenlesbares Element angegeben, darf keine Referenz darauf im narrativen Text-Bereich angegeben werden (<renderMultiMedia referencedObject="…"/>).
(Bri...ext)
Treetree.pnghl7:entry
0 … 1Es KANN zusätzlich ein Logo als maschinenlesbares Element angegeben werden.
Maschinenlesbares Element gemäß Template „ELGA Logo-Entry“ (1.2.40.0.34.11.1.3.2).
Beinhaltet 1.2.40.0.34.11.1.3.2 Logo Entry (DYNAMIC)
(Bri...ext)

Der Titel dieser Sektion wird vom ELGA Referenz-Stylesheet nicht angezeigt, das Logo wird speziell platziert. Andere CDA-Stylesheets könnten den Titel der Sektion anzeigen und das Logo direkt im Text der Sektion darstellen.

6.5.4 Abschließende Bemerkungen

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

Ein am Ende des Briefes formulierter Freitext entsprechend einer Grußformel.


Auszug aus dem Allgemeinen Implementierungsleitfaden

6.5.5 Abschließende Bemerkungen

6.5.5.1 Überblick

EIS „Enhanced“ und „Full Support“
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 einer 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]
Konformität Level 3 [NP]

6.5.5.2 Spezifikation

Id1.2.40.0.34.11.1.2.2
ref
elgabbr-
Gültigkeit2012‑07‑14
StatusKgreen.png AktivVersions-Label
NameAbschliessendeBemerkungBezeichnungAbschliessendeBemerkung
BeschreibungEin am Ende des Briefes formulierter Freitext entsprechend einer Grußformel.
Die Angabe von medizinisch fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT.
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.11.1.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.1.3.1ContainmentKgreen.png Eingebettetes Objekt EntryDYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.1.2.2 AbschliessendeBemerkung (2012‑07‑14)
ref
elgabbr-
Beispiel
Strukturbeispiel
<section>
  <!-- ELGA EIS „Basic“ und “Full support” -->
  <templateId root="1.2.40.0.34.11.1.2.2"/>  <!-- Code der Sektion -->
  <code code="ABBEM" displayName="Abschließende Bemerkungen" codeSystem="1.2.40.0.34.5.40" codeSystemName="ELGA_Sections"/>  <!-- Titel der Sektion Abschließende Bemerkungen wird vom ELGA Referenz-Stylesheet nicht angezeigt! -->
  <title>Abschließende Bemerkungen</title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
Container zur Angabe der abschließenden Bemerkungen.(Abs...ung)
Treetree.pnghl7:templateId
II1 … 1R(Abs...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.11.1.2.2
Treetree.pnghl7:code
CE1 … 1M(Abs...ung)
Treeblank.pngTreetree.png@code
CONF1 … 1FABBEM
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.40.0.34.5.40
Treeblank.pngTreetree.png@displayName
1 … 1FAbschließende Bemerkungen
Treetree.pnghl7:title
ST1 … 1R(Abs...ung)
 CONF
Elementinhalt muss "Abschließende Bemerkungen" sein
Treetree.pnghl7:text
ST1 … 1RInformation für den menschlichen Leser.(Abs...ung)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.11.1.3.1 Eingebettetes Objekt Entry (DYNAMIC)(Abs...ung)

Der Titel dieser Sektion wird vom ELGA Referenz-Stylesheet nicht angezeigt. Andere CDA-Stylesheets könnten den Titel der Sektion anzeigen. 

6.5.6 Schlüsselbilder

In dieser Sektion werden Links (URLs) zu Schlüsselbildern gespeichert. Die Links sind vor allem für den Aufruf von bereits gerenderten Bildern (JPG) gedacht, da DICOM beim Zugriff auf Serien die Information zu Schlüsselbildern mitliefert.

6.5.6.1 Überblick

Titel der Sektion Schlüsselbilder
Definition In diesem Abschnitt werden Links zu den Key-Images gespeichert (ein technischer Vorgang, welcher vom RIS/PACS zu realisieren ist. Ist aus Kompatibilitätsüberlegungen zu WG20 erhalten geblieben).
Codierung 55113-5
KEY IMAGES
Konformität [O]

Wenn im Befund „Bildgebende Diagnostik“ Bilder referenziert werden, vor allem bei Schnittbild-Serien, so sind die Key-Images normalerweise beim DICOM Zugriff ebenfalls verfügbar. Folglich wird diese Sektion im Normalfall nicht nötig sein.

7 Technische Konformitätsprüfung

Die Prüfung einer XML-Instanz gegenüber Konformität zu diesem Leitfaden erfolgt gemäß dem entsprechenden Kapitel im „Allgemeinen Implementierungsleitfaden“.


Auszug aus dem Allgemeinen Implementierungsleitfaden

8 Technische Konformitätsprüfung

Dieses Kapitel behandelt die technische Konformitätsprüfung von CDA-Dokumenten gemäß diesem Dokumentleitfaden mittels Schema und Schematron.

8.1 Schema-Prüfung

Das Absolvieren der Schema-Prüfung ist der erste Teil der technischen Konformitätsprüfung.

Eine Prüfung gegen das CDA Schema prüft die gültige „Struktur“ eines CDA-Dokuments, wie beispielsweise

  • ob die XML Struktur generell gültig ist
  • ob alle Elemente die richtigen Namen haben
  • ob alle Elemente an der richtigen Stelle platziert sind
  • ob alle gemäß Schema erforderlichen Elemente vorhanden sind

Die Schema-Prüfung stellt sicher, dass es sich beim geprüften CDA-Dokument tatsächlich um eine gültige CDA-Struktur handelt.

Die Gültigkeit der „Inhalte“ wird nur in Bezug auf den erforderlichen Datentyp der Elemente geprüft. Hiermit kann beispielsweise sichergestellt werden, dass ein „id“-Element (technisch) immer eine gültige ID enthält.

Das von ELGA verwendete Schema basiert im Wesentlichen auf dem original publizierten Schema von CDA, weist aber einige Spezifika auf. Das angepasste Schema wird auf der Website der ELGA GmbH bereitgestellt.

Die Mindestvoraussetzung, damit ein CDA-Dokument als „gültig“ erachtet wird, ist die fehlerfreie Validierung mit dem CDA-Schema. Das maßgebliche CDA-Schema wird auf http://www.elga.gv.at/cda publiziert.

8.2 Schematron-Prüfung

Im Unterschied zu einer CDA Schema Prüfung kann mittels einer Schematron-Prüfung jede beliebige Inhaltsvorschrift geprüft werden.

Das Schematron-Prüfmittel wird gemäß den Spezifikationen dieses Implementierungsleitfadens angefertigt, und stellt sicher, dass das geprüfte CDA-Dokument auch jene Anforderungen erfüllt, die über die Anforderungen des CDA Schemas hinausgehen. Solche Anforderungen sind beispielsweise:

  • Optionalitäten von Elementen
    • Zusätzliche Pflicht-Elemente
    • Eventuell konditional von anderen Inhalten abhängig
  • Anforderungen an den Inhalt von Elementen
    • Bestimmte Code/Wertelisten
    • Anzugebende Identifikatoren (ID)
  • etc.

Das Absolvieren der Schematron-Prüfung ist der zweite Teil der technischen Konformitätsprüfung und stellt sicher, dass das geprüfte Dokument die in den Implementierungsleitfäden beschriebenen „Geschäftsregeln“ befolgt.

Damit ein CDA-Dokument als vollständig „gültig“ hinsichtlich der ELGA Implementierungsleitfäden erachtet wird, ist die fehlerfreie Konformitätsprüfung mit den entsprechenden Schematron-Prüfregeln vorausgesetzt. Eine vollständige Prüfung der Geschäftsregeln kann nur durch einen menschlichen Prüfer erfolgen. Die ELGA GmbH kann auf Anfrage an http://cda@elga.gv.at eine solche Prüfung durchführen. Die maßgeblichen Schematron-Prüfmittel werden auf http://www.elga.gv.at/cda publiziert.

8.3 Online-Validation von CDA-Dokumenten

Für die Prüfung von einzelnen CDA-XML-Instanzen mit dem entsprechenden Schema und Schematron-Regeln stellt ELGA GmbH eine Webapplikation zur Verfügung. Diese ist erreichbar über https://ovp.elga-services.at/. Eine erfolgreiche Prüfung durch den Online-Validator beweist nicht automatisch die vollständige Einhaltung aller Geschäftsregeln, sondern nur die technische Konformität zu den Templates.

9 Anhang

9.1 Hinweise zur Anwendung des APPC

Befunde oder Bilddaten der bildgebenden Diagnostik werden mit dem APPC beschlagwortet, damit eine schnelle Filterung nach relevanten Informationen ermöglicht wird, beispielsweise um entsprechende Vorstudien aus der Radiologie zu selektieren.

Der APPC besteht aus vier Achsen mit Codes für Anatomie, Lateralität, Modalität und Prozedur. Ein gültiger APPC-Code besteht jeweils aus 4 Codes aus jeder der vier unabhängigen Achsen, die frei kombiniert werden können. Die Einträge in den Achsen sind hierarchisch geordnet, so dass Ober- und Unter- bzw. Teilbegriffe angegeben werden können (z.B. Arm – Hand – Finger).

Sinn des APPC ist NICHT eine möglichst detaillierte Angabe aller anatomischen Strukturen oder durchgeführten Prozeduren, sondern eine treffende Angabe von Informationen, damit vergleichbare Studien schnell identifiziert werden können.

Anatomie: In der Regel reicht die Angabe der anatomischen Region aus, was durch die ersten beiden hierarchischen Ebenen der Anatomieachse ausgedrückt werden kann; bei der Beschreibung von Extremitäten kann auch die dritte Ebene sinnvoll sein.

Lateralität: Die Lateralität soll angegeben werden.

Modalität: Die Modalität kann im APPC nur grob granuliert angegeben werden – auf Ebene des bildgebenden Prinzips.

Prozedur: Die Achse Prozedur hat nur nachgeordnete Bedeutung, sie ist daher nur anzugeben, wenn sie ein notwendiges Selektionskriterium darstellt, z.B. wenn es sich bei der Studie der eine Gefäßdarstellung handelt und andere Strukturen schlecht dargestellt sind.

Es können mehrere APPC Codes für einen Befund angegeben werden, vor allem wenn

  • mehrere anatomische Regionen beschlagwortet werden sollen,
  • mehrere Prozeduren angewendet wurden,
  • „kombinierte Modalitäten“ zum Einsatz kamen, wie z.B.: PET/CT, PET/MRT.

Die Angabe des APPC "0.0.0.0" - wenn also alle Achsen als "unbestimmt" angegeben werden - ist nicht erwünscht.


9.2 Empfehlung der Arbeitsgruppe zum Austausch von Bilddaten

Die Arbeitsgruppe bezieht sich auf den Beschluss der Bundesgesundheitskommission vom 4. Mai 2007. Mit der darin enthaltenen Empfehlung zur bundesweiten Verwendung einheitlicher Standards wurde eine grundlegende Weichenstellung zur Verbesserung der Interoperabilität der elektronischen Kommunikation von Gesundheitsdaten vorgenommen. Die Bedeutung dieser Empfehlung geht über die eigentliche Einführung von ELGA hinaus: Die neun Länder, die Sozialversicherung und der Bund haben beschlossen, dass eine gemeinsame Sprachgrundlage allen Gesundheitsdiensteanbietern ermöglichen soll, den Gesundheitsdatenaustausch auf der Grundlage bundesweit einheitlicher Rahmenbedingungen durchzuführen.

Im Arbeitskreis wurden 2 Arten der Bilddokumentation identifiziert und diskutiert:

  • in ELGA zu publizierende Bilddaten
  • in ELGA nicht zu publizierende bilaterale Bilddaten (Bildzugriff und Bildaustausch)

Die WADO (“Web Access to DICOM persistent Objects“) Technologie ist die Bild-zugriffstechnologie der IHE (Integrating the Healthcare Enterprise). Diese soll das definierte Framework der Implementierung in der ELGA bilden (siehe beigefügte Passage des Beschlusses der Bundesgesundheitskommission).

DICOM 3.0 und WADO

ISO 12052:2006(E), Health informatics – Digital imaging and communication in medicine (DICOM) including workflow and data management

ISO 17432:2004 (E), Health informatics – Messages and communication – Webaccess to DICOM persistent objects“

Empfehlung der Arbeitsgruppe:

Die ELGA GmbH soll die Machbarkeit und eine einheitliche standardisierte Struktur vorgeben. Die Arbeitsgruppe empfiehlt den Einsatz eines technologischen einheitlichen Bild-Repository-Konzeptes mit WADO in Österreich zu definieren und zu entwickeln.

Wenn Bild-Repositories für ELGA entstehen, sollten diese alle dieselbe internationale standardisierte Technologie benutzen und vorgegeben bekommen. Ein gemeinsames Einsatzgebiet wäre z.B. Mammographie/Zweitmeinungen, also dort, wo noch kein Befund entstanden ist.

Die Erreichbarkeit aller verfügbaren Bilddaten mit derselben Kommunikations- und Zugriffstechnologie ist in Summe für alle Beteiligten billiger, leichter zu realisieren und wesentlich einfacher in der Anwendung und Handhabung.

9.3 Referenzen

[1] HL7 International. / NEMA: Implementation Guide for CDA Release 2: Imaging Integration. Levels 1, 2, and 3. Basic Imaging Reports in CDA and DICOM Diagnostic Imaging Reports (DIR) – Universal Realm; Release 1.0, 2009
(http://www.hl7.org/store)
[2] IHE international: IHE RAD-XDSi.b
(http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Suppl_XDS-I-b_TI_2009-06-21.pdf)
[3] IHE Simple IMAGE and numeric Report (SINR)
(http://wiki.ihe.net/index.php?title=Simple_Image_and_Numeric_Report)
[4] ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.1.6]
http://www.elga.gv.at/cda

9.4 Revisionsliste

Version Datum Änderungsgrund
1.00 06.07.2009 Erste Version des Implementierungsleitfadens.
Veröffentlichtes Ergebnis aus der zweiten ELGA CDA Harmonisierungsphase.
2.00 10.10.2011 Veröffentlichtes Ergebnis aus der dritten ELGA CDA Harmonisierungsphase.
2.01 21.12.2012 Einarbeiten der Kommentare aus dem Ballot.
Redaktionelle Überarbeitung.
2.01a 05.02.2013 Kapitel 2.1.4 und 2.2.4: Akteure MTA/RTA ersetzt durch Biomedizinische AnalytikerInnen / Radiologietechnologinnen
2.01a 07.02.2013 Kapitel 4.4.1.2: XML-Beispiel in Zeile 840 und 841 closing tags korrigiert (</tr>)
2.01a 04.03.2013 Korrekturen in Zeile: 5: ebenso -> sowohl; 6,8 "und" eingefügt; 22: "diesem" eingefügt; ~60: LOINC Erklärung vorgezogen; 22: "sie" gelöscht; 173: "werden" eingefügt; 186: "für" gelöscht; 263, 290: "Innen" jeweils gelöscht; 342; 1023: "Und" eingefügt; 1027: "die" eingefügt; 1142: "Die darin enthaltene Empfehlung" -> "Mit der darin enthaltenen Empfehlung"
Mehrmals im Dokument:
Verweis auf den allgemeinen Leitfaden: "den" eingefügt; title, text, code etc in Tabellen (linke Spalte) kleingeschrieben
Änderungen in Beispielen: Beispiel in 3.1.2.2.2 code war falsch
Änderungen in Tabellen:
Tabelle in 4.3.4.1. Zeile 2 "wurde" eingefügt
Tabelle in 4.4.6.3, Zeile 2 das statt die Addendum
2.01a 08.04.2013 3.3.1.3.2. code@codeSystemName von M auf R2 korrigiert
2.01a 18.04.2013 3.1.2.2. Verweis auf ELGA-Value Sets hinzugefügt.
2.02 05.08.2013 Umbenennung des weiteren Beteiligten „Einweisender/Zuweisender Arzt“ in „Einweisen-der/Zuweisender/Überweisender Arzt“
2.02 09.08.2013 Kap. 3.1.2.3: Der Titel des Befundes kann frei vergeben werden (analog der allgemeinen Vorgaben)
2.02 12.08.2013 4.4.1.4, 4.4.1.5, 4.4.1.6 Konformität der Level-3-codierung von BI-Rads von [M] auf [R2] korrigiert und Kardinalität entsprechend auf 0. angepasst
2.02 12.08.2013 3.3.1.2 und 3.3.1.3.2: Ergänzung beim DisplayName des APPC für automatische Generierung des Textes
2.02 19.08.2013 4.2.2.2. Strukturbeispiel: templateId korrigiert auf 1.2.40.0.34.11.5.2.10
2.02 19.08.2013 4.2.3.2. Strukturbeispiel: templateId korrigiert auf 1.2.40.0.34.11.5.2.3
2.02 19.08.2013 3.1.2.1 TemplateIDs zur Unterscheidung von EIS Basic und EIS Full Support hinzugefügt
2.02 26.08.2013 3.3.1 Definition von serviceEvent.effectiveTime geändert. High und Low-Value müssen unterschiedlich sein.
2.02a 11.02.2014 4.5.3 Sektion „Abschließende Bemerkungen“ explizit erlaubt. Überblickstabelle 4.1.2 entsprechend angepasst.
2.02a 11.02.2014 3.3. DocumentationOf / ServiceEvent: Kardinalität entsprechend Allgemeinen Leitfaden korrigiert
2.02a 18.03.2014 4.4.1.6 EffectiveTime: Datetyp auf TS korrigiert
4.5.1.3.2 EffectiveTime: Datetyp auf TS korrigiert
2.02a 18.03.2014 4.4.1.3 Snippets korrigiert
2.02a 18.03.2014 4.4.1.5 TemplateId 1.2.40.0.34.11.5.3.2 hinzugefügt
2.02a 18.03.2014 4.4.3.3. Spezifikation der Sektion Verdachtsdiagnose Section von [M] auf 0..1 [O] korrigiert (entsprechend Übersicht, Sektion optional)
2.02a 18.03.2014 Korrigierte Strukturbeispiele:
4.3.1.2. Strukturbeispiel templateId root auf 1.2.40.0.34.11.5.2.4
4.3.2.2. Strukturbeispiel templateId root auf 1.2.40.0.34.11.5.2.5
4.3.3.2. Strukturbeispiel templateId root auf 1.2.40.0.34.11.5.2.6
4.3.3.2. Strukturbeispiel templateId root auf 1.2.40.0.34.11.5.2.7
4.4.3.2. Strukturbeispiel templateId root auf 1.2.40.0.34.11.5.2.11
4.4.4.2. Strukturbeispiel templateId root auf 1.2.40.0.34.11.5.2.12
4.4.5.2. Strukturbeispiel templateId root auf 1.2.40.0.34.11.5.2.13
4.4.6.2. Strukturbeispiel templateId root auf 1.2.40.0.34.11.5.2.14
2.02a 26.03.2014 4.4.1.5, 4.4.1.6 Position der TemplateId korrigiert (Kind-Element von Observation)
2.02a 01.07.2014 3.1.2.2.3. Bei clinicalDocument.Code Verweis auf Value Set statt auf Tabelle 1, Tabelle 1: Engl. DisplayName für 18782-3 korrigiert.
2.02a 01.07.2014 4.5.1: Im DICOM Object Catalog wurde die Angabe von Serien von Einzelbildern von [M] auf [R] geändert.
Betroffene Elemente: 4.5.1.3.3. Series Act
4.5.1.3.4. SopInstance (DICOM Service Object Pair)
2.02a 24.07.2014 Typos in Tabellen korrigiert: alle Strukturelemente kleingeschrieben
2.02a 26.08.2014 Dokumenteninformation auf Seite 2 und Hinweise zur Nutzung, Verbindlichkeit, verwendete Grundlagen auf Seite 4 neu erstellt.
2.02a 26.08.2014 4.1.3. WADO: Hinweis zum aktuellen Definitionsstand in ELGA eingefügt.
Version 2.05
2.05 12.03.2014 Seite 4: Formulierung zur Verbindlichkeit aktualisiert
2.05 20.11.2014 2.2 Bei den Anwendungsfällen Hinweis auf Suche im Patientenindex entfernt
2.05 20.11.2014 3.3.1.2. APPC DisplayName im Beispiel verbessert
2.05 20.11.2014 3.3.1.3.4. performer: Korrektur einer fehlenden Verweisquelle
2.05 20.11.2014 Tabelle 1: Geänderte LOINC Dokumenten-Codes korrigiert
2.05 20.11.2014 Typos korrigiert
Version 2.06
2.06 10.09.2015 Buchstabendreher korrigiert für (richtig) POCD_MT000040
2.06 12.10.2015 Neu organisiert: Dokumententeninformation, Harmonisierung, Hinweise zur Nutzung des Leitfadens, Verbindlichkeit, Hinweis auf verwendete Grundlagen, Danksagung, Bedienungshinweise und Inhaltsverzeichnis
2.06 29.09.2015 1.1 Präzisierung der Beschreibung der „bildgebenden Diagnostik“
2.06 29.09.2015 3.1.2.2 Verweis auf den Terminologieserver eingebaut.
2.06 20.06.2015 3.2.2.1.1.1 Konformitäten für rechtlichen Unterzeichner / legalAuthenticator: Präzisiert auf [M] Korrektur der Kardinalität des Fachlichen Ansprechpartners auf 1..1 (nicht 1..*)
2.06 17.06.2015 3.3.1.1. Spezielle Vorgaben für APPC: Beschreibung der "automatischen Codierung" verbessert. ALT: „Eine automatisierte Codierung durch Eintrag des für die Bildgebende Diagnostik entwickelten APPC wird empfohlen.“ NEU: "Für eine benutzerfreundliche Anwendung des APPC wird empfohlen, den APPC möglichst automatisiert aus bestehenden internen Codierungen zu verknüpfen/mappen."
2.06 20.06.2015 4.3.2. Aktuelle Untersuchung: Umsetzung der Strahlenschutzrichtlinie 2013/59/EU Art. 58b: Angabe der Patientendosisinformation ermöglicht (nun mit optionaler Level-3-Codierung)
2.06 29.09.2015 4.2.1.2. Strukturbeispiel Anforderung: TemplateID ist korrekt 1.2.40.0.34.11.5.2.1
2.06 18.09.2015 4.3.2.1 Aktuelle Untersuchung ist [R2], korrigiert auch in Übersichtstabelle 4.1.2
2.06 30.07.2015 4.3.2.2. Strukturbeispiel Aktuelle Untersuchung: verbessert:
2.06 30.07.2015 4.4.1.3. Strukturbeispiel Mammographie mit BI-RADS® Klassifikation: Tabelle korrigiert
2.06 28.10.2015 4.4.1.4. Spezifikation der Sektion Befund: Schreibweise von BI-RADS® mit arabischen Ziffern empfohlen.
Version 2.06.1 (Nebenversion)
x …betrifft Implementierung (erste Spalte)
28.01.2016 3.3.1 ServiceEvents Strukturbeispiel: Datum geändert. High und low müssen unterschiedlich sein.
Version 2.06.2 (Nebenversion)
x …betrifft Implementierung (erste Spalte)
x 16.12.2016 Der DisplayName für Loinc 18748-4 „Diagnostic Imaging Report“ wurde seitens LOINC verändert und daher nun auch im Leitfaden durchgängig auf „Diagnostic imaging study“ nachgezogen. In den Value Sets bereits seit 2014 korrigiert.
01.08.2016 Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
01.08.2016 Kapitel Harmonisierung: Arbeitszeitraum der Arbeitsgruppen hinzugefügt
01.08.2016 3.2.2. Elemente mit speziellen Vorgaben: Kapitel reorganisiert. Präzisierung für legalAuthenticator in eigenem Unterkapitel. 3.2.2.3. Beabsichtigte Empfänger des Dokuments („informationRecipient“) hinzugefügt: Hinweis, dass der Empfänger auch der Patient sein kann.
09.09.2016 3.2.2. Ausnahmen für den „Multidisziplinären Befund“ hinzugefügt.
25.03.2016 4.1.2 Ergänzung der Definition für EIS Basic und Structured
01.08.2016 4.2.3. Indikation: essentieller Bestandteil eines radiologischen Befundes, daher [R2] statt [O]
01.08.2016 4.4.2. Zusammenfassung/Ergebnis: essentieller Bestandteil eines radiologischen Befundes, daher [R2] statt [O]
x 01.09.2016 4.3.2. Aktuelle Untersuchung - Tabelle 3: die Einheit für das Dosisflächenprodukt (DAP) wurde in Abstimmung mit dem BMGF, Mag. Ditto von Gym² auf das üblichere cGycm² korrigiert. Andere Einheiten sind künftig ebenfalls zulässig.
27.04.2016 4.3.2.1 Aktuelle Untersuchung ist [R2], Wiederherstellung der Änderung vom 18.9.2015
02.08.2016 3.3.1.1., 3.3.1.3.2, 4.2.1.1, 4.2.2.1, 4.3.2.1, 4.4.1.1., 4.5.1.1, 4.5.1.3.1, 4.1.2, 4.3.2.4, 4.4.1.4, 4.3.2.1, 4.4.1 Korrektur der Großschreibung bei normativen Vorgaben
03.08.2016 Kapitel 6.1 Hinweise zur Anwendung des APPC hinzugefügt
Version 2.06.3 (Nebenversion)
x …betrifft Implementierung (erste Spalte)
15.07.2021 Kapitel 3.3 verweist anstatt auf die aktuelle Version des Allgemeinen Implementierungsleitfadens für ELGA CDA Dokumente auf dessen Hauptversion 2.
03.03.2021 Kapitel 9.1. "Hinweise zur Anwendung des APPC": Ergänzung, dass der APPC aus 4 Achsen besteht sowie der Hinweis "Die Angabe des APPC "0.0.0.0" - wenn also alle Achsen als "unbestimmt" angegeben werden - ist nicht erwünscht"
Version 2.06.4 (Nebenversion)
x …betrifft Implementierung (erste Spalte)
22.06.2022 Im Template "Aktuelle Untersuchung" 1.2.40.0.34.11.5.2.5 wurde "Eingebettetes Objekt Entry" 1.2.40.0.34.11.1.3.1 hinzugefügt (0..* R)