Hi @Sebastian_Brudzinski (and the rest of the Tech Committee that attended this morning’s discussion),
I had a chance to catch-up with @Chongsun_Ahn today after the Tech Committee call and we realized where some of the confusion was coming from w/ regards to the Malawi need for Requisition data, the idea behind a new micro-service in that implementation, and ultimately circling back to why I was bringing up Data Pumps:
- @Chongsun_Ahn and I caught up on the Malawi OpenLMIS-Kuunika integration work and that there is already a data pipeline built in Nifi (in 3.6) to pull Requisition data and transform it into a format intended for DHIS2 (though which is not Malawi’s Kuunika format). This pipeline delivers reports on metrics & indicators from the Requisition into our FHIR Server as Measure and MeasureReport resources. In effect this new service has no need to make API calls to Requisition service, it can query and search the data in the FHIR service for the OpenLMIS integration to Malawi’s Kuunika.
- The above doesn’t change the problem which exists in the Reporting stack that requires it to have special API access built to give it “superuser” access to Requisition data. The short-term work-around is the known one: configure a special user that has this access. No code changes are required. This is what Malawi should use for the short-term.
- My point about data pumps is intended to address the above problem of the reporting stack’s access to Requisition data, so that the work-around isn’t needed someday. That is I want us to make headway on building a data pump for Requisition data to feed the reporting stack, instead of building hacks in the Requisition API to “get all data”. There are many reasons to do this and stick to our plan.
Please followup with @Chongsun_Ahn for more on these available FHIR resources. For our work in 3.8 and beyond I want to followup on how we can make incremental movements to data pumps, so please be on the lookout for that.