Interface - Interface with DHIS2

I read through all comments/linked docs referred on the presentation slide deck. I identify more with the comments and sentiments Craig captured in this wiki page, that's why responding through this wiki page.

I'm making an attempt to explain my two cents opinion below (it refers to the slide deck, comments there-in, as well as the comments in this wiki page)

- Facility Registry. It is true that Tanzania eHealth Architecture ask for standard based facility registry. But at this point in time, it is more aspirational, rather than a functional reality. The eco system on which eLMIS is working now with - Epicor, eLMIS, DHIS2 – are not using any facility registry. Epicor enters new customer or does have the capability to import customer accounts (aka Facility codes)  from CSV/Excel files (see – link 1, link 2). Epicor does not have any feature to link with a Facility Registry like Resource Map/OpenHIE. However, a linkage can be established between Epicor and Resource map through developing an intermediate app that will essentially export facility data in CSV/Excel format and importing that in Epicor, in theory. In practical reality this may face additional blocker due to dependency/validation that Epicor may apply, for example, missing required fields, creating a customer account may need more related info such as credit limit, primary contacts, type of customer, preferred delivery mode, etc., which Facility Registry may not have.

In other words, the way that we think about health facility and reporting by a health facility, a commercial ERP application does not think that way, it thinks in terms of customer, vendor, supplier, warehouse, 3PL etc. Also, when there is a need to add a new customer, the process is transaction driven (e.g., a new clinic placing an order for health products from the central warehouse (MSD in Tanzania). Epicor will have faced that transaction first, rather than the Facility Registry application. In all likelihood, Epicor will create a new customer account with all the other profile/financial details it needs to capture about that customer and fulfill that order. Resource map and eLMIS will have to sync with Epicor to create that facility code with a subset of data. The assumption that a customer will have to be setup in Resource map first, is impractical, most likely to fail because of inefficient and unreasonable demand it makes.

Now, lets bring in DHIS2 into the picture. DHIS2 treats a facility as an organizational unit. It allows grouping, hierarchical associations (province > districts > councils etc) between facilities. You can enter organizational units through the web site interface or you can import from CSV/XML/JSON files. You can include facility code on the import file. But that field is optional. When you import from a file, DHIS2 internally assign a org id which is not the same as the facility code. If you want to submit data to DHIS2 (e.g., eLMIS submitting data to DHIS2), you'll have to encode the record with orgUnit. DHIS2, currently does not have any built-in mechanism to sync with Facility Registry (Resource map) to ensure that organization codes are in sync with each other. If you develop an additional app to export facility list from Resource map and import it into DHIS2, DHIS2 is still going to assign it's own orgUnit id to that record and it would not accept any data submission that does not encode the data with that Id. A catch-22 situation. Can a solution be found, yes, but will require an upgrade to DHIS2, write some code in Resource Map or additional custom app to act as the translator.

<dataValue orgUnit="Lo423ozVkFw" dataElement="ndLcCJP1R5n" period="201607" value="0"/>

You may ask that, how come eLMIS is able to submit data to DHIS2 currently. It entailed a painful manual process of exporting all orgUnit Ids from DHIS2 into CSV file, manually mapping each of the orgUnit to a corresponding facility code, importing that data into eLMIS in a separate table. When eLMIS generates data for submission to DHIS2, it uses that table to encode data with orgUnit id that DHIS2 expects.

You can validate the assertions made above about DHIS2, at this links on DHIS2 documentation – managing organization units, meta data import, API doc 

There could be other mechanism available to build interface with DHIS2 so that it can sync with a Facility Registry, but I relied on what is publicly available through their existing documentation. 

- Product Registry. ERP application like Epicor treats product as an inventory item. You can enter it through UI or import it from CSV, XLS, XML, etc format. When we talk about GS1 bar coded product, we're taking about a product encoded with a bar code that is following one of the GS1 bar symbology (link). Scanning a bar code will read only few data points encoded in that bar code such as UPC, batch, serial #, expiration, etc. A typical product record will need additional required field. These are typically handled through GDSN (link). As can be seen from Oracle/Peoplesoft one is, link (I could not find online Epicor doc on this), on page 76, ERP can be configured to read and parse a GS1 bar code. When a new product is encountered, it would be through a receiving transaction at the ERP which will assign an SKU id to that record. eLMIS/OpenLMIS will not be aware of that transaction, until through a separate manual SOP eLMIS/OpenLMIS is notified and some import from CSV file process is triggered. Whether or not a product was GS1 bar coded, would not change this workflow. In fact less than 5% of MSD SKUs are actually going to be GS1 bar coded. That means a practical solution needs to support both GS1 bar code as well as non GS1 bar code or no bar code at all.

If a product registry application, such as Facility Registry (e.g., Resource map) were to be setup, it will face the same challenges. It will be the ERP that will encounter a new product through a receiving transaction first. The requirement to obtain a product/SKU code from 3rd party Product Registry first will prove to be impractical and likely to fail (imagine a scenario where a truck is waiting unload in a rainy day at the MSD warehouse and warehouse is refusing to the receive the shipment because somebody from that 3rd party app have not yet created an SKU for them and there can be dozens of new SKUs to be created in that shipment alone).

Now, let's put DHIS2 into the mix. DHIS2 does not have any concept about product, like the way it had for organizational units. It treats product as dataelement (similar to indicator or variable, a concept coming from statistic application like SPSS, SAS, or R). For example, for Stock-on-hand, DHIS2 will assign a dataElementId. For consumption it will assign a separate dataElementId, even through both data points are for the same product (see DHIS2 documentation on this here).

To DHIS2, health facilities are going to submit data through online forms. When a data submission form is designed in DHIS2, it assigns each data element id for each field/questionnaire on the form such as – open stock, receipts, closing stock, or a question like "Are you pregnant (y/n)"? DHIS2 allows data submission using their API, as long as you encode the data with the data element ids that it assigned when that online form was created. DHIS2, currently does not have any means to use product id that a product registry may assign. All it cares about is what data collection form you designed and what was the internal data element id it assigned. If you don't encode your data submission with that id, it will not accept that submission.

Now, coming back to the original premise of this discussion, that is what standard based interfacing mechanism to develop under OpenLMIS gap project. In my opinion, there is no simple solution. While we should all work towards a standard based approach, but a solution package to be implementable in near terms, needs to allow a phased adoption until everybody comes on-board. This will entail upgrades on respective applications as well.

I would argue that a variant of Option 2+, would be more practical. 

How it might work?

Perhaps this way:

• OpenLMIS interfaces with Facility Registry (optionally Product Registry), if such an application existing in the country and regularly syncs code with it

• If one of those registry does not exists, or the interfacing app like Epicor is not able to communicate with it, OpenLMIS have capability to import from ERP application, newly created customer a/c (or product records) from CSV file. Then it submits that new record to Facility Registry or Product Registry to keep that in sync. This will acknowledge the fact that central warehouse receiving translation initiated the whole workflow and subsequent processes were triggered by that. This will also allow OpenLMIS implementation in other countries who may not have any functioning Facility Registry (or Product Registry), since it can maintain mapping code on it's own, if needed. This also encourages those country to gradually adopt such registries since OpenLMIS will have the capability to import existing records from such registry and send only new facility and new products to the registry. In this later case the registries will take over the mapping function.

• Note that this reverse loop (ERP > OpenLMIS > Registry) is only for new facility and new products. For existing facility and products the regular data feed (Registry > OpenLMIS) should be followed.

• For Interfacing with DHIS2, there is no mechanism currently documented in their website, that will allow DHIS2 to be standard based, to accept orgUnit (facility code) or dataElementId (product code) to be taken from either OpenLMIS of Facility/Product Registry. In other words, DHIS2 in it's current version is not capable to be standard based, particularly for products. For the short-term the manual process of getting an export of orgUnit and dataElementId from DHIS2 and manually entering those in either OpenLMIS or Facility/Product registry comes to mind. For Craig's question about whether OpenLMIS or OpenLMIS/Reporting service submits data depends on what type of data. If DHIS wants district/regional/six monthly/annual aggregated/summarized indicator data, then OpenLMIS/Reporting service makes better sense. If DHIS2 wants monthly data broken down to individual facility reporting, then OpenLMIS submitting to DHIS2 makes better sense.

• In terms of prioritization, OpenLMIS's own capability to maintain code mapping code, ability to interface with Facility Registry, and manual mechanism to setup interface with DHIS2 can be the priority order. Product code mapping within OpenLMIS and ability to interface with product registry perhaps can be taken in later stages. For the short term, ERP can notify OpenLMIS through a report that get emailed to eLMIS admin on a monthly basis listing the newly created product/SKU(Epicor reporting tool has such scheduler/email a report, capability) 

The commercial ERP applications has dealt with this set of problems, albeit with a much robust/costly solution package. Links here (X12, Amazon marketplace) discusses about how ERP applications uses X.12 EDI interfaces (or EDIFACT for EU) to exchange/interfaces with other systems through EDI documents. Different transaction uses different EDI documents. For example ERP can send X12 846 EDI advising new inventory or sending EDI 850 or 810 for sales (which may happens to be, to a new health facility). There are commercial 3rd party EDI vendor/translator) tool exists which can be added to the solution package.

Discussion above used Epicor as the ERP straw-man. But when Zambia migrate to Sage/WHExpert, the situation will be comparable (MACS WMS have limited EDI capability). Sage will bring capability similar to Epicor. 

My two cents.

An in-depth discussion left a number of focus areas that need work:

• More formally defining metrics

• The need to find a technical solution for moving these indicators generated in the reporting stack, into a document format.

• The need to investigate the document formats for use with DHIS2:  FHIR MeasureReport and/or ADX.

• The need to evaluate if we have the need to demo OpenLMIS→DHIS2 integration, and if so if we could even support the configuration management needed for both systems for such a demo.

Current discussion of the approach is here: https://docs.google.com/document/d/19xysVDrfBuJcqTyDd7-j3zzOSnAU0WMf6OcmSFZ20eI/edit

Once decided, we'll want to update this wiki page with what we plan to implement. This page is currently linked to the roadmap so external parties will be directed here for scope of what OpenLMIS will implement as a part of the Gap Project.

FYI @Josh Zamor (Deactivated)