Help and support for technical issues
All editors should register to use the Tactuum support portal at https://support.tactuum.com/hc/en-us/ The Right Decision Service has a contract with Tactuum for technical development and maintenance of the Right Decisions Platform.
When a technical problem is identified, editors should:
- Log in to the Support Portal.
- Include his.decisionsupport@nhs.scot in the ‘CC’ field. The CC field is only visible when you are logged in. It is important to include the HIS decision support email address in your tickets as this is the main way that the RDS team can keep track of issues arising with the system. In addition, the RDS team will help if your problem is related to content management issues that do not require technical input from Tactuum.
- Complete the fields in the form, providing as much detail as possible about the steps you took to encounter the problem, error messages, URLs etc.
- In the “Project” dropdown list, select “QURIS-UOS-RDS (new QURIS).
Select the appropriate category from the “Priority” dropdown list, using the following definitions from the RDS service level agreement with Tactuum. Response times from Tactuum are determined by the category selected. Note that Tactuum or the RDS team may change the priority if the one you select does not correspond to the service level agreement definition.
Important: If your issue is Critical/Urgent, please add "Urgent" into the subject line. This will ensure that Tactuum and the RDS team are immediately alerted to activate the business continuity plan.
Tactuum and RDS responsibilities
Tactuum has initial responsibility for responding to support ticket requests, so please do not routinely expect an immediate response direct from the RDS team. If the request lies out with Tactuum's remit, they will forward it on to the RDS team and advise the requester accordingly.
Support requests that are out with the warranty period of 12 weeks since the software was originally developed will not be automatically addressed by Tactuum. Tactuum passes these requests on to the RDS team, which will consider these requests for costed development work and will obtain estimate of effort and cost from Tactuum for priority issues.
Support tickets for technical issues that are not classified as bugs will not be automatically addressed by Tactuum. The definition of a bug is ‘a defect in the software that is at variance with documented user requirements.’ Issues that are not bugs will also be considered by the RDS team for new costed development work where budget permits.
Tactuum response times
P1 – Critical/Urgent |
|
Definition |
|
1. The Service as a whole is not operational for multiple users during the Support Period. 2. Multiple core functions of the Service are not operational for multiple users during the Support Period. |
|
Response |
Resolution |
Initial response within 1 hour on receipt of notification. |
Investigation and attempt to resolve within 4 hours of response time pickup. |
P2 – High |
|
Definition |
|
1. A single core function of the Service is not operational for multiple users during the Support Period. 2. Multiple non-core functions of the Service are not operational for multiple users during the Support Period. |
|
Response |
Resolution |
Initial response within 4 hours on receipt of notification. |
Investigation and a suggested resolution within 24 hours of response time pickup. Where a scheduled release plan exists for the Service, P2 – High resolutions will be planned into the next available release slot. Alternatively, resolutions will be deployed as required once costs have been agreed and approved. |
P3 – Medium/Normal |
|
Definition |
|
1. One or more non-core functions of the Service are not operational for multiple users during the Support Period. 2. A function of the Service does not work as expected/defined but does not cause a serious impact to the overall Service. |
|
Response |
Resolution |
Initial response within 24 hours on receipt of notification. |
Where a scheduled release plan exists for the Service, P3 – Medium/Normal issues will be planned into the next available release slot. |
P4 – Low |
|
Definition |
|
1. One or more non-core functions of the Service are not operational for a single user during the Support Period. 2. Any other issues of minor impact, e.g. cosmetic. |
|
Response |
Resolution |
Initial response within 24 hours on receipt of notification. |
Where a scheduled release plan exists for the Service, P4 – Low issues will be planned into the next available release slot. |
Tactuum or the RDS team will add comments and questions to the Support Portal ticket to respond to your support request. You should also use the ticket to add your responses and further comments and questions.
If you feel the response is not satisfactory or has not met the service level agreement obligations, please email ann.wales3@nhs.scot direct.
Content management and other non-technical issues
Non-technical issues, including questions about content management, or requests about training, should be sent to the RDS Support email address his.decisionsupport@nhs.scot . We will endeavour to respond to your request within 3 working days.
You also have the option to use the “General Discussion” and “Asked and Answered” sections of the community area to seek help from the RDS editor community.
High risk /critical issues
From time to time issues may be detected which represent a potential risk to clinical care or organisational reputation. For example:
- Non-availability of a toolkit which is the primary route for clinicians to access essential clinical guidance.
- Media in password-protected areas being searchable via the Internet.
- Errors in transcribing clinical content.
Where the problem is technical in nature, an “Urgent” support ticket should be raised, copied to his.decisionsupport@nhs.scot . You should also email his.decisionsupport@nhs.scot and ann.wales3@nhs.scot directly so that the RDS team is notified to liaise with Tactuum to find a resolution.
Once the problem is resolved, Tactuum will perform a root cause analysis, put in place appropriate mitigation, and inform the RDS team, who will update the editors. Both Tactuum and the RDS team will complete an incident report which will be made available for the governance groups in HIS and the Scottish Government-led Decision Support Advisory Board to review.
Back-ups and disaster recovery
Backups of all Tactuum produced software and configuration files are retained within a secure source code repository. Backups are applied to website(s), database(s) and any associated file/media folders, i.e. all elements required to reinstate the Service in full.
Backups are performed weekly (automatically).
Weekly backups are retained within Microsoft Azure Cloud service for 30 days.
Backups are normally scheduled to run between the hours of 2am and 4am GMT to avoid impact to service.
In the event of complete failure of the hosting platform/environment disaster recovery (Disaster Recovery” or “DR”) procedures include:
Failure within the cloud hosting environment will result in recovery backups being deployed into an alternative cloud environment. This will be performed in agreement with the Client. Complete deployment (for a single service) into alternative/new cloud hosting environment would typically require 2 days.