This document covers the following:
- Outstanding user requests
- Validating email addresses
- Rejecting accounts
- Account permissions
- Suggested permission sets
- Deleting DoS accounts
Outstanding user requests
The Outstanding User Requests tab (see home page) allows users with appropriate permissions (approve user) to approve or reject any requests for access to the DoS. You will only see requests for regions you have access to.
Validating email addresses
You cannot approve a user’s DoS account until they have validated their email address.
If the user has not yet validated their email address by following the link in the email they were sent at registration, then it will show (unvalidated email) under their name and the following error message will be shown when you open the user’s details:
(Unvalidated email. Email address must be validated by the user before this account can be approved)
In this case, you will need to contact the user to request they validate their email address. It is advised that a period of 28 days is allowed for users to validate their email address, after which the request should be rejected with instructions to submit again and verify their email address if access is still required.
If the user has not received the email, ask them to check their junk mail folder and if they have entered their email address correctly onto the DoS. If this does not resolve the issue, you can resend the activation email as either plain text or rich text.
Once you have resent the email the following message is displayed: ‘Activation email has been resent…’
Rejecting accounts
It is sometimes appropriate to reject user account requests, for instance if the user has applied for DoS access, but another tool such as Pathways DoS or Service Finder would be more appropriate. If users have applied for an incorrect region, it is prudent to liaise with the relevant DoS team regarding this, however, the region can be altered without the need to reject the request. If you do wish to reject the request, click the ‘reject’ button and give the reason, which will be emailed to the requestor advising them that the request is rejected. If the requested is rejected because the user has inadvertently requested access to DoS when they require access to another product such as Profile Update or NHS Service Finder, it may be prudent to include the link to the correct product.
Account permissions
Users that have the ‘approve user’ permission can manage user permissions.
Allocating roles is very important as these roles define the functions that a user can carry out when using the DoS. Only give the user the permissions they need. This can be done both when a user requests a new account, or with existing users by clicking on ‘Account’, then ‘users in my region’.
For new users, some of the details are automatically populated depending on what the new user selected when completing the new user request.
The correct ‘Service Relationship’ should be added. Multiple service relationships can be added. They will see these services on their home page and their permissions will apply to the services and the child services underneath them. The available roles and abilities they provide are as follows:
Permission Role |
Provides the ability to… |
Based on… |
addCapacityGrids |
create new capacity grids in an existing database record |
Relationship |
addService |
create a new entry in the Database |
Relationship |
approveClinical |
make live the changes to Clinical details tab (users with the corresponding edit permission can edit and make live the changes at the same time) |
Relationship |
approveControlService |
make live the changes to Control Service attributes (users with the corresponding edit permission can edit and make live the changes at the same time) |
Relationship |
approveDemographic |
make live the changes to Demographic tab (users with the corresponding edit permission can edit and make live the changes at the same time) |
Relationship |
approveEndpoints |
make live the changes to Endpoints tab (users with the corresponding edit permission can edit and make live the changes at the same time) |
Relationship |
approveUser |
delegate assignments to new/existing users |
Region(s) |
bulkUpdate |
apply multiple changes to multiple services at once |
Region(s) |
compareService |
run/download compare service reports |
None |
controlService |
edit/propose changes (users with the corresponding approve permission can edit and make live the changes at the same time) to Control Service attributes |
Relationship |
editCapacity |
edit/make live changes to capacity status |
Relationship |
editCapacityGrids |
edit/make live changes to capacity grids |
Relationship |
editClinical |
edit/propose changes to Clinical Details tab (requires ‘viewClinical’ role in order to access the Clinical Details tab) |
Relationship |
editDemographic |
edit/propose changes to Demographic tab |
Relationship |
editEndpoints |
edit/propose changes2 to Endpoints tab |
Relationship |
searchBySymptom |
access to the Service Finder search by Z-Code (these permissions are no longer active within DoS. Users wishing to use NHS Service Finder must register on the NHS Service Finder site) |
N/A |
searchBySymptomSGSD |
access to the Service Finder search by SG/SD code |
N/A |
searchByType |
access to the Service Finder search by service type |
N/A |
testScenarios |
run the scenario testing tool |
N/A |
viewClinical |
read-only access to the Clinical Details tab |
None |
viewReport |
run/download service status reports |
Region(s) |
viewUnlinkedOrg |
view the list of unlinked commissioning organisations |
Region(s) |
userReport |
run/download user status reports |
Region(s) |
For new users, add the permissions and then click ‘Approve’.
For existing users, whose accounts are being amended, click ‘Save’.
Suggested permission sets
Not all colleagues within UEC require a DoS User Account, It is the responsibility of the DoS Team to ensure only appropriate colleagues are given DoS User Accounts.
Different types of DoS users will require certain permissions that are appropriate depending on the access required and the operational processes that have been put in place. The only users who should ever be given permissions to edit and update DoS should be DoS leads, and users required to make emergency changes in line with local arrangements.
Local DoS Lead
In most cases, DoS leads at both regional and local level should have all permissions added to their account. There may be some local variation; for example some regions may choose to maintain user account approvals at regional level. It’s also possible that newer leads may not be immediately given access to approve changes, until sufficient training has been given and adequate knowledge of the DoS has been gained. It is also possible that bulk update may be withheld for a period of time until sufficient training has been given, given the possibility for significant damage to be caused to the integrity of DoS data if this is used incorrectly.
Appropriate permission roles:
addCapacityGrids
addService
approveClinical
approveControlService
approveDemographic
approveEndpoints
approveUser
bulkUpdate
compareService
controlService
editCapacity
editCapacityGrids
editClinical
editDemographic
editEndpoints
editServiceAdmin
searchBySymptom
searchBySymptomSGSD
searchByType
searchRoadDistance
testScenarios
viewAdminAttribute
viewClinical
viewReport
viewServiceAdmin viewUnlinkedOrg
Regional DoS Lead
Regional DoS leads have strategic oversight of the DoS for their region and can delegate responsibility for ensuring the accuracy and integrity of the DoS to local DoS teams. To allow for this, regional leads should be given all permission roles.
Appropriate permission roles:
addCapacityGrids
addService
approveClinical
approveControlService
approveDemographic
approveEndpoints
approveUser
bulkUpdate
compareService
controlService
editCapacity
editCapacityGrids
editClinical
editDemographic
editEndpoints
editServiceAdmin
searchBySymptom
searchBySymptomSGSD
searchByType
searchRoadDistance
testScenarios
viewAdminAttribute
viewClinical
viewReport
viewServiceAdmin
viewUnlinkedOrg
Clinical Lead
A clinical lead should be given view access to all demographic and clinical information. Depending on whether they are a clinical lead for a single service or multiple, for such as a clinical lead for a region or ICB footprint, the user may be given access to a single service or multiple services. Clinical leads should NOT be given edit permissions for clinical information on DoS. To ensure the integrity of DoS data, it is important that changes to clinical profiling are made by fully trained DoS leads only. It is also strongly advised that the permission to approve clinical changes rests solely with DoS leads. Although some areas have trialled giving the approved clinical permission to clinicians, this is not recommended as it can cause unnecessary delays when urgent changes are needed. In order to ensure that clinical sign-off is obtained, local clinical governance processes should be followed and DoS leads should make the final changes. The same is true of demographic changes. It is possible that, depending on the service type, clinical leads may be given permission to edit capacity. However, it is generally recommended that capacity changes are actioned via local escalation routes to ensure proper sign-off by commissioners.
Appropriate permission roles:
viewClinical
compareService
editCapacity (in limited circumnstances)
111 Provider
It is not appropriate for staff within 111 providers to be given DoS accounts. 111 health advisors and clinical advisors should rely solely on NHS Pathways and its related products, such as Pathways Clinical Consultation Support (PaCCS) to access DoS information.
The exception to this rule would be staff specialising in reviewing DoS incidents. These staff should be given view access to the DoS for services in the footprint covered by their provider. It may be appropriate to give these staff view access to a full region, following the introduction of Single Virtual Call Centres. Some 111 providers may have delegated responsibility to make emergency changes during the out of hours period, in which case the following section on ‘Someone making emergency changes (including Director on Call)’ should be referred to.
Appropriate permission roles:
viewClinical
compareService
Someone making emergency changes (including Director on Call)
Most local and regional DoS teams do not work during the out of hours period. Local arrangements must therefore be in place for others to undertake emergency DoS changes during this period. These should be the only user group outside of DoS leads to be given edit rights to DoS. This should be done using individual DoS accounts and not shared accounts wherever possible in order to preserve an accurate audit trail of changes. Local processes must be in place to ensure that these changes are reported to local and regional DoS teams within 24 hours of the change being made. This is to allow DoS leads to review and amend changes as necessary, and to determine whether the change warrants a more permanent change to DoS.
Appropriate permission roles:
editCapacity
editDemographic
Service Provider (who is managing their account)
In some cases, it is appropriate for service providers to be given access to DoS. This can be to view the profile of their own service(s) in the same way as clinical leads, or in some cases to make certain limited changes. Some services will be given permission to edit their own capacity status, in line with local governance policies. In some cases, where regular changes to service provision is required, it may be appropriate for service leads to have access to edit permissions only, but not approve permissions. This allows the service lead to submit changes to information such as opening times, and alterations to disposition instructions. Without the approve permission being present for these accounts, these changes will be sent to DoS leads for approval. This can speed up communication between service leads and DoS leads,and ensure that local changes are made in a timely manner.
Contract teams and commissioning teams
It may be appropriate for local commissioning and contracting teams to be given view only or reporting access to DoS, in order to ensure that entries are accurately reflecting local commissioning arrangements. Although commissioners have overall responsibility and ownership of the data held in DoS, it is not appropriate that these users be given edit rights to DoS. It is important that changes to DoS are only made by DoS leads, and according to local governance processes. It is also important that DoS leads are recognised as the experts in the field, and therefore commissioning and contracting teams should raise any concerns or queries with DoS leads before reaching decisions or conclusions based on their own understanding of DoS.
Any others
Occasionally, requests for user accounts may be received that do not fit into the groups outlined here. In these situations, guidance should be sought from regional teams, or in some cases the national DoS team.
Deleting DoS accounts
DoS accounts no longer required should be manually deleted. These may be accounts where users require DoS access for a limited time only. For example, temporary staff, or those who are temporarily granted DoS access to cover an on-call period on a one-off basis. A record of these accounts should be maintained by local and/or regional DoS leads, along with a date when these accounts will no longer be required. Once this date is reached, the need for access should be re-evaluated and the account deleted if no longer required. You can delete a user’s DoS account by going to ‘Account’, clicking on ‘users in my region’, then selecting the DoS account and clicking delete. It is possible that some users may require DoS access for a limited time only.
Accounts where users have not logged in for more than 6 months will be deleted by the Live Services and Operations Team.
Queries
Any queries regarding this document should be directed to your Regional DoS team or:
National Directory of Services Team
NHS England Integrated Urgent Care Operational Delivery
england.dos@nhs.net
Publication reference: PRN00207