Page Comparison

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

...

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

(copied 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.

...

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)

...