Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
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.

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

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

  • No labels