EHR Beacon Site Proposal

Heads of Agreement for County Durham

EHR Pan-Community Demonstrator Project

County Durham NHS

Mental Health Primary Care Hospital Mental Health Primary Care Hospital EPR EPR EPR EPR EPR EPR

Electronic Electronic Routine Routine Patient Patient accessible Health patient patient Health accessible Record care care Record

Community Community Social Care Social Care Services Aggregated Services Aggregated anonymised Records anonymised Records EPR subsets EPR subsets

20th October 2000 Heads of Agreement Durham EHR Version Final 20/10/00

RECITALS...... 5 Schedule A – Project Specification...... 7 A1 Executive Summary...... 7 A2 Background to Electronic Health Record Service...... 8 A2.1 Introduction...... 8 A2.2 Definition - What is the EHR?...... 9 A3 Issues and Risks for the EHR...... 10 A3.1 Security and confidentiality...... 10 A3.2 Privacy and Ethics...... 10 A3.3 Methods of working...... 10 A3.4 Coping with external changes...... 10 A3.5 Complexity...... 11 A3.6 User involvement...... 11 A3.7 Advances in technology...... 11 A3.8 Location and ownership...... 11 A4 Approach...... 13 A4.1 Distributed Information service approaches to the EHR...... 13 A4.2 Proposed architecture for the EHR...... 14 A4.3 The regional and sectoral context of the EHR...... 16 A5 Project Organisation...... 18 A5.1 Organisation Structure...... 18 A5.2 Managing the project...... 18 A6 Quality Plan...... 22 A6.1 Responsibility...... 22 A6.2 Standards...... 22 A6.3 Configuration Management...... 22 A6.4 Acceptance Testing / Outcome Reviews...... 22 A6.5 Project Quality...... 22 A6.6 Change Management...... 22

2 Heads of Agreement Durham EHR Version Final 20/10/00

Schedule B - Deliverables...... 23 B1 Work Package 1 - Project Management and Co-ordination...... 23 Objectives...... 23 Key Tasks...... 23 Work Description...... 23 Staff Resources...... 23 Deliverables...... 24 B2 Work Package 2 - Exploitation and Dissemination...... 25 Objectives...... 25 Key Tasks...... 25 Work Description...... 25 Staff Resources...... 26 Deliverables...... 26 B3 Work Package 3 - Requirements and architecture...... 27 Objectives...... 27 Key Tasks...... 27 Work Description...... 28 Staff Resources...... 28 Deliverables...... 29 B4 Work Package 4 - Specifications of the Systems and Services to be supplied...... 30 Objectives...... 30 Key Tasks...... 30 Work Description...... 31 Staff Resources...... 31 Deliverables...... 31 B5 Work Package 5 Development of the Simulator EHR...... 32 Objectives...... 32 Key Tasks...... 32 Work Description...... 33 Appendix 1 to Schedule B example workload for EPI Work Package 5...... 36

Schedule C - Individual Organisations Responsibilities...... 37 Schedule D - Third Party Responsibilities...... 40 Schedule E - Timetable...... 41 Schedule F - Acceptance of Work Packages...... 42 Schedule G - Financial Obligations...... 43 Costs...... 43 Payment profile...... 43 Schedule H - Change Control Procedures...... 44 H1 Principles...... 44 H2 Procedures...... 44 Schedule I – Copyright and Intellectual Property Rights...... 48 Appendix 1 to Schedule A - Scope Appendix 2 Project Forms

RECITALS

This Heads of Agreement represents the contractual commitment of the Partners in Health in County Durham to the Electronic Health Record Pan Community Demonstrator Project. It is hereby agreed that the parties detailed below agree to meet their contractual commitments to the project described within this document:

Contracting Authority Signature………………………… Name…………………………….. Position………………………….. For and on behalf of County Durham & Darlington Health Authority

Partner Organisations

Signature………………………… Signature………………………… Name…………………………….. Name…………………………….. Position………………………….. Position………………………….. For and on behalf of North Durham For and on behalf of South Durham Health Care NHS Trust Health Care NHS Trust

Signature………………………… Signature………………………… Name…………………………….. Name…………………………….. Position………………………….. Position………………………….. For and on behalf of Darlington For and on behalf of County Durham Social Services Department and Darlington Priority Services NHS Trust

Signature………………………… Signature………………………… Name…………………………….. Name…………………………….. Position………………………….. Position…………………………..

For and on behalf of Durham Social For and on behalf of The University Services Department of Newcastle which includes The Centre for Software Reliability and The Sowerby Centre for Health Informatics in Newcastle

Signature………………………… Name…………………………….. Position………………………….. For and on behalf of Eclipsys Limited

Schedule A – Project Specification

A1 Executive Summary

The concept of an Electronic Health Record has been proposed to improve health care delivery and provide better integrated health and related services. Current health records are generated and held in many forms in a wide range of locations by many different types of health and social care agencies and the means for accessing and maintaining this information are cumbersome and fragmentary. The authors of this proposal do not believe that a constructive response to the EHR concept can be based on the conventional approaches. We believe that the technologies and infrastructures now becoming available allow a more distributed and flexible approach to delivering the required benefits of EHR while still addressing the fundamental requirements for a dependable, coherent and secure service which supports professional, ethical, social and clinical needs of the modern health service. The envisaged EHR, if deployed, would rapidly become a fundamental aspect of the delivery of health services and, for this reason, it can not be treated simply as another exercise in systems procurement. Because it has implications across health care systems, it may not be decomposed into a set of components problems such as security, data modelling, communications, etc., and each handled piecemeal. A systematic and architectural approach is required to understanding and analysing the problems and options as well as to the formulation and evaluation of proposed solutions. The consortium presenting this proposal brings together the expertise required from within the NHS, the commercial sector and academia to deliver the following elements:  A comprehensive and rigorous investigation of EHR resulting in a systems and operational architecture which has been tested and validated against the policies and interests of all user communities and stake holders.  A simulator environment populated with realistic but anonymised data (and maybe with other sensitive information removed), which provides the basis for explaining and exploring proposed solutions, introduction strategies and evolution paths for an EHR service.

The demonstrator will be not be a live system. However, our aim is for it to be possible to move directly from the simulator, produced within the project, to the procurement of a scalable operational system.

A2 Background to Electronic Health Record Service

A2.1 Introduction Information for Health introduces the concept of a primary care Electronic Health Record (EHR). It indicates that the EHR should be automatically updated with data from Electronic Patient Records (EPRs) based in the Acute, Mental Health, or Community Services environment. In addition, social care records should be used to supplement this data. Information for Health suggests that use of the EHR by clinicians would deliver numerous benefits, including the following:  Provide 24 hour access to key patient problems, history and current medication from any location connected to NHSnet.  Support seamless care by providing common patient records, shared by professionals working in different disciplines and organisations.  Reduce the risk of poor treatment and outcomes arising from poor communication of information.  Provide more accurate, comprehensive and relevant extracts, to support clinical governance, epidemiological research and the further development of health improvement programmes. These would of course be these would be aggregated and anonymised.  Provide appropriate data sets to the patient.

Information for Health calls for the development of beacon sites to explore the validity of different approaches, and prove the benefits. This document presents a proposal for a demonstrator in County Durham. Because the concept of the EHR has yet to be proven in practice, and because it raises many difficult issues concerning boundaries of trust and ethical codes this is not an information systems project where the only problem is to find an appropriate, effective and acceptable solution. Rather, it is a project where the main issue is problem uncertainty (i.e. what are the real benefits that may be expected to be delivered by the system and what additional problems or opportunities could the solution reveal?)

There is a lot of experience that conventional procurement processes do not work well in the presence of problem uncertainty, since a period of exploration is required and it cannot be stated in advance what the end point will be. This is sometimes addressed in two distinct stages: a feasibility study or similar, and an implementation exercise. The current proposal combines these, but not as distinct and separable stages; rather, we recognise that the implementation process itself may well bring to light further problems to be explored. Thus our proposal is intended as a pilot to identify a path through uncharted territory. It brings together NHS, supplier and academic expertise to take a rigorous approach to the exploration of both systems and organisational options, the representation and analysis of policy and requirements and the identification of current and future needs. The approach places particular emphasis on the involvement of clinicians, patients, managers as well as of other internal and external agencies to ensure that the ethical, contractual and operational characteristics of proposed EHR solutions are understood and can be evaluated from the viewpoint of all relevant interests.

A2.2 Definition - What is the EHR? The EHR could be considered as an extension of current general practice systems. This view raises numerous technical and operational difficulties. In County Durham there are approximately 88 General Practice systems and at least 12 other clinical systems. There are potentially some 7,000 clinical staff who may need access on a 24 hour basis. Implementing an EHR solution based on existing GP systems raises the following questions:  How does the system enable the clinician locate patient data, when it may be stored on one of 100 different systems?  How can access be guaranteed on a round the clock basis in a cost effective way among these systems?  How can security and authentication of each of the 7,000 clinicians be maintained in such an environment? The creation of a dependable, secure and highly available EHRs based on the existing widely dispersed and diverse set of data sources and legacy systems is not feasible technically or organisationally. Existing systems provide neither the necessary controls over access and ownership of data, nor the availability, performance and functionality required. In any case, the EHR is more than a simple extension of existing information structures. It has a job to do in forwarding information to other clinicians and services, and its scope is potentially wider than the NHS, in that it may contain pointers to other information held by other agencies. An EHR system 9 Heads of Agreement Durham EHR Version Final 20/10/00 must therefore be capable of delivering information coherently from a NHS- wide service and provide clinicians (under appropriate controls) with the awareness of and access to the wider information spaces to which the EHR points. Any approach to the definition of an EHR environment, which is likely to span many levels of application components as well as network and communication services, must take the following factors into account:  There is a core of basic patient information concerned with identification and location, which is relatively long-lived and static and which must be maintained and managed on a NHS-wide basis.  For any item of a health record to be of clinical benefit it must meet the following conditions: firstly, its existence and relevance must be visible so that clinicians are aware of what information is available to them, secondly, it must be deliverable on the basis of properly validated requests and, thirdly, it must be presented in a clinically appropriate way.  From generation through to eventual destruction, there are explicit responsibilities for the content, custodianship and use of clinical information in the interests of the individual patient and of the Health Service in general. These responsibilities may be reallocated and reconfigured with the introduction of new technologies, services and organisational structures but their fundamental nature does not change.

A3 Issues and Risks for the EHR There are a number of technical and organisational issues which will have to be very carefully thought through if the EHR concept is to fulfil its intended purpose. The following list raises the major ones.

A3.1 Security and confidentiality The development will consider the maintenance of data integrity, security and confidentiality through the provision of a strong authentication layer. The potential for the use of encryption will be explored. This security layer will be complemented by appropriate processes which are able to ensure the consistency and auditability of the system and its operation across the boundaries of the many agencies concerned. The EHR will also have to support current policies and mechanisms on confidentiality of patient care in its operational approach, and the architecture of the EHR system will have to be adaptable to future policy directions.

A3.2 Privacy and Ethics The security and confidentiality solutions just mentioned are mechanisms in support of wider issues of ethical policy and practice. It remains to be found 10 Heads of Agreement Durham EHR Version Final 20/10/00 out to what extent there are differing ethical codes in different domains, and to determine possible implications of any differences on the security and confidentiality solutions to be deployed.

A3.3 Methods of working The concept of an EHR has implications for the organisational structures and workflows within and among health and social care agencies and also for the information and communications infrastructures that support them. These implications need to be carefully explored if the EHR is to be proved fit for its intended purpose.

A3.4 Coping with external changes The health service and the society in which it operates is not static. New structures and relationships, processes and technical possibilities will continue to emerge. For this reason, it is essential that any approaches to delivering an EHR, in addition to responding to the policies and requirements which have been set out, must also support incremental introduction and continuing evolution.

A3.5 Complexity An EHR environment represents a considerable increase in complexity from both the systems and the organisational standpoints compared with conventional health care applications. Recent developments in the structure of the communications service and application systems sectors have created new options for the type of solutions which could meet the needs of the EHR. It is essential that these options are understood, and that the technical solution which we choose is one which anticipates these possibilities. Such a solution will offer new scope for both the efficiency and effectiveness of the EHR environment which will not be achieved through a conventional approach.

A3.6 User involvement The interim EHR will be based on new and as yet unexplored configurations of systems and of organisational relationships. It will be essential to ensure that clinicians and all other interested parties understand the options and consequences of decisions at all stages of development. An operational system will need to hide much of its internal working so that is easy to use. However, to reach agreement on exactly how it operates, a version of the system which is able to demonstrate what it is doing behind the scenes will be necessary. All aspects and implications of proposed systems must be open to inspection and evaluation during the systems definition and design processes. 11 Heads of Agreement Durham EHR Version Final 20/10/00

A3.7 Advances in technology The technical platform in which we prototype and explore solutions must be based on the emerging standards which will become commonplace in the 3 to 5 year time frame. This is particularly significant because developments such as distributed transaction and workflow management services, which are the subject of current standardisation and product development, are specifically aimed at creating new options in the integration of information distribution and management across domains of control and responsibility. The emerging standards and practices in the NHS, and the EHR in particular, must intercept these developments.

A3.8 Location and ownership In an EHR implementation, the different elements of medical data could be hosted in different organisational units and different levels, for example PCG, General Practice, Local or regional Informatics Service. The initial phase of the project will explore options and make an initial choice which makes best use of existing infrastructure but which can respond to the evolving organisational needs and technological possibilities. Some of the background and implications of the distribution of the EHR service and information components is presented in the next section.

A characteristic of large, complex distributed information systems such as the EHR is that they must provide a high level of transparency: that is to say, they hide complexity from the user. The architecture of the EHR must achieve two objectives: it must deliver appropriate transparency in the operational systems and services but, at the same time, it must be capable of making the details of its precise structure and operation visible and auditable. The characteristic of monitorability and the capability to present the process and history of operation represent important objectives at the architectural level. They have a significant impact on the initial validation and introduction processes and are also part of the operations management of the EHR system. The characteristics of monitorablity and the means for visualisation and inspection must be considered from the outset of the EHR systems design. Our approach to problem and policy definition and to systems specification is based on the Open Distributed Processing (ODP) standards which, through their concept of projections, provide a proven basis for structuring the complex, multi-faceted representations of enterprise and information as well as computation and design.

An important aspect of the validation will be the acceptability of the visual presentation of the operation of the system. Particularly where a complex system function is invoked, it is vital to present to the user a picture of what is happening. Validation is a matter of checking that the user’s mental model of what is going on is a sufficiently accurate representation of what is actually occurring in the distributed computer system.

A4 Approach

A4.1 Distributed Information service approaches to the EHR Developments in distributed information systems over the last decade have opened up many new possibilities for the implementation of complex services such as the proposed Electronic Health Record. The most significant consequence has been that we are now better able to reflect evolving organisational structure and relationships within the architecture of our technical systems. The purpose of this section is to try to explain the nature of these new possibilities. In its most simple and direct form, the concept of a universal EHR implies that users, who are generating and requesting health record information, access a common information resource. This is the logically centralised approach which could, in theory, be implemented in a physically centralised service: one EHR server for the whole NHS. However, the scale and performance issues associated with such an approach present serious problems as do the organisational consequences of the concentration of control. Consequently a distributed approach in which many systems co- operate and together provide an overall service is to be preferred. This distributed approach, which is based on conventional and mature technologies, offers major architectural design choices in the selection of the number and size of the component systems and how these a mapped onto existing organisational structures. In NHS terms, the information hosts could correspond to natural health communities, health authorities, or individual trusts and practices. Such choices would have a number of significant organisational and operational consequences. Because of this, we wish to produce an architecture which leaves open the decision as to the level of granularity until the consequences of a particular decision have been considered and evaluated in the context of a particular health authority. Different authorities may decide on different levels of granularity; it would be desirable if these could be met by selecting different configurations of a common architecture rather then redesigning the system from scratch. We shall therefore produce a system capable of supporting a range of configurations which are capable of interworking. The first stage in designing such a distributed service involves connecting a number of information resource systems together and partitioning and distributing the information among them. The total information resource system then becomes a network of nodes each of which is able to process local data and is able to redirect transactions involving remote data where required.

Splitting up and distributing information introduces a second area of flexibility: the extent to which data could be replicated in different places to provide more efficient access and availability. At one extreme, all the data could be replicated in each of a relatively small number of systems giving a logically centralised but physically distributed service. At the other extreme, each system could represent unique ownership and control of local data and offer an information service to external enquirers. Such an approach is embodied in the Internet which illustrates advantages of robustness, scalability and flexibility at the overall network level. However, this extreme of distribution does not provide the manageability and predictable quality of service required of the EHR service. There are many intermediate configurations of a distributed information service which can deliver manageability and quality of service without sacrificing the flexibility and overall robustness of the distributed approach. It is the objective of this demonstrator proposal to explore and evaluate these options.

A4.2 Proposed architecture for the EHR Now we have described the possibilities for distribution of the systems and the information they contain, we present, at the highest level, the sort of technical architecture we envisage as a basis for exploring the concept of an Electronic Health Record in terms of five sorts of system.

Patient Epidemiological Health Programme Access Research Development Clinicians in Primary Emergency & & Secondary Care Para-medical Care User Systems

Gateway Systems

Core Systems

Service Systems

Hospital EPR Primary Care EPR Community Services EPR

Social Care Mental Health Record Holding Systems records EPR Systems

1. User systems supporting clinicians in primary and secondary care, emergency and para-medical use, patient access and also epidemiological and health programme planning. Such systems will be widely distributed through NHS and also in some non NHS institutions. 2. EHR Gateway systems which control access to medical records and is responsible for the presentation of record information. In some contexts of use, this may be anonymous and aggregated. Note that our approach is not based on the idea that data sets will be universally standardised: the EHR system will provide windows on existing information sources as appropriate for the access technology and context of use. 3. EHR Core systems will provide a highly available core service delivering basic patient record information and pointers to the relevant records and content held in a wide range of information service systems within the EHR network. 4. EHR Service systems provide EHR information services on behalf of record holders. Thus, such a system may offer a service which mirrors the medical records held in a set of practices which is updated on a 24 hour basis. Understanding and experience of the technologies required to deliver such services in a highly dependable way even in the context of relatively unreliable systems and communications services represents one of the more important developments which the members of the consortium bring to this proposal. 5. Patient Record systems including social care records and, potentially, all current medical record systems in the primary and secondary sectors. Clearly, these classes of systems may be mapped in many different ways onto existing systems resources: a large hospital records system may also include its own EHR service and operate the gateway for internal and local users, while special gateways for mobile and emergency services could provide specially tailored services. NHS direct would integrate its tailored gateway into the call centre environment while the channels for patient access may be associated with local health centre facilities. In addition to issues of distribution policy, regarding where information is held, here are major questions of policy and requirements concerning the technical and organisational relationship between the Information Service and 16 Heads of Agreement Durham EHR Version Final 20/10/00

Core Systems on the one hand and the Record Holding Systems on the other. It could be the case that all health record information is regarded as belonging to the record holding system and, as a consequence, there is no possibility of remote updates. Alternatively, the mirroring relationship between service systems and the record holding systems could be symmetrical allowing some forms of remote update. In addressing these questions, the concept that the maintenance of the coherence, accuracy and timeliness of the EHR data should be a consequence of the operation of the services and the delivery of care and a consequence of the capability of the infrastructure rather than an additional user overhead, is important. The implications for clinical governance, security, quality of care and efficiency of the chosen approach requires considerable investigation and evaluation. It is clear that the architectural approach we describe provides a wide range of options regarding the configuration of an EHR service. The challenge of the first phase of the proposed work is to demonstrate that there are specific configurations which will meet current health care needs and policies and can provide a basis for a well ordered roll out and manageable evolution. On the basis of the evaluation of this initial definition, as second phase will develop a pilot system which will provide a realistic test of the operational capabilities of the proposed architecture and will also provide the tools and resources for presenting, explaining and evaluating the approach with a wider NHS audience.

A4.3 The regional and sectoral context of the EHR A concept as significant as the EHR can not be treated on a piecemeal basis. Its implications on so many different internal and external organisational and technical levels mean that it must be considered in relation to the evolving communications and information strategies of the Health Service and of the many agencies that interact with it in the delivery of wider social services. Two areas in particular must be considered:  The relationship between the EHR approach and the developing NHSnet infrastructure.  The current political pressure towards evolving policies for more integrated and co-ordinated public services will necessarily lead to a change in the relationship between the separate enterprises providing these services. As a network and information systems environment, the proposed EHR approach provides a platform not only for health record information services but also for a wide range of structured communication and work-flow 17 Heads of Agreement Durham EHR Version Final 20/10/00 services between the different health and social service agencies. It thus represents a core application and service which will require investigation of appropriate facilities for delivery, one of which may well be the NHSnet infrastructure. Close links will be required with the evolving definition and deployment of the local and national communications infrastructure throughout the course of the proposed demonstrator project. One of the most important areas for investigation in the definition of the EHR is the extent to which different aspects of the environment can be out-sourced, shared within the Health Service or maintained as application components within individual health care institutions. An important factor in this respect is the Northern Informatics initiative to develop a regional “intranet” connecting public service providers and electronic commerce and telecommunications-based businesses in a new, public-private sector partnership in the Northern Region. This project is called REEP The regional Electronic Economy Project. This provides an opportunity to explore new configurations of telematics service provision not only at the level of basic data communications and network services but also but also the possibility of externally supplied secure and highly dependable message services, transaction and intermediation services and hosting, archiving and audit trail services.

A5 Project Organisation

A5.1 Organisation Structure

IfH Programme Board Programme Manager sits on IfH Programme Boardwhich links to the: Joint Exec Group HIMP IfH Steering Group Stakeholder Forum Programme Manager

EHR Project Board Consortia Board

Project Manager

Project Manager directs activities of Project Project Board/Team Architecture Team Project Board/Team Members supported by Sub Project Teams

Focus Group Sub Project Teams Technical Support Team Ferret Team Software Development (Eclipsis)

A5.2 Managing the project The project will be a component of the LIS, which is managed using PRINCE2. However, because of the problem uncertainty mentioned in the introduction, a methodology more suited to the management of prototype developments might be better suited to the nature of the project. The project brings together technical and operation staff from several NHS units, academics and also involve detailed interactions with the technical and commercial staff of external system and service suppliers. It also includes clinical management and other NHS staff and Social Services who will form part of the Focus Groups. A high proportion of the work to be undertaken is concerned with the generation of policy and design concepts which are to be tested and evaluated from the clinical, managerial, technical and commercial/economic points of view. While there will not be any large scale development work undertaken, nevertheless a substantial amount of implementation and systems integration activity will be required in mounting a realistic demonstrator. Overall project management responsibility will be vested in the prime contractor. Day to day responsibility will be held by a part-time Project

Manager who will produce and maintain detailed schedules for development and delivery of individual project components. The technical direction and co-ordination of the project will be undertaken by an architecture team which will report to the project manager. It will be responsible for:  Producing an architectural document which clarifies and states the policy framework and shows how this framework dictates and constrains a number of design choices while leaving others as implementation trade- offs.  Preparing and delivering client and user consultations and collecting and representing client/user inputs.  Specifying the functionality to be developed in the prototype and ensuring the quality of the implementation process.  Producing the technical documentation which the project will publish as part of the dissemination and roll out of the EHR system. The implementation teams will be responsible for the detailed design, delivery and integration of the technical components of the prototype EHR system. Monthly technical management and review meeting will be held at which progress will be reported against planned activities. This meeting will be attended by task leaders and will be chaired by the project manager. At three monthly intervals a project board meeting will be held at which the work package leaders and the project manager will report progress to senior representatives of the health agencies and project sponsors. The format of project reports and milestone status are detailed in Appendix 2. EHR Project Board

Executive role Andrew Thompson – Programme Manager represents interest on project board

Technical role Andrew Izon – Head of IM&T, NDHCNT

Senior User role Dr Stewart Findlay – The Dales PCG Dr Robert Upshaw - Darlington PCG Dr Duke - Duke Partners Mr K Wright - Consultant Surgeon NDHCNT Mr D Hutchon - Consultant Obs & Gynae NDHCNT

Dr R Hammond - Consultant Radiologist NDHCNT Marie Burnham – Executive Director of Performance & Governance CDDPSNT Joanne Woodward – Snr Finance Officer Angela Radcliffe - Darlington Social Services Peter Appleton – Durham Social Services Supplier role Dr Nick Booth – SCHIN Steve Dent - Eclipsys

In attendance Paul Morgan - Project Manager

Consortia Board (representing supplier side)

Chair Dr Nick Booth Andrew Thompson Andrew Izon Bob Sugden John Dobson Mike Martin Steve Dent (Eclipsis) SDHCNT rep

Project Manager Paul Morgan

Project Architecture Team Project Manager Paul Morgan 2 x Research Assistants 1 x Technical Research Assistants Eclipsys representative

Responsibilities Job Descriptions(to be developed). Meeting Arrangements Project Board Meetings will be called to agree the HOA and quarterly thereafter and in line with Milestones agreed in the Project Plan (see Schedule E). They will be organised and minuted by the Project Manager. In the absence of Project Board Meetings the functions normally carried out by this group will be fulfilled by direct contact between The Project Manager and the appropriate people on an "as needed" basis. Project Team Meetings will be chaired by the Project Manager. The Project Manager may call upon other specific personnel to attend as needed, over and above the core members. The frequency of Project Team Meetings will be approximately monthly. They will be minuted by the Project Manager.

A6 Quality Plan

A6.1 Responsibility It is the Project Board’s responsibility to assure itself both as to the quality of the project and the quality of individual delivered products. Individual members may achieve this by delegating quality control to other staff not involved in the project.

A6.2 Standards The project will be run using the PRINCE 2 standards.

A6.3 Configuration Management Copies of all project documents will be held by the Project Manager. All documentation will contain a unique reference, a version number and a date created (rather than a date printed).

A6.4 Acceptance Testing / Outcome Reviews Procedure for acceptance testing or reviewing products is detailed in Schedule F. The Executive Role will on behalf of the Project Board formally sign off each product against work package specification. This will be documented by the Project Managers report with a signature box to authorise the report is agreed and accepted. A good acceptance criteria is that the product meets the work package description.

A6.5 Project Quality The Project Board with the Project Manager will conduct an End of Project review six months after the end of the project; additionally the Project executive with the project manager will conduct a stage review at the end of each stage. Project documentation will be reviewed by the Projects Manager prior to initial publication for quality.

A6.6 Change Management All Requests For Change (RFC) must be approved by the Project Manager and presented on standard forms (a sample of the Change Control Request form to be used is appended). When changes require additional resource or significantly affect deliverables authorisation will be required from a member of the Project Board.

Only milestone changes to the Project plan will need to be submitted to change control.

Schedule B - Deliverables

The following schedule details the five work packages to be delivered.

B1 Work Package 1 - Project Management and Co-ordination

Objectives  To co-ordinate and manage the project successfully within the boundaries of the FLIS and the bid.

Key Tasks 1.1 appoint person responsible for co-ordination to develop Heads of Agreement document that will detail the following:  agree a management framework which dovetails with overall LIS development  ensure all partners are fully aware of what is expected of them, and how it fits with the contribution of others  develop common, shared assumptions about the scope, processes and deliverables in the project  establish appropriate communication channels between partners, and to Programme Management and other stakeholders as required  develop excellent working relations with the centre, building links to other related national initiatives  establish appropriate financial and quality control systems  develop and maintain project file, including plans, specifications, progress reports, budget/expenditure statements  consortia board meet quarterly and produce project update

Work Description The production of regular management and progress reports including annual reviews as required by the detailed Project Plan, for the partnership, the LIS Programme Board and the project sponsors.

Staff Resources A part-time project manager and part-time administrative support.

Work package 1 Deliverables Key Month nature of deliverable Task 1.1 1 Project Initiation Document 1.1 1 Project Plan 1.1 Monthly Internal Progress Reports 1.1 Quarterly External Progress Reports to Programme Board 1.1 Quarterly Financial Control Statements to Programme Board 1.1 as required Quality Assurance Reviews of deliverables 1.1 as required deliverable sign-offs [Reports, implementations] 1.1 3, and materials towards work package 2 [publicity policy, thereafter as briefing documents] required

B2 Work Package 2 - Exploitation and Dissemination

Objectives To develop and initiate the dissemination and exploration of the EHR project results using SCHIN or ERDIP web site. To liase with EHR partners and other national groups and bodies for sharing of information. To demonstrate EHR system to appropriate interested local and national bodies.

Key Tasks 2.1 Strategy Develop a strategy for promoting, communicating and dissemination of information on all aspect of the project and produce an implementation plan for the strategy. 2.2 Launch EHR project. Prepare a plan for the launch of the project, including promotional material and other information. 2.3 Dissemination Prepare both regular and ad hoc informational material for distribution. Receive and circulate information to project participants about other national projects which are relevant to the project. Broadcast information about the EHR project. In the first instance, the main audience will be internal, both project staff and other staff in the partner organisations; but later this activity will be extended out to the wider community within the NHS. 2.4 Demonstration Undertake demonstration of the pilot EHR system where appropriate.

Work Description  Produce a draft communication strategy for discussion and approval by the Clinical Steering Group and Programme Board.  Produce a plan for approval by the Clinical Steering Group and commence implementation.  Develop a plan for launching the project and thereafter its implementation.

 Ascertain other similar EHR partners and establish regular communications with them to share information about the project.  Organise and co-ordinate demonstration of the pilot system.

Staff Resources Within the membership of the project architecture team managed by the consortia

Work Package 2 Deliverables

Key month nature of deliverable Task 2.1 3 A communication strategy and implementation plan 2.2 3 A plan for the launch of the project and its related launch material 2.3 as required Information leaflets, broadcast material, articles, newsletters 2.4 to be arranged Demonstration itinerary and material

B3 Work Package 3 - Requirements and architecture

Objectives To determine the requirements and the constraints on the implementation of an EHR. To represent these requirements in terms of a set of models and descriptions which are suitable to inform the policy discussions and the process of explanation and introduction of an EHR system. To provide the input to the design and engineering processes for the initial prototypes and also for the longer term implementation, roll out and evolution of an national EHR service.

Key Tasks 3.1 Initial enterprise model and requirements This task will determine the responsibilities of those who will have access to the EHR system, what they need to know, to do and to record in order to fulfil those responsibilities (and demonstrate that they have done so), and to determine the characteristics of their required access to the system. (Note that these stakeholders are not restricted to the NHS but include other organisations such as infrastructural and support service providers.) It will determine the impacts on indirect stakeholders – non-clinical roles whose responsibilities and jobs will be changed by it, including the possibility of access by patients. 3.2 Ethical framework This task will produce an ethical policy framework, to provide a basis for consultation and negotiation with all the parties involved in the generation and use of EHR information. This framework will be based on the principle that all responsibilities must be explicit and be built into clear processes and protocols. The systems and services which are components of the EHR must then support these processes with equal explicitness. The benefits of a highly distributed service and application must not disguise the significance and possible consequences of user actions. 3.3 Enterprise, information and security models The objectives of key task 3.3 are to analyse the information elicited in key tasks 3.1and 3.2 so as to produce  a set of requirements models which are an appropriate input into the design and engineering process;

 a set of evaluation criteria that is a fit input into a validation and assessment process. The models will address the following areas:  identification of roles to be supported by the information system  identification of workflows to be supported by the information system  information access requirements by role  statement of ethical and security policy and model  statement of availability and other dependability policies  physical location of demonstrator server(s)  data models The evaluation criteria will cover  acceptance criteria  performance criteria  training needs criteria

Work Description Key tasks 3.1 and 3.2 will initially involve some mix of interviews, focus groups, questionnaires and observation. Key task 3.3 will take this initial set of enterprise and information models and workflows and use them to further the elicitation process by which requirements are determined, and to identify further stakeholders (both direct and indirect). It will thus concentrate on the enterprises and the relationships between them and the information architecture and the boundaries of the system. A second set of models will be elaborated, showing not only the overall information and workflow architecture, but also the detailed data and security models. These models will initially be produced by the architectural team and refined in the light of discussion with the relevant stakeholders. In these interactions with users, stakeholders and policy makers, the requirements-oriented models will be combined with emerging implementation proposals expressed as workflows and as systems configurations in order to provide concrete presentations and choices appropriate to the specific interests and experience of the audience.

Staff Resources Three people during the first year, thereafter one person.

Work package 3 Deliverables

Key Task month nature of deliverable 3.1 3 a preliminary enterprise model and requirements statement 3.2 6 an information model and ethical framework 3.3 9 detailed data models, a detailed security model, and evaluation criteria

B4 Work Package 4 - Specifications of the Systems and Services to be supplied

Objectives To specify the EHR concept in technical terms To generate an implementation reference model of the system and its interfaces required for working with other organisations To produce a refined design and technical specification

Key Tasks 4.1 Development of the EHR Reference Model The technical specification of the systems structure and configuration which includes where an item of information is located, whether and how it is replicated and how the access rules are enforced. The concrete reference models will specify the range of available solution options and must be convincingly mapped onto and justified by the ethical and security models developed and agreed in WP3 taking advantage of products from the Tees ERDIP demonstrator if available and other HER sites if appropriate. 4.2 Analysis and evaluation of EHR configurations This task will explore a range of systems and service configurations based on different levels of aggregation of information and configurations of service resources. Thus, concepts such as an information service system which mirrors GP data, acts as an access portal to local secondary systems and maintains links with a regional node will be considered from both the technical, organisational points of view as well as in terms of cost and performance. Given any particular concept of aggregation such as this, the requirement for infrastructural services to deliver the coherence, connectivity and security of the EHR service will also be examined. 4.3 External interfaces and components One of the problems which must be addressed by the proposed EHR service is the relationship with legacy systems on the one hand and with new infrastructural services on the other. This key task will develop and publish two proposals for open specifications, mentioned in this key task and the next: (i) The connectivity and integration components required by existing information source systems such as GP and hospital medical record systems and the proposed EHR system.

(ii) The technical and quality of service specifications of the structured communications, transaction and other services which are proposed as part of the EHR infrastructure. 4.4 Final EHR definitions To produce a binder of the published work which is a consolidated and appraised final version of the project.

Work Description The work to be undertaken involves systems and process design at the architectural level supported by more detailed feasibility analysis. The concept of an EHR node, and the network of such nodes, is initially defined to meet functional requirements associated with the capture, coverage and accessibility of data. However, the issues which are raised in the definition of the security and ethical framework must be addressed with proposed specific technical and organisational solutions. The location, configuration and operation of these mechanisms must be evaluated in the context of a proposed EHR network configuration and a recommendation and justification regarding the initial configuration to be piloted will be made. An overall systems design will be developed and a proposed pilot environment defined which will provide a suitable platform for testing, demonstrating and evaluation the EHR implementation concept. The systems design will consider connected systems and agencies including NHS Direct. It will be supported by an analysis of the use of NHSnet and Local Strategic Networking infrastructure based upon gateways and nodes. The exact configuration is to be decided as part of the project but could for example include 1 EHR node, 3 service provider gateways and 2 GP gateways.

Staff Resources This will be the responsibility of the Project Architecture Team.

Work package 4 Deliverables

Key Task Month nature of deliverable 4.1 3 Reference Model 4.2 6 Proposed pilot environment 4.3 15 Overall definition of a national EHR environment (draft) 4.4 24 Final EHR technical definition 34 Heads of Agreement Durham EHR Version Final 20/10/00

B5 Work Package 5 Development of the Simulator EHR

Objectives To implement an EHR simulator environment, initially on the basis of artificial content but with the potential for increasing realism of both content and operation. To verify the ethical and security models and also the proposed operational characteristics of the EHR service through experiments and evaluation exercises involving representatives of all the stake holders. To identify critical technical issues, constraints and opportunities which arise in developing the simulator which have an impact on any aspect of the architecture and to reflect these back into the architectural process.

Key Tasks 5.1 Provision of the simulator environment The simulator must contain and present a sufficient quantity of realistic data to provide a test of the proposed architecture. This may be either based on sanitised real data or artificially generated material; the purpose of this task is to provide this corpus and to be responsible for all aspects of traffic simulation and evaluation. This task will also configure the server and communications environment required to mount a realistic prototype. This will include a basic EHR node with links to a representative set of health record sources. It will support the basic information updating and maintenance transactions, a pilot access control function and an initial set of service management and monitoring functions. To demonstrate how user requirements and policies are addressed at each client node. 5.2 EHR presentation tools The EHR environment must present consistent and appropriate interfaces to the different sorts of user involved in personal medical records. This task will propose and implement a set of user interface conventions and refine them in the light of user evaluation. To check the acceptability of the visual presentation. Explanatory materials, tools and demonstrations have to be designed to meet the specific needs of different types of user and interested party. In a number of cases, e.g. in information policy and security evaluation, the underlying

36 Heads of Agreement Durham EHR Version Final 20/10/00 structure and operation of the system must be presented for evaluation. In others, it is user functionality which is under scrutiny.

Work Description Much of the work in this package is of a detailed technical nature and will impinge on the operational environments of the health agencies involved in delivering this project. While the detailed technical approach depends on the outcome of the early phases of the project, the work is expected to adopt the following approach:  An initial technical environment will be established on the basis of dummy nodes, servers and databases. In the first instance this will not be connected to real world entities.  This experimental environment will be populated with some data, which has potential to become more and more realistic as the project matures, and will be instrumented to provide the means of observing and demonstrating structure and behaviour.  A framework for conducting tests and evaluations from both the technical and the user perspectives will be defined and refined through experiments and evaluation exercises.

Deliverables

An External Master Patient Index (EPI) capable of rationalising demographic information fed from acute, community, Mental Health and Social Services EPRs.

Simulation of batch feeds to this external Index from two representative systems, North Durham EPR and G.P.system using information provided from these systems in the first instance and actually receiving feeds if the project budget and timeframe permits.

Creation of Community Clinical Data Repository capable of receiving real time feeds from Acute, Mental Health and Social Services, and Community EPRs

Definition of four data content types using the work already done on Headings: e.g. Clinic Notes, G.P. letters and tests, X ray reports, Discharge summaries, Consultant letters, Lab Reports, Drugs and demographics.

We will be guided in this by the work done elsewhere in the project group to define content but as an initial thought would propose the following document types be trialed: Discharge summary from Acute EPR, End of Visit/referral from G.P., Radiology and Pathology results.

Simulation of transfer of these documents from originating systems to EHR. 37 Heads of Agreement Durham EHR Version Final 20/10/00

Definition and creation of message types between acute, mental health and social services, community and EHR in order to support communication between the systems for both the demographic and clinical information implicit in the preceding deliverables. This will be based upon information from existing systems so as to provide maximum value and correspondence to a “Real World” view and thus applicability.

Views into the EHR for two stakeholders: Initial proposal: e.g. G.P./Community Health professional look up and referral screens and A&E doctor look-up.

Definition, creation and demonstration of security models for two different system access types, informed by work done at Tees and by other collaborators in the Durham and Darlington project.

Additional areas to be explored:

Provision of links to third party data bases for dissemination of best practice, medical knowledge and other patient and clinical services.

Resource Requirements

Software

Sunrise Enterprise Patient Index Sunrise eWebIT suite eLink (Inegration engine) eView (Web integration toolset) eSign (composite application security toolset) Sunrise Clinical Manager Data Repository SQL server, Oracle and NT licenses Visual Studio Front Page development tools

For the purposes of this project for a two year license for use on the simulator only we will charge a nominal £1000 for each of the five Eclipsys Items concerned.

Human Resources

As a highly conservative estimate, 350 days Technical, Integration, Implementation and Clinical consultancy will be sufficient to support definition, construction, configuration, maintenance, testing and presentation/demonstration of all of the above. Accomodation and travel expenses will be met by Eclipsys. Our normal daily rate is between 650 and 750 per day plus expenses depending upon resource type. The resources focused on the ERDIP bid would ordinarily attract the higher rate.

Hardware

Servers sufficient to support the proposed configuration and permit a simulator capable of maintaining a sufficient quantity of data and transactions to provide a realistic assessment of future needs. Provisional estimate based upon twin DELL PowerEdge 4400 servers with dual processors.

Key Task Month nature of deliverable 5.1a 9 Content of EHR Simulator 5.1b 9 EHR Simulator 5.2a 9 Presentation tools 5.2b 21 User validation of simulator

Appendix 1 to Schedule B example workload for EPI Work Package 5 The following table provides an approximate estimate of the Tasks necessary to complete an implementation of the EPI for Passive Mode: TASK Task Detail Duration 1. Installation of Hardware  Server  1Day  Clients  ½ Day 2. Establish Remote  Installation of PC Anywhere /Telnet for  ½ Day Connectivity remote access support 3. Prep  Establish Goals  1Day  Project Flow/Definition  Data Element and Rules  Batch Extract 4. Installation and configuration  Installation of Oracle  1 Day of Software  Installation of EPI  1 Day

5. Definition and Creation per  DB building and End user Functionality  1 Day batch extract  Determine Sources, Data Elements  Determine initial Rule Set  System Admin.  Running a batch file  Emptympi  1 Day  Troubleshooting  Create Crystal Reports  Duplicate / Likely Report  100% Exact Match Report  Table Fields Report  Merge Report  Unmerge Report

6. Batch Extract – by Source  Documentation for creating standard  TBE batch file  Creation and testing of Batch Extract  1Week File 7. Interface Build  Real-Time Transaction I/F  Inbound to EPI from I/F engine  4 days  Outbound from EPI to I/F engine  4 days  Real time transaction testing  19 days

 Animation I/F  Animation spec visit  1 days  Animation development  35 days  Programmer test animated workflow  10 days  Animation functionality testing  10 days 8. Rules Analysis of Sample  Analyze rule set from Sample Batch file  1 Week Batch Extract  Modify rule set and re-run Sample batch file until best Rule Set determined. 9. Scrubbing of Source  Run full Batch file for source.  1-2 Implementation Complete  Analyze and determine best rule set. Weeks

NOTE: All estimates are based on one source and we are planning two sources for the simulator.

Schedule C - Individual Organisations Responsibilities

Detail contribution to work packages (material and human) and timetable milestones

Deliverables Responsible for Key month nature of deliverable delivery Task Proj Manager 1.1 1 Project Initiation Document Proj Manager 1.1 1 Project Plan Proj Manager/ 1.1 monthly Internal Progress Reports Consortium Board Programme 1.1 Quarterly External Progress Reports to Programme Manager/ Board/Project Board project mngr Programme 1.1 Quarterly Financial Control Statements to Programme Manager/project Board/Project Board mngr Project 1.1 as required Quality Assurance Reviews of deliverables Board/Project Team Project 1.1 as required deliverable sign-offs [Reports, Manager/Project implementations] Board Tech 1.1 3, and materials towards work package 2 [publicity team/Consortiu thereafter policy, briefing documents] m Board as required

Responsible for Key month nature of deliverable delivery Task Consortium 2.1 3 A communication strategy and Board implementation plan Project 2.2 3 A plan for the launch of the project and its Board/Consortiu related launch material m Board Tech 2.3 as Information leaflets, broadcast material, team/Consortium required articles, newsletters Board Ferrets/tech 2.4 to be Demonstration itinerary and material team/Consortium arranged Board

Responsible for Key month nature of deliverable delivery Task Architecture 3.1 3 a preliminary enterprise model and requirements team statement Architecture 3.2 6 an information model and ethical framework team Architecture 3.3 9 detailed data models, a detailed security model, and team evaluation criteria

Responsible for Key Month nature of deliverable delivery Task Architecture 4.1 3 Reference Model team Eclipsys 4.2 6 Proposed pilot environment Architecture 4.3 15 Overall definition of a national EHR environment team (draft) Architecture 4.4 24 Final EHR technical definition team/Eclipsys

Responsible for Key Month nature of deliverable delivery Task Architecture 5.1a 9 Content of EHR Simulator team Eclipsys 5.1 9 EHR Simulator Architecture 5.2 9 Presentation tools team Architecture 5.2 21 User validation of simulator team

Schedule D Third Party Responsibilities

There are two main areas that involve third parties and could affect the success of the project the first is liaison with other ERDIP pilots Tees, Cornwall and South Staffs. This area is outside the scope of the project but is required to ensure that there is not unnecessary duplication of effort in areas such as security and confidentiality.

The second area of third party responsibilities is the hardware platform suppliers for the simulator and demonstration system environment. The exact hardware configuration is still to be agreed and the supplier selected.

Schedule E Timetable

The milestones for the project are as follows:

Milestone Work Package & Description Date

1 WP 1 Heads of Agreement Document 19/09/00

2 WP2.1 Communication strategy and 19/12/00 implementation plan

3 WP3.1 preliminary enterprise model 19/12/00 and requirements statement

4 WP4.1 Reference Model 19/12/00

5 WP4.2 Proposed pilot environment 19/03/01

6 WP3.2 information model and ethical 19/03/01 framework

7 WP3.3 detailed data models, detailed 19/06/01 security model and evaluation criteria

8 19/06/01 WP5.1a Content of EHR Simulator

9 19/06/01 WP5.1b EHR Simulator

10 19/06/01 WP 5.2a Presentation tools

11 WP4.3 Overall definition of a national 19/12/01 EHR environment (draft)

12 WP5.2b User validation of simulator 19/06/02

13 WP4.4 Final EHR technical definition 19/09/02

The milestones are at 3, 6, 9, 15, 21 and 24 month intervals and will form the deliverables against the payment profile in Schedule G

Schedule F Acceptance of Work Packages

The acceptance of the work packages and therefore the milestone s and related payment profile will be accepted by the Project Board if they are complete and accurate against description in Schedule B

Schedule G Financial Obligations

Quantity Description 2 year Cost 1 Senior Research Assistant 89,416 0.5 Research assistant 29,924 1 Research assistant (Technical support) 59,924 0.5 Secretarial support 18,735 Eclipsys technical development 180,000 48 days SCHIN director involvement 24,000 0.5 Project Management 104,000 0.5 Dr Nick Booth 104,000 0.3 Mike Martin (CSR) 80,000 4 Presentation s/w licences & PCs 10,000 2 H/w servers 15,000 overhead budget(trg/travel, locum cover) 35,000 Total 749,999

Payment profile

The payment profile will from the NHSIA will be as follows:

Payment Amount(£ Product Description Due Date ’000) Ref

19/09/00 90 WP.1 Heads of Agreement Document (PID) 19/12/00 125 WP 4.1 Reference Model 19/03/01 125 WP 4.2 Proposed Pilot Environment 19/06/01 125 WP 5.1a Content of EHR Simulator 19/12/01 125 WP 4.3 Overall Definition of National HER environment (draft) 19/06/02 125 WP 5.2b User validation of Simulator 19/09/02 35 WP 4.4 Final EHR technical definition

Schedule H Change Control Procedures Standard NHS change control procedure shall apply to this contract.

H1 Principles 1.1 Where the Authority or the Contractor, during the implementation of the Contract, see the need for change (which term includes modification) to system interfaces, inputs, outputs, loads, functionality or to the way the system is implemented, the Authority may at any time request, and the Contractor may at any time recommend such change and propose an amendment to the Contract in accordance with the formal Change Control Procedure (CCP) as set out at paragraph 2. 1.2 Neither the Authority nor the Contractor shall unreasonably withhold its agreement to any change. 1.3 Unless the Authority and the Contractor otherwise agree in writing, there shall be no presumption that the obligations undertaken by either party in connection with the Contract are in any way changed until the Contract has been effected in accordance with the CCP. 1.4 No amendments to the Contract shall be valid unless they have been agreed in writing by or on behalf of the Project Manager, on behalf of the Authority and by the Contractor.

H2 Procedures 2.1 The Authority and the Contractor shall discuss changes proposed by either party and such discussions shall result in either: 2.1.1 Agreement not to proceed further, or 2.1.2 In a written request for a change by the Authority, or 2.1.3 A recommendation for a change by the Contractor. 2.2 Where a written request for a change is received from the Authority, the Contractor shall, unless otherwise agreed, submit a Change Control Note (CCN) to the Authority within three weeks. 2.3 A recommendation for a change by the Contractor shall be submitted as a CCN direct to the Authority at the time of such recommendation. 2.4 Each CCN shall contain: a) the title of the change b) the originator and date of request or recommendation for the change c) reason for the change 49 Heads of Agreement Durham EHR Version Final 20/10/00 d) full details of the change including any specifications and user facilities e) the price, if any, of the change f) a timetable for implementation together with any proposals for acceptance of the change g) a schedule of payments if appropriate h) the impact, if any, of the change on other aspects of the Contract including but not limited to:  milestones  the overall contractual timetable  project implementation plan  the Contract Price/Contract Charges  overall payment schedule  documentation list  resources  contractual issues  serviceability and performance levels  system configuration including store utilisation  throughput  resilience I) the date of expiry of validity of the CCN j) provision for a signature by the authority and by the Contractor. 2.5 For each CCN submitted, the Authority shall, within the period of the validity of the CCN: 2.5.1 allocate a sequential number to the CCN 2.5.2 evaluate the CCN and as appropriate either a) request further information, or b) notify the Contractor of the rejection of the CCN 2.5.3 arrange for two copies of an approved CCN to be signed by or on behalf of the Authority and the Contractor

PROJECT: CHANGE CONTROL NOTE

Originator Unit/Location Date: Reference

Validity:

Title of change:

Reason for change:

Description of Change:

Impact Assessment

Signature/Approval Block Name: Name: Name: Name:

Position: Position: Position: Position:

Date: Date: Date: Date:

Signature: Signature: Signature: Signature:

Schedule I – Copyright and Intellectual Property Rights

Work packages 1 - 4

The NHSIA

Work package 5

ECLIPSYS Ltd will retain the rights to the simulator software developed by them using their own software tools and other products.

The NHSIA and the NHS organisations in County Durham will have the right to use this software for simulation and demonstration purposes to any audience, without further payments to ECLIPSYS.

54 Appendix 1 to Schedule A - Scope North Durham South Durham

GP Systems TOREX MEDITEL EMIS Practice(s) to Bishopgate Medical be agreed Centre

North Durham South Durham Trusts Health Care Health Care

CAMIS OP Appointments MDIS OP Attendance Discharge Summaries Discharge Summaries Radiology Results ECLIPSYS EPR A&E Discharge letter IIntegration Engine FOOTMAN WALKER REAL SOFTWARE Pathology Results A&E Discharge letter STC Integration Engine Durham County Priority Services Unit

PIMS Care Plans, OP Appointments and Discharge Social Services SSIDSummaries OP Appointments Care Plans Discharge SummeriesOP

HA EXETER Patient demographics

NHS Strategic SEMA Group Tracing Service Look up NHS numbers

Access EHR NHS Direct Referrals to primary care Referrals to secondary care

Conceptual View The diagram modifies and extends the schema described in Information for Health. Communications between EPRs and the local EHR, (and between EHRs), would require the definition and development of appropriate gateways. Appendix 2 Project Forms

Appendix 2 Project Forms

I. Trust Project Report Project [Name] Report Report to Project Board Report Date

Project Manager [Name] Executive Rôle [Name] User Rôle(s) [Name] Technical Rôle(s) [Name]

Project Update Current Activity [milestones achieved since last report (always attach milestone log), deliverables delivered since last report (attach any sign-offs required), next activities]

Exceptions

Issues [Only those you wish to highlight to Project Board] Always attach the Issues Log.

Change Controls [attach any change controls - only include if you want Board to sign]

Project Team (attach Project Team minutes) Appendix 2 Project Forms

Other information (attach other documentation if appropriate) II. Project milestone status report

Mileston Planned Status Revised Reason for Agreed e date Delay Action Date