See notes at bottom of Interface - Facility list sync (Direct connectors).
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
(copied from OLMIS-3385):
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
Assumptions
User Stories
| Title | User Story | Label | 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)
| 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. | |||
| 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. |
Diagrams
Work breakdown of epic and spikes as of 9/12/18:
Comparison of FHIR server options
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: