Skip to end of metadata
Go to start of metadata


This workflow is currently specific to DHIS2 as the HMIS and OpenMRS as the SHR, in future iterations it may change to incorporate a more standard based approach.


Description: This workflow will enable the Shared Health Record to be able to export aggregate data to the HMIS systems so that it can be used for reporting purposes.

Sponsor:  HMIS community? with the SHR community

Status:  proposed

Last Modified:  10 Sept 2014


Technical details

RefInteractionEndpointDataTransaction Specification
1Trigger on time period GET /trigger  
2Request aggregated data for the time period SQL 
3Aggregated data SQL result set 
4Aggregated data  DXF API Request 
5Ack DXF API response 
  • No labels


  1. I think this needs more analysis.  While I haven't thought very deeply, I see 4 different bases for directing an aggregation operation: (1) an epidemiological approach, where selection is based on person, place and time; (2) a cohort-based approach, with both persistent and dynamic cohort definitions (rule-based or constructed with add/delete); (3) a program-workflow-state approach, which is maybe more M&E oriented; (4) a query perhaps like those in CSD.  Either (2) or (3) should allow the process requesting the aggregation to tag data with the persistent cohort or the program-workflow-state for later reuse even if these are not supplied by the underlying patient record source; this would allow incremental calculation of cohort membership.  Some of these tags might need to include parameters to differentiate them, e.g. patients starting ART in 2004Q3. 

    I don't necessarily think that the message is processed in the right order.  While the HMIS sub-community is new, my hope is that it will address the issue of indicator definition.  In that case, the IL should send the HMIS a message to get an indicator definition (or set of related definitions); the definition ID and the parameters necessary for the calculation would be returned to the IL.  In a second message, the IL would send an indicator definition ID and a set of parameter values to the HMIS; the HMIS would orchestrate the execution of the indicator calculation by the SHR; the HMIS would combine the returned results into the indicator values and return them to the IL.

    I'm concerned that this whole approach is too tightly coupled with the OpenMRS-DHIS2 integration issue.  It might be worth having a data mart actor between the SHR and the HMIS.  The data mart would be loaded by ETL steps from the SHR and perhaps the HMIS; indicator calculations would take place inside the data mart and the results made available in a message, which might be to the HMIS to persist the indicator incrementally.  This could be useful for producing repeatable reads of SHR data without keeping it locked during the calculation by caching it in the data mart.  Using the model from the preceding paragraph, the HMIS orchestration would consist of loading the data mart from the SHR (and HMIS if necessary), executing the calculation on the data mart, and persisting the new results.  This is somewhat like the transaction machine/reporting machine division of labor frequently employed.

    Another issue has to do with indicator data that is not patient-based and perhaps not even numeric, for example, an infection control site visit.  The questionnaire would have a facility ID and survey date plus questions like "use of lab coats (Exceeds rqmnts, Meets rqmnts, Needs improvement, Did not evaluate)", "use of gloves (EMND)", "separation of patients with cough (EMND)"; then "Corrective action (text)"; and "Previous corrective action completed (YN)".  My current thought is to have a separate data store, associated with either the FR or the HMIS, but an OpenMRS facility data module is the favorite idea at the moment as I understand it.


  2. Hi Roger, thanks for these comment. I agree with you this workflow hasn't been through out in depth. Hopefully we can make some progress with this on the HMIS group is off the ground. Thanks for your insights, these would be great to kick off that sort of discussion. In general I agree with your proposed orchestration steps, that seems to be a more through process.