Arztbrief 2013

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche


Abstimmungsdokument 
Version Datum Status Realm
01 ??.??.2013 Si-draft.svg Entwurf Flag de.svg Deutschland
Document PDF.svg noch kein download verfügbar
Kontributoren 
Logo-Agfa.jpg Agfa HealthCare GmbH Bonn
100px Heitmann Consulting & Services GmbH Hürth
100px Tieto Deutschland GmbH Köln


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Inhaltsverzeichnis

Impressum

Dieser Leitfaden ist im Rahmen des Interoperabilitätsforums und den Technischen Komitees von HL7 Deutschland e. V. sowie der entsprechenden Projektgruppen zusammengestellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums[1] und der Technischen Komitees von HL7 Deutschland e. V. [2]

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Ansprechpartner

  • Dr. Kai U. Heitmann, HL7 Deutschland e.V., Heitmann Consulting and Services
  • Dr. Frank Oemig, Agfa HealthCare GmbH, Bonn
  • Mathias Aschhoff, ZTG GmbH, Bochum
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Disclaimer

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Danksagung

Wir danken besonders den folgenden Organisationen und Projekten.

Bundesverband der Hersteller von IT-Lösungen für das Gesundheitswesen, e.V. , Berlin

bvitg: www.bvitg.de

Logo bvitg.JPG

eBPG-Projekt (electronic Business Plattform im Gesundheitswesen), NRW

Konsortialprojekt eBusiness-Plattform Gesundheitswesen (Förderkennzeichen 005-GW01-038C)

Arbeitspaket AP04: Einrichtungsübergreifende elektronische Patientenakte (eEPA)

Logo ebpg.jpg

Gefördert von der EU und dem Land NRW:

EULogo EFRE neu foerderhinweis 2 081117.jpg NRW Landesregierung RGB.png

Deutscher Hausärzteverband e.V., Köln

DHAEV logo.png

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Autoren

  • Dr. Kai U. Heitmann (KH), Heitmann Consulting and Services, Hürth
  • Dr. Frank Oemig (FO), Agfa HealthCare GmbH, Bonn
  • Daniel Hellmuth (DH), Cerner Deutschland GmbH, Berlin
  • Mathias Aschhoff (MA), ZTG Gmbh, Bochum

Mit Beiträgen von

  • Jürgen Brandstätter, HL7 Austria
  • Dr. Rainer Fehling, Kassenärztliche Vereinigung Westfalen-Lippe
  • Dr. Erich Gehlen, DURIA e.G.
  • Dr. Christof Gessner, gematik
  • Dr. Christian Herrmann, KRH Klinikum Region Hannover
  • Michael Hofer, iSOFT Health GmbH
  • Tarik Idris, InterComponentWare AG
  • Dr. Stefan Sabutsch, HL7 Austria
  • Dr. Norbert Sigmond, DIMDI
  • Prof. Dr. Martin Staemmler, FH-Stralsund
  • Prof. Dr. Sylvia Thun, HS Niederrhein
  • Lars Treinat, ZTG GmbH

Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

Die erste Version dieses Dokumentes wurde 2005 vom Verband der Hersteller von IT für das Gesundheitswesen (VHitG, heute bvitg) entwickelt und ist unter dem Namen "VhitG-Arztbrief" bekannt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.
Der Inhalt dieser Spezifikation ist öffentlich.
Der VHitG-Arztbrief basiert auf den Spezifikationen der Arbeitsgemeinschaft SCIPHOX GbR mbH und dem national adaptierten HL7-Standard der „Clinical Document Architecture (CDA)".

Die hier erarbeitete Fassung ist die Weiterentwicklung davon. Sie ist u.a. auch abgeglichen mit den ELGA-Spezifikationen (http://elga.gov.at) in Österreich.

Näheres unter http://www.hl7.de und http://www.hl7.org. Für alle veröffentlichten Dateien mit einem CDA-Bezug gilt ferner: Alle abgestimmten und veröffentlichten Spezifikationen wie Implementierungsleitfäden, Stylesheets und Beispieldateien sind frei verfügbar und unterliegen keinerlei Einschränkungen, da die Autoren auf alle Rechte, die sich aus der Urheberschaft der Dokumente ableiten lassen, verzichten.

Alle auf nationale Verhältnisse angepassten und veröffentlichten CDA-Schemas können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
Aus der Nutzung ergibt sich kein weiter gehender Anspruch gegenüber dem VHitG bzw. bvitg, zum Beispiel eine Haftung bei etwaigen Schäden, die aus dem Gebrauch der Spezifikationen bzw. der zur Verfügung gestellten Dateien entstehen.


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Einleitung

Motivation

Dieser Leitfaden soll als generische Grundlage für Arztbriefe aller Art dienen und damit die Ablösung der papiergebundenen Arztbriefe ermöglichen. Entsprechende Anwendungsbeispiele finden sich im Anhang dieses Leitfadens und dienten als Grundlage für die Vollständigkeit der Analyse.

Im Rahmen der Kommunikation zwischen Akteuren im Gesundheitswesen ist der Arztbrief als „Kondensat ärztlichen Handelns" von überragender Bedeutung. Das Ziel dieses Dokuments ist die Beschreibung des elektronischen Arztbriefs. Ein derartiger Arztbrief enthält die medizinisch relevanten Teile der Geschichte eines Patienten über einen bestimmten Zeitraum und ist gedacht zur Übermittlung zwischen Gesundheitsdienstleistern (primär: „Leistungserbringer"). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA-Elementen.

Zielgruppe

Der Leserkreis dieses Dokuments sind Software-Entwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld des „Arztbriefs" betraut sind.

Diese Spezifikation definiert zusätzliche Festlegungen, Einschränkungen und Bedingungen für die CDA-Elemente in „Arztbrief"-Dokumenten, die als „stationärer Entlassbrief" von Kliniken im Bereich deutscher Gesetzgebung (SGB) an Niedergelassene (auch: REHA-Einrichtungen) oder als „(Fach ) Arztbrief" vom niedergelassenen (Fach )Arzt an niedergelassene Kollegen oder Krankenhäuser versendet werden sollen.

Beispiele für konforme Dokumenten-Fragmente werden innerhalb dieses Leitfadens aufgeführt. Die Spezifikation von Infrastrukturen, Workflows, Nachrichten, Prozeduren oder Protokollen zur Übermittlung der Arztbriefe ist nicht im Fokus dieses Dokuments.

Ein elektronischer Arztbrief wird vom Gesetzgeber nach §291a ff. SGB V im Rahmen der Einführung der elektronischen Gesundheitskarte als freiwillige Anwendung betrachtet. Es ergeben sich mit Einführung einer nationalen Telematikinfrastruktur verschiedene Vorgaben für einen solchen Arztbrief, die in diesem Implementierleitfaden nicht umfänglich dokumentiert sein sollen. An den nötigen Stellen wird versucht, Hinweise auf relevante Implikationen und Überschneidungen zu geben.

Dokumente im Gesundheitswesen

Wir sind es in der medizinischen Welt gewohnt, eine Dokumentenansicht von medizinischen Beobachtungen zu verfassen, reich an Text, den Zusammenhang des Geschehens zusammenstellend und zusammenfassend. Dieser Kontext – z. B. das Ergebnis einer Laboruntersuchung im Lichte einer speziellen Medikamentenbehandlung – muss dauerhaft erhalten bleiben, da er wichtige medizinische Zusammenhänge zwischen Einzelinformationen darstellt. Die Krönung dieses „in den Kontext stellen" von Informationen über die Zeit stellt zum Beispiel der Arztbrief dar. Gleichzeitig muss der medizinische Inhalt leicht verfügbar sein und ohne große technische Barrieren sichtbar gemacht werden können. Dies ist unabdingbar für die Akzeptanz von und das Vertrauen in Technologie bei den Benutzern, den Ärzten und Pflegekräften. Mit der heutigen Papierwelt wurde dies bis zu einem gewissen Grade erreicht, es muss aber für das Einführen des elektronischen Gegenstücks ebenso gelten. „Interoperabilität" ist unter anderem gekennzeichnet durch gemeinsam verstandene Definitionen, wie zum Beispiel die des Patienten und der zu ihm bekannten (klinischen/medizinischen) Informationen, sowie deren Wiederverwendbarkeit. Hierbei kann man zwei Gegenpole beobachten. Zum einen ist da die Facette der Mensch-zu-Mensch Kommunikation. Dies wird z. B. erreicht durch das Versenden von Papier und Formularen. Jeder weiter führende elektronische Ansatz muss auch diese Art der Interoperabilität gewährleisten. Die Möglichkeit zur Signatur muss auch in elektronischer Form bestehen bleiben. Darüber hinausgehend wäre das andere Ende die Anwendungs-Interoperabilität. Dies beinhaltet die Wiederverwendbarkeit von Informationen, Kontext-abhängige Analysemöglichkeiten und angemessenes Speichern und Verwalten von klinischen Dokumenten.

Im Rahmen der bvitg-Initiative „Intersektorale Kommunikation" wird der Arztbrief als generisches Dokument beschrieben. So wird beispielhaft die Entlassung nach durchgeführter Behandlung in einem Krankenhaus o. ä. zur Weiterbehandlung durch den Niedergelassenen (Dokument „stationärer Entlassungsbrief") definiert, wie auch der ambulante Arztbrief des Facharztes zur Weiterbehandlung über den Hausarzt oder im Krankenhaus.

Im Falle der Entlassung/Ende der Behandlung werden die Behandlungsdaten übermittelt. Der Kurzbericht bei Entlassung/Behandlungsende ist als sofortige Mitteilung an den einweisenden/überweisenden Arzt am Ende der Konsultation/Krankenhausaufenthaltes konzipiert und beinhaltet neben der Patientenidentifikation einen Kurzbericht zusammen mit Diagnosen und Therapien, Befunden sowie eine Zusammenfassung. Beispiel: Termine zur Wiedervorstellung oder Nachsorgetermine.

In einer späteren Ausbaustufe kann mit überwiegend den gleichen Teilen wie im Arztbrief auch die Einweisung/Überweisung definiert werden. Das dahinterliegende Szenario: Der Patient geht vom Niedergelassenen in ein Krankenhaus zur Mitbehandlung (Dokument „Einweisung") bzw. wird von einem Niedergelassenen zum anderen überwiesen (Dokument „Überweisung").

Diese Fälle werden allgemein teilweise von den Komponenten im „Arztbrief" abgedeckt, wie zum Beispiel: Aktuelle Medikation, die auch in Ein-/Überweisungen vorkommen kann. Beim Arztbrief handelt es sich dementsprechend um ein Dokument, das in Anlehnung an die realen Gegebenheiten zwischen den Akteuren und Systemen ausgetauscht wird und das dauerhaft existiert, d.h. es wird dauerhaft gespeichert. Dies steht im Gegensatz zum Austausch von Nachrichten, bei dem der Nachrichten-Inhalt vom Empfangssystem in der Regel extrahiert, in der eigenen Datenbank gespeichert und die Nachricht als solche danach gelöscht wird.

Abgrenzung

Dieser Leitfaden deckt eine Reihe von Themen nicht ab. Dazu gehören:

  • dieser Leitfaden beschreibt den Arztbrief (Discharge summarization note [physician], LOINC-Code 11490-0); andere Dokumententypen wie z. B. OP-Berichte sind hiermit nicht beschrieben (aber dem Prinzip nach gleich aufgebaut).
  • digitale Signatur und andere Sicherheitsaspekte wie Verschlüsselung etc.; der geneigte Leser möge hierzu auch die Ausarbeitung zu XML-Signaturen für CDA (Elektronische Signatur von Arztbriefen)[3] konsultieren.
  • Transport von CDA-Dokumenten
  • Verwendung von Stylesheets

Hilfreich ist in diesem Zusammenhang das IHE-Cookbook[4].

Aufbau dieses Implementierungsleitfadens

Die Spezifikation Arztbrief 2014 basiert auf dem VHitG-Arztbrief von 2006 (v1.5)[5] und berücksichtigt hierbei die neueren Entwicklungen und Methodiken zur Erstellung von Leitfäden, beispielsweise die Nutzung von Templates oder speziellen Ausprägungen von Datentypen.

Dieser Implementierungsleitfaden verfolgt drei Ziele. Neben dem grundlegenden Konzept und dessen Begründung sollen die zugrunde liegenden Modelle ausführlich beschrieben werden, die für die Kommunikation genutzt werden. Aus ihnen leiten sich die Nachrichten/Dokumente in ihrem Aufbau und ihrer Semantik ab. Gleichzeitig können die Modelle Hinweise liefern für den Aufbau von Datenbanken oder Anwendungssystemen, die in diesem Kommunikationsszenario als Sender oder Empfänger fungieren.

Zum dritten soll dieser Leitfaden praktische Implementierungshilfen geben. Dies kann bis zu einem gewissen Detaillierungsgrad geschehen und ist in der Regel mit Beispielen angereichert, so dass ein Programmierer einer Schnittstelle das nötige Wissen erlangen kann, wie die Schnittstelle aufzubauen ist. Auf dieser Basis werden schließlich die tatsächlichen Informationsinhalte beschrieben und die Beziehung an die entsprechenden Klassen und Attribute im Modell aufgezeigt. Daraus folgen dann Dokumente und zugehörige Beispiele.

Zudem sind in diesem Leitfaden einige Anhänge aufgenommen, die als Referenzmaterial dienen können und Hinweise geben für eine erfolgreiche Implementierung.


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Transportaspekte

Interaktionsdiagramm

In diesem Leitfaden geht es um die Präzisierung des Aufbaus von Dokumenten (hier: der Arztbrief), d.h. wie diese inhaltlich strukturiert sind. Die Prinzipien der Gliederung gelten aber auch für andere Arten von Dokumenten wie Ein-/Überweisungen, Befunde, etc.

Im Allgemeinen wird ein CDA-Dokument von einer Anwendung in einem bestimmten Kontext erzeugt und dann als ganzheitliches Objekt übertragen. Dies kann auf unterschiedlichen Wegen passieren (bspw. als Datei, als Binärobjekt in einer Email oder als Objekt einer Akte wie EFA, eEPA oder EGA), diese werden hier aber nicht spezifiziert. Dieses Objekt wird dann letztendlich von einer – oder mehreren – Anwendungen konsumiert:

Interaktionsdiagramm

[Abbildung 1] Interaktionsdiagramm

Dokumentenaustausch

Für den Austausch der Dokumente gibt es mehrere Möglichkeiten, zu denen eine Reihe von konkreten Vorgaben existieren - insbesondere bei IHE ITI -, die hier nur kurz genannt werden sollen:

  • IHE ITI
    • die Integrationsprofile XDS, XDM und XDR
  • Telematikinfrastruktur (in Vorbereitung) mit KOM-LE
  • KV-Connect
  • Safemail
  • FTP
  • ...

Diese Liste ist nicht vollständig und soll nur als Beispiel dienen.

Rechtssichere Übertragung

Eine eAU kann papierbegleitend, aber auch papierersetzend umgesetzt werden. Im letzteren Fall ist diese mit einer rechtssicheren elektronischen Signatur (fortgeschritten oder QES) zu ergänzen:

  • Datenschutz-/-sicherheit
  • IT-Sicherheit
  • Verschlüsselung
  • Signaturen


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Datentypen

Die verschiedenen Templates (Header, Section und Entry) benutzen verschiedene Datentypen in speziellen Ausprägungen. Diese werden nachfolgend kurz aufgelistet. Eine detaillierte Erläuterung findet sich im Wiki unter dem Implementierungsleitfaden zu den Datentypen und den unterstützten Datentypen bei ART-DECOR.

Datentyp DT Ausprägung Erläuterung, Beispiel
Adressen AD hier zu beachten: AD.DE Adresse in Deutschland allgemeine Adresse, Geburtsort
boolesche Werte BL Ja/Nein-Informationen
kodierte Informationen CD
kodierte Informationen CE
kodierte Informationen CR
kodierte Informationen CS.LANG
kodierte Informationen CV
Encapsulated Data ED
Identifikation II
Ganzzahlen INT
nicht-negative Ganzzahlen INT.NONNEG
Zeitintervalle IVL_TS
Namen für Organisationen und Institutionen ON
Namen für Personen PN hier zu beachten: PN.DE Namensnutzung in Deutschland
physikalische Mengenangaben PQ
String mit Codes SC
Text in CDA-Sections SD.TEXT
Zeichenketten ST
Kontaktinformationen TEL Telefon, Telefax und Emailadressen
Zeitpunkte TS Datum und Uhrzeit
Zeitpunkte TS.DATE.MIN mindestens YYYYMMDD
Zeitpunkte TS.DATETIME.MIN mindestens YYYYMMDDhhmmss
URLs URL

[Tabelle 1] CDA Datentypen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

AD (Adresse – Postal Address)

Elemente dieses Datentyps haben eine Substruktur mit verschiedenen Elementen, die in einer Adresse vorkommen können.

Eine Adresse wird in der HL7 Version 3 in einer Serie von Address Name Parts wiedergegeben, beispielsweise Straßenname, Stadt usw.

Im original HL7 Standard ist der Datentyp AD auch als so genannter “mixed content” zugelassen, was bedeutet, dass einige Teile der Daten von einem partType Element umschlossen werden und andere Teile nicht (Mischung aus Text und XML Elementen). Dies ist in Deutschland nicht zugelassen.

Der Datentyp für alle Address Name Parts ist SC. Momentan ist Country das einzige Element, bei dem wir Codes zulassen.

Tabelle: Domäne AddressNamePartType Elementnamen
Element Name Definition
delimiter Trennzeichen [delimiters] werden ohne Leerstellen ausgedruckt [framing]. Wenn keine Wertkomponente geliefert wird, erscheint das Trennzeichen als Zeilenumbruch [line break].
country Das Land, z.B. "Deutschland". Wenn das Land codiert übermittelt wird, geschieht dies konform mit der ISO 3166 Länderkennung mit zwei Buchstaben nach ISO 3166-1 Edition 2 (OID 1.0.3166.1.2.2)
county In Deutschland wird dieses Element benutzt, um die Bundesländer anzugeben (in anderen Ländern kann es sich um eine andere administrative Einheit von Staat/Provinz handeln).
city Der Name einer Stadt, eines Dorfes, eines anderen Wohngebietes oder Zustellzentrums. Bitte beachten: dies ist der Wohnort und nicht die eventuelle Gemeinde, zu der dieser Wohnort gehört. Beispiel: Fleestedt, Gemeinde Hitfeld.
postalCode Eine Postleitzahl, für deutsche Postleitzahlen, ohne Leerzeichen oder vorangestellten Ländercode, #####.
houseNumber Die Nummer eines Gebäudes, Hauses oder Grundstücks an der Straße. Wird auch manchmal “primary street number” genannt. Hierbei wird nicht die Straße nummeriert, sondern das einzelne Haus, und zwar mit der vollständigen Hausnummer, als Adresse für die Postzustellung durch den externen Postboten. Eine alphanumerische Zufügung wie “14a” wird auch bei houseNumber mitgesendet.
streetName Straßenname
streetAddressLine Eine Kombination von Straße und Hausnummer. Dieses Element sollte nur benutzt werden, wenn der Sender Hausnummer und Straße nicht getrennt speichert oder nicht herleiten kann. Der getrennten Angabe von Straße und Hausnummer ist der Vorzug zu geben.
additionalLocator Zusätzliche Standortandeutung als Ergänzung zur Postadresse. Dabei kann es sich um die Bezeichnung einer Wohneinheit (Unit) handeln, wie die Nummer eines Appartements, einer Suite oder einer Etage. Es können mehrere Unit-Bezeichnungen in einer Adresse vorkommen (z.B. “3e Etage, Appartement 342”). Außer einem kleineren Unit innerhalb eines größeren Units kann auch ein abweichender Standort spezifiziert werden, wie beispielsweise “g.ü.” , womit ein gegenüberliegender Standort von Wohnbooten an der Straße angegeben wird.
postBox Eine Postfach-Angabe. Darf nicht in Kombination mit dem PostalAdresUse Code PHYS benutzt werden, da es sich bei einem Postfach nicht um eine Besuchsadresse handelt.

Die Codes für Postadressen werden definiert von der HL7 Domäne PostalAddressUse, angegeben im “use” Attribut des addr Mutterelements (siehe Beispiele).

Tabelle: Domäne PostalAddressUse Attribut-Werte
Code Name Definition
PHYS visit address (Wohn- / Aufenthaltsort) Eine physische Adresse; Wird an erster Stelle benutzt, um den Adressaten zu besuchen. Kann in Deutschland benutzt werden, um eine Adresse durchzugeben, die von der offiziellen Adresse abweicht.
PST postal address (Postanschrift, Postfach) Adresse für die Postzustellung
HP primary home (offizielle Adresse) Die Adresse, die in den offiziellen Registern, z.B. im deutschen Einwohnermeldeamt festgelegt ist; kann maximal ein Mal vorkommen; ist für Personen die primäre Adresse.
HV vacation home (Ferienhaus) Ein Ferienhaus, wo man eine Person im Urlaub erreichen kann.
WP work place (Arbeit) Eine Adresse am Arbeitsplatz. Erste Wahl für arbeitsbezogene Kontakte. Ist für Organisationen und Pflegeanbieter die primäre Adresse.

Für Adressdaten von Patienten sind die Attributwerte HP, WP, PST, PHYS zugelassen, für Organisationen WP, PHYS, PST und für Ärzte WP.

XML-Beispiele

<streetName>An der Garnbleiche</streetName>
<addr>
  <postalCode>52349</postalCode>
</addr>
<addr use="WP"> 	
  <streetName>An der Garnbleiche</streetName>
  <houseNumber>16</houseNumber>
  <postalCode>52349</postalCode>
  <city>Düren</city>
</addr>
<addr use="HP"> 	
  <streetAddressLine>Burgweg 42</streetAddressLine>
  <postalCode>51371</postalCode>
  <city>Leverkusen</city>
</addr>
<addr>
  <country code="DE" codeSystem="1.0.3166.1.2.2">Deutschland</country>
</addr>

Varianten (Flavors)

Der Datentyp AD kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.

Kurzbezeichnung Beschreibung Elemente Datentype/Flavor Kommentar
Volle Adresse alle AD Elemente zugelassen AD
Volle deutsche Adresse alle Teile einer deutschen Adresse (mit useCode) in der richtigen Reihenfolge
  • Strasse (streetName),
  • Hausnummer (houseNumber)
  • PLZ (postalCode)
  • Ort (city)
    Land (country)
AD.DE Adresse mit deutscher Postleitzahl; für Adressen im Ausland ist AD zu nutzen oder die entsprechende Variante des jeweiligen Landes.
Geburtsort Angabe des Geburtsortes, normalerweise ist das lediglich eine Stadt in Deutschland, so dass das Land als Default vorgegeben werden kann
  • Ort (city)
  • Land (country)
AD.DE.BP
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

PN (Personenname – Person Name)

Der Datentyp PN wird verwendet, um den Namen einer Person darzustellen.

Attribute

Lvl Name Desc DT Kard Conf Beschreibung
1 name Name PN 1..1 optional
2 @use Nutzungsart(en) CS 0..1 optional wofür ist diese Namensangabe zu verwenden?
2 validTime Gültigkeitsperiode IVL<TS> 0..1 Optional in welchem Zeitraum ist dieser Name gültig?
2 delimiter Trennzeichen PNXP 0..* Optional zur Kennzeichnung von Trennsymbolen, um eine mixed-content-Darstellung in XML zu vermeiden; Kann an unterschiedlichen Stellen mehrfach vorkommen, beispielsweise zur Trennung von Vor- und Nachnamen
2 prefix Präfix PNXP 0..* Optional
3 @qualifier Qualifier 0..* Optional zur Kennzeichnung von Anreden, Titel, etc.
2 given Vorname(n) PNXP 0..* Optional
3 @qualifier Qualifier 0..* Optional zur Kennzeichnung Geburtsname, Rufname, Initialen, etc.
2 family Nachname PNXP 0..* Optional
3 @qualifier Qualifier 0..* Optional zur Kennzeichnung Geburtsname, Spouse, etc.
2 suffix Suffix PNXP 0..* Optional

Struktur: Der Daten-Typ PN ist eine Extension des Daten-Typs EN (Entity Name) und besitzt folglich einen sogenannten ‘mixed content’, wobei im Prinzip Freitext mit name parts kombiniert werden kann. Für Deutschland gilt, dass die Verwendung von ‘mixed content’ bei Personennamen begrenzt ist. Zugelassen sind:

  • Der vollständige Personenname als Freitext (es gibt also keine person name parts), wenn es dem Sender nicht möglich ist, Teile des Namen zu benennen.
  • Alle Teileinheiten sind als person name part definiert. In einem solchen Fall darf also kein Text vorkommen, der nicht von einem der nachstehend beschriebenen Tags begleitet wird.

XML Beispiele

<name>Jan Meier</name>

Der Name wurde ohne interne Struktur übermittelt.

<name>
	<given>Jan</given>
	<family>Meier</family>
</name>

Die beiden Bestandteile des Namens werden benannt und erhalten einen qualifier: “Jan” ist ein ‘Name, der bei der Geburt gegeben wurde’, bzw. ein Vorname (voll ausgeschrieben). “Meier” ist ein ‘Familienname, der bei der Geburt empfangen wurde’, bzw. der eigene Nachname.

<name>
	Jan <family>Meier</family>
</name>

Dies ist kein gültiger Personenname, da Freitext mit einem name part kombiniert wurde.

@ Attribut DT Card Conf Beschreibung
use CS 0..1 optional Typ der Namenverwendung


Im Prinzip kann von jedem Person Name angegeben werden, in welcher Situation dieser verwendet werden kann. Für Deutschland wurde beschlossen, dass die folgenden Verwendungstypen für Namen zugelassen sind:

Tabelle: Domäne EntityNameUse Attribut Werte
Code Name Definition
L Regulärer Name Der Name, den die Person (Entität) führt. Die Abkürzung ‘L’ stand ursprünglich für Legal (gesetzlich), Tatsache ist aber, dass in dem Namen auch Komponenten vorkommen dürfen (z.B. ein Rufname), die nicht gesetzlich festgelegt sind. Dieser Namenverwendungstyp ist der Default, wenn kein Typ durchgegeben wird.
A Pseudonym Ein Künstlername, ‘Deckname’ oder zeitlicher Name für eine Person (Entität). Dieser weicht also von dem regulär geführten Namen ab und wird z.B. benutzt, um die Identität einer Person zu tarnen (Privacy) oder als temporärer Name, wenn der echte unbekannt ist (‘John Doe’).
OR Gesetzlich registrierter Name Der Name mit den exakten Komponenten, der im Einwohnermeldeamt des betreffenden Landes registriert ist.

XML-Beispiele

Der reguläre Name als default, also kein use Attribut

<name>
	<!-- ... -->
</name>

Ein Pseudonym eines Patienten

<name use="A">
	<!-- ... -->
</name>

Der gesetzlich registrierte Name

<name use="OR">
	<!-- ... -->
</name>

Der geführte Name stimmt exakt mit dem gesetzlich registrierten Namen überein

<name use="OR L">
	<!-- ... -->
</name>
< Element DT Card Conf Beschreibung
validTime IVL_TS 0..1 O Gültigkeitszeitraum


Dies ist ein optionales XML Element innerhalb Person Name, welches die Periode angibt, in der dieser Name für die betreffende Person ‘in Gebrauch’/gültig war. Die Optionen sind:

  • Es gibt kein validTime Element: Der betreffende Name ist im Prinzip unbegrenzt gültig.
  • Es gibt eine Unter- und Obergrenze: Der Name war in der angegebenen Periode gültig.
  • Es gibt nur eine Untergrenze: Der Name ist seit dem angegebenen Datum gültig.
  • Es gibt nur eine Obergrenze: Der Name war bis einschl. angegebenem Datum gültig.

Dieses Element von Person Name kann verwendet werden, um anzugeben, dass im Leben einer Person einmal oder mehrmals eine Namensänderung stattgefunden hat. Dies geschieht u.a bei:

  • Adoption eines Babys, das den Nachnamen der Adoptiveltern erhält.
  • Eheschließung, wobei der Name des Partners an den eigenen Namen angefügt wird.
  • Ehescheidung, wobei ein vorher angenommener Name wieder abgelegt wird.
  • Personen, die aus anderen Gründen ihren Vor- oder Nachnamen ändern.

Zu beachten ist, dass viele Patientenerfassungssysteme keine wirkliche Historie (mit Anfangsdatum) der Patientennamen führen. Wohl wird häufig ein allgemeines ‘audit trail’ (Änderungshistorie) der Patientendaten geführt. Im Bedarfsfall könnte daraus die Historie des Personennamens abgeleitet werden, obwohl es natürlich auch möglich ist, nur den aktuellen Namen durchzugeben (also kein validTime zu verwenden).

Der aktuelle Name ist gültig seit dem 12. Juli 2005

<name>
	<validTime>
		<low value="20050712"/>
	</validTime>
	<!-- ... -->
</name>

Obenstehende Situation kann z.B. bei einem System vorkommen, das nur den aktuellen Namen übermittelt, aber auch die Historie führt. Die oben genannte Person kann z.B. am 12. Juli geheiratet haben und dabei den Namen des Partners angenommen haben.

Alte Namen plus aktueller Name

<name>
  <validTime>
    <high value="19850412"/>
  </validTime>
  <!-- “Nicole de Vries” als Name des Babys vor der Adoption -->
</name>
<name>
  <validTime>
    <low value="19850413"/>
    <high value="20050824"/>
  </validTime>
  <!-- “Nicolette Scheick” als Name nach der Adoption, aber vor Eheschließung -->
</name>
<name>
  <validTime>
    <low value="20050825"/>
  </validTime>
  <!-- “Nicolette Scheick-Jansen” als Name nach der Eheschließung -->
</name>

In vorstehendem Beispiel wird das Baby Nicole de Vries von der Familie Scheick adoptiert, wobei sich also ihr Nachname ändert. Weil den Adoptiveltern dieser Name besser gefällt, wird auch ihr Vorname (oder auf jeden Fall ihr Rufname) geändert in Nicolette. Nach ihrer Eheschließung nimmt sie den Nachnamen ihres Partners (Jansen) an. Das sendende System sendet in diesem Fall die gesamte Namenshistorie mit.

< Element DT Card Conf Beschreibung
delimiter PNXP 0..* O Trennzeichen


Ein delimiter hat keine spezielle Bedeutung als Bestandteil eines Person Name, im Gegensatz zur Übermittlung eines (Stückchens) wörtlichem Text, der in dem geschriebenen Namen vorkommt.

Ein delimiter muss immer an der Stelle in Person Name stehen, an der man auch den Text schreiben würde. Es gibt keine impliziten Leerstellen. Wenn man also normalerweise eine Leerstelle davor oder dahinter schreibt, muss diese explizit angegeben werden.

Beispiele von delimiters in Person Names sind:

  • Der Bindestrich ‘-‘ zwischen dem eigenen Nachnamen und dem Partnernamen (oder umgekehrt).
  • Das Komma plus Leerstelle ‘, ‘ zwischen dem Namen und bestimmten Nachsilben.
  • Der Text ‘, geb. ’ oder ‘, E.v. ‘ (Ehefrau von), der manchmal benutzt wird bei dem eigenen, bzw. Partnernamen.

Diese könnten folgendermaßen in einem Person Name XML Nachrichtenelement benutzt werden:

Trennung zwischen Partnername und Geburtsname

<name>
	<family qualifier=”SP”>Jansen</family>
	<delimiter>-</delimiter>
	<family qualifier=”BR”>Scheick</family>
</name>

Trennung zwischen Nachnamen und akademischem Titel

<name>
	<family>Jansen</family>
	<delimiter>, </delimiter>
	<title qualifier="AC">MSc</family>
</name>

Weitere allgemeine Beispiele finden Sie am Ende dieses Abschnitts.


Einige auf der Hand liegende Fragen (und Antworten) über delimiters:

< Element DT Card Conf Beschreibung
family PNXP 0..* O Nachname


Attribut:

@ Attribut DT Card Conf Beschreibung
qualifier CS 0..1 optional Namensart


Ein person name part des Typen family bezieht sich auf einen Teil des Namens, den eine Person durch Familienbande bekommen hat und der meistens als Nachname bezeichnet wird. Normalerweise bezieht sich dies also auf den eigenen Nachnamen (erhalten von den Eltern) und eventuell auf einen nach einer Heirat angenommenen Nachnamen. (‘übernommen’ vom Partner).

Einige Regeln in Bezug auf person name parts des Typen family:

  • Diese müssen untereinander immer konform mit der offiziellen Schreibweise angeordnet sein (z.B. zuerst der eigene Nachname und dann der Nachname des Partners oder genau umgekehrt).
  • Es gibt immer eine implizite Leerstelle als Zwischenraum mit dem darauf folgenden name part, außer bei einem delimiter oder einem suffix (siehe dort).
  • Die Art des Nachnamens kann weiterhin durch die Verwendung des optionalen Attributs qualifier angegeben werden. Siehe Tabelle für die dabei zugelassenen Werte.
  • Es darf nur ein Familienname pro Qualifier-Typ im Namen vorkommen!
Tabelle: qualifiers bei person name part family
Qualifer Anwendung
BR (birth) Geburtsname. Ein Nachname, den man bei der Geburt erhalten hat. Normalerweise ist dies der Geburtsname eines (natürlichen) Elternteils, aber in einigen Kulturen kann es sich dabei auch um eine Kombination der Geburtsnamen beider Eltern handeln, oder um eine Ableitung des Vornamens eines Elternteils.
CL Rufname. Ein Nachname, mit dem eine Person informell angesprochen wird und der meistens von einem der offiziellen Nachnamen abgeleitet ist.
SP (spouse) Partnername. Ein Nachname, der von einem Partner bei einer Ehe ‘übernommen’ wurde (meistens der Geburtsname eines Partners). Dies sagt nichts aus über das Geschlecht des Namensträgers, da die Annahme von Namen zwischen beiden Partnern in den Deutschland gleichgestellt ist. Auch wenn ein Partnername fehlt, kann daraus keine Schlussfolgerung über den Ehestand gezogen werden, da jemand verheiratet sein kann, ohne den Namen des Partners zu führen. Es ist zu beachten, dass es bei der Verwendung eines Partnernamens nicht nur relevant ist, dass jemand verheiratet ist, sondern vor allem, ob die betreffende Person mit dem Namen des Partners angesprochen werden möchte oder nicht. Die Anwendung des Partnernamens im Personennamen ist unabhängig von einer eventuellen Benennung des Partners als Kontaktperson. In der heutigen deutschen Namensrecht ist nach einer Eheschließung jede Kombination von Eigenname und/oder Partnername von beiden Partnern möglich. Natürlich ist das Geschlecht der beiden Partner dabei nicht relevant.
AD angenommener Name

XML-Beispiele

Jan Meier

<name>
	<given>Jan</given>
	<family qualifier=”BR”>Meier</family>
</name>

Nicolette Jansen-Scheick

<name>
	<given>Nicolette</given>
	<family qualifier=”SP”>Jansen</family>
	<delimiter>-</delimiter>
	<family qualifier=”BR”>Scheick</family>
</name>
< Element DT Card Conf Beschreibung
given PNXP 0..* O Vorname


Attribut:

@ Attribut DT Card Conf Beschreibung
qualifier CS 0..1 optional Namensart


Ein person name part des Typen given bezieht sich auf den Teil des Namens, den eine Person meistens von den Eltern und meistens bei der Geburt erhält. In Deutschland wird dies meistens als Vorname bezeichnet, obwohl dieser nicht in allen Kulturen vor dem Familiennamen steht. Auch Namensbestandteile, die von dem Vornamen abgeleitet sind, z.B. die Initialen (Anfangsbuchstaben) und der Rufname (informeller Vorname) haben den Typ given.

Einige Regeln für person name parts des Typen given:

  • Eine Person kann ohne weiteres mehrere Vornamen oder Initialen haben.
  • Offizielle Vornamen und Initialen müssen immer in der richtigen Sequenz stehen.
  • Es muss immer eine implizite Leerstelle als Zwischenraum zu dem darauf folgenden name part stehen, außer wenn es sich um ein delimiter oder ein suffix handelt (siehe dort).
  • Die Datenart des gegebenen Namens kann zudem angedeutet werden, indem das optionale Attribut qualifier benutzt wird. Siehe Tabelle für die dabei zugelassenen Werte.
Tabelle: qualifiers bei person name part given
Qualifer Anwendung
BR Offizieller Vorname. Ein Vorname, der meistens bei der Geburt gegeben ist (meistens von den Eltern) und der offiziell registriert ist. Vornamen müssen voll ausgeschrieben werden und in der richtigen Sequenz stehen. Wenn eine Person mehrere Vornamen hat, muss auf jeden Fall der erste Name übermittelt werden (Die ausschließliche Benutzung des ersten Vornamens ist also zugelassen, die ausschließliche Benutzung des zweiten Vornamens dagegen nicht). Wenn es mehrere Vornamen gibt, können diese sowohl als separate given Elemente, als auch in einem Element (getrennt durch Leerstellen) übermittelt werden. Es kommt auch vor, dass der erste Vorname voll ausgeschrieben in Kombination mit den Initialen benutzt wird.
CL Rufname. Ein Vorname, mit dem eine Person informell angesprochen wird und der meistens von einem der offiziellen Vornamen abgeleitet ist. Im Gegensatz zu den offiziellen Vornamen kann ein Rufname im Leben einer Person ohne weiteres variieren. Eine Person kann sogar mehrere Rufnamen gleichzeitig haben, je nachdem wie Menschen die Person kennen. In diesem Fall muss der am meisten zutreffende Rufname gesendet werden.
SP Initialen. Meistens eine Abkürzung des Vornamens. Dabei kann es sich um einen einzigen oder um mehrere Buchstaben handeln (z.B. ‘Th.’ für Thomas). Ein abschließender Punkt muss explizit angegeben werden. Initialen müssen in der korrekten Sequenz angegeben werden. Wenn es mehrere Initialen gibt, können diese sowohl als separate given Elemente, als auch in einem Element (getrennt durch Punkte) übermittelt werden. Der Vorteil dieser Methode ist, dass keine Leerstellen zwischen den einzelnen Initialen im Namen impliziert werden.

XML-Beispiele

Hans Jansen, ohne qualifier

<name>
	<given>Hans</given>
	<family>Jansen</family>
</name>

Johannes Theodorus Cornelis Jansen, offizielle Vornamen

<name>
	<given qualifier=”BR”>Johannes Theodorus Cornelis</given>
	<family>Jansen</family>
</name>

Johannes Theodorus Cornelis Jansen, mit Rufname Hans

<name>
	<given qualifier=”BR”>Johannes Theodorus Cornelis</given>
	<given qualifier=”CL”>Hans</given>
	<family>Jansen</family>
</name>

Johannes Th. C. Jansen, ohne Duplizierung des Anfangsbuchstabens ‘J’

<name>
	<given qualifier=”BR”>Johannes</given>
	<given qualifier=”IN”>Th.C.</given>
	<family>Jansen</family>
</name>

Kai Uwe Heitmann, Kai ist sowohl offizieller Name als auch Rufname

<name>
	<given qualifier=”BR CL”>Kai</given>
	<given qualifier=”BR”>Uwe</given>
	<family>Heitmann</family>
</name>

Das Fazit dieser Beispiele ist, dass diverse Kombinationen von offiziellen Vornamen, Rufnamen und Initialen möglich sind, abhängig von den Speicher- und Kommunikations-kapazitäten des sendenden Systems. Die Bedeutung der einzelnen Bestandteile muss allerdings deutlich sein.

< Element DT Card Conf Beschreibung
prefix PNXP 0..* O Präfix


Attribute:

@ Attribut DT Card Conf Beschreibung
code SC 0..1 optional Titelcode


@ Attribut DT Card Conf Beschreibung
qualifier CS 0..1 optional Namensart


Ein person name part des Typen prefix bezieht sich auf einen Teil des Namens, der zu einem oder mehreren anderen Namensbestandteilen gehört und vorne angehängt wird. Im Prinzip gibt es zwei Arten von Vorsilben, nämlich Vorsilben zu Nachnamen und zu Titeln/akademischen Graden (die als Zufügung zum geschriebenen Namen aufgenommen werden).

Einige Regeln für person name parts des Typen prefix:

  • Ein prefix muss immer direkt vor die Namensbestandteile platziert werden, auf die es sich bezieht (d.h. wo es normalerweise geschrieben wird).
  • Es gibt keine implizite Leerstelle als Zwischenraum zu dem darauf folgenden name part, d.h. eine Leerstelle nach der Vorsilbe muss explizit im Text angegeben werden!

Die Art der Vorsilbe kann zudem angedeutet werden, indem man das optionale Attribut qualifier benutzt. Siehe Tabelle für die dabei zugelassenen Werte.

Tabelle: qualifiers bei person name part prefix
Qualifer Anwendung
VV Vorsilbe zu Nachnamen. Dabei handelt es sich um Namensbestandteile wie “von“, “den“, und “zu“, aber auch um Kombinationen wie “von der“ usw. Eine Vorsilbe gehört immer zum person name part des Typen family , der immer direkt dahinter steht (siehe die XML Beispiele). Eine Vorsilbe kann als Bestandteil des Nachnamen aufgenommen werden, aber es ist gebräuchlich, sie einzeln zu speichern (und zu versenden), da Sortierungen (und daher auch das Zurücksuchen) immer auf Nachnamen ohne Vorsilbe stattfinden.
AC Akademischer Grad. Ein Grad (meistens in abgekürzter Form) den jemand aufgrund der Vollendung eines wissenschaftlichen Studiums oder eines anderen Studiums erworben hat, z.B.: “Dr.“, “Dipl.-Ing.“, “Ing.“, “Hr.“, “Dr.“, “Prof.“, aber auch “Prof. Dr.“, „Prof. Dr. med.“.
NB Adelstitel. Ein Titel (meistens voll ausgeschrieben) der auf dem aristokratischen Status einer Person gründet. Beispiele sind “Baron“, “Graf“, usw.
TITLE Allgemeine Anrede (nicht Titel). Diese wird im Prinzip als Anrede zu einem vollständigen Namen (als Briefanrede) verwendet, z.B. “Sehr geehrte Herr” , “Sehr geehrte Frau“, aber auch einfach “Frau“. Die Art einer solchen Anrede hängt also mit dem Geschlecht der Person und dem eventuellen akademischen Grad und/oder Adelstitel ab (mit Hilfe von Ableitungsregeln).

XML Beispiele

Monique van Wijk

<name>
	<given>Monique</given>
	<prefix qualifier=”VV”>van </prefix>
	<family>Wijk</family>
</name>

Dr. Kai Heitmann

<name>
	<prefix qualifier=”AC”>Dr. </prefix>
	<given>Kai</given>
	<family>Heitmann</family>
</name>

In diesem Fall lautet die Regel also, dass der Grad (‘Dr.‘) vor dem kompletten Namen positioniert wird, weil dies die normale Schreibweise ist.

Berend-Jan Baron von Fürst zu Fürst

<name>
	<given>Berend-Jan</given>
	<prefix qualifier=”NB”>Baron </prefix>
	<prefix qualifier=”VV”>von </prefix>
	<family>Fürst zu Fürst</family>
</name>

In diesem (realen) Beispiel steht der Titel (‘Baron‘) zwischen dem Vornamen und dem Nachnamen, da dies die gebräuchliche Schreibweise ist. Zudem steht eine ‘normale’ Vorsilbe vor dem Nachnamen (‘von‘). Übrigens wird die Software häufig nicht in der Lage sein, einen (einzeln gespeicherten) Titel an die richtige Stelle zu setzen, wodurch ‘Baron‘ auch vornan landen kann.

Sehr geehrter Herr Dr. Frank Düren

<name>
	<prefix qualifier=”TITLE”>Sehr geehrter Herr </prefix>
	<prefix qualifier=”AC”>Dr. </prefix>
	<given>Frank</given>
	<family>Düren</family>
</name>

In diesem Beispiel hat das versendende System offensichtlich den vollständigen Titel festgelegt (oder vom Titel ableitet) und als Teil des ‘Korrespondenznamen’ übermittelt. Aber auch ohne Titel kann das versendende System eine allgemeine Anrede mitsenden (siehe nachstehend).

Frau A. Jansen

<name>
	<prefix qualifier=”TITLE”>Frau </prefix>
	<given>A.</given>
	<family>Jansen</family>
</name>
< Element DT Card Conf Beschreibung
suffix PNXP 0..* O Suffix


Attribut:

@ Attribut DT Card Conf Beschreibung
code= SC 0..1 optional Titelscode


@ Attribut DT Card Conf Beschreibung
qualifier CS 0..1 optional Namensart


Ein person name part des Typen suffix bezieht sich auf einen Teil des Namens, der zu einem oder mehreren anderen Namensbestandteilen gehört und hinten angehängt wird. In Deutschland sind Nachsilben ausschließlich bei akademischen Graden zugelassen. Einige Regeln für person name parts des Typen suffix:

  • Ein suffix muss immer direkt hinter die Namensbestandteile positioniert werden, auf die es sich bezieht (d.h. wo es normalerweise steht).
  • Es gibt keine implizite Leerstelle als Zwischenraum zu dem davor stehenden name part, d.h. eine Leerstelle vor der Nachsilbe muss explizit angegeben werden!

Die Art der Nachsilbe kann ferner angegeben werden durch die Anwendung des optionalen Attributs qualifier. Siehe die Tabelle für die dabei zugelassenen Werte.

Tabelle: qualifiers bei person name part suffix
Qualifier Anwendung
AC Akademische Grade. Ein Grad (meistens in abgekürzter Form) den jemand aufgrund der Vollendung eines wissenschaftlichen Studiums oder eines anderen Studiums erworben hat. Bei Nachsilben handelt es sich dabei meistens um internationale Termen wie “MSc”, “PhD” oder “MD”.

XML-Beispiele

Ronald Cornet, MSc

<name>
	<given>Ronald</given>
	<family>Cornet</family>
	<delimiter>,</delimiter>
	<suffix qualifier=”AC”>MSc</suffix>
</name>

Varianten (Flavors, Templates)

Der Datentyp PN kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.

Kurzbezeichnung Beschreibung Datentype/Flavor
voller Name alle Elemente sind zugelassen PN
Standard voller Name mit Anrede, Titel, Vor- und Nachname sowie Geburtsname

Dies entspricht am ehesten dem "legal Name".

PN.DE
förmliche Anrede Zur Darstellung auf Briefumschlägen etc. PN.DE.FORM
Anrede in Briefen Wie soll die Person in Briefen angeredet werden?

"Lieber Hans" anstelle von "Herr Dr. Meier"

PN.DE.LETTER
pseudonymisiert Anstelle des "echten" Namens wird ein Pseudonym übermittelt, das mit Hilfe einer trusted third party ermittelt/festgelegt worden ist. PN.DE.PSEUDONYM
anonymisiert ohne verwertbare Namensinformation PN.DE.ANONYM
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

ON (Organisationsname – Organization Name)

Definition: Ein Name einer Organisation.

Attribut:

@ Attribut DT Card Conf Beschreibung
use SET<CS> Benutzertype(n), nicht verwenden in DE


Element:

< Element DT Card Conf Beschreibung
validTime IVL<TS> 0..* O Gültigkeitszeitraum


Struktur:

Der Datentyp ON ist eine Extension des Datentyps EN (Entity Name) und besteht demnach aus dem so genannten ‘mixed content’ Inhalt, in dem im Prinzip name parts angegeben werden können. Für Deutschland wurde vorläufig abgesprochen, keine organization name parts zu verwenden und den Namen immer als ein Text auszudrucken. Das heißt, dass ON in Deutschland faktisch identisch wird mit dem Datentyp TN (Trivial Name).

XML-Beispiel

minimal

<name>Universität zu Köln</name>

Beachten Sie, dass der Text des Namens ohne Anführungszeichen übermittelt wird.

@ Attribut DT Card Conf Beschreibung
use Benutzungstype(n)

Im Prinzip kann von jedem Organization Name angegeben werden, in welcher Situation dieser benutzt werden kann. Für Deutschland wurde aber beschlossen, dass der Unterschied (noch) nicht relevant ist, so dass die Empfehlung lautet, das Attribut use nicht im XML-Tag zu benutzen.

@ Attribut DT Card Conf Beschreibung
validTime Gültigkeitszeitraum

Dies ist ein optionales XML Element in Organization Name, das die Periode angibt, in der dieser Name für die betreffende Organisation ‘in Gebrauch’/gültig war. Die Optionen sind:

  • Es gibt kein validTime Element: Der betreffende Name ist im Prinzip universell gültig.
  • Es gibt eine Unter- und Obergrenze: Der Name war in der angegebenen Periode gültig.
  • Es gibt nur eine Untergrenze: Der Name ist seit dem angegebenen Datum gültig.
  • Es gibt nur eine Obergrenze: Der Name war bis einschließlich dem angegebenen Datum gültig.

XML-Beispiele

Unter- und Obergrenze: Der Name war gültig vom 1.1.2003 bis vor dem 31.12.2004.

<name>
    <validTime>
        <low value="20030101"/>
        <high value="20041231"/>
    </validTime>
    Medizinische Einrichtungen der Universität zu Köln
    <!-- der alte Name der Organisation -->
</name>

Nur Untergrenze: Der Name ist gültig seit dem 13.1.2005.

<name>
    <validTime>
        <low value="20050113"/>
    </validTime>
    Klinikum der Universität zu Köln
</name>

Nur Obergrenze: Der Name ist gültig bis zum (und ausschließlich dem) 31.12.2005.

<name>
    <validTime>
        <high value="20051231"/>
    </validTime>
    Medizinische Einrichtungen der Universität zu Köln
</name>

Sowohl die Untergrenze als auch die Obergrenze von validTime können in der Zukunft liegen, um einen geplanten neuen Namen oder ein geplantes Verfallsdatum für einen bestehenden Namens anzugeben.

Wiederholter Name

<name>
    <validTime> 
        <high value="20041231"/>
    </validTime>
    Altorganisation
</name>
<name>
    <validTime>
        <low value="20050101"/>
        <high value="20091231"/>
    </validTime>
    Jetzorganisation
</name>
<name>
    <validTime>
        <low value="20100101"/>
    </validTime>
    Zukunftsorganisation
</name>
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

TEL (Telekommunikationskontakt – Telecommunication Address)

Es gibt keinen separaten Datentyp für Telefonnummern. Dies sind lediglich die URLs, die sich auf Telekommunikationsanlagen beziehen.

Details über die Definition von Telefonnummern sind definiert in den Internet “RFC 2806 [1] URLs for Telephone Calls”. Beispielsweise ist “tel:+49(221)6754-63” eine Telefonnummer und “fax:+49(221)6571412-3” eine Faxnummer. Es wird bevorzugt, die globalen, absoluten Telefonnummern mit einem “+” und der Länderkennung anzugeben. Trennungszeichen können hinzugefügt werden (zur besseren Lesbarkeit) haben aber keine Bedeutung für die Nummern. “tel:+49221675463” und “fax:+4922165714123” sind also identisch mit den vor-stehenden Beispielen.

Die Nummern müssen im Falle von internationalen Telefonnummern mit einem „+“ beginnen. Die Angaben dürfen nur Ziffernzeichen 0 bis 9 nutzen sowie als visuelle Separatorzeichen nur Bindestrich –, Punkte . oder Klammern ( ) verwenden.

Elemente mit diesem Datentype haben ein Attribut,

@ Attribut DT Card Conf Beschreibung
value TEL 0..1 opt Wert

das verschiedene Zeichenkombinationen enthalten kann, die Telekommunikations-kontakte wie Telefon (tel:), Fax (fax:), E-Mail (mailto:) usw. wiedergeben.


Zugelassene Werteliste für das Prefix im @value Attribut:
Präfix Definition
tel: Telefonnummer
fax: Faxnummer
mailto: Email-Adresse (gemäß [RFC 2368])
http: Internet-Adresse
@ Attribut DT Card Conf Beschreibung
use cs 0..1 opt Benutzungshinweis

Mit diesem use Attribut können einer oder mehrere Codes angegeben werden, um für ein System oder einen Benutzer den besten Telekommunikationskontakt für den jeweiligen Zweck anzudeuten.

Tabelle Domäne TelecommunicationAddressUse Attribut Werte:
Code Name Definition
HP primary tel (Wohn- / Aufenthaltsadresse) Der primäre Telekommunikationskontakt um eine Person zu erreichen; kann maximal ein Mal vorkommen.
HV vacation tel (Urlaubs- Telekommunikationskontakt) Ein Ferienhaus, wo eine Person im Urlaub zu erreichen ist.
WP work place (Arbeit) Ein Telekommunikationskontakt am Arbeitsplatz. Erste Wahl für arbeitsbezogene Kontakte. Ist für Organisationen und Leistungsanbieter der primäre Telekommunikationskontakt.
AS Beantwortungsservice Eine Person oder ein Service zum Hinterlassen von Nachrichten.
EC Notfallkontakt Ein Telekommunikationskontakt für Notfälle.
PG Pager Ein Pager (Funkmeldeempfänger) mit dem man um einen Rückruf fragen oder eine kurze Nachricht hinterlassen kann.
MC Mobilkontakt Ein Handy oder ein Gerät, das der Besitzer immer bei sich trägt, darf andere use Codes enthalten.
@ Attribut DT Card Conf Beschreibung
usabalePeriod TS 0..1 opt Gültigkeitsdauer

Es ist möglich, die Gültigkeitsdauer eines Telekommunikationskontakts zu begrenzen. Das Element usablePeriod kann zur Angabe eines Zeitintervalls benutzt werden.

XML-Beispiel

<telecom value="tel:+49.40.4765342"/>

<telecom value="mailto:dialyse@centrum-hamburg.de"/>

Varianten (Flavors, Templates)

Der Datentyp TEL kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.

Kurzbezeichnung Beschreibung Datentype/Flavor
??


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Struktureller Aufbau

Das statische Modell umfasst

  • Die zentrale Klasse ClinicalDocument und den Header mit einer Reihe von assozierten Header-Klassen (Patient, Autor, Empfänger, etc.) und
  • den CDA-Body mit Section und Entries.

Grober XML-Aufbau von CDA-Dokumenten

Der XML-Namespace für CDA Release 2 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser muss in geeigneter Weise in jeder XML Instanz genannt werden. In diesem Leitfaden werden typischerweise keine namespace-Präfixe (z. B. "hl7:" oder "cda:") genutzt (Verwendung von default namespace), die Ausgaben der Templates aus ART-DECOR verwenden das Präfix "hl7:".

Für die Arztbrief XML-Dokumente auf der Basis von CDA Release 2 ist der Zeichensatz UTF-8 vorgeschrieben. Arztbrief XML-Dokumente beginnen mit dem Wurzelelement ClinicalDocument, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.

<?xml version="1.0"? encoding="UTF-8">
<ClinicalDocument
    xmlns="urn:hl7-org:v3"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
    <!-- CDA Header -->
               siehe Beschreibung CDA R2 Header
    <!-- CDA Body -->
    <component>
        <structuredBody>
               siehe Beschreibung CDA R2 Body
        </structuredBody>
    </component>
</ClinicalDocument>


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Dokumentenstruktur Arztbrief

Ein Arztbrief - wie andere Dokumente auch - setzt sich aus verschiedenen Teilen zusammen.

  • die Attribute der CDA-Klasse
  • Informationen über die verschiedenen Beteiligten an einem Dokument wie Patient, Autor, Unterzeichner etc.
  • Informationen über Aktivitäten, die in Zusammenhang mit dem Dokument stehen.

Attribute der CDA-Klasse

Die folgende Tabelle gibt eine Übersicht über die in diesem Leitfaden besprochenen CDA-Header-Elemente, deren Datentyp und Bedeutung. Details und weitere Erläuterungen find sich aber der Beschreibung des Dokumenten-Level-Template.

Name DT Beschreibung
realmCode CS Hoheitsangabe, d.h. wo dieser Dokumenttyp eingesetzt werden soll, hier in der Regel "DE"
templateId II Angabe, nach welchem Schema das Dokument erstellt wurde
typeId II Angabe, dass es sich um ein CDA-Dokument handelt
id II eindeutige Identifikation des Dokuments
code CE Typ des Dokuments
title ST Titel bzw. Bezeichnung des Dokuments
effectiveTime TS Erstellungszeitpunkt
confidentialityCode CE Vertraulichkeit
languageCode CS Sprache des Dokuments
setId II Set-Kennung
versionNumber INT Versionsnummer

[Tabelle 2] Übersicht über die (in diesem Leitfaden besprochenen) CDA-Header-Elemente, deren Datentyp bzw. Bedeutung und deren Kardinalität

Beispiel
<?xml version="1.0"? encoding="UTF-8">
<ClinicalDocument
  xmlns="urn:hl7-org:v3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <!-- CDA Header -->
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
  <id extension="60878,33988" root="1.2.276.0.58"/>
  <code code="11488-4" codeSystem="2.16.840.1.113883.6.1" displayName="Consultation note"/>
  <title>Entlassbrief</title>
  <effectiveTime value="20070905"/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
  <languageCode code="de" />
  <setId extension="D1" root="2.16.840.1.113883.3.933"/>
  <versionNumber value="2"/>
  ...
</ClinicalDocument>

Informationen über die verschiedenen Beteiligten und Aktivitäten, die in Zusammenhang mit dem Dokument stehen

Die folgende Tabelle zeigt die Informationen über die verschiedenen Beteiligten und Aktivitäten, die in Zusammenhang mit dem Dokument stehen. Aufgenommen in der Tabelle sind auch Referenzen zu den Definitionen der ELGA (Österreich), die mitunter kein direktes Äquivalent haben und dann unter einem Oberbegriff geführt werden.

Abschnitt Conf. Kardinalität Kommentar
Header (über Rollen)
Patient (recordTarget) M 1..1
Autor (Person) (author) M 1..1 das Autor Element darf nur für natürliche Personen verwendet werden, nicht für Informationssysteme oder medizin-technische Geräte
Datentypist (dataEnterer) O 0..1
Informant (informant) O 0..*
die das Dokument verwaltende Organisation ( custodian) M 1..1
Empfänger (informationRecipient) O 0..*
vor dem Gesetz verantwortliche Unterzeichner (legalAuthenticator) O 0..1 Hier darf es nur eine juristisch verantwortliche Person geben.
Unterzeichner (authenticator) O 0..* Einen Brief dürfen aber mehrere Personen unterzeichnen.
einweisender Arzt O 0..1
Hausarzt O 0..1
Notfallkontakt O 0..*
Angehörige O 0..*
Kostenträger , Versicherung O 0..*
Fachlicher Ansprechpartner O 0..*
Betreuungsorganisation O 0..*
Weitere Beteiligte (generisch) - -
Header (über Act-Relationships)
Patientenkontakt (EncompassingEncounter) O 0..1
Einwilligung O 0..* wozu hat der Patient eingewilligt?
unstrukturierter Body (d.h. ohne Abschnitte)
NonXML-Body O 0..1
strukturierter Body (d.h. Abschnitte)
Anrede O 0..1 ELGA: Brieftext
Fragestellung O 0..1 ELGA: Aufnahmegrund
Anamnese O 0..1 ELGA: Anamnese (ärztlich)
Schwangerschaften O 0..1
Familienanamnese O 0..1
frühere Erkrankungen O 0..1 ELGA: frühere Erkrankungen
Medizinische Untersuchung O 0..1 klinische (körperliche) oder apparative Untersuchung
Befund O 0..* ELGA: Erhobene Befunde
Laborwerte O 0..1
Diagnosen (Aufnahme/Entlassung) mit ICD Code O 0..*
Diagnosen (Aufnahme/Entlassung) ELGA: Diagnose bei Entlassung
besondere Hinweise (CAVE)

(zu beachtende wichtige Hinweise zum Patienten)

O 0..*
besondere Hinweise O 0..* ELGA: Allergien, Unverträglichkeiten, Risiken
Prozeduren und Maßnahmen O 0..* ELGA: Weitere Maßnahmen
ELGA: Durchgeführte Maßnahmen
Medikation (abstrakte Spezifikation) - - Dies ist die vollständige Beschreibung, die für die nachfolgend beschriebenen Abschnitte weiter eingeschränkt wird.
jetzige Medikation O 0..1 ELGA: Letzte Medikation
empfohlene Medikation ELGA: Empfohlene Medikation
Medikation bei Aufnahme O 0..1 ELGA: Medikation bei Einweisung
Medikation bei Entlassung O ELGA: "Verabreichte Medikation während des Aufenthalts|
Impfung O 0..1
Notiz O 0..*
Epikrise
  • Zusammenfassender Rückblick
  • Empfehlung
  • Prognose
O 0..1 ELGA: Zusammenfassung des Aufenthalts; Epikrise streichen und durch die Details ersetzen; Plan of Care
Schlusstext O 0..1 ELGA: Abschließende Bemerkungen
Anhänge:
Referenzen auf externe Dokumente oder direkt inkludierte Objekte
O 0..* ELGA: Beilagen

Das Entry-Level-Template für externe Referenzen ist dafür gedacht, einzelne Aktivitäten (bspw. Befunde oder Maßnahmen) mit Dokumenten zu belegen.
Beilagen gemäß ELGA-Spezifikation müssen in das Dokument eingebettet sein und dürfen nicht referenziert werden.

ELGA: Patientenverfügung (als Referenz auf die Patienteneinwilligung)

[Tabelle 3]Informationen über die verschiedenen Beteiligten und Aktivitäten

Ein Arztbrief kann somit entweder in einem Binärformat als PDF o.ä. Dokument oder XML-formatiert übermittelt werden, und sich entweder ohne Strukturvorgabe oder aus strukturierten Abschnitten zusammensetzen.


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

CDA-Header-Assoziationen

Der Header umfasst neben bereits aufgelisteten einfachen Metadaten noch folgende Beziehungen, diese sind hier der Übersicht halber aufgelistet. Die Verwendung im Arztbrief wird unter Arztbriefstruktur aufgelistet und deren genauen Details später noch genauer spezifiziert.

CDA-Header-Assoziationen
Element (Sequenz) Bedeutung
Participations
recordTarget Patient
author Autor / Urheber
dataEnterer Datentypist
informant Informant
custodian verwaltende Organisation
informationRecipient Empfänger
legalAuthenticator vor dem Gesetz verantwortlicher Unterzeichner
authenticator weitere Unterzeichner
participant Beteiligte
Act Relationships
inFulfillmentOf In Erfüllung von, –noch nicht verwendet–
documentationOf Dokumentierte Gesundheitsdienstleistung, –noch nicht verwendet–
relatedDocument Bezug zu vorhergehenden Dokumenten
authorization Einverständniserklärung
componentOf Informationen zum Patientenkontakt

[Tabelle 4] CDA-Header-Assoziationen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Patient (recordTarget - generisch)

Id1.2.276.0.76.10.2001Gültigkeit2013‑07‑10
StatusKgreen.png AktivVersions-Label
NameHeader​Record​TargetBezeichnungCDA recordTarget
Beschreibung
Das recordTarget repräsentiert die Person, über die dokumentiert wird. recordTarget umfasst neben der Identifikation und dem Namen, Geschlecht, Adressen etc. auch optionale Zusatzangaben wie zum Beispiel Geburtsort und Sprachfähigkeiten.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.90030InklusionKgreen.png PersonennameDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.101 CDA recordTarget (DYNAMIC)
ref
ad1bbr-
Beispiel
Standard-Beispiel
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>    <addr use="HP">
      <streetName>Musterstraße</streetName>      <houseNumber>15</houseNumber>      <postalCode>50825</postalCode>      <city>Köln</city>    </addr>
    <telecom use="HP" value="tel:+49(221)7812220"/>    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>
      <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19700924"/>      <birthplace>
        <place>
          <addr>
            <city>Köln</city>          </addr>
        </place>
      </birthplace>
    </patient>
  </patientRole>
</recordTarget>
Beispiel
Maximal-Beispiel
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>    <id root="1.2.276.0.76.4.8" extension="8003004447"/>    <addr use="HP">
      <streetName>Musterstraße</streetName>      <houseNumber>15</houseNumber>      <postalCode>50825</postalCode>      <city>Köln</city>    </addr>
    <telecom use="HP" value="tel:+49(221)7812220"/>    <telecom use="HP" value="mailto:MuellerMar@gmx.de"/>    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>
      <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19700924"/>      <!-- Familienstand des Patienten -->
      <maritalStatusCode code="M" displayName="Married" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7 MaritalStatusCode"/>      <!-- Religionszugehörigkeit des Patienten-->
      <religiousAffiliationCode code="1077" displayName="Protestant" codeSystem="2.16.840.1.113883.5.1076"/>      <!-- Vormund/Sachwalter des Patienten -->
      <guardian>
        <addr use="HP">
          <streetName>Musterstraße</streetName>          <houseNumber>15</houseNumber>          <postalCode>50825</postalCode>          <city>Köln</city>        </addr>
        <telecom use="HP" value="..."/>        <guardianPerson>
          <name>
            <given>Marius</given>            <family>Müller</family>          </name>
        </guardianPerson>
      </guardian>
      <birthplace>
        <place>
          <addr>
            <city>Köln</city>          </addr>
        </place>
      </birthplace>
      <languageCommunication>
        <languageCode code="EN"/>        <modeCode code="ESP"/>        <proficiencyLevelCode code="G"/>        <preferenceInd value="true"/>      </languageCommunication>
    </patient>
  </patientRole>
</recordTarget>
Beispiel
Minimal-Beispiel
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>  </patientRole>
</recordTarget>
ItemDTKardKonfBeschreibungLabel
hl7:recordTarget
(Hea...get)
Treetree.png@typeCode
0 … 1FRCT
Treetree.png@context​Control​Code
0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treetree.pnghl7:patientRole
1 … 1(Hea...get)
Treeblank.pngTreetree.png@classCode
0 … 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>
Treeblank.pngTreetree.pnghl7:id
II1 … *(Hea...get)
 Beispiel<id extension="6245" root="2.16.840.1.113883.3.933"/><id extension="1543627549" root="1.2.276.0.76.4.1"/>
Treeblank.pngTreetree.pnghl7:addr
AD0 … *Adresse des Patienten(Hea...get)
 Beispiel<addr use="HP">
  <streetName>Dorfstraße</streetName>  <houseNumber>54</houseNumber>  <postalCode>51371</postalCode>  <city>Leverkusen</city></addr>
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *Kontaktdaten des Patienten(Hea...get)
 Beispiel<telecom use="H" value="tel:+4930140400"/><telecom use="MC" value="tel:+492211234567"/><telecom value="mailto:herberthannes.mustermann@provider.de"/>
Treeblank.pngTreetree.pnghl7:patient
0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
 Beispiel<patient classCode="PSN" determinerCode="INSTANCE">
  <name>
    <!-- ... -->
  </name>
  <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>  <birthTime value="19541223"/></patient>
Eingefügt1 … 1M von 1.2.276.0.76.10.90030 Personenname (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1MDie Reihenfolge der Namensbestandteile soll der typischen Schreibweise entsprechen. Zu beachten ist, dass prefix- und suffix-Elemente mit einem Leerzeichen enden müssen, wenn sie nicht unmittelbar an den folgenden Namensbestandteil anschließen sollen.
(Hea...get)
 Beispiel
Dr. med. Sine Johanna Gräfin von Oberberg
<name>
  <prefix qualifier="AC">Dr. med. </prefix>  <given>Sine Johanna</given>  <prefix qualifier="NB">Gräfin </prefix>  <prefix qualifier="VV">von </prefix>  <family>Oberberg</family></name>
 Beispiel
Prof. Dr. med. Dr. rer. nat. Fritz Julius Karl Freiherr von und zu Rathenburg vor der Isar, MdB
<name>
  <prefix qualifier="AC">Prof. Dr. med. Dr. rer. nat. </prefix>  <given>Fritz</given>  <given>Julius</given>  <given>Karl</given>  <prefix qualifier="NB">Freiherr </prefix>  <prefix qualifier="VV">von und zu </prefix>  <family>Rathenburg vor der
Isar
</family>
  <suffix>, MdB</suffix></name>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Titel(Hea...get)
wo [@qualifier='AC']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FAC
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
ENXP0 … *Vorname(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Namenszusatz(Hea...get)
wo [@qualifier='NB']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FNB
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Vorsatzwort(Hea...get)
wo [@qualifier='VV']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FVV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
ENXP0 … *Nachname(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
ENXP0 … *Suffix(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE1 … 1RGeschlecht (administrativ) des Patienten(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.1 Administrative Gender (HL7 V3) (DYNAMIC)
 Beispiel<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.​DATE.​MIN1 … 1RGeburtsdatum des Patienten(Hea...get)
 Beispiel<birthTime value="19491224"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:marital​Status​Code
CE0 … 1Familienstand des Patienten(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12212 Marital Status (DYNAMIC)
 Beispiel<maritalStatusCode code="S" displayName="Never Married" codeSystem="2.16.840.1.113883.5.2"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:religious​Affiliation​Code
CE0 … 1Religionszugehörigkeit des Patienten(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19185 Religious Affiliation (DYNAMIC)
 Beispiel<religiousAffiliationCode code="1077" displayName="Protestant" codeSystem="2.16.840.1.113883.5.1076"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:raceCode
NPdarf nicht verwendet werden(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:ethnic​Group​Code
NPdarf nicht verwendet werden(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:guardian
0 … *Vormund/Sachwalter des Patienten(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...get)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:guardian​Person
  • hl7:guardian​Organization
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Organization
(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthplace
0 … 1Geburtsort des Patienten(Hea...get)
 Beispiel<birthplace>
  <place>
    <addr>Hamburg</addr>  </place>
</birthplace>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:place
1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1M(Hea...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:language​Communication
0 … *(Hea...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Code
CS0 … 1(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:modeCode
CE0 … 1(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12249 LanguageAbilityMode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:proficiency​Level​Code
CE0 … 1(Hea...get)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12199 LanguageAbilityProficiency (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:preference​Ind
BL0 … 1(Hea...get)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Participant: Informant (informant)

Id1.2.276.0.76.10.2018Gültigkeit2014‑08‑25
StatusKyellow.png EntwurfVersions-Label
NameCDAinformantBezeichnungCDA Informant
BeschreibungInformant, Personen, die Informationen zu dem Arztbrief beigesteuert haben (i.d.R. natürliche Personen, die nicht als Leistungserbringer agieren)
KlassifikationCDA Header Level Template
CDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.276.0.76.10.90012InklusionKgreen.png CDA Assigned Entity ElementsDYNAMIC
1.2.276.0.76.10.90020InklusionKyellow.png RelatedEntity (Body)DYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.319 CDA Informant (Body) (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<informant typeCode="INF">
  <assignedEntity>
    <id extension="4342116437" root="2.16.840.1.113883.3.933"/>    <assignedPerson>
      <name>
        <prefix>Dr. </prefix>        <given>Ursula</given>        <family>Müller</family>      </name>
    </assignedPerson>
  </assignedEntity>
</informant>
Beispiel
Beispiel
<informant typeCode="INF">
  <relatedEntity>
    <id nullFlavor="UNK"/>    <relatedPerson>
      <name>
        <given>Hanna</given>        <family>Anverwandt</family>      </name>
    </relatedPerson>
  </relatedEntity>
</informant>
ItemDTKardKonfBeschreibungLabel
hl7:informant
(CDA...ant)
Treetree.png@typeCode
0 … 1FINF
Treetree.png@context​Control​Code
0 … 1FOP
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:assignedEntity[hl7:assigned​Person]
  • hl7:relatedEntity
Treeblank.pngTreetree.pnghl7:assignedEntity
0 … 1Gesundheitsdienstleister(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1R(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(CDA...ant)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(CDA...ant)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(CDA...ant)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(CDA...ant)
Treeblank.pngTreetree.pnghl7:relatedEntity
0 … 1Verwandte, Bekannte, Sozialhelfer, Betreuer/Erzieher(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90020 RelatedEntity (Body) (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1R
 CONF
Der Wert von @classCode muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19316 RoleClassMutualRelationship (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1(CDA...ant)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19563 PersonalRelationshipRoleType (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS0 … 1(CDA...ant)
Treeblank.pngTreeblank.pngTreetree.pnghl7:relatedPerson
0 … 1(CDA...ant)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(CDA...ant)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Participant: Empfänger (informationRecipient)

Id1.2.276.0.76.10.2005Gültigkeit2013‑07‑10
StatusKgreen.png AktivVersions-Label
NameHeader​Information​RecipientBezeichnungCDA informationRecipient
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. (Es sind nicht die möglichen Empfänger, die jemals eine Kopie des Dokuments empfangen könnten.) So weiß man beispielsweise bei der Erstellung der Dokumentation, dass man einen „Brief" primär an den Hausarzt (informationRecipient.typeCode gleich PRCP, siehe unten) und ggf. einen zweiten („in Kopie") an einen mitbehandelnden Kollegen sendet (informationRecipient.typeCode ist gleich TRC).
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.276.0.76.10.90010InklusionKgreen.png CDA Person ElementsDYNAMIC
1.2.276.0.76.10.90011InklusionKgreen.png CDA Organization ElementsDYNAMIC
Beispiel
Beispiel
<informationRecipient typeCode="PRCP">
  <intendedRecipient>
    <id extension="4736437" root="2.16.840.1.113883.3.933"/>    <informationRecipient>
      <name>
        <prefix>Dr.med.</prefix>        <given>Kai</given>        <family>Heitmann</family>      </name>
    </informationRecipient>
    <receivedOrganization>
      <telecom use="WP" value="fax:+49247365746"/>      <addr>
        <streetAddress>Mühlenweg
1a
</streetAddress>
        <houseNumber>1a</houseNumber>        <postalCode>52152</postalCode>        <city>Simmerath</city>      </addr>
    </receivedOrganization>
  </intendedRecipient>
</informationRecipient>
ItemDTKardKonfBeschreibungLabel
hl7:information​Recipient
0 … *(Hea...ent)
Treetree.png@typeCode
cs0 … 1 Typ des Empfängers: im @typeCode der Participation kann angegeben werden, ob es sich um einen primären Empfänger handelt (default) oder einen sekundären Empfänger („CC Kopie").
Der typeCode PRCP ist der default.
 CONF
@typeCode muss "PRCP" sein
oder
@typeCode muss "TRC" sein
Treetree.pnghl7:intended​Recipient
1 … 1M(Hea...ent)
Treeblank.pngTreetree.pnghl7:id
II1 … *R(Hea...ent)
Auswahl1 … *
Wenn der beabsichtigte Empfänger eine Person ist, dann wird dies durch die Anwesenheit der Person Klasse mit oder ohne zugehörige Organisation spezifiziert. Wenn der beabsichtigte Empfänger eine Organisation ist, wird nur die Organisation angegeben, die Person fehlt.
Elemente in der Auswahl:
  • hl7:information​Recipient
  • hl7:received​Organization
Treeblank.pngTreeblank.pngTreetree.pnghl7:information​Recipient
0 … 1(Hea...ent)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:received​Organization
0 … 1(Hea...ent)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...ent)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ent)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Participant: Datentypist (dataEnterer)

Id1.2.276.0.76.10.2017Gültigkeit2014‑08‑25
StatusKyellow.png EntwurfVersions-Label
NameHeaderDataEntererBezeichnungCDA dataEnterer
BeschreibungDatentypist, die bei der Dateneingabe beteiligte Person(en) wie die Sekretärin u.a.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.90012InklusionKgreen.png CDA Assigned Entity ElementsDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.103 CDA dataEnterer (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:dataEnterer
0 … 1(Hea...rer)
Treetree.png@typeCode
0 … 1FENT
Treetree.png@context​Control​Code
0 … 1FOP
Treetree.pnghl7:time
TS0 … 1gibt den Zeitpunkt an, an dem der Datentypist seinen Beitrag am Dokument beendet hat(Hea...rer)
Treetree.pnghl7:assignedEntity
1 … 1R(Hea...rer)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreetree.pnghl7:id
II1 … *R(Hea...rer)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1R(Hea...rer)
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(Hea...rer)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(Hea...rer)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...rer)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(Hea...rer)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (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
TEL0 … *(Hea...rer)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...rer)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Autor (author - generisch)

Id1.2.276.0.76.10.2002Gültigkeit2013‑07‑10
StatusKyellow.png EntwurfVersions-Label
NameHeaderAuthorBezeichnungCDA author
BeschreibungDie Autor-Relation gibt den Urheber der Dokumentation und den Zeitpunkt der Autorenschaft wieder. Dies sind in der Regel Personen (Gesundheitsdienstleister) oder auch Geräte, die Daten erzeugen.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.276.0.76.10.90010InklusionKgreen.png CDA Person ElementsDYNAMIC
1.2.276.0.76.10.90011InklusionKgreen.png CDA Organization ElementsDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.102 CDA author (DYNAMIC)
ref
ad1bbr-
Beispiel
Autor ist eine Person
<author typeCode="AUT">
  <functionCode code="DISPHYS" displayName="discharging physician" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction"/>  <time value="20130407130000+0500"/>  <assignedAuthor classCode="ASSIGNED">
    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>
    </assignedPerson>
    <representedOrganization>
      <id root="2.16.840.1.113883.19.5"/>      <name>Beispiel Krankenhaus</name>    </representedOrganization>
  </assignedAuthor>
</author>
Beispiel
Autor ist ein Gerät/Maschine
<author typeCode="AUT">
  <assignedAuthor classCode="ASSIGNED">
    <assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">
      <code>...</code>    </assignedAuthoringDevice>
  </assignedAuthor>
</author>
ItemDTKardKonfBeschreibungLabel
hl7:author
(Hea...hor)
Treetree.png@typeCode
0 … 1FAUT
Treetree.png@context​Control​Code
0 … 1FOP
 Beispiel<author typeCode="AUT" contextControlCode="OP">
  <time value="201306101654"/>  <assignedAuthor classCode="ASSIGNED">
    <!-- ... -->
  </assignedAuthor>
</author>
Treetree.pnghl7:functionCode
CE0 … 1(Hea...hor)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC)
Treetree.pnghl7:time
TS.​DATE.​MIN1 … 1gibt den Zeitpunkt an, an dem der Autor seinen Beitrag am Dokument beendet hat; dies kommt bei einem Autoren praktisch überein mit ClinicalDocument.effectiveTime(Hea...hor)
Treetree.pnghl7:assignedAuthor
1 … 1(Hea...hor)
Treeblank.pngTreetree.png@classCode
0 … 1FASSIGNED
Treeblank.pngTreetree.pnghl7:id
II1 … *(Hea...hor)
Treeblank.pngTreetree.pnghl7:code
CE0 … 1Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin(Hea...hor)
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...hor)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:assigned​Person
  • hl7:assigned​Authoring​Device
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
 … 1(Hea...hor)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
 … 1(Hea...hor)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FDEV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:manufacturer​Model​Name
SC1 … 1(Hea...hor)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:softwareName
SC1 … 1(Hea...hor)
Treeblank.pngTreetree.pnghl7:represented​Organization
1 … 1M(Hea...hor)
 Beispiel<representedOrganization classCode="ORG" determinerCode="INSTANCE">
  <name>
    <!-- ... -->
  </name>
</representedOrganization>
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...hor)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Unterzeichner gesetzlich verantwortlich (legalAuthenticator - generisch)

Id1.2.276.0.76.10.2020Gültigkeit2014‑08‑25
StatusKyellow.png EntwurfVersions-Label
NameHeaderLegalAuthenticatorBezeichnungCDA legalAuthenticator
BeschreibungVor dem Gesetz verantwortliche Unterzeichner des Dokumentes
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.90012InklusionKgreen.png CDA Assigned Entity ElementsDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.106 CDA legalAuthenticator (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<legalAuthenticator typeCode="LA">
  <time value="20130327130000"/>  <signatureCode code="S"/>  <assignedEntity>
    <id extension="a00123456" root="1.2.276.0.76.3.9.8.7.6"/>    <assignedPerson>
      <name>
        <prefix qualifier="AC">Prof. Dr.</prefix>        <given>Hugo</given>        <family>Reinhardt</family>      </name>
    </assignedPerson>
    <representedOrganization>
      <name>Klinik am Zempiner Steig</name>      <telecom use="WP" value="tel:0332-4556"/>      <telecom use="WP" value="fax:0332-45577"/>      <addr>
        <streetName>Zempiner Steig</streetName>        <houseNumber>4</houseNumber>        <postalCode>15266</postalCode>        <city>Berlin</city>      </addr>
    </representedOrganization>
  </assignedEntity>
</legalAuthenticator>
ItemDTKardKonfBeschreibungLabel
hl7:legalAuthenticator
0 … 1(Hea...tor)
Treetree.png@typeCode
0 … 1FLA
Treetree.png@context​Control​Code
0 … 1FOP
Treetree.pnghl7:time
TS1 … 1R(Hea...tor)
Treetree.pnghl7:signatureCode
CS1 … 1R(Hea...tor)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treetree.pnghl7:assignedEntity
1 … 1R(Hea...tor)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreetree.pnghl7:id
II1 … *R(Hea...tor)
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1R(Hea...tor)
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(Hea...tor)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(Hea...tor)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...tor)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(Hea...tor)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...tor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...tor)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Verwaltende Organisation (custodian - generisch)

Id1.2.276.0.76.10.2004Gültigkeit2020‑03‑29
Andere Versionen mit dieser Id:
  • Kblank.png HeaderCustodian vom 2013‑07‑17
  • Kblank.png HeaderCustodian vom 2013‑07‑07
StatusKgreen.png AktivVersions-Label
NameHeaderCustodianBezeichnungCDA custodian
BeschreibungVerantwortliche Organisation für ein erstelltes Dokument (die das Dokument verwaltende Organisation). In der Regel ist es die erstellende Institution des Dokumentes.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
ItemDTKardKonfBeschreibungLabel
hl7:custodian
(Hea...ian)
Treetree.png@typeCode
0 … 1FCST
 Beispiel<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <!-- ... -->
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
Treetree.pnghl7:assignedCustodian
1 … 1M(Hea...ian)
Treeblank.pngTreetree.png@classCode
0 … 1FASSIGNED
Treeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1M(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … 1(Hea...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...ian)

cdaab2:Beteiligte (participant) (Template)


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

CDA R2 Body

Allgemeiner Aufbau des Body

Während im CDA Header die Akteure und mehr oder weniger administrative Inhalte wie Informationen über das Dokument selbst, den Patienten, den Autor etc. festgelegt wurden, enthält der CDA Body des hier definierten Arztbriefes die eigentliche klinische Dokumentation und stellt den „menschenlesbaren" medizinischen Teil dar.

Der hier definierte Arztbrief besteht im Body entweder aus einem nonXMLBody oder einem structuredBody Element, das wiederum section Elemente aufweist, mit denen die Information strukturiert werden kann. Falls nur die Metainformationen (Header) strukturiert übertragen werden und der Body nur aus einem Dokument (z. B. PDF) besteht, sollte man nonXMLBody verwenden (CDA Level1), das Dokumente entweder referenziert oder eingebettet wiedergeben.

Danach zeichnet sich für den Arztbrief folgende Grobstruktur ab.

Variante 1 - unstrukturierter Body

<ClinicalDocument>
  <!-- CDA Header -->
       ... siehe Beschreibung CDA R2 Header
  <!-- CDA Body -->
  <component>
    <nonXMLBody>
      <text mediaType="application/pdf" representation="B64">
        sadsfFAETQETEdfgStreTdsfgSrgregWRTERtSFGwERtwtergq45ttGw5TW%TwtR%TG
        vbnbnDJDZwrGTarGFaerewFasFaGaERgGtRzRthsYDFfGeRTertwerfFgERT3$RT34r
        dfE$R%34ReFD34T34TG§$t§4%T3ER§4t5§4TWEWRt§$t5§$t§g§$rt§$tGF$§t§$t$t
        ...
        cwER"§$wer§$65$%gTGH5643FD§$KJDU21%ZuTz$%z3vXCvSDf2EQeGFE§rwFG3$T%$
        e545REG34T%$gtrfgeg=
      </text>
      <languageCode code="de-DE"/>
    </nonXMLBody>
  </component>
</ClinicalDocument>
Variante 2 - strukturierter Body

<ClinicalDocument>
  <!-- CDA Header -->
       ... siehe Beschreibung CDA R2 Header
  <!-- CDA Body -->
    <component>
        <structuredBody>
              ... CDA R2 Body
        </structuredBody>
   </component>
</ClinicalDocument>

nonXMLBody (Variante 1)

Wie bereits angedeutet gibt es die Möglichkeit, lediglich den Header zur Übermittlung von strukturierten Metadaten zu einem Arztbrief zu nutzen:

Cdaab2 nonxmlbody.jpg

Cdaab2 nonxmlbody.jpg

[Abbildung 2] CDA nonXMLBody

Bei dieser Variante wird der Inhalt als Ganzes übermittelt. In diesem Fall besteht der Body lediglich aus einer verkürzten XML-Struktur, in der das Dokument eingebettet ist. Dann kann es allerdings nicht weiterverarbeitet und nur zur Anzeige mit einem geeigneten Viewer gebracht werden. In diesem Fall kommt ausschließlich die nonXMLBody-Section zum Einsatz.

structuredBody (Variante 2)

In der folgenden Grafik ist wiedergegeben, dass der CDA Body für den Arztbrief aus ein bis vielen Abschnitten (section) besteht. Diese können auch ineinander geschachtelt sein, um so – ähnlich wie in einem Buch – Unterabschnitte zu reflektieren. Als Beispiel ist hier ein „Kapitel" Anamnese zu nennen, das sich wiederum untergliedern könnte in „Eigenanamnese", „Familienanamnese", „Sozialanamnese" sowie „bisherige Operationen", „bisherige Impfungen" etc. In der Regel sind die Abschnitte mit Codes versehen (siehe unten). Manche Abschnitte sind mit zusätzlichen Einträgen (Komponenten) versehen, die RIM-Klassen entsprechen und hochstrukturierte Codierungen zulassen.

Zusammenfassend sind drei Typen von Abschnitten in der hier vorliegenden Arztbrief-Definition zu finden.

  • Text in Abschnitten, die nicht mit Codes identifiziert sind, innerhalb eines Abschnitts mit optionalen Unterabschnitten (Level 1, s. u.)
  • Text in Abschnitten, die mit Codes identifiziert sind, innerhalb eines Abschnitts mit optionalen Unterabschnitten (Level 2, s. u.)
  • Text in Abschnitten und Unterabschnitten, zusätzlich mit codierten Einträgen, die RIM-Klassen entsprechen (Level 3, s. u.).

Cdaab1 body.jpg

Cdaab1 body.jpg

[Abbildung 3] Übersicht über den Body-Teil des CDA-Dokuments. Die medizinische Dokumentation wird als Text in Abschnitten abgelegt, die vorzugsweise mit Codes identifiziert sind. Innerhalb eines Abschnitts kann es optionale Unterabschnitte geben, die eine weiter gehende Strukturierung ermöglichen. Für Diagnosen werden neben codierten Abschnitten auch hochstrukturierte Komponenten vorgesehen, die RIM-Klassen (z. B. Observation) entsprechen. Hier ist als Beispiel der Diagnose-Code für eine Entlass-Diagnose angedeutet.

Der structuredBody eines CDA Release 2 Dokuments setzt sich aus ein oder mehreren Komponenten zusammen, wobei jede Komponente wiederum aus einer oder mehreren Sektionen und gegebenenfalls aus einem oder mehreren „Entry"-Elementen (siehe Abschnitt „Level: 1 bis 3") besteht.

Das bedeutet unter anderem, dass ein CDA-Dokument dahingehend näher bestimmt werden kann, dass es spezifische Abschnitte, Paragrafen und andere Strukturbestandteile aufweisen muss. So kann ein Entlassbrief aus der Urologie beispielsweise ganz bestimmte Abschnitte beinhalten (Anamnese, Behandlung, Medikation, weiteres Vorgehen etc.), während ein OP-Bericht oder ein Pathologie-Befund ganz andere Erfordernisse bezüglich der Abschnitte und Strukturen haben kann bzw. muss.

Attribute von strukturierten Sections

Section.title: Titel des Abschnitts

Das section Element enthält einen optionalen Titel. Näheres regeln die entsprechenden spezialisierten Templates.

Section.text: Text des Abschnitts

Das section Element enthält eine narrative Beschreibung des Inhaltes und ist verpflichtend anzugeben.

Section.code: Klassifizierung des Abschnitts

Das section Element kann ein code Element enthalten, das den Inhalt des Abschnitts klassifiziert. Als Beispiel ist 10164-2 der LOINC Code für „History of Present Illness". Im Arztbrief sind zur primären Klassifikation ausschließlich LOINC Codes zugelassen. Alternative Codes können angegeben werden. Näheres regeln die entsprechenden spezialisierten Templates.

Section.languageCode: Sprache des Abschnitts

Jeder Abschnitt kann in einer anderen Sprache geschrieben sein. Dies wird im section-Element languageCode angegeben, wenn diese von der für das ganze Dokument (mittels languageCode im Header) gewählten abweicht. Weitere Informationen finden sich bei der Beschreibung des Elements languageCode des Headers. Hiervon wird allerdings typischerweise selten Gebrauch gemacht.

Beispiele für Abschnitte in einem Dokument

Ein Dokument besteht aus einem oder mehreren Abschnitten, die bei CDA auch Sections genannt werden. Nachfolgend ein paar typische Beispiele:

Entry

Die Abschnitte/Sections enthalten den Text, der direkt zur Anzeige verwendet werden soll. Für eine Maschine ist dieser normalerweise nicht direkt auswertbar. Dafür ist ein weiterer Mechanismus vorgesehen, bei dem die dem Text zugrundeliegenden Inhalte strukturiert ausgedrückt und in XML dargestellt werden. Diese Zusatzinformationen werden Entries genannt und innerhalb der Abschnitte optional eingebettet.

So kann beispielsweise ein Abschnitt Diagnose mit einer textuellen Darstellung der Diagnose ("Patient hat Blinddarmentzündung") ein Entry Diagnose enthalten, in dem die Diagnose als ICD-Code mit allen dazugehörigen Metadaten dargestellt wird.

Levels

Die CDA Level repräsentieren die unterschiedliche Feinheit (Granularität) der wiedergegebenen klinischen Informationen und des maschinen-auswertbaren Markups (standardisierte Form der maschinenauswertbaren Auszeichnung von Text).

Level 1

Mit Level 1 ist ein XML Dokument gekennzeichnet, das vor allem auf „menschliche Interoperabilität" abzielt („human readable"), also leicht für den menschlichen Gebrauch zugänglich gemacht werden kann, zum Beispiel durch Stylesheets. Es gibt keine Einschränkungen den Gebrauch oder Zweck des Dokuments oder den Inhalt betreffend. Die technischen Anforderungen, Level 1 Dokumente zu erzeugen oder zu verarbeiten, sind verhältnismäßig niedrig. Dies ist aus Datenverarbeitungssicht das gröbste Niveau von Informationen, gewährleistet damit aber sofort die Mensch-Mensch-Interoperabilität, die aus der reinen Papierwelt bekannt ist.

Cdaab1 section lvl1.jpg

Cdaab1 section lvl1.jpg

[Abbildung 4] CDA Level 1

Level 2

Im Level 2 wird der Aufbau der Abschnitte genauer festgelegt. Diese Festlegung kann sowohl die textuelle Darstellung mit <text> und <title> Elementen betreffen als auch die Vorgabe, den Abschnitt mit einem bestimmten Code kenntlich zu machen.

Die Identifikation dieser Abschnitte ist dann auch für Applikationen zugänglich, also maschinenauswertbar. Dies wird typischerweise erreicht durch die Assoziation des Abschnitts mit einem Code (oder einem Set von mehreren Codes). Hierfür werden in diesem Leitfaden ausschließlich LOINC Codes zur Dokumentenabschnittsklassifizierung verwendet. Eine andere Möglichkeit der Kenntlichmachung ist die Zuordnung einer Template-Identifikation, von der in dieser Spezifikation auch Gebrauch gemacht wird (siehe unten).

Cdaab1 section lvl2.jpg

Cdaab1 section lvl2.jpg

[Abbildung 5] CDA Level 2

Als Folge davon können so genannte section-level Templates zur Anwendung kommen. Mit den Codes sind die Abschnitte auch maschinen-auswertbar, d. h. durch Applikationen identifizierbar. Das bedeutet unter anderem, dass ein CDA Abschnitt dahingehend näher bestimmt werden kann, dass es spezifische Textteile (Paragraphen, Listen, Tabllen, etc.) aufweisen muss. So kann für einen Abschnitt mit Labordaten bspw. genau die Tabellenstruktur vorgegeben werden, d.h. welche Spalten in welcher Reihenfolge zu erscheinen haben.

Es liegt auf der Hand, dass die Spezifikation der Abschnitte eng verbunden ist mit dem Typ des Dokuments, z.B. ein OP-Bericht. In Arztbriefen - wofür dieser Leitfaden entwickelt wurde - macht man hier relativ wenig Vorgaben, während in Formularen oder Berichten relativ genaue Vorgaben zu erwarten sind.

Die häufigste Präzisierung ist die Vorgabe einer Menge von Codes für das Attribut code.

Level 3

CDA-Dokumente, die auch Level 3 konform sind, beinhalten zusätzlich auf dem Niveau von Einzelinformationen maschinen-auswertbare Komponenten (wie beispielsweise „systolischer Blutdruck"), die RIM-Klassen entsprechen. Eine Anwendung kann damit Daten wie eine einzelne Beobachtung, Prozedur, Medikamentengabe etc. identifizieren und verarbeiten. Selbst die Anwesenheit von bestimmten Einzelinformationen kann durch Vorgaben (Templates-Konzept) verpflichtend gemacht werden.

Cdaab1 section lvl3.jpg

Cdaab1 section lvl3.jpg

[Abbildung 6] CDA Level 3

Ingesamt spricht man bei CDA und der hier beschriebenen Architektur der Level von einer „inkrementellen bzw. variablen semantischen Interoperabilität". Das heißt schlicht, dass man sehr „bescheiden" anfangen kann und elektronische Dokumente nutzt, die im Wesentlichen Gegenstücke zum Papier sind: Mensch-Mensch-Interoperabilität. Je mehr eine Anwendung oder eine Anwendungsumgebung ermöglicht, desto mehr XML Markup kann man schrittweise zufügen: zunächst dadurch, bestimmte Abschnitte zu identifizieren oder gar zu fordern (Level 2) oder schließlich auf dem Niveau von Einzelinformationen anzugeben bzw. diese verpflichtend zu machen (Level 3). Dies bedeutet dann Anwendungsinteroperabilität.

Die folgende Grafik gibt eine Section Komponente mit ihren Bestandteilen wieder.

Cdaab1 section comp.jpg

Cdaab1 section comp.jpg

[Abbildung 7] CDA Section Komponente mit ihren Bestandteilen

Abbildung: Eine Abschnittskomponente (section) besteht aus einem <code>, der den Abschnitt typisiert, sowie einer Überschrift im <title>. Im obligatorischen <text> Teil sind die lesbaren Informationen repräsentiert. Dies ist verknüpft mit dem Begriff Level 2. Teile des narrativen Texts können darüber hinaus maschinenauswertbar im Level 3 repräsentiert werden, den so genannten CDA Entries <entry>. Zwischen Teilen des narrativen Texts und den Entries können Verbindungen angegeben werden.

XML-technisch gesprochen validieren CDA-Dokumente unabhängig vom Level gegen das generische CDA Schema. Zusätzlich können durch Festlegung bzw. Einschränkung der Abschnitte oder Detailinformationen weitere Validierungen verfügbar gemacht und genutzt werden.

Mit diesem Konzept ist es möglich,

  • narrative Befunde elektronisch strukturiert wiederzugeben, so wie sie heute in der papierbasierten Welt zu finden sind, mit oder ohne zusätzliches Markup. Gleichzeitig wird gewährleistet, dass so viele gemeinsame Informationen wie möglich den Anwendungen zur Verfügung stehen (shared semantics), wie zum Beispiel die Identifikation und andere allgemeine Daten des Patienten.
  • feingranulierte und kodierte Informationen darzustellen, wie Diagnosen, Prozeduren, Medikationen etc., die in (ggf. vorgegebenen) Kodierschemas wie ICD 10 repräsentiert sind, sowie Mess- oder Laborergebnisse darzustellen.
  • Dokumente abzubilden, die irgendetwas zwischen diesen beiden Extremen von grober Strukturierung von narrativem Text bis zu feingranulären Einzelinformationen repräsentieren.

Man kann dies auch als Möglichkeit ansehen, „sanft" und ohne allzu hohe Ansprüche zu beginnen, elektronische Dokumente einzuführen und mit steigenden Anforderungen und technischen Möglichkeiten zu höherer Anwendungsinteroperabilität zu migrieren.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Textstrukturierung

Die medizinischen Informationen werden im CDA Body im Sinne von Level 1 immer in Textform wiedergegeben (verpflichtend) und wo immer möglich auch mit Section-Codes versehen, also auf Level 2 dargestellt. Dies garantiert, dass die Dokumente immer für den Menschen lesbar (und verstehbar) sind. Im Folgenden ist das Muster einer Level 1 und Level 2 Darstellung gezeigt. Level 3 ist angedeutet:

<component>
  <structuredBody>
  ... 
    <component>
      <section>
        <!-- Level 2 -->
        <code code="..." codeSystem="..." />
        <!-- Level 1 -->
        <title> ... </title>
        <text>
           ...
        </text>
        <!-- Level 3 -->
        <entry>
           ...
        </entry>
      </section>
    </component>
    ...
  </structuredBody>
</component>

Textauszeichnung

Der Text selber kann wiederum Strukturelemente aufweisen. Dies kann genutzt werden, um Listen, Tabellen oder auch Unterabschnitte zu definieren. Innerhalb eines Section-Tags wird in CDA Level 2 das text Tag verwendet, um den narrativen Text („plain text") darzustellen. In vielen Fällen lassen sich die medizinischen Inhalte aber auch noch weiter gehend strukturiert darstellen. Dazu stehen in CDA als Stil-Elemente Listen, Tabellen und Unterabschnitte (Paragrafen) zur Verfügung. Mit Hilfe eines einfachen Stylesheets können die Inhalte in diesen Strukturelementen für den Menschen lesbar dargestellt werden.

Listen

Das Strukturelement „Liste" dient zur Abbildung einer einfachen Aufzählung medizinischer Inhalte. Eine Liste wird mit dem list Tag eingeschlossen. Das optionale Attribut @listType ermöglicht die Auflistung unsortiert (@listType="unsorted"), die üblicherweise mit Bulletpoints • dargestellt wird, und in sortierter Form (@listType="sorted") , die mit Zahlen etc. dargestellt wird. Ohne Angabe von @listType ist die Liste unsortiert. Ein Element der Aufzählung (item) wird mit dem item Tag eingeschlossen. Eine Liste hat formal das folgende Aussehen:

<list>
  <item> 1. Element der Liste</item>
  <item> 2. Element der Liste</item>
  <item> ...</item>
  <item> n. Element der Liste</item>
</list>

Das folgende Beispiel zeigt eine mögliche Darstellung eines Befundes, strukturiert mittels Liste.

<text>
  <list>
    <item>Pulmo: Basal diskrete RGs</item>
    <item>Cor: oB</item>
    <item>Abdomen: weich, Peristaltik: +++</item>
    <item>Muskulatur: atrophisch</item>
    <item>Mundhöhle: Soor, Haarleukoplakie</item>
    <item>Haut blass, seborrhoisches Ekzem, Schleimhäute blass,
          Hautturgor herabgesetzt</item>
    <item>Neuro: herabgesetztes Vibrationsempfinden der Beine,
          distal betont, Parästesien der Beine, PSR, AST
          oB und seitengleich.</item>
  </list>
</text>

Dasselbe Beispiel in der Ansicht eines Browsers (mittels Stylesheet).

Ansicht im Browser
  • Pulmo: Basal diskrete RGs
  • Cor: oB
  • Abdomen: weich, Peristaltik: +++
  • Muskulatur: atrophisch
  • Mundhöhle: Soor, Haarkoplakie
  • Haut blass, seborrhoisches Ekzem, Schleimhäute blass, Hautturgor herabgesetzt
  • Neuro: herabgesetztes Vibrationsempfinden der Beine, distal betont, Parästesien der Beine, PSR, AST oB und seitengleich.
Tabellen

Zur Repräsentation medizinischer Inhalte, die sich adäquat tabellarisch darstellen lassen, bietet sich die Tabellenform an. Als Beispiele seien genannt: Laborwerte, Allergiewerte, Diagnose mit ICD-Verschlüsselung etc. CDA realisiert ein vereinfachtes XHTML Table Modell, das HTML sehr ähnelt. Eine Tabelle wird angedeutet mit dem table Element. Als Attribut ist hier @border vorgesehen, das die Breite der Umrahmung angibt.

<table border="1">
  ''...Tabellen-Elemente''
</table>

Eine Tabelle besteht aus einer oder mehreren Spalten. In der ersten Zeile werden die Spaltenüberschriften aufgeführt. Die Tabellenüberschrift wird eingeschlossen in thead Tags, die Überschriftenzeile in tr Tags und die einzelnen Spalten-Items der Überschrift mit th Tag.

<table>
  <thead>
    <tr>  <!-- Überschrift-Zeile -->
      <th> Spaltenüberschrift 1</th> 
      ...
      <th> Spaltenüberschrift n</th>
    </tr>
  </thead>
  ...
</table>

Die eigentlichen Inhalte werden in tbody Tags, die Datenzeile in tr Tags und die einzelnen Spalteninhalte einer Datenzeile mit td Tag gekapselt. Insgesamt hat eine Tabelle formal das folgende Aussehen:

<table>
  <thead>
    <tr>  <!-- Überschrift-Zeile -->
      <th> Spaltenüberschrift 1</th>
      ...
      <th> Spaltenüberschrift n</th>
    </tr>
  </thead>
  <tbody>
    <tr>  <!-- 1. Zeile mit Daten -->
      <td>Inhalt Spalte 1 in Zeile 1</td>
      ...
      <td>Inhalt Spalte n in Zeile 1</td>
    </tr>
    ...
    <tr> <!-- m. Zeile mit Daten -->
      <td>Inhalt Spalte 1 in Zeile m</td>
        ...
      <td>Inhalt Spalte n in Zeile m</td>
    </tr>
  </tbody>
</table>

Das folgende Beispiel zeigt die Repräsentation einer Diagnose in Tabellenform, wobei die Spaltenüberschriften lauten: "Diagnose", "ICD Code", "Lokalisation" und "Zusatz"

<table>
  <thead>
    <tr>
      <th>Diagnose</th>
      <th>ICD Code</th>
      <th>Lokalisation</th>
      <th>Zusatz</th>
    </tr>
  </thead>
  <tbody>
   <tr>
      <td>Tuberkulose des Ohres</td>
      <td>A18.6</td>
      <td>R</td>
      <td>G</td>
    </tr>
    <tr>
      <td>Ausschluss Lungenemphysem</td>
      <td>J43.9</td>
      <td>--</td>
      <td>A</td>
    </tr>
    <tr>
      <td>V. a. Allergische Rhinopathie durch Pollen</td>
      <td>J31.1</td>
      <td>--</td>
      <td>V</td>
    </tr>
  </tbody>
</table>



Beispiel

[Abbildung 8] Dasselbe Beispiel in der Ansicht eines Browsers (mittels Stylesheet).

Unterabschnitte

Zur Strukturierung eines längeren Textes kann das paragraph Tag verwendet werden. Beispiel:

<text>
  <paragraph> Sollten nach der empfohlenen Medikation mit Atemur die
  klinischen Zeichen weiterhin bestehen, halte ich bei dem umfangreichen
  Risikoprofil einen Kuraufenthalt für zwingend notwendig.</paragraph>
  <paragraph> Ich bitte dann um Wiedervorstellung des Patienten.
  </paragraph>
</text>
Überschriften

Mit dem caption Element kann man Paragrafen, Listen, Listenelemente, Tabellen oder Tabellenzellen mit einer Beschreibung („Überschrift") versehen. Ein caption Element enthält Text und kann Verweise (Links) oder Fußnoten enthalten.

Superskripts und Subskripts

Diese Gestaltungsmöglichkeiten sind im CDA-Standard beschrieben, werden aber in diesem Leitfaden noch nicht genutzt.

Zeilenumbrüche

Das br Element <br/> kann benutzt werden, um im laufenden Text einen „harten" Zeilumbruch zu erzwingen. Dies unterscheidet sich vom paragraph Element, da der Zeilenumbruch keinen Inhalt hat. Empfänger sind gehalten, dieses Element als Zeilenumbruch darzustellen.

Beispiel

<text>
  Patient hat Asthma seit seinem zehnten Lebensjahr.<br/>
  Patient kommt damit gut zurecht.
</text>
Fußnoten

Diese Gestaltungsmöglichkeiten sind im CDA-Standard beschrieben, werden aber in diesem Leitfaden noch nicht genutzt.

Sonstige Zeichenstile

Mittels des @styleCode Attributs im Textteil, das in content Elementen verwendet werden kann, ist es möglich, Vorschläge des Autors des Dokuments bezüglich der Visualisierung von umschlossenen Textteilen zu beschreiben. Der Empfänger ist nicht verpflichtet, den Text tatsächlich so visuell darzustellen, wie es die Vorschläge andeuten. Bisher werden im Rahmen dieses Leitfadens die folgenden Style-Codes unterstützt, die in beliebiger Reihenfolge genutzt werden können.

Font-Stil-Angaben (Änderung der Font-Charakteristik)
Code Definition
Bold Fettdruck
Underline Unterstrichen
Italics Kursivschrift
Emphasis Betont

[Tabelle 5] Stil-Codes für den narrativen Text

<text>
  Einiges vom Text wird <content styleCode="Bold">im Fettdruck</content> 
  dargestellt, anderes in <content styleCode="Bold Italics">fetter
  Kursivschrift</content>.
</text>

Referenzierter Inhalt (content)

Das CDA content Element wird benutzt, um Text ausdrücklich mit Tags „einzurahmen", so dass er referenziert werden kann oder bestimmte Möglichkeiten zur visuellen Darstellung genutzt werden können. Das content Element kann rekursiv ineinander geschachtelt werden, was die Einrahmung von ganzen Texten bis hin zu kleinsten Teilen (Worte, Buchstaben etc.) erlaubt.

Das content Element enthält ein optionales Identifikator Attribut, das als Ziel einer XML Referenz dienen kann. Alle diese IDs sind als XML IDs definiert und müssen im gesamten Dokument eindeutig sein. Die originalText Komponente einer RIM Klasse, die sich in den CDA Entries (siehe unten) wieder findet, kann sich somit explizit auf die vom content Element im Textteil umschlossene Information beziehen.

Im Beispiel wird das Textstück Asthma durch das content Element eingerahmt, so dass in einem möglichen Level 3 Entry darauf Bezug genommen werden kann (originalText.reference, siehe unten).

Beim Patienten wurde <content ID="diag-1">Asthma</content> diagnostiziert.

Das content Element wird auch zur Einrahmung von Text benutzt, der in einem, bestimmten Stil dargestellt werden soll, was mit dem @styleCode Attribut (siehe unten) näher beschrieben wird.

Referenz zu (externen) Multimedia-Inhalten

Es ist möglich, zusätzlich zu dem Text auch Referenzen auf externe Multimediaobjekte wie Bilder etc. zu spezifizieren. Dies geschieht über das renderMultiMedia Element und dient dazu aufzuzeigen, wo das Multimedia-Objekt gezeigt/dargestellt werden soll.

Das renderMultiMedia Element hat ein optionales caption Element. Es weist außerdem die Referenz (XML ID) zum erforderlichen Objekt auf, die als XML IDREF im selben Dokument definiert sein muss. XML ID und IDREF sind also korrespondierende Definitionen (einmalig) und Referenzen darauf (mehrfach möglich) eines CDA Entry ObservationMedia (oder RegionOfInterest) im selben Dokument.

Das renderMultiMedia Element trägt dabei im @referencedObject Attribut die ID.

Die Information zum eigentlichen Objekt wird in einem CDA Entry festgehalten. Für diesen Leitfaden wird ausschließlich das Element observationMedia verwendet.

Dieser Eintrag trägt im entry Element unter anderem das @ID Attribut als Zielreferenz des @referencedObject Attributs vom renderMultiMedia Element.

ObservationMedia Klasse

Die Klasse ObservationMedia selbst ist im Prinzip ein Clinical Statement, wobei die im Folgenden genannten Elemente möglich sind.

Observation Media

[Abbildung 9] ObservationMedia CDA Entry zur Darstellung der Informationen eines Multimedia-Objektes.

Eine detaillierte Beschreibung ist beim entsprechenden Template Eingebettetes Objekt Entry angegeben.

Regel OMVL: Wenn die Klasse observationMedia genutzt wird, muss sie ein value Element mit dem eigentlichen Objekt enthalten.

Vokabular

Der Datentyp von Multimedia-Objekten ist immer ED (encapsulated data). Dabei ist auch der Medientyp (MIME) im entsprechenden @mediaType Attribut zu nennen. Zugelassen sind hier zunächst nur die folgenden Mime-Typen. Als „verpflichtend", also als zu unterstützen, werden die Typen text/plain, application/pdf sowie audio/mpeg, image/png, image/jpeg und video/mpeg eingestuft.

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.
Id1.2.276.0.76.11.14Gültigkeit2014‑08‑25
StatusKyellow.png EntwurfVersions-Label
NameMediatypesBezeichnungMedientypen
Benutzung: 1
IdNameTyp
Template
1.2.276.0.76.10.4014Eingebettetes Objekt Entry DYNAMIC
Quell-Codesystem
1.2.840.10003.5.109 - FHIR: urn:oid:1.2.840.10003.5.109
Level/ TypCodeBezeichnungCodesystemBeschreibung
0‑L
text/plain
Mime Type text/plain
1.2.840.10003.5.109Für beliebige Texte. Dies ist der ’default’ Typ. In dieser Form ist er identisch mit dem ST Typ
0‑L
text/html
Mime Type text/html
1.2.840.10003.5.109Bestimmt für formatierte Texte in HTML Format. HTML reicht für die meisten Anwendungen aus, bei denen Layout erwünscht ist. HTML ist Plattform-unabhängig und weit verbreitet.
0‑L
text/xml
Mime Type text/xml
1.2.840.10003.5.109
0‑L
application/pdf
Mime Type application/pdf
1.2.840.10003.5.109Adobe Portable Document Format
0‑L
image/png
Mime Type image/png
1.2.840.10003.5.109Portable Network Graphics (PNG, http://www.cdrom.com/pub/png) ist eine verlustfreie Komprimierung von Bilddateien. Wo vorher GIF benutzt wurde, muss jetzt PNG unterstützt werden.
0‑L
image/jpeg
Mime Type image/jpeg
1.2.840.10003.5.109Dieses Format wird benutzt für hohe Auflösungen bei Fotos und anderen Bilddateien. Die Komprimierung verläuft nicht ohne Verluste, wodurch dieses Format nicht immer geeignet ist für diagnostische Zwecke. JPEG wird vorwiegend benutzt werden für ’thumbnails’ von großen (DICOM) Dateien.
0‑L
image/gif
Mime Type image/gif
1.2.840.10003.5.109
0‑L
video/mpeg
Mime Type video/mpeg
1.2.840.10003.5.109MPEG ist ein internationaler Standard für Videobilder. Er ist weit verbreitet und Open-Source-Implementierungen sind verfügbar.
0‑L
audio/mpeg
Mime Type audio/mpeg
1.2.840.10003.5.109MPEG-1 Audio layer-3 (auch bekannt als MP3) ist momentan der Standard für komprimierte Audiodaten.

Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.


[Tabelle 6] mediaType Attribut Werte (Datenarten)

Beispiel

Das in observationMedia.value befindliche reference Element enthält als Wert den Verweis auf das eigentliche Multimedia-Objekt.

Das folgende Beispiel beschreibt einen Befund am linken Zeigefinger, der zusätzlich mit einem Bild dokumentiert ist.

<section>
   <code code="8709-8" codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>Untersuchung der Haut</title>
   <text>Rötung an der Palmarfläche des linken Zeigefingers
     <renderMultiMedia referencedObject="MM1"/>
   </text>
   <entry>
      <observationMedia classCode="OBS" moodCode="EVN">
         <templateId root="1.2.276.0.76.10.4014"/>
         <value mediaType="image/jpeg">
            <reference value="lefthand.jpeg"/>
         </value>
      </observationMedia>
   </entry>
</section>


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Anrede

Id1.2.276.0.76.10.3001Gültigkeit2013‑01‑10
StatusKgreen.png AktivVersions-Label
NameSalutationBezeichnungAnrede
Beschreibung
Dieser Abschnitt enthält die allgemeinen einleitenden Sätze eines Dokuments, z. B. eines Arztbriefes oder eines Befund-Dokuments. Sie werden in einem Abschnitt zusammengefasst und können Anrede (z. B. „Sehr geehrter Herr Kollege,..."), eine erste Nennung des Patienten evtl. mit der zusätzlichen Angabe des Geburtsdatums etc. enthalten.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.3001
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
Beispiel
Anrede
<section>
  <templateId root="1.2.276.0.76.10.3001"/>  <code code="X-SALUT" codeSystem="2.16.840.1.113883.6.1" displayName="Salutation"/>  <text>
    <paragraph>Sehr geehrter Herr Kollege Dr. Heitmann,</paragraph>    <paragraph>Vielen Dank für die freundliche Überweisung des Patienten Paul Pappel, geb. 12. Dez. 1955.</paragraph>  </text>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Sal...ion)
Treetree.pnghl7:templateId
II1 … 1M(Sal...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3001
Treetree.pnghl7:code
CE1 … 1M(Sal...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1FX-SALUT
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
 Beispiel<code code="X-SALUT" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
Treetree.pnghl7:title
NPEin Titel des Abschnitts kommt in der Begrüßung nicht vor(Sal...ion)
Treetree.pnghl7:text
SD.TEXT1 … 1M(Sal...ion)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Grund der Überweisung

Id1.2.276.0.76.10.3002Gültigkeit2013‑09‑16
Andere Versionen mit dieser Id:
  • Kblank.png ReasonForReferral vom 2017‑02‑01
  • Kblank.png ReasonForReferral vom 2013‑01‑10
StatusKgreen.png AktivVersions-Label
NameReasonForReferralBezeichnungGrund der Überweisung Section
Beschreibung
Dieser Abschnitt enthält die konkrete (medizinische) Fragestellung bzw. Grund für eine Überweisung, die sich aufgrund einer medizinischen Untersuchung ergibt, formuliert als Freitext und in einer eigenen Komponente abgelegt.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.3002
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungAdaptation: Template 1.3.6.1.4.1.19376.1.5.3.1.3.1 IHE Reason for Referral Section (DYNAMIC)
ref
IHE-PCC-

Adaptation: Template 1.2.40.0.34.11.2.2.1 Aufnahmegrund (DYNAMIC)
ref
elgabbr-

Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<section>
  <code code="42349-1" codeSystem="2.16.840.1.113883.6.1"/>  <title>Grund der Überweisung</title>  <text>Röntgen Thorax in zwei Ebenen</text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Rea...ral)
Treetree.pnghl7:templateId
II1 … 1(Rea...ral)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3002
Treetree.pnghl7:code
CE1 … 1M(Rea...ral)
Treeblank.pngTreetree.png@code
CONF1 … 1F42349-1
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
 Beispiel<code code="42349-1" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
Treetree.pnghl7:title
1 … 1M(Rea...ral)
 CONF
Elementinhalt muss "Grund der Überweisung" sein
Treetree.pnghl7:text
SD.TEXT1 … 1MHier wird die eigentliche Fragestellung platziert.(Rea...ral)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Anamnesen

In diesem Leitfaden werden die folgenden Anamnese-Informationen unterstützt.

Jetzige Anamnese

Id1.2.276.0.76.10.3022Gültigkeit2013‑12‑30
StatusKgreen.png AktivVersions-Label
NameHistoryofpresentillnesssectionBezeichnungJetzige Anamnese
BeschreibungJetzige Anamnese
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(His...ion)
Treetree.pnghl7:templateId
II1 … 1(His...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3022
Treetree.pnghl7:code
CE1 … 1M(His...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F10164-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(His...ion)
 CONF
Elementinhalt muss "Jetzige Anamnese" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(His...ion)

Frühere Erkrankungen

Id1.2.276.0.76.10.3023Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Historyofpastillnesssection vom 2017‑04‑09
StatusKgreen.png AktivVersions-Label
NameHistoryofpastillnesssectionBezeichnungFrühere Erkrankungen
BeschreibungListe der bisherigen Krankheiten des Patienten
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(His...ion)
Treetree.pnghl7:templateId
II1 … 1(His...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3023
Treetree.pnghl7:code
CE1 … 1M(His...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F11348-0
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(His...ion)
 CONF
Elementinhalt muss "Frühere Erkrankungen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(His...ion)

Familienanamnese

Id1.2.276.0.76.10.3024Gültigkeit2013‑12‑30
StatusKgreen.png AktivVersions-Label
NameFamilyhistorysectionBezeichnungFamilienanamnese
BeschreibungAngaben über Erkrankungen macht, die bei Verwandten des Patienten aufgetreten sind.
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Fam...ion)
Treetree.pnghl7:templateId
II1 … 1(Fam...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3024
Treetree.pnghl7:code
CE1 … 1M(Fam...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F10157-6
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Fam...ion)
 CONF
Elementinhalt muss "Familienanamnese" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Fam...ion)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Erhobene Befunde

Id1.2.276.0.76.10.3025Gültigkeit2013‑12‑30
StatusKgreen.png AktivVersions-Label
NameHospital​discharge​studies​summary​sectionBezeichnungErhobene Befunde (Krankenhaus)
BeschreibungIm Krankenhaus erhobene Befunde
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<section>
  <templateId root="1.2.276.0.76.10.3025"/>  <code code="11493-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <title>Erhobene Befunde
(Krankenhaus)
</title>
  <text>
    <list>
      <item>Pulmo: Basal diskrete RGs</item>      <item>Cor: oB</item>      <item>Abdomen: weich, Peristaltik: +++</item>      <item>Muskulatur: atrophisch</item>      <item>Mundhöhle: Soor, Haarleukoplakie</item>      <item>Haut blass, seborrhoisches Ekzem, Schleimhäute blass, Hautturgor herabgesetzt</item>      <item>Neuro: herabgesetztes Vibrationsempfinden der Beine, distal betont, Parästesien der Beine, PSR, AST oB und seitengleich.</item>    </list>
  </text>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Hos...ion)
Treetree.pnghl7:templateId
II1 … 1(Hos...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3025
Treetree.pnghl7:code
CE1 … 1M(Hos...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F11493-4
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Hos...ion)
 CONF
Elementinhalt muss "Erhobene Befunde" sein
-oder-
Elementinhalt muss "Erhobene Befunde (Krankenhaus)" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Hos...ion)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Diagnosen

Die Diagnosen werden im Arztbrief im Idealfall

  • in Level 1 zur direkten Ausgabe formatiert,
  • in Level 2 als Diagnose markiert und
  • in Level 3 codiert angegeben (im jetzigen Leitfaden nicht beschrieben, sondern alleinig in den nicht-normativen Einzelabschnitten zu den Diagnosen wiedergegeben):

Die folgenden Typen von Diagnosen werden in den entsprechenden Sektionen wiedergegeben.

Aufnahmediagnose

Id1.2.276.0.76.10.3026Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Admissiondiagnosissection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameAdmissiondiagnosissectionBezeichnungAufnahmediagnose
BeschreibungSpeziell gekennzeichnete Diagnose, die im Verlauf der Aufnahmeuntersuchung gestellt wird.
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Adm...ion)
Treetree.pnghl7:templateId
II1 … 1(Adm...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3026
Treetree.pnghl7:code
CE1 … 1M(Adm...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F46241-6
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Adm...ion)
 CONF
Elementinhalt muss "Aufnahmediagnosen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Adm...ion)


Entlassungsdiagnose

Id1.2.276.0.76.10.3027Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Dischargediagnosissection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameDischargediagnosissectionBezeichnungEntlassungsdiagnose
BeschreibungDiagnose, mit der der Patient entlassen wurde
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Dis...ion)
Treetree.pnghl7:templateId
II1 … 1(Dis...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3027
Treetree.pnghl7:code
CE1 … 1M(Dis...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F11535-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Dis...ion)
 CONF
Elementinhalt muss "Entlassungsdiagnosen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Dis...ion)


Textformatierung für Diagnosen (auf Level 1)

Das nachfolgende Beispiel zur Textformatierung zeigt die Nutzung von Tabellen am Beispiel der Diagnosen.

Beispiel

<component>                     
  <!-- Diagnose mit ICD Komponente auf CDA Level 2--> 
  <section>
    <code code="29548-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
    <title>29.08.2005: Diagnosen mit ICD 10</title>
    <text>
      <table border="1">
        <thead>
          <tr>
          <th>Diagnose</th>
          <th>ICD Code</th>
          <th>Lokalisation</th>
          <th>Zusatz</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td><content ID ="DIAG200508291">Allergisches Asthma</content></td>
            <td>J45.0</td>
            <td>--</td>
            <td>G</td>
          </tr>
          <tr>
            <td><content ID ="DIAG200508292">Ausschluss Lungenemphysem</content></td>
            <td>J43.9</td>
            <td>--</td>
            <td>A</td>
          </tr>
          <tr>
            <td><content ID ="DIAG200508293">V.a. Allergische Rhinopathie durch Pollen</content></td>
            <td>J31.1</td>
            <td>--</td>
            <td>V</td>
          </tr>
        </tbody>
      </table>
    </text>
  </section>
</component>
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Entry: ICD-Diagnose (allgemein)

Template-Metadaten
Template-Typ Entry
Template ID
generischeres Template
genutztes Templates
nutzende Templates
abgeleitete Templates
Schwester-Templates
Generelle Beschreibung Hiermit wird auf Entry-Level die Übermittlung von Diagnosedaten definiert.
allg. Erläuterung IG:Diagnoseleitfaden
Verhältnis zu IHE neu
Ballotierungsstatus in Arbeit
Erweiterbarkeit geschlossen

Einleitung: ICD-10 GM codierte Diagnosen

Die „International Statistical Classification of Diseases" (ICD) ist ein Klassifizierungssystem für Krankheiten und verwandter Gesundheitsprobleme. Sie ist hierarchisch gegliedert. Die ICD-10-GM ist als deutsche Abwandlung (German Modification) eine länderspezifische Variante der ICD-10 der WHO. Die Krankheiten werden über alphanumerische Codes klassifiziert. Jede Krankheit ist einem Code eindeutig zugeordnet. Bei den Codes handelt es sich überwiegend um so genannte Primärdiagnoseschlüssel, die alle Informationen zur Verschlüsselung der jeweiligen Krankheit beinhalten. Zusätzlich liegen in der ICD-10 Sekundärdiagnoseschlüssel vor, die ergänzende Informationen enthalten. Sekundärdiagnoseschlüssel sind in der Klassifikation selbst eindeutig mit einem Stern (*) oder Ausrufezeichen (!) als Zusatzkennzeichen des Codes gekennzeichnet. Sie sind nur in Verbindung mit einer Primärdiagnose zu verwenden. Primärdiagnosecodes führen kein Kennzeichen oder ein Kreuz (+). Beispiel.: E14.30+, H28.0* ICD-10 Code für "Diabetes mellitus mit Katarakt"

ICD-10 Code Begrifflichkeiten

Zur Verschlüsslung von Diagnosen in der ambulanten und stationären Versorgung wird seit dem 01.01.2004 die ICD-10-GM verwendet. Bei der Codierung der Diagnosen müssen im stationären Bereich (§ 301) die Deutschen Codierrichtlinien beachtet werden und die durch das BMG genehmigte Codeerweiterungen. Auf diese und die Codeerweiterungen wird im folgendem eingegangen. Für den ambulanten Bereich gilt die WHO-Tabelle mit BMG-Ergänzungen.

Kreuz–Stern Diagnosen, Ausrufezeichen (!)

Bei der ICD-10 GM wird zwischen Primär- und Sekundärcodes unterschieden. Primärcodes sind Codes ohne Kennzeichen und Codes mit einem Kreuz. Sekundärcodes sind Codes mit einem Stern oder einem Ausrufzeichen. Um die Begrifflichkeiten näher zu beschreiben, werden hier einige Zitate aus der Broschüre „Basiswissen Kodieren" (DIMDI, Basis) aufgeführt. „ .. Der Code für die Ätiologie einer Erkrankung wird in der ICD-Codierung mit einem Kreuz (†) gekennzeichnet und die Organmanifestation mit einem Stern (*). Hierbei darf der Stern-Code aber nie alleine verwendet werden. Der Kreuz-Code ist der Primärcode." Weiterhin gilt: „ ... Als Sterncodes darf man nur diejenigen Codes verwenden, die in der ICD-10-GM explizit als solche definiert sind..." „... Zulässig ist es hingegen, den Code für eine Grunderkrankung mit einem Kreuz zu ergänzen, wenn für die Krankheitsmanifestation ein passender Sterncode zur Verfügung steht..." „... Manche Codes sind mit einem Ausrufezeichen (!) gekennzeichnet. Hierbei handelt es sich um Zusatzcodes, die eine Krankheit näher beschreiben oder deren Schweregrad abgrenzen. Diese Codes dürfen ebenfalls nicht alleine stehen..."

Daraus folgt, dass eine Diagnose mindestens durch einen Primärcode beschrieben wird und falls notwendig, durch die zusätzliche Angabe von Sekundärcodes. Der Primär- bzw. der Sekundärcode selbst setzt sich zusammen aus einer alphanumerischen Zeichenkette, welche den Code repräsentiert und einen Code-Zusatzkennzeichen (†, *, !).

Seitenlokalisation

Zur Angabe der Seitenlokalisation wird hier ein Abschnitt aus der „ICD-10-Bekanntmachung des BMGS" vom 21.10.2004 zitiert. „.. Für die Anwendung des ICD-10-GM gilt Folgendes: Zur Spezifizierung der Diagnoseangaben für die Seitenlokalisation darf eines der nachgenannten Zusatzkennzeichen angegeben werden: – rechts: R – links: L – beidseitig: B ..." (BMGS, 2004) Daraus ergibt sich, dass es möglich sein muss, zu jedem ICD-10 Code eine Seitenlokalisation anzugeben. Anmerkung: Die Seitenlokalisation kann für den Primärcode ein anderer sein als für den Sekundärcode.

Beispiel:
C50.4 R Mamma Ca - rechts
J91* L Pleuraerguss bei sonstiger Erkrankung - links

In der Tumordokumentation gilt die erweiterte Tabelle. Anmerkung: In manchen Fällen ist die Benutzung des Begriffs „beidseits" notwendig.

Diagnosesicherheit

„... Für die Anwendung der ICD-10-GM nach § 295 SGB V (ambulanter Bereich) gilt zusätzlich Folgendes: Zur Angabe der Diagnosesicherheit ist eines der nachgenannten Zusatzkennzeichen anzugeben (obligatorische Anwendung – für eine ausgeschlossene Diagnose: A – für eine Verdachtsdiagnose: V – für einen symptomlosen Zustand nach der betreffenden Diagnose: Z – für eine gesicherte Diagnose: G..." (BMGS, 2004) Das heißt, wird eine Diagnose im Rahmen einer „Abrechnung ärztlicher Leistungen" (§295 SGB V) angegeben, ist neben der Angabe des ICD-10 Codes, die Angabe der Diagnosesicherheit zwingend erforderlich. Im stationären Bereich dürfen diese Angaben nicht verwendet werden. (siehe Änderung zu 3.9)

Darstellung des Diagnosemodells in HL7 V3

Die Diagnose wird in HL7 V3 über die Klasse Observation dargestellt. Die Klasse ist, wie in Abbildung 1: Klasse Observation gezeigt aufgebaut.


Klasse Observation

Abbildung 1: Klasse Observation

Auf die genauere Beschreibung der einzelnen Klassen und die verwendeten Datentypen wird hier verzichtet. Nähere Informationen dazu sind der HL7 V3-Dokumentation oder dem Datentypen-Leitfaden (HL7 Datentypen) zu entnehmen.


Attribute

In den folgenden Abschnitten wird beschrieben, wie die einzelnen Elemente der beschriebenen Diagnosemerkmale, über die Klasse Observation dargestellt werden.


Lvl RIM Name DT Kard Conf Beschreibung
1 act Observation 0..* Diagnose
2 act @moodCode 0..1 F Das Attribut @moodCode beschreibt, wie der Inhalt einer Act-Klasse zu interpretieren ist. Für die Klasse Observation, die eine Diagnose beschreibt, hat das Attribut den festen Wert EVN. Damit wird ausgedrückt, dass es sich um eine Dokumentation eines vorangegangenen Ereignisses handelt, also um die Dokumentation des Ergebnisses einer Beobachtung.

"EVN"

2 act @classCode 0..1 F Das Attribut @classCode spezifiziert den Haupttyp des Akts, der über eine Instanz repräsentiert wird. Über eine Klasse Observation wird immer eine Observation (Beobachtung) dargestellt. Somit hat das Attribut @classCode den festen Wert OBS. In der XML-Struktur wird das Attribut als XML-Attribut des Elements Observation dargestellt.

Die Angabe des Attributs in der XML-Strukur ist optional. Wird es nicht angegeben, geht das empfangende System von dem festen Wert aus und verwendet diesen zur weiteren Verarbeitung.
"OBS"

2 act id SET <II> 0..1 O

Identifikation

Über das Attribut id kann die Diagnose eine eindeutige Identifikation innerhalb eines Systems erhalten. Für die Verarbeitung von Diagnosedaten über ein rechnergestütztes System ist die Vergabe von Ids empfehlenswert, um gezielt auf den Datensatz der Diagnose zugreifen zu können. In der XML-Repräsentation wird die Diagnose-ID im Attribut @extension und die OID des Systems im Attribut @root angegeben. Sollen für Diagnosen später Änderungen oder Löschungen kommuniziert werden, ist eine eindeutige Referenzierung über diese Identifikation unerlässlich.

2 act code CD CWE 1..1 R

Diagnosetyp

Im XML-Attribut @code wird der Klassifizierungscode angegeben im Attribut @codeSystem die OID des Codierungssystems (siehe auch Anhang 10).

3 act @code 1..1 R


3 act @codeSystem 1..1 R
2 act negationInd BL 0..1 O

Negation

Das Attribut @negationInd ist vom Datentyp BL und hat damit die Ausprägungen "true" oder "false". Wird das Attribut mit „true" angegeben, so wird ausgesagt, dass die über die Observation-Klasse beschriebene Beobachtung negiert wird. In Bezug auf die Diagnosendarstellung bedeutet das, dass die beschriebene Diagnose nicht zutrifft. Die Angabe des Attributs ist optional. Wird es nicht angegeben, geht das empfangende System von dem Default-Wert aus und verwendet diesen zur weiteren Verarbeitung. Der Default–Wert ist „false".

2 act statusCode 1..1 F

Status

Über dieses Attribut wird der Status, in dem der beschriebene Act sich befindet, angegeben. Ein Act kann z.B. den Status „new", „active" oder „cancelled" besitzen. Die Beobachtung einer Diagnose wird mit der Dokumentation als abgeschlossene Handlung betrachtet. Somit wird für das Attribut statusCode der feste Wert „completed" vorgegeben.

2 act text ST 0..1 O

Diagnoseerläuterung

Der erläuternde Text zu einer Diagnose wird über das Attribut @text abgebildet. Die strukturierte Darstellung sieht wie folgt aus.

2 act effectiveTime IVL<TS> 0..1

Diagnosezeitraum

Das Attribute effectiveTime der Klasse Observation gibt den Zeitraum an, für den die beschriebene Beobachtung für den Patienten gültig (klinisch relevant) ist bzw. war. In Bezug auf die Darstellung einer Diagnose, handelt es sich um den Diagnosezeitraum, der über das Element effectiveTime abgebildet wird. Über das Unterelement low wird das Startdatum des Zeitraums angegeben, über das Unterelement high das Enddatum. Sowohl das Element low als auch das Element high können alleine angegeben werden.

2 act value CD 0..1 O

Diagnosecode und Text

Die Darstellung eines Diagnosecodes und des zum Code gehörenden Text erfolgt über das Attribut value der Klasse Observation. Das XML-Attribut @code des Elements value enthält den Diagnosecode, das XML-Attribut @displayName enthält den zum Code gehörenden Text. Die strukturierte Darstellung für eine ICD-10 codierte Diagnose sieht wie folgt aus.

3 act @code 1..1 M Diagnosecode
3 act @codeSystem 1..1 M

Codesystem für den Diagnosecode

Im XML-Attribut @codeSystem ist die OID für den ICD-10-GM in der jeweils gültigen Version angegeben.

3 act @codeSystemName 0..1 O

Name des Codesystem für den Diagnosecode

Die Angabe des XML-Attributes @codeSystemName enthält den offiziellen Namen des Codiersystems.

3 act orginalText ST 0..1 O

Freitext

Die Darstellung der Freitextbezeichnung der Diagnose erfolgt über das Element value und dessen Unterelement orginalText. Über das Element orginalText wird die wörtliche Bezeichnung der konkreten Diagnose angegeben, die im Element value codiert dargestellt wird. Ist die Angabe eines Diagnosekodes nicht erforderlich oder ist dieser unbekannt, so ist im Element value das Attribut @nullFlavour mit aufzuführen. Mit diesem Attribut wird das Fehlen der Codierung begründet. Der Wert „NAV" (temporarily unavailable) sagt aus, dass (noch) keine Code-Informationen vorliegen. Weitere mögliche Werte sind der HL7-Dokumentation zu entnehmen.

4 act @language 0..1 O

Sprache

Über das Attribut @language des Element orginalText kann die Sprache des Textinhalts definiert werden.

2 act value 0..1 O Diagnosesicherheit
3 act qualifier CR 0..1 O

Diagnosesicherheit

Die Angabe der Diagnosesicherheit wird über ein Kindelement qualifier des Elements value abgebildet.

4 act name 1..1 R Über das Attribut @code im Element name wird die Bezeichnung für den Qualifier angegeben. Die Diagnosesicherheit wird aus der unten gezeigten Tabelle entnommen. Im Attribut @codeSystem wird die OID der Systems angegeben, welches den Qualifiernamen beinhaltet (s. u.). Die Angabe zur Diagnosesicherheit selbst wird im Attribut @code des Elements value abgebildet.

In der ambulanten Versorgung (§ 295 SGB V) sind die Zusatzkennzeichen für die Diagnosensicherheit obligatorisch. In der stationären Versorgung (§ 301 SGB V) sind die Zusatzkennzeichen für die Diagnosensicherheit verboten, d.h. sie dürfen nicht verwendet werden.


5 act @code 1..1 R
5 act @codeSystem 1..1 R


4 act value 1..1
5 act @code 1..1
5 act @codeSystem 1..1
2 act targetSiteCode CD CWE 0..1 O

Lokalisation

Die Lokalisation zu Diagnosen wird über das Element targetSiteCode angegeben. Wird die Lokalisation im Freitext angegeben, erfolgt die Darstellung über das Unterelement orginalText. Bei fehlender Codierung muss im Element targetSiteCode das Attribut @nullFlavor angegeben werden.

2 act author 0..1 O Das Diagnosedatum wird über die Klasse author dargestellt, welche als Participation mit der Klasse Observation verbunden ist.
3 act @time IVL<TS> 0..1 O

Diagnosedatum

Das Diagnosedatum gibt an, wann die Krankheit diagnostiziert wurde. Das Diagnosedatum muss nicht gleich dem Dokumentationsdatum sein.
Die Klasse author enthält ein Attribut time vom Datentyp IVL <TS>. Nähere Informationen zu der Person, welche die Krankheit diagnostiziert hat, können über die Klasse assignedEntity abgebildet werden.

2 act participant 1..1 DataEnterer
3 act @time TS 1..1 R

Dokumentationsdatum

Das Dokumentationsdatum ist das Datum, an dem die Krankheit z.B. durch einen Arzt dokumentiert wurde. Diese Datumsangabe wird über die Klasse dataEnterer abgebildet, welche als Participation mit der Klasse Observation verknüpft ist (vgl. Abbildung 1: Klasse Observation).

Die Klasse dataEnterer enthält ein Attribut time vom Datentyp TS. D.h., dass in der XML-Struktur die Datumsangabe über einem Element time und dessen Attribute @value abgebildet wird.

Ist keine explizite Klasse dataEnterer vorhanden, so wird eine Participation-Klasse durch die Angabe des Attributes typeCode mit dem Wert ENT zu einer Klasse dataEnterer. Über die Klasse paticipationRole kann die Person näher beschrieben werden.

2 act entryRelationship 0..1 O

Begründung von Ausnahmen

3 act @typeCode 1..1 O Das Attribute @typeCode erhält den Wert RSON (= reason), da es sich um eine Begründung zu Abrechnungszwecken handelt.


3 act observation 0..1 O moodCode="EVN", classCode="OBS"
4 act code 0..1 O nullFlavor="UNK"
4 act value ST 0..1 O

Ausnahmebegründung

Die Begründung der abrechnungsrelevanten Ausnahme wird in dem Attribut @value einer Klasse Observation dargestellt, welche über eine ActRelationship-Klasse mit der diagnosebeschreibenden Klasse Observation verlinkt ist.

Beispiel

<!-- Strukturierte Darstellung der Diagnose -->
<observation moodCode="EVN" classCode="OBS">
	...
	<code code="DX" codeSystem="1.2.276.0.76.5.342"/>

	<statusCode code="completed"/>
	<!-- Diagnosezeitraum -->
	<effectiveTime>
		<low value="20050127"/>
	</effectiveTime>
	<!-- ICD-Code einer Diagnose -->
	<value xsi:type="CD" code="I01.0" 
		displayName="Akute rheumatische Perikarditis"
		codeSystem="1.2.276.0.76.5.311" codeSystemName="icd10gm2006">
		<originalText>......</originalText>
		<!--Diagnosesicherheit-->
		<qualifier>
			<name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/>
		</qualifier>
	</value>
	<text>Intermittierend, seit der Jugend</text>
	<targetSiteCode nullFlavor="NI">
		<originalText>Oberhalb des rechten Knöchels</originalText>
	</targetSiteCode>
	...
	<!-- Dokumentationsdatum -->
	<participant typeCode="ENT">
		<time value="20060606"/>
		<participantRole>
		...
		</participantRole>
	</participant>
	...
	<author>
	<!-- Diagnosedatum -->
		<time value="20060613"/>
		<assignedAuthor>
			...
		</assignedAuthor>
	</author>
	...
	<!-- Ausnahmetatbestand-->
	<entryRelationship typeCode="RSON">
		<observation moodCode="EVN" classCode="OBS">
			<code nullFlavor="UNK"/>
			<value xsi:type="ED">...........</value>
		</observation>
	</entryRelationship>
	...
</observation>


Vokabularien

Sicherheit der Diagnose

Code lt.
§295
SGB V
Umsetzung Bedeutung Erläuterung
G Gesichert Gesicherte Diagnose
V uncertaintyCode = UN Verdacht auf Verdachtsdiagnose
Z Zustand nach Zustand nach
A negationInd = true Ausgeschlossene Erkrankung Ausgeschlossene Erkrankung, gleichzeitig ist dies in Level 3 mittels negationInd anzugeben (siehe auch Hinweis im Text)

Tabelle 2: Vocabulary Domain für Sicherheit/Verlässlichkeit
Codesystem: Sciphox (OID: 2.16.840.1.113883.3.7.1.8)

Sicherung der Diagnose

In der Tumordokumentation wird der Begriff der Sicherung der Diagnose noch durch die Angabe des (höchstwertigen) Diagnoseverfahrens ergänzt. Diese Information wird ebenfalls als Qualifier übermittelt:

Code Umsetzung Bedeutung Erläuterung
k klinisch
z zytologisch
h histologisch
a autoptisch
d DCO Nur auf Leichenschauschein notiert. Death certificate only.
nullFlavor = OTH Sonstiges
nullFlavor = NI unbekannt

Tabelle 3: Vocabulary Domain für Diagnoseverfahren in der Tumordokumentation
Codesystem: (OID: 1.2.276.0.76.5.418)

Lokalisation der Diagnose

Wird die Lokalisation über einen Code oder Zusatzcode ausgedrückt, so wird der Code im Attribut @code und das verwendete Codiersystem über das Attribut @codeSystem angegeben. Optional kann über das Attribut @displayName der zum Code gehörende Text angegeben werden und über das Attribut @codeSystemName der Name des Codiersystems

<!-- Strukturierte Darstellung der Diagnose -->
<observation moodCode="EVN" classCode="OBS">
	...
	<targetSiteCode code="299058009" codeSystem="2.16.840.1.113883.6.96" 
		codeSystemName="SNOMED CT" displayName="kleiner Finger">
		<qualifier>
			<name code="78615007" codeSystem="2.16.840.1.113883.6.96" 
				codeSystemName="SNOMED CT" displayName="mit Seitenlokalisation"/>
			<value code="24028007" codeSystem="2.16.840.1.113883.6.96" 
				codeSystemName="SNOMED CT" displayName="rechts"/>
		</qualifier>
	</targetSiteCode>
	...
</observation>

Anmerkung: Die vom BMG vorgeschlagenen Codes sollten auch nur im Zusammenhang mit ICD-10 codierten Diagnosen verwendet werden. Die Zusatzkennzeichen für die Seitenlokalisation dürfen sowohl in der ambulanten als auch in der stationären Versorgung verwendet werden. In anderen Fällen sollten andere Codierungsschemata Anwendung finden. In der Tumordokumentation werden weitere Codierungen für die Seitenangabe verwendet:


Code Umsetzung Bedeutung Erläuterung allg. Tumordok.
R Rechts Seitenlokalisation rechts X X
L Links Seitenlokalisation links X X
B beidseits beidseitiges Auftreten X X
M Mittellinie Mittellinienzone (je 2cm rechts oder links d. Mittellinie) X
nullFlavor = NA Systemerkrankung (bzw. im Sinne von „nicht zutreffend") X
nullFlavor = UNK Unbekannt X X

Tabelle 4: Vocabulary Domain für Lokalisation Codesystem: (OID: 1.2.276.0.76.5.412)

Die Seitenlokalisation wird in der allgemeinen Diagnosedokumentation und der Tumordokumentation mit unterschiedlichen Werten eingesetzt. Diese beiden Value Sets sind in den beiden rechten Spalten dargestellt. Nachfolgend die Spezifikation der dazu¬gehörigen Value Sets:

Value Set Erläuterung OID
Allgemein nach ICD-10 2.16.840.1.113883.3.7.1.7
Tumordokumentation 1.2.276.0.76.11.10

Tabelle 5: Value Sets für Lokalisation



Beispiele

Freitext

<!-- Strukturierte Darstellung der Diagnose -->
<observation moodCode="EVN" classCode="OBS">
  ...
  <value xsi:type="CD" nullFlavor="NAV">
    <originalText>
      Rektumkarzinom mit Höhenlokalisation ab Anokutanlinie/Linea dentata
    </originalText>
  </value>
</observation>

Abbildung einer ICD-10 codierten Diagnose in HL7 V3

Bei der strukturierten Darstellung einer ICD-10 codierten Diagnose muss es möglich sein, zwei ICD-Codes (Primär-, Sekundärcode), mit den beschriebenen Eigenschaften (Codeerweiterung, Seitenlokalisation, Diagnosesicherheit) abbilden zu können. Der Primärcode kennzeichnet dabei die Grunderkrankung. Der Sekundärcode wird als Zusatzangabe zum Primärcode verstanden, da er entweder dazu verwendet wird Organmanifestationen näher zu beschreiben (Stern-Code) und/oder den Auslöser (Ätiologie, z. B. welcher Erreger) einer Krankheit näher zu spezifizieren (Ausrufezeichen).

Um diese Abhängigkeit darzustellen, wird der Sekundärcode über eine weitere Klasse Observation abgebildet, welche über eine ActRelationship–Klasse mit der Klasse Observation referenziert, die den Primärcode beinhaltet. Daraus leitet sich folgende Grundstruktur einer ICD-10 verschlüsselten Diagnose ab.

ICD-10 Diagnose

Abbildung 2: Blockdiagramm ICD-10 Diagnose

Über das Attribut typeCode der ActRelationship-Klasse soll die Codeerweiterung abgebildet werden. Über die Klasse Observation, die über eine ActRelationship-Klasse mit dem typeCode MFST (Manifestation) eingebunden wird, werden Sterncodes dargestellt. Codes mit einem Ausrufezeichen als Codeerweiterung werden in einer Klasse Observation abgebildet, die über eine ActRelationship-Klasse mit dem typeCode CAUS (Ursache) eingebunden werden. Die XML-Struktur einer ICD-10 codierten Diagnose sieht demnach wie folgt aus:

<!-- Strukturierte Darstellung der Diagnose-->
<observation moodCode="EVN" classCode="OBS">
		<!-- Primärcode-->
	<value xsi:type="CD" code=" E14.30" codeSystem=" 1.2.276.0.76.5.311"/>
	<entryRelationship typeCode="MFST">
		<observation moodCode="EVN" classCode="OBS">
						<!-- Sekundärcode-->
			<value xsi:type="CD" code=" H28.0" codeSystem=" 1.2.276.0.76.5.311"/>
		</observation>
	</entryRelationship>
</observation>

In diesem Fall ist die einbindende ActRelationship-Klasse die Klasse entryRelationsship, welche durch das gleichnamige Element repräsentiert wird. Das Attribute @typeCode erhält den festen Wert MFST, womit auf einen Sterncode verwiesen wird.


Lvl RIM Name DT Kard Conf Beschreibung
1 act value 1..1 M
2 act @code ST 1..1 M ICD-Code

Das XML-Attribut @code enthält den ICD-10 Code.

2 act @codeSystem UID 1..1 M OID der ICD-10 Version

Das XML-Attribut @codeSystem enthält die OID der verwendeten ICD Version, mit der auf die ICD-10 GM verwiesen wird. Hinweise zu gültigen Codesystemen sind im Anhang genannt.

2 act @codeSystemName ST 0..1 optional Name der ICD-10 Version

Im XML-Attribut @codeSystemName kann der Name der aktuellen ICD-10 Version angeben werden.

2 act @displayName ST 0..1 optional ICD-Code -Text

Im XML-Attribute @displayName kann, der zum ICD-Code gehörende Text angegeben werden.
Die OID und die Bezeichnung der ICD-10 Version(en) können von der Internetseite des DIMDIs bezogen werden.

Darstellung der Seitenlokalisation

Lvl RIM Name DT Kard Conf Beschreibung
1 act value 0..1 O
2 act qualifier CR 0..1 O Seitenlokalisation

Die Abbildung des Seitenlokalisationscode erfolgt über ein Kindelement qualifier des Elements value, da er eine nähere Beschreibung des Diagnosecodes ist . Die Darstellung sieht wie folgt aus:

<!-- Strukturierte Darstellung der Diagnose -->
<observation moodCode="EVN" classCode="OBS">
	<code code="DX" codeSystem=""/>
	<!-- Primärcode-->
	<value xsi:type="CD" code="E14.30" codeSystem="1.2.276.0.76.5.311">
		<qualifier>
			<name code="7" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="L" codeSystem="2.16.840.1.113883.3.7.1.7"/>
		</qualifier>
	</value>
	<entryRelationship typeCode="CAUS">
		<observation moodCode="EVN" classCode="OBS">
			<code/>
			<!-- Sekundärcode-->
			<value xsi:type="CD" code="H28.0" codeSystem="1.2.276.0.76.5.311">
				<qualifier>
					<name code="7" codeSystem="2.16.840.1.113883.3.7.1.0"/>
					<value code="B" codeSystem="2.16.840.1.113883.3.7.1.7"/>
				</qualifier>
			</value>
		</observation>
	</entryRelationship>
</observation>

Über das Kindelement name des Elements qualifier wird die Art des Qualifiers bezeichnet. Um auszudrücken, dass es sich um einen Qualifier zur Seitenlokalisation handelt, muss hier „7" angegeben mit Codesystem OID 2.16.840.1.113883.3.7.1.0 angegeben werden:

<qualifier>
	<name code="7" codeSystem="2.16.840.1.113883.3.7.1.0"/>
	<value code="L" codeSystem="2.16.840.1.113883.3.7.1.7"/>
</qualifier>

Darstellung der Diagnosesicherheit

Lvl RIM Name DT Kard Conf Beschreibung
1 act value 0..1 O Diagnosesicherheit
2 act @qualifier CR 0..1 O Diagnosesicherheit

Die Angabe der Diagnosesicherheit, welche als „Anhang" zu einem ICD-Code mit angegeben werden kann, wird über ein Kindelement qualifier des Element value abgebildet.

<!-- Strukturierte Darstellung der Diagnose-->
<observation moodCode="EVN" classCode="OBS">
	<code code="" codeSystem=""/>
	<!-- Primärcode-->
	<value xsi:type="CD" code="E14.30" codeSystem="1.2.276.0.76.5.311">
		<qualifier>
			<name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/>
		</qualifier>
	</value>
	<entryRelationship typeCode="CAUS">
		<observation moodCode="EVN" classCode="OBS" negationInd="true">
			<code/>
		<!-- Sekundärcode-->
			<value xsi:type="CD" code="H28.0" codeSystem="1.2.276.0.76.5.311">
				<qualifier>
					<name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
					<value code="A" codeSystem="2.16.840.1.113883.3.7.1.8"/>
				</qualifier>
			</value>
		</observation>
	</entryRelationship>
</observation>

Über das Kindelement name des Elements qualifier wird die Art des Qualifiers bezeichnet. Als fixer Wert bei der Angabe der ICD-Code Erweiterung muss hier „8" angegeben werden. Im Kindelement value des Elements qualifier wird der entsprechende Wert angegeben. Die zulässigen Werte sind in Tabelle 2 zusammengefasst.

<observation classCode="OBS" moodCode="EVN">
	...
	<value xsi:type="CD" code="A25.1" codeSystem="1.2.276.0.76.5.311" 
			codeSystemName="icd10gm2006">
		<qualifier>
			<name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/>
		</qualifier>
	</value>
</observation>

Bei der Angabe einer ausgeschlossenen Diagnose muss das Attribut @negationInd mit dem Wert „true" angegeben werden.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Allergien, Unverträglichkeiten, Risiken

In diesem Abschnitt (auch CAVE genannt) werden

  • Hinweise zu Risikofaktoren beim Patienten und
  • Allergien

abgebildet.

Id1.2.276.0.76.10.3028Gültigkeit2013‑12‑30
StatusKgreen.png AktivVersions-Label
NameAllergiesintolerancesriskssectionBezeichnungAllergien, Unverträglichkeiten, Risiken
BeschreibungBeschreibung der Allergien, Unverträglichkeiten und Risiken und deren beobachteten Nebenwirkungen, sowie sonstiger Risiken.
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<section>
  <templateId root="1.2.276.0.76.10.3028"/>  <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <title>Allergien, Unverträglichkeiten, Risiken</title>  <text>Penicillinallergie</text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(All...ion)
Treetree.pnghl7:templateId
II1 … 1(All...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3028
Treetree.pnghl7:code
CE1 … 1M(All...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F48765-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(All...ion)
 CONF
Elementinhalt muss "Allergien, Unverträglichkeiten, Risiken" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(All...ion)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Prozeduren und Maßnahmen

In dem Abschnitt Prozeduren und Maßnahmen werden u. a.

  • Fachspezifische Eingriffe
  • Operationen
  • Strahlentherapie
  • Lichttherapie
  • Psychiatrische Therapie

abgebildet.

Damit ist die Weitergabe von Freitextprozeduren oder Prozeduren ohne OPS möglich.

Id1.2.276.0.76.10.3032Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Proceduressection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameProceduressectionBezeichnungProzeduren und Maßnahmen
BeschreibungKurzbeschreibung sämtlicher während des Aufenthalts durch-geführten Maßnahmen, wie OPs, Eingriffe oder sonstige Maßnahmen.
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Pro...ion)
Treetree.pnghl7:templateId
II1 … 1(Pro...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3032
Treetree.pnghl7:code
CE1 … 1M(Pro...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F29554-3
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Pro...ion)
 CONF
Elementinhalt muss "Prozeduren und Maßnahmen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Pro...ion)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Entry: Massnahme

Template-Metadaten
Template-Typ Entry
Template ID
generischeres Template
genutztes Templates
nutzende Templates
abgeleitete Templates
Schwester-Templates
generelle Beschreibung Dieser Abschnitt enthält Informationen über Massnahmen.
allg. Erläuterung
Verhältnis zu IHE dt.Übersetzung oder Ergänzung oder neu
Ballotierungsstatus
Erweiterbarkeit offen oder geschlossen

Beschreibung

Diese Act-Relationship-Klasse ist die Einleitung für die strukturierten, maschinenlesbaren Teile des Dokumentes. Sie stellt die Verbindung zwischen dem Text in einer Sektion und den Detailinformationen auf Level 3 her. Hierbei müssen die Maßnahmen innerhalb der Sektion stehen.

Modell

Cdaab2 procedure.gif

Attribute

Lvl RIM Name DT Kard Conf Beschreibung
6 act procedure ST 0..1 O
7 act moodCode 1..1 F Mood-Code <= EVN

Der Mood-Code der hier spezifizierten Prozeduren ist immer EVN (Event), da es sich immer um stattgefundene Prozeduren handelt.


7 act id SET<II> 0..* O Prozedur-Identifikationsnummer

Es ist empfehlenswert, jeder Einzelprozedur in einem Anwendungssystem eine Identifikation zuzuordnen (II). Damit wird eine gezielte Prozeduren-Kommunikation möglich, zum Beispiel das Zuordnen von Prozeduren beim Update / Änderung bzw. Löschen von Angaben.

7 act code CD CWE 1..1 R Prozedur-Klassifizierung (Prozedurtyp)

Hiermit wird der Typ der Prozedur spezifiziert. Für die Codierung der Prozeduren muss der OPS in der deutschen Fassung [ops2006], mit der OID 1.2.276.0.76.5.310 benutzt werden. Neben den verpflichtend anzugebenden OPS-Codes können auch zusätzlich alternative Codierungen spezifiziert werden. Diese werden als Übersetzung (translation) zusammen mit dem ursprünglichen Code angegeben.

7 act @negationInd BL 0..1 O Negations-Indikator

Wenn der negationInd auf true gesetzt ist, wird die Prozedur negiert/verneint. Das Modelattribut negationInd ist als Structural Attribute im root Element der Procedure zu finden (siehe unten). Wenn negationInd auf „true“ gesetzt ist, bedeutet dies, dass die Behandlungsmaßnahme als Ganzes negiert wird. Davon sind andere Eigenschaften wie Procedure.id oder Procedure.code und eventuelle Beteiligte nicht berührt. Diese Eigenschaften behalten ihre Bedeutung. Zum Beispiel bleibt der Autor ein Autor trotz einer negierten Prozedur. Eine negierte „Appendektomie“ beispielsweise bedeutet, dass der Autor bestätigt, dass diese nicht stattgefunden hat und dass er dies mit derselben Bestimmtheit sagen kann, als wäre die Behandlungsmaßnahme nicht negiert. Hinweis: Kann die Information des negationInd vom empfangenden System nicht korrekt angezeigt und verarbeitet werden, muss der dazugehörige Text von Level 2 angezeigt werden.

7 act text ED 0..1 O ergänzende Erläuterungen zur Prozedur

Hier können ergänzende (ausführlichere) Erläuterungen zur Prozedur angegeben werden, so vorhanden. Die Prozedur in Textform (Langtext) ist nicht der Text aus dem Codierschlüssel des OPS, sondern enthält zusätzliche Informationen.

7 act statusCode 1..1 F Statuscode <= completed

Der statusCode der hier spezifizierten Prozeduren ist immer completed, da es sich immer um eine abgeschlossene Behandlungsmaßnahme handelt.

7 act effectiveTime IVL<TS> 0..1 O Zeitangabe Prozedur

Zeitangaben, von wann an (bis wann) die Prozedur durchgeführt wurde. Dies ist in der Regel ein Zeitpunkt.

7 act priorityCode O Priorität
7 act languageCode 0..1 O Sprachcode
7 act methodCode SET<CE> CWE 0..* O Klassifizierung der Methode

Hier wird die Methode näher spezifiziert, mit der die Behandlung durchgeführt wurde bzw. das Ergebnis erreicht wurde. Das Attribut wird im Rahmen dieses Leitfadens zunächst nicht verwendet. Beim OPS Code ist die Behandlungsmethode bereits im Code enthalten.

7 act approachSiteCode SET<CE> CWE 0..* O Klassifizierung der Zugangsmethode

Der anatomische Situs oder das System, über das die Behandlungsmaßnahme ihr Ziel erreicht. Zum Beispiel kann eine Nephrektomie als transabdominaler Eingriff oder mit retroperitonealem Zugang ausgeführt werden. Dieses Klassenattribut wird im Rahmen dieses Leitfadens zunächst nicht verwen-det. Beim OPS Code ist die Zugangsmethode bereits im Code enthalten.

7 act targetSiteCode SET<CE> CWE 0..* O Klassifizierung der Zielgebiets

Der anatomische Situs oder das System, auf das die Behandlungsmaßnahme abzielt. Dieses Klassenattribut wird im Rahmen dieses Leitfadens zunächst nicht verwendet.


Beispiel

<entry>
  <!-- Massnahme -->
  <procedure moodCode='EVN' >
    <id root="9.9.9.9.9.9" extension ="abcde" />
    <code code="73761001" codeSystem="2.16.840.1.113883.6.96" displayName="Colonoscopy"/>
    <statusCode code='completed' />
    <effectiveTime value='201408121200' />
  </procedure>
</entry>
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Notiz

Template-Metadaten
Template-Typ Section
Template ID
generischeres Template
genutztes Templates
nutzende Templates
abgeleitete Templates
Schwester-Templates
Generelle Beschreibung Dieser Abschnitt enthält allgemeine Notizen.
allg. Erläuterung
Verhältnis zu IHE neu
Ballotierungsstatus in Arbeit
Erweiterbarkeit offen

Beschreibung

In dem Abschnitt Notizen werden die medizinischen Informationen abgebildet, die keiner anderen Komponente zugewiesen werden können. Hierfür ist kein LOINC Code für die Sektion vorgesehen, das code Element wird weggelassen. Innerhalb des text Elementes kann eine der bekannten Strukturen verwendet werden.


Attribute

Lvl RIM Name DT Kard Conf Beschreibung
1 act section 1..1 M Abschnitt mit Notizen
2 act templateID 1..1 F
2 act code 1..1 F
2 act title 0..1 F Notizen
2 act text 1..1 M Notizen in textueller Form

Vokabularien

keine

Beispiel

<component>
  <section>
    <templateID root=""/>
    <title>Notizen</title>
    <text>
             ....
    </text>
  </section>
</component>
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Epikrise (Zusammenfassung des Aufenthalts)

Id1.2.276.0.76.10.3021Gültigkeit2013‑09‑16
StatusKgreen.png AktivVersions-Label
NameHospitalcoursesectionBezeichnungZusammenfassung des Aufenthalts
Beschreibung
Im Abschnitt Epikrise / Zusammenfassung des Aufenthalts wird ein spezieller zusammenfassender Rückblick, eine Interpretation des Krankengeschehens sowie der veranlassten Therapie, erfasst, welches für den weiterbehandelnden Arzt gedacht ist.
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungAdaptation: Template 1.3.6.1.4.1.19376.1.5.3.1.3.5 Hospital Course Section (DYNAMIC)
ref
bccdapilot-

Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<section>
  <templateId root="1.2.276.0.76.10.3021"/>  <code code="8648-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <title>Epikrise</title>  <text>Sollten nach der empfohlenen Medikation mit Atemur die klinischen Zeichen weiterhin bestehen, halte ich bei dem umfangreichen Risikoprofil einen Kuraufenthalt für zwingend erforderlich. Ich bitte dann um Wiedervorstellung des Patienten.</text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Hos...ion)
Treetree.pnghl7:templateId
II1 … 1(Hos...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3021
Treetree.pnghl7:code
CE1 … 1M(Hos...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F8648-8
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Hos...ion)
 CONF
Elementinhalt muss "Epikrise" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Hos...ion)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Medikationen

In diesem Leitfaden werden folgende Templates zu Medikations-Informationen unterstützt:

Medikation bei Einweisung (Historie)

Id1.2.276.0.76.10.3029Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Admissionmedicationsection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameAdmissionmedicationsectionBezeichnungMedikation bei Einweisung (Historie)
BeschreibungErhobene Medikation bei Aufnahme des Patienten.
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Adm...ion)
Treetree.pnghl7:templateId
II1 … 1(Adm...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3029
Treetree.pnghl7:code
CE1 … 1M(Adm...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F42346-7
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Adm...ion)
 CONF
Elementinhalt muss "Medikation bei Aufnahme" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Adm...ion)

Verabreichte Medikation während des Aufenthalts

Id1.2.276.0.76.10.3030Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Medicationduringstaysection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameMedicationduringstaysectionBezeichnungVerabreichte Medikation während des Aufenthalts
BeschreibungSämtliche verabreichte Medikation während des Aufenthalts
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
0 … *(Med...ion)
Treetree.pnghl7:templateId
II1 … 1R(Med...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3030
Treetree.pnghl7:code
CE1 … 1M(Med...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F29549-3
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Med...ion)
 CONF
Elementinhalt muss "Verabreichte Medikation während des Aufenthalts" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Med...ion)

Medikation bei Entlassung

Id1.2.276.0.76.10.3031Gültigkeit2013‑12‑30
Andere Versionen mit dieser Id:
  • Kblank.png Dischargemedicationsection vom 2017‑02‑01
StatusKgreen.png AktivVersions-Label
NameDischargemedicationsectionBezeichnungMedikation bei Entlassung
BeschreibungMedikation bei Entlassung
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Dis...ion)
Treetree.pnghl7:templateId
II1 … 1(Dis...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3031
Treetree.pnghl7:code
CE1 … 1M(Dis...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F10183-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(Dis...ion)
 CONF
Elementinhalt muss "Medikation bei Entlassung" sein
Treetree.pnghl7:text
SD.TEXT1 … 1M(Dis...ion)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Labordaten

Template-Metadaten
Template-Typ Section
Template ID
generischeres Template
genutztes Templates Laborbefund Entry Template
nutzende Templates
abgeleitete Templates
Schwester-Templates
generelle Beschreibung Dieser Abschnitt enthält Informationen über Labordaten.
allg. Erläuterung
Verhältnis zu IHE dt.Übersetzung oder Ergänzung oder neu
Ballotierungsstatus
Erweiterbarkeit offen oder geschlossen

Beschreibung

Laborbefunde im Sinne von Ergebniszusammenfassungen und Beurteilungen für in-vitro Probenanalysen inklusive Mikrobiologie werden im elektronischen Arztbrief im Idealfall

  • in Level 1 & 2 tabellarisch angegeben,
  • in Level 3 codiert und mit dem entsprechenden Ergebniswert und Ergebniseinheit angegeben.

In der Regel liegen Laborergebnisse schon in hochstrukturierter Form in den Anwendungssystemen vor, der narrative Teil (z. B. tabellarische Darstellung) ist daher meist aus der strukturierten Information abgeleitet. Dies wird mit dem @typeCode DRIV (derived from) im entry Element angedeutet.

Laborergebnisse sind Spezialformen von Beobachtungen (Observation), weshalb zur Level 3 Wiedergabe von Laborergebnissen die entsprechende RIM-Klasse aus dem CDA Modell genutzt wird.

Beispiel

Test Beschreibung Wert Einheit Normbereich
ERY Erythrozyten 4.37 10*12/l 4.2 - 6.2
HB Hämoglobin 12.6 g/dl 14 - 18
...


<component>
  <!-- Labordaten -->
  <section>
    <code code="18723-7" codeSystem="2.16.840.1.113883.6.1"
          codeSystemName="LOINC"/>
    <title>24.09.2006: Laborwerte</title>
    <text>
      <paragraph>Wir berichten kurz zusammenfassend über die
                Laborergebnisse des obigen Patienten.</paragraph>
      <table border="1">
        <thead>
          <tr>
            <th>Test</th>
            <th>Beschreibung</th>
            <th>Wert</th>
            <th>Einheit</th>
            <th>Normbereich</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>ERY</td>
            <td>Erythrozyten</td>
            <td>4.37</td>
            <td>10*12/l</td>
            <td>4.2 - 6.2</td>
          </tr>
          <tr>
            <td>HB</td>
            <td>Hämoglobin</td>
            <td>12.6</td>
            <td>g/dl</td>
            <td>14 - 18</td>
          </tr>
          ...
        </tbody>
      </table>
    </text>
    ...
  </section>
</component>
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Abschließende Bemerkungen (Schlusstext)

Id1.2.276.0.76.10.3034Gültigkeit2013‑12‑30
StatusKgreen.png AktivVersions-Label
NameFinalremarkssectionBezeichnungAbschließende Bemerkungen
BeschreibungEin am Ende des Briefes formulierter Freitext entsprechend einer Grußformel, z.B.: "mit kollegialen Grüßen
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:section
(Fin...ion)
Treetree.pnghl7:templateId
II1 … 1(Fin...ion)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3034
Treetree.pnghl7:code
CE1 … 1M(Fin...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1FX-FINREM
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST0 … 1(Fin...ion)
Treetree.pnghl7:text
SD.TEXT1 … 1M(Fin...ion)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Anhang (Beilagen)

Id1.2.276.0.76.10.3037Gültigkeit2014‑08‑25
StatusKgreen.png AktivVersions-Label
NameBeilagenBezeichnungBeilagen/Anhang
Beschreibung
Sonstige Beilagen/Anhänge, außer denjenigen Dokumenten, die in „Patientenverfügungen und andere juridische Dokumente“ angegeben sind.
Diese Section sollte (mind.) ein Entry enthalten.
Die Anhänge können entweder als Referenz oder als direkte Inklusion des Objektes übermittelt werden.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.3037
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.4014ContainmentKyellow.png Eingebettetes Objekt EntryDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-
Beispiel
Beispiel
<section>
  <templateId root="1.2.276.0.76.10.3037"/>  <code code="X-OBSMED" displayName="Beilagen" codeSystem="2.16.840.1.113883.6.1"/>  <title>Beilagen/Anhänge</title>  <text>Bild vom Befund an der linken Hand</text>  <entry>
    <!-- template 1.2.276.0.76.10.4014 'Eingebettetes Objekt Entry' (dynamic) -->
  </entry>
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Bei...gen)
Treetree.pnghl7:templateId
II1 … 1(Bei...gen)
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3037
Treetree.pnghl7:code
CE1 … 1M(Bei...gen)
Treeblank.pngTreetree.png@code
CONF1 … 1FX-OBSMED
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
 Beispiel<code code="X-OBSMED" displayName="Beilagen" codeSystem="2.16.840.1.113883.6.1"/>
Treetree.pnghl7:title
ST1 … 1(Bei...gen)
 CONF
Elementinhalt muss "Beilagen/Anhänge" sein
Treetree.pnghl7:text
SD.TEXT1 … 1(Bei...gen)
Treetree.pnghl7:entry
0 … 1Beinhaltet 1.2.276.0.76.10.4014 Eingebettetes Objekt Entry (DYNAMIC)(Bei...gen)


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anhang

Referenzen

  1. Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)
  2. HL7 Deutschland e. V. http://www.hl7.de
  3. Erstellung von XML-Signaturen für Dokumente nach Clinical Documents Architecture – R2 (Elektronische Signatur von Arztbriefen). Spezifikation der Bundesärztekammer, Ärztekammer Nordrhein, Ärztekammer Westfalen-Lippe. Version 1.4 vom 20. Mai 2008
  4. IHE Deutschland: Cookbook http://wiki.hl7.de/index.php?title=IHE_DE_Cookbook
  5. Arztbrief des VHitG (jetzt bvitg), http://www.bvitg.de/arztbrief.html


Referenzfehler: Es sind <ref>-Tags für die Gruppe „Abbildung“ vorhanden, jedoch wurde kein dazugehöriges <references group="Abbildung" />-Tag gefunden oder ein schließendes </ref> fehlt.
Referenzfehler: Es sind <ref>-Tags für die Gruppe „Tabelle“ vorhanden, jedoch wurde kein dazugehöriges <references group="Tabelle" />-Tag gefunden oder ein schließendes </ref> fehlt.