This article outlines what your Radar System Hierarchy is, the implications your Hierarchy has on functionality within Radar and some examples of how you may choose to set up your Hierarchy. Users setting up their Hierarchy for the first time or thinking of changing their Hierarchy are advised to read this article.


Your System Hierarchy is integral to many areas of Radar and can be complex to amend after you start using Radar so it is important to consider your Hierarchy setup first before configuring other areas of Radar. You should aim to implement a Hierarchy that will still be relevant for some time in the future.


We recommend reading the entirety of this guide and speaking with your Radar Project Manager/Account Manager before deciding how to structure your Radar System Hierarchy.




Radar Hierarchy Overview


Radar allows for a three-tiered System Hierarchy as shown in the diagram below:

 

Organisation: This is the top-most level in the hierarchy and encompasses the entirety of your Radar system. E.g. this is the name of your organisation/business


Region: The Organisation can be broken down into Region(s). Regions are commonly used to group together multiple, related services. Often Regions are geographic areas (e.g. counties or cities) but this does not have to be the case. Regions could be used to represent different areas of a business. 


E.g. You could have Regions called ‘York’ and ‘Leeds’, or you could have Regions called ‘Residential Care’ and ‘Domiciliary Care’.


There is no limit to the number of Regions you can create.


Location: Locations often represent a Service you provide at a particular place. 


E.g. A Location could be a care home, a GP surgery or a clinic.


Locations are very important, as these are where items are logged e.g. Events are raised at a specific Location and Audits are scheduled for a specific Location. 


There is no limit to the number of Locations you can create.


If your System Hierarchy has more than three tiers there are ways to capture additional levels of information. This is explained later within this document.



System Implications


The way you set up your System Hierarchy affects key functionality within Radar. 


Below are the five aspects of your system to consider when designing your System Hierarchy:

  1. Location-Based Functionality
  2. Analytics and Reporting
  3. Data Access Levels for Users
  4. User Work Assignment
  5. Dashboard Displays


1. Location-Based Functionality

The following items within Radar need to be logged against a Location in your System Hierarchy:

  • Events (e.g. Incidents are reported at a Location)
  • Audits (e.g. audits are Scheduled at a Location)
  • Actions
  • Scheduled Tasks

When deciding what to set up as your Locations in Radar you will need to consider how you currently record the above information. E.g. are incident events reported per care home, per surgery, per service etc. 

The screen shots below provide some examples where you would select a Location when recording or logging new items in Radar.

 

 

 

In the above examples, items cannot be raised at a Region or against the Organisation. However, some functionality allows you to allocate an item against multiple Locations within the same Region or at all Locations within the Organisation. 


E.g. you may schedule an audit at all Locations within a particular Region or you may schedule a task against every Location within your Organisation (see screenshot below).

 

 

Key Considerations:

  • When your users currently report Events/Incidents how do you capture where the Event took place – can these places be set up as Locations?
     
  • What do you audit in your organisation? List your audits and for each one record where the audit is carried out at e.g.
    - Medication Management Audits – carried out at every service
    - KLOE Audit – carried out at every service
    - Kitchen Audit – carried out at every kitchen at a service

    If you find the majority of your audits are carried out at your services you may decide to set up your services as Radar Locations. However, this would mean separate audits would need to be scheduled for any building/room-based audits at the same service e.g. ‘Ground Floor - Kitchen Audit’ and ‘First Floor – Kitchen Audit’ would be scheduled as separate audits at the same Location.

  • What routine scheduled tasks/checks are completed at your Organisation and where are they completed? e.g.
    - Fire Alarm checks are completed in every building at a service
    - Cleaning Checklists are completed in each building at a service
    - PAT Checks are completed across a service

    Even if most of your Scheduled Tasks are completed per building, you may decide to set up your services as Locations if this is the level where you want to log Events and schedule the majority of your Audits. This would mean that you create separate Scheduled Tasks for each Building within the service Location.

 

  • Do some services/sites require the same types of Audits/Scheduled tasks? Can you group these services/sites into Regions  to make it quicker to schedule the same audit/scheduled task across all Locations within that Region?
    E.g. if your organisation provides separate Care Home and Day Centre services you may have some audits that are only relevant to your Care Homes e.g. Bedroom Hygiene Audits. In this instance you may choose to create your Regions as ‘Residential Care’ and ‘Day Care’ to easily schedule the ‘Bedroom Hygiene Audit’ at all Care Home Locations within the ‘Residential Care’ Region.


2. Analytics and Reporting

Your Radar Locations and Regions are also vital to the data captured for your analysis reports and analytics graphs.

As the items outlined above (Events, Audits, Actions and Scheduled Tasks) are recorded against a Location, the analysis reports and analytics graphs display data by Location/Region.


e.g. you can view the number of Events logged at each Location, calculate the average Audit Score per Location or the number of open Actions against each Location.

 

When deciding on your Locations and Regions you should consider what data reporting levels you commonly use and what data you regularly monitor. Setting your Locations at the right level will ensure Radar analytics provide useful information and reports can be produced more quickly.


Key Considerations

  • Do you have a mix of reporting levels required for different stakeholders? List items and state at which level they need to be reported at, e.g.
    - Hand Hygiene Audit reported across your services
    - Fire Safety is reported by building/site

    If the majority of your reports are at the physical location/site you may want to set these up as Locations so that you can easily produce the required reports.
    Note: You can create more complex reports that capture additional information. Please see the ‘Complex Hierarchy Examples’ later for more information.

  • What statistics are you required to submit to commissioners/governing bodies?
    If these reports require data to be displayed at a certain level or across an area of your Organisation  you may use this to help choose your Regions and Locations.
      
  • Do you have any example reports that can be shared with your Project Manager/Account Manager?


3. Data Access Levels for Users

Every User within Radar must be assigned a Role which has a ‘Scope’ to control the level of data access for any users assigned that Role. 


The Role Scope is linked to your Radar System Hierarchy so it is important to consider what levels of data access you want within your system when designing your Hierarchy.


Roles can have the following Scopes:

  • Organisation Scope – Users with an Organisation Role can access all data in your Radar system.
  • Region Scope – Users with a Regional Role can access data at all Locations within a Region(s).
  • Location Scope – Users with a Location Role can access data at a specific Location(s).


When a user is allocated a Region or Location Scope role, you will need to select any Region(s) or Location(s) within your System Hierarchy where the user is based. A user may be assigned to more than one Location/Region. The screen shot below shows the drop down list where you can tick Locations/Regions where a user is based when assigning them a Role.

 

 

A staff member with a Location scope role can see only the Events at the Location(s) assigned to them, whereas a user with an Organisation scope role, will have visibility of all events for the organisation.


Note: Specific Role Permissions can also be configured to control what the user can do and see with the data they have access to. Whilst the details of setting up Permissions are not covered in this guide it is worth being aware that functionality-based Role restrictions exist as you decide what Roles you require. Your Project Manager will provide more information about how to configure Permissions as you progress through your onboarding.


The system has some built-in Roles that are linked to our Toolkit Events and workflows. These are listed in the diagram below along with their Scope:

 

Note: There is no default Regional Role – you are able to create additional roles as needed.

 

Key Considerations:

  • List your key staff roles and consider what data these Roles should have access to. Consider any policies and GDPR.
      
  • What levels do staff operate at?
    It may help to create a hierarchy of your key roles and see how this maps to your proposed Radar System Hierarchy.
     
  • What data should be available to a user when they login with Regional or Location Scope roles?
      
  • Do your staff work across a service operating out of multiple physical sites, or are they based at one physical location? e.g
    If the majority of staff work at one physical site you may choose to set up your sites as Radar Locations to prevent them seeing data across a whole service. However, if most staff work across multiple physical sites within the same service you may choose to set up the service as the Location, so they have greater visibility across the service.


4. User Work Assignment

When Events are logged in Radar, a series of follow up tasks can automatically be created and assigned to your system users based on their Location and Role.


e.g. if an Incident Event is logged at a Care Home, a user based at the Care Home with the ‘Service Manager’ role will be assigned to complete an Incident Investigation step.


An Event step can only be assigned to one user so that there is no confusion over who is responsible for completing the work. If an Event workflow is configured to assign a step to the Location ‘Service Manager’ and there is more than one user at a Location with this role, the system will assign the step to the first user that was created in the system with the relevant role.

To ensure Event workflow steps are distributed correctly you will need to consider how you currently distribute work throughout your staff, teams and services.


Key Considerations:

  • How do you currently assign follow up tasks when an incident/event is reported?
    E.g. do you have managers across your services or at physical sites that authorise/investigate an event? If work is assigned based on the physical site you may choose to set these up as your Radar Locations. However, if you have multiple services at one site but assign tasks based on the service you may choose to set up your services as Locations.

  • Are you intending to use our Toolkit Events?
    Our Toolkit events use the ‘Service Manager’ role when assigning Event steps. The Toolkit Events are designed for use where your services are set up as Locations. Toolkit Events can be customised, this may require the use of Service Hours depending on your Radar licence agreement.


5. Dashboard Displays

Within Radar information can often be filtered and viewed automatically by Location/Region on various dashboards.

When deciding what to set up as a Location/Region consider what information users need to easily group and view to identify where an item has been logged and what work they need to complete. This applies particularly to Users with Organisation/Region scope Roles, or users that are based at more than one Location as these users will have visibility of data across multiple Locations.


Below are some examples where information can be filtered on dashboards by Location/Region:

  • Main Dashboard
  • Scheduled Audits
  • Recorded Events
  • Scheduled Tasks
  • Actions

 

Note: Users will only be able to see data at the Locations/Regions selected in their Role Scope.


Key Considerations:

  • What data do managers need to be able to easily monitor their service/area within Radar? e.g.
     
    When deciding on your Regions and Locations consider how managers need to easily filter data e.g. is this by geographic area or by service type?

  • Do any of your users work at multiple services/sites? e.g.
    Users that work at different services may need to easily distinguish where information has been logged. Setting up your services as a Location would enables users to quickly filter and see what has been recorded at the service they are working at.

    Alternatively, if users work across multiple physical sites at the same service and need to be able to quickly filter for information based on the physical site, you may choose to set up the physical site as the Location.



Issues to Avoid

The table below summarises the key issues to avoid and consider when structuring your hierarchy and the impact of setting your Locations at a too high/granular level.


System Implications

Location Level Too High/Broad

Location Level Too Granular 

Location-Based Functionality

Events/Audits/Scheduled Tasks etc. may not capture specifically where the item took place and may be duplicated at the same Location e.g. you will need to schedule the same audit many times at the same Location

Events/Audits/Scheduled Tasks etc. don’t fully capture where the item took place and may need to be duplicated at another Location

Analytics and Reporting

Data not specific or detailed enough to be useful

e.g. difficult to see all Complaints raised at a particular site

Data superfluous and obscures important, higher-level trends

e.g. difficult to see all Complaints raised at a particular service

Data Access Levels for Users

Users can access more data than they need

Users require multiple Roles at different Locations to access relevant data

User Work Assignment

Event workflow steps are not assigned to the most relevant user due to multiple users within a Region/Location having the same Role

Users need to be based at multiple Locations to ensure correct Event workflow steps are assigned to them

Dashboard Displays

Dashboard filters cannot drill down to specific services/sites and users will need to create their own Reports to view relevant data

Multiple dashboard filters needed to be applied to find information across a service/site



Simple Hierarchy Example

You may have a simple System Hierarchy with one or two Regions and several Locations.


The example below is for a care home service provider. 

 

A separate Location has been created for each care home. A Location has also been created for the ‘Head Office’ so that Audits, Events and Scheduled Tasks can be logged there if needed.


When deciding on your Regions it can be beneficial to consider any expansion plans to ensure your System Hierarchy will still be relevant in 5 years’ time. Rather than having a Region of the ‘United Kingdom’ you may choose to name the Region by country/county/city or perhaps the name of the organisation itself.



Complex Hierarchy Examples

If you find that your Organisation Hierarchy has more than 3 tiers it can be hard to simplify the structure for your Radar configuration.


You may have a hierarchy as below:

 


In this instance, your GP OOH and Phlebotomy Services comprise of multiple physical sites so you will need to consider all the System Implications outlined above to decide what you want to configure as your Locations.


There are 2 ways that Radar can help capture information beyond the three-tiered hierarchy by:


1. Using Location Tags

2. Using Custom Form Fields


The additional information captured will be available within your ‘Analytics and Reports’ but will not affect ‘Location-Based Functionality’, ‘Data Access Levels for Users’, ‘User Task Assignment’ or ‘Dashboard Displays’.


1. Using Location Tags

Your Locations can be assigned ‘Tags’ that apply a label/category to the Location – these tags are used in your Analytics Location Tag report. This can be used to capture an additional level of information when items such as Events or Audits are logged against a Location in Radar.


Note: The Radar team will need to set up the Location Tags for you. Depending on your Radar license, setting up Location Tags may use some of your Service Hours.


Below are some examples of how Location Tags may be applied.


Example 1



In the example above the physical sites have been set up as your Radar Locations. The type of service has been added to each Location as a Tag. The city has been created as the Region. 


With the above set up you will primarily be able to report and filter by the physical sites as Locations and cities as Regions. User Role Scopes will also be linked to the physical Locations and city Regions.

 

However, within your Analytics reports, there will be a graph to show data by Location Tag which enables you to create reports based on the ‘service type’. 


The screen shot below shows an example of your Analytics Events dashboard with the Location graphs highlighted.


You can filter your data by Location tag to analyse your Events by service type (see screen shot below).

 

  

Example 2


In the example above the physical addresses have still been set up as your Radar Locations however, the types of service have been set up as Regions. The city has instead been added as a Location Tag.


This enables you to view data easily by service type on dashboard in Radar rather than by the city. Role scope and data access will also be configured by service type and physical site.


However, you can use the Analytics Location Tag graph to see the number of Events raised at each city. 


 

2. Using Custom Form Fields

When logging Events in Radar the data forms used to record information can include custom fields that capture additional information about the Event.


Any data fields within an Event can be reported on within our Report Builder. The majority of fields can also be ‘tagged’ and included in the Analytics Event Tags graph.


Event Form Fields can be created and managed by yourself.


This method of capturing data cannot be used for Audits, Scheduled Tasks or Actions.


Below are some examples of how Event Form Fields can be used.

 

Example 1


In the example below the cities have been set up as Regions and the service types have been set up as Locations. This enables you to filter and restrict user data access by service type and city. Dashboards and most reports will display data by the service type Locations and city Regions. Location-based functionality such as Events and Audits are logged at the service type Locations.


The physical sites have been created within a Custom Form List that can be selected within the details of an Event. This enables you to see a breakdown of Events by physical site within the Radar Report Builder and the Analytics Event Tags report.


 

You can filter your data by the Event Tags to analyse your Events by the physical site.


Example 2

Custom Event Form Fields can be useful for domiciliary care providers that many not want to create and maintain separate Locations for the individual, personal addresses of their Service Users.

 

In the example above, the service types have been set up as Regions. In the ‘Domiciliary Care’ Region each city has been set up as a Location and the service user’s address can be captured as needed within the Event Form Details.

 

This enables dashboard displays and staff data access to be determined by the service type and the city where they might be based.


Event Details store the service users’ address and exports can be created within the Report Builder to include service users’ addresses.



What To Do Next

Together, you and your Project Manager/Account Manager can make an informed decision on how best to approach the configuration.


1. Define what your Regions and Locations represent in your system hierarchy.


Hierarchy LevelMy Definition
Locatione.g. My Radar Locations represent the physical buildings that make up my organisation.
Regione.g. My Radar Regions represent the cities where my organisation operates.


2. Map out your hierarchy in a table and provide this to your Project Manager.


Region

Location

Location Tag (Optional)

Leeds

Beech Road Hospital

Phlebotomy

Leeds

Willow Street Clinic

GP OOH

York

Elm Tree Hospital

Phlebotomy

York

Holly Bank Surgery

GP OOH

 ...

 ...

 ...

 ...

 ...

 ...