OpenMRS TRACNet integration (Design Page)

The following points are a requirement for this project:

Identify a Java-IXF binding that allows SDMX-HD to be read into a Java object, modified, and rewritten back to SDMX-HD.
- If no such library exists already, then implement it.
- This may be done either by Voxiva, OpenMRS, or in collaboration.
Implement functionality in an OpenMRS module to save an SDMX-HD file to the database along with appropriate metadata on its source, the frequency of the report, and the method for submitting it.
- In this project, these will be uploaded via a web form. Eventually a web service endpoint is needed, but this is out of scope for the current work.
Implement functionality in the OpenMRS core to save an “Indicator Dataset”, i.e. a mapping of named indicators (from the imported SDMX-HD) to definitions of how to calculate them, and along what dimensions they should be broken down.
Implement functionality in the OpenMRS core to tag locations and other metadata with external identifiers--specifically their keys in the SDMX-HD document.
Implement functionality in an OpenMRS module to run a report (containing an indicator dataset), and merge those results into an SDMX-HD template.
- In this project, the resulting SDMX-HD file will just be downloaded on-demand. Eventually these reports should be run on a schedule and automatically submitted to a web service endpoint in TRACNet,
- but this is out of scope for the current work.

The following points are not necessary to show SDMX-HD integration--they will be implemented during this project if possible, pending time being available.

Implement a user interface in the OpenMRS core to allow a user to easily create a cohort definition that depends on the start date and end date of a given report period.
- It is already possible for an administrator to define these queries, which is sufficient for this project, but not ideal for use past this pilot integration.
Implement a user interface in an OpenMRS module to choose how to calculate a group of indicators, and allow these to be saved in a such a way that common components (e.g. “Male”, “Adult”, “On Antiretrovirals”) are stored in a common way across that group of indicators.
- It is already possible to define these queries individually, which is sufficient for this project. For eventual real-world use, we will need a better user interface.

Discussion

We need to create Indicator in the OpenMRS core. Something like:


interface Indicator
public Double calculate(Date fromDate, Date toDate, Location location);


class PatientIndicator implements Indicator
String key;
CohortDefinition cohort;
LogicCriteria lc; // optional
AggregationFunction ag; // optional, defaults to COUNT
List<Dimension> dimensions; // optionally break this down on the specified dimensions


class ExpressionIndicator implements Indicator
       // represents things like "indicator #1 + indicator #2 - indicator #3"

Developer Calls

Participants

@Carl Fourie +27 (0)84 465 4305 (mobile)
@Mike Seaton
@Ryan Crichton

Call Notes

links

User interface Mockups

Revision 1

These mockups are the current design of how a IXF template can be uploaded and viewed. Also, the user interface for how OpenMRS indicator and dimensions can be mapped to IXF indicator and dimensions.http://archive.openmrs.org/wiki/Image:TracNetIntegrationUIs.png

Revision 2

These are the new proposed mockup for how users would map OpenMRS indicators and dimension to SMDX-HD indicators and dimensions.

http://archive.openmrs.org/wiki/Image:Tracnet_UIs_v2.png

Projects