Notice D

Notice D for promoting investments in digital health global goods

Printable Application Content with Comments

Use your browser's print function to output application content only, with each application starting a new page. Print to Adobe PDF to produce a file. (Note: Chrome and IE9 do not support starting a new page for each application.)

EMR DHIS2 Connector

Two-sentence overview: 

The goal of this project is to connect Electronic Medical Record (Bahmni) to DHIS2 to allow for a longitudinal view of patient-level data and better assess project implementation, coverage, and impact. The connector will be built and tested through an HIV linkage to care project based in Zimbabwe that tracks clients across different locations and service provision.

Executive summary: 

Population Services International (PSI) would like to partner with ThoughtWorks to develop a "connector" between DHIS2, a health management information system (MIS), and electronic medical record tools, ie Bahmni.  The connector will make it easy to send Electronic Medical Record (EMR) data to DHIS2 allowing health program managers to quickly generate dynamic and powerful client profiles and information to better communicate data and inform health program strategy.  

 

This proposed connector actively supports progress against the Global Goods Maturity Model for Digital Health Software Tools. This connector promotes interoperability and data accessibility by providing a means for data to be more readily visualized and understood. The connector also has global utility as both ministries of health and health organizations both already use DHIS2 as an MIS and EMR tools like Bahmni.

 

Over 60 countries and 40+ organizations are using DHIS2 as its management information system.  DHIS2 helps governments and health organizations like PSI to manage their operations more effectively, monitor processes, and improve communication. PSI is the largest NGO implementer of DHIS2 and works closely with UiO to further develop the platform.  

 

Electronic Medical Record tools like Bahmni provide a space where users can record confidential client information and create long term and complete records of health history without having to depend on information technology staff or database administrators. Via this proposed connector, the data will be pulled directly from Electronic Records to DHIS2. Any Electronic Medical Record tool would benefit from the option of having a DHIS2 connector.  

 

As proof of concept that EMR data can easily be imported into DHIS2, we propose to build a simple DHIS2 connector for Bahmni. Bahmni is already free  and open source. There is currently no connector for DHIS2 in Bahmni. Off-the-shelf Electronic Medical Record tools are easy-to-use, impactful, and effective tools for health ministries and health organizations. Data storage and analysis features in DHIS2 could provide more in-depth technical information on clients to allow users a more in-depth idea of client profile, tracking across the continuum, and linkage to care.

Consortium Team: 

About PSI team:

Role: Project Manager

PSI is a leading global health organization with programs targeting malaria, FP, RH, and HIV/AIDS and more. Active in more than 65 countries, PSI is a thought leader in DHIS2, implementing DHIS2 across its platforms and supporting Ministries of Health and partners in 20 countries to design HMIS, using DHIS2. PSI is a global leader in DHIS2 implementation and using data for decision-making.  Through our very close collaboration and significant influence with the University of Oslo (developers of DHIS2), we have directly proposed and influenced the development of features that benefit the entire community of DHIS2 users, including 40+ MOHs and NGOs using the platform. PSI received InsideNGO’s Operational Excellence Award Winner for Information Technology in 2015 and was one of the founding partners of the annual DHIS2 Symposium, the only DHIS2 conference held in the United States.

About ThoughtWorks:

Role: Developer

ThoughtWorks is a software company and a community of passionate, purpose-led individuals. At ThoughtWorks, we think disruptively to deliver technology to address our clients' toughest challenges, all while seeking to revolutionize the IT industry and create positive social change.

ThoughtWorks Global Health experience:

ThoughtWorks has a long experience in creating and contributing to technology for social needs, especially in Global Health. Bahmni (an EMR based on OpenMRS) was created by ThoughtWorks as a free open-source software and is now used in over 40 countries and is regarded as a global good software. A concept of Shared Health Record (SHR) and  Health Information Exchange (HIE) was created and demonstrated for Ministry of Health, Bangladesh by ThoughtWorks.ThoughtWorks was the development partner in delivering the 1st version of OpenLMIS software, which is a free open-source logistics management software. Please refer to other work of ThoughtWorks in global health at the link .

Geographic Reach: 

PSI has deployed DHIS2 in over 35 countries, including Angola, Benin, Burundi, Cambodia, Cameroon, Cote d'Ivoice, Dominican Republic, DRC, El Salvador, Ethiopia, Ghana, Guatemala, Haiti, Kenya, Laos, Madagascar, Malawi, Mali, Mozambique, Myanmar, Nepal, Nicaragua, Niger, Nigeria, Somaliland, South Africa, Tanzania, Uganda, Vietnam, Zambia, and Zimbabwe.

PSI and Thoughtworks have deployed Bahnmi in Zimbabwe. 

WHO Classification: 
Electronic medical record
Application Status: 
In Scope - withdraw
Application Tags: 
interoperability
FHIR
EMR
HIV / 90-90-90
electronichealthrecord

Comments

I'm not sure this is addressing patient level reporting.

Thanks for submitting this, can you outline how the proposal aims to address or support the use cases/data flows suggested and or supported whitepaper in the call?

Thank you for the update, does this build on any of the existing OpenMRS DHIS2 reporting modules? How will this leverage the Patient Level Monitoring approach to achieve this outcome?

What PSI and ThoughtWorks have deployed in Zimbabwe is similar to "Standalone" maturity as described in the White paper, however, our proposal is to move it the "Integrated" maturity, while continuing to use and validate our approach on the ground in Zimbabwe.

During the process of moving to the "Integrated" maturity, we will have to establish the FHIR server and CQL engine (as described in the Whitepaper to enable Patient level monitoring.

OCL FHIR support, metadata publication and presentation for Patient Level Indicator Reporting

Two-sentence overview: 

We propose to enhance the Open Concept Lab (OCL) suite of tools to serve as an authoritative, FHIR-compliant source for codes, value sets, disaggregates, and other metadata required to support the FHIR/mADX approach to aggregate data exchange. OCL is actively supporting a proof of concept for aggregate data exchange using the TX_PVLS indicator and would use this award to build out FHIR terminology services functionality, publish all metadata needed by the point of service, health information exchange and data warehouse layers, and to develop a thin-client web interface for browsing and searching this metadata.

Executive summary: 

This award would be used for the following: 1. Build a FHIR terminology services layer onto the existing OCL terminology server, specifically the FHIR CodeSystem and ValueSet resources. * OCL would provide FHIR-based code/code system lookups, validations, and value set expansions that would be used by the CQL execution engine in the HIE layer. * Optionally, OCL would provide point of service systems, such as OpenMRS, with access to the metadata needed to capture data in a format compatible with the aggregate data exchange process and to prepare FHIR messages. * Along with a FHIR Measure, OCL would have all the metadata required to set up a data warehouse or aggregate reporting system, such as DHIS2, to store the results of a FHIR Measure Report. 2. Model and publish definitions for all codes, value sets, disaggregates, and other metadata required to support the aggregate data exchange process. * The model to represent these definitions in OCL was already implemented for the TX_PVLS proof of concept with PEPFAR. * Optionally, store links to FHIR Measure resources in the definitions of the corresponding measures published in OCL, so that client systems may easily access the full package of metadata needed to evaluate a measure regardless of which service they access first. 3. Enhance the OCL Metadata Browser Prototype to support intuitive browsing, searching and downloading of all metadata published to OCL as part of this project and easy access to view or download the associated FHIR resources. * The OCL Metadata Browser (currently in development) is designed to be the primary method for browsing, searching, and visualizing metadata published in OCL. It is an open-source, ReactJS tool that can be used in the cloud or customized for a local implementation. It would be enhanced for this project to provide intuitive, hierarchical navigation of indicator metadata. 4. Demonstrate OCL terminology service facilitating the aggregate data exchange workflow with a selected point of service system. * We will be able to demonstrate the full workflow with a selected point of service system assuming that compatible HIE and Data Warehouse components are available. Additional information to be added soon.

Consortium Team: 

Open Concept Lab Regenstrief Institute Apelon

Geographic Reach: 

Ethiopia PEPFAR global implementation CIEL interface terminology publication

WHO Classification: 
Clinical terminology and classifications
Application Status: 
Incomplete
Application Tags: 
interoperability
FHIR
data standards
terminology service

Comments

It's interesting to see the adaption and extension to have FHIR interfaces exposed here. How do you see this working as per ftp://ftp.ihe.net/Quality/2019_2020_YR_13/QRPH%20Technical/Whitepapers/ (from notice). Will be interested in seeing any discussions of how the system is envisaged to play out in the overall solution architecture. Please elaborate the narrative of how the solution will function as per the use-cases.

Is there interface opportunities with this proposal (https://applications.digitalsquare.io/content/integrated-hie-approach-patient-level-indicator-reporting)?

Thanks Carl. Very interested in the apprach that Jembi proposed as well and let me see if I can provide a brief explanation here. A FHIR-enabled OCL would provide a level of support for all 3 scenarios (standalone, paired, integrated) and for all 3 levels of systems (POS, HIE, and HMIS/DW), and we'll elaborate on these in the concept note. At the most basic level, OCL would serve as a reference for implementers and developers of the codes, value sets and indicator metadata involved in a transaction. This could be, for example, OpenIMIS building its data model against this metadata. A step up from there would be OpenMRS using the OCL Subscription Module to actually subscribe to the required codes (as specified in the minimum data set message (MDSM)), pulling them into its local concept dictionary. A third model would be using OCL to map a local data model to the MDSM, enabling automated metadata transformation, which could be used to perform ETL on the local data to get it into the required format. Within the HIE, where the FHIR measure is actually evaluated, OCL would provide structured indicator metadata, which could be used by a CQL execution engine, for example, to lookup and validate the codes from the relevant value sets for the indicator being evaluated. In the PEPFER TX_PVLS proof of concept, OCL exposes the indicator reference definition, the data element definitions, and the disags (category/category options in DHIS2) along with the expressions used to filter data from the POS for each disag (e.g. the expression for the age band, gender, etc.). Hope this all helps!

Interesting -- this project plus the FHIR-SmileCDR one could be "available" artifacts in our Policy and Artifact Generator Tool -- (see my question on semantics at the FHIR-SmileCDR comments section) -- 

Hi Alvin- Is there a FHIR SmileCDR concept? I don't see it in the list of applications but maybe I'm missing something! Is the Policy and Artifact generator tool a service of AeHIN? Could you provide a link? Thank you!

What's up it's me, I am also visiting this web site on a regular basis, this site is actually nice and the users are truly sharing nice thoughts.

FYI in the spirit of collaboration, we have joined forces with Jembi, OpenMRS and Bluesquare on the concept note "Towards an Integrated HIE Approach to Patient-Level Indicator Reporting" (https://applications.digitalsquare.io/content/towards-integrated-hie-approach-patient-level-indicator-reporting)

This means that we are no longer moving forward with this independent concept note. Thanks!

OpenMRS Patient Level Indicator Reporting Modules

Two-sentence overview: 

In support of the use of longitudinal patient data for national level monitoring and evaluation, OpenMRS aims to leverage existing work and introduce two OpenMRS indicator reporting modules. One module will perform indicator calculations and transmits results using mADX messaging, while the second will submit relevant data using FHIR resources to a health information exchange (HIE).

Consortium Team: 

In addition to being an open source EMR, OpenMRS is an open source community that functions as a consortium. As such, the community seeks to engage and motivate volunteers and organizations who actively contribute to all aspects of the software development and implementation process. 

The OpenMRS community provides the following:

a) community team members with technical skills and experience in project management, subject matter expertise, business analysis, development, documentation, and quality assurance; mentorship; access to community best practices; and publicity and outreach.

b) community support from OpenMRS leadership, including a dedicated community director and technical project manager. Additional examples of support include community meetings, such as design forums, OpenMRS university sessions, the annual Implementer’s meeting, hackathons, and programmatic support those working on specific OpenMRS projects/modules.

c) operational and infrastructure support. This takes the the form of communication channels (Talk, Wiki, IRC channel/Telegram, audio/video conferencing technology), software development tools (JIRA, github, server hosting), and other operational support.

OpenMRS is open to collaborating with organizations working on complementary components of proposed technical solutions.

WHO Classification: 
Electronic medical record
Application Status: 
In Scope - withdraw
Application Tags: 
community engagement
FHIR
point of service
EMR

Comments

Do you see this leveraging and or working with any of the discussions and ideas in the OCL work? https://applications.digitalsquare.io/content/ocl-fhir-support-metadata-publication-and-presentation-patient-level-indicator-reporting 

Is there envisaged interface opportunities with this proposal (https://applications.digitalsquare.io/content/integrated-hie-approach-patient-level-indicator-reporting)?

Policy and Artifact Generator for Integrating Patient-level Indicators Reporting Systems into the National eHealth Program

Two-sentence overview: 

Ministries of Health in Asia have, to some extent, established patient-level indicator reporting systems, albeit fragmented, over the years. This Policy and Artifact Generator Tool consolidates the knowledge base from various frameworks, collects current architectural picture of the country, and creates policies and artifacts which countries can use to establish the foundations for interoperable digital health systems. 

Executive summary: 

Since its launch in 2011, the Asia eHealth Information Network, as a community of eHealth advocates in the public sector, has seen the growth of electronic health information systems among its member countries. Due to the decreased costs of connectivity and technology, these systems have easily propagated. Yet information fragmentation persists. Despite the availability of patient-level indicator reporting systems, many Ministries of Health still grapple with interoperability, accuracy, completeness, timeliness, and availability of data for decision-making.

Globally, various efforts have emerged that try to help countries with their national eHealth program. The WHO-ITU National eHealth Strategy Toolkit helped countries understand the major components of an eHealth program and how to craft a strategy. Other partners like DIAL, Broadband Commission, OpenHIE, etc have also created their own artifacts that aim to make it easy for developing countries to establish robust health information systems at a national scale. Yet despite these frameworks, countries remain challenged with integrating data from patient-level indicator reporting systems for decision-making.

Recognizing this, AeHIN members are collaborating to create an easy to use tool that guides countries in the development of local policies and artifacts which they will need to build their foundations.

The software tool guides policymaker and technologists through a workflow from governance to architecture to program management to standards.

The output will be country-specific policies and artifacts which the MOH can distribute to its stakeholders especially those maintaining patient-level indicator reporting systems. With the policies and artifacts, the stakeholders will now have an understanding of what the government requires, and how they can contribute to the national eHealth program.

 

<name of country>

<Governance>

<national eHealth focal point/name/address>

<name of strategic level eHealth governance structure>

<name of leader/designation>

<name of member/designation>*

<name of tactical level eHealth governance structure>

<name of leader/designation>

<name of member/designation>*

<Architecture>

<name of architecture>

<name of client registry>

<name of client registry focal point>

<name of client registry>

<name of client registry focal point>

<name of client registry>

<name of client registry focal point>

<name of client registry>

<name of client registry focal point>

<Digital Health Atlas entry ID>

<name of provider registry>

<name of provider registry focal point>

<Digital Health Atlas entry ID>

<name of facility registry>

<name of facility registry focal point>

<Digital Health Atlas entry ID>

<name of terminology service>

<name of terminology service focal point>

<Digital Health Atlas entry ID>

<name of terminology service>

<name of terminology service focal point>

<Digital Health Atlas entry ID>

<name of interoperability layer>

<name of interoperability layer focal point>

<Digital Health Atlas entry ID>

<name of shared health record>

<name of shared health record focal point>

<Digital Health Atlas entry ID>

<name of health management information system>

<name of health management information system focal point>

<Digital Health Atlas entry ID>

<name of patient-level indicator reporting system>*

<name of patient-level indicator reporting system>

<Digital Health Atlas entry ID>

Consortium Team: 

World Health Organization

Digital Impact Alliance (tbc)

OpenHIE (tbc)

Health Data Collaborative (tbc)

ITU (tbc)

ISACA (tbc)

 

Digital Health Atlas: 

N/A

Geographic Reach: 

n.a.

WHO Classification: 
Shared Health Record and health information repositories
Application Status: 
In Scope - withdraw
Application Tags: 
openhie
governance
universal health coveage
digital transformation
electronichealthrecord

Comments

Hi Team,

The concept note isn't talking about how it is addressing the call for the Patient-level Indicator Reporting and seems to be looking to support the meeting. This call for applications is themed to address a particular area (Patient-level Indicator Reporting).

Can you please unpack and or realign the concept to talk to this.

Working on this over weekend -- 

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: 

Global

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

Comments

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.

Towards an Integrated HIE Approach to Patient-Level Indicator Reporting

Two-sentence overview: 

To support with an integrated approach to patient level monitoring, we propose the use of a health information exchange that supports onboarding of multiple digital health systems through HL7 FHIR-based interfaces, providing a common way to connect and register data to a longitudinal client record, on which indicator calculations are performed.  

This work will be achieved through a consortium of partners working together on a shared vision and architecture, leveraging each partner’s individual strengths while limiting overlap, and optimising investment through an integrated, extensible approach, enhancing existing global goods towards a solution that supports multiple Point of Service applications and Health Information Exchange components able to support patient-level indicator reporting.

Executive summary: 

The Digital Square investment will be used to bring together a consortium of partners to collaborate on solution to patient-level monitoring that is appropriate and scalable for low and middle income countries (LMICs). We propose the use of a standards-based architectural framework and integrated solutions to patient-level monitoring. Our vision of an integrated approach adopts the use of international architectural patterns (OpenHIE) to provide a mature solution that is both instantiable and reusable, through the use of an extensible framework able to support a multitude of Point of Service (PoS) applications in an integrated patient level monitoring system.

The consortium aims to use the Digital Square investment to support FHIR profiling activities to specify the data model, resource mappings, terminologies and indicator definitions relevant to the priority use case, supporting the development of HL7 FHIR interfaces in the selected PoS applications and IOL, and demonstrating the end-to-end feasibility of the paired and integrated approaches to extracting indicator data from a Minimum Data Set Message or a shared longitudinal data store.

Consortium Team: 

Jembi Health Systems will lead and oversee a consortium that also includes OpenMRS Inc., BlueSquare, Open Concept Lab (OCL), and IntelliSOFT. In this role, Jembi will set up a central Health Information Exchange (HIE) sandbox for testing, and ensure the platform provides FHIR-based end points for Point of Service applications to submit demographic and clinical data, and enable extraction of indicators from a longitudinal FHIR server. OpenMRS Inc. will work to ensure OpenMRS supports integrated patient-level monitoring architecture, and similarly, BlueSquare will focus on openIMIS, Open Concept Lab on the OCL suite of tools, and IntelliSOFT on Bahmni.

Jembi is an African non-profit company specialising in digital health and open source software development and implementation. Jembi has a successful track record developing and implementing open source software in the health sector, including in a number of African countries. It has contributed to many open-source software development projects and communities of practice, including OpenMRS, Bahmni, OpenHIM, HEARTH and OpenHIE. Jembi is registered and headquartered in South Africa with country offices in Mozambique, Rwanda and Zambia. 

OpenMRS Inc. provides oversight on the open source EMR, OpenMRS, and its associated community, which seeks to engage and motivate contributors and supporting organizations who actively engage in all aspects of the software development and implementation process. 

Bluesquare is a Belgian data company founded in 2012, focused on digital health in emerging economies around the globe. Bluesquare, thanks to its proven experience in designing and leading IT products in use in UHC sector, will reinforce the development team and ensure that the high level architecture is translated without distortion into concrete software components. Thanks to its involvement in the openIMIS re-architecture, which includes the provision of a native HL7 FHIR interface, Bluesquare will also facilitate a good integration with the coming openIMIS platform.

Open Concept Lab (OCL) provides an open-source suite of tools to support terminology and metadata management, including the OCL Terminology Service, OCL Metadata Browser, and OCL for OpenMRS Authoring Interface. OCL is recognized as a digital global good and works in close partnership with the OpenHIE and OpenMRS communities. OCL is actively supporting PEPFAR’s demonstration project for TX_PVLS to evaluate indicators directly from patient-level data.

IntelliSOFT Consulting Limited is a wholly owned Kenyan company with more than 8 years of experience. As a technology company, IntelliSOFT has deliberately focused on designing, developing, implementing, supporting and maintaining digital health solutions, particularly for Low to Medium-Income Countries. They have extensive experience in implementing appropriate digital health solutions running either on OpenMRS or Bahmni in resource constrained environments. IntellISOFT’s past and current projects are spread across Africa covering Kenya, Uganda, Tanzania, Zambia, Sierra Leone, Rwanda, Ethiopia, Mozambique & Zimbabwe.

Geographic Reach: 

OpenHIM: Rwanda, Tanzania, South Africa, Mozambique, Lesotho, Liberia, as well as PEPFAR recipient countries and DATIM reporting countries.

OpenMRS: Albania, Argentina, Armenia, Australia, Bangladesh, Belarus, Bhutan, Bolivia, Botswana, Brazil, Burundi, Cambodia, Cameroon, Chile, Colombia, D.R.C., Ecuador, Ethiopia, Gambia, Georgia, Ghana, Haiti, Honduras, Hungary, India, Indonesia, Israel, Japan, Jordan, Kazakhstan, Kenya, Kiribati, Kyrgyzstan, Laos, Lesotho, Liberia, Libya, Madagascar, Malawi, Malaysia, Mali, Mexico, Mozambique, Myanmar, Nepal, Nicaragua, Nigeria, Pakistan, Peru, Philippines, Rwanda, Senegal, Sierra Leone, South Africa, Spain, Sri Lanka, Svalbard, Tajikistan, Tanzania, Uganda, Ukraine, United States

openIMIS: Nepal, Tanzania

OCL: Ethiopia, PEPFAR global implementation, CIEL interface terminology publication

Bahmni: Nepal, India, Lesotho, Bangladesh, Sierra Leone, Uganda, Pakistan, South Africa, Zambia, Cambodia, Haiti, Kenya, Mozambique

WHO Classification: 
Data interchange interoperability and accessibility
Application Status: 
Pending Review & Investment
Application Tags: 
openhie
FHIR
interoperability layer
shared health record
point of service

Comments

mADX on FHIR on Android

Two-sentence overview: 

Most mobile health reporting is generated server side or in a HMIS. Our goal is to provide a standardized way for health apps to make real-time reports accessible to health workers offline for better decision making. We will create a set of open source libraries, expanding HAPI FHIR and CQL tools, to enable Android based apps to quickly generate health reports offline using a standards based approach defined in the mADX Profile.

Executive summary: 

The digital health ecosystem is rapidly maturing with mobile solutions that support the capture of health services delivered by frontline health workers. While data collection in these apps is quite mature, in-app reporting is still very limited with most solutions limited to pushing reports into a Health Management Information System (HMIS) from the central system.

There are two major problems that we aim to address. First, the majority of mobile frontline health systems push report generation to a central system that requires internet connectivity instead of providing the capability to generate reports at the point of service. This results in frontline health workers not having access to up-to-date reports offline for decision making. Second, developing performant reporting on low powered mobile is technically challenging and, to date, a standards based approach to address this has not emerged.

Our goal is to develop an open source FHIR standards based reporting stack for offline generation of health reports on Android devices. We will use OpenSRP to implement a reference app using this approach. To achieve this we will adapt a reporting architecture we developed for OpenSRP in-app reporting.

Consortium Team: 

Ona is a technical social enterprise focused on global health, based in the United States & Nairobi, Kenya. Ona was founded in 2013 and has been in operation for close to 6 years. The company has a 25-person development team which includes software developers, software architects, and machine learning experts. Ona has extensive experience designing, developing and implementing health information systems that are used at national scale and integrate with existing government health information systems and open standards. Ona has developed numerous open source standard tools and libraries in the space that are used by mobile teams to add functionality to their existing technologies. Ona serves as the technical lead for OpenSRP, having co-created the platform with the World Health Organization.

As an organization we have extensive experience developing digital health applications for mobile. We are the technical leads and main developers of OpenSRP - a digital health global good that provides service delivery support for frontline health workers. With OpenSRP we currently are supporting large implementations of OpenSRP in Tanzania with Jhpiego, with UNICEF in 5 countries in West Africa and with GAVI and Mastercard in Mauritania. Previously, we supported PATH to use OpenSRP to develop a national electronic immunization registry (EIR) in Zambia. For this we developed extensive in-app reporting, that was used to tally over 100 indicators which were then reported to DHIS2. This work forms the technical foundation for this proposal.

With Akros, Vital Wave and CHAI we are developing Reveal (https://revealprecision.com) a next generation task based service delivery tool developed on top of OpenSRP. Reveal relies heavily on FHIR including supporting FHIR task, planDefinition and location resources. As part of the Reveal work, Ona is developing with Novel-T the geo-widget - an Android SDK that makes it possible to view locations and structures on map and link services to it by clicking on it. The Geo Widget is a global good currently being adopted by DHIS2, CommCare and other popular digital health applications.

Lastly, for the past year we supported Village Reach to help develop a reporting stack using an open source enterprise analytics suite we developed called Canopy. In doing this we got hands on experience using the appropriate R4 FHIR reporting resources that are cited in this application including generating measures, measureReports and libraries. This work also included building organizational capacity in running HAPI FHIR as part of the Canopy stack.

Digital Health Atlas: 

OpenSRP has been cited in two DHA projects:
https://digitalhealthatlas.org/en/-/projects/978/published
https://digitalhealthatlas.org/en/-/projects/890/published

We have also requested that OpenSRP be registerd a a part of the taxonomy (see email attachment)

Geographic Reach: 

Indonesia, Pakistan, Bangladesh, India, Zambia, Tanzania, Kenya, Mauritania

WHO Classification: 
Community-based information system
Final Technical Application: 
Application Status: 
Pending Review & Investment
Application Tags: 
FHIR
universal health coveage
Mobile tools
mhealth
data collection

Comments

Ranga's team at ITINordic is working on some Android+FHIR libraries that you may be able to leverage.
https://github.com/ITINordic
https://www.itinordic.com/what-we-do/

 

Thanks Carl, we'll check it out.

Yes, thanks Carl. We are working on integrating DHIS2 with Programs with a HAPI FHIR. Data is captured on Android devices. We are developing an Android library for HAPI FHIR integration.