The @ICAPEthiopia team are working together with me, @dkayiwa, and @UCSF on an address hierarchy module, discussed here.
We would like to use this real need for the first form-embeddable esm-widget.
Why: Because this widget wants to live both inside and outside of a form. The Address Hierarchy widget has two-three places it will need to live:
- in a Registration workflow (yes, this could/should be a form one day, but it’s not right now)
- in a form (this was previously an issue for ICAP-ET - they already tried using Address Hierarchy in Bahmni, but it didn’t work well for them because it couldn’t be embedded in a form. And there are numerous places/forms where Address Hierarchy may need to be embedded (see requirements here).
- possibly elsewhere in the chart (eg in a click-here-to-edit-the-address workflow… probably other use cases I’m not thinking of as well)
There are definitely other use cases as well. Eg. the 3.x designs for in-form Drug Orders, Lab Orders, Allergy reporting etc could all possibly be construed this way.
Requirement Ideas
@samuel34 & @dkayiwa & I have been discussing. Here’s our vision, and we’d like feedback from folks:
- Self-contained widget. Not contained in the form.
- You’d specify in your Form JSON schema “leverage this widget here”, and you might also add further config (e.g. with Address Hierarchy - this is for a patient or for a contact)
- Not tied to an encounter, patient-centric.
- Gets and posts data from Backend to UI
What OMRS already has
Both Samuel and Daniel pointed out that we already have a history of very similar widgets in the 2.x RefApp:
- Encounter-Diagnosis widget in HFE
- Concept searching, Pt search, and Encounter search can be used in any module
@mksd @mksrom @eudson @zacbutko @vasharma05 @bistenes @ibacher @jdick we’d like to hear what you think!
