Child pages
  • OpenMRS - DHIS2 - ADX - Reporting
Skip to end of metadata
Go to start of metadata

Goals

  • 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
    • Able to successfully transport ADX
    • Able to successfully transport ADX with Disaggregations
  • 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 to handle disaggregations

Background and strategic fit

  • OpenMRS-DHIS2 integration is obviously a big desire of lots of people in the OpenMRS community, and we'd like to more effectively mobilize the OpenMRS community to contribute to a preferred integration module. 
  •  

    Exciting moment: we've been exploring OpenMRS-DHIS2 connectivity for years now

     
    • developed something as part of HISP-India work that was very simple (and received some scorn) but worked!
     
    • it's in need of a revisit/rethink
     
    • for the first time, a possibility of an international standard for data exchange (with more legs than SDMX-HD)
     
    • good company of people and talent with expressed and vested interest in making this work
  • 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.)

Existing Functionality of the DHISReport Module -  (SHR branch detailed documentation can be found here): 

 

  • 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

 

  • Next steps:
    • HISP India (consulting with Bob Jolliffe) to share a roadmap based on today's call
    • 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


 

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.

 

Requirements

#TitleUser StoryImportanceNotes
1
     

Use Cases

Waiting for HISP India Input.

Questions

QuestionOutcome
Sri Maurya Kummamuru - Do we want a seperate ADX/Reporting Module that generates ADX data? or do we want to continue expanding on the present module providing reporting module support?
Darius Jazayeri - Wouldn't you just start from a blank ADX template?there are advantages and disadvantages to both. Exchanging code lists works better via a REST call to DHIS2.
Sri Maurya Kummamuru - how widespread is adoption of the current DHIS connector OpenMRS module? I hear rumors here and there.

Not Doing