Facility Registry Workflows

Owned by Piotr Mankowski
Last updated: Nov 12, 2021 by Jennifer Antilla

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  ACTIVE 

Jira Epics:

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

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:

Alt text 


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