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: O3-968 - Getting issue details... STATUS
  • Previous O3 ticket/discussion about Address Hierarchy: O3-328 - Getting issue details... STATUS  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

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.