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.