Digitaler Mutterpass auf der Basis von CDA R2

__NOTITLE__ Elektronischer Mutterpass/Documentinfo Dieses Dokument gibt den Implementierungsleitfaden "Digitaler Mutterpass für das Deutsche Gesundheitswesen auf der Basis von CDA R2" wieder.

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

Einleitung

Motivation und Ziel

Seit der Einführung des Mutterpasses in Papierform im Jahr 1968 werden Vorsorgeuntersuchungen für Schwangere dokumentiert, um Probleme während der Schwangerschaft frühzeitig zu erkennen und ihnen entgegen zu wirken. Im Rahmen der gesetzlich vorgeschriebenen Vorsorgeuntersuchungen werden relevante Daten, wie z. B. Erb- und Immunschwächekrankheiten der Mutter, Informationen über den Zustand des Kindes wie z. B. Lage, Gewicht und Größe, im Mutterpass erfasst. Somit ist der Mutterpass einer der ersten Maßnahmen der Präventivmedizin.

Trotzdem beinhaltet der Mutterpass in seiner bisherigen Papierform einige Schwachpunkte. So muss er z. B. bei Verlust beim Frauenarzt neu ausgestellt werden und alle Daten, die von den Frauenärzten bis dahin festgestellt und dokumentiert wurden, erneut eingetragen werden. Außerdem muss der Mutterpass von der Mutter ständig mitgeführt werden, um im Notfall auf die Daten zugreifen zu können. Obwohl der Mutterpass mehrmals überarbeitet wurde, fehlen immer noch einige medizinische Inhalte, die mittlerweile zum Standard einer Vorsorgeuntersuchung gehören, wie z. B. die HIV-Serologie oder der Toxoplasmose-Nachweis.

Mit der Umstellung des Mutterpasses auf eine digitale Lösung könnte der Arzt bei einem Verlust alle bisher erfassten Daten neu abspeichern. Ein Austauschen der Daten über Institutionsgrenzen wäre auch möglich. Da spätestens mit Einführung der elektronischen Gesundheitskarte die Interoperabilität von Hard- und Software im Gesundheitswesen eine immer größere Rolle spielt, könnte der elektronische Mutterpass neben dem elektronischen Rezept ein wichtiger Schritt in diese Richtung sein.

Durch die elektronische Gesundheitskarte wird die Basis für eine Infrastruktur geschaffen, die mittelfristig eine lückenlose intersektorale Kommunikation u. a. zwischen Ärzten untereinander sowie Ärzten, Kliniken und Apotheken ermöglichen soll.

Da sich der Mutterpass über einen so langen Zeitraum etabliert und bewährt hat, ist es notwendig, entsprechend sensibel an eine solche Veränderung heranzugehen. Die im Rahmen dieser Arbeit erarbeitete digitale Speicherung des Mutterpasses soll den Mutterpass in bisheriger Form nicht ersetzen, sondern kurzfristig parallel eingesetzt werden, um die Schwächen des Mutterpasses in Papierform auszugleichen. Dadurch ergibt sich auch mittel- und langfristig die Möglichkeit, den Mutterpass auf eine komplett digitale Lösung umzustellen, wenn sich herausstellt, dass die Vorteile dieser Form überwiegen. In enger Zusammenarbeit mit Ärzten werden die bisherigen Informationen, die im Mutterpass gespeichert wurden, um zusätzliche erweitert, welche in die Mutterschaftsrichtlinien aufgenommen wurden. Dazu zählen z. B. Untersuchungen auf Toxoplasmose und Diabetes.

In der Schweiz hat man die Vorteile einer digitalen Lösung gegenüber der Papierform schon länger erkannt. Hier gibt es seit Herbst des vergangenen Jahres ein Pilotprojekt, welches die Daten des Mutterpasses in Form einer PDF-Datei auf einem USB-Stick speichert. Das hat den Vorteil, dass die Daten in einer wesentlich kleineren Form, als dem ursprünglichen Papierformat, gespeichert werden können und bei einem Verlust des USB-Sticks die Daten schnell wieder vom betreffenden Arzt generiert werden können. Das PDF-Format bietet allerdings nicht die Möglichkeit, die Daten maschinell auswerten zu können.

Ziel der vorliegenden Arbeit ist daher die Erarbeitung eines Konzeptes zur digitalen Speicherung der Informationen in strukturierter maschinenlesbarer Form, wie sie bisher im Mutterpass vorliegen. Dabei ist die Form, wie diese Daten gespeichert werden, von essentieller Bedeutung, da sie für verschiedene Anwendungen zur Verfügung stehen müssen. Die Daten müssen sowohl für die Visualisierung, als auch für die maschinelle Auswertung geeignet sein. Das Hauptziel dieser Arbeit besteht somit in der Evaluierung der gegeben Infrastruktur im deutschen Gesundheitswesen und den damit verbundenen Schwierigkeiten, Daten über die Institutionsgrenzen hinweg auszutauschen. Außerdem sollen Daten, die im Laufe einer Schwangerschaftsuntersuchung erfasst wurden, späteren Anwendungen zur Verfügung stehen, um so Doppeluntersuchungen zu minimieren. Dazu muss ein geeignetes Format gewählt werden, um den Kontext der gespeicherten Daten nicht zu verlieren und global so eindeutig zu halten, dass weitere Anwendungen im Gesundheitswesen die Syntax und Semantik der Informationen interpretieren können.

Mutterpass

Einen Mutterpass erhält eine werdende Mutter in Deutschland ab offizieller Feststellung der Schwangerschaft durch den zuständigen Frauenarzt. 1968 wurde das Dokument in Deutschland eingeführt und seitdem mehrmals verändert, zuletzt 2004. Der Mutterpass enthält alle im Verlauf der Schwangerschaft und Geburt kontrollierten Daten und Befunde, einschließlich der Untersuchungsbefunde des Neugeborenen und der Wochenbett-Kontrollbefunde der Mutter. Daten über die werdende Mutter, wie Blutgruppe, Gewicht etc., Art und Anzahl der Untersuchungen, sind von der Vereinigung der Krankenkassen in den Mutterschaftsrichtlinien genau vorgeschrieben. Einige dieser Untersuchungen können bei einer Hebamme durchgeführt werden.

Die Untersuchungsrichtlinien sehen vor, dass eine Mutter bis zur 32. Schwangerschaftswoche Untersuchungen im Abstand von vier Wochen und danach im Rhythmus von zwei Wochen durchführt. Bis zu zwei Schwangerschaften können in einem solchen Mutterpass festgehalten werden.

Der Mutterpass dient sowohl einer kontinuierlichen Dokumentation, als auch einer Notfalldokumentation, um im Falle einer auftauchenden Komplikation schnell reagieren zu können. Aus diesem Grund sollte der Mutterpass ständig von der Schwangeren mitgeführt und auch bei der Entbindung mitgebracht werden. Er kann in folgende Kategorien unterteilt werden:

• Serologische Untersuchungen
• Vorangegangene Schwangerschaften
• Angaben zur Schwangeren und Anamnese (Krankheitsgeschichte)
• Terminbestimmung
• Gravidogramm
• Cardiotokographische Befunde
• Ultraschalluntersuchungen
• Abschlussuntersuchung (Epikrise)

Ziel der vorliegenden Arbeit ist es, den aktuellen Mutterpass, welcher momentan in Papierform vorliegt, in einen XML-basierten Standard zu überführen. Dieser XML-basierte Standard soll mit der Clinical Document Architecture (CDA) kompatibel sein, die ein Bestandteil des HL7-Standards ist, welcher schon jetzt in der Datenübertragung genutzt wird.

Bei der InterComponentWare AG (ICW AG) mit Sitz in Walldorf und Köln hat man die Vorteile einer digitalen Lösung des Mutterpasses erkannt. Die InterComponentWare AG entwickelt internationale Telematik-Lösungen für den medizinischen Sektor. In Zusammenarbeit mit dem medizinischen Kompetenzteam der ICW AG, dass Vorgaben zu bestimmten medizinischen Parametrisierungen erarbeitet hat, wurde an einer digitalen Lösung auf Basis von CDA Release 2 gearbeitet. Die Ergebnisse sind in der Masterarbeit von Daniel Hellmuth "Entwicklung eines digitalen Mutterpasses für das Deutsche Gesundheitswesen" festgehalten und hier zu einem Implementierungsleitfaden umgeschrieben.

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

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

Schematischer Aufbau eines CDA-Dokumentes

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

Header

Body

Sections

Entries

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

CDA- Wurzelement

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

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

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

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

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

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

typeId

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

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

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

CDA-Header

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

Inhalt des CDA-Headers im Überblick:

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

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

ClinicalDocument.id

	<	Element	DT	Card	Conf	Beschreibung
		id	II	1..1	M	Id des Dokuments

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:

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

ClinicalDocument.code

	<	Element	DT	Card	Conf	Beschreibung
		code	CE	1..1	M	Andeutung der Art des Dokuments

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:

<code code="57059-8" codeSystem="2.16.840.1.113883.6.1"/>

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

ClinicalDocument.title

	<	Element	DT	Card	Conf	Beschreibung
		title	ST	0..1	O	Titel des Dokuments

In diesem Tag wird der Titel des Dokumentes dargestellt. In diesem Falle wird konstant "Mutterpass" verwendet.

ClinicalDocument.effectiveTime

	<	Element	DT	Card	Conf	Beschreibung
		effectiveTime	TS	1..1	M	Erstellungsdatum/zeitpunkt des Dokuments

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

	<	Element	DT	Card	Conf	Beschreibung
		confidentialityCode	CE	1..1	M	Vertraulichkeitsgrad des Dokuments

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.

Mögliche Vertraulichkeitsangaben in einem CDA-Dokument

Value Set Name Value Set Id Effective date BasicConfidentialityKind 2.16.840.1.113883.1.11.16926 2010-04-21 Source Code System: 2.16.840.1.113883.5.25 (Confidentiality) Level/ Type Code Codesystem Kurzbezeichnung Beschreibung 0-L N Confidentiality normal Normale Vertraulichkeitsregeln sind anzuwenden. Nur autorisiertes Personal im Bereich Medizin, darf auf die Daten zugreifen. 0-L R Confidentiality restricted Eingeschränkter Zugriff, nur Personal in einer zeitnahen medizinischen Dienstleistungsfunktion darf auf die Daten zugreifen. 0-L V Confidentiality very restricted Stark eingeschränkter Zugriff, Zugriffsregeln gibt der „Privacy Officer" des Daten-Anbieters vor.

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

ClinicalDocument.languageCode

	<	Element	DT	Card	Conf	Beschreibung
		languageCode	CS	0..1	O	Sprache der menschenlesbaren Texte des Dokuments

In diesem Tag wird die Sprache der menschenlesbaren Texte angegeben. Die Werte des @code-Attributes sind Sprachenbezeichner, die durch IETF (Internet Engineering Task Force) RFC 3066 für die Kennzeichnung von Sprachen definiert sind. Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben). 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.

<languageCode code="de-DE"/>

Header Beteiligte Personen

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

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

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

Optionale Teilnehmer

Unterzeichner

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

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

• unauthenticated
• authenticated
• legally 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: [0..n]

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

Ein authenticator hat drei erforderliche Unterelemente

• time
• signatureCode
• assignedEntity.

authenticator.time

Datentyp: CE

Kardinalität: [1..1]

Gibt den Zeitpunkt der Authentisierung an.

authenticator.signatureCode

Datentyp: CS

Kardinalität: [1..1]

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

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

Signierung in einem CDA-Dokument

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

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

authenticator.assignedEntity

Kardinalität: [1..1]

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

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

legalAuthenticator

Kardinalität: [0..1]

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

• time
• signatureCode
• assignedEntity

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

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

dataEnterer

Kardinalität: [0..1]

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

dataEnterer.assignedEntity

Kardinalität: [1..n]

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

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

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

Dies stellt den Zeitpunkt oder den Zeitraum der Behandlung dar.

informant

Kardinalität: [0..n]

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

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

• relatedEntity
• assignedEntity

informant.relatedEntity

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

informant.assignedEntity

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

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

informationRecipient

Kardinalität: [0..1]

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

Empfänger eines CDA-Dokumentes

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

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

informationRecipient.intendedRecipient

Kardinalität: [1..1]

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

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

participant

Kardinalität: [0..n]

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

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

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

participant.associatedEntity

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

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

Pflichtteilnehmer

author

Kardinalität: [1..n]

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

Das Element author, besitzt zwei Attribute

• @typeCode
• @contextControlCode

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

author.time

Datentyp: TS

Kardinalität: [1..1]

Gibt den Zeitpunkt der Datenerfassung durch eine Person an.

author.assignedAuthor

Kardinalität: [1..1]

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

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

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

Author.assignedAuthor.id

Datentyp: II

Kardinalität: [1..n]

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

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

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

custodian

Kardinalität: [1..1]

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

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

custodian.assignedCustodian.representedCustodianOrganisation.id

Datentyp: II

Kardinalität: [1..n]

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

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

recordTarget

Kardinalität: [1..n]

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

recordTarget.patientRole.id

Datentyp: II

Kardinalität: [1..n]

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

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

recordTarget.patientRole.patient

Kardinalität: [0..1]

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

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

CDA-Body

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

Level 1

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

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

<br> für einen Zeilenumbruch

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

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

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

<paragraph> zur logischen Trennung von zusammengehörigen Textabschnitten

<table> zur Darstellung einer Tabelle

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

Level 2

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

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

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

Level 3

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

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

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

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

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

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

EntryActs

Act

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

Encounter

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

Observation

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

ObservationMedia

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

Organizer

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

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

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

Procedure

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

RegionOfInterest

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

SubstanceAdministration

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

Supply

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

Referenzieren mit URIs

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

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

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

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

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

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

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

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

Code-Systeme

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

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

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

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

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

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

Für die Speicherung von Messwerten wird in CDA Release 2 der Datentyp PQ (Physical Quantity) benutzt [HL7M]. Die OID für das Kodierungssystem UCUM ist 2.16.840.1.113883.6.8.

Nur wenige Codes, die im Mutterpass eingesetzt werden, existieren bereits in einem der vorgestellten Code-Systeme. Aus diesem Grund musste ein eigenes Code-System erstellt werden, welches sich im Anhang dieser Arbeit befindet. Die Codes wurden anschließend mit der Codegenehmigungsstelle der ICW AG abgestimmt, zugelassen und eine OID Struktur unterhalb der ICW OID angelegt. Hierdurch steht es auch weiteren Anwendungen der ICW zur Verfügung. Später sollen die Codes in ein offizielles Code-System aufgenommen werden und so auch der Öffentlichkeit zur Verfügung stehen.

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

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.

<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 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 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>
...
<!-- Maschinen lesbarer Teil -->
<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.

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

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.

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

Anhang

Die Arbeit bildet einen ersten Grundstein für die Realisierung eines digitalen Mutterpasses im deutschen Gesundheitswesen. Damit ist die automatische Auswertung von erhobenen Befunden und Untersuchungen möglich. Ferner können Untersuchungen, die im Rahmen des Mutterpasses durchgeführt werden, für Vorsorgeuntersuchungen anderer Anwendungsfälle übernommen werden.

Ein konkretes Beispiel sind die neun Untersuchungen, die im Kinderuntersuchungsheft durchgeführt werden. Die ersten beiden Untersuchungen im Kinderuntersuchungsheft stimmen vollständig mit bereits durchgeführten Untersuchungen im Mutterpass überein. Somit lassen sich in Zukunft Doppeldokumentationen, die einen großen Kostenpunkt im deutschen Gesundheitswesen darstellen, durch die automatisierte Weiterverarbeitung der Daten vermeiden. Neben der automatischen Weiterverarbeitung der Daten kann die im vorherigen Kapitel angesprochene Transformation der Daten in andere Sprachen eine große Rolle spielen. Über die angesprochenen Stylesheets lassen sich die Daten relativ einfach in alle Sprachen übersetzen.

Bei dem hier vorliegenden Standardisierungsversuch handelt es sich um einen reell möglichen Anwendungsbereich, wie das Beispiel der ICW AG zeigt. Dort wird der Lösungsansatz schon in einer ersten Implementierungsphase eingesetzt und auf seine Tauglichkeit geprüft. Damit das hier beschriebe Format eine große Akzeptanz findet, sind noch einige Rahmenbedingen zu erfüllen. Manche davon sind schnell umzusetzen, bei einigen ist man auf Mithilfe von Standardisierungsgremien angewiesen.

Momentan findet eine Beantragung der Codes, die bei der ICW AG spezifiziert wurden, als Codetabelle bei der HL7-Gruppe in Deutschland statt, damit die Codes allen Interessenten zugänglich sind.

Zwei Punkte, die ohne fremde Mithilfe nicht so schnell zu realisieren sind, sind die eindeutige Patienten- und die eindeutige Institutionsbezeichnung. Um Daten über Patienten zwischen verschiedenen Softwaresystemen austauschen zu können, ist es notwendig, die Daten den Patienten eindeutig zuzuordnen. Das Problem liegt darin, dass die Patienten nicht über eine weltweit eindeutige ID verfügen. Damit wird der Austausch der Daten zwischen verschiedenen Ländern unmöglich. Dieses Problem tritt aber schon beim Austausch der Daten zwischen verschiedenen Softwareprodukten auf, da die Patienten nur innerhalb eines Systems eindeutig sind. Abhilfe könnte hier die Einführung der elektronischen Gesundheitskarte (eGK) im deutschen Gesundheitswesen schaffen. Mit ihrer Einführung verfügt jeder Patient über eine lebenslang eindeutige Versichertennummer. Das Problem der eindeutigen Zuordnung gilt auch für die Institutionen, bei denen die Daten erhoben wurden. Jede serologische Untersuchung im Mutterpass wird bei einer Institution, in der Regel einem Labor, durchgeführt. Diese Institution ist für die Durchführung und das Ergebnis verantwortlich. Aus diesem Grund müssen die erhobenen Daten zugeordnet werden können. Mit der OID-Vergabe gibt es zwar ein System, das dies ermöglicht, jedoch ist es nicht möglich, diese Fremdarbeit im Rahmen dieses Standards zu realisieren. Vielmehr müssen alle Institutionen dazu angehalten werden, sich an solch einer OID-Vergabe zu beteiligen, um diesen Punkt zu realisieren. Durch einen solchen Standard, wie den hier beschriebenen digitalen Mutterpass, sollte die Akzeptanz für einen eindeutigen Bezeichner aber in Zukunft gesteigert werden.

Benötigte Dateien zur Erstellung und Validierung eines Mutterpasses

Anbei eine Beschreibung der benötigen Dateien um einen vollständigen Mutterpass zu generieren.

Beispieldokument

Im Anhang befindet sich ein vollständig ausgefüllter Mutterpass als Beispieldokument. Jede Untersuchung, die mehrmals vorkommen kann, ist nur einmal abgebildet.

• Mutterpass_Beispiel_V2.0_22.08.2008.xml

Codetabelle

Die Codetabellen enthalten alle generierten Codes, für den Fall, dass sich die speziellen Untersuchungen über bestehende Codesysteme (LOINC, ICD10) nicht abbilden lassen.

• Mutterpass_Codetabelle_V1.0.xsl

Mapping-Tabelle

Das Mapping sollte als Komponente des Leitfadens gesehen werden, denn dort wurden allen Feldern die Datentypen nach HL7 zugeordnet, was eine einfachere Programmierung ermöglichen soll. Es beinhaltet den kompletten Aufbau des Mutterpasses. Wie dieses Mapping zu lesen ist, ist dem Kapitel 3.3.9 Mapping-Tabelle zu entnehmen.

• Mutterpass_Mapping_V1.0.xsl

Schema

Das Schema bildet die speziellen Anforderungen des Mutterpasses vollständig ab und ist vom CDA-Schema abgeleitet worden. Die erstellten Mutterpassdokumente müssen sowohl gegen das Mutterpass-Schema, als auch das generische CDA-Schema validieren.

• Mutterpass_Schema_V2.0.xsd

Diskussion

Das vorliegende Dokument ist aus einer Master-Thesis entstanden. Als Vorlage für den elektronischen Mutterpass wurde die Papiervorlage des Mutterpasses von 2004 verwendet. Bei auftauchenden medizinischen Fragen, wie z. B. welche Eingabewerte für eine bestimmte Untersuchung möglich sind, wurde Rückfrage mit medizinischem Fachpersonal gehalten. Das Gleiche gilt für die Gruppierung von logisch zusammengehörigen Untersuchungen, die kontextbezogen gespeichert werden. Es wurde versucht, auf möglichst viele Freitextfelder zu verzichten, da diese nicht maschinell auswertbar sind.

In der Schweiz wurde durch das Führen einer elektronischen Krankengeschichte für Schwangerschaft, Geburt und Wochenbett bereits der erste Schritt für eine elektronische Verfügbarkeit der Daten geschaffen. Das Modell in der Schweiz sieht eine Speicherung des Mutterpasses im Portable Document Format (PDF) vor. Dadurch lassen sich die Daten elektronisch übertragen und auf einem USB-Stick speichern. Zum Anzeigen des PDF-Formates benötigt man lediglich eine kostenlose Version von Acrobat um die Dateien anzuzeigen. Es wird also keine zusätzliche Software benötigt. Der große Nachteil dieses Formates ist allerdings, dass er nicht maschinell auswertbar ist und die Daten nicht weiterverarbeitet werden können.

Der hier vorgestellte Lösungsansatz geht noch einen Schritt weiter. Diese Arbeit und die beigefügten Dateien bilden eine vollständige Implementierungsmöglichkeit des digitalen Mutterpasses für Deutschland auf Basis von CDA Release 2. CDA beschreibt keine Applikation, sondern vielmehr eine Standardisierungsmöglichkeit, wie klinische Daten gespeichert werden sollen, um sie automatisch auswertbar zu machen. In Deutschland existieren bereits eine Reihe an Spezifikationen, die auf dem CDA-Standard basieren, wie z. B. der Arztbrief. Die Anzeige erfolgt nicht wie beim PDF-Format über ein kostenloses Tool zum herunterladen, sondern wird über Stylesheets realisiert. Da es sich bei CDA um einen XML-basierten Standard handelt, ist die gespeicherte Information von der Darstellung getrennt. Dadurch lassen sich die Daten flexibler handhaben. Es ist z. B. möglich, ein Stylesheet zur Konvertierung nach HTML oder PDF zu generieren. Momentan kann das Stylesheet des VHitG-Arztbriefes zur Transformation nach HTML und damit zur Anzeige genutzt werden. Das generische Standardstylesheet hat den Namen „vhitg-cda“ und liegt aktuell in der Version 3 vor. In Form von CDA lassen sich die Dokumente mit einem Stylesheet auch schnell und kostengünstig in andere Sprachen übersetzen, so dass auch ausländische Mitbürger, die nicht der deutschen Sprache mächtig sind, den Mutterpass verstehen und benutzen können. Dieser Punkt ist ein großer Vorteil der digitalen Implementierung, da ein sehr hoher Prozentsatz derjenigen, die nicht regelmäßig an den Vorsorgeuntersuchungen teilnehmen, ausländische Mitbürger sind. Dies ist sicherlich auch zum Teil auf Sprachprobleme zurückzuführen. Die Transformation der Daten in andere Sprachen kann auch ein großer Vorteil sein, wenn sich die werdende Mutter im Ausland aufhält. Da es sich bei dem Mutterpass um ein Notfalldokument handelt, kann der schnelle Zugriff auf die Daten eine wichtige Rolle spielen.

Implementierungsbeispiel

Die Firma InterComponentWare AG hat für niedergelassene Ärzte ein Modul zum digitalen Mutterpass entwickelt, welches schon auf dem hier entwickelten Lösungsansatz basiert. Dieses Modul ist ein Bestandteil der Software Praxis4More (P4M), die ebenfalls in der InterComponentWare AG entwickelt wurde. P4M ergänzt vorhandene Praxisverwaltungssysteme (PVS) und ermöglicht den Austausch medizinischer Daten in verschiedenen Arztnetzen.

Blutgruppenmaske von P4M beim digitalen Mutterpass

In diesem digitalen Mutterpass werden alle relevanten Daten zur Gesundheit der Mutter und der Entwicklung des Kindes bis zu dessen Geburt eingetragen. Die Unterteilung der Masken richtet sich dabei nach der Originalpapiervorlage, um den Ärzten die Umstellung auf die digitale Lösung zu erleichtern. Beispielsweise werden in der Untergruppe Blutgruppe die Informationen zur Blutgruppe des Patienten eingetragen. Blutgruppe und Rhesus-Faktor können aus den entsprechenden Dropdownmenüs ausgewählt werden. Dies bewirkt einen entsprechenden Vermerk im Eingabefeld Blutgruppe im Übersichtsbereich.

Die so erhobenen Daten werden zusätzlich zur Ablage in einer Datenbankstruktur als CDA-Dokument nach dem hier vorgestellten Lösungsansatz gespeichert. Dadurch lassen sich die Daten später digital weiterverarbeiten. Auf Wunsch des Patienten werden die digital gespeicherten Daten des Mutterpasses an die elektronische Gesundheitsakte (EGA) des Patienten weitergeleitet. Dafür verfügt die InterComponentWare AG ebenfalls über ein hauseigenes Produkt, die Lifesensor Gesundheitsakte. Dabei handelt es sich um eine plattformunabhängige Webanwendung. Dort können die Daten des Mutterpasses eingelesen und verarbeitet werden. Dadurch ergibt sich, von der Erhebung der Daten bis zur Wiederverwendung, ein komplettes Szenario.

Anwendungsszenario eines digitalen Mutterpasses

Szenario:

1. Die Daten werden nach der ersten Untersuchung im Praxisverwaltungssystem des Arztes aufgenommen und als Mutterpass-CDA gespeichert. Dieses Dokument wird an die Lifesensor Gesundheitsakte hochgeladen, so dass der Patient seine Daten einsehen und verwalten kann.
2. Bei weiteren Untersuchungen in der Klinik oder in einer Arztpraxis wird das aktuellste Mutterpass-Dokument heruntergeladen und um die zusätzlichen Daten erweitert.
3. Das veränderte Dokument mit den neuen Daten wird wieder an die EGA hochgeladen.
4. Sobald das Kind der Mutter geboren wird und über eine eigene EGA verfügt, können die digitalen Daten aus dem Mutterpass in seine eigene Lifesensor-Akte übertragen werden. Das spart die bisherige Doppelerfassung der Daten, da die ersten Untersuchungen im Kinderuntersuchungsheft mit den erhobenen Daten des Mutterpasses identisch sind.

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

Abkürzungsverzeichnis

A
ADT	Abrechungsdatenträger
ANSI	American National Standards Institute
B
BDT	Behandlungsdatenträger
C
CD	Concept Descriptor
CDA	Clinical Document Architecture
D
DICOM	Digital Imaging and Communications in Medicine
DIMDI	Deutsches Institut für Medizinische Dokumentation und Information
DMP	Desease Management Programme
DTD	Document Type Definition
E
eGK	elektronische Gesundheitskarte
EPA	Elektronische Patientenakte
G
GDT	Gerätedatenträger
H
HIV	Humane Immundefizienz-Virus
HL7	Health Level Seven
HPC - HBA	Heilberufsausweis
HTML	Hypertext Markup Language
I
ICD	International Classification of Diseases and Related Health Problems
ICW	InterComponentWare
ID	Identifikationsnummer
IETF	Internet Engineering Task Force
II	Instance Identifier
ISO	Internationale Organisation für Normung
K
KBV	Kassenärztliche Bundesvereinigung
KIS	Klinikinformationssystem
KVK	Krankenversichertenkarte
L
LDT	Labor-Datenträger
LOINC	Logical Observation Identifiers Names and Codes
M
MDF	Message Development Framework
MIME	Multipurpose Internet Mail Extensions
O
OID	Object Identifier
OPS	Operationen- und Prozedurenschlüssel
OSI	Open Systems Interconnection Reference Model
P
PDF	Portable Document Format
PKV	Private Krankenversicherung
R
RIM	Reference Information Model
PVS	Praxisverwaltungssystem
S
SGML	Standard Generalized Markup Language
T
TS	TimeStamp
U
UCUM	Unified Code for Units of Measure
URI	Uniform Resource Identifier
USB	Universal Serial Bus
UFT	Unicode Transformation Format
X
XML	Extensible Markup Language
XSD	XML-Schema-Definition

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

Literaturverzeichnis

[AZTB]	Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen. Dokumenten-OID: 1.2.276.0.76.3.1.13.7.5 Version 1.50 Stand: 12.05.06
[XML1]	W3C: Extensible Markup Language (XML) 1.0 (Zweite Auflage) http://www.edition-w3c.de/TR/2000/REC-xml-20001006/#sec-intro Stand: 6.10 2000
[XML2]	W3C: Extensible Markup Language (XML) 1.1 (http://www.w3.org/TR/2004/REC-xml11-20040204) Stand: 08.1.2007
[XML3]	Rainer Eckstein / Silke Eckstein XML und Datenmodellierung : XML-Schema und RDF zur Modellierung von Daten und Metadaten einsetzen Heidelberg 2004.
[XML4]	Dirk Ammelburger XML: Grundlagen der Sprache und Anwendungen in der Praxis München 2004.
[DIMDI]	DIMDI (Deutsches Institut für Medizinische Dokumentation und Information) http://www.dimdi.de Stand: 17.01.07
[OPS]	Operationen und Prozedurenschlüssel (OPS) Version 2007 http://www.dimdi.de/static/de/klassi/prozeduren/ops301/opshtml2007/fr-ops.htm OID 1.2.276.0.76.5.317 Stand: 25.07.06
[ICD10]	ICD-10-GM 2007 http://www.dimdi.de/dynamic/de/klassi/downloadcenter/icd-10-gm/version2007 OID 1.2.276.0.76.5.318 Stand: 12.10.06
[LOINC]	LOINC-Benutzerhandbuch http://www.dimdi.de/dynamic/en/ehealth/loinc/downloads/loinc/german_loinc_user_guide.pdf OID: 2.16.840.1.113883.6.1 Stand: 20.12.06
[UCUM1]	The Unified Code for Units of Measure http://aurora.regenstrief.org/UCUM/ Stand: 17.01.07
[UCUM2]	Commonly Used UCUM Codes for Healthcare Units http://www.hl7.de/download/documents/ucum/ucum.html Stand: 13.03.07
[HL7]	Health Level Seven http://www.hl7.org/ Stand 13.03.07
[HL7B]	HL7 Benutzergruppe in Deutschland e.V. http://www.hl7.de/standard/wasist_hl7.php Stand: 07.03.07
[HL7M]	HL7-Mitteilungen ISSN1616-8909 Nr.21 Offizielle Mitteilung der Hl7-Benutzergruppe in Deutschland e.V. Ausgabe 14.08.2006
[HL7RIM]	HL7 Reference Information Model http://www.hl7.org/library/data-model/RIM/C30204/rim.htm#open-rimdiv Stand: 07.03.07
[CDAR2]	Clinical Document Architecture, Release 2 http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm Stand: 07.03.07