Version |
Date |
Status |
Realm
Dieses Dokument gibt den Implementierungsleitfaden "HL7 Version 3 Datentypen" 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 .
|
Impressum
Dieser 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.
Danksagung
Wir danken besonders
- Stichting HL7 Nederland, Veenendaal
- Nictiz, Nationaal ICT Instituut in de Zorg, Den Haag
- Verband der Hersteller von IT-Lösungen für das Gesundheitswesen, e.V. (VHitG), Berlin.
Ansprechpartner
Kai U. Heitmann
HL7-Benutzergruppe in Deutschland e.V.
Heitmann Consulting and Services
Sciphox Arbeitsgemeinschaft GbR mbH
|
Der Inhalt dieses Dokumentes ist öffentlich. Zu beachten ist, dass Teile dieses Dokuments auf dem Abstimmungspaket 11 und der Normative Edition 2005 von HL7 Version 3 beruhen, für die © HL7 Inc gilt. |
|
Disclaimer
Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann die HL7 Benutzergruppe in Deutschland keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten. |
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 .
|
Dokumenteninformation
Status
Erste Konzeptversion
|
April 2005
|
Letzte Konzeptversion
|
November 2005
|
Erste komplette Version
|
November 2005
|
Korrigierte Version
|
April/Mai 2006
|
Publikationsdokument
|
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 .
|
Datum
Erstes Release: April/Mai 2006
Wiki Release: November 2009
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 .
|
Revisionsliste (NL)
Version |
Autoren |
Inhalt |
Datum
|
0.70 |
KH |
Erster Ansatz Implementierungsleitfaden, teilweise basierend auf früheren Bearbeitungen von RS und TdJ |
2005-05-09
|
0.71 |
KH |
Anmerkungen erste und zweite Besprechung verarbeitet |
2005-05-27
|
0.72 |
MT |
Anmerkungen Einleitung |
2005-06-08
|
0.73 |
KH |
Anmerkungen dritte Besprechung verarbeitet |
2005-06-24
|
0.80 |
KH |
Korrekte Sequenz, Bearbeitungen RS, TdJ, KH verarbeitet |
2005-07-16
|
0.81 |
KH |
Bearbeitungen GB, TdJ, KH verarbeitet |
2005-08-26
|
0.82 |
TdJ |
Letzte Bearbeitungen TdJ verarbeitet (Leseversion für die DT-CMET Besprechung von HL7 NL am 6. September) |
2005-09-04
|
0.90 |
KH, TdJ |
Verarbeitung der Anmerkungen des Besprechungstages und E-Mail-Kommentare |
2005-10-05
|
0.91 |
KH, TdJ |
Hinzufügen der noch fehlenden Elemente und Bearbeitung weiterer Anmerkungen |
2005-10-08
|
0.92 |
TdJ |
Bearbeitung offener Punkte anlässlich des HL7 NL Tages |
2005-10-18
|
1.00 |
TdJ |
Publikation NICTIZ (HTML) |
2005-11-30
|
1.20 |
-Autoren- |
Abstimmungskommentare Niederlande verarbeitet |
2006-04-05
|
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 .
|
Revisionsliste (DE)
Version |
Autoren |
Inhalt |
Datum
|
1.20 |
KH |
Übertragung ins Deutsche auf der Basis der Übersetzung und der Diskussionen innerhalb des deutschen HL7 Version 3 Technischen Komitees |
2006-04-09
|
1.21 |
KH |
Erste Kommentare verarbeitet |
2006-05-07
|
1.30 |
KH |
Anmerkungen Einleitung |
2006-09-21
|
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 .
|
Editoren
Kai U. Heitmann (KH), Heitmann Consulting and Services, und HL7 Benutzergruppe in Deutschland e. V.
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 .
|
Autoren
Gerrit Boers (GB)
|
Maastricht
|
Kai U. Heitmann (KH)
|
Heitmann Consulting and Services, Hürth
|
Tom de Jong (TdJ)
|
Nova Pro, Purmerend
|
René Spronk (RS)
|
Ringholm, Haarlem
|
Michael Tan (MT)
|
Nictiz, Leidschendam
|
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 .
|
Mit Beiträgen von
Christof Geßner
|
|
|
|
|
|
|
|
|
|
Optimal Systems GmbH
|
Legenda
In dieser Spezifikation werden regelmäßig folgende Symbole verwendet:
|
Dies ist ein Punkt, der besondere Aufmerksamkeit erfordert. |
|
Dies ist ein einfacher Hinweis. |
|
Dies ist ein Hinweis auf einen Sachverhalt, der noch bearbeitet werden muss. |
|
Dies ist ein bekanntes Problem / offener Punkt. |
|
Dies ist eine häufig gestellte Frage mit Antwort. |
|
Dies ist ein Punkt, der unbedingt zu beachten ist. |
|
Dies ist eine Einschränkungsregel. |
|
Dieser Punkt muss in HL7 Deutschland noch besprochen/abgestimmt werden |
|
Dieser Punkt muss in HL7 Deutschland oder HL7 International noch besprochen/abgestimmt werden |
|
Dies ist ein Hinweis auf empfehlenswertes Vorgehen (best practice) |
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
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 .
|
Ziel dieses Dokuments
Die 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.
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 .
|
Aufbau des Dokuments
Dieses 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.
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 .
|
Relation zu den übrigen HL7v3 Implementierungsleitfäden
Diverse 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.
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 .
|
Status dieses Dokuments
Dieses 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.
|
An den Stellen, an denen dieses Dokument zusätzliche deutsche Anforderungen im Hinblick auf den internationalen Standard stellt, wird dies im Text angegeben mit “In Deutschland...“ . Der internationale Standard beschreibt Objektklassen, die in diesem Dokument überhaupt nicht wiedergegeben oder beschrieben sind. Als HL7 Deutschland sehen wir für diese Klassen keine Anwendungsmöglichkeiten, obwohl die Benutzung dieser Klassen im Prinzip zugelassen ist. |
Wenn nicht ausdrücklich anders angegeben wurde, ist in Deutschland das Vokabular (Code-Tabellen) anwendbar, das im internationalen Standard beschrieben ist.
Wenn Sie in der deutschen Situation eine HL7 Version 3 Datentyp oder CMETs benutzen wollen, die
- im Widerspruch zu den deutschen Richtlinien ist, und die
- nicht im Widerspruch zum internationalen HL7 Version 3 Standard ist,
können Sie ein Beispiel-Nutzungsszenario (use-case) bei HL7 Deutschland einreichen und einen Antrag zur Anpassung dieses Dokuments anmelden.
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 .
|
Datentypen
In 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
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 .
|
XML Repräsentation von Klassen-Attributen
Klassen-Attribute und Datentypen
Die 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
- einen Namen, beispielsweise id,
- einen Datentyp, beispielsweise AD,
- sowie eine Kardinalität, beispielsweise [0..*].
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.
|
Achtung: Im heutigen XML Schema Sprache kann die Kardinalität eines XML Elements festgelegt werden, aber ob der “Inhalt”, also die Informationen gemäβ der Datentyp-Spezifikation vorhanden sind oder nicht, oder ob sie die korrekte Zusammensetzung haben, ist mit den jetzt vorhandenen Schemas nicht validierbar. Hier ist aber ein zweiter Validierungsschritt erforderlich, wenn garantiert werden muss, dass beispielsweise ein II Datentyp immer mit einem root/extension Attributpaar ausgefüllt ist oder ein nullFlavor Attribut enthält. Um dieses Validierungsniveau möglich zu machen, sind weitere Validierungsschritte mit so genannten constraint Sprachen erforderlich (beispielsweise OCL, Schematron). |
Die XML Elemente haben XML Attribute, die durch den Datentyp selbst bestimmt werden. Die hier verwendete Notationsform für die Datentyp-Attribute lautet:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
Bezeichnung
|
Datentyp
|
Kardinalität
|
Konformität
|
Beschreibung / Erklärung
|
Für die Datentypen wurden Attribute definiert, welche die Daten tragen. So hat in dem Beispiel das id Modellattribut den Datentype II (Instance Identifier). Die zu diesem Datentyp gehörenden Attribute sind beispielsweise root und extension, die als XML Attribute beim Element wiedergegeben werden.
<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 Content
Bei 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 Datentypen
Es 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:
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
Name Kindelement
|
Datentyp
|
Kardinalität
|
Konformanz
|
Beschreibung / Erklärung / Bedeutung
|
Strukturelle Attribute
Es gibt eine Liste von Klassen-Attributen, die nicht als separate Elemente präsentiert werden, sondern als XML Attribute der Klassenelemente.
RIM Klasse
|
Attribut
|
|
Act
|
moodCode
|
classCode
|
negationInd
|
levelCode
|
|
ActRelationship
|
typeCode
|
inversionInd
|
contextControlCode
|
contextConductionInd
|
negationInd
|
|
Entity
|
classCode
|
determinerCode
|
|
Participation
|
typeCode
|
contextControlCode
|
|
Role
|
classCode
|
negationInd
|
|
RoleLink
|
typeCode
|
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"/>
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 .
|
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.
Begriff |
Erklärung/Anmerkungen
|
Kardinalität |
Spezifiziert die minimale und maximale Anzahl des Vorkommens eines Elements (Feld oder Assoziation) in einer XML Instanz. Beispielsweise 1..* bedeutet, dass das Element mindestens 1 Mal vorkommen muss und dass maximal eine unbeschränkte Anzahl Elemente zugelassen ist.
Typische Beispiele:
|
Mandatory |
Ein “mandatory" Item (Feld/Assoziation) muss in einer XML-Instanz vorkommen, ansonsten ist die Nachricht ungültig. Für “mandatory” Elemente ist die Mindestanzahl (Kardinalität) auf 1 (eins) festgelegt. “Mandatory" Elemente sollten nur sparsam und bedacht in Spezifikationen eingesetzt werden, da beim Fehlen von Informationen gar keine Information als Nachricht oder Dokument gesendet werden kann.
|
Conformance |
Hier wird ein Unterschied gemacht zwischen:
- R = Required bedeutet, dass das sendende Anwenderprogramm dieses Feld oder diese Assoziation unterstützen muss. Wenn Daten verfügbar sind, muss dieses Feld/diese Assoziation in einer Nachricht vorhanden sein. Wenn die Mindest-Kardinalität 0 ist und wenn keine Daten verfügbar sind, darf das Element in einer XML-Instanz fehlen und ist die Nachricht/das Dokument immer noch gültig. Wenn die Mindest-Kardinalität 1 ist und keine Daten verfügbar sind, muss dies mit einem nullFlavor (siehe nullFlavor) angegeben werden.
Beispiel: <value nullFlavor="UNK"/>
- Optional (optional) bedeutet, dass ein Element in einer Instanz nicht oder doch vorhanden sein darf und dass Unterstützung durch das sendende Anwenderprogramm nicht verpflichtend ist.
- NP = not permitted (nicht zugelassen) bedeutet, dass das Feld / die Assoziation nicht in einer Nachricht/einem Dokument vorkommen darf (und auch nicht in dem zugrunde liegenden Schema vorhanden ist/sein soll).
|
NullFlavor |
Für Felder/Assoziationen mit einer Mindest-Kardinalität von 1 muss ein nullFlavor angegeben werden, wenn in einem sendenden Anwenderprogramm keine Informationen für dieses Element verfügbar sind. Beispiele von nullFlavor sind “keine Information” (NI – no information), “unbekannt” (UKN – unknown), “sonstige” (OTH - other) usw. Für nähere Erläuterungen siehe nullFlavor.
|
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 .
|
Fehlende Informationen: nullFlavors
Jeder 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:
Codesystem NullFlavor (OID: 2.16.840.1.113883.5.1008)
Lvl |
Typ |
Code / Domänenname |
Kurzbezeichnung |
Definition/Beschreibung
|
0 |
S |
NI |
NoInformation |
Aus der Verwendung von diesem nullFlavor darf keinerlei Information abgeleitet werden. Es bedeutet lediglich, dass die betreffende Information fehlt, ohne dass dafür ein Grund angegeben wird
|
1 |
L |
.NA |
not applicable |
Es gibt keinen zutreffenden Wert in diesem Kontext (z.B. Datum der letzten Menstruation bei einem männlichen Patienten)
|
1 |
S |
.UNK |
Unknown |
Es gibt zwar einen zutreffenden Wert, aber dieser ist beim Versender nicht bekannt (diverse Spezialisierungen sind möglich)
|
2 |
L |
..NASK |
not asked |
Die Information wurde nicht erfragt (z.B. wenn dem Patienten eine bestimmte Frage nicht gestellt wurde) und ist dadurch nicht bekannt
|
2 |
S |
..ASKU |
Asked but unknown |
Die Information wurde zwar erfragt, aber nicht beantwortet (z.B. wenn der Patient zwar befragt wurde, es aber nicht wusste)
|
3 |
L |
...NAV |
Temporarily unavailable |
Die Information ist momentan noch nicht vorhanden, aber man erwartet, dass sie zu einem späteren Zeitpunkt doch noch verfügbar sein wird
|
2 |
L |
..TRC |
Trace |
Es handelt sich um eine Menge die größer ist als 0, die aber zu klein ist, um sie zu quantifizieren; dieser nullFlavor wird nur beim Datentyp PQ (Physical Quantity) verwendet
|
1 |
S |
.OTH |
Other |
Es ist kein brauchbarer Wert in der Domäne verfügbar, der für die entsprechende Information zutreffend ist (z.B. vorgeschriebenes Vocabulary Domain für einen Code)
|
2 |
L |
..PINF |
Positive infinity |
Ein numerischer Wert, der (positiv) im Unendlichen liegt
|
2 |
L |
..NINF |
Negative infinity |
Ein numerischer Wert, der (negativ) im Unendlichen liegt
|
1 |
L |
.MSK |
Masked |
Es ist zwar Information über dieses Item verfügbar, aber der Sender (oder ein Gateway) hat diese aus Gründen der Sicherheit, Privatsphäre oder anderweitig abgesichert; es gibt evtl. einen zusätzlichen Mechanismus um die Information zu erhalten
|
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>
|
Achten Sie darauf, dass die Anwendung des nullFlavor Attributs in welcher Information einer HL7v3 Nachricht auch immer, bedeutet, dass grundsätzlich kein anderes Attribut oder Element der betreffenden Information vorhanden sein darf. Eine Ausnahme hierzu ist zum Beispiel die Nutzung von originalText in Kombination mit nullFlavor "OTH" im Datentyp CD. |
|
Ansich recht es aus der Schema-Perspektive aus, um xsi:nil in Assoziationen zu spezifizieren, wenn keine Informationen hierzu verfügbar ist. In HL7 sind nullFlavor und xsi:nil äquivalent, die XML Prozessoren aber verlangen, dass neben nullFlavor auch xsi:nil angegeben wird. |
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 .
|
Der generische (ANY) Datentyp
Dieser 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:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
nullFlavor
|
cs
|
|
|
fehlender Wert
|
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>
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 .
|
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):
NOT
true |
false
|
false |
true
|
AND
|
true
|
false
|
NULL
|
true |
true |
false |
NULL
|
false |
false |
false |
NULL
|
NULL |
NULL |
NULL |
NULL
|
OR
|
true
|
false
|
NULL
|
true |
true |
true |
NULL
|
false |
true |
false |
NULL
|
NULL |
NULL |
NULL |
NULL
|
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
value
|
bl
|
|
|
Wert true|false
|
XML Beispiele
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).
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 .
|
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.
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 .
|
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:
- Inline data: In diesem Typ werden die vollständigen Daten gesendet. Diese Form wird über-wiegend für Texte verwendet.
- By reference: Eine verkleinerte Version der Daten wird in einem “thumbnail” erfasst, wobei mit einer “reference” auf die vollständigen Daten verwiesen wird. Diese Form wird in Deutschland vorläufig noch nicht verwendet.
Attribute von ED
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
encoding
|
cs
|
|
|
|
Benutzung dieses Attributs ist optional. Dabei sind zwei Kodierungstypen möglich.
Tabelle der Attributwerte für encoding
Code |
Definition
|
TXT |
Für Textdaten. Das ist der Standardtyp. Wenn kein Encoding angegeben ist, wird von TXT ausgegangen.
|
B64 |
Die Base 64 Kodierung wird für alle anderen Multimedia Daten benutzt
|
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
mediaType
|
cs
|
|
|
Datenart
|
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:
Tabelle mediaType Attribut Werte (Datenarten):
Code |
Name |
Status |
Definition
|
text/plain |
Plain Text |
verpflichtend |
Für willkürliche Texte. Dies ist der ‘default’ Typ. In dieser Form ist er identisch mit dem ST Type.
|
text/html |
HTML Text |
empfohlen |
Bestimmt für formatierte Texte in HTML Format. HTML reicht für die meisten Anwendungen aus, bei denen Layout erwünscht ist. HTML ist Plattform-unabhängig und weit verbreitet.
|
audio/basic |
Basic Audio |
verpflichtend |
1- Kanal Audioformat für Sprache. Obwohl Unterstützung dieses Formats verpflichtend ist, wird es in Deutschland kaum benutzt werden.
|
audio/mpeg |
MPEG audio layer 3 |
verpflichtend |
MPEG-1 Audio layer-3 (auch bekannt als MP3) ist momentan der Standard für komprimierte Audiodaten.
|
image/png |
PNG Image |
verpflichtend |
Portable Network Graphics (PNG) [1] ist eine verlustfreie Komprimierung von Bilddateien. Wo vorher GIF benutzt wurde, muss jetzt PNG unterstützt werden.
|
image/jpeg |
JPEG Image |
verpflichtend |
Dieses Format wird benutzt für hohe Resolutionen bei Fotos und anderen Bilddateien. Die Komprimierung verläuft nicht ohne Verluste, wodurch dieses Format nicht immer geeignet ist für diagnostische Zwecke. JPEG wird vorwiegend benutzt werden für ‘thumbnails’ von großen (DICOM) Da-teien.
|
video/mpeg |
MPEG Video |
verpflichtend |
MPEG ist ein internationaler Standard für Videobilder. Er ist weit verbreitet und Open-Source-Implementierungen sind verfügbar.
|
text/rtf |
RTF |
empfohlen |
RTF-Format
|
application/pdf |
PDF |
verpflichtend |
PDF-Format
|
Zugelassene mediaTypes in einer faktischen Implementierung können weiter eingeschränkt werden.
|
Es wird ausdrücklich keine Begrenzung der Größe von den Attributwerten vorgegeben. Auch bei spezifischen Elementen einer HL7 Nachricht geschieht dies nicht, weil der Standard die maximale Größe prinzipiell nicht einschränkt.
Vereinbarungen hierüber werden auf Implementierungsniveau gemacht. Ohne spezifische Vereinbarungen muss der Empfänger in der Lage sein, Encapsulated Data (z. B. Freitext) von beliebiger Größe zu verarbeiten. |
Kindelemente von ED
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
reference
|
TEL
|
|
|
Verweis
|
Dieses Element wird nur in Kombination mit dem ‘thumbnail’ Element benutzt. Es enthält den Hinweis auf die vollständigen Daten in der Form eines TEL (Telecom) Typs.
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
thumbnail
|
ED
|
|
|
verkleinerte Wiedergabe
|
Dieses Element wird benutzt wenn die Datei zu groß ist für den ED-Typ. Das ‘reference’ Element enthält den Hinweis auf die originale Datei. Das ‘thumbnail’ Element kann beispielsweise benutzt werden, um JPEG Versionen von DICOM Dateien weiterzuleiten.
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>
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 .
|
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>
Referenzen
|