Exeter, Mid and East Devon R1 Deployment Project Initiation Document (PID) Summary Version

Transcription

1 Programme NCRS DOCUMENT RECORD ID KEY Sub-Prog / Project Release 1 Prog. Director Owner Version 0.09 Author Version Date Status Draft Exeter, Mid and East Devon R1 Deployment Project Initiation Document (PID) Summary Version Crown Copyright 2006 Page 1 of 29

2 Glossary of Terms Term Accident & Emergency Admissions, discharges & transfers (inpatient movement events) Business Management Office Commissioning Data Sets Care Records Service Data Collection Worksheet Devon Partnership Trust Deployment Verification Criteria Deployment Volumetric Targets Emergency Department (also known as A&E) Fujitsu Services General Practitioner Integrated Service Improvement Programme Local Area Network Local Health Community (the NHS organizations comprising the Exeter, Mid and East Devon deployment group) Local Service Provider Milestone Achievement Certificate Minor Injury Units Master Patient Index (also Patient Master Index (PMI)) National Health Service Connecting for Health Picture Archiving and Communication System Patient Administration System Acronym A & E ADT BMO CDS CRS DCW DPT DVC DVT ED FJS GP ISIP LAN LHC LSP MAC MIU MPI NHS CfH PACS PAS Project Initiation Document PID Post Implementation Review PIR Project Management Office PMO Projects In Controlled Environments v2 PRINCE 2 Registration Authority RA Role Based Access Control RBAC Radiology Information Systems RIS Release 1 of the Cerner Millennium product set R1 Referral to Treatment RTT Strategic Health Authority SHA Specific, Measurable, Attainable, Relevant, Timebound SMART Senior Responsible Owner SRO Train the Trainer TTT Wide Area Network WAN Crown Copyright 2006 Page 2 of 29

3 Contents Exeter, Mid and East Devon R1 Deployment...1 Project Initiation Document (PID) Executive Summary Purpose of the Document Background Current Position Operational Need Why is the project required? Project Definition Strategic Drivers Project Objectives Benefits Scope & Exclusions Key Stakeholders Key Deliverables/Desired Outcomes Approach Deployment Testing and Verification Approach Assumptions Constraints Organisational interfaces Project interfaces Data Migration Strategy Training Strategy Technical interfaces Strategic Direction of Local Service Management Strategic Outline Business Case Project Organisation Structure and Governance Project Board Senior Responsible Owner...Error! Bookmark not defined Senior User...Error! Bookmark not defined Senior Supplier...Error! Bookmark not defined. 6.2 Project Manager...Error! Bookmark not defined. 6.3 Team Managers and Team Roles Project Assurance Project Implementation Plan Communication Plan Project Quality Plan Quality Control...Error! Bookmark not defined. 9.2 Lessons Learnt...Error! Bookmark not defined. 10 Project Controls Change Control Project Tolerances Configuration Management Risk Management Issues Management Progress Monitoring & Reporting Project Filing Structure...29 Appendix 1 Project Implementation Plan...Error! Bookmark not defined. Appendix 2 Quality Plan...Error! Bookmark not defined. Appendix 3 Risk Log...Error! Bookmark not defined. Appendix 4 Issues Log...Error! Bookmark not defined. Appendix 5 Communications Plan...Error! Bookmark not defined. Appendix 6 Financial Implications Paper...Error! Bookmark not defined. Appendix 7 Assumptions Register...Error! Bookmark not defined. Appendix 8 Benefits Plan...Error! Bookmark not defined. Appendix 9 R1 Functionality Scope...Error! Bookmark not defined. Appendix 10 Project Team Member Roles and Responsibilities...Error! Bookmark not defined. Appendix 11 - Stakeholder Management Plan...Error! Bookmark not defined. Appendix 12 - Lessons Learnt Log...Error! Bookmark not defined. Crown Copyright 2006 Page 3 of 29

4 Appendix 13 Release 1 DVTs...Error! Bookmark not defined. Appendix 14 Information Reporting Requirements...Error! Bookmark not defined. Appendix 15 Training Strategy...Error! Bookmark not defined. Crown Copyright 2006 Page 4 of 29

5 Programme NCRS DOCUMENT RECORD ID KEY Sub-Prog / Project Release 1 Prog. Director Owner Version 0.09 Author Version Date Status Draft 1 Executive Summary The purpose of this Project Initiation Document (PID) is to ensure that the project to implement the NHS Care Records Service (NCRS) Release 1 (R1) within Exeter, East and Mid Devon local health community (the LHC) has a sound basis for proceeding. It will also act as a base document against which progress, change management, the delivery of agreed outcomes and ongoing viability can be assessed. The deployment of the NCRS presents an opportunity to align processes across all organisations in the LHC and to examine current processes and procedures to ensure that they are still appropriate in the patient-led NHS. The NCRS is part of a multi-year service improvement programme, enabled by IT, supporting fundamental changes in working practices across clinical, managerial and administrative environments. The project is benefits driven, and supports outcomes which will improve the service delivery and the patient s experience of it. The benefits will increase over time as successive software releases, including electronic orders and results, clinical documentation, e-prescribing, are implemented, leading to a full electronic healthcare record, resulting in a paper-light environment. The organisations involved in the deployment of NCRS in the LHC are: The Royal Devon and Exeter Foundation NHS Trust East Devon Primary Care Trust Exeter Primary Care Trust Mid Devon Primary Care Trust Devon Partnership NHS Trust (DPT) locations and staff within the geography of Exeter, Mid and East Devon The PCTs listed above, together with Teignbridge and South Hams have formed a new Devon PCT as from 1st October For the purposes of this deployment definition, the scope is those organisations identified in CCN60 unless changed. The LHC currently has a functionally-rich suite of existing healthcare systems, of varied ages. In most cases, these systems are integrated around a common patient index and, in some cases, common access to inpatient details. To ensure the integrity of patient records it is recommended that all available modules of the NCRS are deployed, on the assumption that they are considered fit-for-purpose by the organisations concerned. However, it should be remembered that R1 of the NCRS is the first step in a journey which will bring more depth of clinical functionality in the coming years. It is therefore intended that this project will manage the implementation of the core Cerner Millennium functionality together with available additional modules such as Theatres, A&E and Maternity to: Replace the current Patient Administration System (PAS) and associated systems, as applicable; and Present a consolidated, multi-organisational patient record. NCRS R1 will therefore provide the foundation for the implementation of further functionality that will expand the capabilities for effective data management within the NHS. On completion of all the phases of the project there will be a secure, comprehensive, accurate, single and up-to-date patient- Crown Copyright 2006 Page 5 of 29

6 centred healthcare record, accessible quickly and reliably at any time by both appropriate staff and patients themselves wherever they may be located. Together with related projects, this implementation will eventually enable electronic requesting of Pathology and Radiology tests and improved efficiency in patient correspondence. Furthermore, the implementation of NCRS R1 provides a single platform which will be the foundation for future releases which will deliver rich clinical functionality, and support further service modernisation. NCRS R1 is due to go live throughout the LHC in September Given the size and complexity of the systems to be deployed, it is recognized that this represents a major challenge to the LHC, particularly at a time of structural reorganisation at SHA and PCT levels, and when the NHS is under pressure to meet financial and other targets, such as achieving financial stability and Foundation Trust status. Also, it is a relatively short period of time to ensure that the system is technically and operationally acceptable, that all users have been trained, and that all processes have been aligned to the use of the new system. However, investment now will deliver long term benefits which will improve the effectiveness and efficiency of the service, and provide essential support to on-going modernisation. Perhaps the most important aspect of this programme is the opportunity it presents for change in the organisations. This means that there will be a requirement for the organisations to engage fully with the programme, as the shape of the system and any additional functionality (and therefore its usefulness to the organisations) depends entirely on the input received from the expert users of the current systems. Furthermore, the realisation of the potential benefits of the new system depends on the staff s ability to use it accurately. Therefore training, and the release of staff for that training, is critical to the success of the deployment. Every effort will be made by the project team and Fujitsu to ensure that the implementation of the NCRS is a success; this will be aided greatly by the organisations concerned fully committing to the deployment. The Net Revenue Costs of NCRS R1 for the LHC are 609,500 in 2006/07 and 3,134,167 in 2007/08 and the Capital Costs are 60,000 in 2006/07 and 1,463,000 in 2007/08. Although the project delivers long-term benefits to the Health Community, it has significant revenue implications in 2007/08 and subsequent years which the LHC has agreed to fund through increased IM&T spending. Crown Copyright 2006 Page 6 of 29

7 2 Purpose of the Document This Project Initiation Document ( PID ) is produced in accordance with the PRINCE 2 methodology for project management used by the National Health Services (NHS) and Fujitsu Services Limited ( Fujitsu ), to document the baseline scope and plan for local deployment at the LHC of Services Bundles purchased for the NHS by the Secretary of State for Health ( the Authority ) under its Project Agreement with Fujitsu dated 26th January 2004 ( Project Agreement ). The Project Implementation Plan (PIP) in Appendix 1 to this document will constitute the Implementation Plan for the local R1 deployment to the LHC under the Project Agreement for the specified Services Bundles to Sites at Locations specified in the baseline survey, unless and until superseded by any revised Project Implementation Plan agreed with the Authority under the Project Agreement. This document is not intended to vary the Project Agreement between the Authority and the Contractor. In the event of any conflict between the Project Agreement and this document, the Project Agreement will prevail. Neither this document nor anything done in consequence of it will constitute a waiver of the rights of either party under the Project Agreement. The purpose of this document is to define the scope of the project, underlying assumptions, financial implications, roles and responsibilities, approach, and the mechanisms that will be used to control the project. A fuller business case may also be presented to local boards to supplement the financial implications section of this document. Sign-off of that business case is planned to synchronise with sign-off of this PID. Crown Copyright 2006 Page 7 of 29

8 3 Background 3.1 Current Position The NHS established the National Programme for IT (NPfIT) in October One of the key objectives of NPfIT, which is now known as Connecting for Health (CfH), is the development and delivery of a nationally-consistent NHS Care Record Service (NCRS). This is to be delivered via a series of national contracts. Five geographical clusters covering the whole of England were identified and a national contract for local service provision has been award to each of these clusters. The main local NHS relationship will be with the Local Service Provider (LSP). The ten-year contract for LSP provision to the Southern Cluster was signed between the NHS and the Fujitsu Alliance (now known as Fujitsu) in January This involves the deployment of core applications and information services from Fujitsu data centres. The Southern Cluster consists of NHS organisations within the former Strategic Health Authority areas of South West Peninsula, Dorset and Somerset, Avon Gloucestershire and Wiltshire, Thames Valley, Kent and Medway, Surrey and Sussex and Hampshire & Isle of Wight. These organisations have now been merged into the three Southern SHAs of South West, South Central, and South East Coast. The NCRS plan is to provide a live, interactive aggregated patient record service accessible by health professionals 24-hours a day, seven days a week, whether they work in hospital, primary care or community services. It is the summary record from NCRS on the National Spine (patient record data repository) that will be accessible by authorised NHS staff across England. The intention is that, in the future, all those involved in the care of a patient will have secure access to up-to-date, accurate information for diagnosis, treatment and care. Patients will also have easier access to their own health and care information. The detailed NCRS record within R1 will be accessible within the deployment organisations (excluding GPs at this stage). R1 incorporates the base layer of functionality (R0) and is the first of 3 planned releases of the Cerner Millennium application, each of which will take months to implement. Each subsequent release will add additional layers of clinical functionality, so that when it is fully implemented, the NCRS will function across care settings and organisations and will support planned, emergency and unscheduled care. The implementation of Cerner Millennium Care Record System, R1 lays the foundation towards the achievement of this vision by enabling information to be shared across NHS organisations. R1 core functionality provides the following bundles: Spine Compliance R1 PAS R1 (Patient Administration System including Mental Health functions) Clinicals R1 (including Order Communications) Maternity R0 ED R0 Theatres R1 Care Pathways R1 Information for Analysis R1 Crown Copyright 2006 Page 8 of 29

9 3.2 Operational Need The operational need is driven by shortcomings in the IM&T systems in use, e.g. as lack of wider integration, local systems (and therefore data) fragmentation, reduction of unnecessary duplication of solutions, and the processes that surround them, combined with the requirement to supply high quality services as efficiently as possible within the new frameworks and initiatives. There is a growing requirement for integration of data amongst systems. For example, the LHC, as stated, has a good spread of systems, but no single view of locally-available patient information, and no point of integration for order communications. It also makes sense to have the systems as closely integrated as possible, removing the need to administer several systems which contain the same or very similar information. By implementing R1 of NCRS, the organisations can realise the potential to have demographic data captured once, and in one place. The deployment of R1 will also bring functionality to many areas of the organisation where currently there is none, e.g. order communications and nursing care planning. Current legacy systems are not all being developed or supported adequately to rely on for the future, and licence and maintenance costs for some of these will be saved through use of R1 (although it is acknowledged that the current PAS costs are low at 1000 annual licence, we will still have to keep these components running to support the interface strategy). 3.3 Why is the project required? The efficient provision of services within the LHC is dependent on clinical and administrative staff having easy access to the necessary information. Inherent in this is the ability for multi-disciplinary teams undertaking different functions to access common information ideally through a common software solution leading to a shared approach to providing services, and improving information available to patients about their treatment options, including the information required to facilitate patient choice. Implementation of R1 of the NCRS would allow the use of some of the existing systems to be discontinued whilst bringing all patient administration data into a centralised system. Decommissioning many of the existing systems would negate risks that may be posed by their age, supportability and functionality. In association with the improved clinical functionality provided by the Cerner Millennium solution, centralising the data would allow a far clearer picture to be obtained of the treatment record provided to an individual patient across the LHC and wider areas. In establishing a new basis for the storage of patient information there will be significant alterations in the way the Trusts within the LHC function and interact. Although the individual Trusts are justifiably proud of the services they currently supply, the different systems and processes used by different services sometimes obstruct the efficient and effective treatment of patients. Improving the consistency of information at both acute and PCT level will increase the visibility of information and improve communication within the LHC. Subject only to restrictions applied in response to guidelines on information sharing issued by CfH, this should lead to greater cooperation within the LHC and improvements to the services provided to the patient. R1 supports other opportunities to changing storage of information namely through the Electronic Documentation Management system which would need to be purchased as an additional bundle but could bring significant financial and clinical benefits to delivering patient care. Crown Copyright 2006 Page 9 of 29

10 4 Project Definition The NCRS is being developed to provide patient record accessibility to clinicians regardless of location or time. Information will eventually be maintained in secure national and Southern Cluster repositories that can be accessed with appropriate authorisation supporting planned, emergency and unscheduled care. The programme will be implemented over an extended time frame with functionality being added during its progression. R1 will deliver a workable and pragmatic solution, which meets the requirements of the NHS to deliver a robust patient administration and clinical system that will be enhanced over time to an advanced clinical state across the primary and acute setting. This release provides the foundation to which functionality will be added to deliver a complete healthcare solution. The project will follow a standardised implementation methodology allowing for repeatability and incorporation of lessons-learned during the implementation of future releases. 4.1 Strategic Drivers For the purposes of context, members of the LHC have articulated their strategic drivers that will be impacted by the implementation and use of R1 functions. Specific links to these drivers are not expressed in this document, although the objectives listed in the subsequent sections can all be seen as addressing certain elements. For the RD&E The RDE has four key strategic principles: Strategy One: Improving access to the RD&E and its services in the widest sense including: Providing the increase in capacity that is required to meet future growth in the demand Access to information Getting to the hospital transport and car parking Waiting for care: addressing waiting times and improving patient s experiences before arriving and once arrived in hospital Providing services away from the main RD&E site Strategy Two: Improving relationships with partners and stakeholders Participating more in the work of other organisations Supporting provision of NHS care outside the RD&E Working with patients Becoming more part of the social and economic community in Exeter, North and East Devon and the wider South West Strategy three: Developing new ways of delivering care In different places Through different or new kinds of staff To improve the patient s experience of care eg fewer people to deal with, less conflicting information and more convenient services Offering real and greater choices to patients in how they can be cared for Strategy four: Responding to staff Improving communications Helping staff to have a reasonable workload when at work Enabling flexible working patterns Recognising behind the scenes staff more Providing opportunities for staff to express their views Crown Copyright 2006 Page 10 of 29

11 Providing better staff facilities For the PCTs 1. To keep the people within our community healthy and to provide first-class healthcare to everyone 2. To ensure that patients have a choice of services that are timely and effective. 3. To provide an efficient, trustworthy and accountable organisation that takes the best care of patients and staff. 4. To keep the focus on what our patients want and need For DPT 1. Delivering the right care and treatment in the right place and at the right time. 2. Offering choice and control to service users in terms of how their needs are met. 3. Working with others to meet the clinical and social care needs of service users. 4. Developing and sustaining a competent, confident and motivated workforce who feel motivated and respected The components of DPT s strategic drivers are elaborated in the Trust's Service Development Strategy , which can be viewed at: Project Objectives With the strategic drivers identified in the previous section in mind, the main objectives of the project are: to implement R1 within the LHC, together with necessary interfacing to retained applications; to identify and deliver quantifiable benefits from process and the redesign of working practice; to gain financial efficiencies through the use of common underlying IM&T systems and services throughout the LHC and wider communities; to identify and support changes to the business procedures required to maximise the benefits from the deployment of R1; to deliver the project whilst maintaining business continuity; to improve the quality of care by enabling standards to be implemented across the NHS and Clinical and Community networks; to enable effective and appropriate access to clinical and administrative information across care providers and locations to support the NHS clinical priorities; to establish a foundation for the next Millennium release (R2). Whilst the project involves the implementation of R1 software within the LHC, it is recognised that this is part of a wider business change programme and not just an IT project. Service improvement will continue and will be further enhanced by subsequent releases of the software (R2, R3, etc). Achieving these objectives will be dependent on: 1. All staff identified as users of the system must receive training in the use of the Millennium system To achieve this: The Project Board will approve the training schedule; Line managers will release staff for Millennium training; Crown Copyright 2006 Page 11 of 29

12 The Board will review training take-up and intervene where engagement is low as reduced attendance will impact on the efficiency of the training delivered. 2. Healthcare practitioners will be encouraged to use Millennium to maximise the benefits gained from implementation For hospital information functionality this will require that: Millennium will be used to admit, discharge and transfer patients to help deliver the benefits of real-time bed management; Requests for follow-up appointments will be carried out using the R0 functionality and, where appropriate, HCPs will make an appointment on-screen in conjunction with the patient. For Clinical functionality this will require that: Clinicians will use Millennium functionality throughout the patient encounter where there are clear benefits and such use does not obstruct the consultation or the patient specifically objects; Clinicians will use clinical functionality where it exists in addition to other supplementary processes that may be locally agreed. 3. Where functionality exists, Millennium will become the primary system and will be used routinely by all staff To achieve this: Requests for secondary care will be placed directly onto Millennium and will not be actioned using paper or telephone referrals; All bed requests will be made and updated electronically in line with the real-time procedures; Case notes will be tracked on Millennium (and appropriate hardware (e.g. bar code readers) will be provided to support this); Millennium will be used as the central repository for patient data until spine compliance is achieved. 4. Functioning in a real-time environment: To achieve this: Hardware and networking availability be maintained and enhanced as required to support workstations at the point of information capture; An understanding will be engendered of what data needs to be captured in real time and by whom it is captured; A policy will be agreed that explains what real time means in practice. 5. All patient-related activity will be captured on Millennium To achieve this: Staff will be trained to ensure that, where functionality exists, they know how all patientrelated activity can be captured in Millennium; A timetable will be developed that shows when further activity related to other healthcare practitioners can be captured on Millennium. 4.3 Benefits There are several benefits that will be achieved through the implementation of R1, and many of these will be related to meeting the strategic drivers summarised in the previous section. Patients Crown Copyright 2006 Page 12 of 29

13 will benefit because the NCRS will improve the quality and convenience of care by ensuring that the right information is available to the right people at the right time, including patients themselves. It will also improve choice for patients and, in due course, will allow them easy, secure access to their NHS Care Record. Clinicians will have improved access to patient information across the LHC (assuming shared information protocols are in place) and wider national access when the NHS spine information service is implemented. It is estimated that around 80 per cent of the decision for patient diagnosis or treatment is based on information, for example medical history. The NHS will benefit through better collection and analysis of information, enabling resources to be used more efficiently, and allowing the NHS to plan better for the future (NHS, 2004). Processes for the identification and realisation of local benefits a) Review the generic R0/1 benefits road map; b) Plan the steps to be carried out to identify, plan, and realise the potential benefits of the NCRS R1 deployment; c) The benefits realisation plan is built into the deployment project plan as a series of actions, deliverables and milestones; d) Where possible and pragmatic, align the NCRS benefits work to the on-going ISIP work; e) Form a basis for agreement by both the ISIP Board and the CfH Programme Board on the benefits approach to be taken. Background As part of the NCRS deployment there is a requirement for associated benefits of the system to be identified, prioritised and realised. In addition, through the local ISIP and financial recovery) projects, the executives of the organisations within the LHC have agreed joint priority objectives and the expected outcomes and benefits for these projects. It has been established that the NCRS project and other CfH-based projects are important enablers to the LHC s Integrated Change Programmes for Scheduled Care, Unscheduled Care and Long Term Conditions Management. It is therefore important that all these initiatives are well aligned. Early work has been carried out to identify in more detail how the NCRS project supports the wider identified outcomes, and this is illustrated in the ISIP level 2 diagrams, attached in appendix 8. As the NCRS deployment progresses, more detailed work on specific benefits will be carried out. Approach The approach will draw on the Fujitsu NCRS R1 Benefits tool-kit and further incorporates the national ISIP approach. The table below sets out the proposed plan for the identification and management of the benefits throughout the stages of the NCRS project within the LHC. Responsibilities The NCRS benefits realisation approach has the following main responsibilities: Fujitsu Change Team As part of the NCRS contract, Fujitsu has responsibilities to provide product awareness and tools to identify and realise benefits from the NCRS deployments. These responsibilities are primarily facilitative, working with the local teams to ensure that the necessary processes and materials for identifying and realising benefits are in place. NCRS Change Team The NCRS change team is responsible for ensuring that the potential benefits are identified and that the benefits realisation plans are put in place and managed. They will devise and manage benefits-monitoring processes that should lay out the approach for identifying Crown Copyright 2006 Page 13 of 29

14 individuals to own each benefit and its realisation; the measurement and tracking of each benefit; and corrective procedures if benefits are not being realised, etc.. Organisational Benefits Owners The achievement of the realisation of the identified benefits will be through the successful deployment of the systems and processes provided to deliver the NCRS. This will be managed by the local process-owners from within the LHC organisations. The benefits also need to be owned and their realisation planned and managed by identified local benefits owners. The Benefits Realisation Plan is included in Appendix Scope & Exclusions The Local Service Provider (LSP) provides a standard and extensively tested solution as required by the contract between Connecting for Health and the LSP. Responsibility for ensuring that modifications or additions to the recommended workflows or any local modifications to the configuration of the system (whether locally introduced or introduced as part of the collaboration with the LSP) do not create hazards lies with the NHS client. We recommend that the Medical Director, overseen by the Chief Executive of the organisation, should undertake a formal Hazard Analysis before operational use of the system is permitted. All hazards identified at this time will remain in the ownership of the Trust and be managed by them as part of their identified mitigations and approach. The R1 functionality scope table is included at Appendix 9. Release 1 provides the following functions: Spine Compliance including Single Sign-on to the Cerner Millennium application, Advance Trace Queries (returning multiple matches) and NHS Number allocations; PAS functions including Inpatient Admission, Discharges and Transfers, Outpatient Scheduling, Waiting List Management, Case Note Tracking and support for the administrative processes in Mental Health (including basic support for Mental Health Act administration) and Community settings; Some clinical functions including order requesting and results reporting, some generic care pathways (to facilitate comprehensive multi-disciplinary assessment, planning and coordination of care for the patient), vital signs recording and clinical noting and support for the electronic Care Programme Approach in Mental Health; Emergency Department (ED), automates the functions in A&E including registration, triage and tracking, clinical documentation and discharge processes; Theatres, which automates the theatre process to support scheduling to capacity including patient scheduling and conflict checking. Maternity which provides PAS functionality for maternity including delivery and post-delivery documentation, NHS number for babies and clinical notes; Care Pathways that are designed to facilitate comprehensive multi-disciplinary planning and coordination of care for the patient. Initially there will be four generic Care Pathways in R1 Information for Analysis provides reporting tools to support the PAS functionality and additional content for analysis based on the implemented content, which includes analysis of patients by orders/interventions, clinical event, result, procedure codes, associated service providers. Crown Copyright 2006 Page 14 of 29

15 Information Reporting Requirements Reporting requirements fall into three categories: statutory reports, operational reports and ad hoc reports. It is expected that NCRS R1 will support each of these types of reporting by: Enabling current statutory reporting obligations of the LHC constituent organisations to be met; Providing operational reporting functionality to support the business needs of the LHC organisations by allowing access to timely and accurate information in an appropriate format for the purpose and allowing for on-going local and central development and maintenance of operational reports; Enabling local querying of business-related data from the agreed dataset held within NCRS R1, including specification of format and selection criteria, and allowing local viewing, printing or exporting of the query results in a standard file format. Examples of specific reports required can be found in Appendix 14. Exclusions to the project are: Replacement of any systems other than functions included in the new NCRS solution. Specifically, departmental systems, except where explicitly stated are not replaced and will be retained; any interface requirements for these systems have been identified. In addition, it may be necessary to procure or develop further departmental systems solutions to support the organisation and where feasible provide appropriate interfaces; In the hospital setting, R1 delivers systems that will take the LHC to the level of being able to order some tests and, subject to CfH guidelines on information sharing, view the results across the LHC. It does not take the organisation to electronic prescribing, although it is a pre-requisite for R2. Decommissioning of existing systems where these have been replaced by the new NCRS solution and are no longer required for access to historical data; Implementation of Fujitsu s EDM solution, which may be procured and implemented at a later date; Pre-requisite establishment of the N3 Connection upon which this project is dependent; General practice systems and services; General Practitioners except where they work within an LHC Location and require the use of the Millennium Systems; Social Services systems; Social Services Staff except where they are an integral part of an NHS Team and require the use of the Millennium Systems; Healthcare facilities provided within the prison service; Healthcare facilities provided within military or naval establishments. 4.5 Key Stakeholders Stakeholder identification, analysis, and planning has been carried out for each of the following organisations: The Royal Devon and Exeter Foundation NHS Trust; East Devon, Exeter and Mid Devon Primary Care Trusts Primary Care Trust Devon Partnership NHS Trust Crown Copyright 2006 Page 15 of 29

16 4.6 Key Deliverables/Desired Outcomes The following diagram illustrates the key deliverables within each stage of the project. Prepare For Implementation Initiate Local Design Prepare for Go live Go Live Support Preliminary Survey Localised Prepare for Implementation & Initiate Stage PIP Project Brief Organisation Readiness Assessment Stakeholder Analysis Localised Project Implementation Plan Communication Strategy & Plan Stakeholder Management Plan Financial Implications Paper Lessons Learned Log Risk / Issue Register Quality Plan PID Organisational Change Strategy Role Based Access Control Model Local Policy Statement Benefits Realisation Plan Business Process Design Site Design Support Design Data Migration Design High Level Architecture Design Local Infrastructure Design Interface Design System Design Deployment Verification Criteria Test Report Localised Training Materials Operational Readiness Report Train the Trainer Completed End Users Trained Test Specification Data Migration Completed Lessons Learned Report Post Implementation Review Organisation Change Review Benefits Review Training Evaluation Handover Report Verification Report Test Strategy Detailed Baseline Survey Solution Workshop Test Plan Training Plan Registration Authority Plan Environment Available in Data Centre End of Stage 3: Agreement to Go-live End of Stage 4: Go Live End of Stage 5: Project Closure Responsibility End of Stage 0: Project Brief End of Stage 1: Project Initiation Document End of Stage 2: Full Design FJS NHS 4.7 Approach The PRINCE2 methodology, incorporated with key features of the Fujitsu methodology will be included in the approach for this project. The project is based on the implementation of a standard solution across the Southern Cluster with standard processes, workflow configuration and national reporting. Deployment will use repeatable, standardised toolkits that include generic plan templates, design documents, training materials and upload programmes, as well as other data collection and reporting templates. The project will be sub-divided into five stages: Prepare for Implementation Initiate Local Design Prepare for Go-Live Go-Live These stages will have clearly defined milestones and deliverables, which will be routinely tracked, monitored and reported by the local Fujitsu Deployment Project Manager. Adherence to milestone tracking will minimise rework and ensure readiness before resources are committed by either the NHS or Fujitsu. To ensure seamless management, the deployment activities will have a sole source Crown Copyright 2006 Page 16 of 29

17 of responsibility, either Fujitsu or the NHS, although the activity may be resourced by both Fujitsu and NHS staff. 4.8 Deployment Testing and Verification Approach The Deployment Testing and Verification phase will take place towards the end of the lifecycle of the deployment project. All testing phases required to achieve the Bundle Key Milestone MAC will have been performed for R1 of the Cerner Millennium Solution, prior to the start of Deployment Testing and Verification. 4.9 Assumptions A number of assumptions have been made in order for a successful implementation to be achieved within the proposed timescale. These assumptions are primarily concerned with the availability of resources and the availability of facilities within stipulated time-scales Constraints There are a number of constraints and inter-dependencies that must be managed for a successful implementation to be achieved within the proposed timescale. These include: Existing vendors may be unable to meet the required timeframes for any defined activities; Configuration of an end-to-end test environment for existing legacy system interface testing; The R1 Millennium product must be available and tested in accordance with the Test Strategy; The project must be deployed upon a satisfactory technical infrastructure that is robust and fit for purpose; The warranted environment must be established prior to the start of deployment acceptance testing; Smart cards have been issued to all staff required by go-live; Data cleansing must be completed prior to data migration; Legacy Integration is a key element in ensuring business continuity; The availability of sufficient financial and human resources from suppliers and customers; Sufficient knowledge of other programmes that will potentially impact the LHC s R1 deployment The LHC can supply sufficient trainers and training accommodation; Generic R1 Training materials & access to an appropriate system are available from Fujitsu Organisational interfaces The organisations within the LHC are accustomed to working collaboratively in operational and service delivery, with formal communications channels between parties. Described in a later section, the project structure includes representatives from each of the LHC constituent organisations, who will continue to work together under the leadership of the Royal Devon and Exeter Foundation Trust to meet the requirements of the project within their respective areas Project interfaces There are a number of other major projects within the LHC that will coincide with the implementation of this project. These concurrent projects will be considered during the planning effort to ensure that Crown Copyright 2006 Page 17 of 29

18 necessary components are integrated and that resources are available to support each of the projects Data Migration Strategy The strategy proposes to: Migrate patient identity records with validated NHS numbers, not including deceased, possibly with a time limit; Migrate further patient identity records and specific event details for current & future operational running; and Maintain availability of current operational systems to a limited set of users, for access to historical data, which will then be migrated to a separate historical data viewer within a defined timescale Training Strategy The LHC has formulated a comprehensive training strategy that articulates the means by which the significant training workload will be planned and delivered. A training workstream has been convened and has commenced the detailed work necessary to undertake the exercise. Numbers for the R1 end-user training are currently estimated. Work has been done to identify all users at all locations, although there will need to be further investigation to establish process changes amongst staff, particularly in clinical functionality. The Training Workstream will work with the Business Change work stream to identify gaps and changes in working process, which will then be reflected in localisation of training materials. From information gathered in the Project Initiation Stage, it is estimated that there approximately 13,000 staff employed across the LHC; the number of staff affected by R1 is estimated to be approximately 10,178, of which approximately 7,259 Staff will need to be trained before go-live. The number of end users will depend to some extent on the outcome of decisions arising from choice of R1 functionality, future work on change management and decisions about new working processes. Consequently, there is a minimum number of staff who will be affected, and a maximum number who may or may not be end users. The calculation of staff numbers and resources required will therefore be subject to revision and refinement. There will be further training for the estimated 363 Champion Users (Ratio of 1 to 20), and also the IT specialists, who will require additional system and communication classroom-based training. Fujitsu will carry out training of the NHS trainers (Train-the-Trainer training (TTT)). The LHC will be responsible for training all end users and providing any additional training necessary for champion users. The full training strategy has been included at Appendix Technical interfaces Current Position The LHC currently has a functionally rich suite of existing healthcare systems of varied ages. In most cases, these systems are integrated around a common patient index and, in some cases, common access to inpatient details. Crown Copyright 2006 Page 18 of 29

19 The system interface architecture does not use a generic interface engine. Inter-system interfaces are of five general types: shared database, e.g. PAS, Maternity, Ward Nursing & EDS SWIFTPath; read/write interface to MPI from MSS PatientFirst ED/MIU system; exported text files; MPI and ADT transactions exported to relational tables, available for ODBC access; and HL7 messages. As well as these local clinical feeds, there are a number of additional interfaces: Electronic document messages to GP systems: Pathology results, from EDS SWIFTPath not affected by this project; Radiology results from HSS CRIS - not affected by this project; Discharge summaries from PLATO clinical information system; For Devon Partnership Trust, a feed of mental health specific data from Protechnic epex to a local data warehouse. Proposed Future Position The LHC intends to provide an integration service that will allow it to re-provide the existing functions: Discharge Summaries from Cerner Millenium can be integrated with current electronic discharge to GP processes (LHC initiative only); and For Devon Partnership Trust, and subject to further investigation, feeding mental health specific data to their local data warehouse. In addition, the LHC would like to gain the clinical benefit of making: Radiology reports from CRIS; and Pathology results from EDS SWIFTPath, or replacement, available to view in Millennium. It is recognised that this may be an extra cost item Strategic Direction of Local Service Management Connecting for Health (CfH) has chosen the globally-recognised IT Infrastructure Library (ITIL) framework as best practice in service management and contractually imposed the ITIL based BS15000 standard on all CfH suppliers. CfH require that Trust support focuses on ITIL processes for incident, problem, change, release, service introduction and business continuity. Prior to the go-live of the NCRS service it will be necessary for local Trusts to achieve ITIL Level 3 in Incident Management, i.e. have agreed and documented ITIL processes that all involved understand, have been trained, and are using ITIL best practice for Incident Management. Failing to meet this standard will mean that the Trust will need to use the National Service Desk to triage calls for which the local Trust will be charged per incident report. 5 Strategic Outline Business Case The National Business Case published in 2003 made the overall case for Connecting for Health, as aligned with the NHS Plan. Effective use of ICT was also identified as a critical area of concern in the HM Treasury s report into NHS funding (the Wanless Report), which stated that: Crown Copyright 2006 Page 19 of 29

20 Improving the use of information and communication technology (ICT) in the health service is a key issue in improving quality and productivity. Similarly, the Business Case stated that: at the present time the information systems available to the NHS remain an obstacle to the delivery of clinical governance in many Trusts. Many CHI Clinical Governance Reviews have commented adversely on the quality of information available from existing systems and supporting clinical governance through present generation of organisation specific patient systems will become increasingly difficult as the delivery of care becomes less bounded by individual organisations. In September 2003, Sir Nigel Crisp issued a letter regarding the Contractual Relationship between the Local Service Providers and the NHS. An extract from that letter is shown below. Gateway Reference 1969 At my first meeting with the 28 Strategic Health Authority Chief Executives in April 2002, we agreed to the following approach with regard to the above: In recognition of the complexity of the task and specialist knowledge required we agreed to the creation of a national team led by a Director General of IT to negotiate and procure key elements of the national programme, on our behalf. Thus we agreed to a direction and a common national approach anticipating that the national procurement would mean an element of common systems, a catalogue of preferred solutions, and centrally negotiated contracts. We have now agreed that I will sign the five contracts to be awarded to the successful Local Service Providers (LSPs) for each of the five clusters. I will pass the responsibilities so entered into by those contracts as a duty to each of the 28 Strategic Health Authorities, by direction. This course of action will eliminate the need for any further legal or technical evaluation of the contracts, at local level. The Strategic Health Authorities will be responsible for ensuring that each individual NHS organisation in their geographical area would meet any reasonable expectations of such a contract. Business cases and contracts for IT services and suppliers outside the national contract would continue to be the responsibility of individual organisations in the usual way. As a Nationally-mandated must-do, and with the contractual relationship that has been established between the Department of Health and the Local Service Providers, the requirement for a separate local Business Case is not definite. However, there are financial implications for the organisations in the LHC. Some level of local financing will be required in order to fully exploit the potential benefits of the NCRS. It is up to the organisations concerned as to decide how much of the gap between central funding and their perceived requirements is funded. The Financial Implications Paper is included in Appendix 6. Crown Copyright 2006 Page 20 of 29

21 6 Project Organisation Structure and Governance Full descriptions for all project team members can be located in NHS Roles and Responsibilities Document and Deployment Team Role Definitions. The following diagram illustrates the high level project organisation structure. Corporate Management: Trust Boards (RDE, PCT & DPT); Exeter District Local Programme for IT Programme Board NCRS Project Board (See table for Project Board Members) * Finance * Internal Audit * Work Force Development (Executive Group) NCRS Project Managers Project Support Office NCRS Steering Group: Communications Service Management Information Management Clinical Specialists: Technical Implementation RA/Security Application Specialists * System Configuration Interfaces * Warranted Environment * N3 * Data Migration Training Business Change Business Change: Change Leads (RDE, PCT & DPT) Testing * Reporting * Data Cleansing * Clinical Coding * Health Records Work Force Development (Steering Group) Change Groups: Service Areas (see attached) Business Lead Champion User Trainer * Communication Specialist * Change Analyst * * Supporting Roles across all Service Areas Delivery Groups: Supporting Roles: Change Analysts Communication Specialists Trainers Product Specialists * PAS / Maternity / Theatres / A&E / Mental Health / Clinical Crown Copyright 2006 Page 21 of 29