Harmonizing Clinical Information

longtermsingularInternet and Web Development

Dec 4, 2013 (3 years and 8 months ago)


Harmonizing Clinical Information
Between Patient Record Systems:
Distinguishing Information from Data

Distinguishing Information from Data

Electronic medical records (EMRs) are a very rich
source of health information

However, what’s typically within them is the raw content
clinicians collect to document details of service delivery.
These low level “facts” are called

What people want from these systems however, is
, which is a processed and analyzed product
of data.

Clinicians typically interpret data during clinical care

Researchers and M&E specialists also communicate and
typically think in terms of information as well

Challenges of Information Harmonization

Process of harmonizing information between
EMRs is deceptively complex

Variations in how care is provided and
documented in different locations leads to
variations in what/how data are gathered and
how they are stored

To efficiently pool health information between
settings, we must develop practical approaches
with freely available technologies that can be
used to streamline this labor
intensive, manual


Identifying HIV positive patients
between settings:

Foundation of all of IEDEA research

Identifying these patients, especially in the pediatric
population, can be extremely challenging.

Data sources include enrollment in an HIV clinic, HIV
test results (both DNA PCR and Elisa), CDC
classification, WHO stage, CD4 count or percent, ART
use, and in some settings, clinician’s assessment.

To define HIV Positive, researchers must make
inferences from these various data elements.

Challenges of Information Harmonization

Information Tokens

Tokens are information definitions or logic
derivations of multiple discrete clinical data elements
within a given clinical setting

Tokens are defined collectively by a data sharing
community, but the logic underneath each is specific to
the vagaries of a given EMR implementation

: HIV positive is a token described by EA
IeDEA, but the Masaka implementation of OpenMRS
creates the logic one time to best derive that notion and
then reuses it as necessary

Currently, this derivation work is often done in a very
unorganized way, by multiple analysts, with little or no
documentation or ability to reuse methodology.

OpenMRS Logic Service

Automates derivations using
a human expressible form
of logic (Arden Syntax)

Provides a mechanism for consuming data from
, both discrete data elements, as well as,
derived data elements

Reporting with Tokens and Indicators

A report builder takes tokens generated by the logic
service and selects/groups as needed to arrive at

(indicators = compositions of tokens)

Allows sharing of data logic between reports

More efficient and transparent

Easier to maintain

Eliminates redundancy

Ensures consistency across reports

Token Reuse for Research

One Option: Pooling Information from
Multiple Systems

Logic service standardizes information across programs

Another Option: Sharing Indicator
Definitions Between Sites

The EA
IeDEA supplement group has been
working hard with the WHO to support the
evolution of the SDMX
HD standard
) to define a standard
for sharing indicator definitions between sites

Pilot implementation will share the same SDMX
HD definition of three indicators between a
clinical site in Kenya and Uganda.

Each site will have tokens defined within the
implementation of OpenMRS

Next Steps

Finalize upgrades of software at pilot sites

Pilot three indicators through sharing of SDMX
HD definition file

expected ETA in a month

Complete software development

Optimize performance (speed)

Make token development more end
user friendly

Prepare instruction manuals and technical