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

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

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

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

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

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

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

8. Token Reuse for Research

9. One Option: Pooling Information from Multiple Systems Logic service standardizes information across programs

10. 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 siteshttp://www.sdmx-hd.org 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

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

12. Questions?