It is important to note that the module does not provide direct mappings between a Person Address and an Address Hierarchy Entry. For example, if the "City" field in a Person Address is set to "Boston" via the address hierarchy, the string "Boston" is simply stored in the "City" field; no keyed relationship is created between the entry in the Person Address table and the "Boston" entry in the Address Hierarchy Entry table.
The Address Hierarchy module provides a utility that can be scheduled to compare Person Addresses to Address Hierarchy Entries at regular intervals, and store keyed relationships between addresses and entries in a separate address_to_entry_map table. This table is NOT currently used by module itself, but can be used as a reference for writing custom reports, etc. This functionality is turned off by default, but can be configured via the Advanced Features page in the administration section.
To configure this functionality, check the "Check for address changes and update associated mappings..." check box on Advanced Features page, and specify the repeat interval for this task. The first time the this task is run, it will scan all the non-voided Person Addresses in the system and create Address To Entry Mappings for any matches it can find between addresses and entries. The next time the task is run, it will recalculate mappings for any addresses that have been updated since the previous run.
Note that an Address To Entry Map is a standard OpenMRS object, so it will be synchronized by the Sync module unless explicitly excluded. Therefore, the Address To Entry mapping utility need only be configured on a single server when used within a mult-server environment.
As of version 2.2.6, the module supports specifying "user-generated ids" for each address hierarchy entry when importing a hierarchy. A "user-generated id" is simply a free-text property of an address hierarchy entry that allows implementaters to store in the database some custom information for each entry. Currently, the module doesn't support any functionality for the ids beyond importing them, so at this point they really can only be accessed via sql queries, or custom-written code.
A user-generated id is appended to the end of an entry name, separated by a specified delimiter. For instance, here is an example of a standard pipe-delimited import file with user ids delimited by the percentage character (%): In the example below, the Delimiter would be
"|" and the User Generated ID Delimiter would be
"%". Neither delimiter includes the double quotes.
Note that for upper-level entries that appear more than once within the import file (United States, Massachusetts, Plymouth County) the user-generated id only needs to be specified one, though it is not problematic if it is specified more than once. In the event that more than one id is specified for a single entry, the id that ends up being stored is arbitrary (i.e., in a proper import file, no entry should have more than one id!).
Upon start-up, the address hierarchy module loads it's entire address cache into memory to speed up address searches. Since this slows down module startup, as of version 2.2.6, developers may wish to turn this functionality off during development, This can be done by setting the global property addresshierarchy.initializeAddressHierarchyCacheOnStartup to false.
As of version 2.11.0 it is possible to let the module activator load the address configuration and address hierarchy entries upon starting. The activator will scan the following location in the app data directory:
Two files are excepted to be found in there:
This file defines both the address template and the address hierarchy entry levels in the hierarchy. Furthermore it indicates the location of the second configuration file. Here is a sample file:
When wipe is set true the existing address hierarchy entries will be wiped before loading the address hierarchy entries from the CSV import file. On the other hand setting wipe to false allows to add additionnal entries to a persisted set already in database.
The CSV import file for address entries
Based on the above sample configuration this file is expected to be named addresshierarchy.csv.
This is the usual address hierarchies CSV import file, see 'Importing an Address Hierarchy' for more details about it.