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

Target release
Epic	OLMIS-3385 - Getting issue details... STATUS
Document status	DRAFTED
Priority	HIGH
eLMIS Status	not Implemented
OpenLMIS Status	not Implemented
PATH
OpenLMIS	Josh Zamor (Deactivated)
JSI	Ashraf Islam (Unlicensed)

Goals/Scope

Note this is an alternative to Interface - Facility list sync (Direct connectors). The principal benefit of this approach over the other is that it would utilize global standards which should provide more turn-key interoperability with health (and later supply chain through embedding GLN in FHIR Location) IT systems.

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

	User Story	Importance	Notes	JIRA Tickets
1	Support mCSD profile	High		OLMIS-4188 - Getting issue details... STATUS OLMIS-5260 - Getting issue details... STATUS OLMIS-5261 - Getting issue details... STATUS OLMIS-5262 - Getting issue details... STATUS OLMIS-5351 - Getting issue details... STATUS
2	OpenLMIS serving mCSD Locations (Care Service Update Provider - Use Case 1)	High
3	OpenLMIS as a consumer of mCSD Locations (Care Service Update Consumer - Use Case 2) Update "Facility Admin" screen to support FHIR Location's shared through a Care Services Update Consumer. AKA follow a facility list / read only. Support sync of OpenLMIS and FHIR resources	High
4	Update Reporting stack to use Location instead of OpenLMIS' Facility	Med	Esp useful if reporting stack is leveraged in communicating to other systems. e.g. in aggregation phase to DHIS2.	Out of scope for this feature - we are only completing Use Case 1 & 2
5	Update "Facility Admin" screen to support Care Services Update Supplier. AKA create federated "Facilities" / Locations inside OpenLMIS and share.	Low	Not needed for simple interop with ERP, Facility Edition, etc so long as the level of definition of "facility" is consistent across systems and nesting isn't needed.	Out of scope for this feature - we are only completing Use Case 1 & 2

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 (Deactivated), Sam Im (Deactivated)

Recording here:

Browser not supported