Making all collectable data entities properly form recordable

Great stuff! Thanks @dkayiwa.

@ruhanga will represent Mekom and all or some of @mksd, @achachiez and myself will attend at times as well.

Btw, something that I wish could be added to the itemised roadmap listed on the wiki is the ability to make all collectable data entities properly form recordable. A great example is Condition:

public class Condition extends BaseFormRecordableOpenmrsData {


  @ManyToOne(optional = true)
  private Encounter encounter;

Two key aspects:

  1. It implements FormRecordable.
  2. It has a many-to-one relationship with Encounter.

AFAIK only Condition and Obs fully meet this criterion in Core, and IMO this should be expanded to Diagnosis, Allergy, Order, PatientState, … anything that could be recorded through a form and, while doing so, that would be attached to an encounter.

Beyond that, the next step is to ensure that either or both of REST WS and FHIR2 do properly take the form field path into account through their APIs. I am specifically thinking here of AMPATH Forms that rely on REST WS to transact with the backend.


1 Like

Is this something that you actually need? Or a nice to have? :slight_smile:

This is a bit more than a nice to have IMO.

For example, as you know, with the current form engines (at least HFE for sure), a repeated question cannot be re-ordered anymore in view or edit modes. This means that even HFE’s good old <obs/> does not rely properly on a ‘controlId’ (as it’s done for <condition/>, see here).

Okay, that’s a HFE problem, technically Obs could do it as it has got all that’s needed from Core. However that’s almost where it stops:

Encounter-able FormRecordable Control ID’d
Obs Yes Yes Bahmni Forms 2.0
Condition Yes Yes HFE
Diagnosis Yes - -
Order Yes - -
Allergy - - -
PatientState - - -
  • Encounter-able means "has a relationship with Encounter".
  • FormRecordable means “implements FormRecordable”.
  • Control ID’d means that form engines take profit of the fact that the entity is form recordable.

So what the above table shows is that only Obs and Condition are fully and properly handled by a form engine (and each one of them by a different one), all other potentially form recordable entities are not.

What is more IMO the nice to have, is that down the line this will allow for a very fine tuned analysis of the recorded data. When data is form recordable, then each piece can be tracked down to how and where exactly it was collected.

Cc @angshuonline + @achachiez/@jdick + @mogoodrich, as those guys have stakes in a form engine. Resp. Bahmni Forms, AMPATH Forms, HFE.


So does this mean that even if the Ampath Forms Schema was updated to try to support Form-based collection of Diagnosis, Order, Allergy, or other PatientState information, the backend would not support collecting/storing/fetching this data?

Depending on which one it is (allergy, condition, diagnosis, order or patient state) the backend would allow to:

  • save the entity - always
  • and link it to an encounter - if the entity is Encounter-able
  • and determine where exactly in the form the entity was recorded - if the entity if FormRecordable

For instance HFE allows to save patient states in forms with the tag <workflowState/>. But that’s it, when you look at the encounter that the form submitted, there is no patient state(s) to be found since patient states cannot even currently be linked to encounters. This means that you can’t edit the patient state by using the same form in edit mode.


Not sure I’m following this all here, but I will say that in our “3.0” form technology we should prioritize having the support that @mksd mentions: mainly “FormRecordable” and the ability to map a piece of OpenMRSData to a specific form field.

1 Like

@mksd is this the whole list of collectable data entities that is required to be made Form Recordable ?

Listening to the last Platform Team meeting, some questions came up. For example, for TRUNK-6018:

“Encounter-able” (linking to an encounter) implies information is stored as part of an encounter (an interaction between provider & patient at a point in time). What gets stored as part of an encounter should generally not change over time.

  • Observations (Obs), encounter diagnoses (Diagnosis), and orders (Order) are pretty straightforward, since these are generally data recorded as part of an encounter.

  • The patient’s condition list (aka “problem list”) (Condition) and allergies (Allergy) are tracked longitudinally – i.e., these data are tracked independent of encounters. A change (addition, removal, or edit) of these could be recorded as part of an encounter. For example, knowing this item as added within this encounter and this other item was voided within that encounter.

  • Programs represent treatment programs and studies within which patient can participate or be enrolled. Program workflows are used to track the status of patient’s within any given program. For example, for this patient in the HIV treatment program, are they in active treatment or have they been lost to follow up? One of the ways a patient’s state within a program’s workflow (PatientState) could be changed is during a clinical encounter (e.g., a during an initial HIV encounter, the patient is enrolled in the HIV treatment program and their status in the program is initialized to “enrolled”; in a follow up encounter they are started on meds and their status is changed to “active treatment”). Patient’s state might be manually changed or changed through other triggers; making PatientState encounter-able, means optionally linking to an encounter if the state happened to be changed during that encounter.

@dkayiwa, @moshon, @ibacher, et al does the above help or just confuse further? :wink:

It helps!!! Thanks a lot @burke

We also found these resources very helpful: Programs - Documentation - OpenMRS Wiki

Update: Thanks to @dkayiwa & @aojwang, the following is now done :tada:

@dkayiwa how can implementers get these improvements? Will they need to wait for / upgrade to Platform 2.5?

FYI @mksd


And @aojwang from Palladium. :slight_smile:

True dat!

1 Like

Thanks to the Platform team for making this happen, that is what I call a squad :slight_smile:

Thumbs up @aojwang.

@achachiez @grace can we create tickets (if they don’t exist yet) so that AMPATH forms take profit of the form field path and name for the entities that it can handle? Obs for sure, maybe Order, Condition, Allergy?

1 Like