DrDoctor Service Level Agreement
Last Updated: 10 July 2024
Service Level Agreement - Gold
1. Introduction
This Service Level Agreement (the "SLA") applies if (1) DrDoctor is party to a written, in-force and binding contractual agreement with the Customer (the “Services Agreement”), and (2) the Services Agreement incorporates this SLA directly (as a schedule, exhibit or similar) or by referring to this SLA or generally to the DrDoctor Service Level Agreement.
DrDoctor may change its standard Service Level Agreement at any time. The version of this SLA that shall apply under the agreement at any particular time during the term of the SaaS Agreement shall be the then-current version of this SLA issued by DrDoctor at that time.
This SLA sets out the Service Levels which DrDoctor is required to achieve when delivering the Services, the mechanism by which Service Failures will be managed and the method by which DrDoctor’s performance of the Services will be monitored.
Goals and Objectives
The purpose of this SLA is to ensure that the proper elements and commitments are in place to provide consistent service support and delivery to the Customer by DrDoctor.
The objectives of this SLA are to:
- Provide clear reference to service ownership, accountability, roles and/or responsibilities.
- Present a clear, concise and measurable description of service provision to the Customer.
- Match perceptions of expected service provision with actual service support & delivery.
2. Performance Reporting and Performance Review
DrDoctor commits to collecting data that will enable service to be accurately, efficiently and effectively monitored.
DrDoctor must make available Service Level reports at the end of each reporting period for the purposes of review by the Customer. Upon request, Service Management Meetings can be scheduled with the Customer at regular intervals.
4. Service Management
4.1 Service Scope
The following Service desk methods of communication are covered by this Agreement;
- Manned telephone support
- Email support
- Live Chat
4.2 Service Availability
Service desk coverage by DrDoctor as outlined in this agreement follows the schedule specified below.
Core Service Desk hours are 9am - 5pm Mon – Fri (excluding Bank Holidays).
Tickets may be logged by the following channels
- Telephone Support: 24hrs
- Support Number: 0330 3211 206 (ask for Support)
- Email Support: 24hrs
- Email: support@drdoctor.co.uk
- Live Chat: 9am – 5pm Mon – Fri (excluding Bank Holidays)
4.3 Service Desk Expectations
4.3.1 Call answer time to be 95% of calls to be answered within < 60 seconds during core opening hours.
4.3.2 The Service Desk will provide advisors with the means to securely and accurately
-
- Provide technical support
- Catalogue the enquiry
- Record user contact details
- Schedule and manage call back; Initiate management information; Validate caller identity
- Set / clear / monitor outstanding work
4.3.3 DrDoctor will provide a Service Desk to manage service incidents reported by the Customer and will be required to rectify reported faults.
4.3.4 DrDoctor will provide the Customer with a documented Service support model, identifying the main procedures, including the procedures for passing calls on to other relevant parties.
4.3.5 The DrDoctor will provide the means to register, track and manage calls from initiation to resolution. Call histories will be retained for 12 months.
4.3.6 The Service Desk will provide the means for advisors to receive up to date information on known faults with any aspect of the Service to enable information to be quickly passed on to callers.
4.3.7 Advisors will record and update appropriate level of details for resolution and transfer of calls within their own Service Desk systems.
4.3.8 Faults reported by service users or detected by the DrDoctor will be logged on a single system and given a unique reference number. This reference number is to be used with all communication with the Customer.
4.3.9 The capture, retention and management of Patient Identifiers (PIDs) will comply with Customer and national standards on the protection of patient information and the Data Protection Act and other relevant regulations and legislation. This includes processing of third party data.
4.3.10 The Service Desk will provide a single contact point for all enquiries by telephone and email. An acknowledgement should be issued within a reasonable time of receipt as agreed with the Customer, and a unique reference enquiry number should be issued, to be used if the service user requires follow up of the enquiry.
4.3.11 The Service Desk call number will not be chargeable at more than local rates.
4.3.12 The Service Desk will only be required to receive calls in English.
4.3.13 The Service Desk must comply with the requirements of the Disability Discrimination Act.
4.3.14 The Service Desk should provide the capability for users to log non-priority calls on-line with the ability to attach images and documents in support of both new calls and existing cases. Service users should be able to view the progress of logged calls and to provide additional information to the DrDoctor.
5. Service Agreements
5.0 Services Definitions
5.0.0 Terminology
A Service Failure (Incident) is an event that that results in the interruption of one of more services.
A Service Request is the need or wish for assistance, enhancement or change with something that does not result in a Service Failure.
Service(s) as defined in the agreement with the Customer.
5.0.1 Severity
The severity will be assigned by DrDoctor upon triage, taking into consideration the information provided by Customer and the application of the descriptions below:
Severity/Priority |
Description |
Level 1 Severe |
A Service Failure that results in one or more of the following outcomes:
a. A significant, adverse impact on the provision of the Service to a large number of service users
b. A significant, adverse impact on the delivery of patient care to a large number of patients
a. c. Significant financial loss and/or disruption to the Customer or a Subcontracting Customer.
d. Material loss or corruption of Customer or Subcontracting Customer data, or its provision to a service user
No work-around will be available for a Severity 1 Incident. |
Level 2 High |
A Service Failure that results in one or more of the following outcomes:
a. A significant, adverse impact on the provision of the Service to a small or moderate number of service users
b. A moderate, adverse impact on the delivery of the Service to a large number of service users.
c. A significant adverse impact on the delivery of patient care to a small or moderate number of patients
d. A moderate adverse impact on the delivery of patient care to a large number of patients
e. A moderate financial loss and/or disruption to the Customer, or a Sub Contracting Customer.
The Customer has only limited use of the Service. The incident may be mitigated by using a work-around. |
Level 3 Medium |
A Service Failure that results in one or more of the following outcomes:
a. A moderate, adverse impact on the provision of the Service to a small or moderate number of service users
b. A minor, adverse impact on the delivery of the Service to a large number of service users.
c. A moderate adverse impact on the delivery of patient care to a small or moderate number of patients
d. A minor adverse impact on the delivery of patient care to a large number of patients
Operation of the system is impaired, but only to a minor degree. Overall, the Service can still be used. A workaround is available. |
Level 4 Low |
A Service Failure that results in one or more of the following outcomes:
a. A minor, adverse impact on the provision of the Service to a small or moderate number of service users
b. A minor, adverse impact on the delivery of patient care to a small number or moderate number of patients.
A workaround is available. |
Level 5 No impact |
A Service Failure affecting only the presentation of the Service, with no functional impact and which does not impact on the delivery of care to any patient.
Feature Requests/Enhancements. |
Examples are given below:
Severity/Priority |
Incident |
Level 1 |
System crash, with no cluster failover – total loss of Service. No users able to log on to the Service. Security of DrDoctor’s Application Software rendering it vulnerable to unauthorised access. Mismatched or corrupt data for a large group of patients – e.g. demographics for one patient being displayed with images for another patient. |
Level 2
|
Unplanned failover to a resilient node in the Service. Loss of a Service HL7 interface. Mismatched or corrupt data for a patient or small group of patients – e.g. demographics for one patient being displayed with images for another patient. No access to the images for a patient or small group of patients. |
Level 3 |
Failure of access for a single service user. Loss of a particular function with no work around available. |
Level 4 |
Loss of a particular function with a work around available. All incidents relating to the Test or Train environments. |
Level 5 |
Cosmetic changes, e.g. a spelling error in a field label or misalignment of onscreen data. Minor faults that can wait until the next release. |
5.0.2 Service Timings
The times as determined by the events in the management of an incident are defined below.
Response Time
Is defined as the amount of time between the time the Customer first reports an incident/request, and the time the Customer is notified the ticket is logged
Triage Time
Is defined as the amount of time between the Customer being notified the ticket has been logged and the incident/request is reviewed, and priority is assigned.
Intervention Time
Is the period between the ticket being triaged and the analysis of the problem/request.
Resolution Time
is the period between the analysis being completed and when a fix/resolution provided by DrDoctor is applied and verified.
Restoration Time
Is the total period of time taken for Response, Triage, Intervention and Resolution
Dealing with multiple incidents
Incidents are mutually exclusive; i.e. any one event which could potentially fall within the definition of more than one incident will only be counted as one incident, with the highest applicable Severity level.
5.1 Service Response & Resolution
DrDoctor will respond and resolve incidents within a fault resolution process. The following time periods will apply, depending on the severity of the incident and Support level agreed:
Gold |
||||
Severity/Priority |
Response Time |
Intervention Time |
Resolution Time |
Restoration Time |
1 |
0.5 hours |
3.5 Hours |
4 Hours |
8 Hours |
2 |
0.5 hours |
10 Hours |
12 hours |
24 Hours |
3 |
0.5 hours |
120 hours |
24 hours |
168 hours |
4 |
0.5 hours |
840 hours (35 Days) |
96 hours (4 days) |
960 hours (40 Days) |
5 |
0.5 hours |
Prioritised Accordingly |
|
Prioritised Accordingly |
5.1.1 Exceptions:
- 24-hour support can be provided for an additional fee, however this will only apply to Severity Level 1 & 2 issues.
- Should a viable interim solution be available that restores Service or alleviates immediate concern, this will be deemed as resolved and a root cause fix will be prioritised as a Severity Level 5 issue.
- Any material delays from the Customer in providing information essential to the investigation or restoration of a Service Failure will constitute a ‘clock stop’ for the timing of that issue.
5.1.1 Completion of the fault resolution process
The resolution of the fault is reported to and agreed by the Customer. The successful resolution of a fault is documented by DrDoctor. Once this has been completed, the fault resolution process is complete.
5.2 Service Availability
- DrDoctor will measure the availability of the Service; it will be measured against a target of 9% in a 12 month period.
- DrDoctor will monitor the availability of the system and shall provide the results of such monitoring to the Customer via a monthly service report.
- Availability will be measured in accordance with the following formula:
Service Availability % =
MP |
= |
Total number of minutes, excluding planned maintenance up to a maximum of 480 minutes over a twelve month period. |
SD |
= |
Total number of minutes of service downtime, excluding planned maintenance. |
5.2.4 The Service will tolerate hardware failure and must maintain data integrity and remain operational in the eventuality of the loss of one of the hardware server hardware nodes with minimal interruption in alignment with agreed availability targets.
5.2.4 Exclusions
The service commitment does not apply to any unavailability, suspension or termination of the DrDoctor Service, or any other DrDoctor Service performance issues:
- Caused by factors outside of our reasonable control, including any force majeure event, internet access, or problems beyond the demarcation point of the DrDoctor network;
- That result from any actions or inactions of the Customer or any third party;
- That result from the equipment, software or other technology of the Customer or any third party (other than third party equipment within our direct control);
- That result from failures of DrDoctor Services not attributable to unavailability; or
- During periods of planned maintenance
Specifically excluded from the fault resolution process are the following items:
- Any part of the network infrastructure at the Customer’s sites.
- Any Customer systems external to DrDoctor’s System.
- Any 3rd party system that is outside of DrDoctor’s control.
The above list is not exhaustive. DrDoctor will only be held responsible for incidents that are shown to be caused solely by the DrDoctor’s software or services running in an environment that meets with DrDoctor’s warranted environment specification (WES).
5.3 Service Credits
Service credits are applied as a percentage to the license fee for the Service affected and will be credited to future invoices. Service credits will lapse if there is no ongoing contract between the Customer and DrDoctor for the service.
5.3 Availability
The Service will be measured against the contractual requirement of 99.9% availability as stated in this section 5. If this is not attained there will be a service credit of 1% and further service credits will accrue as follows:
Availability |
Service Credit |
Approximate Duration (for information only) |
99.9% or above |
No service credits |
<8hr |
99.75 to 99.9% |
1% |
8hr to 1day |
99.5 to 99.75% |
2% |
1day to 2 days |
<99.5% |
5% |
>2 days |
5.3.2 Restoration time
DrDoctor will be expected to meet restoration times for the Service, as detailed in section 5.2. There will be a 0.5 % Service Credit applied for exceeding the Restoration Time for incident reported by the Customer at Severity levels 1 and 2 up to a maximum of 5% per contract year.
5.3.3 Multiple high severity incidents
Severity 1: more than 2 incidents reported by the Customer within a 12-month period a service credit of 1% will apply for each incident thereafter, up to a maximum of 5%.
Severity 2: more than 5 incidents reported by the Customer within a 12-month period a service credit of 1% will apply for each incident thereafter, up to a maximum of 5%.
5.4 Incident Escalation
Should a fault not be resolved in line with the targets, DrDoctor will invoke a standard Escalation Procedure under which DrDoctor’s CTO will be automatically notified.
Escalation Procedure
5.4.1 When a software fault is reported to DrDoctor that is agreed to be a High Severity Incident (Levels 1 or 2), the appropriate actions will be immediately initiated by both DrDoctor and Customer.
5.4.2 Upon examination of the incident, DrDoctor will make an assessment of the call to fix time. If this time is estimated to exceed the agreed resolution timetable then this escalation procedure will be immediately invoked.
5.4.3 The initial stage escalation will be to involve the Customers System Manager or nominated deputy to manage resources on the Customer side and a senior manager from DrDoctor to manage support resources.
5.4.4 If at any time during problem resolution it becomes apparent that call to fix time is likely to exceed 4 or more contracted hours beyond the Resolution timetable then the appropriate Director from DrDoctor will take over management of the problem.
5.4.5 Escalation of Severity 3, 4 & 5 Faults will be at the discretion of the System Manager and a senior DrDoctor representative will be expected to attend any problem management review meetings as required.
5.4.6 DrDoctor is required to provide details of the escalation procedure to be followed by the Customer in the event that a Service incident of Levels 1 or 2 are not resolved within the defined service levels prior to the achievement of full go-live. This will include a contact telephone number other than the helpdesk to be used for escalation purposes 24/7/365.
5.4.7 The Customer will provide a reciprocal arrangement for escalation in the event that DrDoctor does not receive the support that they require to resolve an incident.