Page Comparison

• • 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. Adding model objects to map with DHIS2 dataset, data element and

   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.