Etherpad Link: https://notes.ohie.org/2018-08-01_Unconference_Faru_1115

• currently iterating on architecture and how point of serive applications interact with OHIE components 

• Next meeting - Aug. 17th, Friday - connection details here - https://wiki.ohie.org/display/resources/Supply+Chain+Subcommunity

•     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 layers.  https://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 

•  - ADX standard https://wiki.ihe.net/index.php/Aggregate_Data_Exchange

• - 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.

• 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?)

• Share GS1 information (slides here: https://docs.google.com/presentation/d/1s23Y-ZhhVVpk9cqezk2Nr4VaRFexzghJohkg7XGT_Nk/edit?usp=sharing) 

• group list https://wiki.ohie.org/display/resources/Mailing+Lists

• Call / meeting schedule https://wiki.ohie.org/display/resources/Supply+Chain+Subcommunity