HL7 Version 3 Datentypen und CMETs
Zeile 1: | Zeile 1: | ||
__NOTITLE__ | __NOTITLE__ | ||
− | {{#HL7 Version 3 Datentypen und CMETs} | + | {{#customtitle:HL7 Version 3 Datentypen und CMETs}} |
− | } | ||
− | |||
{{Infobox Ballot | {{Infobox Ballot | ||
|Leitfaden = HL7 Version 3 Datentypen und CMETs | |Leitfaden = HL7 Version 3 Datentypen und CMETs | ||
Zeile 11: | Zeile 9: | ||
|Originaldokument= --nicht verfügbar-- | |Originaldokument= --nicht verfügbar-- | ||
}} | }} | ||
+ | |||
+ | Dieses Dokument gibt den Implementierungsleitfaden "HL7 Version 3 Datentypen" wieder. | ||
{{:V3dtr1:Impressum}} | {{:V3dtr1:Impressum}} |
Version vom 5. Januar 2011, 23:08 Uhr
__NOTITLE__
Abstimmungs- Dokument |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Version | Date | Status | Realm
Inhaltsverzeichnis
ImpressumDieser Leitfaden ist vom Interoperabilitätsforum und den Technischen Komitees der HL7-Benutzergruppe in Deutschland e. V. zusammengestellt und ist angelehnt an den Leitfaden "HL7 Basicomponenten", erstellt durch Stichting HL7 Nederland, Technische Stuur Commissie, Veenendaal (Niederlande) und Nictiz, Nationaal ICT Instituut in de Zorg, Leidschendam. Er wurde aus dem Niederländischen übersetzt und an die deutschen Gegebenheiten angepasst. DanksagungWir danken besonders
AnsprechpartnerKai U. Heitmann HL7-Benutzergruppe in Deutschland e.V. Heitmann Consulting and Services Sciphox Arbeitsgemeinschaft GbR mbH
DokumenteninformationStatus
DatumErstes Release: April/Mai 2006 Wiki Release: November 2009
Revisionsliste (NL)
Revisionsliste (DE)
EditorenKai U. Heitmann (KH), Heitmann Consulting and Services, und HL7 Benutzergruppe in Deutschland e. V.
Autoren
Mit Beiträgen von
LegendaIn dieser Spezifikation werden regelmäßig folgende Symbole verwendet:
Einleitung
Ziel dieses DokumentsDie HL7 Version 3 Standard beschreibt unter anderem eine Reihe von Artefakts, die in vielen Nachrichten benutzt werden. CMETs und Datentypen werden in allen HL7v3 Nachrichten benutzt. Die diversen Implementierungsleitfäden der HL7 Version enthalten bis jetzt jeweils eine Beschreibung der darin verwendeten Datentypen und CMETs. Um Wiederholungen zu vermeiden, aber auch aus Gründen der Konsistenz, wurde in mehreren Ländern beschlossen, für dieses Thema einen eigenen Implementierungsleitfaden zu erstellen. Dieser Leitfaden ist eine Übersetzung des Leitfadens, den die niederländischen Kollegen erstellt haben. Er wurde an die deutschen Gegebenheiten und Erfordernisse angepasst. Zweck dieses Dokuments ist es, die meistgebrauchten Datentypen und CMETs ausführlicher zu beschreiben und für die Anwendung im deutschen Gesundheitswesen zu spezifizieren. Dieses Dokument muss zusammen mit der HL7 Version 3 Standard Materie gelesen werden. Dieses Dokument richtet sich vor allem auf Softwareentwickler von IT Anwendungen im Gesundheitswesen und auf das Gesundheitswesen bezogene infrastrukturelle Applikationen, die anhand des HL7 Version 3 Kommunikationsstandards und anhand dieses Dokuments ihre Nachrichtenschemas und Nachrichten bzw. Dokumente definieren wollen.
Aufbau des DokumentsDieses Dokument enthält eine Beschreibung der wichtigsten Datentypen und CMETs, wobei ausschließlich die Aspekte beschrieben werden, die auf die deutschen Situation zutreffen. Falls es spezielle Anhaltspunkte dafür gibt, wie etwas (möglicherweise abweichend vom internationalen Standard) in Deutschland implementiert werden muss, wird dies im Text angegeben. HL7 Artefakts werden in diesem Dokument mit ihrer offiziellen Identifikation konform mit der HL7 Version 3 Ballot #7 vom März 2004 angegeben. Diese Artefakts werden in diesem Dokument nicht im Detail besprochen. Dazu wird auf den HL7 Version 3 Standard selbst verwiesen. Einige der in diesem Implementierungsleitfaden beschriebenen HL7 Artefakts sind (noch) nicht im internationalen HL7 Standard aufgenommen. Diese Artefakts werden in diesem Dokument detailliert beschrieben, da sie nicht in der HL7 Materie dokumentiert sind. Als Vorbereitung auf eine eventuelle spätere Aufnahme in den weltweiten Standard sind die Namen dieser HL7 Artefakts in Englisch abgefasst. Neue Artefakts haben eine Identifikation konform mit dem HL7 v3 Kennzeichnungs- und Identifikationsabkommen erhalten. Die (vorläufig) Deutschland-spezifischen Artefakts sind mit einem “DE” Code gekennzeichnet. Alle neuen Artefakts werden der internationalen HL7 Organisation zur Beurteilung vorgelegt, bevor sie in den internationalen Standard aufgenommen werden können. Wenn sie einmal aufgenommen sind, verfällt der “DE” Code.
Relation zu den übrigen HL7v3 ImplementierungsleitfädenDiverse Veröffentlichungen zu IT Spezifikation im Rahmen von HL7 Version 3 in Deutschland enthalten Beschreibungen von Datentypen und CMETs. Dieses Dokument ist eine detailliertere, nicht kontextabhängige Bearbeitung der Datentypen und CMETs. Dieses Dokument wurde zudem an neue Erkenntnisse aus vorigen Projekten und Spezifikationen angepasst. Bereits publizierte Implementierungsleitfäden behalten ihre Relation zu den CMETs und Datentypen, die in den Implementierungsleitfäden enthalten waren. Allerdings werden künftige Publikationen an eine Version des Implementierungsleitfadens für CMETs und Datentypen gekoppelt.
Status dieses DokumentsDieses Dokument enthält eine Reihe deutscher Angaben zur Anwendung der HL7 Version 3. Dieses Dokument ist auf Ballot 7 des HL7v3 Standards basiert. Dieses Dokument ist eine Erweiterung (und kein Ersatz) für die internationale HL7 Version 3 Materie. Bei Differenzen zwischen dem internationalen Standard und diesem Dokument gilt dasjenige, das in dieser Richtlinie festgelegt ist. Dieses Dokument schreibt einzelne Einschränkungen der Freiheiten vor, die der internationale Standard bietet; Es ist ein “conformance profile”. Parteien, welche die Version 3 auf der Basis des internationale HL7 Version 3 Standards implementieren, entsprechen damit also nicht dem “HL7 Deutschland conformance profile”. Anbieter von Anwendungen im Gesundheitswesen und Lieferanten, die Daten über die kommende nationale Infrastruktur austauschen wollen, müssen dem “HL7 Deutschland conformance profile” entsprechen.
können Sie ein Beispiel-Nutzungsszenario (use-case) bei HL7 Deutschland einreichen und einen Antrag zur Anpassung dieses Dokuments anmelden.
DatentypenIn diesem Abschnitt werden die wichtigsten Datentypen beschrieben, wobei ausschließlich die Aspekte beschrieben werden, die auf die deutsche Situation zutreffen. Falls es spezielle Anhaltspunkte dafür gibt, wie etwas (möglicherweise abweichend vom internationalen Standard) in Deutschland implementiert werden muss, wird dies im Text angegeben. Nur die innerhalb der Modelle dieses Leitfadens verwendeten Datentypen werden erläutert. Weitere Information finden Sie in der HL7 V3 Standard/Ballot Materie, namentlich in den Kapiteln “abstract data types” und “XML ITS data types”. v3dtr1:AE
XML Repräsentation von Klassen-AttributenKlassen-Attribute und DatentypenDie Attribute von Klassen in den HL7 Modellen werden auf eine bestimmte, fest vordefinierte Weise in die XML Repräsentation umgesetzt. Beispiel: In der vorstehenden Klasse “Patient” ist eine Reihe von Attributen aufgenommen, darunter der classCode (mit dem festen Wert “PAT”), id, addr und telecom. Jedes dieser Klassen-Attribute hat unter anderem
Mit Ausnahme der strukturellen Attribute (siehe nachstehend) werden die Modell-Attribute als XML Elemente wiedergegeben. Die Elemente tragen den im Modell angegebenen Namen. Wenn z.B. ein Attribut den Namen id hat, ist der Name des XML Elements <id/>. <id ... />
<addr ... />
<telecom ... />
In dem XML Schema ist die Kardinalität des Modellattributs aufgenommen. In dem vorstehenden Beispiel ist <id> Pflicht [1..1], <addr> [0..1] und <telecom> [0..*] sind optional. Die XML Elemente haben XML Attribute, die durch den Datentyp selbst bestimmt werden. Die hier verwendete Notationsform für die Datentyp-Attribute lautet:
<id root="..." extension="..." />
Nähere Erläuterungen zu den Datentypen und den dazugehörenden Attributen sind in den folgenden Kapiteln pro Datentyp aufgenommen. Ausnahmen mit Informationen als Element ContentBei den meisten Datentypen werden die faktischen Informationen in den XML Attributen wiedergegeben. Es gibt allerdings ein paar Ausnahmen. Bei den Datentypen Binary, Encapsulated Data, Entity Name, Person Name, Organization Name, Trivial Name, Address und Character String werden die Informationen als Element Content wieder-gegeben. Beispiel: Die Komponenten einer Adresse werden durch Kindelemente des addr Elements mit den Informationen als Element Content (im Beispiel rot markiert) aufgenommen. <addr>
<streetName>Große Bleichen</streetName>
<houseNumber>23-25</houseNumber>
<postalCode>20354</postalCode>
<city>Hamburg</city>
</addr>
Zusammengesetzte DatentypenEs gibt eine Reihe zusammengesetzter Datentypen, die eine Sammlung von Datenelementen darstellen. So wird beispielsweise in einem Intervall die Unter- und Obergrenze angegeben und eine Ratio stellt ein Verhältnis zweier Werte dar. Bei zusammengesetzten Datentypen wird die Substruktur (beispielsweise <low> und <high> bei einem Intervall) immer als Kindelement des betreffenden Datentyp-Elements wiedergegeben. <effectiveTime>
<low value="20040507"/>
<high value="20040909"/>
</effectiveTime>
In den Beschreibungen der zusammengesetzten Datentypen werden die Kindelemente folgendermaßen notiert:
Strukturelle AttributeEs gibt eine Liste von Klassen-Attributen, die nicht als separate Elemente präsentiert werden, sondern als XML Attribute der Klassenelemente.
Beispiel: In der Klasse Observation gibt es zwei Attribute, classCode und moodCode, die als strukturelle Attribute nicht als separate XML Elemente auftreten, sondern als XML Attribute des Klassenelements. <observation classCode="OBS" moodCode="EVN"/>
Kardinalitäten, “mandatory", “required”, "optional"In den HL7 Version 3 Nachrichten bzw. CDA-Dokumenten können bei den Klassen-Attributen weitere Eigenschaften genutzt werden, wie z.B. die Kardinalität des Attributs. Die nachstehende Tabelle enthält eine Übersicht dieser zusätzlichen Eigenschaften.
Fehlende Informationen: nullFlavorsJeder Datentyp und jede Assoziation besitzt das Attribut nullFlavor, mit dem angegeben wird, dass der betreffende Wert fehlt, inklusive einer möglichen Erklärung für das Fehlen. Dies wird verwendet, wenn eine Information in einer HL7v3 Nachricht / einem CDA-Dokument verpflichtend ist (Kardinalität 1..), das sendende Anwenderprogramm aber einfach keinen Wert verfügbar hat. Es handelt sich dabei um Informationen, von denen die Conformance required ist. Wenn die Conformance mandatory ist, muss grundsätzlich ein echter (Nicht-Null) Wert zugewiesen werden. Der Datentyp für das Attribut nullFlavor ist CS (Coded Simple Value) mit dem Vokabular der Domäne nullFlavor:
XML Beispiel Da keinerlei Information in einer HL7v3 Nachricht de facto den Datentyp ANY haben kann, wird hier die Verwendung des Attributs nullFlavor anhand einiger spezieller Datentypen erläutert (die das Attribut nullFlavor also von ANY erben). Bei den Beschreibungen im weiteren Verlauf dieses Implementierungsleitfadens wird im übrigen von Nicht-Null-Werten ausgegangen. 1) Der Anfrage/Verordnungszeitpunkt ist in einer HL7 v3 Nachricht Pflicht, aber das sendende Anwenderprogramm weiß einfach nicht, wann die Anfrage oder Verordnung ausgeschrieben wurde (auch wenn das Konzept unterstützt wird, weil es required ist). <author>
<time nullFlavor="UNK"/>
</author>
2) Ein Anwenderprogramm hat die Möglichkeit, Daten von Patienten zu registrieren, deren eindeutige Identifikationsnummer (noch) nicht bekannt ist, und diese später doch noch an die registrierten Daten zu koppeln. In diesem Fall kann die Personenidentifikation (wenn sie verpflichtend in der betreffenden HL7 v3 Nachricht vorhanden ist), folgendermaßen wiedergegeben werden: <Patient>
...
<Person>
<id nullFlavor="NAV"/>
...
</Person>
</Patient>
3) In bestimmten Situationen wird bei den Spezifikationen ein festes Vocabulary Domain angegeben, ohne die Möglichkeit, extra Werte hinzuzufügen. Das sendende Anwenderprogramm kann allerdings keinen dieser Werte in der betreffenden Domäne nutzen (ein Beispiel dieser Situation ist die Übermittlung von Arzneimittel-Rezepturen). <medicationKind>
<code nullFlavor="OTH"/>
</medicationKind>
4) Bei der Spezifikation der Inhaltsstoffe eines bestimmten Arzneimittels muss angegeben werden, dass es Spuren von Eisen enthält, obwohl die exakte Menge nicht bekannt ist (und angesichts der geringen Menge nicht relevant). In diesem Fall könnte angegeben werden, dass es sich um eine TRC (trace) Menge von unbekannter Größe handelt. <ingredient>
<quantity nullFlavor="TRC"/>
</ingredient>
5) Das Privacy Filter eines bestimmten Anwenderprogramms (oder ein zwischen-gelagertes Gateway) hat beschlossen, dass eine bestimmte Information nicht übermittelt werden darf. Der betreffende Wert wird durch ein nullFlavor des Typen MSK (masked) ersetzt, um ihn abzuschirmen. Achten Sie darauf, dass der Empfänger trotzdem darüber informiert wird, dass die Information verfügbar war! <subject>
<Patient>
...
<addr nullFlavor="MSK"/>
...
</Patient>
</subject>
Der generische (ANY) DatentypDieser abstrakte Datentyp ist die Basis für alle anderen Datentypen. Kein einziger Wert in einer HL7 v3 Nachricht hat de facto den Datentyp ANY, obwohl jeder Datentyp innerhalb HL7 v3 eine Spezialisierung von ANY ist. Das bedeutet auch, dass jeder andere Datentyp die Attribute von ANY mittels Vererbung übernimmt (siehe “Fehlende Daten: nullFlavor”). Der ANY Type kommt hin und wieder in den HL7 Modellen vor, wobei es sich meistens um den Wert klinischer Befunde oder Verordnungen handelt. Der ANY Typ kommt jedoch in XML Nachrichten nicht vor, da ANY immer durch einen bestimmten Datentyp in einer Nachricht ersetzt wird. Der Datentyp des Attributs value ist beispielsweise bei einer Observation “ANY” , denn es ist vorab (im Modell) nicht deutlich, welcher Typ für den Wert zutreffend ist. Dies wird jedoch erst durch die faktische Instanziierung festgelegt. Der Datentyp für value muss also immer über die xsi:type Instruktion festgelegt werden. Wenn man einen ANY Typ in einer Instanziierung nicht begrenzt, kann eine XML Nachricht nicht validiert werden. Attribute eines Elements mit diesem Datentyp sind:
Nachstehend sind einige Beispiele aufgeführt, aber für alle Datentypen gilt, dass ein nullFlavor angegeben werden kann (außer wenn das Element mandatory ist). XML Beispiele <value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>
<value xsi:type="CD" code="C1" codeSystem="2.16.528.1.1003.99.100"
displayName="Warnung: die gefundenen Namensdaten weichen ab von den Namensdaten in der Anfrage."/>
<value xsi:type="PQ" value="12" unit="ml"/>
<value xsi:type="ED">dies ist der Text mit der Begründung</value>
BL (Boolean)Der Datentyp BL (Boolean) bezieht sich auf die so genannte Zwei-Werte-Logik. Eine Information dieses Typs kann lediglich die Werte “true” oder “false” enthalten oder ein nullFlavor, falls die Conformance dies zulässt (also wenn die Information nicht mandatory ist). Jeder Wert (oder zwei Werte) des Typen Boolean kennt die nachstehenden Bearbeitungen (NULL bedeutet, dass der Wert fehlt):
Eine Information mit dem Datentyp BL hat (wenn es Nicht-Null ist) das Attribut value. Die möglichen Werte sind “true” oder “false”, womit angegeben wird, ob die Information richtig oder falsch ist.
Eine Person (oder ein anderes ‘living subject’) ist gestorben. <livingSubject>
…
<deceasedInd value="true"/>
</livingSubject>
Eine Assoziation ist non-conductive (das heißt: gibt keinen Kontext an). <support2 contextConductionInd="false">
...
</support2>
In der vorstehenden Situation ist der Datentyp BL nicht zutreffend auf ein XML Element, sondern auf ein Attribut. In diesem Fall erhält das betreffende Attribut direkt den Booleschen Wert (Es übernimmt also praktisch die Rolle, die das Attribut value normalerweise hat).
BIN (Binäre Daten – binary data)BIN ist der Supertyp für Multimedia-Daten. Der BIN-Typ kommt nicht selbständig in Nachrichten vor. Wenn Multimedia-Daten in einer Nachricht aufgenommen werden müssen, muss dazu der Encapsulated Data (ED) Typ verwendet werden.
ED (Eingekapselte Daten – encapsulated data)Dies ist ein allgemeiner Typ für allerlei Multimedia-Daten. In Deutschland wird dieser Typ vorläufig für Texte mit oder ohne (einfachem) Layout verwendet. ED ist ein komplexer Typ, der Elemente und Attribute enthält. Die Daten (Text, Bilder) befinden sich im ED-Element in der Form, die das ‘encoding’ Attribut spezifiziert hat. Der ED-Typ kennt zweierlei Nutzungsformen:
Attribute von ED
Benutzung dieses Attributs ist optional. Dabei sind zwei Kodierungstypen möglich.
Dieses Attribut zeigt die Art der Daten an. In Deutschland werden vorläufig nur die verpflichteten Datenarten unterstützt, die in der nachstehenden Tabelle wiedergegeben sind:
Zugelassene mediaTypes in einer faktischen Implementierung können weiter eingeschränkt werden. Kindelemente von ED
Da ‘thumbnail’ ein ED-Typ ist, können alle hiervor genannten Datenarten darin untergebracht werden. XML Beispiele Einfacher Freitext: <text xsi:type="ED" mediaType="text/plain">
Die häusliche Situation des Patienten ist schwierig, da die Kinder weit weg wohnen.
</text>
Beispiel einer Anwendung von Thumbnail und Reference: <value xsi:type="ED" mediaType="image/png" encoding="B64">
<reference value="http://radiology.iumc.edu/xrays/128s.png">
<useablePeriod xsi:type="IVL_TS">
<low value="200007200845" />
<high value="200008200845" />
</useablePeriod>
</reference>
<thumbnail mediaType="image/jpeg" representation="B64">
MNYD83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83
6edjzMMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir
...
omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu83
4zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83==
</thumbnail>
</value>
ST (Zeichenkette – Character String)Dieser Typ ist für Freitext in der einfachsten Form gedacht. ST ist eine Spezialisierung des ED-Typs. Der mediaType ist festgelegt mit ‘text/plain’ und der encoding Typ ist ‘TXT’. Die anderen Attribute und Elemente von ED dürfen beim ST-Typ nicht benutzt werden. Der ST-Typ wird vorwiegend in anderen Datentypen, wie AD und PN verwendet. Im Allgemeinen gilt jedoch, dass man für Texte besser den ED-Typ benutzen kann, weil dieser ja auf einen ST-Typ reduziert werden kann, wenn die Attribute korrekt ausgefüllt werden. XML Beispiel Dieses Beispiel ist nahezu gleich mit dem ersten Beispiel bei ED. Funktional sind beide identisch. <text xsi:type="ST">
Die häusliche Situation des Patienten ist schwierig, da die Kinder weit weg wohnen.
</text>
SC (Zeichenkette mit Code – Character String with code)Dieser Typ ist eine Erweiterung des SV-Typen, ergänzt mit Attributen des Datentyps CV. Hierdurch ist es möglich, den Text über einen Code näher zu spezifizieren. Momentan wird der SC-Typ noch nicht benutzt. In einem folgenden Ballot wird er ein Bestandteil des AD (Adresse) Typen werden. Es wird dann möglich sein, um beispielsweise dem Land, neben dem freien Text, auch einen Code zuzuordnen.
CD (Konzeptdeskriptor – Concept Descriptor)Dieser Datentyp spezifiziert ein Konzept über einen Code und das Codesystem (die Tabelle) aus dem der Code stammt, und enthält optional eine oder mehrere Übersetzungen dieses Codes mit Hilfe anderer Kodiersysteme. Der einzige Unterschied zwischen dem CE-Datentyp und dem CD-Datentyp ist der Fakt, dass CD ein qualifier Kindelement besitzen kann. Die weiteren Attribute, mit Ausnahme von qualifier, sind bei der Beschreibung von CE für die Benutzung des CE-Datentyps in Deutschland zu finden.
CE (Kodierte Daten mit Äquivalenten – Coded with Equivalents)Dieser Datentyp spezifiziert ein Konzept über einen Code und das Codesystem (die Tabelle) aus dem der Code stammt und enthält optional eines oder mehrere Äquivalente dieses Codes mit Hilfe anderer Codiersysteme. Beispiel: Das Konzept “Männlich” wird abhängig von dem verwendeten Codiersystem identifiziert, beispielsweise durch ein “M” oder den Code “1”. Der Empfänger ist nur dann in der Lage, einen Code eindeutig zu interpretieren, wenn neben dem Code auch das verwendete Codiersystem identifiziert wird. Die Kombinationen (“M”, HL7 v3 Tabelle AdministrativeGender) oder deren Übersetzung (“1”, ABC-KIS System Geschlechtscodetabelle) sind eindeutig zu interpretieren. AttributeAttribute eines Elements mit diesem Datentyp sind:
Ein ISO Object Identifier (OID) ist ein weltweit eindeutiger String (Zeichenkette), der aus Zahlen und Punkten besteht (beispielsweise "2.16.840.1.113883.3.1"). Laut ISO Definition bestehen OIDs aus Pfaden mit einer Baumstruktur, wobei die äußerst links situierte Zahl die root ist und die am meisten rechts situierte Zahl ein leaf (ein Blatt als Endpunkt) markiert. Die Nummer ist garantiert weltweit eindeutig, weil sie auf dem System der delegierten Verantwortlichkeit basiert. Jeder Zweig unter einer Wurzel in der Baumstruktur korrespondiert mit einer Domäne, in der eine Organisation die Abgabe von OIDs verwaltet. Die zentralen Vergabestelle für OIDs im Gesundheitswesen in Deutsch-land publiziert eine Tabelle mit OIDs. Informieren Sie sich bei Zweifel bei der zentralen Vergabestelle, welche (eventuell neu zu registrierende) OID benutzt werden muss. Im OID Konzept für das Deutsche Gesundheitswesen oidk finden Sie nähere Informationen über Codiersysteme und OIDs. Grundsätzlich sollte erwähnt werden, dass die Verwendung von Codesystems in einem bestimmten Kontext z. B. durch Implementierungsleitfäden eingeschränkt wird.
Optional. Eine Textform des Namens des Codiersystems, das den Code enthält. Dem Wert dieses Attributs darf keine Bedeutung zugemessen werden, außer dass es dem Benutzer vorgelegt wird, um den Hintergrund des Codes zu verdeutlichen. Für die Lesbarkeit von Nachrichten wird empfohlen, das codeSystemName mitzusenden.
Optional. Eine Textform der Version des Codiersystems, das den Code enthält. Dem Wert dieses Attributs darf keine Bedeutung zugemessen werden, außer dass es dem Benutzer vorgelegt wird, um den Hintergrund des Codes zu verdeutlichen. Verschiedene Versionen eines Codiersystems können über einzelne OIDs im codeSystem Attribut identifiziert werden. Das empfangende System darf deshalb niemals den Wert des codeSystemVersion benutzen, um den Code zu interpretieren. Ob eine neue Version eines Codesystems ein neue OID bekommt, hängt von verschiedenen Faktoren ab, die hier nicht näher erläutert werden sollen. So sehen die verschiedenen ICD-Schlüssel in Deutschland für jede Version eine eigene OID vor, verschiedene Versionen des LOINC-Codes beispielsweise hingegen haben konstant eine OID. Elemente
Optional. Eine textliche Beschreibung des Konzepts. Dies stellt den Text dar, worauf das sendende System den Code zugewiesen hat. Dies ist also gerade umgekehrt zu displayName zu sehen, wo eine Beschreibung auf Basis des Codes bestimmt wird. Das bedeutet auch, dass originalText gerade auch ausdrücklich in den Fällen vorkommen kann, wo kein Code zugewiesen ist oder gefunden werden kann. In diesem Falle biete originalText die Möglichkeit, Text anzugeben, der anscheinend (noch) nicht in einen Code umzusetzen war.
Optional. Null oder mehr Übersetzungen des Konzepts mit Hilfe alternativer Codier-systeme. Alle Übersetzungen müssen auf ein und dasselbe Konzept hinweisen. Dabei ist es zugelassen, dass die Übersetzungen “weniger nuanciert/detailliert” sind als das originale Konzept. Beispiel: Das Konzept “Granny Smith” kann, wenn ein Codiersystem nicht das entsprechende Niveau an Details enthält, übersetzt werden in das Konzept “Apfel”. Das Konzept “Apfel” darf allerdings niemals übersetzt werden in das detaillierte Konzept “Granny Smith”. Das Konzept “Apfel” darf ebenfalls nicht übersetzt werden in das Konzept “Grün”: Es handelt sich dabei vielleicht um verwandte Konzepte, aber inhaltlich ist es keine Übersetzung des originalen Konzepts. XML Beispiele <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
<value xsi:type="CE" code="Z94.0" codeSystem="2.16.840.1.113883.6.3" displayName="Lungenentzündung" codeSystemName="ICD10"/>
<code code="ERY" codeSystem="2.16.840.1.113883.2.4.4.13"/>
<code code="GSMITH" codeSystem="2.16.840.1.22.3"
codeSystemName="US Fruit Category" displayName="Granny Smith">
<translation code="100" codeSystem="2.16.840.1.113883.2.4.4.99"
displayName="Appel"
codeSystemName="Deutscher Verband für Nahrungsmittel" />
</code>
<code code="13715119" codeSystem="2.16.840.1.113883.2.4.4.8"
codeSystemName="G-Standard Artikel"
displayName=" ABSORIN UNTERLAGE 60X90CM 120G FLUFF 60920">
<translation code="753696" codeSystem="2.16.840.1.113883.2.4.4.7"/>
</code>
<code nullFlavor="OTH" originalText="eine selbstgemachte Medizin"/>
CV (Kodierte Werte – Coded Value)Dieser Datentyp spezifiziert ein Konzept über einen Code und das Codesystem (die Tabelle) aus dem der Code stammt. Im Gegensatz CE-Datentyp dürfen CV-Datentypen keine Übersetzungen (translation) aus einem Konzept und kein qualifier Attribut enthalten. Siehe Beschreibung von CE – mit Ausnahme von qualifier und translation – für die Verwendung des CV-Datentyps in Deutschland. XML Beispiele<code code="SF36" codeSystem="2.16.840.1.113883.2.4.4.13"/>
<value xsi:type="CV" code="Z94.0" codeSystem="2.16.840.1.113883.6.3"
displayName="Lungenentzündung" codeSystemName="ICD10"/>
CO (Sortierbarer kodierter Wert – Coded Ordinal)Dieser Datentyp spezifiziert ein Konzept über einen Code und das Codesystem (die Tabelle) aus dem der Code stammt. Der einzige Unterschied zwischen dem CO-Datentyp und dem CV-Datentyp ist der Fakt, dass die Konzepte, die im CO Datentyp aufgenommen sind, eine bestimmte Sequenz haben und sortiert werden können. Siehe Beschreibung von CV, für eine Beschreibung der Verwendung des CO-Datentyps in Deutschland. XML Beispiele <value xsi:type="CO" code="4" codeSystem=.../>
<value xsi:type="CO" code="HHPOS" codeSystem=.../>
CS (Einfacher Code – Coded Simple)Dieser Datentyp spezifiziert ein Konzept über einen Code aus einem vordefinierten Codesystem (die Tabelle), aus dem der Code stammt. Dieser Datentyp wird häufig verwendet, wenn feste, HL7 definierte Tabellen, benutzt werden.
XML-Beispiele <Observation classCode="OBS" moodCode="EVN"/>
<statusCode code="active"/>
II (Objekt Identifikation – Instance Identifier)Dieser Datentyp spezifiziert Identifikationen von Objekten. Dazu gehören beispielsweise Identifikationen für Organisationen oder Personen. Ein Attribut des II Datentyp enthält eine weltweit eindeutige Identifikation eines Objekts. AttributeAttribute eines Elements mit diesem Datentyp sind:
Ein ISO Object Identifier (OID) ist ein weltweit eindeutiger String, der aus Zahlen und Punkten besteht (beispielsweise "2.16.840.1.113883.3.1"). Laut ISO Definition bestehen OIDs aus Pfaden mit einer Baumstruktur, wobei die äußerst links situierte Zahl als root und die äußerst rechts situierte Zahl als leaf (ein Blatt als Endpunkt) bezeichnet werden. Die Nummer ist garantiert weltweit eindeutig, weil das Ausgabesystem auf dem System der delegierten Verantwortlichkeit basiert. Jeder Zweig unter einem root in der Baumstruktur korrespondiert mit einer Domäne, in der eine Organisation die Abgabe von OIDs verwaltet. Die zentralen Vergabestelle für OIDs im Gesundheitswesen in Deutschland publiziert eine Tabelle mit OIDs. Informieren Sie sich bei Zweifel bei der zentralen Vergabestelle, welche (eventuell neu zu registrierende) OID benutzt werden muss. Im OID Konzept für das Deutsche Gesundheitswesen [oidk] finden Sie nähere Informationen über Codiersysteme und OIDs.
Optional. Eine eindeutige Zeichenkette im Kontext des Identifikationssystems, das definiert wird in der root. Ein Attribut des Datentyps II muss in der deutschen Situation mindestens aus einem @root-Attribut oder aus einer Kombination von @root und @extension bestehen (z.B. root = “1.2.528.4.5” mit extension “22”). Mindestens die Angabe von @root ist verpflichtend für die Identifikation von allen Objekten. Die Länge des extension String und die Benutzung von eventuellen Vorlaufnullen in der Extension, sowie deren Anzahl wird vom Verwalter des Identifikationssystem festgelegt.
XML-Beispiele<id extension="13234453645" root="2.16.840.1.113883.2.4.15.3.427.1"/>
<id extension="S12345678" root="1.2.276.0.76.4.8"/>
<id root="2.16.840.1.113883.2.4.15.3.427.1.13234453645"/>
<id extension="1234567890" root="2.16.840.1.113883.2.4.6.3" assigningAuthorityName="Innenministerium"/>
<id extension="JANS2" root="2.16.840.1.113883.2.4.7.33" assigningAuthorityName="Alfa Krankenhaus"/>
Varianten (Flavors)Der Datentyp II kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.
URL (Universal Resource Locator)Dies ist eine Telekommunikationsadresse, die nach dem Internet Standard “RFC 1738 [2]” spezifiziert ist. Die URL gibt ein Protokoll und einen Kontaktpunkt an, die für dieses Protokoll definiert sind. Bekannte Beispiele sind Telefon- und Faxnummern, E-Mail-Adressen, Hyperlink Referenzen, Datenübertragungsprotokolle (FTP) Referenzen usw. URLs haben eine Standard-Repräsentationsform wie Strings im Format scheme:address; Die bekanntesten Schemen sind in der folgenden Tabelle aufgenommen. Im Bereich address einer URL ist ein String, dessen Format durch die URL scheme bestimmt wird.
TEL (Telekommunikationskontakt – Telecommunication Address)Es gibt keinen separaten Datentyp für Telefonnummern. Dies sind lediglich die URLs, die sich auf Telekommunikationsanlagen beziehen. Details über die Definition von Telefonnummern sind definiert in den Internet “RFC 2806 [3] URLs for Telephone Calls”. Beispielsweise ist “tel:+49(221)6754-63” eine Telefonnummer und “fax:+49(221)6571412-3” eine Faxnummer. Es wird bevorzugt, die globalen, absoluten Telefonnummern mit einem “+” und der Länderkennung anzugeben. Trennungszeichen können hinzugefügt werden (zur besseren Lesbarkeit) haben aber keine Bedeutung für die Nummern. “tel:+49221675463” und “fax:+4922165714123” sind also identisch mit den vor-stehenden Beispielen. Die Nummern müssen im Falle von internationalen Telefonnummern mit einem „+“ beginnen. Die Angaben dürfen nur Ziffernzeichen 0 bis 9 nutzen sowie als visuelle Separatorzeichen nur Bindestrich –, Punkte . oder Klammern ( ) verwenden. Elemente mit diesem Datentype haben ein Attribut,
das verschiedene Zeichenkombinationen enthalten kann, die Telekommunikations-kontakte wie Telefon (tel:), Fax (fax:), E-Mail (mailto:) usw. wiedergeben.
Mit diesem use Attribut können einer oder mehrere Codes angegeben werden, um für ein System oder einen Benutzer den besten Telekommunikationskontakt für den jeweiligen Zweck anzudeuten.
Es ist möglich, die Gültigkeitsdauer eines Telekommunikationskontakts zu begrenzen. Das Element usablePeriod kann zur Angabe eines Zeitintervalls benutzt werden. XML-Beispiel <telecom value="tel:+49.40.4765342"/>
<telecom value="mailto:dialyse@centrum-hamburg.de"/>
Varianten (Flavors, Templates)Der Datentyp TEL kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.
AD (Adresse – Postal Address)Elemente dieses Datentyps haben eine Substruktur mit verschiedenen Elementen, die in einer Adresse vorkommen können. Eine Adresse wird in der HL7 Version 3 in einer Serie von Address Name Parts wiedergegeben, beispielsweise Straßenname, Stadt usw. Im original HL7 Standard ist der Datentyp AD auch als so genannter “mixed content” zugelassen, was bedeutet, dass einige Teile der Daten von einem partType Element umschlossen werden und andere Teile nicht (Mischung aus Text und XML Elementen). Dies ist in Deutschland nicht zugelassen. Der Datentyp für alle Address Name Parts ist SC. Momentan ist Country das einzige Element, bei dem wir Codes zulassen.
Die Codes für Postadressen werden definiert von der HL7 Domäne PostalAddressUse, angegeben im “use” Attribut des addr Mutterelements (siehe Beispiele).
Für Adressdaten von Patienten sind die Attributwerte HP, WP, PST, PHYS zugelassen, für Organisationen WP, PHYS, PST und für Ärzte WP. XML-Beispiele <streetName>An der Garnbleiche</streetName>
<addr>
<postalCode>52349</postalCode>
</addr>
<addr use="WP">
<streetName>An der Garnbleiche</streetName>
<houseNumber>16</houseNumber>
<postalCode>52349</postalCode>
<city>Düren</city>
</addr>
<addr use="HP">
<streetAddressLine>Burgweg 42</streetAddressLine>
<postalCode>51371</postalCode>
<city>Leverkusen</city>
</addr>
<addr>
<country code="DE" codeSystem="1.0.3166.1.2.2">Deutschland</country>
</addr>
Varianten (Flavors)Der Datentyp AD kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.
PN (Personenname – Person Name)Der Datentyp PN wird verwendet, um den Namen einer Person darzustellen. Attribute
Struktur: Der Daten-Typ PN ist eine Extension des Daten-Typs EN (Entity Name) und besitzt folglich einen sogenannten ‘mixed content’, wobei im Prinzip Freitext mit name parts kombiniert werden kann. Für Deutschland gilt, dass die Verwendung von ‘mixed content’ bei Personennamen begrenzt ist. Zugelassen sind:
XML Beispiele <name>Jan Meier</name>
Der Name wurde ohne interne Struktur übermittelt. <name>
<given>Jan</given>
<family>Meier</family>
</name>
Die beiden Bestandteile des Namens werden benannt und erhalten einen qualifier: “Jan” ist ein ‘Name, der bei der Geburt gegeben wurde’, bzw. ein Vorname (voll ausgeschrieben). “Meier” ist ein ‘Familienname, der bei der Geburt empfangen wurde’, bzw. der eigene Nachname. <name>
Jan <family>Meier</family>
</name>
Dies ist kein gültiger Personenname, da Freitext mit einem name part kombiniert wurde.
XML-Beispiele Der reguläre Name als default, also kein use Attribut <name>
<!-- ... -->
</name>
Ein Pseudonym eines Patienten <name use="A">
<!-- ... -->
</name>
Der gesetzlich registrierte Name <name use="OR">
<!-- ... -->
</name>
Der geführte Name stimmt exakt mit dem gesetzlich registrierten Namen überein <name use="OR L">
<!-- ... -->
</name>
Dieses Element von Person Name kann verwendet werden, um anzugeben, dass im Leben einer Person einmal oder mehrmals eine Namensänderung stattgefunden hat. Dies geschieht u.a bei:
Zu beachten ist, dass viele Patientenerfassungssysteme keine wirkliche Historie (mit Anfangsdatum) der Patientennamen führen. Wohl wird häufig ein allgemeines ‘audit trail’ (Änderungshistorie) der Patientendaten geführt. Im Bedarfsfall könnte daraus die Historie des Personennamens abgeleitet werden, obwohl es natürlich auch möglich ist, nur den aktuellen Namen durchzugeben (also kein validTime zu verwenden). Der aktuelle Name ist gültig seit dem 12. Juli 2005 <name>
<validTime>
<low value="20050712"/>
</validTime>
<!-- ... -->
</name>
Obenstehende Situation kann z.B. bei einem System vorkommen, das nur den aktuellen Namen übermittelt, aber auch die Historie führt. Die oben genannte Person kann z.B. am 12. Juli geheiratet haben und dabei den Namen des Partners angenommen haben. Alte Namen plus aktueller Name <name>
<validTime>
<high value="19850412"/>
</validTime>
<!-- “Nicole de Vries” als Name des Babys vor der Adoption -->
</name>
<name>
<validTime>
<low value="19850413"/>
<high value="20050824"/>
</validTime>
<!-- “Nicolette Scheick” als Name nach der Adoption, aber vor Eheschließung -->
</name>
<name>
<validTime>
<low value="20050825"/>
</validTime>
<!-- “Nicolette Scheick-Jansen” als Name nach der Eheschließung -->
</name>
In vorstehendem Beispiel wird das Baby Nicole de Vries von der Familie Scheick adoptiert, wobei sich also ihr Nachname ändert. Weil den Adoptiveltern dieser Name besser gefällt, wird auch ihr Vorname (oder auf jeden Fall ihr Rufname) geändert in Nicolette. Nach ihrer Eheschließung nimmt sie den Nachnamen ihres Partners (Jansen) an. Das sendende System sendet in diesem Fall die gesamte Namenshistorie mit.
Ein delimiter muss immer an der Stelle in Person Name stehen, an der man auch den Text schreiben würde. Es gibt keine impliziten Leerstellen. Wenn man also normalerweise eine Leerstelle davor oder dahinter schreibt, muss diese explizit angegeben werden. Beispiele von delimiters in Person Names sind:
Diese könnten folgendermaßen in einem Person Name XML Nachrichtenelement benutzt werden: Trennung zwischen Partnername und Geburtsname <name>
<family qualifier=”SP”>Jansen</family>
<delimiter>-</delimiter>
<family qualifier=”BR”>Scheick</family>
</name>
Trennung zwischen Nachnamen und akademischem Titel <name>
<family>Jansen</family>
<delimiter>, </delimiter>
<title qualifier="AC">MSc</family>
</name>
Weitere allgemeine Beispiele finden Sie am Ende dieses Abschnitts.
Einige Regeln in Bezug auf person name parts des Typen family:
XML-Beispiele Jan Meier <name>
<given>Jan</given>
<family qualifier=”BR”>Meier</family>
</name>
Nicolette Jansen-Scheick <name>
<given>Nicolette</given>
<family qualifier=”SP”>Jansen</family>
<delimiter>-</delimiter>
<family qualifier=”BR”>Scheick</family>
</name>
Einige Regeln für person name parts des Typen given:
XML-Beispiele Hans Jansen, ohne qualifier <name>
<given>Hans</given>
<family>Jansen</family>
</name>
Johannes Theodorus Cornelis Jansen, offizielle Vornamen <name>
<given qualifier=”BR”>Johannes Theodorus Cornelis</given>
<family>Jansen</family>
</name>
Johannes Theodorus Cornelis Jansen, mit Rufname Hans <name>
<given qualifier=”BR”>Johannes Theodorus Cornelis</given>
<given qualifier=”CL”>Hans</given>
<family>Jansen</family>
</name>
Johannes Th. C. Jansen, ohne Duplizierung des Anfangsbuchstabens ‘J’ <name>
<given qualifier=”BR”>Johannes</given>
<given qualifier=”IN”>Th.C.</given>
<family>Jansen</family>
</name>
Kai Uwe Heitmann, Kai ist sowohl offizieller Name als auch Rufname <name>
<given qualifier=”BR CL”>Kai</given>
<given qualifier=”BR”>Uwe</given>
<family>Heitmann</family>
</name>
Das Fazit dieser Beispiele ist, dass diverse Kombinationen von offiziellen Vornamen, Rufnamen und Initialen möglich sind, abhängig von den Speicher- und Kommunikations-kapazitäten des sendenden Systems. Die Bedeutung der einzelnen Bestandteile muss allerdings deutlich sein.
Einige Regeln für person name parts des Typen prefix:
Die Art der Vorsilbe kann zudem angedeutet werden, indem man das optionale Attribut qualifier benutzt. Siehe Tabelle für die dabei zugelassenen Werte.
XML Beispiele Monique van Wijk <name>
<given>Monique</given>
<prefix qualifier=”VV”>van </prefix>
<family>Wijk</family>
</name>
Dr. Kai Heitmann <name>
<prefix qualifier=”AC”>Dr. </prefix>
<given>Kai</given>
<family>Heitmann</family>
</name>
In diesem Fall lautet die Regel also, dass der Grad (‘Dr.‘) vor dem kompletten Namen positioniert wird, weil dies die normale Schreibweise ist. Berend-Jan Baron von Fürst zu Fürst <name>
<given>Berend-Jan</given>
<prefix qualifier=”NB”>Baron </prefix>
<prefix qualifier=”VV”>von </prefix>
<family>Fürst zu Fürst</family>
</name>
In diesem (realen) Beispiel steht der Titel (‘Baron‘) zwischen dem Vornamen und dem Nachnamen, da dies die gebräuchliche Schreibweise ist. Zudem steht eine ‘normale’ Vorsilbe vor dem Nachnamen (‘von‘). Übrigens wird die Software häufig nicht in der Lage sein, einen (einzeln gespeicherten) Titel an die richtige Stelle zu setzen, wodurch ‘Baron‘ auch vornan landen kann. Sehr geehrter Herr Dr. Frank Düren <name>
<prefix qualifier=”TITLE”>Sehr geehrter Herr </prefix>
<prefix qualifier=”AC”>Dr. </prefix>
<given>Frank</given>
<family>Düren</family>
</name>
In diesem Beispiel hat das versendende System offensichtlich den vollständigen Titel festgelegt (oder vom Titel ableitet) und als Teil des ‘Korrespondenznamen’ übermittelt. Aber auch ohne Titel kann das versendende System eine allgemeine Anrede mitsenden (siehe nachstehend). Frau A. Jansen <name>
<prefix qualifier=”TITLE”>Frau </prefix>
<given>A.</given>
<family>Jansen</family>
</name>
Die Art der Nachsilbe kann ferner angegeben werden durch die Anwendung des optionalen Attributs qualifier. Siehe die Tabelle für die dabei zugelassenen Werte.
XML-Beispiele Ronald Cornet, MSc <name>
<given>Ronald</given>
<family>Cornet</family>
<delimiter>,</delimiter>
<suffix qualifier=”AC”>MSc</suffix>
</name>
Varianten (Flavors, Templates)Der Datentyp PN kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.
ON (Organisationsname – Organization Name)Definition: Ein Name einer Organisation. Attribut:
Der Datentyp ON ist eine Extension des Datentyps EN (Entity Name) und besteht demnach aus dem so genannten ‘mixed content’ Inhalt, in dem im Prinzip name parts angegeben werden können. Für Deutschland wurde vorläufig abgesprochen, keine organization name parts zu verwenden und den Namen immer als ein Text auszudrucken. Das heißt, dass ON in Deutschland faktisch identisch wird mit dem Datentyp TN (Trivial Name). XML-Beispiel minimal <name>Universität zu Köln</name>
Beachten Sie, dass der Text des Namens ohne Anführungszeichen übermittelt wird.
Im Prinzip kann von jedem Organization Name angegeben werden, in welcher Situation dieser benutzt werden kann. Für Deutschland wurde aber beschlossen, dass der Unterschied (noch) nicht relevant ist, so dass die Empfehlung lautet, das Attribut use nicht im XML-Tag zu benutzen.
Dies ist ein optionales XML Element in Organization Name, das die Periode angibt, in der dieser Name für die betreffende Organisation ‘in Gebrauch’/gültig war. Die Optionen sind:
XML-Beispiele Unter- und Obergrenze: Der Name war gültig vom 1.1.2003 bis vor dem 31.12.2004. <name>
<validTime>
<low value="20030101"/>
<high value="20041231"/>
</validTime>
Medizinische Einrichtungen der Universität zu Köln
<!-- der alte Name der Organisation -->
</name>
Nur Untergrenze: Der Name ist gültig seit dem 13.1.2005. <name>
<validTime>
<low value="20050113"/>
</validTime>
Klinikum der Universität zu Köln
</name>
Nur Obergrenze: Der Name ist gültig bis zum (und ausschließlich dem) 31.12.2005. <name>
<validTime>
<high value="20051231"/>
</validTime>
Medizinische Einrichtungen der Universität zu Köln
</name>
Sowohl die Untergrenze als auch die Obergrenze von validTime können in der Zukunft liegen, um einen geplanten neuen Namen oder ein geplantes Verfallsdatum für einen bestehenden Namens anzugeben.
Wiederholter Name <name>
<validTime>
<high value="20041231"/>
</validTime>
Altorganisation
</name>
<name>
<validTime>
<low value="20050101"/>
<high value="20091231"/>
</validTime>
Jetzorganisation
</name>
<name>
<validTime>
<low value="20100101"/>
</validTime>
Zukunftsorganisation
</name>
QTY (Quantität – Quantity)Quantität ist ein abstrakter Datentyp. Er wird benutzt, um die Basiseigenschaften abgeleiteter Typen zu definieren. Diese Abstraktion ist erforderlich, um andere Datentypen definieren zu können, wie z.B. Integer, Physical Quantity etc.
INT (Ganze Zahl – Integer number)Elemente dieses Datentyps haben ein Attribut,
das ganze Zahlen (Integer) annehmen kann. Integer können als solche in den Nachrichten vorkommen, beispielsweise die Anzahl der Wiederholungen einer Verordnung (repeatCount) und die sequenceNumber in einem wiederholbaren actRelationship. Im allgemeinen gilt, dass Integer zum Zählen, bzw. Ordnen verwendet wird. XML-Beispiel <number value="24"/>
REAL (Zahl mit Dezimalen – Real number)Der Datentyp Real kann eine Zahl mit Dezimalen als Wert annehmen. Die dezimale Wiedergabe mit einem Punkt „.“. Der Typ REAL kommt als solcher nicht in Nachrichten vor. Ein REAL ist immer Bestandteil eines anderen Typs, meistens Physical quantity (PQ).
PQ (Quantitative Angabe physikalischer Größen – Physical Quantity)Elemente dieses Datentyps sind physikalische Größen, d.h. eine Menge, die einen messbaren (oder zählbaren) Wert aus dem physikalischen Umfeld wiedergibt. Das ist also etwas anderes als nur eine ‘Anzahl’, da es auch um eine (natürliche) Einheit geht, worin der festgelegte Wert ausgedrückt wird. Beispiele:
Elemente dieses Datentyps haben die folgende Struktur: Das Attribut value trägt die Größe der Menge, ausgedrückt in der Einheit (unit):
Eine vollständige Beschreibung der möglichen Einheiten finden Sie in der Spezifikation des Unified Code for Units of Measure (UCUM), die in HL7 v3 aufgenommen ist. UCUM ist eine Sammlung von atomaren Einheiten und Präfixen mit der dazugehörigen Grammatik zum Aufbau gültiger Kombinationen. Wenn ein nullFlavor Attribut vorhanden ist, dürfen value und unit nicht vorkommen; Wenn kein nullFlavor Attribut vorhanden ist, muss ein value und unit spezifiziert werden. Eine alternative Repräsentation mit derselben physikalischen Menge, ausgedrückt in einer anderen Einheit, eventuell aus einem anderen System als UCUM und eventuell mit einem anderen zugehörigen Wert (value) kann unter translation wiedergegeben werden:
XML-Beispiele Messwert mit UCUM Einheit (165 cm) <value value="165" unit="cm"/>
Messwert mit UCUM Einheit (92,1 kg) <value value="92.1" unit="kg"/>
Messwert mit UCUM Einheit (Blutdruck 120 mm Hg) <value value="120" unit="mm[Hg]"/>
Messwert z. B. Stück (5) <value value="5" unit="1"/>
Messwert mit alternativer Repräsentation (2 [Stück], in HL7 V3 mit Einheit „1“, übersetzt in zwei alternative Einheiten [niederländische WCIA Tabelle 25 Dosiereinheit und G-Standard Thesaurus 002 Dosiereinheit]) <doseQuantity>
<center value="2" unit="1">
<translation value="2" code="245"
codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
displayName="Stück"/>
<translation value="2" code="100"
codeSystem="2.16.840.1.113883.2.4.4.1.361"
displayName="Tablette"/>
</center>
</doseQuantity>
MO (Geldbetrag – monetary amount)Elemente dieses Datentyps haben zwei Attribute:
Währungen werden codiert nach ISO 4217:
XML-Beispiel <value xsi:type="MO" currency="EUR" value="97.32"/>
TS (Zeitpunkt – timestamp)Elemente dieses Datentyps haben ein Attribut
XML-Beispiele 14. Juni 1970 <effectiveTime value="19700614"/>
12. April 2004, 12:45 Uhr <effectiveTime value="200409091245"/>
Das Jahr 1996 <effectiveTime value="1996"/>
24. September 2005, 17:32:45 Uhr <effectiveTime value="20050924173245"/>
Mai 2000 <effectiveTime value="200005"/>
BAG BagEinige Attribute tragen den Datentyp BAG<T> mit T als diskreten oder kontinuierlichen Datentyp. Dies ist eine ungeordnete Sammlung von Werten, wobei Werte auch mehr als einmal vorkommen können.
SET SetEinige Attribute tragen den Datentyp SET<T> mit T als diskreten oder kontinuierlichen Datentyp. Dies ist eine ungeordnete Sammlung von Werten, wobei Werte maximal ein-mal vorkommen können.
SXCM Set ComponentEs gibt ein generisches Set Component, das eine Komponente eines diskreten oder kontinuierlichen Datentyps repräsentiert und als Teil einer Menge fungiert. In Deutschland wird dies momentan ausschließlich beim Datentyp GTS angewendet (siehe GTS).
IVL IntervallIn der deutschen Situation werden momentan die folgenden Intervalldefinitionen benutzt. Intervalle sind nur für Datentypen mit einem Ordinal- oder Intervall-Skalentyp definiert. Es gibt verschiedene Möglichkeiten, ein Intervall festzulegen (siehe nachstehende Abbildung): Hier wird beispielsweise
angegeben. Es spricht für sich, dass es noch mehr Möglichkeiten gibt. Ein Intervall muss auch nicht immer vollständig spezifiziert werden (offene Intervalle). So kann beispielsweise mit nur einer Obergrenze eine maximale Dosis angegeben werden. Aus Implementierungsgründen sind in der deutschen Situation ausschließlich die nachstehenden Kombinationen zur Angabe eines Intervalls zugelassen:
Für die Datentypen IVL_TS, IVL_INT und IVL_PQ sind Intervallspezifizierungen definiert.
IVL_TS (Zeitintervall – Interval of Timestamps)Elemente dieses Datentyps geben Zeitintervalle an. Dabei wird normalerweise eine Ober- und eine Untergrenze als Zeitpunkt angegeben. Bei offenen Zeitintervallen (beispielsweise ab Zeitpunkt X, oder gültig bis Zeitpunkt Y) wird lediglich eines der beiden Element angegeben.
Enthält den Anfangszeitpunkt eines Zeitintervalls. In Deutschland gibt es nur zwei Möglichkeiten, low anzuwenden: entweder individuell (wenn der Endzeitpunkt des Intervalls unbekannt ist), oder zusammen mit high. Low wird in Deutschland nie zusammen mit width oder center benutzt. Der bei low angegebene Wert wird standardmäßig interpretiert als "ein Anfangszeitpunkt später als, oder gleich mit". Zu beachten ist, dass die Interpretation u.a. von der Präzision des Zeitpunkts abhängt:
Enthält den Endzeitpunkt eines Zeitintervalls. In Deutschland gibt es nur zwei Möglichkeiten, high anzuwenden: entweder individuell (wenn der Anfangszeitpunkt des Inter-valls unbekannt ist), oder zusammen mit low. High wird in Deutschland nie in zusammen mit width oder center benutzt. Der bei high angegebene Wert wird standardmäßig als "ein Endzeitpunkt vor oder gleich mit" definiert. Indem explizit angegeben wird, dass die Obergrenze nicht inklusiv ist, kann dies verändert werden in "ein Zeitpunkt vor". Dies wird mit dem Attribut
angegeben und kann sowohl in einem <low> als auch in einem <high> Element benutzt werden. Wenn dies nicht spezifiziert ist, wird “true” als Default angenommen. Zu beachten ist, dass die Interpretation u.a. von der Präzision des Zeitpunkts abhängt:
Enthält den Zeitpunkt, der den Mittelpunkt des Zeitintervalls kennzeichnet. In Deutschland wird dies ausschließlich benutzt, wenn man (in einem Attribut des Datentyps IVL<TS> einen spezifischen Zeitpunkt angeben will, anstatt eines Zeitintervalls. Center wird in Deutschland nie zusammen mit low, high, oder width benutzt. Zu beachten ist, dass die Interpretation u.a. von der Präzision des Zeitpunkts abhängt:
Enthält die Zeitdauer des Intervalls. In Deutschland wird dies ausschließlich benutzt, wenn low, high und/oder center bei einem Intervall nicht bekannt ist, sondern nur die Dauer. width wird in Deutschland nie zusammen mit low, high, oder center benutzt. XML-Beispiele Am und später als der 7. Mai 2004 bis ausschließlich 9. September 2004 <effectiveTime>
<low value="20040507"/>
<high value="20040909"/>
</effectiveTime>
Am und später als der 7. Mai 2004 <effectiveTime>
<low value="20040507"/>
</effectiveTime>
Am (während des) 3. Januar 1975 <value>
<center value="19750103">
</value>
In (während) 2003 <value>
<center value="2003">
</value>
Am und nach dem 3. Januar 1975, aber vor dem 7. Januar 1975 <value>
<low value="19750103">
<high value="19750107">
</value>
IVL_INT (Intervall von Integer – Interval of Integers)Elemente dieses Datentyp geben Intervalle von Integer (ganze) Zahlen an. Dabei wird in der Regel eine Ober- und eine Untergrenze als Zahl angedeutet. Bei offenen Intervallen (beispielsweise bei der Ausgabe einer Wiederholung “maximal 3 Mal wiederholen”) wird nur eines der beiden Elemente angegeben.
von 3 bis einschl. 5 <repeatNumber>
<low value="3"/>
<high value="5"/>
</repeatNumber>
maximal 5 <repeatNumber>
<high value="5"/>
</repeatNumber>
IVL_PQ (Intervall bei physikalischen Mengen – Interval of Physical Quantities)Elemente dieses Datentyps geben Intervalle bei physikalischen Mengen an. Dabei wird in der Regel eine Ober- und eine Untergrenze als value unit Paar angedeutet.
XML-Beispiel Zwischen 7,5 und 10 mmol/l. Bemerkung: 10.1 gehört nicht mehr zum Intervall, die Grenze ist exakt 10. <referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>
RTO (Verhältnisangaben zweier Daten – ratio)Elemente dieses Datentyps haben zwei Sub-Elemente, den Zähler (numerator) und den Nenner (denominator) eines Vergleichs (ratio). Der QTY (quantity) Datentyp ist ein abstrakter Datentyp, der in Nachrichten durch einen spezifischen Datentyp ersetzt wird, häufig PQ oder TS. Die relevanten Strukturelemente sind:
Die Menge, die in der Ratio geteilt wird. Der Defaultwert ist der Integer 1.
Die Menge, durch die der numerator in der Ratio geteilt wird. Der Defaultwert ist der Integer 1. Der denominator darf nicht den Wert 0 haben. Der denominator ist häufig eine Zeiteinheit. XML-Beispiele 6 (mal/Stück) pro (ein) Tag <maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>
400 Milligramm pro (ein) Tag <maxDoseQuantity>
<numerator xsi:type="PQ" value=’400’ unit=’mg’/>
<denominator xsi:type="PQ" value=’1’ unit=’d’/>
</maxDoseQuantity>
5 mal pro (eine) Stunde <maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>
1:10000 beispielsweise bei epidemiologischen Daten oder bei Laborbefunden <value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
GTS – Der generische Zeit DatentypNachstehend wird der GTS Datentyp (General Timing Specification oder generische Zeitangabe) beschrieben, wobei ausschließlich die Aspekte beschrieben werden, die auf die deutsche Situation zutreffen. Falls es spezifische Anweisungen gibt, wie etwas in Deutschland implementiert werden muss, wird dies im Text angegeben. Der Datentyp GTS bietet eine sehr umfangreiche (aber auch komplexe) Struktur für die Angabe von Zeitpunkten, Zeitintervallen und Zeitschemas mit einem praktisch unbegrenzt komplexen Aufbau an. Die Analyse von GTS ist ein Thema für sich, aber zum Glück lassen sich die meisten Anwendungen mit einem limitierten Set an GTS Funktionen, wie TS und IVL_TS beschreiben. Simpel gesagt ist ein GTS ein SET<TS>. Diese können zu periodischen Sets zusammengefügt werden und durch Set-Operationen ist es möglich, auch komplexe Zeitangaben zu spezifizieren. Das folgende Schema zeigt zur Illustration eine Zeitangabe am Beispiel einer Instruktion zur Arzneiverabreichung “an geraden Tagen (Beginn am Tag 0, dem ersten Tag, an dem die Arznei verabreicht wird), wochentags von Mo. bis Fr.” als ein Set von Tagen. Das Set der Wochentage (erste Reihe) wird mit einem zweiten Set, das als Zeitintervall der Tage von Mo. bis Fr. definiert ist, geschnitten. Daraus ergibt sich die dritte Reihe. Diese wird mit einem Set von geraden Tagen geschnitten, wodurch schließlich Reihe fünf mit dem gewünschten Ergebnis entsteht. Es sind verschiedene XML Repräsentationen eines Elements mit dem Typen GTS denkbar, aber in Deutschland hat ein vollständiges Element des Typen GTS immer folgendes Format: Das XML Element effectiveTime wird als SXPR_TS (parenthetic set expression des Typen TS) definiert und die Set-Komponenten <comp> werden als Kindelemente zugefügt. Das bedeutet, dass im XML Element die Set- Komponente Elemente benutzt wird. Bei XML hat ein GTS Datentyp also immer das folgende Muster: <effectiveTime xsi:type="SXPR_TS">
<comp xsi:type="…">
…
</comp>
<comp xsi:type="…" operator="A">
…
</comp>
<effectiveTime/>
Als Set-Komponenten sind die Datentypen PIVL (periodic interval of time oder periodisches Zeitintervall) und EIVL (event related interval of time oder ereignisbezogenes Intervall) zugelassen. In Deutschland wird zurzeit nur PIVL benutzt. Eine Set-Komponente wird über die Angabe xsi:type als Datentyp PIVL_TS, IVL_TS oder TS definiert. Für die Set-Komponenten sind Operatoren verfügbar (siehe auch vorstehendes Beispiel für die Set-Operationen), welche die verschiedenen Komponenten zusammen-setzen können: die Vereinigung mit dem vorigen Zeitschema, die Differenz mit dem vorigen Zeitschema oder den Durchschnitt mit dem vorigen Zeitschema (siehe nachstehend unter PIVL für eine nähere Erläuterung). <effectiveTime xsi:type="SXPR_TS">
<comp xsi:type="IVL_TS">
<!-- eine normale Intervallangabe -->
</comp>
<comp xsi:type="PIVL_TS" operator="A">
<!-- periodische Intervallangaben (hier mit einem Operator zwischen zwei Sets) -->
</comp>
<effectiveTime/>
Weil GTS eine Superklasse für alle Zeitangaben in HL7 ist, kann von einem Element des Datentyps GTS in einer XML Instanz beispielsweise auch ein Intervall erstellt werden, indem man das xsi:type XML Attribut anwendet. Gesetzt den Fall, dass effectiveTime als GTS in einem Modell definiert ist, dann enthalten die folgenden XML Instanzen ausnahmslos gültige Zeitangaben. <effectiveTime xsi:type="IVL_TS">
<low value="20050924"/>
<high value="20050925"/>
</effectiveTime >
<effectiveTime xsi:type="SXPR_TS">
<comp xsi:type="IVL_TS">
<low value="20050901"/>
<width value="90" unit="d"/>
</comp>
<comp xsi:type="PIVL_TS" operator="A">
<period value="2" unit="d"/>
</comp>
<effectiveTime/>
PIVL (Periodisches Zeitintervall – Periodic Interval of Time)Definition: Ein Zeitintervall (oder Zeitpunkt) das/der sich periodisch wiederholt. Attribute
Elemente
StrukturDer Datentyp PIVL ist eine Erweiterung des Datentyps SXCM (Set Component) und gilt daher als ein Teil einer Menge. In diesem speziellen Fall setzt sich eine solche Menge aus Zeitspezifikationen zusammen, die gemeinsam die Beschreibung eines bestimmten Zeitschemas darstellen. Die Zeitspezifikationen werden dabei zusammengesetzt mit Operatoren (Set Operators), wie ‘Vereinigung’, ‘Differenz’ und ‘Durchschnitt’. Ohne Beispiele ist das schwierig zu erklären. Deshalb wird dies nachstehend anhand ausführlicher Beispiele demonstriert. AnwendungNachrichtenelemente mit dem Datentyp PIVL kommen ausschließlich als Teil des (abstrakten) Datentyps GTS vor. General Timing Specification nutzt eine sehr allgemeine Methode zur Darstellung von Zeitschemas und besteht grundsätzlich aus einer Menge zusammengesetzter Komponenten. Eine der wichtigsten Komponentenarten ist der Datentyp PIVL. Hiermit werden Zeitphasen angegeben, die sich wiederholen, wie z.B. ‘2x täglich’, oder ‘alle 2 Wochen Montags von 10:00 bis 10:30’. XML-Beispiele 2x täglich <comp xsi:type="PIVL_TS">
<period value="0.5" unit="d"/>
</comp>
Alle 2 Wochen Montags von 10:00 bis 10:30 <comp xsi:type="PIVL_TS" alignment="DW">
<phase>
<low value="200508291000"/>
<width value="30" unit="min"/>
</phase>
<period value="2" unit="wk"/>
</comp>
Anmerkung: In den beiden vorstehenden Beispielen hat das Nachrichtenelement den Namen <comp>. Damit wird angegeben, dass es sich um Elemente binnen des Datentyps SXPR (Paranthectic Set Expression) handelt. Das ist die Form, in der PIVL meistens vorkommt. Nähere Erläuterungen zu SXPR finden Sie unter Datentyp GTS (General Timing Specification) an anderer Stelle in diesem Dokument.
Wie gesagt fungiert PIVL als Teil einer Menge Komponenten. Wenn diese Komponenten zusammengesetzt werden, ergibt sich ein Zeitschema. Dies lässt sich am besten anhand praktischer Beispiele erklären. Beispiel: Ein Rezept hat eine Gültigkeitsdauer von 90 Tagen ab 1.9.2005 (d.h. die geplante Verabreichungsperiode läuft vom 1.9.2005 bis einschl. 29.11.2005). Das Attribut effectiveTime in der Gebrauchsanweisung besitzt den Datentyp GTS und besteht aus einer Menge des Datentyps SXPR_TS (Paranthetic Set Expression), die mit dem Intervall zwischen diesen beiden Daten beginnt. Es handelt sich also um eine Menge, die ein IVL_TS enthält. XML-Beispiele Geplante Verabreichungsperiode <effectiveTime xsi:type="SXPR_TS">
<comp xsi:type="IVL_TS">
<low value="20050901"/>
<width value="90" unit="d"/>
</comp>
<effectiveTime/>
Bemerkung: In vorstehendem Beispiel kommt der Datentyp PIVL selbst noch gar nicht vor, aber es soll deutlich machen, wie der Operator im PIVL benutzt wird, um die Menge zu definieren. Siehe auch die Beschreibung des allgemeinen Datentyps GTS. Angenommen, dass in der betreffenden Periode alle 2 Tage eine Arznei verabreicht werden muss. De facto muss dann der Durchschnitt des angegebenen Intervalls genommen werden, sowie ein sich periodisch wiederholendes ‘Etwas’, von nur bekannt ist, dass es alle 2 Tage stattfindet. Alle 2 Tage innerhalb des angegebenen Intervalls <effectiveTime xsi:type="SXPR_TS">
<comp xsi:type="IVL_TS">
<low value="20050901"/>
<width value="90" unit="d"/>
</comp>
<comp xsi:type="PIVL_TS" operator="A">
<period value="2" unit="d"/>
</comp>
<effectiveTime/>
Der Operator “A" in der vorstehend zugefügten PIVL Komponente hat die Definition: ‘Nehmen sie den Durchschnitt der zuvor angegebenen Zeiten (Intervall von 90 Tagen ab 1.9.2005) mit der Wiederholungsperiode (period) die danach angegeben wird. Das Ergebnis ist also ‘alle 2 Tage vom 1.9.2005 bis einschl. 29.11.2005’. Dies ergibt also 45 Verabreichungszeitpunkte, ohne dass genau definiert wird, an welchen Tageszeitpunkten diese Ereignisse stattfinden sollen. Die gültigen Operatoren bei PIVL_TS (und aller anderen Komponenten eines SXPR_TS) sind:
Siehe auch die allgemeine Beschreibung bei GTS über die Anwendung von set operator.
Das Element phase ist eigentlich ein Beispiel (Prototyp) eines Basisintervalls (oder Basiszeitpunkt), das im PIVL Datentyp periodisch wiederholt wird. Dabei kann in PIVL z. B. ‘täglich um 14:00’ angegeben werden, indem man den Zeitpunkt ‘14:00’ an einem willkürlichen Tag als phase andeutet und bei period angibt, dass dies sich täglich wiederholt. Das Element phase ist nicht verpflichtend, weil es auch vorkommt, dass nur eine Wiederholungsperiode angegeben werden muss und ein Basiszeitpunkt oder Basisintervall nicht nötig ist. So ist phase bei ‘alle zwei Tage’ im Beispiel weiter oben nicht nötig, weil es nicht relevant ist, an welchem Zeitpunkt innerhalb der zwei Tage das Ereignis (z.B. die Verabreichung der Arznei) stattfindet. Nachstehend finden Sie einige Beispiele von Situationen, in denen dies der Fall ist. Täglich um 8:00 <comp xsi:type="PIVL_TS">
<phase>
<center value="200509010800"/>
</phase>
<period value="1" unit="d"/>
</comp>
Zu beachten ist, dass die Tatsache, dass hier der 1. September 2005 eingetragen ist, de facto unrelevant ist! Phase ist nur angegeben, weil der Zeitpunkt 08:00 übermittelt werden muss und dient insofern als Prototyp eines solchen Zeitpunkts. Dabei muss aber ein Datum angegeben werden, weil die Übermittlung eines separaten Zeitpunkts in der HL7 Version 3 (Datentyp TS) nicht möglich ist. Es hätte dort also auch <center value="198812040800"> stehen können, woraus die Verarbeitungssoftware exakt die gleiche Schlussfolgerung ziehen muss (täglich um 08:00). Zu beachten ist auch, dass phase immer die Form eines Intervalls hat (Datentyp IVL_TS). Wenn also ein separater Zeitpunkt (oder ein separater Tag) angegeben werden muss, geschieht dies am besten, indem man das Element <center> von IVL_TS anwendet. Damit wird das Intervall praktisch auf einen Zeitpunkt reduziert, behält aber die Struktur von IVL. Täglich um 8:00, während 10 Minuten <comp xsi:type="PIVL_TS">
<phase>
<low value="200509010800"/>
<width value="10" unit="min"/>
</phase>
<period value="1" unit="d"/>
</comp>
Der einzige Unterschied zu dem vorigen Beispiel ist, dass phase jetzt ein ‘echtes’ Intervall ist, anstatt ein einfacher Zeitpunkt. Dies ist z.B. der Fall, wenn eine Arzneiverabreichung, eine physiotherapeutische Behandlung oder eine andere Aktivität in einer bestimmten Zeitspanne ausgeführt werden muss. Dies kann auch vorkommen, wenn der Zeitpunkt im Grunde nicht relevant ist: Täglich, während 10 Minuten <comp xsi:type="PIVL_TS">
<phase>
<width value="10" unit="min"/>
</phase>
<period value="1" unit="d"/>
</comp>
In diesem Beispiel ist von phase nur noch die Dauer (width) relevant.
Das Attribut alignment wird benutzt, um anzugeben, welcher Aspekt von phase (das Basisintervall) relevant ist zum Festlegen des Wiederholungsmusters. Das klingt in erster Instanz sehr verwirrend, bietet aber die Möglichkeit, Wiederholungsmuster, wie ‘jeden Montag’ oder ‘an jedem 14e eines Monats’ oder ‘jeden 2. Mai’ relativ einfach anzugeben. Jeden Montag <effectiveTime xsi:type="PIVL_TS" alignment="DW">
<phase>
<center value="20050829"/>
</phase>
<period value="1" unit="wk"/>
</effectiveTime>
Das alignment ‘DW’ gibt hier an, dass der relevante Aspekt der angegebenen phase ‘day of the week’ is. Angesichts der Tatsache, dass 29.8.2005 ein Montag war, steht hier also nichts anderes wie ‘jeden Montag’. Wie bereits zuvor erwähnt, ist der exakte Wert von phase nicht relevant. Die gültigen alignment Varianten bei PIVL_TS beschränken sich in Deutschland auf:
Zu beachten ist also, dass alignment nur dann sinnvoll ist, wenn phase die Form eines einfachen Zeitpunkts oder eines Intervalls hat, die innerhalb eines Tages liegt. Jeden 15. des Monats <effectiveTime xsi:type="PIVL_TS" alignment="DM">
<phase>
<center value="20050915"/>
</phase>
<period value="1" unit="mo"/>
</effectiveTime>
Jeden 1/3 und 1/8, von 14:00 bis 16:00 <effectiveTime xsi:type="SXPR_TS">
<comp xsi:type="PIVL_TS" alignment="DY">
<phase>
<low value="200503011400"/>
<width value="2" unit="h"/>
</phase>
<period value="1" unit="a"/>
</comp>
<comp xsi:type="PIVL_TS" operator="I" alignment="DY">
<phase>
<low value="200508011400"/>
<width value="2" unit="h"/>
</phase>
<period value="1" unit="a"/>
</comp>
</effectiveTime>
Das Attribut institutionSpecified soll angeben, ob es sich bei der Wiederholungsperiode, die der PIVL Datentyp angibt, um eine ‘harte’ oder ‘weiche’ Zeitspezifikation handelt. Das bedeutet: Darf der Empfänger bei der Angabe ‘3x täglich’ selbst entscheiden, an welchen Zeitpunkten das Ereignis stattfindet oder muss dies exakt alle 8 Stunden (gleichmäßig verteilt) geschehen. Es gibt drei Gründe, weshalb dieses Attribut in Deutschland vorläufig nicht benutzt wird:
Das Element period ist in jedem Nachrichtenelement des Datentyps PIVL verpflichtend. Es gibt darin die Wiederholungsperiode des Ereignisses an, auf das es sich bezieht. Die period selbst hat den Datentyp PQ (Physical Quantity), mit der Einschränkung, dass ausschließlich Daten einer Zeitdauer benutzt werden dürfen. Das Format ist also immer: <period value=[Anzahl] unit=[Zeiteinheit] />
Die folgenden Zeiteinheiten (konform mit UCUM) müssen dabei immer unterstützt werden:
Bemerkung: Zu beachten ist, dass die Definition eines Jahres (Unit ‘a’, abgeleitet von ‘annum’) auf dem so genannten Julianischen Kalender (mit einem Jahr von exakt 365.25 Tagen) beruht. In Fällen, in denen es wichtig ist, dass ein Ereignis immer auf den gleichen Tag eines Monats oder Jahres fällt, wird das alignment Attribut benutzt, damit es keine Missverständnisse geben kann. Im einfachsten Fall kann auf diese Art und Weise z.B. angegeben werden, dass ein Ereignis (z.B. das Verabreichen einer Arznei) alle 2 Stunden auszuführen ist. Das geschieht wie folgt: Alle 2 Stunden <comp xsi:type="PIVL_TS">
<period value="2" unit="h"/>
</comp>
Bei Arzneimittelverordnungen ist es üblich, um z.B. ‘3x täglich’ als Frequenz für die Verabreichung anzugeben. Dies kann im PIVL auf zweierlei Art und Weise angegeben werden: 3x täglich, in Tagen <comp xsi:type="PIVL_TS">
<period value="0.3333" unit="d"/>
</comp>
3x täglich, in Stunden <comp xsi:type="PIVL_TS">
<period value="8" unit="h"/>
</comp>
Im zweiten Fall findet die Umrechnung also über 1 d = 24 h. statt. Weil im PIVL Datentyp keine Frequenz, sondern eine Wiederholungsperiode angewendet wird, kann ‘3x täglich’ nur in ganzen Zahlen ausgedrückt werden, also ‘alle 8 Stunden’. Gefühlsmäßig klingt letzteres strenger, aber mathematisch sind beide Angaben natürlich vollkommen äquivalent.
Ein vergleichbares Phänomen ergibt sich bei Wiederholungsperioden von mehr als einem Tag: 1x in 2 Tagen <comp xsi:type="PIVL_TS">
<period value="2" unit="d"/>
</comp>
Diese Situation ist einfach, aber schwieriger wird es bei ‘3x wöchentlich’ (zwei Möglich-keiten): 3x wöchentlich, in Wochen <comp xsi:type="PIVL_TS">
<period value="0.3333" unit="wk"/>
</comp>
3x wöchentlich, in Tagen <comp xsi:type="PIVL_TS">
<period value="2.3333" unit="d"/>
</comp>
Hier ist deutlich, dass es nicht hilft, die Einheit anzupassen an “d", da in allen Fällen auch ein Dezimalpunkt nötig ist. Die Wahl liegt auch hier bei dem sendenden System, aber jedes empfangende System muss in der Lage sein, beide Varianten zu verarbeiten. Zudem ist es möglich, eine Frequenz mit ‘2x monatlich’ anzugeben. Dazu muss angemerkt werden, dass dies keine exakte Angabe ist (aufgrund der wechselnden Anzahl Tage pro Kalendermonat), aber im PIVL kann dies folgendermaßen ausgedrückt werden: 2x monatlich <comp xsi:type="PIVL_TS">
<period value="0.5" unit="mo"/>
</comp>
oder indem die Frequenz angegeben wird mit ‘3x pro Jahr’: 3x pro Jahr <comp xsi:type="PIVL_TS">
<period value="0.3333" unit="a"/>
</comp>
Es ist allerdings wohl zugelassen, Jahre und Monate untereinander umzurechnen. Vorstehendes Beispiel könnte dann auch mit dem folgenden PIVL ausgedrückt werden: 3x jährlich, in Monaten <comp xsi:type="PIVL_TS">
<period value="4" unit="mo"/>
</comp>
Hier wird also der Umrechnungsfaktor 1 mo = 1 a/12 eingesetzt. Fakt ist, dass dieser Umrechnungsfaktor nicht so ‘hart’ ist wie der Umrechnungsfaktor zwischen Sekunden, Minuten, Stunden und Wochen. Daraus ergibt sich die folgende Tabelle mit Umrechnungsfaktoren, die unterstützt werden müssen:
Die “X" in dieser Tabelle geben Umrechnungen an, die von allen empfangenden Systemen unterstützt werden müssen. Die “+" geben Umrechnungen an, die vorzugsweise unterstützt werden müssen. Die nicht ausgefüllten Zellen geben Umrechnungen an (von gesendeten Informationen an gespeicherte Interpretation oder umgekehrt) die nicht zugelassen sind. Allgemeine BeispieleUm die kombinierte Anwendung von phase und period zu erläutern, werden nachstehend noch einige Beispiele von periodischen Ereignissen aufgeführt (z.B. bestimmte Arzneiverabreichung), die einen festen Eichpunkt und/oder eine feste Zeitdauer haben. Dies geschieht meistens in Kombination mit einer SXPR Komponente, die das Intervall angibt, in der das Ereignis stattfindet. Die vollständige effectiveTime wird dann: 3x täglich, jeweils um 06:00, 14:00 und 22:00, während 30 Min., ab 2. Sept. 2005 um 14:00 <effectiveTime xsi:type="SXPR_TS">
<comp xsi:type="IVL_TS">
<low value="200509021400"/>
</comp>
<comp xsi:type="PIVL_TS" operator="A">
<phase>
<low value="200509022200"/>
<width value="30" unit="min"/>
</phase>
<period value="0.3333" unit="d"/>
</comp>
</effectiveTime>
Die PIVL Komponente erhält hier den Operator “A", weil der Durchschnitt mit dem Intervall genommen werden muss, das zuvor bereits im IVL_TS angegeben ist (‘ab 2.9.2005’). Zu beachten ist, dass der faktische Zeitpunkt in der phase Komponente des PIVL nicht relevant ist, d.h. er ist nur der Eichpunkt für period, ist aber ansonsten willkürlich. Auf diese Art und Weise steht dort ‘3x täglich, während 30 Min.’, wobei aber wohl angegeben wird, dass dies stets um 14:00, 22:00 und 06:00 wiederholt werden muss (da 22:00 als Eichpunkt für die Wiederholung angegeben wird). In Kombination mit dem zuvor angegebenen Intervall ergeben sich die folgenden Zeitpunkte, an denen das Ereignis stattzufinden hat:
Zu beachten ist, dass wenn die Dauer der Aktivität unrelevant (oder unbekannt) gewesen wäre, die Komponente width von phase einfach hätte fehlen können. Wenn sogar die Anfangszeit unrelevant (oder unbekannt) gewesen wäre, wäre phase überhaupt nicht nötig gewesen. Das würde die nachstehenden PIVL Komponenten in dem vorgenannten Beispiel ergeben: 3x täglich, jeweils um 06:00, 14:00 und 22:00 <comp xsi:type="PIVL_TS" operator="A">
<phase>
<low value="200509022200"/>
</phase>
<period value="0.3333" unit="d"/>
</comp>
3x täglich <comp xsi:type="PIVL_TS" operator="A">
<period value="0.3333" unit="d"/>
</comp>
Schließlich ein vergleichbares Beispiel mit einer Wiederholung an zwei festen Wochentagen: jeden Mo. und Fr. um 13:00, während 4 Stunden, während Sept. 2005 <effectiveTime xsi :type="SXPR_TS">
<comp xsi:type="IVL_TS">
<low value="20050901"/>
<high value="20050930"/>
</comp>
<comp xsi:type="SXPR_TS" operator="A">
<comp xsi:type="PIVL_TS" alignment="DW">
<phase>
<low value="200508291300"/>
<width value="4" unit="h"/>
</phase>
<period value="1" unit="wk"/>
</comp>
<comp xsi:type="PIVL_TS" operator="I" alignment="DW">
<phase>
<low value="200509021300"/>
<width value="4" unit="h"/>
</phase>
<period value="1" unit="wk"/>
</comp>
</comp>
</effectiveTime>
Zu beachten ist, dass hier zwei PIVL Komponenten definiert sind, die miteinander vereinigt werden (Operator “I"). Gemeinsam wird dieses Sub-Set wieder geschnitten (Operator “A") mit dem zuvor festgelegten Intervall (‘der Monat September’). Dies ist ein Beispiel einer geschachtelten Anwendung des Datentyps SXPR, das unter GTS näher erläutert wird. Zu beachten ist auch, dass das Basisintervall des ersten PIVL (für die Wiederholung am Montag) nicht einmal innerhalb des Intervalls liegt, mit dem geschnitten wird. (29/8 wird nämlich als Eichpunkt benutzt). Die relevanten Aspekte des Eichpunkts sind nur der Wochentag (durch die Kombination mit dem alignment auf “DW") und der Anfangszeitpunkt (ab 13:00). Mit anderen Worten: PIVL beschreibt de facto jeden Montag zwischen 13:00 und 17:00, von der unendlichen Vergangenheit bis in die unendliche Zukunft. Der Durchschnitt sorgt für die Begrenzung. Alles in allem ergibt sich daraus die folgende Liste mit den durch diese Struktur definierten Zeiten:
Zum Schluss noch ein Beispiel, in dem ein bestimmtes periodisches Intervall ausgeschlossen wird: Tablettenschema 21 Tage einnehmen, 7 Tage nicht, 1x täglich um 09:00 <effectiveTime xsi :type="SXPR_TS">
<comp xsi:type="IVL_TS">
<low value="20050901"/>
<high value="20051130"/>
</comp>
<comp xsi:type="SXPR_TS" operator="A">
<comp xsi:type="PIVL_TS">
<phase>
<low value="200509010900"/>
</phase>
<period value="1" unit="d"/>
</comp>
<comp xsi:type="PIVL_TS" operator="E">
<phase>
<low value="20050922"/>
<width value="7" unit="d"/>
</phase>
<period value="28" unit="d"/>
</comp>
</comp>
</effectiveTime>
Auch hier werden zwei PIVL Komponenten definiert, wobei die Differenz zwischen der ersten und der zweiten Komponente festgelegt wird (die zweite wird dabei von der ersten subtrahiert). Gemeinsam wird dieses Sub-Set wieder geschnitten (Operator “A") mit dem zuvor festgelegten Intervall (‘die Monate September bis einschl. November’). Der Effekt ist, dass ein sich wiederholendes Muster mit der folgenden Struktur entsteht:
Die tägliche Einnahme wird durch period im ersten PIVL festgelegt. Die Woche ohne Einnahme wird durch die zweite PIVL mit einer phase von 7 Tagen festgelegt, die sich pro period von 28 Tagen wiederholt und im Muster des ersten PIVL ausgeschlossen wird. Zu beachten ist, dass es durchaus relevant ist, welches Datum als Anfangsdatum bei phase im zweiten PIVL gewählt wird. Dies muss nämlich so mit dem Anfangsdatum des Intervalls übereinstimmen (nicht unbedingt mit dem von phase im ersten PIVL!), dass die Periode ohne Einnahme stets in die 4e Woche fällt (also im Anschluss an eine Periode von 3 Wochen mit täglicher Einnahme). v3dtr1:CMETs
Referenzen[HL7V3] HL7 Version 3 Ballot 11, September 2005 Normative Edition 2005
http://www.w3.org/TR/xmlschema-0/ http://www.w3.org/TR/xmlschema-1/ http://www.w3.org/TR/xmlschema-2/ + World Wide Web Consortium. XML Schemas Part 1: Structures. http://www.w3.org/TR/xmlschema-1/ + World Wide Web Consortium. XML Schemas Part 2: Datatypes. http://www.w3.org/TR/xmlschema-2/
AnhangDieses Kapitel ist nicht normativ. HL7HL7 (Health Level Seven) ist der weltweit eingesetzte und anerkannte Kommunikationsstandard im Gesundheitswesen. Im Vordergrund stand dabei bisher der Austausch von Nachrichten, sowohl für administrative als auch klinische Belange. HL7 Version 3 [HL7V3] definiert eine neue Generation von Kommunikationsstandards für die Spezifikation, Entwicklung und Pflege von Nachrichten im gesamten Gesundheitswesen. Dies wird mit einer ausgereiften Methodik zur modell-basierten und Werkzeug-gestützten Entwicklung zugeschnittener Nachrichten erreicht. Zahlreiche Projekte wurden bereits mit HL7 Version 3 Spezifikationen erfolgreich durchgeführt. Viele europäische Länder, darunter die Niederlande, Großbritannien und Dänemark, haben HL7 Version 3 als strategisches Konzept für eine landesweite Kommunikation im Gesundheitssektor gewählt. In England wurde vom National Health Service (NHS) bereits vor zweieinhalb Jahren das GP2GP-Projekt initiiert, das sich gerade HL7 Version 3 zur Unterstützung für die Kommunikation Niedergelassener zu Nutze machte. Daraus ist mittlerweile ein nationales, staatlich stark gefördertes und deutlich ausgedehntes Projekt geworden. Auch in Deutschland ist in den zurzeit vom Gesundheitsministerium initiierten Bestrebungen rund um die elektronische Gesundheitskarte (bIT4health) aktiv HL7 Version 3 als Zieltechnologie und Kernelement sektorenübergreifender IT-Anwendungen vereinbart worden.
Hinweise zur Vergabe und Verwendung von Object Identifiern (OIDs)Identifikationen von ObjektenIn HL7 muss für jeden der beteiligten Kommunikationsteilnehmer (Systeme, die an der Kommunikation teilnehmen, sog. Devices) ein eindeutiger Object Identifier (OID) existieren [OIDK]. Das bedeutet für die Software, dass bei den Stammdaten einer jeden Senderinstanz für alle Kommunikationspartner eine eindeutige OID bekannt sein muss. Auch ein Heilberufler ist eindeutig mit einer OID zu versehen. Dabei ist zu beachten, dass ein Arzt selber in diesem Sinne nicht als Sender- oder Empfänger-Gerät auftritt, sondern als Person z. B. in der Rolle Autor. Es handelt sich also um verschiedene OIDs, sendende und empfangende Anwendungen müssen darüber hinaus auch identifizierbar sein. Eine mögliche und häufig anzutreffende Lösung ist, dass die Hersteller, die sendende Systeme installieren, die OID selbst vergeben. Dabei wird davon ausgegangen, dass jeder Hersteller über eine eigene OID verfügt. Diese wird rechts ergänzt um eine innerhalb des Unternehmens eindeutige Kennung für die jeweilige konkrete Installation (Instanz der Anwendung, bzw. Mandant). Daran angehängt werden die jeweils benötigten Kennungen für die verschiedenen mit einem Identifikator zu versehenden Objekte, wie Dokumenten-Id, Diagnosen-Id, etc. Verwenden mehrere Software-Prozesse und/oder mehrere Arbeitsplätze einer Praxis/Abteilung/Klinik denselben OID-Zähler, so muss der Zugriff auf diesen Zähler serialisiert sein. Ist dies zu aufwändig, müssen separate Zähler mit jeweils unterschiedlichem Präfix für jede parallel arbeitende Instanz eingerichtet werden.
Hierbei handelt es sich – wie gesagt – um ein Beispiel, es sind auch andere Vorgehensweisen denkbar oder in realen Implementationen zu finden. Der Hersteller hat dabei dafür Sorge zu tragen, dass jede OID nur einmal vergeben wird und bei Änderungen der Zuordnung von OIDs eine neue OID zur Anwendung kommt. Einzige Verpflichtung des Herstellers ist also, dass Objekte mit dem OID Konzept weltweit eindeutig und dauerhaft identifiziert werden können. Identifikationen von CodesystemenAuch die Nutzung der bei HL7 verpflichtend anzugebenden Codesysteme bei der Übermittlung von Codes und anderen Klassifikationen, die ebenso mittels einer OID verwaltet und in Dokumenten spezifiziert werden, stellt ggf. neue Anforderungen an die Hersteller von Software. Im Prinzip muss zu jedem verwendeten Codewert das zugehörige Codesystem im Sinne einer OID bekannt sein. Referenzen |