v3dtr1:NullFlavor
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 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, denn wenn die Conformance mandatory ist, muss grundsätzlich ein Nicht-Null-Wert zu-gewiesen werden.
Der Datentyp ist CS (Coded Simple Value) mit dem Vokabular der Domäne nullFlavor:
Lvl | Type, Domänen-name und/oder Mnemonic code | Druckname | Definition/Beschreibung |
---|---|---|---|
1 | S: NoInformation (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. |
2 | L: (NA) | not applicable | Es gibt keinen zutreffenden Wert in diesem Kontext. (z.B. Datum der letzten Menstruation bei einem männlichen Patienten). |
2 | S: Unknown (UNK) | Unknown | Es gibt zwar einen zutreffenden Wert, aber dieser ist beim Versender nicht bekannt (diverse Spezialisierungen sind möglich). |
3 | L: (NASK) | not asked | Die Information wurde nicht ‘gesucht’ (z.B. wenn dem Patienten eine bestimmte Frage nicht gestellt wurde) und ist dadurch nicht bekannt. |
3 | S: Asked But Unknown (ASKU) | AskedButUnknown | Die Information wurde zwar ‘gesucht’, aber nicht ‘gefunden’ (z.B. wenn der Patient zwar befragt wurde, es aber nicht wusste). |
4 | 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. |
3 | L: (TRC) | Trace | Es handelt sich um eine Menge die größer ist als 0, die aber zu klein ist, um zu quantifizieren. Dieser nullFlavor wird nur bei dem Datentyp PQ (Physical Quantity) verwendet. |
2 | S: Other (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). |
3 | L: (PINF) | positive infinity | Ein numerischer Wert, der (positiv) endlos ist. |
3 | L: (NINF) | negative infinity | Ein numerischer Wert, der (negativ) endlos ist. |
2 | L: (MSK) | Masked | Es ist zwar Information über dieses Item verfüg-bar, aber der Sender (oder eine Gateway) hat diese aus Gründen der Sicherheit, Privatsphäre oder anderweitig abgesichert. Es gibt evt. 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 Burger Service Number (eindeutige Identifikationsnummer der Niederlande) (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>
Vorlage:BeginEMBox 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. Vorlage:EndEMBox
Vorlage:BeginHL7Box Innerhalb von HL7 ist leider noch keine Klarheit darüber, wie mit xsi:nil in Assoziationen umgegangen werden muss. An sich sind nullFlavor und xsi:nil äquivalent. Die XML Prozessoren aber verlangen, dass neben nullFlavor auch xsi:nil angegeben wird. Vorlage:EndHL7Box