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:
Enable OpenMRS to act as a client of a Facility Registry service within a Health Information Exchange.
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 ACTIVE
Jira Epics:
How does this project fit in with the strategy?
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.
Community Strategy
OpenMRS Product Advance
Health Information Systems
Frontline Healthcare Workers
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.