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>
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 .
|
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.
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 .
|
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.
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
qualifier
|
cr
|
|
|
Ergänzung zum Code
|
Optional: Enthält eine nähere Präzisierung des unter Code Attribut beschriebenen Konzepts. In dieser Version des Implementierungsleitfadens wird dieses Attribut und der verwendete CR-Datentyp nicht näher ausgearbeitet. Momentan sind in der deutschen Situation keine Terminologien bekannt, die dieses Attribut verwenden. Die Benutzung komplexer Terminologien (z.B. SNOMED CT) ist ausschließlich in Kombination mit diesem Attribut möglich.
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 .
|
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.
Attribute
Attribute eines Elements mit diesem Datentyp sind:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
code
|
string
|
|
|
Code
|
Verpflichtend. Enthält den Code (mnemonic), eine Identifikation des Konzepts, das in dem unter codeSystem angegebenen Codiersystem beschrieben ist.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
codeSystem
|
OID
|
|
|
Codiersystem
|
Verpflichtend. Enthält die Identifikation des Codiersystems (Tabelle, Terminologie). Zur Identifikation wird ein OID verwendet.
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
displayName
|
string
|
|
|
Konzeptbeschreibung
|
Optional. Eine textliche Beschreibung des Konzepts. Diese Beschreibung legt das sendende System seinen Benutzern vor und auf Basis dieser Beschreibung selektiert ein Pflegeanbieter den Code. Dem Wert dieses Attributs darf keine Bedeutung zugemessen werden, außer dass es dem Benutzer vorgelegt wird, um den Hintergrund des Codes zu verdeutlichen. Ein displayName darf niemals ohne zugehörigen code vorkommen und muss dieselbe Bedeutung haben.
|
Es darf nicht erwartet werden, dass der Empfänger den displayName auf Konsistenz mit dem angegebenen Code prüft. Der Empfänger kann selbst bestimmen, ob er eine eventuell vorhandene eigene Beschreibung oder den displayName des Senders für eine Wiedergabe benutzt. Bei der Benutzung eines nullFlavors darf kein displayName, wohl aber das Kindelement originalText genutzt werden, um nicht-kodierte Beschreibungen anzugeben.
EMBox |
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
codeSystemName
|
string
|
|
|
Name des Codiersystems
|
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
codeSystemVersion
|
string
|
|
|
Version des Codiersystems
|
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
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
originalText
|
string
|
|
|
ursprünglicher Text
|
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.
|
Es darf nicht erwartet werden, dass der Empfänger den originalText auf Konsistenz mit dem eventuell abgeleiteten Code prüft. Bei der Nutzung von nullFlavor in diesem Datentyp kann der originalText als Alternative zum codierten Wert verwendet werden (siehe auch Beispiele unten).
EMBox |
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
translation
|
CD
|
|
|
Übersetzung des Codes
|
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"/>
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 .
|
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"/>
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 .
|
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=.../>
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 .
|
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
code
|
string
|
|
|
Code
|
Verpflichtend. Enthält den Code (mnemonic), eine Identifikation des Konzepts, das in dem vordefinierten Codiersystem beschrieben ist.
XML-Beispiele
<Observation classCode="OBS" moodCode="EVN"/>
<statusCode code="active"/>
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 .
|
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.
Attribute
Attribute eines Elements mit diesem Datentyp sind:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
root
|
(OID)
|
required
|
M
|
Identifikationssystem
|
In Deutschland ist dies ein Pflichtattribut. Es enthält einen eindeutigen Identifikator (in Deutschland: eine OID) für das Identifikationssystem, in dem die Extension generiert (und eindeutig) ist.
Ein Identifikationssystem wird verwendet, um Personen, Systeme, Institutionen und andere materielle Sachen identifizieren zu können. Einige (deutsche) Beispiele sind: ‘Personalausweisnummer’, unveränderlicher Teil des Personenkennzahl auf der Versicherungskarte, Krankenhausnummer des St. Josef Krankenhauses, die eindeutige Identifikationsnummer eines Anbieters von Software im Gesundheitswesen, das Institutskennzeichen (IK-Nummer).
|
Ein Element vom Datentyp II hat mindestens ein nicht-leeres @root-Attribut mit einer gültigen OID |
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
extension
|
(string)
|
optional
|
O
|
Identifikation
|
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
assigningAuthorityName
|
(string)
|
optional
|
O
|
Name der ausgebenden Organisation
|
Optionales Attribut. Eine Textform der so genannten ‘assigning authority’, der Organisation, die die Identifikation festgelegt hat (und meistens das entsprechende Identifikationssystem verwaltet). Dem Wert des Attributs darf keine Bedeutung zugemessen wer-den, außer dass es einem Benutzer vorgelegt wird, um den Hintergrund der Identifikation zu verdeutlichen. Für die Lesbarkeit der Nachrichten wird empfohlen, den assigningAuthorityName mitzusenden.
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.
Kurzbezeichnung
|
Beschreibung
|
Komponenten
|
Datentype/Flavor
|
Kommentar
|
Instanzidentifikator |
|
|
II |
|
Identifikator in Deutschland |
|
|
II.DE |
DRAFT
|
Patienten-ID |
|
root + extension |
II.DE.PAT |
DRAFT
|
eGK |
eGK-Kartennummer (root-OID: 1.2.276.0.76.4.8) |
|
II.DE.EGK |
|
|
Es gibt keine II.DE Flavors, was soll das sein? Ebensowenig II.DE.PAT. II.DE.EGK mach Sinn. Was ist der Hintergrund für die anderen Flavors? Wikiadmin 12:52, 25. Feb. 2013 (CET) |
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 .
|
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.
Tabelle: Domäne URLScheme
Code |
Name |
Definition
|
tel |
Telefon |
Telefonnummer [draft-antti-telephony-url-11.txt].
|
fax |
Fax |
Eine Nummer für ein Faxgerät [draft-antti-telephony-url-11.txt].
|
mailto |
Mailto |
Elektronische Mailadresse [RFC 2368].
|
http |
HTTP |
Hypertext Transfer Protocol [RFC 2068].
|
ftp |
FTP |
File Transfer Protocol (FTP) [RFC 1738].
|
mllp |
HL7 Minimal Lower Layer Protocol |
Das traditionelle HL7 Minimal Lower Layer Protokoll. Die URL hat die Form einer IP URL, beispielsweise mllp://<host>:<port>/ mit <host> als IP Adresse oder DNS Hostname und <port> als port Nummer, wo der MLLP Dienst erreichbar ist.
|
file |
File |
Computerspezifische, lokale Dateinamen [RCF 1738]. Diese Schemen funktionieren nur für lokale Dateien. Wird kaum verwendet, weil der Empfänger bei einem Sender / Empfänger Szenario mit einem lokalen Dateinamen meistens nichts an-fangen kann.
|
nfs |
NFS |
Network File System Protokoll [RFC 2224]. Wird für NFS Server zur gemeinsamen Benutzung von Dateien verwendet.
|
telnet |
Telnet |
Referiert an eine interaktive Session [RFC 1738].
|
modem |
Modem |
Eine Telefonnummer mit einem Modem [draft-antti-telephony-url-11.txt].
|
x-hl7-applicatie |
Programm-Identifikation |
OID die ein HL7 Nachrichten sendendes Programm eindeutig identifiziert.
|
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 .
|
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,
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
value
|
TEL
|
0..1
|
opt
|
Wert
|
das verschiedene Zeichenkombinationen enthalten kann, die Telekommunikations-kontakte wie Telefon (tel:), Fax (fax:), E-Mail (mailto:) usw. wiedergeben.
Zugelassene Werteliste für das Prefix im @value Attribut:
Präfix |
Definition
|
tel:
|
Telefonnummer
|
fax:
|
Faxnummer
|
mailto:
|
Email-Adresse (gemäß [RFC 2368])
|
http:
|
Internet-Adresse
|
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
use
|
cs
|
0..1
|
opt
|
Benutzungshinweis
|
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.
Tabelle Domäne TelecommunicationAddressUse Attribut Werte:
Code |
Name |
Definition
|
HP |
primary tel (Wohn- / Aufenthaltsadresse) |
Der primäre Telekommunikationskontakt um eine Person zu erreichen; kann maximal ein Mal vorkommen.
|
HV |
vacation tel (Urlaubs- Telekommunikationskontakt) |
Ein Ferienhaus, wo eine Person im Urlaub zu erreichen ist.
|
WP |
work place (Arbeit) |
Ein Telekommunikationskontakt am Arbeitsplatz. Erste Wahl für arbeitsbezogene Kontakte. Ist für Organisationen und Leistungsanbieter der primäre Telekommunikationskontakt.
|
AS |
Beantwortungsservice |
Eine Person oder ein Service zum Hinterlassen von Nachrichten.
|
EC |
Notfallkontakt |
Ein Telekommunikationskontakt für Notfälle.
|
PG |
Pager |
Ein Pager (Funkmeldeempfänger) mit dem man um einen Rückruf fragen oder eine kurze Nachricht hinterlassen kann.
|
MC |
Mobilkontakt |
Ein Handy oder ein Gerät, das der Besitzer immer bei sich trägt, darf andere use Codes enthalten.
|
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
usabalePeriod
|
TS
|
0..1
|
opt
|
Gültigkeitsdauer
|
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.
Kurzbezeichnung |
Beschreibung |
Datentype/Flavor
|
?? |
|
|
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 .
|
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.
Tabelle: Domäne AddressNamePartType Elementnamen
Element Name |
Definition
|
delimiter |
Trennzeichen [delimiters] werden ohne Leerstellen ausgedruckt [framing]. Wenn keine Wertkomponente geliefert wird, erscheint das Trennzeichen als Zeilenumbruch [line break].
|
country |
Das Land, z.B. "Deutschland". Wenn das Land codiert übermittelt wird, geschieht dies konform mit der ISO 3166 Länderkennung mit zwei Buchstaben nach ISO 3166-1 Edition 2 (OID 1.0.3166.1.2.2)
|
county |
In Deutschland wird dieses Element benutzt, um die Bundesländer anzugeben (in anderen Ländern kann es sich um eine andere administrative Einheit von Staat/Provinz handeln).
|
city |
Der Name einer Stadt, eines Dorfes, eines anderen Wohngebietes oder Zustellzentrums. Bitte beachten: dies ist der Wohnort und nicht die eventuelle Gemeinde, zu der dieser Wohnort gehört. Beispiel: Fleestedt, Gemeinde Hitfeld.
|
postalCode |
Eine Postleitzahl, für deutsche Postleitzahlen, ohne Leerzeichen oder vorangestellten Ländercode, #####.
|
houseNumber |
Die Nummer eines Gebäudes, Hauses oder Grundstücks an der Straße. Wird auch manchmal “primary street number” genannt. Hierbei wird nicht die Straße nummeriert, sondern das einzelne Haus, und zwar mit der vollständigen Hausnummer, als Adresse für die Postzustellung durch den externen Postboten. Eine alphanumerische Zufügung wie “14a” wird auch bei houseNumber mitgesendet.
|
streetName |
Straßenname
|
streetAddressLine |
Eine Kombination von Straße und Hausnummer. Dieses Element sollte nur benutzt werden, wenn der Sender Hausnummer und Straße nicht getrennt speichert oder nicht herleiten kann. Der getrennten Angabe von Straße und Hausnummer ist der Vorzug zu geben.
|
additionalLocator |
Zusätzliche Standortandeutung als Ergänzung zur Postadresse. Dabei kann es sich um die Bezeichnung einer Wohneinheit (Unit) handeln, wie die Nummer eines Appartements, einer Suite oder einer Etage. Es können mehrere Unit-Bezeichnungen in einer Adresse vorkommen (z.B. “3e Etage, Appartement 342”). Außer einem kleineren Unit innerhalb eines größeren Units kann auch ein abweichender Standort spezifiziert werden, wie beispielsweise “g.ü.” , womit ein gegenüberliegender Standort von Wohnbooten an der Straße angegeben wird.
|
postBox |
Eine Postfach-Angabe. Darf nicht in Kombination mit dem PostalAdresUse Code PHYS benutzt werden, da es sich bei einem Postfach nicht um eine Besuchsadresse handelt.
|
Die Codes für Postadressen werden definiert von der HL7 Domäne PostalAddressUse, angegeben im “use” Attribut des addr Mutterelements (siehe Beispiele).
Tabelle: Domäne PostalAddressUse Attribut-Werte
Code |
Name |
Definition
|
PHYS |
visit address (Wohn- / Aufenthaltsort) |
Eine physische Adresse; Wird an erster Stelle benutzt, um den Adressaten zu besuchen. Kann in Deutschland benutzt werden, um eine Adresse durchzugeben, die von der offiziellen Adresse abweicht.
|
PST |
postal address (Postanschrift, Postfach) |
Adresse für die Postzustellung
|
HP |
primary home (offizielle Adresse) |
Die Adresse, die in den offiziellen Registern, z.B. im deutschen Einwohnermeldeamt festgelegt ist; kann maximal ein Mal vorkommen; ist für Personen die primäre Adresse.
|
HV |
vacation home (Ferienhaus) |
Ein Ferienhaus, wo man eine Person im Urlaub erreichen kann.
|
WP |
work place (Arbeit) |
Eine Adresse am Arbeitsplatz. Erste Wahl für arbeitsbezogene Kontakte. Ist für Organisationen und Pflegeanbieter die primäre Adresse.
|
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.
Kurzbezeichnung
|
Beschreibung
|
Elemente
|
Datentype/Flavor
|
Kommentar
|
Volle Adresse
|
alle AD Elemente zugelassen
|
|
AD
|
|
Volle deutsche Adresse
|
alle Teile einer deutschen Adresse (mit useCode) in der richtigen Reihenfolge
|
- Strasse (streetName),
- Hausnummer (houseNumber)
- PLZ (postalCode)
- Ort (city)
Land (country)
|
AD.DE
|
Adresse mit deutscher Postleitzahl; für Adressen im Ausland ist AD zu nutzen oder die entsprechende Variante des jeweiligen Landes.
|
Geburtsort
|
Angabe des Geburtsortes, normalerweise ist das lediglich eine Stadt in Deutschland, so dass das Land als Default vorgegeben werden kann
|
- Ort (city)
- Land (country)
|
AD.DE.BP
|
|
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 .
|
PN (Personenname – Person Name)
Der Datentyp PN wird verwendet, um den Namen einer Person darzustellen.
Attribute
Lvl
|
Name
|
Desc
|
DT
|
Kard
|
Conf
|
Beschreibung
|
1
|
name
|
Name
|
PN
|
1..1
|
optional
|
|
2
|
@use
|
Nutzungsart(en)
|
CS
|
0..1
|
optional
|
wofür ist diese Namensangabe zu verwenden?
|
2
|
validTime
|
Gültigkeitsperiode
|
IVL<TS>
|
0..1
|
Optional
|
in welchem Zeitraum ist dieser Name gültig?
|
2
|
delimiter
|
Trennzeichen
|
PNXP
|
0..*
|
Optional
|
zur Kennzeichnung von Trennsymbolen, um eine mixed-content-Darstellung in XML zu vermeiden; Kann an unterschiedlichen Stellen mehrfach vorkommen, beispielsweise zur Trennung von Vor- und Nachnamen
|
2
|
prefix
|
Präfix
|
PNXP
|
0..*
|
Optional
|
|
3
|
@qualifier
|
Qualifier
|
|
0..*
|
Optional
|
zur Kennzeichnung von Anreden, Titel, etc.
|
2
|
given
|
Vorname(n)
|
PNXP
|
0..*
|
Optional
|
|
3
|
@qualifier
|
Qualifier
|
|
0..*
|
Optional
|
zur Kennzeichnung Geburtsname, Rufname, Initialen, etc.
|
2
|
family
|
Nachname
|
PNXP
|
0..*
|
Optional
|
|
3
|
@qualifier
|
Qualifier
|
|
0..*
|
Optional
|
zur Kennzeichnung Geburtsname, Spouse, etc.
|
2
|
suffix
|
Suffix
|
PNXP
|
0..*
|
Optional
|
|
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:
- Der vollständige Personenname als Freitext (es gibt also keine person name parts), wenn es dem Sender nicht möglich ist, Teile des Namen zu benennen.
- Alle Teileinheiten sind als person name part definiert. In einem solchen Fall darf also kein Text vorkommen, der nicht von einem der nachstehend beschriebenen Tags begleitet wird.
|
Die Sequenz der person name parts ist relevant! Als Richtlinie gilt, dass diese in der ‘natürlichen’ Sequenz der Benutzung des Namens angegeben werden. Die angegebene Sequenz ist besonders in den folgenden Fällen wichtig:
- Präfixe (prefix) müssen immer vor dem Namen stehen, zu dem sie gehören.
- Suffixe (suffix) müssen immer hinter dem Namen stehen, zu dem sie gehören.
- Vornamen (given) müssen immer in der offiziellen (gesetzlichen) Sequenz stehen.
- Nachnamen (family) und ein eventuelles Trennzeichen (meistens ‘-‘) müssen in der offiziellen Sequenz stehen, abhängig von der Wahl bei der Eheschließung.
Nähere Erläuterungen finden Sie bei den verschiedenen person name parts. |
XML Beispiele
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
use
|
CS
|
0..1
|
optional
|
Typ der Namenverwendung
|
Im Prinzip kann von jedem Person Name angegeben werden, in welcher Situation dieser verwendet werden kann. Für Deutschland wurde beschlossen, dass die folgenden Verwendungstypen für Namen zugelassen sind:
Tabelle: Domäne EntityNameUse Attribut Werte
Code |
Name |
Definition
|
L |
Regulärer Name |
Der Name, den die Person (Entität) führt. Die Abkürzung ‘L’ stand ursprünglich für Legal (gesetzlich), Tatsache ist aber, dass in dem Namen auch Komponenten vorkommen dürfen (z.B. ein Rufname), die nicht gesetzlich festgelegt sind. Dieser Namenverwendungstyp ist der Default, wenn kein Typ durchgegeben wird.
|
A |
Pseudonym |
Ein Künstlername, ‘Deckname’ oder zeitlicher Name für eine Person (Entität). Dieser weicht also von dem regulär geführten Namen ab und wird z.B. benutzt, um die Identität einer Person zu tarnen (Privacy) oder als temporärer Name, wenn der echte unbekannt ist (‘John Doe’).
|
OR |
Gesetzlich registrierter Name |
Der Name mit den exakten Komponenten, der im Einwohnermeldeamt des betreffenden Landes registriert ist.
|
|
Beachten Sie, dass ein Name auch zwei use Attribute haben darf. Das kann z.B. vorkommen, wenn der gesetzlich registrierte Name (‘OR’) auch als regulärer Name geführt wird (siehe nachstehendes Beispiel). Achten Sie aber darauf, dass dann keine einzige Komponente vorkommen darf (wie Rufname oder ein Partnername) die nicht Teil des gesetzlich registrierten Namens ist. |
|
Der use code ‘OR’ ist noch nicht im offiziellen HL7 Standard aufgenommen. Er wurde aber, vorauslaufend auf die internationale Harmonisierung, bereits hinzugefügt. |
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>
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
validTime
|
IVL_TS
|
0..1
|
O
|
Gültigkeitszeitraum
|
Dies ist ein optionales XML Element innerhalb Person Name, welches die Periode angibt, in der dieser Name für die betreffende Person ‘in Gebrauch’/gültig war. Die Optionen sind:
- Es gibt kein validTime Element: Der betreffende Name ist im Prinzip unbegrenzt gültig.
- Es gibt eine Unter- und Obergrenze: Der Name war in der angegebenen Periode gültig.
- Es gibt nur eine Untergrenze: Der Name ist seit dem angegebenen Datum gültig.
- Es gibt nur eine Obergrenze: Der Name war bis einschl. angegebenem Datum gültig.
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:
- Adoption eines Babys, das den Nachnamen der Adoptiveltern erhält.
- Eheschließung, wobei der Name des Partners an den eigenen Namen angefügt wird.
- Ehescheidung, wobei ein vorher angenommener Name wieder abgelegt wird.
- Personen, die aus anderen Gründen ihren Vor- oder Nachnamen ändern.
|
In allen Situationen, in denen ein oder mehrere Person Names durchgegeben werden, muss minimal der Name angegeben werden, der zum Zeitpunkts des Versendens gültig/aktuell ist. Nicht mehr gültige Namen können also nur angegeben werden, wenn das betreffende Nachrichtenelement wiederholt benutzt wird (also mit einer Kardinalität > 1). |
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).
|
Im Gegensatz zu der Situation bei Organization Name ist es nicht zugelassen, dass die Unter- oder Obergrenze einer validTime Angabe bei Person Name in de Zukunft liegt. Es kann also kein ‘geplanter’ neuer Name oder ein ‘geplantes Verfallsdatum’ des heutigen Namens für Personennamen durchgegeben werden. |
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.
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
delimiter
|
PNXP
|
0..*
|
O
|
Trennzeichen
|
Ein delimiter hat keine spezielle Bedeutung als Bestandteil eines Person Name, im Gegensatz zur Übermittlung eines (Stückchens) wörtlichem Text, der in dem geschriebenen Namen vorkommt.
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:
- Der Bindestrich ‘-‘ zwischen dem eigenen Nachnamen und dem Partnernamen (oder umgekehrt).
- Das Komma plus Leerstelle ‘, ‘ zwischen dem Namen und bestimmten Nachsilben.
- Der Text ‘, geb. ’ oder ‘, E.v. ‘ (Ehefrau von), der manchmal benutzt wird bei dem eigenen, bzw. Partnernamen.
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 auf der Hand liegende Fragen (und Antworten) über delimiters:
|
Frage: Muss ein empfangendes System einen delimiter speichern?
Antwort: Ein empfangendes System, dass die einzelnen person name parts verarbeitet, wird delimiters praktisch nie in der eigenen Datenbank speichern.
Frage: Warum sollte ein sendendes System dann überhaupt delimiters mitsenden?
Antwort: Es kann vorkommen, dass empfangende Systeme keine oder nicht alle person name parts separat verarbeiten können (z.B. weil sie nur ein Feld für den Nachnamen haben). Sie können über delimiters einen voll ausgeschriebenen Namen übernehmen. (Ein Beispiel eines solch einfachen Empfängers ist ein Webinterface, das eingehende HL7 v3 Nachrichten in ein HTML Format umsetzt, zur direkten Wiedergabe auf dem Bildschirm). |
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
family
|
PNXP
|
0..*
|
O
|
Nachname
|
Attribut:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
qualifier
|
CS
|
0..1
|
optional
|
Namensart
|
Ein person name part des Typen family bezieht sich auf einen Teil des Namens, den eine Person durch Familienbande bekommen hat und der meistens als Nachname bezeichnet wird. Normalerweise bezieht sich dies also auf den eigenen Nachnamen (erhalten von den Eltern) und eventuell auf einen nach einer Heirat angenommenen Nachnamen. (‘übernommen’ vom Partner).
Einige Regeln in Bezug auf person name parts des Typen family:
- Diese müssen untereinander immer konform mit der offiziellen Schreibweise angeordnet sein (z.B. zuerst der eigene Nachname und dann der Nachname des Partners oder genau umgekehrt).
- Es gibt immer eine implizite Leerstelle als Zwischenraum mit dem darauf folgenden name part, außer bei einem delimiter oder einem suffix (siehe dort).
- Die Art des Nachnamens kann weiterhin durch die Verwendung des optionalen Attributs qualifier angegeben werden. Siehe Tabelle für die dabei zugelassenen Werte.
- Es darf nur ein Familienname pro Qualifier-Typ im Namen vorkommen!
Tabelle: qualifiers bei person name part family
Qualifer |
Anwendung
|
BR |
(birth) Geburtsname. Ein Nachname, den man bei der Geburt erhalten hat. Normalerweise ist dies der Geburtsname eines (natürlichen) Elternteils, aber in einigen Kulturen kann es sich dabei auch um eine Kombination der Geburtsnamen beider Eltern handeln, oder um eine Ableitung des Vornamens eines Elternteils.
|
CL |
Rufname. Ein Nachname, mit dem eine Person informell angesprochen wird und der meistens von einem der offiziellen Nachnamen abgeleitet ist.
|
SP |
(spouse) Partnername. Ein Nachname, der von einem Partner bei einer Ehe ‘übernommen’ wurde (meistens der Geburtsname eines Partners). Dies sagt nichts aus über das Geschlecht des Namensträgers, da die Annahme von Namen zwischen beiden Partnern in den Deutschland gleichgestellt ist. Auch wenn ein Partnername fehlt, kann daraus keine Schlussfolgerung über den Ehestand gezogen werden, da jemand verheiratet sein kann, ohne den Namen des Partners zu führen. Es ist zu beachten, dass es bei der Verwendung eines Partnernamens nicht nur relevant ist, dass jemand verheiratet ist, sondern vor allem, ob die betreffende Person mit dem Namen des Partners angesprochen werden möchte oder nicht. Die Anwendung des Partnernamens im Personennamen ist unabhängig von einer eventuellen Benennung des Partners als Kontaktperson. In der heutigen deutschen Namensrecht ist nach einer Eheschließung jede Kombination von Eigenname und/oder Partnername von beiden Partnern möglich. Natürlich ist das Geschlecht der beiden Partner dabei nicht relevant.
|
AD |
angenommener Name
|
prüfen! |
|
|
Wenn ein person name part vom Typ family ohne einen qualifier benutzt wird, wird dies einfach als Nachname interpretiert. Wenn der Empfänger zwischen einer Speicherung als Geburtsname oder als Partnername wählen kann, muss in einem solchen Fall der Geburtsname gewählt werden. |
|
Es muss noch entschieden werden, was mit einem Geburtsnamen geschehen soll, den jemand nach einer Eheschließung nicht mehr führt (weil ausschließlich der Partnername geführt wird). Der Geburtsname muss in einem solchen Fall trotzdem gespeichert (und übermittelt) werden, aber es könnte dabei angegeben werden, dass der Name ‘unsichtbar’ sein muss. Eine Lösung könnte die Implementierung eines Attributs invisible sein. Es ist auf jeden Fall möglich, den Namen zweimal zu übermitteln: einmal mit dem use Attribut ‘OR’ (mit dem Geburtsnamen) und einmal mit einem ‘L’ (ohne). |
|
Es muss im internationalen Rahmen noch untersucht werden, wie mit dem Nachnamen zu verfahren ist, der von den Adoptiveltern übernommen wurde. Nach der heutigen Definition ist der qualifier “BR” hierfür nicht geeignet, aber es ist klar, dass die qualifiers “SP” und “CL” ebenfalls nicht ausreichend sind. Vorläufig lautet die Empfehlung in solchen Fällen (falls überhaupt bekannt ist, dass es sich um einen Adoptivnamen handelt) keinen qualifier mitzusenden. In der Praxis wird ein derartiger Name allerdings meistens als ‘eigener Nachname’ (und daher mit qualifier “BR”) benutzt werden. |
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>
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
given
|
PNXP
|
0..*
|
O
|
Vorname
|
Attribut:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
qualifier
|
CS
|
0..1
|
optional
|
Namensart
|
Ein person name part des Typen given bezieht sich auf den Teil des Namens, den eine Person meistens von den Eltern und meistens bei der Geburt erhält. In Deutschland wird dies meistens als Vorname bezeichnet, obwohl dieser nicht in allen Kulturen vor dem Familiennamen steht. Auch Namensbestandteile, die von dem Vornamen abgeleitet sind, z.B. die Initialen (Anfangsbuchstaben) und der Rufname (informeller Vorname) haben den Typ given.
Einige Regeln für person name parts des Typen given:
- Eine Person kann ohne weiteres mehrere Vornamen oder Initialen haben.
- Offizielle Vornamen und Initialen müssen immer in der richtigen Sequenz stehen.
- Es muss immer eine implizite Leerstelle als Zwischenraum zu dem darauf folgenden name part stehen, außer wenn es sich um ein delimiter oder ein suffix handelt (siehe dort).
- Die Datenart des gegebenen Namens kann zudem angedeutet werden, indem das optionale Attribut qualifier benutzt wird. Siehe Tabelle für die dabei zugelassenen Werte.
Tabelle: qualifiers bei person name part given
Qualifer |
Anwendung
|
BR |
Offizieller Vorname. Ein Vorname, der meistens bei der Geburt gegeben ist (meistens von den Eltern) und der offiziell registriert ist. Vornamen müssen voll ausgeschrieben werden und in der richtigen Sequenz stehen. Wenn eine Person mehrere Vornamen hat, muss auf jeden Fall der erste Name übermittelt werden (Die ausschließliche Benutzung des ersten Vornamens ist also zugelassen, die ausschließliche Benutzung des zweiten Vornamens dagegen nicht). Wenn es mehrere Vornamen gibt, können diese sowohl als separate given Elemente, als auch in einem Element (getrennt durch Leerstellen) übermittelt werden. Es kommt auch vor, dass der erste Vorname voll ausgeschrieben in Kombination mit den Initialen benutzt wird.
|
CL |
Rufname. Ein Vorname, mit dem eine Person informell angesprochen wird und der meistens von einem der offiziellen Vornamen abgeleitet ist. Im Gegensatz zu den offiziellen Vornamen kann ein Rufname im Leben einer Person ohne weiteres variieren. Eine Person kann sogar mehrere Rufnamen gleichzeitig haben, je nachdem wie Menschen die Person kennen. In diesem Fall muss der am meisten zutreffende Rufname gesendet werden.
|
SP |
Initialen. Meistens eine Abkürzung des Vornamens. Dabei kann es sich um einen einzigen oder um mehrere Buchstaben handeln (z.B. ‘Th.’ für Thomas). Ein abschließender Punkt muss explizit angegeben werden. Initialen müssen in der korrekten Sequenz angegeben werden. Wenn es mehrere Initialen gibt, können diese sowohl als separate given Elemente, als auch in einem Element (getrennt durch Punkte) übermittelt werden. Der Vorteil dieser Methode ist, dass keine Leerstellen zwischen den einzelnen Initialen im Namen impliziert werden.
|
|
Wenn ein person name part des Typen given ohne einen qualifier verwendet wird, wird dieses einfach als Vorname interpretiert. Wenn der Empfänger wählen muss, ob dies als offizieller Vorname oder als Rufname gespeichert werden soll, muss in einem solchen Fall der offizielle Vorname gewählt werden. |
|
Die qualifiers “BR” und “CL” können auch gemeinsam vorkommen, um an-zugeben, dass ein offizieller Vorname auch als Rufname fungiert. So kann vermieden werden, dass der gleiche Name zwei Mal mit gesendet werden muss. Wenn der Rufname allerdings von den offiziellen Vornamen abweicht, können beide übermittelt werden: zuerst die offiziellen Vornamen und danach der Rufname. |
|
Wenn eine Kombination von offiziellem Vornamen und Initialen mit gesendet wird, dürfen diese sich in Deutschland nicht ‘überlappen’ dürfen, d.h. dass der erste Anfangsbuchstabe (falls erforderlich) von dem empfangenden System von dem/den ersten Buchstaben des offiziellen Vornamens ab-geleitet werden muss (siehe nachstehendes Beispiel). |
|
In Deutschland muss noch untersucht werden, wie man mit dem Vornamen, den die Adoptiveltern gegeben haben, zu verfahren hat. Nach der heutigen Definition ist der qualifier “BR” hierfür nicht geeignet, aber es ist nicht klar, ob der qualifier “CL” (Rufname) wohl ausreichend ist. Die Frage ist nämlich, ob ein derartiger Name einen offiziellen Charakter bekommt oder nur als Rufname fungiert. |
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.
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
prefix
|
PNXP
|
0..*
|
O
|
Präfix
|
Attribute:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
code
|
SC
|
0..1
|
optional
|
Titelcode
|
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
qualifier
|
CS
|
0..1
|
optional
|
Namensart
|
Ein person name part des Typen prefix bezieht sich auf einen Teil des Namens, der zu einem oder mehreren anderen Namensbestandteilen gehört und vorne angehängt wird. Im Prinzip gibt es zwei Arten von Vorsilben, nämlich Vorsilben zu Nachnamen und zu Titeln/akademischen Graden (die als Zufügung zum geschriebenen Namen aufgenommen werden).
Einige Regeln für person name parts des Typen prefix:
- Ein prefix muss immer direkt vor die Namensbestandteile platziert werden, auf die es sich bezieht (d.h. wo es normalerweise geschrieben wird).
- Es gibt keine implizite Leerstelle als Zwischenraum zu dem darauf folgenden name part, d.h. eine Leerstelle nach der Vorsilbe muss explizit im Text angegeben werden!
Die Art der Vorsilbe kann zudem angedeutet werden, indem man das optionale Attribut qualifier benutzt. Siehe Tabelle für die dabei zugelassenen Werte.
|
Im nächsten Release der Datentypen von HL7 v3 wird es möglich sein, diverse Elemente die jetzt ein ‘string’ sind, auch optional als Code anzugeben.
Dies kann u.a. zur kodierten Versendung von Titeln/akademischen Graden benutzt werden, wenn das sendende System diese als Code speichert. Darüber hinaus muss der Text aber immer gesendet werden, damit der Empfänger entscheiden kann, was benutzt wird. |
Tabelle: qualifiers bei person name part prefix
Qualifer |
Anwendung
|
VV |
Vorsilbe zu Nachnamen. Dabei handelt es sich um Namensbestandteile wie “von“, “den“, und “zu“, aber auch um Kombinationen wie “von der“ usw. Eine Vorsilbe gehört immer zum person name part des Typen family , der immer direkt dahinter steht (siehe die XML Beispiele). Eine Vorsilbe kann als Bestandteil des Nachnamen aufgenommen werden, aber es ist gebräuchlich, sie einzeln zu speichern (und zu versenden), da Sortierungen (und daher auch das Zurücksuchen) immer auf Nachnamen ohne Vorsilbe stattfinden.
|
AC |
Akademischer Grad. Ein Grad (meistens in abgekürzter Form) den jemand aufgrund der Vollendung eines wissenschaftlichen Studiums oder eines anderen Studiums erworben hat, z.B.: “Dr.“, “Dipl.-Ing.“, “Ing.“, “Hr.“, “Dr.“, “Prof.“, aber auch “Prof. Dr.“, „Prof. Dr. med.“.
|
NB |
Adelstitel. Ein Titel (meistens voll ausgeschrieben) der auf dem aristokratischen Status einer Person gründet. Beispiele sind “Baron“, “Graf“, usw.
|
TITLE |
Allgemeine Anrede (nicht Titel). Diese wird im Prinzip als Anrede zu einem vollständigen Namen (als Briefanrede) verwendet, z.B. “Sehr geehrte Herr” , “Sehr geehrte Frau“, aber auch einfach “Frau“. Die Art einer solchen Anrede hängt also mit dem Geschlecht der Person und dem eventuellen akademischen Grad und/oder Adelstitel ab (mit Hilfe von Ableitungsregeln).
|
|
Wenn ein person name part des Typen prefix ohne einen qualifier benutzt wird, wird dies immer interpretiert als Titel. Dies geschieht, weil viele ver-sendende Systeme zwar Titel unterstützen, aber keinen Unterschied machen zwischen akademischen Graden und Adelstiteln. Vorsilben bei Nachnamen und die allgemeine Anrede (“VV” bzw. “TITLE”) müssen also immer explizit übermittelt werden. |
|
Wenn nicht bekannt ist, ob ein Titel vor oder hinter dem Namen anzuhängen ist, muss dieser als prefix gesendet werden. Dies wird häufig der Fall sein bei Systemen, die keine Rangfolge im Textfeld bei einem Titel speichern. In solchen Fällen werden Titel also immer vor dem Namen im Datentyp Person Name positioniert. |
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>
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
suffix
|
PNXP
|
0..*
|
O
|
Suffix
|
Attribut:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
code=
|
SC
|
0..1
|
optional
|
Titelscode
|
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
qualifier
|
CS
|
0..1
|
optional
|
Namensart
|
Ein person name part des Typen suffix bezieht sich auf einen Teil des Namens, der zu einem oder mehreren anderen Namensbestandteilen gehört und hinten angehängt wird. In Deutschland sind Nachsilben ausschließlich bei akademischen Graden zugelassen.
Einige Regeln für person name parts des Typen suffix:
- Ein suffix muss immer direkt hinter die Namensbestandteile positioniert werden, auf die es sich bezieht (d.h. wo es normalerweise steht).
- Es gibt keine implizite Leerstelle als Zwischenraum zu dem davor stehenden name part, d.h. eine Leerstelle vor der Nachsilbe muss explizit angegeben werden!
Die Art der Nachsilbe kann ferner angegeben werden durch die Anwendung des optionalen Attributs qualifier. Siehe die Tabelle für die dabei zugelassenen Werte.
|
Im nächsten Release der Datentypen von HL7 v3 wird es möglich sein, diverse Elemente die jetzt ‘string’ sind, optional auch als Code anzudeuten.
Dies kann u.a. zur kodierten Versendung von Titeln benutzt werden, wenn das sendende System diese als Code speichert. Darüber hinaus muss aber immer der Text gesendet werden, damit der Empfänger entscheiden kann, was benutzt wird. |
Tabelle: qualifiers bei person name part suffix
Qualifier |
Anwendung
|
AC |
Akademische Grade. Ein Grad (meistens in abgekürzter Form) den jemand aufgrund der Vollendung eines wissenschaftlichen Studiums oder eines anderen Studiums erworben hat. Bei Nachsilben handelt es sich dabei meistens um internationale Termen wie “MSc”, “PhD” oder “MD”.
|
|
Ein person name part des Typen suffix, der ohne qualifier benutzt wird, muss interpretiert werden als nicht näher bestimmtes Suffix. Auch die Verwendung von (vielfach amerikanischen) Termen wie ‘, Jr.’, ‘, Sr.’ of ‘ III’ fällt unter diese Kategorie. |
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.
Kurzbezeichnung
|
Beschreibung
|
Datentype/Flavor
|
voller Name
|
alle Elemente sind zugelassen
|
PN
|
Standard
|
voller Name mit Anrede, Titel, Vor- und Nachname sowie Geburtsname
Dies entspricht am ehesten dem "legal Name".
|
PN.DE
|
förmliche Anrede
|
Zur Darstellung auf Briefumschlägen etc.
|
PN.DE.FORM
|
Anrede in Briefen
|
Wie soll die Person in Briefen angeredet werden?
"Lieber Hans" anstelle von "Herr Dr. Meier"
|
PN.DE.LETTER
|
pseudonymisiert
|
Anstelle des "echten" Namens wird ein Pseudonym übermittelt, das mit Hilfe einer trusted third party ermittelt/festgelegt worden ist.
|
PN.DE.PSEUDONYM
|
anonymisiert
|
ohne verwertbare Namensinformation
|
PN.DE.ANONYM
|
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 .
|
ON (Organisationsname – Organization Name)
Definition: Ein Name einer Organisation.
Attribut:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
use
|
SET<CS>
|
|
|
Benutzertype(n), nicht verwenden in DE
|
Element:
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
validTime
|
IVL<TS>
|
0..*
|
O
|
Gültigkeitszeitraum
|
Struktur:
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
use
|
|
|
|
Benutzungstype(n)
|
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.
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
validTime
|
|
|
|
Gültigkeitszeitraum
|
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:
- Es gibt kein validTime Element: Der betreffende Name ist im Prinzip universell gültig.
- Es gibt eine Unter- und Obergrenze: Der Name war in der angegebenen Periode gültig.
- Es gibt nur eine Untergrenze: Der Name ist seit dem angegebenen Datum gültig.
- Es gibt nur eine Obergrenze: Der Name war bis einschließlich dem angegebenen Datum gültig.
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.
|
In allen Situationen, in denen ein oder mehrere Organization Names übermittelt werden, muss minimal der Name angegeben werden, der zum Zeitpunkt des Versendens gültig/aktuell ist. Nicht mehr gültige Namen können also nur übermittelt werden, wenn das betreffende Nachrichtenelement wiederholt benutzt wird (also mit max. Kardinalität > 1). |
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>
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 .
|
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.
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 .
|
INT (Ganze Zahl – Integer number)
Elemente dieses Datentyps haben ein Attribut,
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
value
|
INT
|
|
|
Wert
|
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
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 .
|
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).
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 .
|
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:
- Eine abgenommene Blutmenge von 20 ml (Probengröße)
- Eine Schnittwunde mit einer Länge von 10 cm (Ergebnis Beobachtung)
- Eine Dosis von 200 Milligramm eines Medikaments (Dosiermenge)
- Lieferung von 60 Stück einer Tablette (gelieferte Menge)
Elemente dieses Datentyps haben die folgende Struktur:
Das Attribut value trägt die Größe der Menge, ausgedrückt in der Einheit (unit):
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
value
|
REAL
|
|
|
Größe der Menge
|
In unit steht die Messeinheit, konform mit dem Unified Code for Units of Measure (UCUM). Diese Tabelle enthält alle natürlichen Messeinheiten:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
unit
|
CS
|
|
|
Messeinheit
|
Wenn value “nicht zählbar”, “messbar” ist (z.B. ausgedrückt in Milligramm oder Liter) muss diese Einheit in diesem Attribut aufgenommen werden. Wenn value ‘zählbar’ ist (z. B. Tabletten), trägt dieses Attribut den Wert 1.
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:
|
<
|
Element
|
DT
|
Card
|
Conf
|
Beschreibung
|
translation
|
PQR
|
|
|
alternative Repräsentation
|
Weil die Messwerte meistens im Zusammenhang mit einer allgemeinen Beobachtung wiedergegeben werden (Observation), wobei der Datentyp für value ANY ist, muss auf jeden Fall der Datentyp für die Instantiierung über xsi:type angegeben 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>
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 .
|
MO (Geldbetrag – monetary amount)
Elemente dieses Datentyps haben zwei Attribute:
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
value
|
REAL
|
|
|
Wert
|
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
currency
|
CS
|
|
|
Währung
|
Dieser Datentyp wird benutzt, um einen Geldbetrag (value) in einer bestimmten Währung (currency) anzugeben. MO hat viel Ähnlichkeit mit dem PQ Typ, aber es gibt einen essentiellen Unterschied: Währungskurse sind im Gegensatz zur Umrechnung physikalischer Einheiten variabel, wodurch Geld nicht in einem PQ Typ definiert werden kann.
Währungen werden codiert nach ISO 4217:
Tabelle: Codes für das currency Attribut (wichtigste Codes)
Code |
Name |
Land
|
EUR |
Euro |
Europäische Union
|
GBP |
Britisches Pfund |
Vereinigtes Königreich
|
USD |
Amerikanischer Dollar |
Vereinigte Staaten
|
CHF |
Schweizer Franken |
Schweiz
|
XML-Beispiel
<value xsi:type="MO" currency="EUR" value="97.32"/>
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 .
|
TS (Zeitpunkt – timestamp)
Elemente dieses Datentyps haben ein Attribut
|
@
|
Attribut
|
DT
|
Card
|
Conf
|
Beschreibung
|
value
|
TS
|
|
|
Wert
|
Ein Datum kann mit dem folgenden Format festgelegt werden: YYYYMMDDHHMM. Wenn ein System zu wenig Information hat (beispielsweise: nur das Jahr ist bekannt), kann die Kette von rechts nach links abgebrochen werden.
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"/>
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 .
|
BAG Bag
Einige 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.
In der XML Repräsentation wird ein BAG<T> mit einer Kardinalität von n..m umgesetzt in ein wiederholbares XML Element mit der Kardinalität n..*. Eine explizite Darstellung von BAG in XML ist also nicht vorhanden.
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 .
|
SET Set
Einige 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.
In der XML Repräsentation wird ein SET<T> mit einer Kardinalität von n..m umgesetzt in ein wiederholbares XML Element mit der Kardinalität n..*. Eine explizite Darstellung von SET in XML ist also nicht vorhanden.
Referenzen
|