Understanding Observations and Observation Values

Many kinds of health data are represented as observations. A laboratory test result, a vital sign measurement, a pain scale rating, or recording the kind of exercise activity that a patient engaged in (e.g. running, walking, swimming, etc.) can all be considered observations. In this context, we use observation as a generic term. Depending on the domain of interest, you might call these tests, variables, or data elements, etc.

Within and among health IT systems, observations are communicated with a structure that has two key structural elements. The first element identifies what the observation is, e.g. diastolic blood pressure, hematocrit, tobacco smoking status, or pain intensity on a 0 to 10 scale. The second element carries the result value of the observation, e.g. 80 (mmHg), 40 (%), “current every day smoker”, or 5. When used together, these two elements carry the instance of specific test result for a given patient.

Another way to think about this model is as questions and answers. This first element of the structure (the observation) is like the question, and the second element (the observation value) is like the answer. For example, the question might be: What is this patient’s blood type? The answer then, might be O Positive.

When identifying Vocabulary/Code Sets/Terminology Standards for health data represented as observations, the ISA lists separately the different standards for the observation and the observation value because they fulfill different roles.  Quantitative results don’t need a standard code for the value: the observation value is simply a number (with its associated units of measure). On the other hand, nominal or ordinal results benefit from having a standard code.

A common pairing for many domains is to use LOINC as the standard code for the observation (that’s what the O in LOINC stands for), and SNOMED CT as the standard code for the observation value when needed. This approach is endorsed by the developers of both of these terminologies and fits their design purpose. Yet, the choice of which vocabulary standard to use for these roles varies by domain. For example, when reporting the results of a validated patient assessment (e.g. the Morse Fall Scale), you may choose to use the LOINC Answer Codes as the observation value because they represent the exact text as it appears in that instrument. In contrast, a different approach may be needed when reporting genetic variant results. For example, when reporting a simple genetic variant you could pair the LOINC observation code [81252-9] for “Discrete genetic variant” with an observation value using an identifier from NCBI's ClinVar. Reporting a complex genetic variant may instead pair the LOINC observation code [81262-8] for “Complex variant HGVS name” with an observation value expressed in the HGVS nomenclature.

There are some situations where the structure of health IT system removes the need for the two-part observation structure. If an EHR has a “Problem” table where the records are instances or assertions of patient problems (conditions), then there is no need for an observation code. On the other hand, if the structure of the health IT system or the exchange format lacks such a structural element, the patient’s problem list could be represented using the observation and observation value pattern.

Text developed by the Health IT Standards Committee as part of the 2017 ISA Task Force