Adding Program Attributes to HTML Form Entry

OpenMRS Platform 2.2.0 adds support for Program Attributes, which enables capture of some data on each active program instance (I hope). We are looking to leverage this within UgandaEMR to capture some details which are used to track a user in each program treatment (which starts and end)

This may be during enrollment or at any time during the lifetime of the program

The question is what is the best place to put this?

  • enrollProgram tag: this seems like a logical place to me, just wondering how to add patient attributes when a patient is already enrolled in a program
  • create a new tag like patient, so enable the addition of these attributes?

@mogoodrich @mseaton Thoughts?

1 Like

patient or program attributes?

@dkayiwa sorry add/update program attributes to a patient already enrolled into a program

enrollProgram tag seems logical for enrolment. For cases of simply adding attributes to a patient already enrolled in a program, i see no harm in adding a new programAttribute tag, just like we have a separate tag for completing a patient program completeProgram

@dkayiwa cool that makes alot of sense let me open a ticket

So I am sharing progress, as it seems I have gotten myself more confused so I figured that I can get help untangling myself to move forward

  1. Constraints: This tag only works with core 2.2.x so has to be isolated in that profile which seems to make sense
  2. The approach is to add a programAttribute HTML which allows to provide a text value, inspiration drawn from the patient identifier tag (now I am thinking should I just copy everything there)? <programAttribute programId="1" programAttributeType="2" required="false" />
  3. So my questions to help me understand the approach
    • Do I need a ProgramAttributeElement or ProgramAttributeTag, I am not sure which one to use and why
    • As part of the business rules - if the patient is not enrolled in a specific program should I throw an exception, enroll the patient in the program, or just ignore the program attribute (why throw away data)?
    • I am looking at the tests for ConditionElement and I am wondering is this the new style? @samuel34

My current PR illustrates my confusion as I may not understand the framework approaches, but at least I may have the beginnings of a test that I can use to muddle my way through

No, it’s not the new style, I just found it interesting and more flexible using Mock tests as compared to overriding the RegressionTestHelper methods.

I think you will need the ProgramAttributeElement: This will define what the tag will do, provide some bones and flesh and make sure it handles form submissions.

I see in your PR, you have something like;

	public String generateHtml(FormEntryContext context) {
		return "";
	}

I didn’t have a second look in the PR but that should return the html that would give structure of the tag.

I find this annoying but I think you also need the ProgramAttributeTag. This would reference the ProgramAttributeElement to get the markup that gives the tag structure and registers the submission handlers for the element eg.

https://github.com/openmrs/openmrs-module-htmlformentry/blob/master/api-2.2/src/main/java/org/openmrs/module/htmlformentry/handler/ConditionTagHandlerSupport2_2.java


If you feel you must use one and not both, then you only need ProgramAttributeTag.

@ssmusoke so in the end we would have the following tags to control programs, workflows, states in general:

  • <enrollInProgram/>
  • <workflowState/>
  • <programAttribute/>

?

It depends a bit on the business needs, but perhaps the shorter way would be to expand on the existing <enrollInProgram/> tag? Of course that would only work if setting the attribute is always done when enrolling.

@mksd the challenge then is that the htmlFormEntry module is dependent on Platform 2.2 only since the ProgramAttribute model is only available from then

@mogoodrich @mseaton Is there a way to have an attribute for a tag only available for certain platform versions?

You can certainly do that by ensuring that there is a compatibility API to deal with processing the new tag attribute, and prior to 2.2 its implementation would either do nothing or throw an error.

Would the program attribute be able to set a location for the enrollment? We do use the tag, but the location is set to null.

In addition, is buggy. Use caution. I don’t see a ticket for this.

@ssmusoke there existing API 2.2 sub-project where the ConditionList tag is implemented… I don’t remember 100% how this operates off the top of my head, but I believe that should give you a starting point as to how to achieve what you want to achieve.

Take care, Mark

Any pointers to an example that you have seen? This would help me alot

I think this would be of help: https://github.com/openmrs/openmrs-module-htmlformentry/commit/1b60268d9250926eb7e5eb4676e5113664c63b53

I introduced ConditionTagHandlerSupport that’s implemented by all conditionally loaded resources ie. ConditionTagHandlerSupport2_2 will be loaded if running core >= 2.2.0 while ConditionTagHandlerSupport1_10 is loaded for versions prior to 2.2.0

This is a example for you @ssmusoke: ObsSubmissionElement relies on an API (ConceptCompatibility) whose implementation varies across Core versions.

That’s closer to the kind of stuff you will want to achieve in EnrollInProgramElement, assuming that’s where the changes need to take place.