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

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: __________

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