IG:V3 Datentypen Release 1

__NOTITLE__

Abstimmungs- Dokument
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 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: 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. 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. 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: 0..1 1..1 1..* 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> 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. Kindelemente von ED < Element DT Card Conf Beschreibung reference TEL Verweis Dieses Element wird nur in Kombination mit dem ‘thumbnail’ Element benutzt. Es enthält den Hinweis auf die vollständigen Daten in der Form eines TEL (Telecom) Typs. < Element DT Card Conf Beschreibung thumbnail ED verkleinerte Wiedergabe Dieses Element wird benutzt wenn die Datei zu groß ist für den ED-Typ. Das ‘reference’ Element enthält den Hinweis auf die originale Datei. Das ‘thumbnail’ Element kann beispielsweise benutzt werden, um JPEG Versionen von DICOM Dateien weiterzuleiten. Da ‘thumbnail’ ein ED-Typ ist, können alle hiervor genannten Datenarten darin untergebracht werden. XML Beispiele Einfacher Freitext: <text xsi:type="ED" mediaType="text/plain"> Die häusliche Situation des Patienten ist schwierig, da die Kinder weit weg wohnen. </text> Beispiel einer Anwendung von Thumbnail und Reference: <value xsi:type="ED" mediaType="image/png" encoding="B64"> <reference value="http://radiology.iumc.edu/xrays/128s.png"> <useablePeriod xsi:type="IVL_TS"> <low value="200007200845" /> <high value="200008200845" /> </useablePeriod> </reference> <thumbnail mediaType="image/jpeg" representation="B64"> MNYD83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83 6edjzMMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir ... omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu83 4zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83== </thumbnail> </value> Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier . ST (Zeichenkette – Character String) Dieser Typ ist für Freitext in der einfachsten Form gedacht. ST ist eine Spezialisierung des ED-Typs. Der mediaType ist festgelegt mit ‘text/plain’ und der encoding Typ ist ‘TXT’. Die anderen Attribute und Elemente von ED dürfen beim ST-Typ nicht benutzt werden. Der ST-Typ wird vorwiegend in anderen Datentypen, wie AD und PN verwendet. Im Allgemeinen gilt jedoch, dass man für Texte besser den ED-Typ benutzen kann, weil dieser ja auf einen ST-Typ reduziert werden kann, wenn die Attribute korrekt ausgefüllt werden. XML Beispiel Dieses Beispiel ist nahezu gleich mit dem ersten Beispiel bei ED. Funktional sind beide identisch. <text xsi:type="ST"> Die häusliche Situation des Patienten ist schwierig, da die Kinder weit weg wohnen. </text> Referenzen