Handling Missing Information

This page is outdated and no longer receives updates!

Background

It's common practice to start recording data on paper forms with a series of check boxes, where the providers only need to tick items on the page. When presenting only a single check box as a "boolean" (Yes/No) option, we lose information, because we cannot determine if the check box was left empty because the answer is "No" or because the provider skipped the question. In many cases, we handle this by introducing at least one other option – e.g., "Unknown". For this reason, OpenMRS allows for boolean (Yes/No) datatypes, but stores these internally as coded answers with two possible answers. When an implementation realizes that they want to allow "Unknown" or other coded values as possible answers to the question, it is much easier to convert the concept from boolean to coded (because it's stored like a coded concept within the API).

Issues like this make you realize that there is more to missing information than simply omitting an answer. For example, HL7 specifies at least nine types of missing information.

Recommendations

When modeling your concept and forms, think carefully about how missing information will be interpreted. If someone leaves a question unanswered, could there be more than one reason why? If so, is it important to be able to distinguish between these reasons – e.g., being able to distinguish between a questions that was skipped, one that was asked but the patient was unable to provide an answers, one that was considered but not applicable to the patient, etc. If you need to be able to distinguish between different reasons for missing information, you will want to model your concept to allow for coded answers that account for these reasons.

Resources

Section 1.11.4 of HL7 Data Type Specification provides nine different types of missing information:

Code	Name	Definition

Code	Name	Definition
NI	No information	No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
OTH	other	The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
UNK	unknown	A proper value is applicable, but not known
ASKU	asked but unknown	Information was sought but not found (e.g., patient was asked but didn’t know)
NAV	temporarily unavailable	Information is not available at this time but it is expected that it will be available later.
NASK	not asked	This information has not been sought (e.g., patient was not asked)
MSK	masked	There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.Note: using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
NA	not applicable	No proper value is applicable in this context (e.g., last menstrual period for a male).
NP	not present	Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.