Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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
  • 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:
    Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
     

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)




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)







  • No labels