3.x Address Hierarchy Widget
- Grace Potma
Current State Resources
Backend support and metadata upload support already exist. This feature has been very widely used in existing OMRS implementations around the world.
Backend: Backend support is provided via the Address Hierarchy Module: https://addons.openmrs.org/show/org.openmrs.module.addresshierarchy https://github.com/openmrs/openmrs-module-addresshierarchy
Documentation on the Address Hierarchy Module: Address Hierarchy Module
Metadata - need both the Address Hierarchy Module and Initializer installed; then follow csv conventions.
Add the metadata you want at:
configuration/ ├── addresshierarchy/
O3 Background: Many orgs have wanted Address Hierarchy support for the 3.x Frontend, but it has not yet been built by anyone.
it should already be possible to embed (and hook to the form submission workflow) anything with custom controls. See:
Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.Previous O3 ticket/discussion about Address Hierarchy:
Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.TODO
Key Points
Template to set up
Give this to AH module
RefApp should have a baseline template to work with, that other orgs can customize and add stuff to. So, what should the baseline template be? TODO
How it is configured in RefApp TODO
Visuals to know
Current State in SmartCare-Ethiopia: | Current State in RefApp 2.x: (PIH-Haiti Registration Form Example) | Proposed State | |
|---|---|---|---|
Create: |  |  Notice that this OMRS-EMR was able to customize the names of the regions (eg Department, Commune, etc) | |
Edit: | Slimmed-down version, to edit the address: | Note that the Address Hierarchy is used again, when you want to Edit the address. 1) Click Pencil of "Contact info": 2) Get taken to a slimmed-down version of original registration form, to edit the address: |
Use Cases
Addresses are needed in several places - note the following Use Cases:
For the Patient: At registration
For the Patient: In a form
For a contact of the Patient: At registration (eg emergency contact)
For a contact of the Patient: In a form (eg Sexual Partner Contact Tracing form)
So, this widget needs to be able to handle collecting either Patient or non-patient information, in either registration or in a form. Discussion on Form-Embeddable Widget here: __________TODO cc Dimitri any more info on how this should be done? Can we meet tmrw?
Acceptance Criteria
Who: Can collect address info on pt or on a contact (who may or may not already exist in the system) (Idea: perhaps this could be set as config in the extension? like set to "patient" or "contact"?)
Visuals: Should follow Carbon Design System - see colors, spacing, and layout guidance in the 3.x Styleguide here: https://app.zeplin.io/project/60d59321e8100b0324762e05/styleguide
Nice to have for users: Type+Search: Should slim-down the dropdown list options as the user searches in the box. This way the user does not have to painfully scroll through all options looking for what they want.