1.1	Definitions and interpretations;
•	Concurrent User means the total number of users that can access the service at any given time
•	Named User means an individual person that is provided with access to the service at any given time
•	Endpoint Device means the device used to access the service

1.2	Service Description
Clinical Workspace (“Workspace”) is a secure desktop service allowing remote access to a virtual desktop powered by a cloud environment. Each subscribed user is provided with a Windows virtual desktop that can be accessed from any internet connected location to gain secure access to clinical systems and data and the data stored and transmitted by a subscribed user is encrypted. Management of the desktop environment, including application changes, security patches and Windows updates are included as part of the service offering. 
1.3	The minimum subscription term is 12 months.  All subscriptions will automatically rollover to a new 12-month period. Subscriptions are charged upfront for the full duration of the term unless agreed otherwise in a Statement of Work.
1.4	The minimum number of users and minimum increments will be as set out In a Statement of Work.
1.5	The Client acknowledges and agrees that increasing the quantity of the users for a specific period is subject to agreed charges based on subscription quantity and length of contract and the exporting of data may be subject to specific termination services and additional charges.
1.6	Any changes to the required specification of virtual desktops due to application changes or any other factors may be subject to additional charges
1.7	The client is responsible for the management and maintenance of all devices and peripherals unless agreed otherwise In the Statement of Work 
1.8	Block is unable to guarantee the correct operation of endpoint devices, medical devices, patient callboards, other devices or peripherals that are not approved for use by Block when using the service
1.9	Block is unable to guarantee the performance of compatibility of printers, scanners of other peripheral devices that are not listed within the approved catalogue
1.10	Software licensing is provided by the client unless stated otherwise. Block do not hold any responsibility for the licensing of software packages and applications

2	MANAGED SERVICES GENERAL - ASSUMPTIONS
2.1	For the process of Service Management, the following assumptions apply:
2.1.1	Communication and liaison with the client’s end users will be undertaken by the client’s ICT team.
2.1.2	Block will use its own service management processes, which it will integrate with the client’s processes where appropriate.
2.1.3	For clients who have service reporting, the provision of additional reporting beyond that agreed at service transition will be subject to an assessment of the effort required to produce the additional report(s) and may incur an additional set-up and ongoing service charge.
2.2	For the process of Supplier Management, the following assumptions apply:
2.2.1	Any suppliers and vendors contracting directly with the client, which Block have not been requested to manage, will liaise directly with the client. Block will provide no support or engagement with suppliers and vendors contracting directly with the client.
2.3	For the process of Risk Management, the following assumptions apply:
2.3.1	The client operates a risk management framework and has a risk management policy.
2.4	For the process of managing capacity on the systems, networks or Infrastructure:
2.4.1	Block reserves the right to refuse to prioritise problems and incidents as P1 or P2 for the affected infrastructure, where the incident is the direct result of the client’s refusal to increase the affected infrastructure’s capacity.
2.4.2	Block expects that its capacity management process can interface with the client’s Change Advisory Board (CAB). This facilitates the assessment of the impact of changes to the existing infrastructure and hence capacity, reducing the risk of capacity problems being caused by the change.
2.5	For the process of managing any change to Infrastructure, systems or networks directly Impacting the Workspace Service, the following assumptions apply:
2.5.1	Changes to the in-scope infrastructure and systems will be undertaken by Block – no other parties will be involved unless by prior agreement.
2.5.2	Any additions to the proposed in-scope infrastructure will be procured and undertaken by Block.
2.5.3	The deployment of changes required to amend or improve the functionality of existing services, or to commission or decommission services  may be charged at agreed professional services rates.
2.6	For the process of applying patches, the following assumptions apply:
2.6.1	Block will always endeavour to ensure patch deployments are non-service affecting, by planning changes in advance and, where feasible, deploying patches within the agreed service maintenance window(s). However, in some instances (e.g. where a patch is non-service impacting) Block reserves the right to deploy patches outside of maintenance window(s).
2.7	For the process of Service Request Management and Fulfilment, the following assumptions apply:
2.7.1	All service requests requiring implementation outside of the hours set out in the Block SFIA Rate card will require a professional services quote from the Block Account Management team
2.8	For the process of Underpinning Vendor/Supplier Support, the following assumptions apply:
2.8.1	Changes to the in-scope infrastructure and systems will be undertaken by Block – no other parties will be involved unless by prior agreement.
2.8.2	Any additions to the proposed in-scope infrastructure or services will be procured and undertaken by Block.
2.8.3	For new clients, the client will provide an accurate inventory of all hardware and software it wishes Block to manage.
2.8.4	Block will use reasonable endeavours to procure suitable hardware and/or software underpinning maintenance contracts for infrastructure elements which are past their end of support date. However, there may be occasions when this is not possible. Block will aim to inform the client of the nature and level of risk posed by continuing to use these elements. Any element in the in-scope infrastructure which has reached its end of support date, will be maintained on a reasonable endeavours basis; this assumes the client has appropriate spares available if necessary. If support and maintenance cannot be transitioned to Block from the incumbent supplier, it is assumed the client will continue to extend the supplier contract until the infrastructure elements have been decommissioned.
2.8.5	When Block take over the service management of a client’s existing infrastructure, it reserves the right to perform a detailed assessment of the hardware and software within the in-scope infrastructure; this is usually performed as part of service transition. Block will produce an assessment report outlining any foreseeable issues and risks (categorised in to as high, medium or low category), with their likely impact, and any mitigating actions. Block reserves the right to present amended charges should there be a material difference between the infrastructure inventory supplied by the client and the results of Block’s infrastructure assessment.
2.8.6	If there is an incumbent supplier of IT services whom Block are replacing, it is assumed that the client and the supplier will assist Block in transitioning services into Block’s service management framework.

3	MANAGED SERVICES GENERAL – CLIENT RESPONSIBILITIES
3.1	For the process of Service Management, the client is expected to:
3.1.1	Provide appropriate user and service management representatives for the regular service reviews, (if the client has requested service reviews).
3.2	For the process of Supplier Management, the client is expected to:
3.2.1	Provide Block with all relevant contract details prior to contract signature for any suppliers currently contracted directly with the client which Block will become responsible for.
3.2.2	Provide Block with technical, service and contact details (including, but limited to, postal addresses, e-mail addresses, telephone numbers, hours of operation, etc.) during service transition for incumbent suppliers or any suppliers currently contracted directly with the client which Block will become responsible for.
3.2.3	Provide access to client premises where required by Block’s 3rd party suppliers.
3.3	For the process of Risk Management, the client is expected to:
3.3.1	Inform Block of their ‘risk appetite/attitude’ i.e. its general approach to risk. A client’s attitude towards risk can influence whether risks are taken, tolerated, retained, shared, reduced or avoided.
3.3.2	Maintain a risk management framework (a set of components that support and sustain risk management throughout the client).
3.3.3	Maintain a risk management policy (a policy statement of general commitment, direction, or intention).
3.3.4	Assist Block with aligning and integrating the Block process of Risk Management with the client’s risk management policy and framework.
3.4	For the process of Capacity Management, the client is expected to:
3.4.1	approve and act upon Block’s recommendations for additional capacity to be added to the in-scope services, in a timely manner; and
3.4.2	collate and provide Block with any business event or volume information which they can reasonably predict will affect the in-scope infrastructure and/or service.
3.5	For the process of Software Asset Management, the client is expected to:
3.5.1	provide Block with details (e.g. software description, part numbers, version, licence details, location, etc.) of any software assets the client, or any other third party contracted by the client, has purchased and deployed without Block’s assistance.
3.6	For the process of Hardware Asset Management, the client is expected to:
3.6.1	provide sufficient virtual computing resources for the deployment of information collectors on their network; and
3.6.2	provide Block with details (e.g. serial number, location, device description, part number, etc.) of any infrastructure assets the client, or any other third party contracted by the client, has purchased and deployed without Block’s assistance 
3.7	For the process of Change Management, the client is expected to:
3.7.1	manage and co-ordinate those vendors who are not contracted to Block, when required for the implementation of changes;
3.7.2	be responsible for ensuring the client’s change management authorisation processes are followed; and
3.7.3	ensure Block are part of the change management process for
3.8	For the process of Patch Management, the client is expected to:
3.8.1	work collaboratively with Block to develop and maintain agreed patch management policies;
3.8.2	develop manageable and effective technical security standards and policies; and
3.8.3	review and approve the identified patches in a timely manner.
3.9	For the process of Incident Management, the client is expected to:
3.9.1	triage all incidents to ensure only those relating to the in-scope infrastructure are logged with Block;
3.9.2	provide on-call contacts to enable communications – including contact for outside core service hours – in the event of incidents of priority P1 and P2 
3.9.3	collate and provide Block with any business event or volume information which may affect incident volumes;
3.9.4	provide the service desk capability to receive and validate all end-user calls;
3.9.5	manage and co-ordinate any contractors, 3rd party suppliers and vendors not contracted to Block, when required for the resolution of incidents and problems; and
3.9.6	communicate and liaise with the client’s end-users.
3.10	For the process of Service Request Management and Fulfilment, the client is expected to:
3.10.1	triage all service requests to ensure only those relating to the in-scope infrastructure are logged with Block;
3.10.2	provide the service desk capability to receive and validate all end-user service requests, before passing on to Block; and
3.10.3	when necessary for the completion of a logical service request, provide intelligent hands and eyes to aid efficient resolution of issues which require physical access to in-scope infrastructure.
3.11	For the process of Event Management (Monitoring and Alerting), the client is expected to:
3.11.1	provide on-call contacts to enable communications – including contact for outside core service hours – in the event of alerts causing incidents of priority P1 and P2; and
3.11.2	provide on-call contacts to manage and resolve alerts for out-of-scope infrastructure.
3.12	For the process of Backup and Restore, the client is expected to:
3.12.1	be responsible for the backup and restoration of user data, unless explicitly within the scope of the services Block provides to the client;
3.12.2	ensure its backup and data retention policy, and backup and restore requirements are communicated to Block;
3.12.3	ensure any changes to its backup and data retention policy, and backup and restore requirements are communicated to Block; and
3.12.4	ensure its business continuity and disaster recovery plans, and any changes to those plans, are communicated to Block.
3.13	For the process of Enhanced Technical Services, the client is expected to:
3.13.1	provide intelligent hands and eyes to aid efficient resolution of issues which require physical access to in-scope infrastructure, when necessary for the diagnosis of a fault.
3.13.2	deploy failed hardware for incidents with a priority of P3 or P4, unless previously agreed with Block that one of its engineers will deploy the failed hardware for an additional agreed charge; and
3.13.3	deploy hardware for service requests, unless previously agreed with Block that one of its engineers will deploy the failed hardware for an additional agreed charge.
3.14	For the process of Underpinning Vendor/Supplier Support, the client is expected to:
3.14.1	purchase an appropriate level of underpinning support for hardware via Block. For example, a next business day service level should not be selected for critical network infrastructure devices;
3.14.2	provide Block with sufficient information for each client site to facilitate access by Block’s engineers to Block equipment installed at the site to enable them to replace the affected part(s), including, but not limited to:
•	full postal address;
•	site opening hours;
•	process for gaining access to the site during business hours and outside of business hours;
•	any security or access issues for the site;
•	site specific information. e.g. parking, how to gain access to the site during business hours and outside of business hours;
•	telephone and e-mail address for named client contact(s) who can be contacted during business hours and outside of business hours;
•	location in the building of Block equipment, e.g. room(s); and floor(s)
•	any details about gaining access to the room(s); and floor(s) where Block equipment is located; and
•	any other relevant site-specific information.

4	MANAGED SERVICES GENERAL – EXCLUSIONS
4.1	The service level targets will not be applicable where an incident is caused directly or indirectly by:
4.1.1	a client’s action or inaction;
4.1.2	the quality of a client’s facilities, or a failure in one or more elements of a client’s facilities;
4.1.3	hardware or software not supported by us;
4.1.4	action or inaction of a client’s 3rd party supplier or contractor;
4.1.5	a change implemented by the client, a 3rd party supplier or contractor, and the time taken to reverse the change is longer than the relevant service level target;
4.1.6	incidents which are agreed as requiring a resolution action which will take longer than relevant service level target (e.g. software patch deployment); or
4.1.7	a client who has selected an inappropriate level of underpinning support for hardware. For example, a next business day service level for critical network infrastructure.
4.1.8	The client needs to confirm the incident’s resolution;
4.1.9	The client's actions have caused the incident and the client must act to resolve;
4.1.10	The incident is caused due to non-supported infrastructure and the client must resolve;
4.1.11	The incident is caused by failure of the client’s facilities e.g. power failure;
4.1.12	The client has not purchased underpinning support for hardware replacement, or has purchased underpinning support for hardware replacement with an unsuitable service level;
4.2	For the process of Incident Management, we will place an incident in a ‘stop the clock’ state whilst:
4.2.1	We are unable to contact the individual raising the incident to request further information;
4.2.2	The support quoted covers the agreed asset list and infrastructure only. Any elements outside of that are considered out of scope.
4.2.3	Communication and liaison with end-users will be undertaken by the Client’s IT Team.
4.2.4	All Block services will be provided remotely except in a P1 or P2 situation where on-site presence is required.
4.2.5	The client will provide the 1st and 2nd line service desk capability and will take all end user calls.
4.2.6	The client will be responsible for providing 1st line and 2nd line investigation, triage and remediation activities before escalating to Block and the Block Operations Centre (BOC).
4.2.7	The client will provide on-call contacts to enable communications – including contact for outside core service hours – in the event of incidents of severity P1 and P2.
4.2.8	The client will collate and provide Block with any business event or volume information which may affect incident volumes.
4.2.9	A client change freeze is active, preventing resolution of the incident;
4.2.10	The incident resolution requires a change that needs to be written, technically approved and submitted to our Change Advisory Board (CAB) and/or the client’s Change Advisory Board (CAB);
4.2.11	The incident resolution is awaiting on a change to be approved by tour Change Advisory Board;
4.2.12	The incident resolution is awaiting on a change to be approved by the client’s Change Advisory Board (CAB);
4.2.13	The incident resolution is awaiting procurement of an item; or
4.2.14	We are awaiting action (information, fix or workaround) from a third party or vendor that sits outside of our direct management control