• Epic Name:
      Support Care Services Update Consumer/Provider for Facility Registries


      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. Though the actual backing communication standards are from HL7's FHIR STU3.

      As part of this work OpenLMIS and Nexleaf's ColdTrace have agreed upon an iterative strategy 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 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:

      1. 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.
      2. Connect to a national Facility Registry and follow it to speed setup, configuration and minimize ongoing maintenance of OpenLMIS.
      3. 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


          Issue links



              • Assignee:
                joshzamor Josh Zamor
                joshzamor Josh Zamor
              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created: