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 data.

• What people want from these systems however, is information, 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 process.

Example - 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-based 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

• Example: 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 OpenMRS, 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 (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 (http://www.sdmx-hd.org) 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 documentation

Questions?