NullFlavor

Background

There remains several open issues with regard to nullFlavor. A number of specific possible nullFlavor codes are proposed below. However the most important thing is to agree on a scope statement for nullFlavor: What is it trying to achieve. How much does it try to achieve, particularly in a non-messaging environment?

Scope of nullFlavor

to what?

related issues

• translations may have nullFlavor. This confuses everything when it comes to conformance - nulLFlavors, conformance, and translations will be considered for Datatypes R3
• QS - is it really a nullFlavor - should it be able to be used in a mandatory field? (Another R3 conformance/nullFlavor issue)

From Dipak Kalra

Communicating missing values - Briefing paper

Introduction

Interoperability specifications such as messages and service interfaces at times need to represent the fact that data values are for some reason not available for inclusion. This is of most importance when a data item is specified as mandatory for the communication, but might also arise if the data item is important for other reasons (such as for good practice).

HL7 has historically provided a means of supporting the management of missing information by communicating a “null” data value along with a coded reason for the omission, known as a Null Flavour. The specification of the Null Flavour value options has historically been managed within the Data Types package, and this code set is now subject to review as part of a broad review of this package, for combined balloting through HL7 and ISO to become a new International Standard for Data Types. Other communications standards will be required to adopt this new standard for the specification of data value types; this briefing paper has been informed by but is not limited to the requirements for adoption by EHR communications standards.

The Null Flavour code set has evolved somewhat organically, and this briefing paper offers a re-examination of its scope from a use case perspective, with a view to facilitating its streamlining.

Scenario

The high level goal of this code set is to communicate the rationale for a prescribed data value not being included when, according to the particular interface specification being used, it is either mandatory or would be considered important by the communicating parties. It must be remembered that this code set is to be used when generating a communication instance, and is not primarily intended to be adopted within end-user applications although inevitably some applications and systems developers may find it useful. Efforts should be made not to tie the values of this code set too tightly to particular data entry formats or clinical workflow situations.

Use Cases

Situation: When populating an instance of a given interface specification, the relevant source data does not include a data value that can be included or transformed to provide the corresponding data value for a particular data item within the specification.

Use case 1: The relevant data item is not part of the source database schema, and the process generating the communication instance form is unable to comply with the requirement to provide this value.

Use case 2: The relevant data value is missing from this instance of the source data, and there is no ancillary information that would permit its value to be inferred or explained or justified.

Use case 3: The relevant data value instance is corrupt, secured or in other ways not able to be extracted from the source data, and so no value can be provided or inferred.

Use case 4: The corresponding data value exists, but is of a data value type that cannot be transformed into a format that is required by the interface specification e.g. a free text comment exists, but a formal coded value is required, or a textual value exists but a quantity is required, or the value is included within a scanned document image and could be understood by a human reader but cannot be extracted computationally.

Use case 5: The relevant data value was not captured as a discrete data item in the source data, but its value may be inferred from other information included in the instance e.g. the indication for a prescribed drug is not captured as a specific value but can be deduced from the reason for encounter; a link exists in the source data to indicate that this is a valid inference for this instance, but no link-equivalent is provided for in the interface specification for the data item.

Use case 6: The relevant data value was not captured as a discrete data item in the source data, but its value may be inferred from other information that is NOT included in the instance e.g. a previously documented clinical problem, which is managed in the local application via an internal record link; this problem instance is not part of the interface specification.

Use case 7: The relevant data value is deliberately omitted from the source data (i.e. it was deliberately not captured); optionally the capture application has permitted the author to provide a justification for this omission which it is important to communicate in lieu of the required value; this justification might be in the form of a standardised response and/or as a free text explanation.

The seven use cases each document a different situation within the source data that prevents a specified data value being provided, and that might be important to communicate to explain the missing data. It may therefore be reasonable for a Null Flavour code set to distinguish these seven (or most of them).

This set of use cases might not be exhaustive, and for the purposes of classifying the rationale for data being missing some might usefully be amalgamated.

Clinical justification

Use case 7 has been the subject of much debate in recent weeks. It is important to remember that the goal of this use case is to facilitate the accurate interoperable communication of justifications that have been captured within source systems, rather than to dictate what those justifications might be. In the EHR context, this justification is often a kind of medico-legal statement of why a element of good practice has not been performed, and the communication needs to be faithful to the originally captured reason.

A coarse grained classification of the main reasons for omitting a clinical data item is offered below.

• This data item was not possible to capture, on this occasion or indefinitely, because of this patient’s clinical situation e.g. amputation or bandaged injury preventing measurement of a foot pulse.
• This data item was omitted (as a clinical judgement) because of this patient’s clinical/social situation e.g. to avoid psychological distress, or at the patient’s request.
• This data item was omitted because equivalent information had already been captured and was present in the patient’s record e.g. height.
• This data item was not populated because relevant (background) information was not available at the time e.g. the patient could not recall a fact or date, a relevant measurement result or instruction was not to hand to permit a procedure to be performed.
• This data item was not captured because logistic or facility resource problems prevented the clinical workflow step from being performed to capture it e.g. not enough time, equipment faulty, nobody to facilitate language translation with patient, no female chaperone.
• This data item was pending at the time of committing the data set: the clinical workflow item was performed but the data value needed as the outcome was not yet available.
• The most correct response for this data item is null: i.e. it is a positive assertion that this this data item does not have a value.
• This data item was omitted in error (overlooked).
• This data item was omitted for other reasons - which need to be elaborated.

I can foresee three problems with the above reason list:

1. that even if this list were to be refined and improved through consensus (either simplified or extended), I have not seen many systems that capture clinical reasoning in a systematic way and I am not sure if a mapping process would be feasible to shoe-horn what systems really capture (which is quite diverse) into a standardised code list such as this;
2. even if consensus could ratify a systematised list of options, this is unlikely to be definitive: it is likely that the revision cycles for this list of clinical justifications would be more frequent than for the rest of the Data Type standard, making it an inconvenient inclusion in that standard;
3. this coarse grained set is insufficient to capture a medico-legal justification: knowing something was omitted as a clinical judgement is not useful to a subsequent clinician without some amplification of what that judgement was based on.

Given that a number of systems do support such justifications as free text comments, if the Null Flavour property is to take on this medico-legal role it will have to support the communication of a free text justification remark in addition to or in place of a coded reason.

Conclusion

The set of values offered within the Null Flavour code set needs primarily to classify the set of source data situations that may give rise to a missing value (Use Cases 1-7 above). The model of Null Flavour should consider support for an additional clinical justification coded value. A separate decision needs to be taken on whether this code value should be defined within the Data Type standard. The model of Null Flavour should consider support for an additional clinical justification free text value.

An alternative and much simpler approach, that I would prefer, is to focus the Data Type standard Null Flavour on classifying missing values at the source database/system level (Use Cases 1-4), and leave inferred or deliberately omitted values to be handled and explained within clinical data structures (as content within archetypes, templates etc.).

From Julie James

We have done a fair amount of work on flavours of null from a medicines database standpoint (and I guess the work would be relevant to other knowledgebase type applications and message flows). It is likely to have some relevance for specifications like the SPL, ICSR and Medication DMIM.

From this, we get a couple of use cases that I think are a little different to the clinical/EHR use cases that Dipak focuses on.

Use case A: The value for the instance of this data item is being investigated; at this time there is no information available, but there will be in the future (and therefore the next message covering this instance may well be able to instantiate the correct value).

Use case B: The value for the instance of this data item has been investigated; but there was no information available that allows it to be correctly valued, therefore it is effectively null. The key thing here is that the data has been sought but not found, and therefore the inference is that it is not available (not that it does not exist - there is a (subtle) difference, certainly in medicines terminology; it is not the same as there being no pulse value because of an amputated limb).

Use case C: The value for the instance of this data item has not yet been investigated (effectively the same as Dipak's use case 2, I think). Use case D: The value for the instance of this data item is not relevant in this instance (I think this is effectively the same as the LMP in a male, our examples would be "sugar-free-ness in an injection solution") So my reason for this posting is to request that messaging use cases beyond the EHR but still clinically focussed are included in the Null Flavour re-working.

From Yab Havinga

QS: what about sufficient quantity to make pH neutral?

Reason for Null Flavor

Lloyd McKenzie: BRIDG has identified a requirement to capture the "reason" for a particular null flavor. Examples include such things as: Fire drill - forgot to ask, subject refused, sample lost, broken equipment

Now we have the "reasonCode" attribute and the RSON relationship, but those are used to capture the reasons for the act. I.e. why did the observation itself occur. It seems a stretch for me to use the same attribute to capture the reason for a particular observation value. Particularly when we may want both aspects. "I ordered this test because of X, and I don't have results because of Y". Do we need a distinct attribute? Do I handle this as an observation about the observation? Other suggestions?

Charlie Bishop: We need to recognise that multiple attributes in a class may use nullFlavors in the same instance. Consequently, the reason information may need to repeat and it must be possible to link each reason to the specific attribute to which it applies.

I don’t see how reasonCode or a RSON act relationship can currently satisfy this requirement. Could we change the data type of nullFlavor from CS to CD which would allow the use of qualifiers to give an appropriate reason?