ImplementierungCDA

Aus Hl7wiki
(Teildokument von Elektronischer Mutterpass)
Wechseln zu: Navigation, Suche
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 .

Inhaltsverzeichnis

Implementierung in CDA

Die Umsetzung eines elektronischen Mutterpasses dokumentiert den Verlauf einer Schwangerschaft. Dabei werden sowohl Vorsorgeuntersuchungen für das Wohl der Mutter als auch des ungeborenen Kindes bzw. der ungeborenen Kinder durchgeführt.

Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA Release 2. CDA wird heute im deutschen Gesundheitswesen bereits für den Arztbrief, Disease Management Programme (DMP) u.a. verwendet.

Allgemeines zur Implementierung

CDA sieht vor, für jede Behandlung ein eigenes Dokument zu erstellen. Diese einzelnen Dokumente werden dann an das ursprüngliche Dokument über Verweise, die als „appends“ bezeichnet werden, angehängt.

Der Mutterpass in Papierform enthält eine Grafik die den Wachstumsverlauf des Fötus zeigt. Diese Grafik wird in der CDA-Abbildung mittels der observationMedia-Klasse in den Mutterpass eingebunden. Die Grafik selbst wird als jpeg- oder png-Bilddatei gespeichert.

Das Dokument beginnt mit dem ClinicalDocument Tag. Dieser wird wie jedes CDA-Dokument in zwei Teile aufgeteilt.

Im ersten Teil, dem Header, werden alle Informationen zu den beteiligten Personen, den mitwirkenden Organisationen und Informationen über das Dokument selbst gespeichert. Der zweite Teil, der CDA-Body, enthält Informationen über die eigentliche Behandlung und über Diagnosen. Im Allgemeinen müssen CDA Release 2 Dokumente für den Menschen lesbar (Level 1) dargestellt werden und können zusätzlich maschinenlesbar (Level 2 und Level 3) codiert werden. In diesem Dokument wird sowohl der menschenlesbare, als auch der maschinenlesbare Teil vorgestellt und als verpflichtend für die Erstellung eines Mutterpasses nach diesem Leitfaden angesehen.

Schwangerschaften, Geburten und Dokumentinstanzen

Der Mutterpass ist eigentlich ein Geburtsdokument. Pro Geburtsfall (also auch Mehrlingsgeburten und Schwangerschaftsabbrüche) wird genau ein CDA-Dokument erstellt.

Wenn sich eine Untersuchung auf das Kind bezieht, wird das Kind mit den entsprechenden Daten, z. B. seiner ID, als subject innerhalb der jeweiligen Untersuchung (Observation) aufgeführt. So ist sichergestellt, dass auch eine Mehrlingsgeburt in dem Dokument verwaltet werden kann. Damit behebt der digitale Mutterpass ein anderes Problem der klassischen Papierform. Es ist nun auch möglich, die Daten über mehr als zwei Kinder innerhalb eines Dokumentes zu speichern. Wird eine Mutter erneut schwanger, wird eine neue CDA-Instanz vom Typ Mutterpass erzeugt.

Textinhalte

Die Textinhalte von Level1 text müssen, wie es CDA vorschreibt, mit den Level 3 Informationen übereinstimmen und sollten so gewählt werden, dass sie direkt visualisiert werden können (z. B. 11:30h anstelle von 1130 bei einer Zeitangabe). Bei Telefonnummern sollte ein in Deutschland gebräuchliches Format gewählt werden (z. B. (0221)12323 anstelle von 0221.12323).

Booleanwerte

Die Booleanwerte in den Observations, welche die Werte True und False annehmen können, werden im Textteil mit Ja und Nein dargestellt.

Zahlenwerte

Die Zahlenwerte innerhalb der observation werden in englischer Schreibweise geschrieben. Das bedeutet, dass die Dezimalstellen durch Punkte getrennt sind. Der Textteil wird komplett in deutscher Sprache gehalten. Deshalb werden die Zahlen dort in deutscher Schreibweise durch Kommata getrennt dargestellt.

Statuscode

Jede Untersuchung, die durchgeführt wurde und abgeschlossen ist, erhält einen statusCode mit dem Inhalt completed. Da im Mutterpass momentan nur Untersuchungen (Observations) abgebildet werden, die schon durchgeführt wurden, steht standardmäßig bei jeder Untersuchung ein <statusCode code="completed"/>. Das gleiche gilt für organizer.

Referenzieren zwischen Level 1 und Level 3

Auf die Referenzierung zwischen Level 1 und Level 3 wurde in diesem Implementierungsleitfaden verzichtet, da sie in den meisten Fällen nicht möglich ist. Man kann den Value nur referenzieren, wenn er vom Typ CD ist. Die meisten der im Mutterpass enthaltenen Observations sind aber vom Typ Boolean oder String. So dass das Referenzieren nur in einem geringen Teil der Observations möglich wäre. Um die Übersichtlichkeit der Dokumente zu erhöhen und einen möglichst homogenen Aufbau der verschiedenen Observation-Typen zu realisieren, wurde ganz darauf verzichtet.

Codesystem

Für semantisch zusammenhängende Codes kann man ein gemeinsames Codesystem definieren. Wenn nun ein bestimmtes Attribut nur eine definierte Untermenge dieses Codesystems unterstützt, wird dies durch Constraints festlegt.

Gegeben:

  1. Eine Untersuchung (Observation 1) mit der Werteliste „ja", „nein" oder „normal".
  2. Eine weitere Untersuchung (Observation 2) mit den möglichen Werten „ja", „nein", „normal", „Kontrolle".

In diesem Fall würde man ein Codesystem für die Werte „ja", „nein", „normal", „Kontrolle" definieren. Für Observations vom Typ Observation 1 würde man festlegen, dass sie alle Werte aus der Codetabelle mit Ausnahme von „Kontrolle" annehmen können. Diese Einschränkung (Constraint) erfolgt innerhalb dieses Leitfadens und ist aus der Mapping-Tabelle zu entnehmen (siehe Anhang).

Codes

Da fast alle Felder des Mutterpasses in keinem bekannten Codesystem definiert waren, wurden für die meisten Felder eigene Codetabellen definiert. Diese Codetabellen befinden sich im Anhang. Alle Codes innerhalb des CDA-Dokumentes sind „case sensitive“.

Implementierung des Header

typeId

Da es sich bei der typeId um ein konstantes Element handelt, muss dieses wie folgt gefüllt werden. 

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

id

Die Dokumenten-ID setzt sich aus zwei Teilen zusammen. Bei dem @root-Attribut handelt es sich bei jedem Mutterpass innerhalb eines Systems um einen konstanten Wert, da das @root-Attribut das erzeugende System des Dokumentes angibt. Das zweite Pflichtattribut ist das @extension-Attribut. Der Wert dieses Attributes ist eine eindeutige Nummer. Dieses kann entweder eine fortlaufende Nummer sein, die nach dem Erstellen eines Dokumentes um den Wert „Eins“ erhöht wird, oder eine innerhalb des definierten Systems eindeutige Nummer.

code

Das code-Element besitzt wiederum zwei fest vorgeschriebene Attribute. Das @code-Attribut und das @codeSystem-Attribut. Für die eindeutige Typisierung des Mutterpasses wird das ICW-Codesystem für Dokumente verwendet. Hier wird der Wert 2.16.840.1.113883.3.37.1.9.10.1 in das Attribut @codeSystem eingetragen.

Der spezifische Mutterpass-Code „MP01“ befindet sich im Attribut @code. In das optionale Attribut @displayName wird der String „Mutterpass“ eingetragen, welcher nicht vom empfangenden System ausgewertet werden darf. 

<code 	code="MP01" 
	codeSystem="2.16.840.1.113883.3.37.1.9.10.1" 
	codeSystemName="ICW-GEN-DOCUMENT-TYPE-DE" 
	displayName="Mutterpass"/>

effectiveTime

Über effectiveTime wird das Erstellungsdatum des Dokuments angegeben. Die Angabe erfolgt mindestens Tagesgenau (JJJJMMTT). 

<effectiveTime value="20050924"/>

confidentialityCode

Über confidentialityCode wird die Vertraulichkeit des Dokuments angegeben. Das verwendete @codeSystem ist die Vokabel-Domäne für den confidentialityCode (2.16.840.1.113883.5.25). Die möglichen Werte für das code-Attribut sind:

  • N (normal)
  • R (restricted)
  • V (very restricted)
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>

Wenn nichts spezielles angegeben wird, wird der ConfidentialityCode beim Mutterpass immer auf den Default-Wert „N“ gesetzt.

languageCode

Beim Mutterpass handelt es sich um einen Standard, der momentan nur im deutschsprachigen Raum eingesetzt werden soll, so dass die Angabe der verwendeten Sprache nicht unbedingt notwendig ist. Aus dieser bestehenden XML-Spezifikation soll langfristig ein internationaler Standard entstehen, deshalb sollte auch eine Zuordnung zur verwendeten Sprache existieren.

Sollte dieses Element implementiert werden, wird der Wert des @code-Attributes standardmäßig auf „de-DE“ gesetzt. Daraus ergibt sich folgender Aufbau. 

<languageCode code="de-DE" codeSystem="2.16.840.1.113883.6.121" />

setId und versionNumber

Die Elemente setId und versionNumber werden eingesetzt um CDA-Dokumente zu versionieren oder Beziehungen zwischen Dokumenten herzustellen.

Die setId setzt sich zusammen aus einem @root-Attribut und einem @extension-Attribut. Bei der versionNumber handelt es sich um eine fortlaufende Nummer, die beim Aktualisieren immer um eins erhöht wird. Beide Elemente dürfen nur gemeinsam vorkommen.

Beteiligte Personen

Authenticator (Im Rahmen dieser Arbeit nicht realisiert)

Beim Mutterpass sind verschiedene Unterschriften für das Dokument möglich, da mehrere Personen an der Dokumentation mitwirken können. In der aktuellen Papierform kann z. B. jede serologische Untersuchung durch einen anderen Arzt durchgeführt und unterschrieben werden.

Eine Unterschrift kann nur im Attribut @signatureCode von authenticator und legalAuthenticator festgehalten werden. Beide können aber nur im Header und nicht im Body (section, observation etc.) angegeben werden. Die Idee ist, die verschiedenen Unterschriften der einzelnen Observations im Header über verschiedene authenticator´s zu hinterlegen. Bei den einzelnen Observations wird dann ein participant angelegt, der die gleiche ID bekommt wie der entsprechende authenticator im Header.

Laut CDA-Spezifikation gilt sowohl der authenticator, als auch der legalAuthenticator für das gesamte Dokument. Im Mutterpass werden Authenticators im Header lediglich identifiziert. Es kann sein, dass Teile (im Body) jeweils verschiedene Authenticators haben. Diese müssen dann in der Participant-Klasse referenziert werden (siehe Beispiel unten). Insofern wird ein Link gelegt zwischen dem Header und den Abschnitten aus dem Body. 

<!-- ********************* HEADER **************************-->
...
<authenticator>
    <signatureCode code="ASDF" codeSystem="EAA"></signatureCode>
    <assignedEntity>
        <id extension="000001" root="1.2.3.4.5"/>
        <assignedPerson>
            <name>
                <prefix qualifier="AC">Dr. med.</prefix>
                <given>Hans</given>
                <family>Mueller</family>
            </name>
        </assignedPerson>	
    </assignedEntity>
</authenticator>	

<authenticator>
    <assignedEntity>
        <id extension="000002" root="1.2.3.4.5"/>
        <assignedPerson>
            <name>
                <prefix qualifier="AC">Dr. med.</prefix>
                <given>Lieschen</given>
                <family>Meyer</family>
            </name>
        </assignedPerson>	
    </assignedEntity>
</authenticator>	

<!-- ********************* BODY **************************-->
<!-- Für diese Observation ist nur der 1. Authenticator verantwortlich -->
<observation classCode="OBS" moodCode="EVN">
    <!-- Blutgruppe -->
    <code 	code="BLDTYP" codeSystem="2.16.840.1.113883.3.37.1.9.11.9.1" 
        codeSystemName="ICW-GEN-OBSERVATION-CODE-DE" 
        displayName="Blutgruppe">
        <participant typeCode="AUTHEN">
            <participantRole>
                <!-- siehe authenticator 1 -->
                <id extension="000001" root="1.2.3.4.5"/>	
            </participantRole>
        </participant>
    </code>
    <statusCode code="completed"/>
    <value xsi:type="CD" code="A" 
        codeSystem="2.16.840.1.113883.3.37.1.9.11.16.1" 
        codeSystemName="BLOOD_TYPE">
    </value>
</observation>

Mutter

Die Mutter ist recordTarget des Mutterpasses, d.h. die Dokumentation gehört auch zu ihrer Akte. recordTarget wird im Header folgendermaßen angegeben: 

<!-- ********************* HEADER **************************-->
<recordTarget>
    <patientRole>
        <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>
        <addr>
            <streetName>Musterstraße</streetName>
            <postalCode>50825</postalCode>
            <city>Köln</city>
        </addr>
        <telecom use="HP" value="tel:+49(221)7812220"/>
        <telecom use="HP" value="mailto:MuellerMar@gmx.de"/>
        <patient>
            <name>
                <given>Marie</given>
                <family>Müller</family>
            </name>
            <administrativeGenderCode 	code="F" 
                codeSystem="2.16.840.1.113883.5.1"/>
            <birthTime value="19700924"/>
            <birthplace>
                <place>
                    <addr>
                        <city>Köln</city>
                    </addr>
                </place>
            </birthplace>
        </patient>
        <!-- Daten der Praxis wo der Patient gemeldet ist -->
        <providerOrganization>
            <id root="1.2.276.0.76.4.5" extension="22222"/>
            <name>Musterklinik</name>
            <telecom use="WP" value="tel:+49(221)1199282"/>
            <addr>
                <streetName>Muster-Allee</streetName>
                <houseNumber>10</houseNumber>
                <postalCode>50825</postalCode>
                <city>Köln</city>
            </addr>
        </providerOrganization>
    </patientRole>
</recordTarget>

Autor

Der Arzt, der für die gesamte Dokumentation des Mutterpasses verantwortlich ist, wird als author im Header angelegt. 

<author>
    <time value="200610101821"/>
    <assignedAuthor>
        <id root="2.16.840.1.113883.3.24535" extension="190388km89"/>
        <telecom value="tel: (0221)12345"/>
        <assignedPerson>
            <name>
                <prefix qualifier="AC">Dr. med.</prefix>
                <given>Gustav</given>
                <family>Muster</family>
            </name>
        </assignedPerson>
        <representedOrganization>
            <id root="1.2.276.0.76.4.5" extension="22222"/>
            <name>Musterklinik</name>
            <telecom use="WP" value="tel:+49(221)1199282"/>
            <addr>
                <streetName>Muster-Allee 17</streetName>
                <houseNumber>10</houseNumber>
                <postalCode>50825</postalCode><city>Köln</city>
            </addr>
        </representedOrganization>
    </assignedAuthor>
</author>

Custodian

Hier wird das Dokument verwaltet, also auch geändert. Da keine zentrale Institution in Deutschland existiert, custodian aber Pflicht ist, werden hier die gleichen Daten wie in der providerOrganisation der Mutter eingetragen. 

<custodian>
    <assignedCustodian>
        <representedCustodianOrganization>
            <id root="1.2.276.0.76.4.5" extension="22222"/>
            <name>Musterklinik</name>
            <telecom use="WP" value="tel:+49(221)1199282"/>
            <addr>
                <streetName>Muster-Allee</streetName>
                <houseNumber>10</houseNumber>
                <postalCode>50825</postalCode><city>Köln</city>
            </addr>
        </representedCustodianOrganization>
    </assignedCustodian>
</custodian>

Kind

Sobald das Kind geboren wurde, können auch Untersuchungen direkt an ihm vorgenommen werden.

Da das Kind nicht direkt an den Untersuchungen im Mutterpass beteiligt ist, sondern nur Informationen über das Kind von der Mutter erfragt werden (z. B. „Wurde eine U3 durchgeführt?“), taucht es nicht als participant im Header auf, sondern nur als subject bei den jeweiligen Observations, die ihm zugeordnet werden können. Innerhalb der Observations wird das Kind über seinen Namen identifiziert. Optional können auch noch Geschlecht und Geburtsdatum angegeben werden.

Bei Mehrlingsgeburten können so die Einträge zu den verschiedenen Kindern unterschieden werden.

Da erstens für das ungeborene Baby noch keine eigene Akte besteht, zweitens der Mutterpass nicht in einer Kindakte abgelegt wird und drittens ungeborene Babys noch nicht eindeutig identifiziert werden können, wird das ungeborene Baby nicht in den Headers als zweites recordTaget mit aufgenommen.

Solange das Kind noch nicht geboren ist, sind alle klinischen Befunde des Gravidogramms und auch der Ultraschallbefunde formal noch der Mutter zuzuordnen. Dies bedeutet, dass beispielsweise die Herztöne des Kindes gemessen werden, jedoch die Untersuchung formal eine Untersuchung an der Mutter ist. Wenn kein subject angegeben ist, ist das recordTarget automatisch das Subjekt einer Observation.

Untersuchungen im Mutterpass, die sich auf das ungeborene Kind beziehen, aber der Mutter zugeordnet werden.
Untersuchung Untersuchungsbereich
Herztöne Gravidogramm
Kindsbewegungen Gravidogramm
Embryo darstellbar Screening I
Auffälligkeiten Screening I
Bewegung Screening II / Screenin III
Kindslage Gravidogramm / Screening III / Zwischenuntersuchung
Einling Screening II / Screenin III / Zwischenuntersuchung
Lebenszeichen Screening II / Screenin III / Zwischenuntersuchung
körperliche Entwicklung Screening II / Screenin III / Zwischenuntersuchung
Körperumriss Screening II / Screenin III / Zwischenuntersuchung
fetale Strukturen Screening II / Screenin III / Zwischenuntersuchung
Herztätigkeit Screening I / Screening II / Screening III
Zeitgerechte Entwicklung Screening I / Screening II / Screening III /Z-Untersuchung
Untersuchungen im Mutterpass, die sich auf das geborene Kind und nicht auf die Mutter beziehen (kenntlich gemacht durch <subject>.).
Untersuchung Untersuchungsbereich
vollendete SSW Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
extern entbunden Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Lebendgeburt Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Geburtsmodus Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Kindslage Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Körpergewicht Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Kindsgeschlecht Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Geburtstag (min-genau) Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Körperlänge Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Kopfumfang Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Apgar-Zahl 5´ / Apgar-Zahl 10´ Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
ph-Wert (Nabelarterie) Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
BE Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
auffällige Fehlbildung Angaben zur Geburt (Abschluss-Untersuchung/Epikrise)
Kind unauffällig entlassen am Wochenbett (Kind)
Kind verlegt am Wochenbett (Kind)
Kind verstorben am Wochenbett (Kind)
Untersuchung 3 (durchgeführt) 2. Untersuchung nach Entbindung
lebt ist gesund 2. Untersuchung nach Entbindung
ist laut U3 behandlungsbedürftig 2. Untersuchung nach Entbindung
ist verstorben am 2. Untersuchung nach Entbindung

Implementierung des Body

Der Body eines CDA Release 2 Dokuments besteht aus einem component-Element gefolgt von einem structuredBody-Element und wird auch mit diesen Elementen geschlossen. Diese beiden Tags bilden den Rahmen, den jeder CDA Release 2 - Body haben muss.

Der structuredBody eines CDA Release 2 Dokuments setzt sich aus ein oder mehreren Komponenten zusammen, wobei jede Komponente nur aus einer section bestehen kann und vor jeder neuen Section ein component stehen muss. Innerhalb der Sections gibt es einen titel, ein text- Element und ein oder mehrere entry-Elemente. 

<component>
    <structuredBody>
        <component>
            <section>
                <title>Titel</title>
                <text>
                    Menschenlesbarer Teil (Level 1)
                </text>
                <entry>
                    Maschinenauswertbarer Teil (Level 3)
                </entry>
            </section>
        </component>
    </structuredBody>
</component>

Author im Body

Im Body des Mutterpasses wird der author nur dann angeben, wenn er vom author aus dem Header abweicht. Da immer dieser Author als Default angenommen wird, wäre diese Angabe ansonsten redundant und würde das Dokument unnötig aufblähen.

Sections

Sections dienen zur logischen Aufteilung eines CDA-Dokumentes in bestimmte Unterbereiche. Das dient hauptsächlich dazu, die Navigation durch ein solches Dokument und damit die menschliche Lesbarkeit zu erhöhen. 

<section>
    <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>
   ...
</section>

Section.code

Jedes section-Element enthält ein code-Element, das den Inhalt des Abschnitts klassifiziert und somit das Dokument CDA Release 2 Level 2 - konform macht. Zum Beispiel ist „MP-SEC-0018“ der Code für „Ultraschall-Untersuchungen“. Laut CDA-Spezifikation sind zur primären Klassifikation ausschließlich LOINC-Codes zugelassen. Alternative Codes können durch das Attribut @code im Element translation angegeben werden.

Das code-Element dient zur eindeutigen Identifizierung der section. Die zwingenden Attribute sind @code und @codeSystem. Der Code stellt das codierte Element dar und das Codesystem gibt an, wo der Code definiert ist. Mit @codeSystemName besteht optional noch die Möglichkeit den Namen des verwendeten Codesystems anzugeben. Die Angabe des @displayName kann überall dort gemacht werden, wo das code-Element verwendet wird. 

<code code="CodeNr." codeSystem="CodesystemOID" codeSystemName="z.B LOINC" displayName="z. B. Blutgruppe"/>

Section.title

In das title-Element unterhalb von section wird jeweils der Titel angegeben. Der Titel ist ein optionales Feld und darf höchstens einmal pro section vorkommen. 

<section>
    <code code="dieCodeNummer" codeSystem="dasCodesystem" />
    <title>Serologie</title>
   ...
</section>

Section.text

Jede section muss genau ein text-Element beinhalten, das nicht leer sein darf. Innerhalb des text-Elements sind im Mutterpass nur Tabellen zugelassen.

Level 1 im Mutterpass

Grundsätzlich besteht für den Textteil innerhalb eines CDA- Dokumentes keine Vorgabe, wie dieser auszusehen hat. Er soll lediglich „menschenlesbar“ sein.

Um eine bessere Übersichtlichkeit und einheitlichere Darstellung zu erhalten, werden im Folgenden ein paar Regeln zur Füllung des Level 1 für Mutterpass- Dokumente festgehalten.

Zur Repräsentation medizinischer Inhalte, die sich adäquat tabellarisch darstellen lassen, bietet sich die Tabellenform an. CDA realisiert ein vereinfachtes XHTML Table Modell, das HTML sehr ähnelt. Eine Tabelle beginnt mit dem table-Element.

Eine Tabelle besteht aus einer oder mehreren Spalten. In der ersten Zeile werden die Spaltenüberschriften aufgeführt.

Die Tabellenüberschrift wird eingeschlossen in caption-Elemente. Der Tabelleninhalt wird im tbody (tableBody) über das tr-Element (für die Zeile) und die Elemente th (tablehead) und td (tableData) für Spalte eingefügt.

Im folgenden Beispiel wird der Aufbau einer Tabelle in einem CDA-Dokument exemplarisch aufgezeigt. 

<title>Seriologische Untersuchungen</title>
<text>
    <table>
        <caption>Blutgruppenzugehörigkeit</caption>
        <tbody>
            <tr>
                <th>Datum der Untersuchung:</th>
                <td>21.08.2005</td>
            </tr> ... </tbody>
    </table>
</text>

Elemente im Level 1 des Mutterpasses und deren Bedeutung

title

Im title-Element steht die Überschrift der jeweiligen section. Diese stimmt mit dem Attribut @displayName des translation-Elementes unterhalb von code überein.

text

Innerhalb des text-Elementes folgen die Tabellen mit der klinischen Dokumentation.

table

Die Anzahl der Tabellen richtet sich nach den enthaltenen organizer-Elementen im zugehörigen Level 3.

caption

Innerhalb der caption wird der Inhalt der nachfolgenden table beschrieben. Der Inhalt des caption-Elementes entspricht dem @displayName-Attribut aus dem zugehörigen organizer im Level 3.

tbody

Innerhalb des tbody-Elementes folgen die weiteren Tabellenelemente.

tr

Das tr-Element beinhaltet die Elemente th und td.

th

Das th-Element entspricht dem @displayName Attribut aus dem code-Element der zugehörigen observation in Level 3.

td

Innerhalb des td-Elementes stehen die Daten der jeweils zugehörigen Untersuchung aus Level 3. Hierbei gibt es Unterschiede, die von dem Observation-Typ abhängen. Die verschiedenen Observations und wie die Information in Level 1 dargestellt wird, sind in folgender Tabelle dargestellt.

Level 1- Darstellung der verschiedenen Observation-Typen
Observation-Typ Darstellung innerhalb des <td> Elementes in Level 1
Observation_ST Der Inhalt des value-Elementes kann aus Level 3 übernommen werden.
Observation_TS Der Inhalt des value-Elementes kann aus Level 3 mit einer entsprechenden Transformation in eine gebräuchliche Zeitangabe übernommen werden.
Observation_INT Der Inhalt des value-Elementes kann aus Level 3 übernommen werden.
Observation_REAL Der Inhalt des value-Elementes kann aus Level 3 übernommen werden.
Observation_CD Die klartextliche Bedeutung des @code-Attributes aus Level 3 wird eingefügt.
Observation_BL Die klartextliche Bedeutung des @value-Attributes aus Level 3 wird eingefügt.
Observation_PQ Der Inhalt des @value-Attributes und der Inhalt des @unit-Attributes (bei der Angabe von Tagen wird die klartextliche Bedeutung eingefügt) werden mit einem Leerzeichen konkateniert.
ObservationMedia Das Element renderMultiMedia referencedObject=""/ wird eingefügt. Das '@referencedObject' Attribut wird durch das @ID-Attribut innerhalb des observationMedia-Elementes gefüllt.

Besonderheiten bei der Füllung von Level 1

Diese Daten werden zusätzlich zu den vorher aufgeführten Observations in Level 1 übernommen: 

<tr>
  <th>Protokoll-Nr. des Laboratoriums:</th>
  <td>25861</td>
</tr>

<tr>
  <th>Datum der Untersuchung</th>
  <td>12.4.2006</td>
</tr>

<tr>
  <th>Kommentar-IgG:</th>
  <td>Kommentar</td>
</tr>

| code =
<tr>
  <th>Nächster Arzttermin</th>
  <td>12.05.2006, 11:30h</td>
</tr>

Encounter

Mit encounter-Angaben werden frühere, jetzige oder geplante Patientenkontakte abgebildet. Im Mutterpass werden damit die Termine für die einzelnen Untersuchungen festgehalten. Ein encounter besitzt zwei Pflichtattribute @classCode und @moodCode. Das Attribut @classCode hat den konstanten Wert „ENC“. Das bedeutet, dass eine Interaktion zwischen einem Patienten und einem „healthcare participant“ durchgeführt wird. Diese Interaktion dient zur Feststellung des Gesundheitszustandes eines Patienten oder zur Durchführung von Serviceleistungen am Patienten. Das zweite Attribut, @moodCode, kann im Mutterpass einen von zwei Werten annehmen: EVN (event) und APT (appointment). Ein event beschreibt das tatsächliche Auftreten eines Ereignisses, während appointment für ein geplantes Ereignis steht, dessen Ort und Zeitpunkt festgelegt sind.

Unterhalb von encounter gibt es zwei Pflichtelemente.

  • code
  • effectiveTime

encounter.code

Der code muss aus dem @codeSystem 2.16.840.1.113883.5.4 sein. Somit haben alle Encounter, die im Mutterpass vorkommen, das gleiche @codeSystem, den gleichen @codeSystemName und @displayName. Der Inhalt vom Attribut @code ist davon abhängig, ob es sich um eine ambulante oder stationäre Behandlung handelt. Im ersten Fall wird der Wert „AMB“ in @code eingetragen und im zweiten Fall wird „IMP“ eingetragen.

encounter.effectiveTime

In dem Unterelement effectiveTime von encounter wird der Zeitpunkt oder das Zeitintervall der Untersuchung angegeben. 

<encounter classCode="ENC" moodCode="APT">
    <!-- nächster Termin -->
    <code code="AMB" codeSystem="2.16.840.1.113883.5.4" 
        codeSystemName="ActEncounterCode" 
        displayName="ambulanter Arztbesuch"/>
    <!-- Zeitpunkt des Termins, inklusive Uhrzeit -->
    <effectiveTime value="200605121130"/> 
</encounter>

<encounter classCode="ENC" moodCode="EVN">
    <!-- stationäre Behandlung -->
    <code code="IMP" codeSystem="2.16.840.1.113883.5.4" 
        codeSystemName="ActEncounterCode" 
        displayName="stationäre Behandlung"/>
    <effectiveTime xsi:type="IVL_TS">
        <low value="20061010"/>
        <high value="20061111"/>
    </effectiveTime>
</encounter>

Procedure

Mit procedure werden Behandlungsmaßnahmen festgehalten, die den Zustand des Patienten verändern. Da der Mutterpass im Wesentlichen nur aus Vorsorgeuntersuchungen besteht, werden in der Regel keine procedure benötigt. Einzige Ausnahme bilden die erfassten stationären Behandlungen. In diesem Fall wird eine procedure mit einem entsprechenden OPS-Code als entryRelationship innerhalb des encounter „stationäre Behandlung“ erstellt.

Bei OPS handelt es sich um einen „Operationen- und Prozedurenschlüssel“ der zum Zwecke der Klassifikation von medizinischen Prozeduren im Krankenhaus und im Bereich von ambulanten Operationen dient. Wie und wann die Schlüssel verwendet werden, kann beim DIMDI (Deutsches Institut für Medizinische Dokumentation und Information) nachgelesen werden[1]. 

<encounter classCode="ENC" moodCode="EVN">
    <!-- stationäre Behandlung -->
    <code code="IMP" codeSystem="2.16.840.1.113883.5.4" codeSystemName="ActEncounterCode" displayName="stationäre Behandlung"/>
    … 
    <entryRelationship typeCode="COMP">
        <procedure classCode="PROC" moodCode="EVN">
            <code code="1-697.7" codeSystem="1.2.276.0.76.5.310" codeSystemName="ops2006" displayName="Kniegelenk"/>
        </procedure>
    </entryRelationship>
    … 
</encounter>

ObservationMedia

Mit der Klasse observationMedia ist es möglich, auf externe Multimediaobjekte zu verweisen. Sie enthält alle Informationen über das Objekt. Unterhalb von observationMedia ist das Element value zwingend vorgeschrieben. Neben dem Datentyp enthält value ein Referenz-Element mit einem Verweis auf das eigentliche Multimedia-Objekt.

Der Datentyp von Multimedia-Objekten ist immer ED (encapsulated data). Weiterhin ist im Mutterpass der Medientyp (MIME) im @mediaType-Attribut immer image/jpeg, da nur Bilder referenziert werden. Das Format jpeg wurde gewählt, weil die Bilder nicht zur Diagnose herangezogen werden und so eine geringe Verlustbehaftung in Kauf genommen werden kann. Es ist aber auch eine Einbindung vom Typ image/png möglich, dabei handelt es sich um eine verlustfreie Komprimierung. Das Attribut @ID innerhalb von observationMedia muss innerhalb des Dokumentes eindeutig bleiben, da es eine ganz bestimmte Grafik kennzeichnet, auf die referenziert wird.

Das Element id unterhalb von observationMedia bekommt die vollständige ID des momentanen Dokuments, da dieser Grafik-Knoten genau diesem CDA zugeordnet ist. 

<id root= <nowiki>ROOT-OID . [49 Ziffern].1.patientID.patientRecordEntryID</nowiki> />

Mit Hilfe des renderMultiMedia-Elementes kann auf das observationMedia-Objekt referenziert werden. Dazu wird im @referencedObject-Attribut die eindeutige ID des Objektes eingetragen. So kann von mehreren Stellen auf das Objekt referenziert werden. Im Mutterpass findet sich eine solche Referenz immer im entsprechenden Textteil. 

  <tr>
    <th>Normkurven<renderMultiMedia referencedObject="Norm1"/>
    </th>
  </tr>
</tbody>

<observationMedia classCode="OBS" moodCode="EVN" ID="Norm1">
  <id root="2.23.56345.234.222.4435"/>
  <value xsi:type="ED" mediaType="image/jpeg">
    <reference value="untitled.JPG"/>
  </value>
</observationMedia>

Observations

Gruppierung von Observations

Im elektronischen Mutterpass gibt es zwei Konzepte, Observations zu gruppieren:

1) Observations mit entryRelationship und

2) Gruppierung mit Hilfe von organizer.

1) Bei Observations mit entryRelationship handelt es sich um Observations, die zu einer übergeordneten observation gehören. Dies trifft auf die serologischen Untersuchungen im Mutterpass zu. Für den Röteln-HAH-Test wird z. B. eine observation und die zugehörigen Untersuchungen, wie die Bestimmung des Titer, als entryRelationship.observation angelegt.

2 a) Um Beobachtungen, die in einen gemeinsamen semantischen Kontext gehören, zu gruppieren, gibt es einen so genannten organizer vom Typ BATTERY. Dieser hat lediglich die Bedeutung, eine Mappe für die Einzelbeobachtungen darzustellen und dadurch den Kontext deutlich zu machen. Das hat unter anderem auch den Vorteil, dass z. B. der Autor der Informationen oder das Subjekt, auf das sich die Informationen beziehen, nur einmal für die gesamte Mappe genannt und nicht bei jeder observation angegeben werden müssen. Beispielhaft könnten hier „Informationen zu einer vorangegangenen Schwangerschaft" angegeben werden. In einem anderen Szenario als dem Mutterpass könnten unter diesem organizer auch andere Untersuchungen zusammengefasst werden.

2 b) Neben dem organizer vom Typ BATTERY gibt es einen organizer vom Typ CLUSTER. Mit diesem organizer gruppiert man Untersuchungen, die nicht unterschiedlich sind, sondern die gleiche Bedeutung haben. Ein typischer Anwendungsfall wäre z. B. das n-malige Durchführen der gleichen Untersuchung.

entryRelationship
  • observation.entryRelationship bei allen Serologien außer Blutgruppe
  • encounter.entryRelationship bei „stationäre Behandlung"
Organizer-BATTERY
  • alle Informationen zu einer der vorangegangenen Schwangerschaften
  • alle Informationen, die in einer Zeile des Gravidogramms zusammengefasst werden
  • alle Informationen zur vaginalen Untersuchung
  • alle Informationen zu MMU
  • alle Informationen zu einer CTG Behandlung (inkl. Bild)
  • alle Informationen zu Screening I / II / III / Z-Untersuchung / Kontrolle nach 1b / c / d
  • alle Angaben zur Schwangerschaft
  • alle Angaben zum Wochenbett, die Mutter betreffend
  • alle Angaben zum Wochenbett, das Kind betreffend
  • alle Angaben zur Geburt
  • alle Angaben zur 2. Untersuchung, die Mutter betreffend
  • alle Angaben zur 2. Untersuchung, das Kind betreffend
  • Zyklus3 und Zyklus28:
  • Sediment (mit Eiweiß/Zucker/Nitrit/Blut/Leukozyten)
Organizer-CLUSTER

Werden im Moment nicht verwendet.

Observation-code

Bei Observations werden Codesets aus verschiedenen Codesystemen benutzt. Eines davon ist eine Untermenge von LOINC, weitere sind im Rahmen dieser Arbeit eigens für den Mutterpass erstellt worden (siehe Anhang Codetabelle). Sowohl die Codesets aus dem LOINC, als auch die eigens definierten, werden direkt unterhalb der observation im code eingetragen und nicht etwa wie das bei den Sections der Fall ist, mit @nullFlavour und translationCode. 

<observation classCode="OBS" moodCode="EVN">
    <!-- Kindsgewicht -->
    <code code="3137-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Körpergewicht"> </code>
    <statusCode code="completed"/>
    <value xsi:type="PQ" value="2700" unit="g"/>
</observation>

<observation classCode="OBS" moodCode="EVN">
    <code code="PRGDUR" codeSystem="2.16.840.1.113883.3.37.1.9.11.9.1" codeSystemName="ICW-GEN-OBSERVATION-CODE-DE" displayName="SS-Dauer in Tagen"/>
    <statusCode code="completed"/>
    <value xsi:type="PQ" value="290" unit="d"/>
</observation>

Laboruntersuchungen

Eine observation besteht mindestens aus einem Code, einem Inhalt (Value) und einem Datum. Bei Laborergebnissen muss, soweit vorhanden, ein LOINC-code für das angewendete Laborverfahren der Einzelbeobachtung angegeben werden. Als ID muss die Auftragsnummer des Laborauftrages verwendet werden. Für einen Messwert ist die Angabe von genau einer UCUM-Einheit[2] zwingend erforderlich, sofern eine solche existiert.

Ein Messwert ist eine physikalische oder chemische Größe, die aus Maßzahl und Einheit besteht (siehe Beispiele „Observation codes“).

Kontrolluntersuchungen

Ob es sich bei der Untersuchung um eine Kontrolluntersuchung handelt, wird bei der observation nicht explizit mit angegeben. Da es sich bei einer Untersuchung nur um eine Kontrolluntersuchung handeln kann, wenn innerhalb des Dokumentes schon eine Untersuchung im gleichen Kontext durchgeführt wurde, wird die älteste Untersuchung als „Original“ verwendet. Das heißt, ob es sich um eine Kontrolluntersuchung handelt, kann man dem Datum (effectiveTime) der zugehörigen observation entnehmen.

Observation-author

Innerhalb der Observations wird ein author nur dann angeben, wenn er von allen Autoren die im Header aufgenommen sind abweicht. Da die Autoren im Header immer als Default angenommen werden, wäre diese Angabe ansonsten redundant und würde das Dokument unnötig aufblähen.

Observation-participant

Mit participant würde man einen zusätzlichen Teilnehmer identifizieren. Per Default ist immer die Mutter (recordTarget aus dem Header) das Subjekt einer Observation, d.h. diejenige, an der die Observation durchgeführt wurde. Daher muss sie nicht jedes Mal mit angegeben werden.

Observation-subject

Das subject wird nur dann angegeben, wenn das Untersuchungsobjekt vom recordTarget aus dem Header abweicht. Dies ist z. B. dann der Fall, wenn Untersuchungen am Kind durchgeführt oder Beobachtungen bezüglich der Geschwister festgehalten werden.

Unter „Vorangegangene Schwangerschaften“ werden Angaben zu anderen Kindern der werdenden Mutter gemacht. Dies wird dadurch kenntlich gemacht, dass den betreffenden Observations ein entsprechendes subject zugeordnet wird. Dieses überschreibt die als recordTarget angegebene Person (= Mutter), die normalerweise als subject für eine observation angenommen wird. Wenn eine observation sich auf die Mutter bezieht, muss das subject-Element nicht angegeben werden: 

<subject>
    <relatedSubject classCode="PRS">
        <code code="CHILD" codeSystem="2.16.840.1.113883.5.111"/>
        <subject>
            <name>
                <given>Sofie</given>
                <family>Müller</family>
            </name>
            <administrativeGenderCode code="F" 
                codeSystem="2.16.840.1.113883.5.1"
                codeSystemName="administrativeGender" 
                displayName="weiblich"/>
            <birthTime value="200610101111"/>
        </subject>
    </relatedSubject>
</subject>

Verschiedene Statusformen von Observations

Alle Observations die im Mutterpass vorkommen, folgen einem definierten Aufbau. Dadurch ist die Anzahl der Observations, die einen unterschiedlichen Aufbau besitzen, beschränkt. Die folgenden Statusformen, die beschrieben werden, bilden eine komplette Übersicht über die im Mutterpass eingesetzten Observations, die sich lediglich im variablen Teil wie code oder Textteil und Befund unterscheiden. Alle Observations, die im Mutterpass vorkommen, lassen sich auf eine der folgenden Arten abbilden und besitzen somit auch die gleichen Unterelemente und Attribute.

  • Observation 1: Geplante Observation
  • Observation 2: Durchgeführt – ohne Ergebnis
  • Observation 3: Durchgeführt – mit Ergebnis
    • Observation mit boolean-Werten (BL)
    • Observation mit boolean-Werten und Qualifier zur Seitenlokalisation (BLQL)
    • Observation mit boolean-Werten und Freitext (BLST)
    • Observation mit Code (CD)
    • Observation mit Code und Qualifier für Diagnosen (CDQL)
    • Observation mit Code und Freitext (CDST)
    • Observation mit Zahlenwert (INT)
    • Observation mit Messwert und Maßeinheit (PQ)
    • Observation mit String (ST)
    • Observation mit Zeitangabe (TS)
    • Observation mit Wertebereich (RTO)

Observation Typ 1: Geplante Observation

Die Untersuchung ist geplant aber noch nicht durchgeführt. Dieser Status wird über den @moodCode des observation'-Elements abgebildet, das auf "INT" (intent) gesetzt wird.

(Im Rahmen dieser Arbeit nicht realisiert.) 

<!-- Variante 2 mit statusCode -->
<tr>
    <th>Gewicht_vor_SS-Beginn(kg) </th>
    <td>Geplant</td>
</tr>
...
<observation classCode="OBS" moodCode="INT">
    <code code="PREWGT" codeSystem="2.16.840.1.113883.3.37.1.9.11.9.1" codeSystemName="ICW-GEN-OBSERVATION-CODE" displayName="Gewicht_vor_SS-Beginn(kg)"/>
</observation>

Observation Typ 2: Durchgeführt – ohne Ergebnis

Die Untersuchung wurde durchgeführt, hat aber kein Ergebnis.

Wenn eine Untersuchung durchgeführt wurde, aber aus irgendeinem Grund kein Ergebnis vorliegt, wird dies mit einem @nullFlavour=“NI“ festgehalten. 

<tbody>
    <tr>
        <th> Gewicht_vor_SS-Beginn(kg) </th>
        <td> Kein Befund</td>
    </tr>
</tbody>

<observation classCode="OBS" moodCode="EVN">
    <code code="PREWGT" codeSystem="2.16.840.1.113883.3.37.1.9.11.9.1" codeSystemName="ICW-GEN-OBSERVATION-CODE" displayName="Gewicht_vor_SS-Beginn(kg)>
    <statusCode code="completed"/>
    <value xsi:type="PQ" nullflavour="NI"/>
</observation>

Observation Typ 3: Durchgeführt – mit Ergebnis

Die Untersuchung wurde durchgeführt und hat ein Ergebnis. Alle durchgeführten Untersuchungen im Mutterpass, die einen Befund ergeben, lassen sich auf einen der folgenden Observation-Typen abbilden.

Observation_BL

Observations mit boolean-Werten sind der am häufigsten benutzte Typ im Mutterpass. Damit werden die Ja/Nein - Abfragen abgebildet. Dazu muss im code-Element der Code der Beobachtung eingegeben werden und im value-Element ein true oder false angegeben werden. Im unten stehenden Beispiel wird der Aufbau einer solchen observation aufgezeigt.

Aufbau des Textbereiches:

Der Textbereich der observation ist als Tabelle aufgebaut. Der Code der observation wird in der ersten Spalte der Tabelle als menschenlesbaren Text eingetragen. Im Normalfall entspricht der menschenlesbare Text dem Attribut @displayName aus dem code-Element des maschinenlesbaren Teils. In dem unten aufgeführten Beispiel bezieht sich die Untersuchung auf den HIV-Test. Hier wird aus datenschutzrechtlichen Gründen kein Ergebnis eingetragen, sondern nur festgehalten ob ein Test durchgeführt wurde. Der Befund wird als Ja bzw. Nein in der zweiten Spalte eingetragen, je nach dem was in dem maschinenlesbaren Teil steht. Dabei steht Ja für true und Nein für false.

Aufbau des maschinenlesbaren Teils:

Im @code-Attribut des code-Elementes wird der Code der Beobachtung eingegeben und im Attribut @value des value-Elementes wird ein true oder false angegeben. Im value-Element wird der @xsi:type auf BL gesetzt. 

<tbody>
    <tr>
        <th>Datum der Untersuchung:</th>
        <td>10.10.2006</td>
    </tr>
    <tr>
        <th> HIV-Serologie durchgeführt </th>
        <td>Ja</td>
    </tr>
</tbody>
...
<observation classCode="OBS" moodCode="EVN">
    <id extension="122178-2" root=" 2.16.840.1.113883.3.37.999.2.1.2.3 "/>
    <code code="HIVACC" codeSystem="2.16.840.1.113883.3.37.1.9.11.9.1" codeSystemName="ICW-GEN-OBSERVATION-CODE-DE" displayName="HIV-Serologien durchgeführt"/>
    <statusCode code="completed"/>
    <effectiveTime value="20061010"/>
    <value xsi:type="BL" value="true"/>
</observation>

Observation_BLQL

Observations mit boolean-Werten und Angabe der Seite, an der die Beobachtung zutrifft, werden mit einer observation vom Typ Observation_BLQL abgebildet

Aufbau des Textbereiches:

Der Textteil dieser observation ist als Tabelle aufgebaut. Die erste Spalte 

<th>Schielen (rechts)</th>

beinhaltet sowohl die observation als menschenlesbaren Text, als auch die Seitenlokalisation, soweit vorhanden. Die zweite Spalte beinhaltet den Befund als <td>Ja</td> bzw. <td>Nein</td>, abhängig von dem maschinenlesbaren Teil. Dabei steht Ja für true und Nein für false.

Beispiele für den Level 1-Eintrag bei der Seitenlokalisation
Spalte 1 Spalte 2
Hernie Ja/Nein
Hernie (rechts) Ja/Nein
Hernie (links) Ja/Nein
Hernie (beidseitig) Ja/Nein
Hernie (ohne nähere Angaben) Ja/Nein

Aufbau des maschinenlesbaren Teils:

Zusätzlich zum code- und value-Element wird ein qualifier-Element angegeben, in dem über die Elemente name und value die Seite abgebildet wird. Der unten stehende XML-Code gilt als Beispiel für alle Observations dieser Art. Die Auflistung für die möglichen Werte, die man als Seite angeben kann, sind in der Tabelle 8: Codetabelle für die Seitenlokalisation zu finden (siehe folgende Seite). 

<!--Menschen lesbarer Teil -->
<tr>
    <th>Hernie re/li</th>
    <td>Nein</td>
</tr>
...
<!--Maschinen lesbarer Teil -->
<observation classCode="OBS" moodCode="EVN">
    <code code="PE.3.HERNIA" codeSystem="2.16.840.1.113883.3.37.1.9.11.4" codeSystemName="ICW-GEN-OBSERVATION-CLINICAL-RESULTS" displayName="Hernie re/li"> </code>
    <statusCode code="completed"/>
    <value xsi:type="BL" value="false">
        <qualifier>
            <name code="8" codeSystem="2.16.840.1.113883.3.7.1"/>
            <value code="B" codeSystem="2.16.840.1.113883.3.7.1.7"/>
        </qualifier>
    </value>
</observation>

Seitenlokalisation

Für die Angabe der Seitenlokalisation, also links, rechts oder beidseitig etc. wird in Level 2 „links“, „rechts“, etc. oder die übliche abkürzende Schreibweise „L“, „R“, etc. benutzt. In Level 3 wird die Seitenlokalisation im qualifier unterhalb des value-Elementes wiedergegeben. Hierzu ist folgende Codetabelle zu verwenden.

Codetabelle für die Seitenlokalisation (OID: 2.16.840.1.113883.3.7.1.7)
Code Bedeutung Erläuterung
L links Seitenlokalisation links
R rechts Seitenlokalisation rechts
B beidseitig Beidseitiges Auftreten
U unbekannt Seitenlokalisation nicht bekannt 
<observation classCode="OBS" moodCode="EVN">
    ...
    <value xsi:type="CD" ...>
        <qualifier>
            <name code="8" codeSystem="2.16.840.1.113883.3.7.1"/>
            <value code="L" codeSystem="2.16.840.1.113883.3.7.1.7"/>
        </qualifier>
    </value>
</observation>

Observation_BLST

Eine observation vom Typ Observation_BLST wird dann benutzt, wenn zu einem Befund mit Ja oder Nein ein zusätzlicher Freitext eingetragen werden soll. Das kann z. B. dann von Interesse sein, wenn eine freitextliche Begründung zu dem Befund angegeben wird.

Aufbau des Textbereiches:

Der Textteil dieser Observations besteht aus zwei tr-Einträgen, also aus zwei Zeilen. Die erste Zeile beinhaltet den gleichen Aufbau wie es für Observations vom Typ Observation_BL der Fall ist. Die zweite Zeile beinhaltet in der ersten Spalte ebenfalls den Code der Untersuchung als menschenlesbaren Text mit dem Zusatz „Anmerkungen“. In der zweiten Spalte steht der Freitext als String der dem maschinenlesbaren Teil aus dem text-Element entspricht.

Aufbau des maschinenlesbaren Teils:

Im value-Tag wird der @xsi:type auf BL gesetzt. Zusätzlich zum code- und value-Element wird ein text-Element angegeben, in dem der Freitext als String steht. Der unten stehende XML-Code gilt als Beispiel für alle Observations dieser Art. 

<!--Menschen lesbarer Teil -->
<tr>
    <th>Frührere eigene schwere Erkrankungen</th>
    <td>Ja</td>
</tr>
<tr>
    <th>Frührere eigene schwere Erkrankungen. Anmerkungen:</th>
    <td>Eine frühere Erkrankung</td>
</tr>
...
<!--Maschinen lesbarer Teil -->
<observation classCode="OBS" moodCode="EVN">
    <code code="RCN-AR-00002" codeSystem="2.16.840.1.113883.3.37.1.9.11.36.1" codeSystemName="ICW-GEN-OBSERVATION-GRAV-ANAMNESIS-GEN-DE" displayName="Frühere eigene schwere Erkrankungen"> </code>
    <text>Eine frühere Erkrankung</text>
    <statusCode code="completed"/>
    <value xsi:type="BL" value="false"/>
</observation>

Observation_CD

In Observations mit CD-Werten werden Befunde über einen Code spezifiziert, die sich eindeutig zuordnen lassen. Das ist meistens der Fall, wenn das Befundergebnis eine abgeschlossene, abzählbare Menge ist. Das heißt, dass für das Ergebnis der observation nur bestimmte Werte in Frage kommen, die z. B. in einer Maske über eine Drop-Down-Liste ausgewählt werden können. Das Klassische Beispiel für eine solche observation ist die Blutgruppe.

Aufbau des Textbereiches:

Der Textteil dieser Observations ist als Tabelle aufgebaut. Die erste Spalte beinhaltet die observation als menschlich lesbarer Text und ist identisch mit dem @displayName des code-Elements. Die rechte Spalte beinhaltet das Ergebnis der observation als menschlich lesbarer Text, dass entspricht dem Inhalt des @displayName-Attributes innerhalb des value-Elements.

Aufbau des maschinenlesbaren Teils:

Dazu wird im Attribut @code des code-Elements der Code der Beobachtung eingetragen und im Attribut @code des <value>-Elements das Ergebnis der observation. Im value-Element wird der @xsi:type auf CD gesetzt. 

<!-- Menschen lesbarer Teil -->
<tr>
    <th>Blutgruppe</th>
    <td>A</td>
</tr>
...
<!-- Maschinen lesbarer Teil -->
<observation classCode="OBS" moodCode="EVN">
    <!-- Blutgruppe -->
    <code code="BLDTYP" codeSystem="2.16.840.1.113883.3.37.1.9.11.9.1" codeSystemName="ICW-GEN-OBSERVATION-CODE-DE" displayName="Blutgruppe"> </code>
    <statusCode code="completed"/>
    <value xsi:type="CD" code="A" codeSystem="2.16.840.1.113883.3.37.1.9.11.16.1" codeSystemName="BLOOD_TYPE" displayName="Blutgruppe"> </value>
</observation>

Observation_CDQL

Eine Untersuchung vom Typ Observation_CDQL dient dazu, Diagnosen innerhalb des Mutterpasses festzuhalten. Es handelt sich dabei um eine Untersuchung vom Typ CD und einem zusätzlichen Qualifier (QL), um die Zuverlässigkeit der Diagnose anzugeben.

Aufbau des Textbereiches:

Der Textteil dieser Observations ist als Tabelle aufgebaut. Die erste Spalte beinhaltet die Information, wie sicher die Diagnose ist. Als Angaben der Sicherheit/Verlässlichkeit der Diagnose aus dem KVBereich ist hier der Text anzugeben: „Gesichert“, „Verdacht auf“, „Zustand nach“, „Ausschluss von“. Die Angabe zur Sicherheit ist im Rahmen der Abrechnung mit den gesetzlichen Krankenkassen eine Pflichtangabe, bei Rechnungen für Privatversicherte ist die Angabe von „Gesichert" nicht möglich. Die rechte Spalte beinhaltet die Art der Diagnose und das Codesystem aus dem der Schlüssel für die Diagnose stammt. Das entspricht dem Inhalt des @code-Attributes und dem @codeSystemName-Attributes, beide innerhalb des value-Elements.

Aufbau des maschinenlesbaren Teils:

Dazu wird im Attribut @code des code-Elements der Code-Schlüssel für die Beobachtung eingetragen und im Attribut @codeSystem und @codeSystemName das entsprechende CodeSystem aus dem der Schlüssel stammt.

Zum value-Element des Codes kommt hier ein zusätzliches qualifier-Element, dass die Sicherheit der Diagnose angibt.

Vocabulary Domain für die Verlässlichkeit von Diagnosen (OID:2.16.840.1.113883.3.7.1.8)
Code Bedeutung Erläuterung
G Gesichert Gesicherte Diagnose
V Verdacht auf Verdachtsdiagnose
Z Zustand nach Zustand nach
A Ausgeschlossene Erkrankung Ausgeschlossene Erkrankung 
| code =
<!-- Menschen lesbarer Teil -->
<tr>
    <th>Gesicherte Diagnosen</th>
    <td> F.42 (ICD10)</td>
</tr>
...
<!-- Maschinen lesbarer Teil -->
<observation classCode="OBS" moodCode="EVN">
    <code code="DISDX" codeSystem="2.16.840.1.113883.3.7.1.50" codeSystemName="ActCode" displayName="Entlassdiagnose"> </code>
    <statusCode code="completed"/>
    <value xsi:type="CD" code="F.42" codeSystem="1.2.276.0.76.5.311" codeSystemName="ICD10">
        <qualifier>
            <name code="8" codeSystem="2.16.840.1.113883.3.7.1"/>
            <value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/>
        </qualifier>
    </value>
</observation>

<!-- Menschen lesbarer Teil -->
<tr>
    <th>Verdachtsdiagnose</th>
    <td>F.42 (ICD10)</td>
</tr>
...
<!-- Maschinen lesbarer Teil -->
<observation classCode="OBS" moodCode="EVN">
    <code code="DISDX" codeSystem="2.16.840.1.113883.3.7.1.50" codeSystemName="ActCode"> </code>
    <statusCode code="completed"/>
    <value xsi:type="CD" code="F.42" codeSystem="1.2.276.0.76.5.311" codeSystemName="ICD10">
        <qualifier>
            <name code="8" codeSystem="2.16.840.1.113883.3.7.1"/>
            <value code="V" codeSystem="2.16.840.1.113883.3.7.1.8"/>
        </qualifier>
    </value>
</observation>

Observation_INT

Mit diesem Typ werden alle Untersuchungen ausgedrückt, die einen quantitativen Zahlenwert speichern und keine Aussage zur Maßeinheit machen. Ein typischer Anwendungsfall für eine solche Untersuchung ist die Bestimmung der Schwangerschaftsanzahl.

Aufbau des Textbereiches:

Der Textbereich der observation ist als Tabelle aufgebaut. Der Code der observation wird in der ersten Spalte der Tabelle als menschenlesbarer Text eingetragen. Im Normalfall entspricht der menschenlesbare Text dem Attribut @displayName aus dem code-Element des maschinenlesbaren Teils. In der zweiten Spalte steht die gespeicherte Zahl der Untersuchung, welcher dem Inhalt des @value-Attributes unterhalb des value-Elementes entspricht.

Aufbau des maschinenlesbaren Teils:

Im @code-Attribut des code-Elementes wird der Code der Beobachtung eingegeben und im Attribut @value des value-Elementes wird der Zahlenwert eingetragen. Im value-Element wird der @xsi:type auf INT gesetzt. 

<!-- Menschen lesbarer Teil -->
<tr>
    <th>Anzahl Schwangerschaften (mit dieser)</th>
    <td>1</td>
</tr>
...
<!-- Maschinen lesbarer Teil-->
<observation classCode="OBS" moodCode="EVN">
    <code code="PRGCNT" codeSystem="2.16.840.1.113883.3.37.1.9.11.5" codeSystemName="ICW-GEN-OBSERVATION-BIRTH-HIST" displayName="Anzahl Schwangerschaften (mit dieser)"/>
    <statusCode code="completed"/>
    <value xsi:type="INT" value="1"/>
</observation>

Observation_PQ

In Observations mit PQ-Werten werden quantifizierte Daten wie Gewicht oder Größe festgehalten. Der Unterschied zu Observations vom Typ INT besteht in der zwingend vorgeschrieben Angabe der Maßeinheit.

Aufbau des Textbereiches:

Der Textteil dieser Observations ist als Tabelle aufgebaut. Die erste Spalte beinhaltet die observation als menschlich lesbaren Text. Die rechte Spalte beinhaltet das Ergebnis der observation als menschlich lesbaren Text, dass entspricht dem zusammengesetzten Inhalt des @value-Attribut und dem @unit-Attribut unterhalb des value-Elements.

Aufbau des maschinenlesbaren Teils:

In Observations mit PQ-Werten werden quantifizierte Daten wie Gewicht oder Größe festgehalten. Dazu wird im code-Element der Code der Beobachtung eingegeben. Der eigentliche Messwert steht innerhalb des value-Elements, während die Einheit in dem Attribut @unit codiert wird. Die Abkürzungen für die Einheit sind der UCUM-Tabelle[3] zu entnehmen. 

<!-- Menschen lesbarer Teil -->
<tr>
    <th>Körpergewicht</th>
    <td>6000 g</td>
</tr>
...
<nowiki><!-- Maschinen lesbarer Teil --></nowiki>
<observation classCode="OBS" moodCode="EVN">
    <code code="3137-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Körpergewicht"/>
    <statusCode code="completed"/>
    <value xsi:type="PQ" value="6000" unit="g"/>
</observation>

Das Attribut @unit ist zwingend vorgeschrieben. Einzige Ausnahme ist, wenn der Messwert nicht angegeben werden kann. Für den Fall, das der Messwert nicht angegeben werden kann, muss das Attribut @nullFlavour im Element value existieren. 

<observation classCode="OBS" moodCode="EVN">
    <code code="3137-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName=" Körpergewicht "/>
    <statusCode code="completed"/>
    <value xsi:type="PQ" nullFlavour="ASKU"/>
</observation>

Observation_ST

Diese Observations erlauben dem Nutzer maximale Freiheit, was seine Eingabemöglichkeiten angeht. Der Nachteil ist aber, dass es hier keinerlei automatisierte Kontrollmöglichkeiten gibt.

Das Klassische Beispiel für eine solche observation ist ein Kommentar oder eine Bemerkung.

Aufbau des Textbereiches:

Der Textteil dieser Observations ist als Tabelle aufgebaut. Die erste Spalte beinhaltet die observation als menschlich lesbaren Text. Die rechte Spalte beinhaltet den Freitext, dieser entspricht dem Text innerhalb des value-Elements.

Aufbau des maschinenlesbaren Teils:

Im code-Tag wird der Code der observation angegeben und im value-Element wird der @xsi:type auf ST gesetzt. Der Text der observation steht innerhalb des value-Elements und nicht etwa im Attribut @value, wie das bei den anderen Observation-Typen der Fall ist. 

<!-- Menschen lesbarer Teil -->
<tr>
    <th>Bemerkung</th>
    <td>Text zur Bemerkung</td>
</tr>
...
<!-- Maschinen lesbarer Teil -->
<observation classCode="OBS" moodCode="EVN">
    <code code="REMARK" codeSystem="2.16.840.1.113883.3.37.1.9.11.9.1" codeSystemName="ICW-GEN-OBSERVATION-CODE-DE" displayName="Bemerkung"/>
    <statusCode code="completed"/>
    <value xsi:type="ST">Text zur Bemerkung</value>
</observation>

Observation_TS

Observations vom Typ Observation_TS bilden Datums- und Zeitangaben ab. Dieser Typ wird benutzt, wenn die Zeitangabe das eigentliche Ziel der Untersuchung ist. Der Unterschied zum Encounter besteht darin, das hier nicht der Patientenkontakt im Vordergrund steht, sondern die Zeitangabe zu einer durchgeführten Untersuchung.

Aufbau des Textbereiches:

Der Textteil dieser Observations ist als Tabelle aufgebaut. Die erste Spalte beinhaltet die observation als menschlich lesbaren Text, das entspricht dem @displayName unterhalb des code-Elements. Die rechte Spalte beinhaltet die Zeitangabe des @value-Attributes aus value in einem konvertierten Format zur besseren Lesbarkeit.

Aufbau des maschinenlesbaren Teils:

Dazu wird im code-Element der Code der observation angegeben um im @value-Attribut des value-Elements das Datum. Im unteren Beispiel wird die verpflichtende Form aufgezeigt. Im value-Element wird der @xsi:type auf TS gesetzt. 

<observation></nowiki> mit <nowiki><value></nowiki> vom Typ „Observation_TS“">
<!-- Menschen lesbarer Teil -->
<tr>
    <th>letzte Periode</th>
    <td>07/06/2006</td>
</tr>
...
<nowiki><!-- Maschinen lesbarer Teil --></nowiki>
<observation classCode="OBS" moodCode="EVN">
    <code code="LSTPER" codeSystem="2.16.840.1.113883.3.37.1.9.11.9.1" codeSystemName="ICW-GEN-OBSERVATION-CODE-DE" displayName="letzte Periode"> </code>
    <statusCode code="completed"/>
    <value xsi:type="TS" value="20060607"/>
</observation>

Observation_RTO

Mit Observation_RTO werden vor allem Untersuchungen angegeben, die ein Verhältnis angeben. Ein typisches Beispiel im Mutterpass sind Titerangaben. Titer ist ein Begriff aus der Labormedizin und gibt die Konzentration eines Antikörpers oder eines Virus an. Die Konzentration wird immer durch ein Verhältnis „1:“ angegeben, deshalb ist die Titerangabe vom Typ Ratio (RTO).

Aufbau des Textbereiches:

Der Textteil dieser Observations ist als Tabelle aufgebaut. Die erste Spalte beinhaltet die observation als menschlich lesbaren Text, dass entspricht dem @displayName unterhalb des code-Elements. Die rechte Spalte beinhaltet den zusammengesetzten Inhalt des @value-Attributes aus den Elementen numerator und denominator unterhalb von value, durch einen Doppelpunkt getrennt.

Aufbau des maschinenlesbaren Teils:

Dazu wird im code-Element der Code der observation angegeben. Unterhalb des value-Elements befinden sich zwei weitere Elemente numerator und denominator, welche jeweils im @value-Attribut eine Zahl beinhalten. Im unteren Beispiel wird die verpflichtende Form aufgezeigt. Im value-Element wird der @xsi:type auf RTO gesetzt. 

 mit Titerangabe vom Typ „Observation_RTO”">
<tr>
    <th> AK-Suchtest.Titer </th>
    <td>1:5</td>
</tr>

<observation classCode="OBS" moodCode="EVN">
    <code code="TITER" codeSystem="ICW-OID" codeSystemName="ICW" displayName="AK-Suchtest.Titer"> </code>
    <statusCode code="completed"/>
    <value xsi:type="RTO">
        <numerator xsi:type="INT" value="1"/>
        <denominator xsi:type="INT" value="5"/>
    </value>
</observation>

Mapping-Tabelle

Die Mapping-Tabelle beschreibt den kompletten Aufbau des CDA-Dokumentes für den Mutterpass. Dabei werden nur die maschinell auswertbaren Informationen berücksichtigt. Der menschlich lesbare Teil steht immer im Textteil der jeweiligen section. Da es für den Aufbau des Textteils keine Richtlinien von CDA gibt, wird dieser Teil in der Mapping-Tabelle nicht behandelt. Der Textteil kann von jeder Instanz, die ein solches CDA-Dokument entwirft, fast nach Belieben erstellt werden. Innerhalb der Arbeit werden verschiedene Richtlinien vorgegeben, wie ein solcher Textteil auszusehen hat. Es ist aber keine zwingende Vorgabe.

Der Maschinen lesbare Teil richtet sich stark nach der originalen Papiervorlage des Mutterpasses. Im Folgenden ist eine Seite dieses Mutterpasses dargestellt und sowie der entsprechende Auszug der Mapping –Tabelle, der die Speicherung der Information exemplarisch an „Blutgruppenzugehörigkeit“ erklärt. Wie aus der ersten Spalte in der Abbildung zu entnehmen ist, wird die Blutgruppenzugehörigkeit als eigener Organizer abgebildet. Die nächste Spalte „Section 1“ gibt die Sektionen an in die der Mutterpass auf erster Hierarchiestufe unterteilt ist. Wenn diese Sektion weiter unterteilt ist, gibt es einen weiteren Eintrag unter der Spalte „Section 2“. Um jetzt zu idendifizieren unter welcher Sektion die Blutgruppenzugehörigkeit gespeichert wird, liest man die Mapping-Tabelle von der geplanten Untersuchung bottom-up, bis man zum ersten Treffer in einer der Section-Spalten kommt. Der Organizer „Blutgruppenzugehörigkeit“ gehört somit zu Sektion „Serologische Untersuchungen“. Die Observations „Blutgruppe“, „Rhesus-Faktor“, „Rhesus-Formel“ und „Kell-System“ gehören innerhalb des Organizers zu den „Serologischen Untersuchungen“.

Falls die Spalte „entryRelation .OBS bzw. entryRelation .ENC“ gefüllt ist, bedeutet das, dass diese Untersuchung zu einer übergeordneten Observation gehört (bottom-up) und als entryRelation zu speichern ist.

Die Spalte „Feldbezeichnung“ gibt an, welche Werte die Observation zulässt.

Die Spalte „Feldinhalt“ beschreibt in der Regel einen der oben beschriebenen Observation-Typen.

Die Spalte „Baustein(XML)“ gibt den genauen XML-Code an, der für die jeweilige Information in das Mutterpass-Dokument eingefügt werden muss.

Die Spalte „CODE bzw Extension bzw Value“ gibt den Code der entsprechenden Observation an bzw die den codierten Inhalt einer Observation, der auch aus der Datei „Mutterpass_Codetabelle_V1.0.xls“ zu entnehmen ist.

Die Spalte „codeSystem“ definiert das Codesystem aus dem der Code stammt (Anmerkung: Der Mutterpass wurde in verschiedene Codesysteme unterteilt aus praktischen Gründen wäre es vielleicht sinnvoll nur ein Codesystem für alle Codes innerhalb des Mutterpasses zu definieren).

Auszug aus der beigefügten Mapping-Tabelle

Vergabe der Instance Identifier in einem CDA-Dokument am Beispiel der ICW

Innerhalb eines CDA-Dokumentes existiert eine eindeutige Nummer für den Patienten, das Dokument, die providerOrganisation, die representedOrganisation beim Autor, den custodian, und den author. Diese IDs sind vom Typ Instance Identifier (II). Der Instance Identifier setzt sich aus zwei Attributen zusammen @root und @extension.

Root-Attribut

Sowohl das Dokument als auch der Patient müssen innerhalb eines installierten Systems eindeutig sein. Aus diesem Grund muss eine OID für jedes installierte System vergeben werden. Diese Installations-OID bildet das @root-Attribut.

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.276.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".[4]

Die Installations-OID wird ausgehend von der Wurzel-OID (2.16.840.1.113883.3.37.6.2) für die ICW vergeben. An die Wurzel-OID wird eine eindeutige Nummer für jede Software-Installation gesetzt. Diese eindeutige Nummer wird aus einem 49 Ziffern langen Code zusammengesetzt und an die Wurzel-OID angehangen. Bei den 49 Ziffern handelt es sich um eine Global Unique Identifier (GUID), die pro Organisation erstellt wird, da auch mehrere Organisationen pro Installation möglich sind.

Damit man unterscheiden kann, um was für ein Objekt es sich handelt, z. B. Dokument oder Patient, wird eine Objektnummer an die so zusammengesetzte Zahl angefügt.

Objektnummern im Mutterpass
Objektnummer Objekt
1 Dokument
2 Dokument_Set
3 Patient
4 Autor
20 Labor

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. Damit man den Objekttypen unterscheiden kann, besitzt das @root-Attribut die Objektnummer (siehe oben, @root-Attribut). Andernfalls könnte es sein, dass ein Dokument zufällig die gleiche @extension wie ein Patient erhält und man diese Unterscheidung nicht machen kann. 

<id root= [ROOT-OID]. [GUID].[Objekt_Nummer] extension= z. B. Dokumenten_Nummer/>

Header-IDs

clinicalDocument.id

Durch die id wird ein Dokument eindeutig identifiziert.

Das @extension-Attribut der id kann eine fortlaufende Nummer sein, die pro Installations-OID eindeutig ist. Diese fortlaufende Nummer muss persistent sein und darf nicht erneut vergeben werden. Momentan wird die id des Dokumentes aus der Datenbank ausgelesen. Es existiert jedoch folgender Sonderfall: replace (siehe Kapitel „3.4 Replace beim Mutterpass“). 

<id root= ROOT-OID. [49 Ziffern] .1 extension= Dokumenten_Nummer/>

clinicalDocument.setId

Durch die setId wird ein Set an Dokumenten eindeutig identifiziert.

Ein Set ist z. B. ein Mutterpass, der einmal gespeichert, nochmals geöffnet und editiert wird. In diesem Fall erhalten die beiden Dokumente jeweils eine eindeutige id, haben aber dieselbe setId. 

<setId root= ROOT-OID. [49 Ziffern] .2 extension= Nummer für ein Set an Mutterpassdokumenten />

Patient

patientRole.id

Die Patient_Nummer ist die ID, die P4M einem Patienten intern zugewiesen hat. 

<id root= ROOT-OID. [49 Ziffern].3 extension= Patient_Nummer/>

providerOrganisation.id

<id root= ROOT-OID extension= [49 Ziffern] />

Autor

assignedAuthor.id

<id root= ROOT-OID. [49 Ziffern].4 extension= Author_Nummer(Arzt)/>

representedOrganisation.id

<id root= ROOT-OID extension= [49 Ziffern] />

assignedCustodian.id

<id root= ROOT-OID extension= [49 Ziffern] />

Body-IDs

Labor

Nach Möglichkeit sollte jedes Labor, aus dem z. B. die serologischen Befunde kommen, über eine eigene OID verfügen. Im Idealfall wäre die id des Labors also wie folgt zu füllen.

@root = OID des Labors

@extension = Protokollnummer des Labors

Wenn die Labore noch keine OID haben oder die OID des Labors unbekannt ist, wird die id wie folgt gefüllt. Das gilt nur, falls eine Protokollnummer eingegeben wird. Sonst muss bei der id ein @nullFlavour gesetzt werden.

@root = ROOT-OID + 49 Ziffern + „.20“

@extension = Protokollnummer des Labors 

<id root= ROOT-OID. [49 Ziffern] .20  extension="123-345.5" />

Autor

Bei manchen Untersuchungen sind individuelle Unterschriften durch den Arzt möglich. Die Untersuchung wird in diesem Fall um einen Autor erweitert. Der Autor entspricht dem Verantwortlichen für die jeweilige Untersuchung. Wenn ein Autor für die jeweilige Untersuchung angelegt wird, muss eine id unterhalb von author gespeichert werden, die im System eindeutig ist. Diese id ist nicht optional. Somit ist es nicht möglich einen Autor nur mit Namen anzulegen. Bei fehlender Angabe des Arztes entfällt der komplette Block author.

Performer

Im performer wird die Klinik der Behandlung festgehalten. Wenn man keine eindeutige Identifikationsnummer der Klinik zur Verfügung hat, wird bei der id ein @nullFlavour gesetzt. Bei performer ist die id verpflichtend und es kann nicht nur der Organisationsname angegeben werden 

<id nullFlavor="UNK"/>

ObservationMedia.ID

Das Attribut @ID innerhalb von observationMedia bleibt über alle Dokumente unverändert, da es innerhalb des einzelnen Dokumentes eine ganz bestimmte Grafik kennzeichnet, auf die referenziert wird.

Das Element id unterhalb von observationMediabekommt die vollständige id des momentanen Dokuments, da dieser Grafik-Knoten genau diesem CDA zugeordnet ist.

  1. ↑ http://www.dimdi.de/static/de/klassi/prozeduren/ops301
  2. ↑ http://aurora.regenstrief.org/~schadow/units/UCUM/ucum.html
  3. ↑ http://www.hl7.de/download/documents/ucum/ucum.html
  4. ↑ Vergleiche.: VHitG Implementierungsleitfaden Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2, S. 44.
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaemp:ImplementierungCDA&oldid=2497“