Page Comparison

About

This project aims to develop the functionality for OpenMRS to interact with a FHIR-based Facility Registry. The goals of this project are as follows:

1. Enable OpenMRS to act as a client of a Facility Registry service within a Health Information Exchange.

2. Enable OpenMRS to upload and synchronize it's own Location hierarchy with a centralized repository.

For more context, information, and discussion, see the original Talk Post: https://talk.openmrs.org/t/openmrs-support-for-a-fhir-based-facility-registry/34908

Current Status  

Status
colour Yellow title Active

 

Jira Epics:

How does this project fit in with the strategy?

This section elaborates more on the project’s goals relating to how they align with OpenMRS’ goals. Consult the Collaboration Opportunities Dashboard to describe the greater implications and importance to the project. There are additional subsections that can be filled out when relevant to the project. Overall, the idea is to show how advancements with the project can help OpenMRS move forward with expansion of healthcare systems.

Community Strategy

OpenMRS Product Advance

Health Information Systems

OpenMRS is an EMR system, which is an integral point-of-service component of a fully-functional Health Information Exchange. In fact, OpenMRS serves as a reference application of an EMR in OpenHIE's architecture framework. As an EMR, OpenMRS would be required to fulfill a number of responsibilities in terms of communication with other HIE components, of which the Facility Registry (FR) is a key example. Developing the functionality for OpenMRS to communicate with a FR using standard-based workflows would further establish OpenMRS as a key component of a global-goods-based HIE.

Background

A Facility Registry (FR) is a vital component of a Health Information Exchange that stores, manages, and distributes information on a Master Facility List (MFL). Systems and services connected to an HIE can require the services of a FR for referrals, care transfer, continuum of care, logistics, laboratory ordering and resulting, and many other key workflows.

FHIR support for FR workflows is documented as part of IHE's mCSD Profile and Implementation Guide. The mCSD Profile specifies the interactions between Care Service Suppliers and Consumers for finding care services, updating the available care services, and maintaining a MFL. The key resources required for the mCSD use cases and workflows include Location, Organization, Practitioner, PractitionerRole, and HealthService:

 

As an EMR, OpenMRS would need to communicate with the FR primarily as a Care Service Consumer, as outlined in the MFL Use Case. OpenMRS would need to be able to query the FR for the most up-to-date facility list, maintain a local cache of this list, and allow the list to be used in OpenMRS use cases that deal with locations:

• drop down population in UI
• reporting
• referrals
• transfer in/outs
• source of required information - Facility ID (national identifier not internal), Name, Address/Location, Active/Not-active, Services Offered, Facility Type
• etc.

This local representation of the MFL should not interfere with the OpenMRS-specific Location data and Location Hierarchy. 

How to Join

Reach out to us on Talk, Slack on the #fhir channel, or join the FHIR Squad Meetings on Tuesdays!

.

Useful Resources

• https://talk.openmrs.org/t/openmrs-support-for-a-fhir-based-facility-registry/34908
• https://ihe.github.io/ITI.mCSD/

Meet the Members

Project Owner