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.