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

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.