Service Level Agreement (SLA) for the M Connect 2 System

Transcription

1 Document filename: M Connect 2 Service Level Agreement Directorate / Programme Systems and Project Service Delivery N/A Document Reference: DOC Project Manager N/A Status Approved Owner Norman Raphael Version 2.6 Author John Martin Version issue date 24 Mar 2015 Service Level Agreement (SLA) for the M Connect 2 System Copyright 2014 Health and Social Care Information Centre

2 Document Management Revision History Version Date Summary of Changes Mar 15 Annual Review and updates to bring in line with v2.1 SLA Guidelines Reviewers This document must be reviewed by the following people: Reviewer name Title / Responsibility Date Version Norman Raphael Head of Service Delivery 2.6 John Pinder Development Lead 2.6 M Connect 2 SRB Members Customer representatives 2.6 Approved by This document must be approved by the following people: Name Title Date Version Norman Raphael Head of Service Delivery 2.6 Samantha Harris M Connect 2 SRB Chair 2.6 Sean Walsh SSD Director 2.6 Glossary of Terms HSCIC SSD HSCIC Health and Social Care Information Centre Systems & Service Delivery Service Provider HSCIC SSD Service Management Service Level Agreement Organisational Level Agreement Customer User NHS HSCIC SSD SLA OLA The Systems and Service Delivery directorate of HSCIC The appropriate Service Delivery Manager and the Senior management of the service provider. An agreement between the Service Provider and Customer that documents services and agreed service levels provided to the Customer. An internal agreement covering the delivery of services which support the IT 2rganisation in their delivery of services. The organisation that negotiates this SLA and any associated funding. Any member of the customer s staff entitled to use the service. Page 2 of 24

3 Third Party Suppliers Complaint Incident Strategic Planning Group M Connect 2User Group SPG MC2 UG Suppliers external to the Service Provider used for the provision of some part of the service. May be internal NHS departments, or external organisations. A statement of unhappiness, expressing discontent about a situation. Any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service. The customer group which represents all Trusts in England, Wales and Northern Ireland, or their successors The group which represents the views of the users of the M Connect 2 service MC2 Service Review Board MC2 SRB The group that reviews and monitors the M Connect 2 service and links between the MC2 UG and SPUG. Document Control: The controlled copy of this document is maintained in the HSCIC corporate network, (according to the pathname recorded on the CMDB configuration Item) Any copies of this document held outside of that area, in whatever format (e.g. paper, attachment), are considered to have passed out of control and should be checked for currency and validity. Distribution Method: The document will be made available via the HSCIC Web site. Related Documents: These documents will provide additional information. Doc Reference Number Title DOC MConnect2 Service - System Level Security Policy (v1.0, 23/03/2015) Page 3 of 24

4 Contents 1 Parties to this Agreement and Authorisation Parties to this Agreement Authorisation 6 2 Introduction Summary of Agreement Validity and Review of this Agreement Service Support and Service Delivery Processes 7 3 Service Description and Specification Service Description and Scope Service Out of Scope Roles and Responsibilities Service Provider roles and responsibilities M Connect 2 Service Review Board roles and responsibilities M Connect 2 User Group Responsibilities User Responsibilities Third Party and Dependent Supplier Responsibilities Service Desk Hosting Performance Targets Reporting Data Protection 14 4 Service Continuity and Availability Hours of Service Availability Hours of Support Operation Service Continuity Backup and Recovery Security 15 5 Support Arrangements Incident Management Incident Response and Resolution times Incident Resolution Incident Escalation 16 Page 4 of 24

5 5.1.4 Major Incident 16 6 Changes & Releases Change Management IT Infrastructure Enhancements Application Change Requests Release Management 18 7 Capacity Planning and Management 18 8 Security Principles and administration 18 9 Service Cost and Charging Arrangements Additional Service Costs Charging and Funding Process Meetings Communications Complaints Complaint Circumstance Complaint Format Complaint Recipient Complaint Acknowledgement Complaint Resolution Complaint Escalation SLA Escalation and Arbitration Termination of the Service Changes to Agreement 23 Page 5 of 24

6 1 Parties to this Agreement and Authorisation 1.1 Parties to this Agreement This Service Level Agreement consists of the following parties: M Connect 2 Service Review Board Health & Social Care Information Centre, Systems & Service Delivery 1.2 Authorisation Agreed on behalf of the M Connect 2 SRB Sign: Date: Print Name: Samantha Harris, Chairman Service Review Board Agreed on behalf of Systems & Service Delivery Sign: Date: Print Name: Sean Walsh, NHS HSCIC, Systems and Service Delivery Page 6 of 24

7 2 Introduction 2.1 Summary of Agreement This document is the Service Level Agreement between the M Connect 2 Service Review Board and HSCIC SSD Service Management for the support and delivery of the M Connect 2 service (MC2). The Agreement defines the standards and levels of service to be provided and the responsibilities of both parties to enable the effective and efficient running of M Connect 2. This Agreement is to be managed and administered by both the M Connect 2 Service Review Board and HSCIC SSD Service Management. 2.2 Validity and Review of this Agreement This agreement is valid from 24/03/2015 to 31/03/2016. A structured review will take place annually to evaluate and prove the performance and appropriateness of this agreement. Interim meetings may also be as held to discuss the agreement. Any recommendations for changes (following these meetings) to the contract/sla/ola will be reviewed and agreed and passed to the Service providers Service Delivery Manager 2.3 Service Support and Service Delivery Processes The processes to be used for service management will be in conformance with the requirements of ISO/IEC and will as far as practicable, utilise ITIL best practice. 3 Service Description and Specification 3.1 Service Description and Scope The M-Connect 2 Service is offered on a Service Desk, Application Support & Maintenance basis and includes the provision of : Qualified technical resources to undertake application support and development A Help Desk for the receipt and processing of User Incidents Qualified technical and service management personnel to monitor, measure, report and administer the performance of the Service A Change Management process, including a standard for minor modifications and enhancement An efficient and up-to-date data dictionary which cross-references accessible NHAIS System screens and provides a business view of all applications. Page 7 of 24

8 M-Connect 2 offers quick and efficient access to data held on the NHAIS System or any health authority database, using standard desktop applications. It presents a logical view of the physical database giving greater scope and flexibility for information retrieval. M Connect 2 provides the following capabilities : Access to data from the four key areas of the NHAIS System - Population (Registration), Finance, Breast Screening, and Cervical Screening Ability to make ad hoc or regular queries Ability to tailor queries to create highly specific and unique reports Integration with office applications allows users to choose the desktop system they are most familiar with to extract and analyse information. This allows the use of the product to be customised to meet the business needs of individual organisations. Health and Social Care Information Centre undertakes to provide support services in relation to the M Connect 2 Service. Full details of functionality of this product can be found in the Product and Service Descriptions available at A full range of support services is provided for this product, from installation of new software through to preventative maintenance, ad hoc training and day to day telephone support. The terms of the agreement and full details of the service included together with all exclusions are described in this document. 3.2 Service Out of Scope Where the SSD Service Delivery team staff requires assistance from a third party to resolve a problem, the fix time targets may no longer be applicable. The Supplier is not responsible for contacting third-party suppliers in respect of hardware or software for which no contract has been purchased from the Supplier. Such advice and guidance may be available subject to additional charges being levied. The Supplier does not provide support for printer hardware, printer cables or printer sharing. Fix times on M Connect 2 software where unauthorised software has been installed against the advice of the Supplier will be out of scope of the agreement. Charges for licences for third party software elements (e.g., KB- SQL, etc) are out of scope. In addition, guaranteed installation times for application software where the length of time is proportional to the content and complexity of the installation are out of scope. Page 8 of 24

9 3.3 Roles and Responsibilities Service Provider roles and responsibilities Party to this Agreement; Assign a Service Delivery Manager for each customer to be responsible for day-today Service delivery; Undertake performance management of this Agreement, including operational reviews, Change Management, Service Review, and Escalation; To provide Help Desk staff to take calls during the service hours; To provide an answer-phone service to record calls outside normal working hours; To make Service Delivery staff available to support all product areas during the service hours; To allocate calls with an initial priority via discussion between the Help Desk and the Customer; Second-line support staff to verify the initial priority set at the Help Desk, via discussion between Service Delivery personnel and the customer, and offer an initial assessment of the time it will take to resolve; To deal with calls raised with the Help Desk in line with the priorities and response rates indicated below; To ensure that a call remains open until a satisfactory resolution has been reached in agreement with the customer; In the event that a customer is unavailable and two attempts have been made to contact the caller, Service Delivery staff will close the call. If this is the case a message will be left with someone at the customer's office and an sent to the caller; To notify all Key Users of any problem or issue that may significantly impact their business and, where applicable, update the software; To provide follow-up communication providing detail of resolution to the problem/issue identified above; To provide communication about call resolutions by telephone, fax or as appropriate. To provide staff for the resolution and fixing of software problems; Page 9 of 24

10 To provide details of any prerequisites for installation work at least 5 working days prior to the work being planned; To undertake the installation of new application software at a time mutually agreed with the customer; To provide representation at the national M Connect 2 User Group and associated meetings with the aim of maintaining close working relationships; To ensure that no member of staff makes unauthorised access to a computer or makes unauthorised changes to the programmes/data; To ensure that all staff are fully briefed in their responsibilities under the Data Protection Act 1998 as it relates to the processing of information relating to individual people covering the obtaining, use, storage or disclosure of such information; To ensure that all staff comply with the provisions of the Data Protection Act (1998), including related Caldicott Guardian principles, and the Computer Misuse Act (1990); To ensure that all staff operate under the good practice included in the HSCIC security policy in particular to its provisions relating to Computer Viruses; In the investigation of incidents, advice may be offered on the root cause of the problem should it lie outside of the application software, although the responsibility for fixing this remains with the User; and M Connect 2 Service Review Board roles and responsibilities The M Connect 2 Service Review Board will represent all Agencies / Area Teams in England, or their successors, and other NHS organisations making use of M Connect 2, including but not limited to Contractor Practices, Area Teams, NHS Trusts and Special Health Authorities. The M Connect 2 Service Review Board will act collectively in: determining protocols for the operation and use of the M Connect 2 service throughout the National Health Service (NHS); commissioning enhancements and modifications to the M Connect 2 service and software; monitoring the provision of the M Connect 2 service to its users in the NHS; facilitating the provision of the M Connect 2 service to the NHS. The detailed responsibilities of the M Connect 2 Service Review Board will be to: be Party to this Agreement; In partnership with the Supplier: Act as the Service Management Board for the service; Forecast Service delivery and associated capacity management with the Supplier; Page 10 of 24

11 Be responsible for the ownership and monitoring of the NHAIS M Connect 2 service, which includes this Service Level Agreement (SLA) Undertake the monitoring of the top-sliced funds agreed with the Technical Infrastructure Group (TIG) and allocated by the Strategic Planning Group for the provision of the M Connect 2 service; Agree the content of enhancements to the M Connect 2 service; Negotiate with the Strategic Planning Group funding of major developments, where appropriate, and monitor resultant projects; and Represent the views of users of the M Connect 2 service as a whole and to disseminate information on M Connect 2 activities to representative bodies throughout the NHS M Connect 2 User Group Responsibilities The M Connect 2 User Group is a national group representing all users of the M Connect 2 service. The M Connect 2 User Group will have the following roles and responsibilities: Through the M Connect 2 Service Review Board, request of the Strategic Planning Group funding for major developments where appropriate; Represent the views of users as a whole and to disseminate information on Group activities to users through the regional representatives; Evaluate requests for change to the M Connect 2 service; Escalate live or potential issues and problems with Service delivery and performance; Undertake performance management of this Agreement with the Supplier, including operational reviews, Change Management, Service Review, Escalation; User Responsibilities To raise all requests for support services with the Supplier Help Desk by telephone on or via ([email protected]); The following information will be requested by the Help Desk: Name of individual; Name of organisation; Organisation code; Telephone number of individual; address of individual; Subject heading (e.g., Open Exeter/Ophthalmic Payments); Details of Incident; and Incident category requested (if applicable). To be responsible for any loss or corruption of data or malfunction of the live system, caused by the use of local administrator access by any PCSS/agency staff. The rectification of such loss or corruption falls outside ALL normal support agreements provided by the Supplier; Page 11 of 24

12 To allocate one member of staff as the product specific M Connect 2 System Administrator through which all HSCIC contact can be addressed; To ensure that the HSCIC SSD Help Desk is notified of any changes to key personnel; To utilise the Change Request process administered by the Supplier to request any software changes - for details refer to: To provide remote access for Service Delivery personnel as and when required for the purposes of working on support calls. In the event that this cannot be/ is not provided, the response and resolution timescales cannot be assured; To ensure that new members of staff receive appropriate and relevant application or systems administration training prior to using any of HSCIC products or services, also to ensure they have been notified of the available user manuals and electronic help files; To ensure that all necessary licensing arrangements are in place for 3 rd party software; To ensure that an up to date back-up is available for the system and stored off site or at the very least in a separate location to the live system; To ensure that new releases of or patches to software are loaded within 3 months of their receipt. Support services on older versions of the application software may be reduced in the event that the new release has not been installed; Where applicable to the product, to ensure that there is a member of IT personnel available locally with designated DBA responsibilities; To ensure that a member of staff is part of any national mailing list made available by HSCIC and to take part in User Group activities if and when appropriate; To ensure that any intention to withdraw from the support contract is discussed with the Service Delivery Manager, and that a minimum of 6 months notice is provided of this intention Third Party and Dependent Supplier Responsibilities In the context of this Agreement, a Third Party Dependent Supplier is a supplier of IT Infrastructure services to support and deliver to the requirements of this Agreement, working to either the Supplier, or the customer. HSCIC Service Management is not directly responsible or accountable for the delivery of services via third parties e.g., Local IT departments or the training provider. Page 12 of 24

13 3.4 Service Desk The Service Desk service will be carried out from HSCIC SSD offices and will undertake call handling, incident escalation, and user communication activities. Users are to report all calls to the Service Desk. Confirmation that a call is logged in accordance with this agreement is the Service Desk reference number. Users should advise the Service Desk of any access constraints, such as restricted times of availability. Calls reported by users to other entities, such as local technical support are not supported by this agreement. Exeter Helpdesk: The service desk can be contacted by telephone / using the details below: Tel: or by [email protected] 3.5 Hosting The hosting arrangement for the service is dependent upon the hardware capability of the NHAIS service installed at individual customer sites.where the NHAIS service is hosted on Itanium architecture hardware it is possible for the M Connect 2 service to be co-hosted on the same hardware alongside the NHAIS service. Where the NHAIS service is hosted on any other architecture the M Connect 2 service is hosted at customer sites using hardware provided and maintained by the customer. Where the M Connect 2 service is implemented on the Itanium architecture, the hosting arrangement will be either from the customer datacentre or where a NHAIS hosting agreement exists with HSCIC from the Land Registry data centres based in Gloucester and Plymouth. The Data Centres are located at Plymouth and Gloucester land registry sites and are accredited to ISO 27001:2005 standard and have CPNI (Centre for Protection of National Infrastructure) and GSI (Government Secure Intranet) status and accreditation exceeding most NHS related security requirements. 3.6 Performance Targets This Agreement includes a number of performance targets for the provision, delivery and measurement of service performance. Performance targets are to be used positively, as a means of identifying both good service performance, and areas of weakness where management effort and pressure should be applied. The period of calculation of performance targets will be monthly. Page 13 of 24

14 The method of calculating performance targets will be determined by the process to be measured, e.g., incidents passing through the Help Desk service will be measured from statistics produced by the HP Open View Help Desk application. The Service review process within this Agreement will set out the process for managing and amending performance targets, appropriate to the levels of performance displayed under this Agreement. The following performance targets apply to Incident Management 3.7 Reporting 95% of reported support calls to be responded to within target 90% of reported support calls to be resolved within the target The following standard reports are provided. The data source is the Supplier s standard incident logging database. Weekly calls report detailing priority, resolution and closure cause. These are available electronically to sites that have requested them. National Response and resolution SLA reports are reported monthly Trend information by period - calls by site and calls by product reports are provided in the monthly Support Reports The reports are provided to customers by Service Delivery Managers at customer reviews upon request by the NHAIS Key User. In the event of any non-compliance or issues being identified, corrective actions will be agreed and communicated to the Customer. These include, but are not limited to, actions within the Service Improvement Plan. 3.8 Data Protection The transfer and use of data within M Connect 2 in the course of normal operational support of M Connect 2 and associated systems is covered by the Data Protection Agreement within this Service Level Agreement. Therefore any support activity which requires the Supplier to exchange service-related data to enable it to deliver the service does not require any further agreement. If the service components hosted at customer sites are set up using the Supplier provided specification the transfer mechanism of all data conforms to HSCIC and SSD security policies, and includes encryption of the data whilst in transit. The data is used only for the purpose for which it is requested. If a requirement arises to use the data for purposes additional to those specified in this Service Level Agreement, the Data Controller must provide written agreement for this additional use before it commences. Therefore, a Data Protection Agreement will be required for any non-standard use of Person Identifiable Data. Page 14 of 24

15 4 Service Continuity and Availability 4.1 Hours of Service Availability The service will generally be available for user access between 9am and 5pm, during weekdays unless alternative local arrangements with the hosting provider are in place. 4.2 Hours of Support Operation Hours of operational support will be 9am to 5pm, Monday to Friday, excluding English Public Holidays. 4.3 Service Continuity Backup and Recovery The Supplier will provide a secure backup to support the live IT Infrastructure in the event of a major Incident or Disaster. The backup Infrastructure will include all the necessary components to ensure that all processes and targets within the Agreement can be fulfilled on invocation. The Supplier will be responsible for determining when and how the backup and recovery infrastructure will be invoked Security The system is housed at customer sites. The customer will be responsible for ensuring that only legitimate user accounts are set up on the system, and monitoring of those accounts. All HSCIC SSD staff are aware of their responsibilities to fully comply with the provisions of the Data Protection Act (1998), including related Caldicott Guardian principles, and the Computer Misuse Act (1990). For further information and advice regarding legislation, please refer to the 'Important Information' link on the Open Exeter Authentication and Audit system, at 5 Support Arrangements 5.1 Incident Management Incident Response and Resolution times All incidents will be categorised and allocated a priority with agreement of the user at the time of logging the call. The incident category may be requested or challenged by Page 15 of 24

16 the user, in which case the incident will be categorised / prioritised according to the wishes of the user. If the support team subsequently believes that a different category or priority should be used, they will negotiate with the user accordingly. All calls are dealt with in order of priority allocation, 1 being the highest order of priority. Incident categorisations, and target response and resolution timescales are as detailed in the below table: Priority Maximum Response Target Maximum Resolution Target Examples 1 2 hours 3 working days Unavailability of the entire system, a key module or major function, causing significant business impact. 2 4 hour 6 working days Impairment of the entire system, a key module or major function, causing limited business impact. 3 2 days 10 working days Issues causing inconvenience, minor disruption or restricting performance. 4 5 days As agreed Non-urgent issues causing slight irritation but where workarounds are available; integrity checkers; cosmetic or general enquiries for information Incident Resolution The closure of an incident record will occur once the user has confirmed satisfactory resolution. If the user cannot be contacted the incident closure shall be dealt with inline with the roles and responsibilities detailed in this agreement Incident Escalation Incident Escalation is the process of communicating information on an Incident, or other live operational service issue for the purpose of raising its profile, and requesting senior management attention and/or intervention. If the customer is not happy with the progress of an incident they may: Contact the Help Desk requesting escalation of an incident. Contact the relevant Service Delivery Manager Major Incident When a Major Incident is recognised and is within scope of this agreement a Major Incident Manager shall be assigned who will liaise with support staff, third parties and senior management. The Service Delivery Manager or deputy will liaise with the Page 16 of 24

17 customer of the service and shall ensure that resources are focused and the situation is effectively managed in a way that minimises disruption to the user. 6 Changes & Releases 6.1 Change Management Change Management and Control is the process of identifying, assessing, communicating and implementing proactive and reactive change to the IT Infrastructure. It is a business-critical service management process that assures the integrity of the IT Infrastructure, and protects its operation, design and performance, for the benefit of users and this Agreement IT Infrastructure Enhancements Changes to the IT Infrastructure will be categorised and planned according to business need. Changes to the Infrastructure will be made outside of agreed service hours where possible; however urgent changes will require immediate action, hence will result in an interruption in service Application Change Requests Change requests for the application can be raised internally by the Supplier or externally by a User. The change request form is available via: On submission / receipt of the form, it is entered onto the change request system and an acknowledgement provided to the originator. The Service Delivery Manager / Product Developer will consider the request, and draw up an estimate as to how many man days effort the request will require. Priority of approved changes will be mutually agreed between the M Connect 2 User Group and the Systems & Operations Manager. The change request system will be updated with the outcome, and the originator informed of the status. The definition of an Emergency Request for Change (erfc) in Systems and Service Delivery is: A Change that must be implemented in order to avoid significant disruption to the system or service or to correct significant usability. Page 17 of 24

18 6.2 Release Management Changes to the IT infrastructure will be released on an on demand basis using either a single or multiple release unit model as agreed with the customer. The release of Changes to the IT Infrastructure shall be planned, tested, packaged, and implemented to a structured plan. All planned releases of hardware and software change will include the following attributes: Checking of live configuration by accessing the Configuration Management databases and definitive software library (as appropriate); Completion of Product Assurance processes, including provision of an environment on the operating system allowing end-to-end testing, where appropriate; Documenting of development activity progress and determination and recording of Issue Logs where appropriate; Creation of a test plan to include the environment required for testing, the process to verify releases are acceptable, and the success criteria; Determination of impact of the release on the live Service configuration, including affected Users ability to use the Service; Assessment of the potential resource requirements and financial commitments to undertake and complete the release; A release note detailing the changes will be produced and issued to users; and Updates to all documentation will be undertaken. An emergency release is normally implemented immediately as a response to a erfc. Such a release could bypass the standard SSD release assurance processes. E.g., Given the urgency the release, activities such as testing and notification may be limited. 7 Capacity Planning and Management Capacity Planning and Management is concerned with ensuring the right resources (both physical and human) are in the right place, at the right time, to deliver the Service in support of this Agreement. Capacity of the service is regularly monitored, in terms of supporting an expanding user base, changing business needs and supporting new functionality. 8 Security Principles and administration The system is housed at customers' premises and it is the responsibility of the customer to ensure it is held in a secure environment. Page 18 of 24

19 The system will be risk assessed on an annual basis and a risk management / security improvement plan will be put in place to address any unacceptable risks. A System Level Security Policy (SLSP) is in place for this service the SLSP helps to demonstrate understanding of information governance risks and commitment to address the security and confidentiality needs of a particular system. The customer will be responsible for ensuring that only legitimate user accounts are set up on the system, and monitoring of those accounts. All HSCIC SSD staff are aware of their responsibilities to fully comply with the provisions of the Data Protection Act (1998), including related Caldicott Guardian principles, and the Computer Misuse Act (1990). For further information and advice regarding legislation, please refer to the 'Important Information' link on the Open Exeter Authentication and Audit system, at 9 Service Cost and Charging Arrangements The cost elements for the service are identified and agreed between customers and their local Service Delivery Managers and documented in the Contract Schedules. Recurring charges for subsequent years will include an inflationary uplift. 44 Days per annum (11 days per quarter are included for Development work) Additional Service Costs Where additional service costs are anticipated or likely to be incurred over-and-above the obligations and cost schedule set out in this Agreement, the following process will apply, either reactively or proactively, according to operational circumstances: Customer Identification The nature of the service to be delivered is documented as a request in an appropriate format by the individual Customer and submitted to the Head of Service Delivery, including: Description of service required; Reason for service requirement; Timescales service required within; Benefits of service to be provided; Budgetary parameters and tolerance for service to be provided; Whether service change is permanent or temporary. The Head of Service Delivery will acknowledge the request and confirm the delivery of the service, together with appropriate actual or estimated costs, and timescales. Page 19 of 24

20 The Parties will decide the outcome of the request, and implement/reject as and where appropriate. Supplier Identification Note: This process is separate to that of implementing an emergency change, where requests for financial assistance form part of the Minor Modifications process. The nature of the service to be delivered is documented as a request in an appropriate format by the Head of Service Delivery and submitted to the M Connect 2 Service Review Board, including: IT Infrastructure configuration item affected; Reason/Justification for service requirement; Timescales service to be delivered within; Benefits of service to be provided; Estimated additional service cost; Recommendations on permanent or temporary service change; Timescales financial agreement required within. The M Connect 2 Service Review Board will acknowledge the request, and confirm satisfaction or otherwise with its outline, together with providing, or otherwise, the necessary financial authorisation. The Parties will decide the timetable for the request to be implemented/rejected as and where appropriate. If the delivery of additional services affects or causes to affect the achievement of Performance Target(s) within this Agreement, prior identification or exclusion of the Target(s) will be discussed and agreed by the Parties Charging and Funding Process Funds from the Strategic Planning Group budget are recorded and monitored on the finance section of their monthly meetings. All charges identified are exclusive of Value Added Tax which will be charged at the appropriate rate. All charges quotes are exclusive of VAT. All charges are subject to inflation uplift on an annual basis. 10 Meetings The Service Review Meeting will be held between the Supplier and the M Connect 2 Service Review Board Chair annually to discuss: - The Service Scope; - The Service Level Agreement; Page 20 of 24

21 - Business needs. The Service Review Board will be held at agreed intervals to discuss : - Performance; - Achievements; - Issues; - Action Plan. Outcomes of these meetings are documented in the MConnect2 Service Review Board minutes. The Service Delivery Manager will attend the M Connect 2 User Group each Quarter to discuss: - Performance; - Achievements; - Issues; - Training requirements; - Action Plan. Outcomes of these meetings are documented in the M Connect 2 User Group minutes. 11 Communications Communication channels used to contact the customer (for example, to agree downtime, accept releases) will be through a combination of (as appropriate): Biannual Service Review Board Meetings Quarterly User Group Meetings to the Service Review Board Chair and / or members M Connect 2 NHS Networks Message Forum 12 Complaints Complaint Circumstance Where a customer or user is not satisfied with the service or support provided by SSD through the usual channels of the SSD Help Desk or escalation to the responsible Service Delivery Manager, he/she has the option of raising a formal complaint. Page 21 of 24

22 Complaint Format Complaints should be written and submitted as an or letter, outlining the situation and the basis of the complaint Complaint Recipient By mail to the NHS HSCIC SSD Head of Service Delivery Or by post to: Norman Raphael Head of Service Delivery Systems and Service Delivery Hexagon House Pynes Hill Exeter Devon EX2 5SE Complaint Acknowledgement An acknowledgement will be returned within 2 working days of receipt of the complaint using the same media as the original complaint (i.e., by or post) Complaint Resolution SSD will seek to resolve the complaint to the satisfaction of the complainant within 20 working days of the receipt of the complaint Complaint Escalation If the complainant is unhappy with the manner in which the complaint has been dealt with or resolution of the complaint they may escalate the issue to the HSCIC SSD Page 22 of 24

23 Director (Sean Walsh) at the above address or by to: 13 SLA Escalation and Arbitration The performance of this Agreement will ultimately be administered and governed by the authorised signatories. If it is necessary to escalate any aspect of either party s obligations or performance under this Agreement, an escalation route (as detailed below) is available as means of arbitration, and to achieve a mutually acceptable solution or decision. The escalation route should only be used as a means to highlight or raise the profile of a particular service delivery issue, should all other opportunities fail. At the point where it is agreed between the signatories that decision or solution to a service issue cannot be resolved within normal means, details of the issue should be escalated to their immediate line managers, dependent upon the nature and context of the issue. Liaison should be undertaken with the escalation point to discuss the circumstances surrounding the issue, and aim to achieve a satisfactory conclusion, including consensus on decision, and action plans. Where it is appropriate to escalate an issue external to the supplier, one or both of the signatories will communicate directly, as appropriate. It will be the responsibility of the signatory to achieve and reach a satisfactory conclusion to the issue, and communicate, as appropriate to personnel involved in the delivery of this service. 14 Termination of the Service If either party wishes to terminate (either early or planned) or transfer the service a minimum of 6 months notice shall be notified to the respective party. If either party wishes to discuss an early end of the service or transfer of the service, they will be required to raise this formally with the NHS HSCIC Service Delivery Manager for discussion at the service review or via an ad-hoc meeting if required earlier. 15 Changes to Agreement Day-to-day or operational changes to this Agreement can be proposed at any time, in writing, by either Party with a minimum of 1 month s notice. Major changes to this Agreement will be proposed and discussed at the M Connect 2 Service Review Board, with a decision made at the time on its approval or rejection. If further analysis is required in order to make a decision, an action will be identified and taken forward for resolution at the next M Connect 2 Service Review Board meeting. The content of proposed changes to this Agreement will be as follows: Submitter details, etc; General description of the change, and the area/section of the Agreement affected; Brief benefits of the change; Page 23 of 24

24 Actions required to effect the change, together with roles and responsibilities; Impact of change on any historic data and information analyses, e.g., change of performance targets, and existing processes and procedures; and The estimated (if possible) financial impact of the change, e.g. on Service cost, or effort to administer the Agreement. For each change proposed it will be necessary to understand if a baseline in service delivery will be necessary, in order to track and measure corresponding change in the performance of the Parties. This may take the form of selected data and information, but each proposal must be agreed by the Parties prior to decisions being made. The process for identifying and agreeing additional Service costs is specified within section (Additional Service Costs). Page 24 of 24