Grundlagen

Dieses Material ist Teil des Leitfadens Elektronischer Mutterpass. 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 .

Grundlagen

Verwendete Datentypen (HL7 Version 3)

Die am häufigsten verwendeten Datentypen dieser Arbeit, werden im Folgenden erläutert. Nähere Informationen zu den verwendeten Datentypen sind dem Datentypen und CMETs Leitfaden der HL7-Benutzergruppe in Deutschland zu entnehmen.

Instance Identifier (II)

Um ein Dokument in einem System wie dem deutschen Gesundheitswesen oder sogar weltweit eindeutig zu benennen, damit man später die Dokumente noch zuordnen kann, hat man das Konzept der OIDs (Object Identifier) entwickelt.

Die Instance Identifier setzen sich aus einer „root-OID" und einer „Extension" zusammen.

<id root="2.16.840.1.113883.3.37.6.2.23.1" extension="4873329"/>

Die root-OID ist die ausgebende Instanz, das @extension Attribut ist der eindeutige Identifier innerhalb dieser Instanz. Es muss also eine zentrale Institution geben, die allen Instanzen (Organisationen) eine eindeutige root-OID vergibt, damit ausgeschlossen werden kann, dass zwei Organisationen die gleiche root-OID besitzen. Aus diesem Grund müssen alle ausgegebenen OIDs bei der deutschen zentralen Verwaltungsstelle für OIDs (“OID Registratur DE”) gemeldet werden. DIN Kodierschemas, die im Gesundheitswesen eingesetzt werden, erhalten OIDs von der OID Registratur DE Gesundheitswesen.

Siehe auch Instance Identifier (Datentypen).

Concept Descriptor (CD)

Um Daten zwischen verschiedenen Systemen austauschen zu können, werden die verschiedenen Untersuchungen durch eindeutige Codes spezifiziert. Das Problem bei der Verwendung von Kodierungen ist, die Eindeutigkeit der verschiedenen Codes zu gewährleisten. Deshalb verwendet HL7 und CDA den Datentyp CD. Durch Angabe des zugrunde liegenden Kodiersystems kann der Code eindeutig bestimmt werden. Das Kodiersystem wird durch eine OID, wie es auch bei den Instance Identifier üblich ist, eindeutig bestimmt. Optional kann noch der Name des Codesystems und der Displayname angegeben werden. Ein typisches Beispiel für einen Concept Descriptor ist die Angabe des Geschlechts.

Beispiel für den Datentyp „Concept Descriptor“ anhand der Geschlechtsangabe

---

<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" codeSystemName="administrativeGender" displayName="Geschlecht"/>

Siehe auch Concept Descriptor (Datentypen).

Numerische Datentypen

Numerische Datentypen wie Integer (INT) dienen dazu Zahlenwerte auszudrücken.

TimeStamp (TS)

Der Datentyp TS lässt mehrere mögliche gültige Zeitangaben zu. Ein typisches Anwendungsbeispiel für diesen Datentyp ist das Erstellungsdatum des Mutterpasses. Dieses sollte mindestens tagesgenau sein, also ein Jahr, Monat und Tag enthalten. Weiterhin besteht die Möglichkeit auch Stunden und Minuten anzugeben.

Beispiel für den Datentyp „TimeStamp“ anhand des Erstellungsdatums

---

<effectiveTime value="200610112014"/>

Siehe auch Time Stamp (Datentypen).

CDA

Die Clinical Document Architecture (CDA) ist ein Standard, der die Struktur und die Semantik von Dokumenten spezifiziert, die im medizinischen (klinischen) Bereich für den Datenaustausch eingesetzt werden.

Der CDA-Standard wurde innerhalb der HL7 Gruppe erarbeitet und stellt seit HL7 Version 3 eine vollständig XML-basierte Lösung dar. Bei einem CDA-Dokument handelt es sich um ein definiertes und komplettes Informationsobjekt, das Texte, Bilder, Klänge und andere multimediale Objekte enthalten kann. Der klinische Inhalt der CDA Dokumente wird über das HL7 Referenzmodell (RIM) definiert bzw. leitet sich aus diesem ab.

Eine CDA-Instanz muss sowohl gegen das CDA Schema validieren, als auch dem hierarchischen Aufbau von CDA folgen. Die CDA hierarchische Beschreibung wird vom CDA R-MIM abgeleitet, welche wiederum vom HL7 Referenz Information Model (RIM) abgeleitet wird. Die HL7 RIM ist die maßgebliche Quelle für den Aufbau der Klassen und Attributbeschreibungen.

Ein klinisches Dokument in CDA hat folgende Eigenschaften:

• Persistenz - Ein klinisches Dokument bleibt für einen bestimmten Zeitraum in einem unveränderten Zustand. Dieser Zeitraum wird durch lokale und regelnde Anforderungen definiert.
• Verantwortung - Ein klinisches Dokument wird durch eine Person oder Organisation verwaltet, die mit der Pflege des Dokumentes betraut ist.
• Möglichkeit zur Authentisierung - Ein klinisches Dokument ist eine Sammlung von Informationen, bei der eine gesetzlich gültige Authentisierungsmöglichkeit gegeben ist.
• Kontext – Alle Informationen, die innerhalb des Dokumentes gespeichert sind, wurden in einem bestimmten Kontext gespeichert. Im Fall des Mutterpasses ist der Kontext die Geburt des Kindes.
• Ganzheit der Authentisierung - Authentisierung eines klinischen Dokumentes trifft auf das Dokument als Ganzes zu und nicht nur auf einzelne Teile, die dem Kontext entnommen werden.
• Menschliche Lesbarkeit - Ein klinisches Dokument ist durch Verwendung allgemein verfügbarer Internet-Browser bzw. Druckertreiber und durch die Anwendung von XSL- Stylesheets für den Menschen lesbar.

CDA-Struktur

Ein CDA Dokument wird durch das ClinicalDocument-Element verankert und enthält einen Header und einen Body. Der Header liegt zwischen dem Wurzelelement ClinicalDocument und dem Body, welcher mit dem Tag structuredBody eingeleitet wird. Der Header identifiziert, klassifiziert und authentifiziert das Dokument.

In ihm werden die Informationen zum Ereignis (z. B. Untersuchung) sowie Informationen über die Erbringer (z. B. Arzt) und Empfänger (z. B. Patienten) einer Maßnahme festgehalten. Damit beinhaltet der Header die sogenannten Metadaten, die benötigt werden, um die Daten innerhalb des Dokumentes später noch klassifizieren und zuordnen zu können.

Der Body enthält den klinischen Report und muss als menschenlesbarer Text vorhanden sein. Zusätzlich kann er strukturierte Tags (Markups) beinhalten. Das Beispiel zeigt einen strukturierten Body, der durch das Element structuredBody eingeschlossen wird, und durch rekursiv ineinander verschachtelte Dokumentabschnitte unterteilt ist. Ein CDA Dokumentabschnitt wird durch das Element section eingeschlossen. Jeder Abschnitt muss einen einzelnen narrativen Block enthalten. Darüber hinaus ist es möglich alle Informationen aus dem narrativen Teil als maschinenlesbaren Inhalt einzufügen. Dafür steht eine Vielzahl von Möglichkeiten innerhalb von CDA zur Verfügung.

Schematischer Aufbau eines CDA-Dokumentes

<ClinicalDocument> // An dieser Stelle steht der Header mit den Metainformationen // z. B. die Informationen über den Patienten <structuredBody> <section> <text>...</text> <observation>...</observation> <substanceAdministration> <supply>...</supply> </substanceAdministration> <observation> <externalObservation>... </externalObservation> </observation> </section> <section> <section>...</section> </section> </structuredBody> </ClinicalDocument>

Header

Body

Sections

Entries

Der CDA narrative Block wird durch das text-Element innerhalb des section-Elements umschlossen und enthält den menschlich lesbaren Inhalt. CDA-Entries stellen den strukturierten Inhalt dar, der für die weitere Computerverarbeitung bereitgestellt wird. CDA-Entries kodieren für gewöhnlich den Inhalt, der im narrativen Block des gleichen Abschnitts vorhanden ist. Das Beispiel zeigt zwei Beobachtungen als CDA-Entries vom Typ observation sowie ein substanceAdministration-Element, das einen verschachtelten supply-Entry enthält. CDA Entries können ineinander verschachteln werden und auf externe Objekte verweisen. Externe CDA-Verweise treten immer innerhalb des Kontextes eines CDA-Entry auf. Externe Verweise beziehen sich auf Inhalt, der außerhalb dieses CDA-Dokumentes liegt, wie z. B. ein Bild oder ein anderes CDA-Dokument. Referenziertes Material wird nicht durch die Authentisierung des Dokumentes abgedeckt aus dem heraus der Verweis stattfindet.

CDA- Wurzelement

Wie aus dem unten stehenden Codefragment ersichtlich ist, setzt sich ein CDA-Dokument aus einem CDA-Header und einem CDA-Body zusammen. Des Weiteren werden allgemeine Dinge in dem Wurzelelement ClinicalDocument festgehalten, das sich noch über dem eigentlichen Header befindet.

Allgemeiner Aufbau eines CDA-Dokumentes in XML-Notation

---

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

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

  &lt;!-- CDA Header --&gt;
	
  &lt;!-- CDA Body --&gt;

</ClinicalDocument>

Zu den Informationen im Wurzelelement gehören die Definition des Namespaces, die Festlegung des verwendeten Zeichensatzes und Festlegungen zu den verwendeten Datentypen.

XML-Namensräume bieten eine einfache Möglichkeit, um Element- und Attributnamen, die in XML-Dokumenten verwendet werden, eindeutig zu benennen. Das geschieht, indem Element- und Attributnamen mit Namensräumen verknüpft werden, die in den meisten Fällen URI-Verweise darstellen. Im Fall der CDA Release 2 Dokumente gibt es einen Default-Namespace. Dieser Default-Namespace ist wie folgt definiert: urn:hl7-org:v3'.'

Der Zeichensatz der XML-Nachrichten, die zwischen medizinischen Geräten und Krankenhausinformationssystemen und Praxisverwaltungssystemen zum Einsatz kommen, ist der UTF-8 Zeichensatz.

Nach dem Wurzelelement ClinicalDocument, ebenfalls noch vor dem Header, muss das Element typeId in einem CDA Release 2 Dokument enthalten sein.

typeId

Das Element typeId definiert den Typ des Dokuments. typeId ist innerhalb von CDA Dokumenten ein Pflichtelement und muss genau wie im Beispiel gezeigt angegeben werden.

Dabei handelt es sich um einen technisch neutralen Verweis auf die CDA Release 2 Spezifikation und setzt sich zusammen aus einer OID für HL7 die sich hinter dem Attribut @root verbirgt, und dem Attribut @extension, dass standardmäßig mit dem Parameter „POCD_HD000040" gefüllt wird.

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

CDA-Header

Im Header eines CDA Dokuments werden alle Informationen zu den beteiligten Personen, Organisationen und Institutionen gespeichert. Im selben Schritt werden im Header auch die verschiedenen Rollen der Beteiligten definiert. Dadurch kann es in der Praxis allerdings vorkommen, dass die Daten des behandelnden Arztes mehrfach im Header gespeichert werden. Durch die Informationen, die im CDA-Header abgelegt werden, soll es möglich sein, die Daten des Dokumentes auch später noch einem bestimmten Behandlungsfall und Patienten zuzuordnen. Das heißt der Header erfüllt zwei zentrale CDA-Eigenschaften. Die Persistenz und die Verantwortung eines Dokumentes.

Inhalt des CDA-Headers im Überblick:

• Informationen über das Dokument - Dies beinhaltet die eindeutige Identifikationsnummer des Dokumentes und Angaben über den Dokumententypen.
• Informationen über die beteiligten Personen und Organisationen - Z. B. welcher Arzt hat für welchen Patienten das Dokument erstellt.
• Informationen über das Ereignis - Der Behandlungsfall in dem das Dokument erstellt wurde.

Bei der Namensgebung der XML-Elemente (Tags), wurde allgemein so vorgegangen, dass der letzte Teil hinter dem Punkt der Name des XML-Tags ist. So ist z. B. ClinicalCocument.id nach „HL7 Clinical Document Architecture Release 2.0”, eine Instanz der Klasse ClinicalDocument. Das bedeutet, dass der Name des XML-Elementes in diesem Fall „id“ ist.

ClinicalDocument.id

Datentyp: II

Kardinalität: [1..1]

Durch die id wird ein Dokument eindeutig identifiziert. Dadurch ist es möglich ein abgeschlossenes Dokument später zuordnen zu können und so in einem neuen Dokument auf ein bereits bestehendes Dokument zu verweisen. Sie gehört zum Datentyp Instance Identifier.

Root-Attribut

Das @root-Attribut wird dabei von dem System bestimmt, das das Dokument erstellt. Bei der Kommunikation zwischen zwei Verwaltungssystemen wäre die ID die OID des Verwaltungssystems, welches das Dokument versendet.

Wenn also der Hersteller „xy“ eine OID im deutschen Gesundheitswesen beantragt und zugewiesen bekommt, wäre diese OID der erste Teil des @root-Attributes. Nach der Definition der Baumstruktur schließt sich an diese OID eine beliebige Anzahl zusätzlicher Nummern an, die durch Punkte getrennt sind. Diese Nummern können vom Hersteller frei vergeben werden. Für das Beispiel nehmen wir an, dass der Hersteller „xy“ die OID „1.2.2.76.0.76" zugewiesen bekommt. Weiterhin nehmen wir an, dass er seine Produktlinien unterteilt hat, dafür wählen wir die „10“. Somit ergibt sich die OID „1.2.276.0.76.10“. Jetzt könnten wir unterhalb der 10 beliebig viele weitere Unterteilungen vornehmen. Dokumenten-IDs sind dadurch gekennzeichnet, dass eine „.1“ angehängt wird, daraus ergibt sich root=“1.2.276.0.76.10.1".

Extension-Attribut

Bei dem @extension-Attribut handelt es sich um eine innerhalb des dokumenterzeugenden Anwendungssystems eindeutige Nummer, die vom jeweiligen System vergeben wird. Es bietet sich an eine fortlaufende Nummer zu verwenden, die mit „1“ anfängt und bei jeder Erstellung eines neuen Dokumentes um „1“ erhöht wird z. B. @extension="1".

In dem oben gewählten Beispiel würde sich die weltweit eindeutige Identifikationsnummer wie folgt zusammensetzen:

<id root="1.2.276.0.76.10.1" extension="1"/>

ClinicalDocument.code

Datentyp: CE

Kardinalität: [1..1]

Der ClinicalDocument.code spezifiziert um welche Art von Dokument es sich handelt. Dazu verwendet man den Datentyp „Concept Descriptor“ (CD).

Der Inhalt von ClinicalDocument.code wird, wenn möglich, mit Daten aus der LOINC-Datenbank gefüllt. Um im ClinicalDocument.code kenntlich zu machen, dass es sich um Daten aus der LOINC-Datenbank handelt, wird im Element code das Attribut @codeSystem, mit der OID (2.16.840.1.113883.6.1) des LOINC Systems gefüllt. In der LOINC-Datenbank existiert zu jedem Eintrag ein eindeutiger Schlüssel. Dieser Schlüssel muss im ClinicalDocument.code als Attribut vorhanden sein und wird mit dem Attributnamen @code vermerkt. Das hat den Vorteil, dass die Art des Dokumentes eine eindeutige Identifikation besitzt und die Einträge innerhalb des XML-Dokument später automatisch ausgewertet werden können. Daneben gibt es noch das optionale Attribut @displayName. Dieses Attribut beinhaltet einen menschenlesbaren Text, der den angegeben Schlüssel beschreibt. In den meisten Fällen ist dieser Text auf ein Stichwort reduziert. Da man hier einen beliebigen Text eintragen darf, der nur dazu dient das XML-Dokument für den Menschen lesbar zu halten, kann dieses Attribut nicht maschinell ausgewertet werden. Da es sich bei dem Mutterpass um ein Dokument handelt, welches noch nicht digitalisiert wurde, existiert für dieses Dokument noch keine Klassifizierung nach einem bekannten Codesystem, wie es z. B. LOINC darstellt. Aus diesem Grund wurde innerhalb der InterComponentWare AG, die über eine eigene OID verfügt, ein Dokumententyp-Code vergeben, der in naher Zukunft bei HL7 beantragt werden soll, um diesen Code zentral für alle Institutionen bekannt zu geben.

Die restlichen Felder und Attribute des Concept Descriptors, wie @codeSystemVersion, originalText, qualifier und translation, werden im Element ClinicalDocument.code nicht gefüllt, so dass sich folgender Aufbau ergibt.

ClinicalDocument.title

Datentyp: ST

Kardinalität: [0..1]

In diesem Tag wird der Titel des Dokumentes dargestellt. Im Allgemeinen besitzen klinische Dokumente keinen Titel. Der Titel wird vielmehr durch den @displayName im ClinicalDocument.code (Mutterpass) dargestellt. Wenn der Name für die beteiligten Informationssysteme eine Rolle spielt oder es sich um einen eindeutigen Namen handelt, sollte ClinicalDocument.title benutzt werden. Wie aus der Kardinalität ersichtlich, ist das Element title optional.

ClinicalDocument.effectiveTime

Datentyp: TS

Kardinalität: [1..1]

Im Element effectiveTime wird die Zeit, zu der das Dokument erstellt wurde, festgehalten. Die Zeitangabe ist vom Datentyp TS und muss mindestens Tagesgenau sein.

ClinicalDocument.confidentialityCode

Datentyp: CE

Kardinalität: [1..1]

Vertraulichkeit ist ein erforderlicher Bestandteil von CDA. Der festgelegte Wert, der im Header angegeben wird, gilt dabei für das gesamte Dokument, es sei denn, dass dieser Wert auf einer niedrigeren Verschachtelungsstufe überschrieben wird. Der Datentyp des confidentialityCode-Elements ist vom Datentyp CE. Das bedeutet, dass das Element die beiden Attribute @code und @codeSystem besitzt. Das codeSystem hat dabei immer den Wert „2.16.840.1.113883.5.25“.

<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25" />

Folgende Werte sind für die Vertraulichkeitsangabe eines CDA-Dokumentes zulässig.

<xtable>Mögliche Vertraulichkeitsangaben in einem CDA-Dokument</xtable>

Code	codeSystem	Display Name	Deutsche Bezeichnung
N	2.16.840.1.113883.5.25	normal	Normale Vertraulichkeitsregeln sind anzuwenden. Nur autorisiertes Personal im Bereich Medizin, darf auf die Daten zugreifen.
R	2.16.840.1.113883.5.25	restricted	Eingeschränkter Zugriff, nur Personal in einer zeitnahen medizinischen Dienstleistungsfunktion darf auf die Daten zugreifen.
V	2.16.840.1.113883.5.25	very restricted	Stark eingeschränkter Zugriff, Zugriffsregeln gibt der „Privacy Officer" des Daten-Anbieters vor.

ClinicalDocument.languageCode

Datentyp: CS

Kardinalität: [0..1]

In diesem Tag wird die Sprache der menschenlesbaren Texte angegeben. Die Werte des @code-Attributes sind Sprachenbezeichner, die durch IETF (Internet Engineering Task Force) RFC 3066 für die Kennzeichnung von Sprachen definiert sind. Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben). Das codeSystem ist dabei standardmäßig „2.16.840.1.113883.6.121". Im Element languageCode, wird die Sprache für das gesamte Dokument festgelegt.

Sollte die Sprache für einen Unterabschnitt eine andere sein, so kann dies dort angegeben werden. Da es sich beim Mutterpass um ein Dokument handelt, welches zurzeit nur im deutschsprachigen Raum eingesetzt wird, ist der languageCode standardmäßig auf „de-DE“ zu setzen oder kann in diesem Fall ganz außen vor gelassen werden, da es sich um ein optionales Element handelt.

<languageCode code="de-DE"/>

Header Beteiligte Personen

Dieser Abschnitt beschreibt die Teilnehmer, die eine Verbindung zum Wurzelelement ClinicalDocument besitzen. Folgende Rollen für Teilnehmer sind in einem CDA-Dokument möglich.

• authenticator (optional)
• legalAuthenticator (optional)
• dataEnterer (optional)
• encounterParticipant (optional)
• informant (optional)
• informationRecipient (optional)
• participant (optional)
• performer (optional)
• author (Pflicht)
• custodian (Pflicht)
• recordTarget (Pflicht)

Nicht alle diese Rollen sind für ein CDA-Dokument zwingend erforderlich. Wie man aus der Aufzählung ersehen kann, sind lediglich die Rollen author, custodian und recordTarget zwingend erforderlich. Aus diesem Grund wird auf diese Rollen am ausführlichsten eingegangen.

Optionale Teilnehmer

Unterzeichner

Es ist möglich, innerhalb von CDA Verantwortlichkeiten für das Dokument festzulegen. Hierfür gibt es innerhalb von CDA drei Möglichkeiten um ein Dokument zu „unterschreiben“.

Ein CDA Dokument kann drei Zustände der Authentisierung einnehmen.

• unauthenticated
• authenticated
• legally authenticate

Der „unauthenticated“-Zustand besteht, wenn keine Authentisierungsinformationen für das Dokument existieren. Das bedeutet, dass weder das Element authenticator noch legalAuthenticator im CDA-Dokument vorhanden ist.

Es ist nicht vorgesehen elektronische Unterschriften in einem CDA Dokument einzubinden, da diese in Deutschland noch nicht standardisiert sind. Wenn die Verantwortlichkeit für ein lokales CDA-Dokument dokumentiert werden soll, wird dies mit den Elementen authenticator bzw. legalAuthenticator realisiert. Sie erfordern, dass ein Dokument manuell oder elektronisch von der verantwortlichen Einzelperson unterzeichnet worden ist.

authenticator

Kardinalität: [0..n]

Ein authenticator ist ein Teilnehmer, der zur Richtigkeit des Dokumentes beigetragen hat, aber über keine Privilegien verfügt, dass Dokument rechtswirksam zu beglaubigen. Ein klinisches Dokument kann beliebig viele „authenticators“ besitzen.

Ein authenticator hat drei erforderliche Unterelemente

• time
• signatureCode
• assignedEntity.

authenticator.time

Datentyp: CE

Kardinalität: [1..1]

Gibt den Zeitpunkt der Authentisierung an.

authenticator.signatureCode

Datentyp: CS

Kardinalität: [1..1]

Zeigt an, dass eine Unterzeichnung stattgefunden hat und dokumentiert ist.

Hier wird eine Typisierung der Signatur angegeben. Die zulässigen Werte sind in der folgenden Tabelle wiedergegeben. Unter der VokabelDomäne von HL7 für die Participation Signatur findet man folgende Definition.

Signierung in einem CDA-Dokument

Lvl	Code	Display name	Definition/Description
0-L	I	intended	The particpant intends to provide a signature.
0-L	S	signed	Signature has been affixed, either written on file, or electronic (incl. digital) signature in Participation.signatureText.
0-L	X	required	A signature for the service is required of this actor.

Seit CDA Release 2 wird code=”X” nicht mehr verwendet. Es ist nur noch <signatureCode code="S"/> vorgesehen, was bedeutet, dass eine Signatur vorhanden ist, entweder auf Papier oder in digitaler Form.

authenticator.assignedEntity

Kardinalität: [1..1]

Unter dem Element assignedEntity muss das Element id vorhanden sein, welches vom Typ II (Instance Identifier) ist. Damit kann die Identifikation einer Person festgehalten werden. Es können auch mehrere IDs abgebildet sein. Das kann z. B. dann relevant sein, wenn die Person bei verschiedenen Institutionen über eine eindeutige Identifikation verfügt.

<authenticator>
	<time ... />
	<signatureCode ... />
	<assignedEntity>
		<id ... />
	</assignedEntity>
</authenticator>

legalAuthenticator

Kardinalität: [0..1]

Im legalAuthenticator kann der Unterzeichner festgehalten werden, der vor dem Gesetz für das Dokument verantwortlich ist. Es gibt genau eine Person auf die dies zutrifft. Ein legalAuthenticator hat ein erforderliches Element time, um die Zeit der Authentisierung anzuzeigen und einen signatureCode, welcher festlegt, dass eine Unterschrift oder Signatur vorhanden und dokumentiert ist. Die Zuordnung zu einer eindeutigen ID des Unterzeichners wird unterhalb von der assignedEntity realisiert. Damit sind drei Elemente verpflichtend.

• time
• signatureCode
• assignedEntity

Diese drei Elemente sind von ihrer Bedeutung her identisch mit den beschriebenen Elementen aus authenticator. Der Unterschied besteht nur darin, dass der legalAuthenticator der vor dem Gesetz verantwortliche Unterzeichner ist und dieses Element höchstens einmal vorkommen darf. Der syntaktische Aufbau ist gleich.

<legalAuthenticator>
	<time ... />
	<signatureCode ... />
	<assignedEntity>
		<id ... />
	</assignedEntity>
</legalAuthenticator>

dataEnterer

Kardinalität: [0..1]

Unter dieser Teilnehmergruppe können Personen eingetragen werden, die an der Dateneingabe beteiligt waren, aber keine medizinische Funktion hatten. Ein typischer Fall wäre ein Übersetzer, der bestimmte Teile der klinischen Dokumentation in eine andere Sprache übersetzt hat. Das einzige verpflichtende Element innerhalb von dataEnterer ist das Element assignedEntity.

dataEnterer.assignedEntity

Kardinalität: [1..n]

Über das Element id legt man die Identifikation des Individuums fest. id ist vom Typ Instance Identifier und kann beliebig oft, muss aber mindestens einmal, vorkommen.

<dataEnterer>
	<assignedEntity>
		<id ... />
	</assignedEntity>
</dataEnterer>

encounterParticipant (EncompassingEncounter)

Kardinalität: [0..1]

Diese Klasse beschreibt das Szenario in dem der klinische Report erstellt wurde. Da klinische Dokumente nicht notwendigerweise während eines Treffens zwischen Arzt und Patient erzeugt werden, dient die Klasse dazu, dies festzuhalten. EncompassingEncounter dient auch dazu, eine Entlassung und deren Grund festzuhalten. Wenn ein Patient gegen den Rat des Arztes entlassen wird, wird in dieser Klasse der Zeitraum und „Entlassung gegen den ärztlichen Rat“ festgehalten. Die Klasse EncompassingEncounter darf höchstens einmal existieren. Das einzig verpflichtende Element von EncompassingEncounter ist das Element effectiveTime.

EncompassingEncounter.effectiveTime

Datentyp: IVL_TS

Kardinalität: [1..1]

Dies stellt den Zeitpunkt oder den Zeitraum der Behandlung dar.

informant

Kardinalität: [0..n]

Ein informant ist eine Person, die relevante Informationen zur Verfügung stellt. Das kann z. B. der Elternteil sein, der die Krankheitssymptome seines Kindes beschreibt.

Der informant kann zwei Rollen annehmen. Das macht man davon abhängig ob die Identität bekannt ist.

• relatedEntity
• assignedEntity

informant.relatedEntity

Wenn die Identität der Person nicht bekannt oder nicht von Bedeutung ist, wird das Unterelement relatedEntity benutzt. In diesem Fall besitzt der informant ein formales Verhältnis zum Patienten, dies kann z. B. eine Person von der Straße sein, die den Vorfall zur Krankheitsbildung beobachtet hat.

informant.assignedEntity

Die assignedEntity Rolle wird für informant benutzt, wenn die Identität bekannt ist.

<informant>
	<assignedEntity>
		<id ... />
	</assignedEntity>
</informant>

informationRecipient

Kardinalität: [0..1]

Der informationRecipient stellt einen Empfänger dar, der eine Kopie des Dokumentes zum Erstellungszeitpunkt erhält. Er ist nicht zu verwechseln mit einer Liste an Personen, für die dieses Dokument freigegeben ist. Solch eine Liste ist nicht die Aufgabe eines CDA-Dokumentes.

Ob es sich um einen Primärempfänger (z. B. Hausarzt) oder einen mitbehandelnden Kollegen handelt, kann man über das Attribut @typeCode von informationRecipient festlegen. Für dieses Attribut sind momentan zwei Inhalte (Values) möglich.

Empfänger eines CDA-Dokumentes

XML-Code	Erklärung
<informationRecipient typeCode="PRCP">	Ein primärer Empfänger, an den das Dokument gesendet wird.
<informationRecipient typeCode="TRC">	Ein sekundärer Empfänger, der eine Kopie des Dokumentes erhält.

Wenn das Attribut nicht gefüllt ist, handelt es sich um einen Primärempfänger, da dies die Default-Einstellung ist.

informationRecipient.intendedRecipient

Kardinalität: [1..1]

Wenn es sich bei dem beabsichtigten Empfänger nicht um eine Person handelt, gibt es zwei Möglichkeiten. Ist der Empfänger eine Organisation, dann wird das Attribut @classCode von intendedRecipient mit „ASSIGNED“ gefüllt. In diesem Fall wird keine Person angegeben, sondern nur eine scopingOrganization. Wenn der Empfänger ein health chart ist, wird das Attribut @classCode mit „HLTHCHRT“ gefüllt. In diesem Fall gibt es kein beteiligtes Wesen, aber wahlweise eine Organisation.

<informationRecipient typeCode="TRC">
	<intendedRecipient classCode="ASSIGNED">
...
        </intendedRecipient>
</informationRecipient>

participant

Kardinalität: [0..n]

Durch diese Klasse werden Personen repräsentiert, die an der Dokumentation beteiligt waren, aber sich nicht durch die oben aufgeführten Klassen beschreiben lassen. Hier können z. B. Angehörige des Patienten oder die Relation zu einer Versicherung aufgenommen werden.

Da die Klasse participant alle anderen Fälle abdeckt, ist sie sehr umfangreich. Die genaue Beschreibung kann in der CDA-Vokabeldomäne eingesehen werden.

Im Element participant ist das Attribut @typeCode verpflichtend, welches die Typisierung der Beteiligung an der Dokumentation erlaubt. Ein participant ist eine Person, die die Rolle eines Beteiligten (AssociatedEntity class) annimmt. Aus diesem Grund ist das Element associatedEntity unterhalb des Elementes participant ebenfalls Pflicht.

participant.associatedEntity

Wenn es sich beim Participant um eine Person handelt, wird sie aus der HL7-RIM-Klasse „Person class“ abgeleitet. Im Falle einer Organisation, leitet sie sich aus der Klasse „Organization class“ ab.

<participant typeCode="">
	<associatedEntity classCode="">
...
        </associatedEntity>
</participant>

Pflichtteilnehmer

author

Kardinalität: [1..n]

Gibt die Menschen und/oder die Maschinen an, die das Dokument erstellt haben.

Das Element author, besitzt zwei Attribute

• @typeCode
• @contextControlCode

und mehrere Unterelemente. Die Unterelemente time und assignedAuthor sind zwingend erforderlich.

author.time

Datentyp: TS

Kardinalität: [1..1]

Gibt den Zeitpunkt der Datenerfassung durch eine Person an.

author.assignedAuthor

Kardinalität: [1..1]

Ein Autor ist eine Person in der Rolle eines zugewiesenen Autors (assignedAuthor class). Es gibt zwei Möglichkeiten. Entweder handelt es sich bei der Instanz um eine Person oder um ein Gerät.

• Wenn es sich bei der Instanz um eine Person handelt, dann ist die Rolle, welche die Instanz spielt, von der Klasse Person. In diesem Fall existiert ein Element assignedPerson innerhalb des assignedAuthor-Elements.
• Ist die Instanz ein Gerät, dass das Ursprungsdokument erstellt, dann ist die ausstellende Instanz ein Gerät, welches die Rolle Gerät (device) einnimmt und sich von der Klasse AuthoringDevice ableitet. In diesem Fall existiert ein Element assignedAuthoringDevice innerhalb des assignedAuthor-Elements.

Es kann immer nur eines der beiden Elemente assignedPerson oder assignedAuthoringDevice vorhanden sein. Neben diesen beiden optionalen Elementen zur Festlegung der Instanz gibt es noch weitere optionale Elemente zur Kontaktdatenspeicherung. Das einzige Element, das zwingend vorgeschrieben ist, ist das id-Element.

Author.assignedAuthor.id

Datentyp: II

Kardinalität: [1..n]

Es herrscht eine 1…n-Beziehung. Pro assignedAuthor muss eine id existieren, es können aber auch beliebig viele existieren. Der Datentyp der id ist vom Typ Instance Identifier. Das heißt, dass die id wieder über zwei Attribute verfügt, @extension und @root.

In einigen Fällen ist die Rolle oder die Funktion des Autors schon im ClinicalDocument.code beschrieben oder lässt sich daraus herleiten, z. B. im Falle von „Medical Student Progress Note". Die Rolle des Autors kann auch im optionalen Element functionCode oder @code-Attribut notiert werden. Wenn einer dieser optionalen Parameter gefüllt ist, sollten sie der Rolle im ClinicalDocument.code nicht widersprechen sondern nur bestätigen oder genauer spezifizieren, da es sonst zu einer Inkonsistenz führen würde.

Zusätzlich kann für eine Person noch optional ein Vor- und Nachname sowie eine Adresse mit Straße, Hausnummer, Postleitzahl und Stadt angegeben werden.

custodian

Kardinalität: [1..1]

Hier wird die Organisation eingetragen, die das Dokument verwaltet oder auch ändert. Da aber keine zentrale Institution in Deutschland existiert, die diese Funktion erfüllt, ist dieser Eintrag für die Bundesrepublik Deutschland nicht notwendig. Dieses Element muss trotzdem gefüllt werden, weil der CDA-Standard in den USA entwickelt wurde, wo solche Institutionen existieren.

Zur eindeutigen Identifikation ist ein Element id vom Typ Instance Identifier erforderlich, welches innerhalb der Organisation eingetragen wird, die die Rolle des zugewiesenen custodian einnimmt.

custodian.assignedCustodian.representedCustodianOrganisation.id

Datentyp: II

Kardinalität: [1..n]

Die Organisation muss mindestens über eine eindeutige id vom Typ Instance Identifier verfügen. Alle anderen Angaben wie Name und Adresse sind optional.

<custodian>
	<assignedCustodian>
		<representedCustodianOrganization>
			<id ... />
		</representedCustodianOrganization>
	</assignedCustodian>
</custodian>

recordTarget

Kardinalität: [1..n]

Das recordTarget repräsentiert die Person, an welcher die Untersuchungen durchgeführt wurden. Im Normalfall handelt es sich um genau einen Patienten. Für den ungewöhnlichen Fall, dass sich das Dokument auf mehrere Patienten bezieht, kann mehr als ein recordTarget im Header angelegt werden. Der Patient wird eingebunden durch eine patientRole-Klasse, in welcher er die Rolle eines Patienten patient annimmt.

recordTarget.patientRole.id

Datentyp: II

Kardinalität: [1..n]

Es herrscht eine 1…n-Beziehung. Für jeden Patienten muss mindestens eine id existieren, es können aber auch beliebig viele existieren. Der Datentyp der id ist vom Typ Instance Identifier. Das heißt, dass die id über zwei Attribute verfügt, @extension und @root.

Im Attribut @extension wird die Id des Patienten selbst angegeben, während @root auf das die Identifikation ausgebende Anwendungssystem hinweist, das mittels Object Identifer (OID) beschrieben wird. Wenn der Patient in verschiedenen Systemen über eine ID verfügt, können diese nacheinander aufgeführt werden.

recordTarget.patientRole.patient

Kardinalität: [0..1]

Die Rolle des Patienten wird durch die HL7-Klasse „patient“ abgebildet. Innerhalb dieser Klasse „patient“ können weitere Angaben über den Patienten, wie z. B. Name und Geschlecht, gemacht werden.

<recordTarget>
	<patientRole>
		<id ... />
		<patient>
...
                </patient>
	</patientRole>
</recordTarget>

CDA-Body

Der Body enthält die Dokumentation über den medizinischen Behandlungsfall und befindet sich immer innerhalb des Tags structuredBody. Der structuredBody setzt sich aus ein oder mehreren Komponenten (component) zusammen, die wiederum aus einer oder mehreren Sektionen (section) und die wiederum aus beliebig vielen Einträgen (entry) bestehen können. Man unterscheidet, je nach dem wie strukturiert die medizinische Dokumentation ist, zwischen drei Levels.

Level 1

Level 1 dient dazu, eine Eigenschaft von CDA-Dokumenten zu gewährleisten, die menschliche Lesbarkeit. Es handelt sich um einen beliebig formatierten Text, der sich innerhalb des text-Tags befindet. Zwar gibt es verschiedene Formatierungsmöglichkeiten um den Text zu strukturieren, allerdings schreibt CDA keine dieser Möglichkeiten vor, so dass der Text nicht zur maschinellen Auswertbarkeit herangezogen werden kann. Der narrative Text kann in einfachster Form ein unformatierter Text-String sein, der im Tag text eingeschlossen ist und die menschliche Lesbarkeit erfüllt, indem dieser Text über ein einfaches Stylesheet angezeigt wird.

Einige dieser Formatierungsmöglichkeiten sind aus HTML bekannt. Die Formatierungen, die am häufigsten benutzt werden, sind:

<br> für einen Zeilenumbruch

<caption> zur Darstellung einer Überschrift, innerhalb von Paragrafen, Listen, List-Items, Tabellen oder Tabellen-Spalten

<content> zur Kennzeichnung bestimmter Inhalte und Referenzierung auf Level 3

<list> kann eine Überschrift <caption> enthalten und dient zur Auflistung verschiedener <item>

<paragraph> zur logischen Trennung von zusammengehörigen Textabschnitten

<table> zur Darstellung einer Tabelle

Neben diesen Strukturmöglichkeiten gibt es auch die Möglichkeit den Text stilistisch aufzubereiten, wie z. B. fett, kursiv und unterstrichen.

Level 2

Level 2 unterscheidet sich von Level 1 darin, das die einzelnen sections mit ihren text-Blöcken durch einen Code eindeutig identifiziert werden. Das heißt, ein Parser kann selbst interpretieren, zu welchem Abschnitt (section) der nachfolgende Text gehört. Man spricht in diesem Fall auch von maschineller Auswertbarkeit. Dies wird über die sogenannten Concept Descriptor (CD) realisiert. Sie gewährleisten die Eindeutigkeit eines Codes, indem sie das zugrunde liegende Codesystem mit angeben. Hierzu verwendet sowohl CDA als auch HL7 die ISO Object Identifier (OID). Allerdings können bei Level 2 noch keine einzelnen Informationen ausgewertet werden sondern nur die zusammengehörige Section.

Zum vollständigen Auswerten aller Messungen und Angaben muss das Dokument in Level 3 abgebildet werden.

Beispiel für einen Level 2–Eintrag in einem CDA-Dokument anhand der serologischen Untersuchungen

---

<section>
    &lt;!-- Serologische Untersuchungen --&gt;
    <code nullFlavor="OTH">
        <translation code="SEREXM" codeSystem="2.16.840.1.113883.3.37.1.9.10.3.1" codeSystemName="ICW-GEN-DOCUMENT-SECTION-CODE-DE" displayName="Serologische Untersuchungen"/>
    </code>
    <title>Serologische Untersuchungen</title>
    <text> Es wurde ein Test der Blutgruppenzugehörigkeit durchgeführt. Datum der Untersuchung war der 21.08.2005 </text>
</section>

Level 3

Der Unterschied zwischen Level 1 und Level 3 bei CDA Release 2 besteht hauptsächlich darin, dass bei Level 3 zusätzlich zu Level 1 die Daten automatisch weiterverarbeitet werden können, wobei die Freitextinhalte von Level 1 erhalten bleiben. Hinzugefügt werden maschinenlesbare Angaben, so dass in Zukunft automatische Auswertungen der Daten durchgeführt werden können. Solche maschinell auswertbaren Angaben werden in so genannten „Entry Acts“ eingeschlossen. Jede section kann keine bis mehrere Entries enthalten.

Bei den Entries handelt es sich um eine Auswahl von Klassen, die so auch in HL7 beschrieben sind. Man hat bei CDA versucht eine Auswahl von bestimmten Acts zusammenzustellen, auf die alle medizinischen Beobachtungen abgebildet werden können. Damit soll eine gleich bleibende Darstellung der klinischen Beobachtungen erreicht werden.

Die HL7 RIM ist die maßgebliche Quelle für verwendeten Klassen und Attributbeschreibungen.

Die CDA Spezifikation gibt nicht vollständig die RIM-Definitionen wieder, verweist aber auf die entsprechenden RIM-Klassen mit den kompletten Definitionen. CDA begrenzt an einigen Stellen die RIM-Definitionen, aber sie widersprechen ihnen zu keinem Zeitpunkt. CDA Release 2 wird von HL7 RIM Version 2.07 abgeleitet.

Das Beispiel unten zeigt einen entry-Eintrag zum Textteil, sodass die Einzelbeobachtung, wann die Untersuchung durchgeführt wurde, ebenfalls maschinell ausgewertet werden kann. Das Datum wird in dem Element effectiveTime eingetragen.

Beispiel für einen Level 3–Eintrag in einem CDA-Dokument anhand der Blutgruppenzugehörigkeit

---

<section>
    &lt;!-- Serologische Untersuchungen --&gt;
    <code nullFlavor="OTH">
        <translation code="SEREXM" codeSystem="2.16.840.1.113883.3.37.1.9.10.3.1" codeSystemName="ICW-GEN-DOCUMENT-SECTION-CODE-DE" displayName="Serologische Untersuchungen"/>
    </code>
    <title>Serologische Untersuchungen</title>
    <text>
        <table>
            <caption>Blutgruppenzugehörigkeit</caption>
            <tbody>
                <tr>
                    <th>Datum der Untersuchung:</th>
                    <td>21.08.2005</td>
                </tr>
            </tbody>
        </table>
    </text>
    <entry>
        <organizer classCode="BATTERY" moodCode="EVN">
            <id extension="123-345.5" root="2.16.840.1.113883.3.37.999.2.1.1.3"/>
            <code code="BLTPRL" codeSystem="2.16.840.1.113883.3.37.1.9.13.1.1" codeSystemName="ICW-GEN-OBSERVATION-CODE-DE"/>
            <statusCode code="completed"/>
            <effectiveTime value="20061010"/>
        </organizer>
    </entry>
</section>

EntryActs

Act

Dabei handelt es sich um die abstrakteste Klasse der Entry Acts. Sie wird benutzt wenn die spezifischeren Klassen nicht zutreffen. Diese Klasse ist eine Ableitung der HL7 RIM-Klasse Act.

Encounter

Leitet sich aus der HL7 RIM-Klasse PatientEncounter ab. In dieser Klasse werden Informationen zum Patientenkontakt dokumentiert. Das gilt sowohl für durchgeführte Termine als auch für Anschlussbesuche. Das Attribut @classCode in dem Element <encounter> wird dabei standardmäßig auf ENC gesetzt. Dieses drückt eine Interaktion zwischen einem Patienten und Akteuren im Gesundheitswesen (healthcare participants) aus, mit dem Ziel eine Untersuchung oder einen Service durchzuführen.

Observation

Nennt sich genau wie die HL7 RIM-Klasse. Wird benutzt um eine Beobachtung zu dokumentieren. Beobachtungen sind die Tätigkeiten, die durchgeführt werden, um einen Antwort- und/oder Resultatswert festzustellen und zu dokumentieren. Im Falle des Mutterpasses handelt es sich ausschließlich um kodierte Untersuchungen. Das heißt diese Observations sind maschinell auswertbar. Das Attribut @classCode in dem Element observation wird standardmäßig auf OBS gesetzt.

ObservationMedia

Ist eine Ableitung der RIM-Klasse Observation. Diese Klasse dient zur Einbindung von Multimediainhalten, die logisch zum Dokument gehören. Das gilt z. B. für Aufnahmen, die als Beweis für einen Befund in das Dokument eingebunden werden und die von der entsprechenden Abteilung selbst erstellt wurden. Die Darstellung des MIME-Media-Types benötigt die entsprechende Software, um dargestellt werden zu können. Außerdem verfügt jedes dieser Objekte über eine ID, die innerhalb des Dokumentes eindeutig ist, so dass auf sie referenziert werden kann, z. B. aus dem Textteil.

Organizer

Leitet sich aus der HL7 RIM-Klasse „Act“ ab. Die Organizer-Klasse dient zur Gruppierung von CDA-Entries, welche einen gemeinsamen Kontext besitzen. Ein Organizer kann wiederum andere Organizer und CDA-Entries über Komponenten einfügen. Ein Organizer kann über die Klasse „external acts“ unter der Verwendung von referenceRelationship auf externe Acts verweisen. Bei der Klasse Organizer verwendet man im Attribut @classCode zwei verschiedene Codes: BATTERY und CLUSTER.

• BATTERY: eine BATTERY spezifiziert einen Satz an Beobachtungen. Diese Beobachtungen haben gewöhnlich eine logische oder praktische Gruppierung. Beispielsweise werden mit einem Organizer vom Typ BATTERY Beobachtungen zusammengefasst, die im Rahmen einer einzelnen Untersuchung gemacht werden.

• CLUSTER ist eine Gruppe von Eintragungen, die eine logische Verbindung miteinander haben. Ein Organizer vom Typ CLUSTER kommt dort zum Einsatz, wo die gleiche Untersuchung mehrmals durchgeführt wird.

Procedure

Eine Prozedur ist ein Behandlungsfall mit einer Änderung des körperlichen Zustandes des Subjektes. Z. B. eine Operation am Patienten.

RegionOfInterest

Dient zum Hervorheben eines bestimmten Bereiches. Das Element RegionOfInterest kann z. B. eingesetzt werden, wenn ein bestimmter Teil eines Bildes hervorgehoben werden soll. In diesem Fall wird ebenfalls eine eindeutige ID innerhalb des Dokumentes vergeben, um darauf referenzieren zu können.

SubstanceAdministration

Leitet sich aus der Klasse SubstanceAdministration von dem HL7-RIM ab. Mit diesem Entry-Act lassen sich Angaben über Medikationen festhalten. Das gilt sowohl für eine spezifische Medikationsgeschichte, als auch für eine geplante Medikationsanleitung.

Supply

Dient zur Spezifikation eines Materials zwischen zwei Entitäten. Mit Hilfe der Klasse supply wird die zur Verfügungsstellung von Material oder Medikamenten beschrieben. Der Unterschied zur Klasse Substance Administration besteht darin, dass das Material Medikament über die Klasse supply beschrieben wird, die Verabreichung aber über die Klasse SubstanceAdministration. Somit wäre die supply-Klasse die Information, die z. B. an die Apotheke weitergeleitet werden müsste.

Referenzieren mit URIs

Elemente innerhalb des Textabschnittes text nutzen die ID-Attribute, um die dazugehörigen Level 3 Entries zu referenzieren. Dies stellt eine Verknüpfung dar zwischen dem codierten Eintrag und dem Text. Dabei wird das Ziel verfolgt, schrittweise mehr strukturiertes Markup zur Verfügung zu stellen, das Applikationen nutzen können. Außerdem werden dadurch Doppeleinträge von Informationen verhindert.

Jedes Element im narrativen Kontext kann ein ID-Attribut mitführen. Dies ist vom Typ xs:ID und muss im gesamten Dokument eindeutig sein. IDs dieser Art beginnen mit einem Buchstaben, gefolgt von einem oder mehreren Buchstaben, Zahlen, Bindestrichen oder Unterstrichen.

Dies erlaubt, dass der Text mit einer einfachen URI referenziert werden kann. Die URI ist lokal im Dokument definiert, beginnt innerhalb einer Observation mit einem #-Zeichen, gefolgt von der ID.

<originalText>
	<reference value="#ID10001"/>
</originalText>

Folgende Teile bekommen eine ID (inkl. Referenz auf originalText)

• organizer code
• observation code
• observation value (sofern vom Typ CD)

Folgende Teile bekommen keine ID (und damit auch keine Referenz auf originalText)

• section code
• encounter code
• observation value (wenn vom Typ BL, INT, RTO, ST etc.)

Code-Systeme

Code-Systeme dienen in CDA-Dokumenten, aber auch in anderen medizinisch-klinischen Bereichen, zur Abbildung von Krankheiten, Labordaten und Therapien als maschinen-auswertbare Daten.

Zurzeit gibt es drei große Code-Systeme die in Deutschland eingesetzt werden: ICD10, LOINC und OPS.

In Deutschland ist ICD10 (International Classification of Diseases Version 10) am weitesten verbreitet. ICD10 wird bei der Diagnoseverschlüsselung eingesetzt. Krankenhäuser und niedergelassene Ärzte sind gesetzlich dazu verpflichtet, ihre Diagnosen in ICD10 zu dokumentieren.

LOINC (Logical Observation Identifiers Names and Codes) ist ein international anerkanntes System zur eindeutigen Verschlüsselung von Untersuchungen (insbesondere im Laborbereich) und ist für den effektiven Datenaustausch mit anderen medizinischen Systemen in Klinik oder Praxis einsetzbar.

Der „Operationen- und Prozedurenschlüssel" (OPS, früher OPS-301) wurde vom DIMDI (Deutsches Institut für Medizinische Dokumentation und Information) erstellt und zunächst nur zur Verschlüsselung operativer Eingriffe angewendet. Im Jahr 2004 wurde der OPS eingesetzt, um allgemein medizinische Prozeduren im Krankenhaus zu verschlüsseln. Seit 2005 wird der OPS auch im Bereich des ambulanten Operierens verwendet.

Neben diesen fest definierten Codesystemen gibt es ein regelbasiertes Code-System, das im Mutterpass verwendet wird. Der UCUM (Unified Code for Units of Measure) ist ein Code-System für Maßeinheiten. Bei einer Übertragung von Messdaten würde die Übertragung des Messwertes ohne die zugehörige Einheit keinen Sinn ergeben. Um eine einheitliche Angabe der Maßeinheit anzugeben, verwendet UCUM eine relativ kleine Anzahl von atomaren Symbolen, die durch entsprechende Syntaxregeln kombiniert werden. Der eigentliche Messwert steht innerhalb des value-Tags, während die Einheit in dem Attribut @unit codiert wird.

Für die Speicherung von Messwerten wird in CDA Release 2 der Datentyp PQ (Physical Quantity) benutzt [HL7M]. Die OID für das Kodierungssystem UCUM ist 2.16.840.1.113883.6.8. Nur wenige Codes, die im Mutterpass eingesetzt werden, existieren bereits in einem der vorgestellten Code-Systeme. Aus diesem Grund musste ein eigenes Code-System erstellt werden, welches sich im Anhang dieser Arbeit befindet. Die Codes wurden anschließend mit der Codegenehmigungsstelle der ICW AG abgestimmt, zugelassen und eine OID Struktur unterhalb der ICW OID angelegt. Hierdurch steht es auch weiteren Anwendungen der ICW zur Verfügung. Später sollen die Codes in ein offizielles Code-System aufgenommen werden und so auch der Öffentlichkeit zur Verfügung stehen.