OpenMRS - DHIS2 - ADX - Reporting

• ADX support - (ADX Data Example)
  • OpenMRS has an out-of-the-box module / functionality to define and transmit/receive ADX messages and indicators.
  • ADX import support is now possible in latest trunk of DHIS
  • this will have implications for the OpenMRS module's data model

• Mechanism for calculating data elements

• Not just SQL, but also tap into OpenMRS reporting framework. (Addition, not replacement.)

• "It's difficult to write and maintain 1200 SQL queries"

• Getting metadata from DHIS uses an old ad-hoc mechanism; use new DHIS API methods
• Reporting Framework Integration

• ADX hasn't actually cleared the final hurdle of standards yet (but there should be no fundamental changes)
  
• ADX will be in the version 20 release that should happen at the end of next week. (Country upgrades to latest versions vary quite a bit. E.g. Rwanda might upgrade 6 weeks later. Ghana would be much slower because of need to retrain.)

• Download all the data elements from DHIS2

• Map these to SQL queries against the OpenMRS database

• From that, compute data values that we post back to DHIS2
• Exposes WebAPI functions providing an additional way to consume the data

• Next steps:

• • Schedule followup design calls (for technical discussions)

• • Decide how we communicate going forwards => Sri Maurya Kummamuru in charge of setting up a Wiki Space and Talk topic

Technical Road Map

1.Supporting ADX (August - November 2015)

In this first phase, we keep the current SQL query approach and enhance the model of the current module.

1. As with DXF format,current module has only one model object to map with DHIS2 which is DataElement. With new ADX format, we need more objects for mapping as below

   • DataElement
   • DataSet
   • CategoryOptions
   • CategoryCombo

   Definition of those in ADX is explained with examples at https://www.dhis2.org/doc/snapshot/en/developer/html/ch01s12.html

   We just need object with basic attributes such as: id, name, code and other audit attributes.

2.  Expose simple API to POST codelists to this model. Current module category such as sex, age group, etc. Currently we only have dataelement. Then dataelement should be matched with datasets and categories (categorycombo). already had the basic code; we need to enhance it (using JAXB). A sample ADX DSD can be found here https://github.com/dhis2/adx/blob/master/IHE/samples/adx_sample_dsd2.xml
3. Find a way to define categorycombo in the DSD.
4. Enhance the current SQL query model so that it can make use of the new model and reduce the number of queries needed. We may need two objects: Query and QueryParameter. Each QueryParemeter contains the category such as sex or age group.

2.Integrate with reporting framework ( December 2015 - May 2016)

We replace/add in addition to the manual SQL query by the Reporting framework from OpenMRS. This needs to be discussed in more detail with Darius and team.

Initial Technical Todo's(Subject to Change):

• Moving forward - DHIS Report module would :

• Modify the concept id's to use macro's 
• Provide an Reporting module functionality as an alternative that would be similar to the one existing.
• User friendly Interface to provide various options available
• Sample xml - wiki
• UI that lets you specify that should cover 80% of the indicator that generates the SQL or leverages Reporting modules' functionality
• 3 UI options - 
  • 1. The present SQL text area with "smart" references to concepts (you can embed a reference to a concept that shows name along with ID, can take a UUID and convert it, can work through mapping, etc.  For example, you type "@" and then start typing a concept name or source:code or UUID to select the concept like usernames are selected in Discourse or Confluence editor)
    • Step 1: support {{conceptMapping("CIEL:1234")}}, or {{encounterTypeName("Intake")}}
    • Step 2: a smart text editor that automatically fills these things in
  • 2. Select from reporting definitions (column definitions) from the Reporting Module 
  • 3. A wizard that provides the option to generate the SQL query.
    • e.g. you pick:
      • based on observation
      • (x) count each patient, nomatter how many times this observation happens in the period    ( ) count each observation in the period, maybe more than once per patient
      • Which question: <autocomplete for choosing concept>
      • What answer: <autocomplete for choosing answer>
    • Design suggestion: rather than hardcoding a wizard that does N different options, make a wizard interface and then implement some of the examples through that interface.  Then your initial wizards can serve as examples for people to add new wizards in the future.
    • Would be ideal to add this functionality to the reporting module and then let people get to these as reporting definitions.
• First Pass: Reporting Module
• Second Pass: Improving the flow
• Third Pass: Give a improved flow to map/define indicators/definitions with reporting module
• Demonstrate DHIS Report module on a video to show it could be imported in any generic implementation would be a nice start and interest.