@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:
@Entity
public class Condition extends BaseFormRecordableOpenmrsData {
...
@ManyToOne(optional = true)
private Encounter encounter;
Two key aspects:
It implements FormRecordable.
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.
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.
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.
ā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.
@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?
