Session Name: Supply Chain Subcommunity
OHIE18 Event Page -  ohie.org/OHIE18 
Time / Room: 11:15 - 12:15 Faru
Presenter: Craig Appl, Ona
Attendees:
    Oswald Luoga, PATH; interested in standards for supply chain interoperability
    Milton Kaye, Uganda - interested in how supply chain systems can interoperate; how can we move info from supply chain systems to DHIS2  
    Jennifer Shivers, Regenstreir - want to learn more about supply chain for eHealth Architecture Ethiopia project - as a co-leader of OpenHIE architecture, I want to best represent supply chain in the OpenHIE architecture  
    Maganizo Monawe, Malawi - interested in DHIS2 and OpenLMIS interoperability  
    Edwin Nyella, Tanzania, JSI
    Ssanyu  Nyinondi, Tanzania JSI - want to learn more interested because of work in Tanzania interoperability
    Alpha Nsaghurwe, JSI - member of OpenHIE supply chain subcommittee; here to share experience and learn from others (in TZ integrated eLMIS and HMIS/DHIS2 and able to share experience)
    Elias Mululeh, JSI - how can we use existing standards to interface with other systems and re-use the same master data?
    Al Shiferaw, JSI Ethiopia - here to listen and learn about OpenHIE and Ethiopian supply chain
    , Kenya - interest in multiple systems have a common interface
    Hussein Hassan, JSI Tanzania - here to learn and share integration experience
    Jonathan Metzger, JSI - here to learn and find where countries would like assistance
    James Kariuki

    Common Interests/Themes
        1. 
        2. Reporting of products and commodities to DHIS2
        3. Defining how supply chain interoperates - this is the purpose of the supply chain subcommittee (see wiki link)

Purpose
    - Share information about the Supply Chain subcommittee for interested members (https://wiki.ohie.org/display/SUB/Supply+Chain+Subcommunity)
    - Direct them to join the mailing list (https://groups.google.com/forum/?hl=en#!forum/openhie-supply-chain)

Notes:
    - Introduction from participants and role in Supply Chain activities
  • currently iterating on architecture and how point of serive applications interact with OHIE components 
    - Review Purpose
    

    - Overview of LMIS integration with HMIS (eLMIS to DHIS2 in Tanzania) by Alpha
  •     Goal: Compare the service provided with the commodity consumed.
  • We send data from eLMIS to DHIS2. We send consumption, stock-on-hand, and are considering also sending the number of stockout days. We may also send losses and adjustments with reasons.
  • We started with life-saving commodities, then added bed nets, and now are exposing ALL commodoties from ALL programs into DHIS2.
  • Question: Are you modeling products in DHIS2?
  • Answer: In DHIS2, the products are already defined. Once a combination of product and indicator are defined, there are UUID codes for each combination. Those mappings are imported into eLMIS, so eLMIS can translate and send the right data to DHIS2.
  • Question: Are you sending only aggregate information, or each stock transaction?
  • Answer: In Tanzania, we only send aggregate information per facility. (The stock management module of OpenLMIS is not used in Tanzania.) 
  • Question: The indicators you have in DHIS2 to track stock...are you counting how much is there? What kind of indicators are you using?
  • Question: Do you develop an app in DHIS2? Or develop in the LMIS? What is the best way?
  • Answer: In DHIS2 we have different apps designed to collect data. But for this integration, we just use the HIM (mediator) to link the two. Universal HIE is the interoperability tool being used in Tanzania as one of the interoperability layershttps://health-e-link.net/product-suite/universal-hie
  • Epicor9, the Central Medical Store ERP, is also integrated with eLMIS for daily stock status.
  • Question: What are the data elements you share between the LMIS and HMIS domains?
  • Answer: Opening balance, Closing balance, Consumption, Receipts, Losses and Adjustments. Those are the key supply chain fields that come from the supply chain domain and are shared into the health domain (into DHIS2).
  •     Aggregate data exchange is probably what is required first 
  • Important to match the metadata - facility ID 
  • Indicator definitions need to be used in point of service and HMIS
  • OpenMRS -> report -> HMIS might be typical 
  • Question: Are there other examples of clinical or LMIS systems sending aggregate data to DHIS2?
  • Answer: In Zanzibar, mSupply is used, and it sends aggregate numbers (such as an order quantity) to DHIS2.
  • Interoperability layer can be used to facilitate the interaction between systems (It can enrich the data, translate facility information) 
  • Question: How do mappings work? Is there a lookup table in the interoperability layer?
  • Answer: The Interoperability Layer has the ILR (inter-linked registry) called OpenInfoMan. That tool maintains a cache of all those mappings. In the ILR you could define a list of all the facilities and codes and retain that lookup table.
  • How do you maintain that lookup table? 
  • Answer: OpenHIE project governance. It would be manually maintained for now. There were some workflows including basic CRUD events (create, read, update, delete). A future state would be that as soon as you add a facility to eLMIS, you could post a trigger to the OpenHIE system to update it.
  • Maganizo: Regarding standardization, there is a key learning point in the work Tanzania has done. Especially for common systems, like OpenLMIS and DHIS2, there is a key need for standardization. We are talking about putting together requirements specific to OpenLMIS and DHIS2 in our work. If you take these systems out of the box, what do you need to do to make this work? Of course you need the master facility registry and master product lists, but it would be good for this integration to just work out of the box.
  • Al: I don't believe DHIS2 should be a substitute for a full HFR. Doing this could be a short-cut with downsides down the road.
  • James: you need to have your metadata defined in order to send aggregate data.  IHE ADX profile requires three things:  1)  Facility 2) Period 3) Data elements and disaggregations 
  • - DHIS2 can receive an ADX message 
  • - You can use a workflow in the interoperability layer to validate or translate facilities and ensure that the period is correct  
  • - Mediators in the interoperability layer can transform data as well.  We can look at how we might do that 
  • Jennifer: I agree that DHIS2 is not the ultimate home for facilities, but you need to consider your project scope and how the OpenHIE architecture is being applied. Figure out your requirements for facilities, and then determine the tool. Looking at some of the functionality required, DHIS2 might not be the best longer-term solution.
    - Group discussion about Domain overlap if time is available
    - Develop next steps

Next Steps:
  • Continue work on how supply chain fits into the OpenHIE Architecture (join the subcommunity to get involved!)
  • Create an out-of-the-box integration between OpenLMIS and DHIS2 (desired by many attendees)
  • Slides or documentation about Tanzania implementation and data flows and use cases (Alpha, what can you share?)
How to join the OHIE supply chain sub community  
  • No labels