Quelltext der Seite cdaemp:Grundlagen

{{DocumentPart}}
= Grundlagen =

== Verwendete Datentypen (HL7 Version 3) ==
Die am häufigsten verwendeten HL7 Version 3 Datentypen dieser Arbeit sind
* Instance Identifier (II)
* Concept Descriptor (CD)
* Physikalische Messgrößen (PQ)
* Time stamps (TS)

Es ist sinnvoll, sich über die Implementierung vor allem dieser Datentypen zu informieren. Nähere Informationen zu den verwendeten Datentypen sind dem Datentypen und CMETs Leitfaden<ref>http://hl7.de/publikationen/techdok.php</ref><ref>http://wiki.hl7.de/index.php/IG:HL7_V3_Datentypen_Release_1</ref> der HL7-Benutzergruppe in Deutschland zu entnehmen.

== 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. 

{| class="prettytable"
|+Schematischer Aufbau eines CDA-Dokumentes
| bgcolor=#FFCBCB | <nowiki><ClinicalDocument></nowiki>

{| class="prettytable"
|  bgcolor=#FFFF40 | // An dieser Stelle steht der Header mit den Metainformationen 
// z. B. die Informationen über den Patienten 

|-
|  bgcolor=#B0E2FF | <nowiki><structuredBody></nowiki>

{| class="prettytable"
|  bgcolor=#B5B5B5 | <nowiki><section></nowiki>
<nowiki><text>...</text></nowiki>

{| class="prettytable"
|  bgcolor=#E066FF | <nowiki><observation>...</observation> </nowiki>

<nowiki><substanceAdministration> </nowiki>

:<nowiki><supply>...</supply> </nowiki>

<nowiki></substanceAdministration> </nowiki>

<nowiki><observation> </nowiki>

:<nowiki><externalObservation>... </nowiki>

:<nowiki></externalObservation> </nowiki>

<nowiki></observation> </nowiki>

|}

<nowiki></section> </nowiki>

<nowiki><section> </nowiki>

:<nowiki><section>...</section> </nowiki>

<nowiki></section> </nowiki>

|}
<nowiki></structuredBody> </nowiki>

|}
<nowiki></ClinicalDocument></nowiki>

|}

{| class="prettytable"
| bgcolor=#FFFF40 style="width:5em" | Header
| bgcolor=#B0E2FF style="width:5em" | Body
| bgcolor=#B5B5B5 style="width:5em" | Sections
| bgcolor=#E066FF style="width:5em" | 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. 

<syntaxhighlight lang="xml" heading="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"/>

  <!-- CDA Header -->
	
  <!-- CDA Body -->

</ClinicalDocument>
</syntaxhighlight>

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.

<syntaxhighlight lang="xml">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
</syntaxhighlight>

=== 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 ====

{{AttDesc
| ae = elm
| rim = act
| name = id
| desc = Id des Dokuments
| dt = II
| card = 1..1
| conf = M
}}
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. 

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.

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:

<syntaxhighlight lang="xml">
<id root="1.2.276.0.76.10.1" extension="1"/>
</syntaxhighlight>

====ClinicalDocument.code====

{{AttDesc
| ae = elm
| rim = act
| name = code
| desc = Andeutung der Art des Dokuments
| dt = CE
| card = 1..1
| conf = M
}}
Der ClinicalDocument.code spezifiziert um welche Art von Dokument es sich handelt. Dazu verwendet man den Datentyp „Concept Descriptor“ (CD).

ClinicalDocument.code wird mit dem LOINC-Code 57059-8 (Pregnancy visit summary) gefüllt, das LOINC-Codesystem hat die OID 2.16.840.1.113883.6.1. Somit ergibt sich hierfür:
<syntaxhighlight lang="xml">
<code code="57059-8" codeSystem="2.16.840.1.113883.6.1"/>
</syntaxhighlight>

Die restlichen Felder und Attribute des Concept Descriptors, wie ''@codeSystemVersion'', ''originalText'', ''qualifier'' und ''translation'', werden im Element ''ClinicalDocument.code'' nicht gefüllt.

====ClinicalDocument.title====

{{AttDesc
| ae = elm
| rim = act
| name = title
| desc = Titel des Dokuments
| dt = ST
| card = 0..1
| conf = O
}}
In diesem Tag wird der Titel des Dokumentes dargestellt. In diesem Falle wird konstant "Mutterpass" verwendet.

====ClinicalDocument.effectiveTime====

{{AttDesc
| ae = elm
| rim = act
| name = effectiveTime
| desc = Erstellungsdatum/zeitpunkt des Dokuments
| dt = TS
| card = 1..1
| conf = M
}}
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====

{{AttDesc
| ae = elm
| rim = act
| name = confidentialityCode
| desc = Vertraulichkeitsgrad des Dokuments
{{ConstraintBox|@confidentialityCode MUSS gewählt werden aus Value Set [[2.16.840.1.113883.1.11.16926]] BasicConfidentialityKind STATIC 2010-04-21}}
| dt = CE
| card = 1..1
| conf = M
}}
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. ''@codeSystem'' hat dabei immer den Wert „2.16.840.1.113883.5.25“.

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

{| class="hl7table"
|+Mögliche Vertraulichkeitsangaben in einem CDA-Dokument<ref name="ftn3">http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#CDA_Header</ref>
|-
|{{:2.16.840.1.113883.1.11.16926/static-2010-04-21}}
|}

<syntaxhighlight lang="xml">
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25" />
</syntaxhighlight>

====ClinicalDocument.languageCode====

{{AttDesc
| ae = elm
| rim = act
| name = languageCode
| desc = Sprache der menschenlesbaren Texte des Dokuments
| dt = CS
| card = 0..1
| conf = O
}}
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<ref name="ftn4">http://rfc.net/rfc3066.html</ref> 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<ref name="ftn5">http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html</ref> (Tabelle mit zwei Buchstaben). 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.

<syntaxhighlight lang="xml">
<languageCode code="de-DE"/>
</syntaxhighlight>

====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 authenticated

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.

Die Einbindung elektronischer Unterschriften in einem CDA Dokument ist nicht Gegenstand dieses Leitfadens.

=====authenticator=====

''Kardinalität: <nowiki>[0..n]</nowiki>''

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: <nowiki>[1..1]</nowiki>''

Gibt den Zeitpunkt der Authentisierung an.

=====authenticator.signatureCode=====

''Datentyp: CS ''

''Kardinalität: <nowiki>[1..1]</nowiki>''

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. 

{| class="wikitable"
|+Signierung in einem CDA-Dokument<ref name="ftn6">http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#CDA_Header</ref>
! 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: <nowiki>[1..1]</nowiki>''

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.

<syntaxhighlight lang="xml">
<authenticator>
  <time ... />
  <signatureCode ... />
  <assignedEntity>
    <id ... />
  </assignedEntity>
</authenticator>
</syntaxhighlight>

=====legalAuthenticator=====

''Kardinalität: <nowiki>[0..1]</nowiki>''

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.

<syntaxhighlight lang="xml">
<legalAuthenticator>
  <time ... />
  <signatureCode ... />
  <assignedEntity>
    <id ... />
  </assignedEntity>
</legalAuthenticator>
</syntaxhighlight>

=====dataEnterer=====

''Kardinalität: <nowiki>[0..1]</nowiki>''

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: <nowiki>[1..n]</nowiki>''

Ü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.

<syntaxhighlight lang="xml">
<dataEnterer>
  <assignedEntity>
    <id ... />
  </assignedEntity>
</dataEnterer>
</syntaxhighlight>

=====EncompassingEncounter=====

Diese Klasse beschreibt den Aufenthalt, den der klinische Report dokumentiert. 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. 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: <nowiki>[1..1]</nowiki>''

Dies stellt den Zeitpunkt oder den Zeitraum der Behandlung dar.

=====informant=====

''Kardinalität: <nowiki>[0..n]</nowiki>''

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.

<syntaxhighlight lang="xml">
<informant>
	<assignedEntity>
		<id ... />
	</assignedEntity>
</informant>
</syntaxhighlight>

=====informationRecipient=====

''Kardinalität: <nowiki>[0..1]</nowiki>''

Der ''informationRecipient'' stellt einen Empfänger dar, der eine Kopie des Dokumente 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. 

{| class="wikitable"
|+Empfänger eines CDA-Dokumentes
! XML-Code !! Erklärung
|-
| <code class="ppcode"><informationRecipient typeCode="PRCP"></code>
| Ein primärer Empfänger, an den das Dokument gesendet wird.

|-
| <code class="ppcode"><informationRecipient typeCode="TRC"></code>
| 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: <nowiki>[1..1]</nowiki>''

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.

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

=====participant=====

''Kardinalität: <nowiki>[0..n]</nowiki>''

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.

<syntaxhighlight lang="xml">
<participant typeCode="">
	<associatedEntity classCode="">
...
        </associatedEntity>
</participant>
</syntaxhighlight>

==== Pflichtteilnehmer ====

=====author=====

''Kardinalität: <nowiki>[1..n]</nowiki>''

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: <nowiki>[1..1]</nowiki>''

Gibt den Zeitpunkt der Datenerfassung durch eine Person an.

=====author.assignedAuthor=====

''Kardinalität: <nowiki>[1..1]</nowiki>''

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: <nowiki>[1..n]</nowiki>''

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: <nowiki>[1..1]</nowiki>''

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: <nowiki>[1..n]</nowiki>''

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

<syntaxhighlight lang="xml">
<custodian>
	<assignedCustodian>
		<representedCustodianOrganization>
			<id ... />
		</representedCustodianOrganization>
	</assignedCustodian>
</custodian>
</syntaxhighlight>

=====recordTarget=====

''Kardinalität: <nowiki>[1..n]</nowiki>''

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: <nowiki>[1..n]</nowiki>''

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: <nowiki>[0..1]</nowiki>''

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.

<syntaxhighlight lang="xml">
<recordTarget>
	<patientRole>
		<id ... />
		<patient>
...
                </patient>
	</patientRole>
</recordTarget>
</syntaxhighlight>

=== 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:

'''<nowiki><br></nowiki>''' für einen Zeilenumbruch

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

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

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

'''<nowiki><paragraph></nowiki>''' zur logischen Trennung von zusammengehörigen Textabschnitten

'''<nowiki><table></nowiki>''' 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<ref name="ftn7">Siehe auch http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#CDA_Section_Narrative_Block</ref>.

==== 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.

<syntaxhighlight lang="xml" heading="Beispiel für einen Level 2–Eintrag in einem CDA-Dokument anhand der serologischen Untersuchungen">
<section>
    <nowiki><!-- Serologische Untersuchungen --></nowiki>
    <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>
</syntaxhighlight>

==== 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.<ref name="ftn8">[http://www.hl7.org/library/data-model/RIM/C30204/rim.htm#open-rimdiv http://www.hl7.org/library/data-model/RIM/C30204/rim.htm#open-rimdiv]</ref>

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. 

<syntaxhighlight lang="xml" heading="Beispiel für einen Level 3–Eintrag in einem CDA-Dokument anhand der Blutgruppenzugehörigkeit">
<section>
    <!-- Serologische Untersuchungen -->
    <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>
</syntaxhighlight>

==== 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 '''<nowiki><encounter></nowiki>''' 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.

<syntaxhighlight lang="xml">
<originalText>
	<reference value="#ID10001"/>
</originalText>
</syntaxhighlight>

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.