In OMRS, form-engine technologies primarily focus on capturing observational data, however we have other data points that in a POC setting are captured from different parts of the framework eg. Allergies, Conditions etc. It’s important to note that these are all patient centric data points. At UCSF we plan to grab some of the existing widgets and embed them within forms.
OpenMRS 2.x support of embeddable widgets
The ancient/legacy OpenMRS had this notion of portlets, were modules had the ability of defining their own portlets and could be re-used within other JSPs.
2.x on the other hand has the UI Framework, which introduced the concept of UI Fragments. A more practical example could be the EncounterDiagnoses widget. This is available in HFE forms but defined within coreapps as a UI Framework fragment. It’s independent of the forms-engine and has a built-in mechanism of posting and fetching data to the backend. I believe this same widget can be used in other parts of the framework.
Happy talking about O3?
O3 has this concept of extensions(Learn more about extensions). An Extension simply wraps a Component(hypothetically agnostic to any framework) within some-kind of special parcel that can mounted at any declared slot in the application. Any basic micro-frontend can declare slot and define extensions declaratively or imperatively.
O3 already has support for capturing patient conditions. This widget(actually a simple static form) is readily available as an Extension. You just have to add the required MF(@ openmrs/esm-patient-conditions-app) to your import-map.
However, we just can’t embed this widget as-is within any form as it’s published as a form itself with the “Cancel” and “Save” controls at the bottom.
As a POC, we are happy to spike on refactoring this to a widget that can be smoothly embedded in an existing form. Below are my thoughts, your thoughts are welcome to help draft a better mind map:
Currently the widget is fused with standard forms controls, I think we should break this down so that the actual widget is independent of the form it lives in.
For this to work, the widget should have a built-in mechanism to handle submission by itself. This could either be more explicit through callbacks or through events? Or we could fuse small adhoc controls within the widget(could be config driven?) that trigger submission? Your input on this would really be helpful.
Hi @samuel34 , it sounds like you’re on the right track. I don’t know what the best way to handle data submission for form sub-components is. I think that’s a big unsolved problem in form engine design.
Wouldn’t it be simpler to start with a widget that does not handle server data submission? A widget that just displays data passed to it, and collects data entered by the user, passing it over to the parent. Just like a calendar or date picker widget.
Having components of a form with side effects breaks the contract of the form – e.g., you can change things without ever submitting the form.
I think you’re suggesting that the ability of the condition widget to submit changes itself be made optional.
My recommendation would be to remove the form submission from the widget and then refactor the other place(s) the widget is used to handle the submission or, if there are multiple places, create a separate “condition form” widget that wraps the condition widget in a little form. Those places that want to let users make direct/immediate changes to conditions can use the condition form and any form would just use the condition widget.
Thanks @grace for updating this thread. We are thinking on supporting recording of multiple conditions at once, as you can see the widget only supports recording of one currently and our BA team (@wamz@mwaririm) think that such feature will be a good addition.
As a heads up… I’ve seen in past projects that the technical complexity can balloon if we want to also display known-conditions within the form as well (so eg the user can see oh, Diabetes Type 2 was already recorded, I don’t need to add that). I wonder if @wamz wants to add that? In the RefApp I guess the split-screen desktop view does allow the clinician to see past reported issues if the user is looking at past conditions on the left while doing the form on the right, but these would not be visible in full-screen-form-view or tablet mode. (Gets even more complicated if we want to enable a clinician to delete a past-reported condition, but I don’t think that needs to be in scope.)
@grace for the known conditions I think validation could help in this scenario. If we agree that the same type/kind of condition cannot be added then, when the user selects a known-condition the system can block or alert the user that he/she is entering an already existing condition. How does that sound?