Notice D

Notice D for promoting investments in digital health global goods

Define Once, Run Anywhere: Portable Indicator Reporting for Multiple Global Goods

Two-sentence overview: 

The consortium will enable multiple Global Goods point of service (PoS) systems, including DHIS2 Tracker, OpenMRS, and OpenLMIS to quickly produce portable, standards-defined indicators based on transactional data. This will be done by strengthening the HAPI FHIR Server ecosystem, the most popular FHIR server in the world, and the FHIR store and API for multiple Global Goods.

Executive summary: 

Multiple Global Goods rely on the immensely popular open source HAPI FHIR Server. This includes the new DHIS2 FHIR Adapter that provides a FHIR interface for Tracker and other features of DHIS2; OpenMRS, OpenSRP, Bahmni, OpenLMIS, and iHRIS v5, in addition to numerous private and public sector products. As HAPI is the most popular reference implementation of FHIR, it is a natural starting point for strengthening Global Goods point-of-service applications to reach even greater scale.

By strengthening the HAPI FHIR Server ecosystem, our approach will enable the large user bases of Global Goods point-of-service systems such as DHIS2, OpenMRS, and OpenLMIS to immediately enjoy automatic indicator generation, and encourage other health applications to become FHIR-compliant too.

Our approach enables multiple FHIR-compliant Global Goods systems to internally and easily produce indicators. We will enable indicator definitions and business logic to be shared, reused, and modified by anyone — no one has to reinvent indicators. Implementers can pull definitions from a central repository, and as raw data is fed into a HAPI server, it can be easily and transparently transformed into indicators and exported into any analytical tool of choice.

Stakeholders will be able to establish and more easily verify, test, and govern national and international repositories of indicators. For example, our approach will enable WHO the flexibility to implement and improve the National Health Workforce Accounts and the Computable Care Guidelines.

Our approach will globally scale the ability of data managers of multiple Global Goods systems to be immediately responsive to the shifting reporting requirements of programs, policies and donors. Utilizing transactional data to build out indicators will expedite reporting, increase transparency and reduce burdens across all health domains. For example, when a health worker identifies a needed PEPFAR report or PEPFAR indicator disaggregates change, they can use a simple spreadsheet to list out required data fields. From the spreadsheet, a software developer can quickly develop a template for FHIR’s server to automatically produce the needed report from the FHIR Data Store, whether the health worker is using DHIS2 Tracker, OpenMRS, OpenLMIS, or any other FHIR-compliant point of service application.

Our approach — to write a report template (indicator definition) once, and instantly use it globally — is possible because the open source HAPI FHIR Server is also a scaled international Global Good. It is used throughout the global FHIR community in both the private and public health sectors. It is the reference implementation of a FHIR server in the Java software language. The consortium’s goal is to implement engines within the HAPI FHIR Server ecosystem to process data-sharing specifications into aggregate indicators, and provide the tests, examples, documentation, and community engagement necessary to reach global scale. The implementation will provide a reference for other implementers to follow in adding Clinical Quality Language for Aggregate Data Exchange (CQL for ADX) support in their FHIR servers.

Our approach solves the problems of both today and tomorrow, as new indicators can be configured instantaneously, and the design enables systems to scale portable, reusable indicators based on transactional data. The FHIR definition of indicators (Measure resources) can be obtained from another source and modified or created then loaded into the HAPI ecosystem. Then the HAPI FHIR Server uses client data to produce indicators (Measure reports) based on the Measure resources. Thus by enhancing a popular reference implementation, we will make it easy for vertical solutions like DHIS2 and OpenMRS to implement CQL for ADX because the shared middleware components will already be built. We will provide the full spectrum of HIV use cases as noted in the HIV-ADX profile for reference and as a testable workflow for other implementations.

Consortium Team: 

IntraHealth International is a global health NGO with a long history in developing successful data tools and digital health applications for health workers and managers. As the developers and core contributors of the iHRIS workforce management solutions, the OpenInfoMan reference product for CSD and Interlinked Registry, as well as the mCSD profile for the FHIR specification, the IntraHealth team brings a passion for open source and open standards. IntraHealth will lead the overall solution development process, relying on its 40-year history of successful project management.

Smile CDR is a Toronto-based company whose mission is to make it easy for health organizations everywhere and of all sizes to deliver interoperable applications quickly. They are transforming the next generation of shared health data by leveraging the standards-based FHIR data model and APIs. Recognized as a global expert in FHIR implementations, Smile CDR is the maintainer of HAPI FHIR, the prevailing open source reference implementation of FHIR worldwide; as well as the developers of Smile CDR, the leading enterprise-grade platform on which regional health exchanges, health systems, hospitals, payers, and application developers rely.

Geographic Reach: 


WHO Classification: 
Data interchange interoperability and accessibility
Application Status: 
Pending Review & Investment
Application Tags: 
interoperability layer


This would be very interesting -- it adopts the FHIR architecture and the SmileCDR implementation as building blocks...Will there be a need for a semantic source like SNOMED to make the combination succeed? Or will the architecture-repository suffice for 80% of the work needed?


What we're proposing wouldn't necessarily need a terminology service in theory, but in practice most use cases would require some terminologies such as SNOMED, LOINC, and/or others.  But that’s just the nature of the data being stored in FHIR from the point of service system, not necessarily from the Measure/MeasureReports, although the CQL would utilize the terminologies that are used by the FHIR resources.  So for the TX_PVLS service example, there would be terminologies associated with that data and the Measure/MeasureReport.

Interesting approach.  If this moves forward, would like to run a POC in our open source CommCare and MoTech to test it out.