OpenSRP Location Hierarchy Endpoint
The OpenSRP 2.0 Location Hierarchy endpoint is designed to efficiently retrieve and manage hierarchical location data within the OpenSRP system. The location hierarchy is defined by the Location.partOf property on the Location resource in the FHIR specification.
1. Data Retrieval Process
Overview
The endpoint is designed to return data in two formats: a tree (hierarchical) format or a list format. This is controlled by a mode parameter. This endpoint is built to return the hierarchy starting from the provided IDs as the root to all its children. Below are the parameters allowed by the endpoint:
_id- This is the ID of the location for which you want the hierarchy. Example:[GET] /LocationHierarchy?_id=<some-location-id>_syncLocations- This parameter holds IDs of locations selected by the users. The locations are comma-separated. Example:[GET] /LocationHierarchy?_syncLocations=<some-location-id,some-location-id>administrativeLevelMin- Specifies the minimum administrative level to include in the response. Locations at this level and above will be included. Example:[GET] /LocationHierarchy?_id=<some-location-id>&administrativeLevelMin=2&administrativeLevelMax=4administrativeLevelMax- Specifies the maximum administrative level to include in the response. Locations at this level and below will be included. Example:[GET] /LocationHierarchy?_id=<some-location-id>&administrativeLevelMin=2&administrativeLevelMax=4filterInventory- A boolean parameter that specifies whether the response should be filtered by locations with inventories. Example:[GET] /LocationHierarchy?_id=<some-location-id>&filterInventory=true_lastUpdated- This filter allows users to retrieve locations based on the last modification date, making it useful for tracking recent updates or syncing data changes over time. Example:[GET] /LocationHierarchy?_id=<some-location-id>&mode=list&_lastUpdated=2024-09-22T15%3A13%3A53.014%2B00%3A00_summary- This allows users to retrieve the total number of matching resources without returning the resource data. Example:[GET] /LocationHierarchy?_id=<some-location-id>&mode=list&_summary=countmode- A parameter to switch between the two response formats. Example:[GET] /LocationHierarchy?_id=<some-location-id>&mode=list
LocationHierarchy List Mode
The LocationHierarchy endpoint supports two response formats: tree and list. By default, the response format remains a tree, providing hierarchical location data. In addition, clients can request the endpoint to return location resources in a flat list format by providing a request parameter mode=list.
Example:
[GET] /LocationHierarchy?_id=<some-location-id>&mode=list&_count=<page-size>&_page=<page-number>&_sort=<some-sort>
LocationHierarchy Dynamic Identifier
The LocationHierarchy endpoint has the following supported functionalities when the _id is not provided as a parameter:
- Build location hierarchies of the User Assigned Locations: The
LocationHierarchyendpoint will build location hierarchies of all user-assigned locations. Example:[GET] /LocationHierarchy - Build location hierarchies of the User Selected Locations: The
LocationHierarchyendpoint will build location hierarchies of the locations provided by the user via the_syncLocationsparameter.-
Conditions for User Selected Location Hierarchies
- The deployment/app user should have Related Entity Location as their sync strategy.
- The deployment/app user should have the
ALL_LOCATIONSrole on Keycloak. - The request should have the
_syncLocationsparameter set.
-
Example:
[GET] /LocationHierarchy?_syncLocations=<some-location-id>,<some-location-id>,<some-location-id>
All other valid parameters can be used on this endpoint.
LocationHierarchy Administrative Level Filters
The LocationHierarchy endpoint supports filtering by administrative levels. This is useful for querying locations at specific levels within the hierarchy. The following search parameters are available:
administrativeLevelMin: Specifies the minimum administrative level to include in the response. Locations at this level and above will be included.administrativeLevelMax: Specifies the maximum administrative level to include in the response. Locations at this level and below will be included. If not set, it defaults to the value ofDEFAULT_MAX_ADMIN_LEVELset in theConstants.javafile.
Behavior Based on Parameters:
- No Parameters Defined: The endpoint works as it does currently, returning the full hierarchy.
- Only
administrativeLevelMinDefined: The response will include all locations from the specified minimum administrative level up to the root. - Only
administrativeLevelMaxDefined: The response will include all locations from the root down to the specified maximum administrative level. - Both Parameters Defined: The response will include locations only within the specified range of administrative levels.
Example:
[GET] /LocationHierarchy?_id=<some-location-id>&administrativeLevelMin=2&administrativeLevelMax=4&_count=<page-size>&_page=<page-number>&_sort=<some-sort>
Inventory Filters
The LocationHierarchy endpoint supports filtering by inventory availability, allowing users to specify whether they want to retrieve only locations that have associated inventories. This filter can be particularly useful for narrowing down the results to locations that are actively involved in inventory management. The following search parameter is available:
filterInventory: A boolean parameter that specifies whether the response should be filtered by locations with inventories.filterInventory=true: Only locations with inventories will be included in the response.filterInventory=false(or not set): Locations with or without inventories will be returned. This effectively disables inventory-based filtering. The response will include all locations, regardless of their inventory status. Both locations with and without inventories will be returned.
Example:
[GET] /LocationHierarchy?_id=<some-location-id>&filterInventory=true&_count=<page-size>&_page=<page-number>&_sort=<some-sort>
LastUpdated Filters
The LocationHierarchy endpoint supports filtering by the last updated timestamp of locations. This filter allows users to retrieve locations based on the last modification date, making it useful for tracking recent updates or syncing data changes over time. The behavior based on the _lastUpdated parameter is as follows:
_lastUpdatedNot Defined: The endpoint will include all locations in the response, regardless of when they were last modified._lastUpdatedDefined: The response will include only those locations that were updated on or after the specified timestamp.
Note: This filter only works when in list mode, i.e., mode=list is set as one of the parameters.
Example:
[GET] /LocationHierarchy?_id=<some-location-id>&mode=list&_lastUpdated=2024-09-22T15%3A13%3A53.014%2B00%3A00&_count=<page-size>&_page=<page-number>&_sort=<some-sort>
LocationHierarchy Summary Count
The LocationHierarchy endpoint supports the _summary=count parameter. This allows users to retrieve the total number of matching resources without returning the resource data. This filter only works when in list mode, i.e., mode=list is set as one of the parameters.
Example:
[GET] /LocationHierarchy?_id=<some-location-id>&mode=list&_summary=count