1. An Overview of Emerging Real-World OpenHIE Use Cases: Successes, Challenges, and Future Opportunities Shaun Grannis, MD, MS, FACMI1, Eric-Jan Manders, PhD2, Carl Leitner, PhD3, Annah Ngaruro, MS4, Jack Bowie, ScD5
1 Indiana University and the Regenstrief Institute, Indianapolis, IN;
2 Centers for Disease Control and Prevention, Atlanta, GA, USA;
3 PATH, Chapel Hill, NC, USA;
4 ICF International Inc., Rockville, MD, USA;
5 Apelon Inc., Hartford, CT, USA.

2. Discussion Questions
What are the key elements of a component-based eHealth architecture supporting low and middle-income countries?
How can elements in component-based eHealth architecture be orchestrated to support specific data exchange workflows?
What are potential barriers to implementing specific data exchange use cases?
What key non-technical factors can enable successful implementation of data exchange workflows?
How can terminology services integrate into an overall eHealth architecture?
What lessons learned from implementing Health Information Exchange in the US could translate to LMIC settings?

3. What We’ll Cover OpenHIE Introduction (Grannis)
Integrating Standard Terminologies: OpenHIE Terminology Services (Bowie)
The DATIM experience supporting indicator reporting (Ngaruro)
mHero: Supporting health workers for routine care and Ebola crisis care (Leitner)
HIV case-based surveillance (Manders)

4. OpenHIE Introduction
Shaun Grannis, MD MS FACMI

5. Who we are
OpenHIE is a diverse mission-driven community of practice including countries, organizations, individuals and donors working to promote sharing of health data across many different software products.
We make and improve standards-based software to improve the exchange of health information.

6. MISSION
Our mission is to improve the health of the under-served through the open collaborative development and support of country driven, large scale health information sharing architectures.
VISION
We envision a world where all countries are empowered to pragmatically implement sustainable health information sharing architectures that measurably improve health outcomes.

7. Architecture Framework
Sharing Data to Improve Health Outcomes

8. OpenHIE Introduction to Terminology Services Jack Bowie, Apelon, Inc.
AMIA, 2017

9. Agenda
What
Why
How
Where

10. Terminology Services
We are here

11. Terminology Services
“The objective of the Terminology Services component is to provide a central resource for the definitional assets of the HIE, i.e., terminologies, ontologies, dictionaries, code systems, value sets, etc., that can be used by other HIE components to achieve normalization of clinical data and consistent aggregation and reporting.”
From the OHIE Terminology Services Planning and Implementation Guide

12. Why Standard Terminologies?
Normalization of clinical data
Consistent aggregation and reporting
Counting
Grouping

13. Courtesy of Mary Morgan, LCS, Partners Healthcare

15. Journal of the American Medical Informatics Association – September 1994

16. Why Terminology Services?
Today’s HIT environment requires access to multiple “standard” terminologies.
These terminologies are under constant revision.
Maintain the official version of HIE datasets (the “gold- standard” or “single source of truth”)
Eliminate multiple, duplicate, copies of these datasets in the HIE

17. Terminology Services Interfaces
Originally, interfaces to other OHIE Components were idiosyncratic and proprietary
Hard to use and weren’t portable
Now moving to interfaces drawn from the HL7 FHIR Specifications
Primary Resources
CodeSystems
ValueSets
ConceptMaps

18. Terminology Services Interfaces
FHIR Operations:
Existence
Membership
Expansion
Mapping
Is ‘123XYZ’ an ICD-10 code?
Is ‘123XYZ’ in the HIV ValueSet?
Get the codes in the HIV ValueSet.
What is the SNOMED code for ‘123XYZ’?

19. Terminology Services Adoption
Implementations vary greatly in their initial terminology services adoption driven by their specific use-case:
Maternal Health
HIV
Immunization tracking
National organizations vary in their maturity for terminology governance
Use-cases often must support specific terminologies, e.g., international standards, or historical local dictionaries

20. National Selections Notes:
Domain
Ethiopia
Nepal
Nigeria
Philippines
Rwanda
South
Africa
Tanzania
Thailand Dx
ICD-10 Px
local
CCHI
CPT
ICD-9
Lab
LOINC
Local
(map to LOINC) Rx
ATC
CVX
SNOMED
Devices
UMDNS
Billing
Notes:
All selections should be considered in development
All Code Systems should be interpreted as national subsets

21. Terminology Services
A typical OHIE Terminology Services component consists of:
A central repository/authority of the datasets needed by the HIE:
Code Systems
Value Sets
A set of public interfaces (APIs) for accessing these datasets (the “services”) by:
Other OHIE components
External, e.g., PoS, applications

22. The DATIM Experience Supporting Indicator Reporting
Annah Ngaruro, MS, CISSP, PMP
Annah Ngaruro, MS, CISSP, PMP

23. The President’s Emergency Plan for AIDS Relief (PEPFAR) Strategy
PEPFAR’s strategy goal: To reach sustainable control of the HIV/AIDS epidemic through the pillars of transparency, accountability, and impact
How: By collecting and using data in the most granular manner (disaggregated by sex, age, and at the facility level) to do the right things, in the right places, and right now within the highest HIV-burdened populations and geographic locations
ICF proprietary and confidential. Do not copy, distribute, or disclose.

24. DATIM: Supporting PEPFAR’s Strategy
DATIM is the global system used by PEPFAR to collect data on monitoring, evaluation, and reporting; site improvement monitoring; and expenditure analysis.
Collects data from 55 countries
Went live in 2015
Has more than 10K users
Provides annual, semi-annual, and quarterly reporting
ICF proprietary and confidential. Do not copy, distribute, or disclose.

25. Data Exchange: Addressing the Gap
Reduce data collection burden: Collect once, used by many
Provide timely and accurate meta data necessary to perform data exchange. All data values in DATIM are associated with these four metadata dimensions:
Where: Site
What: indicator + disaggregation
When: Period
Who: U.S. Government funding mechanism
Meet country-specific data needs: Going beyond PEPFAR data
Lay the foundation for in-country data exchange infrastructure: Facilitate data exchange with respective Ministries of Health
ICF proprietary and confidential. Do not copy, distribute, or disclose.

26. Data Exchange Solution: DATIM4U
Is a standalone data exchange-enabled version of DATIM
Stands for DATIM for Operating Units
Designed for PEPFAR country teams (operating units)
Supports monitoring, evaluation, and reporting results and targets data
Transmits site and data sent to DATIM using the OpenHIE (OHIE) data exchange platform
ICF proprietary and confidential. Do not copy, distribute, or disclose.

27. DATIM4U: Out of the Box Key Features
Preconfigured components to meet PEPFAR reporting requirements
Automated data exchange: (1) quarterly reporting of data to DATIM (the global reporting system) at the push of a button; (2) meta data synchronization of site lists, implementing mechanisms, and up-to-date versions of indicators and disaggregates
Industry-standard health management information system platform (i.e., DHIS2)
A data exchange infrastructure using OHIE
Standards-based components using ADX, CSD, and ITI-73
ICF proprietary and confidential. Do not copy, distribute, or disclose.

28. DATIM4U Status
Conducted a successful year-long pilot that demonstrated the platform’s technical feasibility and utility
Is fully operational in one country
Used pilot feedback to optimize DHIS2 and OHIE components
Developed extensive self-service documentation
Built a data exchange community of practice
Will be adopted by additional countries in 2018
ICF proprietary and confidential. Do not copy, distribute, or disclose.

29. Challenges Documentation gap
Extensive hands-on support from U.S.-based team
Tight coupling with DATIM
Ever-changing PEPFAR reporting needs
Local skills gap to support the variety of technology components
Limited number of OHIE subject matter experts
ICF proprietary and confidential. Do not copy, distribute, or disclose.

30. Thank You!
Annah Ngaruro, MS, CISSP, PMP
Annah Ngaruro, MS, CISSP, PMP

31. HIV Case-Based Surveillance
A use case for OpenHIE in global public health
Eric-Jan Manders
Center for Global Health, Division of Global HIV and TB
Health Informatics, Data Management, and Statistics Branch
Health Information Systems Team
American Medical Informatics Association, Fall Symposium
7 Nov 2017, Washington DC
Center for Global Health
Division of Global HIV/AIDS and TB

32. Outline HIV case-based surveillance Informatics challenges in HIV CBS
On the critical path to controlling the HIV epidemic
Informatics challenges in HIV CBS
Health Information Exchange to support HIV CBS
Current Work
Next Steps

33. HIV care continuum: strategic information measures and the notion of epidemic control
Context of the global HIV epidemic in two slides. Not completely sure if that’s possible, we’ll find out from questions later
WHO laid out a high level subpopulation grouping to help categorize how HIV program services are organized.
Program delivery is then organized to reach programmatic targets for these groups, where the objective is to reach as many people as possible with the full range of services. In the implementation of the HIV program interventions some patients are not reached in the complete set of interventions, so this is a “leaky cascade.” program planning and implementation is driven by resource allocation and program management interventions to further target the gaps.
UNAIDS has set targets for the different sub-population groups, with a timeline, based on modeling and projections on what is needed to reach epidemic control, a compound performance metric reflecting systematic and persistence trends in program response
Target setting has been a part of the global response to HIV since the beginnings of the international response. It is worth noting that we are in a different phase now, bit different. Now, the final target is a true health outcome target, the result of availability of a direct measure of viral suppression, which in turn indicates that the patient is indeed living with a managed chronic condition. 100% of HIV+ people in the viral suppression box effectively interrupts HIV transmission at population level.
There are of course challenges with this way of performance driven program planning. To direct the program interventions properly you need disaggregations for the indicators, so that you can target more specifically, eg. Based on geograhypy, age or sex
Challenges,
First, you need accurate patient counts to make sure you don’t count patients multiple times, in the global HIV context impacted by a life long episode of care, and a mobile population, making robust patient identification a challenge.
Second, if you are not reaching your targets and you can’t determine which program intervention to tweak next. You need to look more closely at characteristics of the patients that don’t fall in your target bins.
In short, this type of program monitoring doesn’t get you everything you need to know.
World Health Organization, Consolidated strategic information guidelines for HIV in the health sector, 2015

34. HIV Case-based surveillance On the path to epidemic-control
Tailor HIV program interventions to evolving dynamics of the epidemic
Understand HIV disease progression over time
Describe epidemic profile beyond performance indicators
UNAIDS: HIV presents as multiple local/regional epidemics, not one global epidemic
Surveillance challenge – detect and respond
HIV Surveillance strategy
HIV case-based surveillance is a component of a comprehensive strategy

35. HIV Case-based surveillance On the path to epidemic-control (2)
What is HIV case-based surveillance
Routine tracking of individual cases over time
From confirmed HIV diagnosis
Through a life-long episode of care
Defined public health use of patient level data
Detect and report events of public health interest, that may require public health action
Use data for planning prevention and response
What HIV case-based surveillance is not
Exploratory data analysis
Research
Events of interest:
We’ll look at those in a bit more detail next
Evaluation criteria
CDC bread and butter, there is a whole guideline on this
What HIV case-based surveillance is not
Important to distinguish because
any information system could be defined to support multiple use cases, with different complexity
The context of handling confidential information is different in different data use scenarios

36. HIV care continuum Sentinel events in the “clinical cascade”
The care continuum has multiple events that are important to monitor at population level
Recognize the corresponding subpopulation bins from the WHO groupings
Reflects corresponding indicator definitions
Can enhance with specific additional events
Can enhance with time-to-event analysis
This is a timeline but
Can have multiple cycles of lack of viral suppression and back to suppression
Partially ordered list of events, we may observe events out of order
Can enhance with other key public health issues or co-morbitities that intersect with HIV program implementation
Episodes of TB
Interrelation of HIV care with maternal child health
Effects of long term exposure to antiretroviral meds
Emergence of drug resistance, and interventions.
Note that the origins of this are in the separate inclusion of reporting conditions for
HIV infection and HIV disease (what is more commonly known as AIDS)

37. HIV case-based surveillance Informatics Challenges
Increasing volume and complexity of data
Implementation scale & design
Uptake of EMR in high burden settings
Large scale databases of Viral Load data
New program elements or design – test and start
New technologies
HIV testing assays – measure recency of infection
HIV Viral load measurements decentralized
Integration of other data sources
Responsiveness
How timely can / should we move case data for public health use
Patient Identification
Patient mobility challenges robust patient identification
Here we are at the Informatics Challenges, finally
Implementation scale and design
Evidence based, Necessity driven
Volume and complexity increasing
Other data sources
National laboratory database for Viral Load data

38. WHO guidelines 2017 HIV Case based Surveillance Public Health Capacity
Policy environment
Case reporting mandate
Governance
Informatics Component
Leveraging EMR uptake
Patient Identification
Information Architecture
Data repository
Case report form
Interoperability
High level guidance
Guidance evolves previously exisiting guidance on HIV specific patient monitoring systems
Extends this with guidance on HIV case-based surveillance
WHO guidance us very high level, starting point for a country level process on implementation.

39. WHO guidance introduces the now familiar OpenHIE architecture figure as a recommended reference for achieving interoperable solutions for handling patient level data Including to enable and facilitate HIV case reporting.
It is clear that Implementation of HIV services can benefit from HIE implementation in multiple ways
Non clinical service elements, including logistics, and supply chain management,
Program monitoring – currently in progress in the PEPFAR context
Clinical service and care coordination
From experience in country HIV programs where CDC provides technical assistance, current activities at implementing interoperable solutions begin to show essential services needed, and limitations of home grown point to point interoperable applications

40. Leveraging Health Information Exchange
Address multiple interoperability challenges in a common framework
EMR, Laboratory, CRVS, Testing services
Stop short of implementing care coordination
Accommodate robust patient identification
The patient registry is key to establish longitudinal record
Demands on matching accuracy are not the same as for care coordination
Align investments in HIV information systems with country strategy for national health information infrastructure
HIE is becoming a strategic aim for countries
Creates a path for integrating HIV investments with emerging other public health priorities

41. Current Work HIV CBS demonstration with OpenHIE
Informed by
Country pilots, and preliminary implementation activities
Country planning activities around existing national infrastructure elements
Objectives
Demonstrate EMR based HIV case based surveillance using OpenHIE
Standards based message format for an HIV electronic CRF
Constructing a longitudinal case record, with identify matching
Status
Outlined an approach for an EMR based HIV caser reporting module
Influenced by the public health informatics institute “HER toolkit”
See AMIA 2017 poster presentation:
Global HIV Case Surveillance Using Electronic Medical Records (EMR) Data
Lisa A. Murie et al
Development work with Regenstrief Institute
Implement a case reporting module in OpenMRS using a CDA template
Configuration of OpenHIE to support case based surveillance workflow

42. Minimal HIE supporting HIV case-based surveillance
Client
Testing
Care
laboratory
Client registry
Person matching
HIM
Interoperability services
ClinicalData Store
Longitudinal Record
Surveillance data mart
Trigger and dataset definitions
Control clinical data messaging
Secure data environment controls access to patient identity

43. Current Status Different country positions/approaches
Incorporating OpenHIE as one alternative to consider in national implementation guidance for implementation of HIV CBS
no concrete decision on implementation plan
Adopting OpenHIE for HIV program implementation where care coordination is the primary motivation
Development/planning in early phase, no live pilot projects yet
OpenHIE not yet considered
Leveraging platform homogeneity on the EMR side
Countries interested in HIE typically mention OpenHIE.
In most cases these countries also have a presence of OPenMRS in country
Range of maturity in technical capacity is not new
Combined with range of maturity of policy environment needs careful dialogue

44. Current opportunities and challenges emerging
Broad range of maturity in capability
technical – OpenHIE introduces a complex technology stack
Policy – Is there a national eHealth policy document?
Does it adequately cover the HIV case based surveillance needs
Existing approaches/investments to point-to-point interoperability difficult to dislodge
Transition paths from legacy tools difficult to envision
Demonstration system facilitates dialogue around what-if implementation scenarios

45. Next Steps Develop more complete data use demonstrations
Use simulated data to demonstrate the HIV CBS workflow in a range of epidemic scenarios
Establish the HIV CBS data mart/repository outside the HIE to demonstrate the data analytics
Continue dialogue with country governments that intend to implement both HIE and HIV CBS on how to establish the right policy environment and needed informatics capacity.

46. THANK YOU
For more information please contact Centers for Disease Control and Prevention
1600 Clifton Road NE, Atlanta, GA
Telephone: CDC-INFO ( )/TTY:
Web:
The findings and statements in this report are those of the authors and do not necessarily represent the official position of the Centers for Disease Control and Prevention.
Center for Global Health
Division of Global HIIV/AIDS (DGHA)