Interface - Facility Lists using Global Standards w/ mCSD

See notes at bottom of Interface - Facility list sync (Direct connectors).

Goals/Scope

To interoperate with other common IT systems in the health space we need to have a shared list of "Facilities" (aka Locations) and a shared unique identifier for them so that we collect and report on data about them in consistent manners across those systems.

To achieve this we should adopt global standards in the health IT space, namely HL7's FHIR STU3 with IHE's mCSD profile.  This is the recommended approach of OpenHIE.

Background

(removed from epic description in OLMIS-3385 and pasted here):

OpenLMIS needs to be configured with a list of Facilities in order to know where stock may be held, where user's have access, etc. This facility list is something that's historically been built into OpenLMIS and continues to exist. When OpenLMIS has its own facility list, and other national health IT systems have their own facility lists, then the ability for multiple systems to interoperate together becomes tedious as updates and cross-walk maps need to be created and maintained to sync multiple different facility lists housed in separate systems.

In OpenHIE Architecture the Facility Registry is a single* source of truth on which "Facilities" (aka Location) exist in the country including a basic hierarchy of where these "Facilities" exist, whom works with them (Organizations), etc. At the very least OpenLMIS desires to leverage the concept of a Facility Registry to speed configuration and ease interoperability. Secondarily if the "facility list" is infact federated in a national IT system (as in OpenLMIS might own the definition of some of the master list - e.g. if OpenLMIS was being run in a country for a charity that had their own health facilities outside the national public facilities), then OpenLMIS would also like to be able to participate in that federated structure.

Supporting being able to follow a Facility Registry is to support the basic profile laid out in [mCSD|https://wiki.ihe.net/index.php/Mobile_Care_Services_Discovery_(mCSD)]. Though the actual backing communication standards are from HL7's [FHIR STU3|https://www.hl7.org/fhir/overview.html].

As part of this work OpenLMIS and Nexleaf's ColdTrace have agreed upon an [iterative strategy|https://docs.google.com/presentation/d/1gMMjrBive1LKsGtSUvUga89naPHByFT-wXX8vpiJ010/edit?usp=sharing] to support Facility Registries, even when national IT systems don't quite have them in place yet. Starting down this path OpenLMIS has created very basic representations of [Location|https://www.hl7.org/fhir/location.html] as a JSON document.

As we move forward we'll need to both be able to produce and consume (the latter being more important):

* Location - started
* Organization
* Bundle

These FHIR Resources which are part of the mCSD profile don't have much use for OpenLMIS:

* Practioner
* PractionerRole
* HealthcareService
* OperationOutcome

There is considerable work in both providing representations and management of these resources, as well as providing all the capabilities laid out in FHIR including XML and JSON representations, and extensive search and caching capabilites. Because of this we'd like to investigate leveraging existing technology to speed our deployment.

Prioritized use cases:

# (/) Provide Facilities and geographic hierarchy as FHIR Location to that OpenLMIS may act as a temporary Facility Registry (without federation or the other FHIR Resources) for interoperability with Coldtrace and others.
# Connect to a national Facility Registry and follow it to speed setup, configuration and minimize ongoing maintenance of OpenLMIS.
# Participate in a federated mCSD Facility Registry with others where the "Locations" that OpenLMIS would provide to others would likely fall be Locations representing stores of stock inside Facilities identified by the national Facility Registry. Presumably this is the same technicaly as a use-case for OpenLMIS to provide a Facility Registry option as apart of it's ref distro where one has yet to be established.

\* single source of truth: facility list definition might be federated

Use case 1: OpenLMIS serving mCSD Locations (Care Service Update Provider)

In this use case, the assumption is that the OpenLMIS implementation is a Care Service Update Provider. OpenLMIS owns an authoritative list of some or all of the Locations and provides those to the federated master facility list management infrastructure. Parts of the facilities that OpenLMIS owns includes supply chain locations like stores, dispensary units.  To support such an implementation with as standard compliant service as possible, OpenLMIS can expose read-only FHIR Location resources. In the OpenHIE Architecture, we anticipate that a mediator will be able to access the FHIR Location resources that are exposed from OpenLMIS and populate the Interlinked registry. 

OpenLMIS v3.4 exposes a partial implementation of Location resource specification from the mCSD profile.  To conform with the mCSD profile, OpenLMIS needs to support the full set of operations related to resources like Location and Organization as outlined in ITI-91. To support these set of interactions, one less expensive option is to use a FHIR server running as a microservice in OpenLMIS. 

Use case 2: OpenLMIS as a consumer of mCSD Locations (Care Service Update Consumer)

Assumes that there is an implementation of an Authoritative Master Facility List that supplies mCSD conforming Location resource. In this case, OpenLMIS needs to be able to consume those Locations and Updates as mCSD update consumer. The Locations from the other owners would need to be created in the OpenLMIS as appropriate entities like geographic zones and facilities. However, In OpenLMIS, no update should be allowed to be made on these Locations that are created and owned by others. 

Comparison of FHIR server options

Assumptions

User Stories

Diagrams

Work breakdown of epic and spikes as of 9/12/18:

8/15 Meeting notes 

Attendees: Ashraf, Elias Muluneh, Chongsun Ahn (Unlicensed), Sam Im (Deactivated)

Recording:  Nikodem Graczewski (Unlicensed), Łukasz Lewczyński (Deactivated), Joanna Szymańska (Deactivated) please listen to this recording to provide background on the work for sprint 106.

8/31 Meeting notes

Attendees: Elias Muluneh, Nikodem Graczewski (Unlicensed), Łukasz Lewczyński (Deactivated), Chongsun Ahn (Unlicensed), Josh Zamor, Sam Im (Deactivated)

Recording here: