We are working on AF-59 and I would like to finalise the design.
Our need is to control the enabling/disabling of extensions depending on whether the patient is in either of the listed states, eg. something like that:
@mksd one thing Iâd mention is that the same concept might be used by different states in different program workflows, so just referring to states by concept might not be a sufficient approach.
Thanks @mseaton, thatâs a good point. Do you think we should refer to the ProgramWorkflowState's name (or UUID)? Rather than a reference to the defining concepts.
I donât think name is ever populated in program workflow state, as we made some effort in earlier days (probably misguided) to delegate that to the associated concept. I think the state UUID or some combination of state concept (name, uuid, mapping, etc) and program/workflow information would be needed.
Interesting⊠the java object ProgramWorkflowState still have a name property because it inherits from BaseOpenMRSMetadata, but that is never stored behind the scenes:
So @mksd so I think that line that does the setName just ends up putting it into the ether somewhereâŠ
Yeah I would agree with @mseaton that weâd want to support a pattern where you specify a workflow and a state. And you would reference a workflow either by itâs name or uuid, and a state by the underlying concept (name, uuid or mapping).
I could see I us wanted to support more complex logic in the future, but I think a list of workflow/workflow state pairs ORed together is great for now and then we could update if needed in the future.
Thanks for working on this!
Take care,
Mark
fyi @ball@ddesimone I think weâve talked about wanting to make some forms only available to patients if they are enrolled in a program, and this would facilitate that.
@mksd Excellent feature, would it be requiredProgramStates for clarity, not sure if there will be any other states (but just my OCD acting up)
@mogoodrich Would that need (which we also have) also be something like requiredEncounterType (so that the form only appears if there is a specified encounter type)
@mksd I am hoping that I am not overloading this request, but would this design also be extended to cater for forms that only appear when a certain concept value is present?
@ssmusoke you mean like the extension is only present if the patient has any encounter of a certain type? (Ie the âfollow upâ form is only present after a âinitialâ encounter type had been created)?
That could be valuable as well, but Iâm fine with just states for now if thatâs all @mksd needs.
@ssmusoke we might need to cover also one the use cases that you mentioned, aka enabling/disabling a form depending on whether a certain obs was recorded for that patient, is that what youâve got in mind?
This doesnât seem exactly right to me. Iâd think requiring a program, a workflow, or a state are all independently useful things, but this model still doesnât allow you to distinguish what program or workflow a state refers to if multiple are included.
I think we should establish some standard like we have in htmlformentry, where referring to concepts by mapping is always done as a single configuration string: âsource:termâ. So referring to a program workflow state could be simply âuuid-of the-stateâ or it could be âprogram-ref:workflow-ref:state-refâ, etc.
Ok first of all yes, having three ârequiresâ will not work to cover all possible use cases, it is the wrong model.
Ok so here we assume that a single UUID necessarily points to a ProgramWorkflowState, but what if we want to simply say something like âenable this extension is the patient is enrolled in program XYZâ?
I guess we will need something more descriptive, such as:
That sounds good to me. #2 and #3 are the same thing, and I would think #2 is unnecessary assuming your âref-to-state-Bâ in #3 is a uuid to the actual program_workflow_state, as a state is foreign keyâd back to the workflow it belongs to. While a concept can be associated with multiple states, one state is only assigned to one workflow. So, #2 is needed only if your âref-to-state-Aâ is a concept reference rather than a state reference.
If I gat you right, we wanna have more specificity as possible, specify âprogram + the-worflow + the-target-stateâ
We could have a simple lightweight java wrapper class to account for the json object literally something like :
public class ProgramWorflowStateContextModel {
// program uuid
private String program;
// workflow name
private String workflow;
// reference by associated concept
private String state;
// getters and setters
}
So the requiredStates property is an array of object literals parseable to ProgramWorflowStateContextModel
A couple of things, it wonât be called requiredStates, since the whole thing goes beyond that.
Keep in mind that both combinations of requirements and isolated requirements should work, as much as possible. For instance this should work:
{
"program": "ref-to-prog-A"
}
This means âthe patient is enrolled in program A.â This assumes that the reference to the program is enough to identify it uniquely. If not, we will have to throw I guess.
This should also work:
{
"state": "ref-to-state-A"
}
This means âthe patient should be in the state Aâ. This assumes that the reference to the state is enough to identify it uniquely.
This means âpatient is enrolled in program A, is within workflow A and is in the state A.â There should be enough information there to spot this combination of requirements.
@mksd I like this, maybe the tag can be requiredProgramWorkflowAndStates (long but very clear)
Also is the expectation that there will be a global âANDâ between the different array of object literals or do you expect to have cases where the operator can be changed to an âORâ