In UgandaEMR we are looking to implement a feature to support the tracking of patient across “treatment lines” as they change regimens. We cannot use the regimens to determine the treatment line since each regimen can appear in a line based on the patients treatment history
The requirements in summary are:
Patient begins ART on first line with a baseline regimen
Patient can have this regimen substituted with another regimen while remaining on the same treatment line
Patient can be switched to 2nd line, and if on 2nd line can be moved to 3rd line
So the implementation approach is to leverage the program features to implement this, so we have the following possible approaches
Create a program for each treatment line, and manage the substitutions in a line as state changes
Create an overall Regimen program, have a workflow for each “treatment line” and manage the state transitions in a workflow
A couple of questions
Which of the designs supports multiple states
Which provides a simpler approach to existing OpenMRS ui tools reporting - current state, treatment line history, integration with existing dashboard widgets, HTML form entry
Which is the simpler design?
Which approach supports extensions over time
Any gotchas in using the approaches
Which scales better with increasing numbers of patients
Which approach provides easier integration/transformation with FHIR for data sharing
Thanks for raising this. I’ll answer some of your questions 2 and 5
We have been toying with it for some time and… rolled back most of it. I think the major issue that we faced with programs-workflows-states is their disconnection from the encounter-based workflow that is enforced within the Ref App and by HFE. There’s a couple of HFE tags out there that let do things that are encounter-unrelated and that should not be the case IMO. Typically this is the case with transitioning workflow states.
That’s the biggest gotcha that I can think of and that pushed us back in the end to not using all this as much as what we intended initially.
Of course if you want to use this as an orthogonal part of the data model (orthogonal to visits/encounters I mean) and that you’re ok to not embroil this with HFE forms, then that might be just fine.
I think it would be helpful to diagram out the program-workflow-state model and how it connects to Visit-enounter-form model. Then we can look at how the Program-Line-Regimen tracking would overlay and of course the Regimen-concept-drug relationship as well!
@ssmusoke Great post and very timely as we’re currently working on HIV and program/workflow/states. We are not using workflows with the treatment lines/regimen. We use obs for treatment lines on htmlforms. We do enroll patients in the HIV program from htmlforms, but do not use the workflow/states on htmlforms which I find buggy.
Could you use a Treatment line workflow with 3 states for each “treatment line”?
With the Implements meeting coming in less than 1 month, I would suggest a show 'n tell session about HIV implementations – especially about point-of-care workflow. I always learn much for @ssmusoke and the community.
@ball What is the buggy aspect of the workflow/states
We are actually going to go back and look at this again, since there is a question we need to answer, do I want to know the line the patient is on (yes), do I want to maintain the history of the lines outside the encounter (not really sure)
@mksd What problem space were you working on and how did you eventually end up doing this? We are still in design which is a good time for us to validate our thinking and actually ensure implementation is not disconnected from how best to use this feature
Great to start this discussion. I just opened a separate talk post to discuss overall program modeling improvement ideas which I’d explore more in that thread. Regarding @ssmusoke’s use case, I share @mksd’s concerns about heavy use of workflows and states within programs, for a few main reasons:
Tooling / module support remains much less mature for program constructs than for Obs (htmlformentry, reporting, refapp widgets, etc) and can be more cumbersome to work with.
Linkages between patient_program/patient_state and encounter data do not exist. So if you have an encounter form where clinician records a regimen change and new treatment line (as Obs), and then you want to also track this longitudinally as state in a workflow, keeping these data points in sync is non-trivial and can lead to data quality issues (these data points will diverge).
That said, I’d also echo @ball’s suggestion that maybe consider a workflow with 3 states. FWIW, @ssmusoke, I believe in Rwanda we do this within our “HIV Program” -> “Regimen Status” workflow.
Exactly @mseaton. In Rwanda, to handle treatment lines, we use a single program and a single workflow with a different state for each of the regimens.
The item that makes our implementation a bit different is that we will then put a patient in a different program when pregnant or nursing, then we also use a state to track their regimen while in that temporary PMTCT program. Having multiple programs allows the tracking of multiple pregnancies. For regimens, as long as we assume that patients are not switching back to a previous regimen (which I think is a good assumption), then the state model works well.
This is what we want to be able to do, to also simplify reporting
@mseaton This is pretty straightforward easier than I had earlier assumed. A question does the implementation also track the different regimens within a line (regimen substitution)?
How would you track a switch from 1st Line to 2nd line regimens? We have an encounter type to do that, but I am wondering how to simulate this in the workflow state switches. Within a state how can I track certain changes within this state (or within a workflow how can I have multiple states that are not necessarily predefined basically the same state 1 to n times)
What data is handled during state transitions? Can I link an encounter_id here (linking to the switch encounter?) - I saw this in @mseaton program modeling enhancements thread
How easy is the reporting handling of state transitions for generating cohorts etc - while this comes at the end, I have found that planning for reporting as part of design is very critical