Background and strategic fit
One of the key opportunities for greater collaboration within the OpenMRS community is around reporting through ETL (Extract, Transform, and Load). This was underscored during discussions at OMRS19. It’s difficult to do modern analytics on OpenMRS data. The manual process of designing and developing ETL queries is time-consuming, complex, and is being tackled one implementation at a time.
We have prototyped ETL approaches with both Spark and FHIR models.
We are handling most of the PEPFAR MER indicators using the traditional ETL pipeline, but we don't have a modular approach that allows more aggregate level analytics. Want to extract data out of OMRS in a structure that is easier to query so that it is easier to query these specific indicators. Using 2-3 specific indicators can be a benchmark - need to ensure we cover both complex and simple ones.
Goals
- Pick one concrete problem to solve
- An output that is general, that most implementations can use. (Since inputs are so different by organization.)
- Build on top of a FHIR-based datawarehouse (assumes people are comfortable working with FHIR schemas, and comfortable writing complex SQL queries → Need to validate)
3-4 Concrete Problems/Use Cases people need us to tackle with intermediate data handling:
- 10 metrics from PEPFAR MER Indicators - like TX_PVLS, and an aggregate that relates to this
- allan kimaina to add specific indicator examples
- Simple Indicator:
- Moderate Indicator:
- Complex Indicator:
- Viral Load Indicators: e.g. Ampath project to consider other metrics in correlation with VL; PVLIs (Pt Viral Load Indicators)
- Getting data out of OMRS is challenging - Mekom's DB Sync work looking at that
- ...?
User Stories
- ...
Questions
- ...