Versions Compared

Old Version 1

changes.mady.by.user Sri Maurya Kummamuru

Saved on

compared with

New Version 2

changes.mady.by.user Burke Mamlin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Page Properties
Project DriversPaul Biondich, Bob Jolliffe, Darius Jazayeri, Burke Mamlin, HISP India, Jembi, Pierre Dane
Tech Lead?
BA?
Use Casesarunima m, HISP India
Document owner

Sri Maurya Kummamuru

Designer

Bob Jolliffe, Darius Jazayeri, Burke Mamlin, Sri Maurya Kummamuru, James K

DevelopersSri Maurya Kummamuru, HISP India devs,Jembi devs
Beta implementer (i.e. guinea pig):Jembi + Mozambique

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

...

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

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

...

  • 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

...

    • 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.

 

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