With the evolution of the FHIR standard, this design should probably be adjusted to align more closely with FHIR – e.g., using the cancelled Observation.status along with Observation.dataAbsentReason from FHIR's Observation model instead of HL7 v2.x's "X" status approach.

Primary mentor

Burke Mamlin

Backup mentor

TBD

Assigned to

TBD

Background

Within OpenMRS the majority of data collected about patients are stored as observations.  Examples of observations are: the patient's weight, the patient's pulse, the patient's answer to the question "How many children live in your home?", or a lab result like serum potassium level.  In most cases, we collect these observations as data and stored them in the system without any problems.  In some cases, observations cannot be completed, but there is value in recording the exception rather than simply omitting the result.  While exceptions for laboratory tests are most common, exceptions are not limited to laboratory tests.  Some examples of common exceptions would be:

Currently, OpenMRS has the ability to store observations but lacks a standardized way to represent observations with exceptions.  Implementations are left to come up with other ways to handle exceptions – e.g., record the exception as a separate observation or omit the exception altogether (possibly losing valuable information).

Purpose

The goal of this project is to add a standard mechanism for handling observation exceptions to the OpenMRS API so that implementations can – in a standard & predictable way – handle and record observations even when they are incomplete, refused, or have other exceptions.

Domain Expert(s) / User(s)

TBD

Required Skills

Objectives

Design Ideas

Data Model Changes

Explicitly mark observations that have exceptions through the use of a status field.  For example, add one or two attributes to the obs table:

Backwards Compatibility in API

For backwards compatibility (since existing code assumes all observations have values), have the existing API work as it does (omitting exceptions) and add new methods to get results including exceptions – e.g., getObservations( ..., boolean includeExceptions).

Upgrade Strategy

This change will need an upgrade strategy, since the obs table can be massive and changes to its structure can be prohibitively slow. Simply changing the structure of the obs table in a liquibase changeset (as we normally do for small changes) could prevent implementations from being able to upgrade.

Ideas for upgrade strategy:

Extra Credit

Resources