Resources:
...
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/
- Add the metadata you want at:
- 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:
Jira Legacy server OpenMRS Issues serverId 45c5771b-fa4b-3e43-b34a-c19dc45ccc95 key O3-328
Visuals to know
| Current State in SmartCare-Ethiopia: | Current State in RefApp 2.x: (PIH-Haiti Registration Form Example) | Proposed Mockup |
|---|---|---|
|
Notice that this OMRS-EMR was able to customize the names of the regions (eg Department, Commune, etc) |
.gif?version=1&modificationDate=1652145592000&cacheVersion=1&api=v2&height=250)
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
- Can collect address info on pt or on a contact (who may or may not already exist in the system)