Through our Digital Square award, we have an opportunity to work on a proof of concept around patient-level indicator reporting. We’d like to hear what you think about the following, high level plan that will guide our work over a twelve-month period - likely starting in June or July.
What questions do you have about this plan? What’s missing? What would you add or change?
- Objective 1: Develop a proof of concept which supports the calculation of the TX_PVLS indicator.
- Activity 1.1: Use community forums to bring together a small team of subject matter experts and business analysts to define the initial scope and identify existing work to leverage.
- Activity 1.2: Establish a project page on the OpenMRS Wiki with documented roles, responsibilities, and communication channels to be used during the project period.
- Activity 1.3: Identify the relevant concepts in a standardized terminology to be used for data capture.
- Objective 2: Build a proof of concept that supports exporting the necessary data for the measure calculation to a standard format e.g., a CSV or a FHIR bundle.
- Activity 2.1: Define the architectural design of the module based on the FHIR R4 standards.
- Activity 2.2: Export the data from OpenMRS for consumption by a tool capable of calculating the TX_PVLS indicator on the basis of the data.
- Objective 3: Build the capability for reading a FHIR Measure resource for the TX_PVLS indicator
- Activity 3.1: Setup a proof of concept FHIR Measure resource to be consumed by OpenMRS
- Activity 3.2: Consume the FHIR Measure resource and generate the corresponding patient-level output in the standard format used in Objective 2.
- Activity 3.3: Adapt the FHIR interfaces of OpenMRS to support the overall workflow.
- Activity 3.4: Contribute to FHIR profiling activities as relevant.
- Activity 3.5: Feedback insights or suggestions for improvements to relevant organizations.
@burke @dkayiwa @ibacher @maurya @mozzy @mseaton @mksd @k.joseph @ssmusoke @ccwhite23 @akanter @janflowers @terry
Dear @jennifer, am so glad we have this award, while at @Jembi , we worked on a number of indicators including TX_PVLS and i know the team is continuing support towards that, i hope there’s a lot that the team can bring in addition to working with the new team. I have shared this on the EPTS team’s slack channel.
This is great to see. It might be interesting to consider whether this could be done as a component within a larger standardized “HIV” module that aims to meet CDC/Pepfar guidelines and standards in various ways. This has been discussed in one flavor or another for years, most recently in this thread started by @ssmusoke . It would be great to see if we can try to find better ways to leverage and share the considerable work done on HIV care and treatment within OpenMRS by all of the various organizations who have worked on this through the years, who up until now have too often worked in parallel. I wouldn’t want to slow down or hinder this particular effort, but might be worth thinking about how we might structure this as the first component of something that could expand to include a much larger scope of standard HIV functionality.
@mseaton, yes, i agree. I think this is one piece of a couple of larger wholes. In addition to the larger, standardized “HIV” module, it could also be one component of a larger approach to reporting, along with ETL, etc.
With that in mind, let’s consider some specific steps we can take early on to share work done, experience gained, determine what can be leveraged, etc. A lot of the scope above is focused on the technical scope and we can also include some approaches for engaging and collaborating more purposefully with implementers and the community. @christine @k.joseph, wondering if you have insight into this from the QA team’s experience?
Just adding my voice here while it will be great to have this within of the larger reporting thinking etc, why not quickly focus on the problem at hand which is funded, provide a proof of concept then use that knowledge to see how it fits into the larger picture.
A bird in the hand is worth two in the bush, move fast learn fast then adapt accordingly
And no need to re-invent the wheel, build upon whatever @Jembi has already done