Skip to end of metadata
Go to start of metadata

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.


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


Call Notes

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.

Revision 2

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

  • No labels