Facility Registry Workflows
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 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.
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.
Useful Resources