GP2GP Pid101

GP-GP Record Transfer - Project Initiation Document
GP-GP Record Transfer
Project Initiation Document
Information for Personal Health
1
Purpose of this document
To describe GP2GP Project in a manner which meets

the needs of the NHSIA and the HIRI Consortium. It
explains the objectives of the project, its scope, the
approach adopted, the strategic context, and
interfaces with other Information for Health initiatives.
It summarises the resources needed and the plans for
the first stage of the work. The proposed
arrangements for managing the project are presented.
Distribution Senior Management ,

GP2GP Project Board
Key Stakeholders
Author NHS Information Authority
Further copies Aqueous II,
from Waterlinks,
Aston Cross,
Rocky Lane,
Birmingham, B6 5RQ
Tel: +44 (0) 121 333 0333
Fax: +44 (0 121 333 0334
E-mail:
helpdesk@nhsia.nhs.uk
Date of issue October 2001
Revision Version 1.0
History Version 1.01
© Crown Copyright 2001

Published by the NHS Information Authority.
2
1. INTRODUCTION 5
1.1. Purpose of this document 5
1.2. Background 5
1.3. Mandate and Project Brief 7
2. PROJECT DEFINITION 8
2.1. Purpose of the Project 8
2.2. Scope 8
2.3. Objective 8
2.4. Deliverables 8
2.5. Interfaces 9
3. ORGANISATION 10
3.1. Project Management Structure 10
3.2. Health Informatics Research International Ltd (HIRI) 11
3.3. Interfaces with Programme Management 11
4. PLANS 12
4.1. Project Plan 12

4.1.1. Start-up / Initiation Stage 12
4.1.2. Development Stage 12
4.2. Quality Plan 14

4.2.1. Approach to Quality Assurance 14
4.2.2. Responsibilities 14
4.2.3. Standards 14
4.2.4. Product Quality Criteria 14
4.2.5. Change Management 14
4.2.6. Configuration Management 15
4.2.7. Validation teams 15
4.2.8. Project assurance 15
4.3. RESOURCES & TIMESCALES 17

4.3.1. Budget 17
4.3.2. Timescales 17
4.4. PROJECT CONTROLS 18

4.4.1. Checkpoint Meetings/Reports 18
4.4.2. Work Package Management 18
4.4.3. Highlight Reports 18
4.4.4. Exception Reports 18
4.4.5. End Stage Assessments 18
3
4.4.6. Mid Stage Assessments 18

4.4.7. Project Closure 18
4.4.8. Change/Issue Management 18
4.4.9. Tolerances 19
5. RISKS 20
5.1. Constraints 20
5.2. Assumptions 20
5.3. Initial Risk Assessment and Outline Contingency 20
APPENDICES 22
Appendix A, Product Descriptions 23

Product Description for M1: Project Initiation Document 23
Product Description for M2: Progress Reports 24
Product Description for S1: Specification of a general message and list of issues 25
Product Description for S2: Specification of a text based record transfer 26
Product Description for S3: Specification of a partially structured record transfer 27
Product Description for S4: Specification of a fully structured record transfer 28
Product Description for S5: Specification of supporting mechanisms and messages 29
Product Description for S6: Skills transfer to the NHSIA 30
Product Description for S7 Final Project Report 31
Product Description for Q1: Validation team reports 32
Appendix B, Notes of Project Organisation and Roles 33
Appendix C, NHS Information Compliance Statement 38
Appendix D: IPU Commissioning Brief 40
Appendix E: NHSIA Business Case 42
Appendix F: Glossary 52
Notes on Appendices 54
4
1. INTRODUCTION
1.1. Purpose of this document
The purpose of this document is to define the GP-GP Record Transfer Project in order to form the
basis for the management and assessment of the success of the project.
This document will allow the Project Board to ensure the project has a sound basis before allowing
major decisions to be made which may alter significantly the overall aims of the project. It will act
as a base document against which the Project Board and Project Manager can assess progress,
change management issues, and on-going viability issues.
1.2. Background
GP to GP Record Transfer Project is one of a series of messaging projects within the Clinical
Communications work area within the Information for Personal Health delivery area of the NHS
Information Authority.
In 2001 an estimated 96% 1 of GPs held at least part of their patient records electronically, with
10% being paperless and a further 24% having a full electronic record with paper records as a
backup.
Every year an estimated 10% of patients change their registered GP to a new GP in another
general practice in the UK. With an average list size of 1700 and an average 3 GPs per practice
this amounts to over 500 transfers per practice annually. When this occurs, there is a well known,
effective mechanism for the transfer of the paper record (Lloyd George envelope or medical record
envelope, MRE) detailing the patient’s past care. There is no provision for the transfer of any
electronic component of the patient record
In order to transfer the electronic component of the patient record, common practice is to produce
a printout of the content of the medical record and to put it in the Lloyd George MRE at de-
registration. Anecdotal evidence is that few doctors study such printouts and that even fewer re-
enter any salient information so that it is available to assist future care. Thus, the increased use of
electronic records by GPs to improve the care of their patients has the paradoxical effect of
reducing the quality of the patient record passed to future GPs.
The EPR and EHR paradigm cannot exist without a reliable method of transferring electronic
patient records from a GP at one practice to a GP at another.
The project will build on work undertaken in three recent areas:
The Textbase Project
This research was carried out by a partnership including the Sowerby Centre for Health
Informatics and the then four leading GP system suppliers AAH Meditel (now Torex Meditel) EMIS,
In Practice Systems and Torex (now Torex Meditel).
1
”Report on awareness of PRODIGY amongst GPs in England” Produced for DOH by Sowerby Centre for
Health Informatics, Newcastle University.
5
It was viewed as a pragmatic first step towards GP to GP transfer, aiming to establish a base level
message supporting EPR 2 transfer. The research was carried out in a laboratory environment,
using record with date & text entries being organised within these structures using HTML, and
transmitted using EDIFACT syntax. There was no encryption.
Three processes were evaluated:

• Generation of an outgoing message
• Process of an incoming message
• Display of processed message from a different EPR
The XML EPR Project
This study was carried out by the Royal College of General Practitioners in 1999. The principle
objective of the project was to enable professional validation of a working draft of the Provide
EHCR message 3. The work described in this report involved technical and clinical validation
involving four major GP systems suppliers and a group of clinical professionals representing the
RCGP. The suppliers populated instances of the message in the Extensible Markup Language
(XML) syntax and these were displayed for scrutiny by a team of clinical professionals.
A number of conclusions were made in particular:
• The Provide EHCR message is substantially able to convey the information present in a
majority of existing GP Electronic Patient Records in England and Wales
• Clear and unambiguous implementation guidance will be essential for effective use of the
Provide EHCR message for GP to GP transfer of patient records within the NHS.
• The potential for automated support for implementation guidance, offered by particular
approaches to the use of XML, should be evaluated, with a view to the adoption of such
techniques.
CEN TC251 ENV 13606
The Comité Européen de Normalisation Technical Committee 251 (CEN TC251) was responsible
for the ENV13606 pre-standard which has four parts:
• Part 1: Architecture
• Part 2: Domain term list
• Part 3: Distribution rules
• Part 4: Messages for exchange of information
All part have relevance to messaging, but especially Part 4, which specifies a number of
messages for requesting, acknowledging and responding to message requests.
Work is currently going on to harmonise all CEN work with that of Health Level 7 (HL7).
This document sets out the management environment for the next part of the GP-GP Record
Transfer Project.
2
Within these studies EPR refers to a generic electronic record and does not necessarily have the same
meaning as EPR in Information for Health
3
This message for healthcare record communication was the subject of a formal Request for Comments
from the European standards body CEN TC251
6
1.3. Mandate and Project Brief
The mandate for this project was established by the NHS Information Strategy “Information for
Health4”.
Information for Health includes electronic transfer of patient records between GPs as one of the
four targets for longer-term implementation, by March 2005. This is one element of a wider
availability of the Electronic Health Record shared across care sectors, subject to appropriate
security.
From 1st October 2001, GPs are allowed to keep electronic records. The agreement from the
General Practitioners Committee was dependent upon the establishment of a mechanism for GP-
GP record transfer.
GP to GP electronic transfer has been identified as a first priority work within National Standards.
The business case approves by the NHS Information Authority Board is included in Appendix E
4
Information for Health, An Information Strategy for the Modern NHS 1998 – 2005, NHS Executive
September 1998, Page 34
7
2. PROJECT DEFINITION
2.1. Purpose of the Project
To develop a validated electronic record transfer mechanism for transferring data between GP
software systems electronically, and thereby contribute to improving the quality and continuity of
care.
2.2. Scope
The scope of the project is identified in the table below.
The Project Includes:
• A review of issues relating to text-based record transfer and specification

• Partially structured message specification
• Fully structured message specification
• Routing and supporting messages
• Involvement of stakeholders
• Demonstration and validation
• Skills transfer to the NHSIA
• Full documentation of all message specifications
The Project Excludes:
• Piloting of the proposed GP2GP Message

• Implementation of the proposed GP2GP Message (this is to be addressed in the NHSIA
business planning for 2002/3 – a bid for funding for an implementation scoping project has
been submitted)
2.3. Objective
The objective agreed for the GP-GP Record Transfer project is by March 2003: To make available
to the NHS Information Authority tested tools to support the clinical, technical and organisational
requirements for GP-GP Record Transfer, to the satisfaction of the main professional and
regulatory bodies within the NHS.
2.4. Deliverables
The principal specialist products (Appendix A) will be:
• Main project report for the programme board (S7)

• Specification of a general message and list of issues (S1)
• Specifications for text based patient record transfer (S2)
• Specifications for partially structured patient record transfer (S3)
• Specifications for fully structured patient record transfer (S4)
• Specifications of mechanisms and messages to support the flow of patient record messages
between practices (S5)
• Skills transfer to the NHSIA (S6)
8
Quality Assurance, Consultation, Education (including skills transfer) and Communication

Products:
• Summary reports: Findings and conclusions from the validation teams (Q1)
Management products include:
• Project Initiation Document (M1)

• Monthly progress reports (M2)
Detailed Product Descriptions are provided in Appendix A
2.5. Interfaces
The GP-GP Record Transfer project is not dependent upon the results of other projects for its
completion. However, interfaces with other work will be important issues for implementation. Any
issues raised in the GP –GP Record Transfer project which have impact on other projects or vice-
versa should be escalated via the Senior Supplier David Robinson in his NHSIA role of Content
Program Co-ordinator.
Relevant areas include:
! ERDIP
! Clinical communications programme
! Headings
! Context of care
! Exeter systems
! Security and confidentiality
! Clinical connect
! Ways of working
Previous GP-GP Record Transfer work has contributed to the emerging International records
standards. This will be of relevance if the UK accepts European standards as a basis for the
development of clinical systems. The implications of specific strategic developments in other areas
must also be considered. Particular attention will be paid to:
! SNOMED Clinical Terms

! HL7
! ISO TC 215
! CEN TC 251
! eGIF
It is important that the implications of these developments are taken into account during the GP-
GP Record Transfer development phase, to ensure that it is feasible to implement GP-GP Record
Transfer within environments utilising these technologies.
There will be major implications for Education Training and Development, and culture change.
Organisational change and team and individual learning needs identified will:
! Also affect other Information for Personal Health projects

! Need to be embedded within mainstream education activity
! Indicate requirements for implementation
9
3. ORGANISATION
3.1. Project Management Structure
The project management structure for the GP-GP Record Transfer Project is identified below.
This board sits under the Clinical Communications Programme Board. Notes on the project
organisation (PRINCE 2) and role descriptions are included in Appendix B.
GP to GP Record Transfer Project Board Structure:
Role Name Organisation
Executive Dr Philip Brown NHS Information Authority
Senior Suppliers Dr David Robinson NHS Information Authority

Glynn Johnson
Senior Users Paul Woolman Glasgow Royal Infirmary
Dr John Nicholas Teesside
Other roles
Project Manager To be confirmed
Business Judith Emberson NHS Information Authority
Assurance
Clinical Communications Programme Board Structure:
Role Name Organisation
Executive Michael Thick NHS Information Authority
Senior Suppliers Dr David Robinson NHS Information Authority

Carrie Armitage NHS Information Authority
Senior Users Dr Jonathon Kay Pathologist, Oxford
Simon Old Information Policy Unit
Merlyn Wilcox General Practitioner, Birmingham
CSSA (to be
confirmed)
Other roles
Project Manager To be confirmed
10
3.2. Health Informatics Research International Ltd (HIRI)

The HIRI consortium was awarded the contract to deliver a mechanism for GP to GP Record
Transfer following an OJEC procurement process.
The core members of the team are:
• Professor Ian Purves (Sowerby Centre for Health Informatics at Newcastle)

• Dr Leo Fogarty (independent health informatics consultant)
• Dr David Markwell (the Clinical Information Consultancy)
• Dr Andrew Perry (the Clinical Information Consultancy)
• Charles McCay (Ramsey Systems Ltd)
Members of the team have been involved in a number of initiatives relating to the for GP to GP
Record Transfer Project including:
• The Textbase Project

• The XML EPR Project
• CEN TC 251 ENV 13606
• HL7 and HL7 UK
3.3. Interfaces with Programme Management
The GP-GP Record Transfer Project is regarded as a category 4 (reporting 4 weekly) project. This
project sits within the NHS Information Authorities Information for Personal Health. The extent of
project reporting within this programme will follow the NHS Information Authority’s PRINCE
guidance.
The GP-GP Record Transfer Project should maintain relationships with:
NHS
Information
Authority Information
Board Standards Board
Information for Clinical

Personal Health Communications
e.g. SNOMED-CT, Programme Board
UKCPRS
Oncoming Pathology GP2GP HIRI

Messaging Messaging Project Board
Projects
11
4. PLANS
4.1. Project Plan
A staged approach is being adopted for the GP-GP Record Transfer Project. Key activities for
each stage are listed below. Major products for each stage are listed under "Deliverables" in
section 2 of this PID.
4.1.1. Start-up / Initiation Stage
During this stage, the main activities to be undertaken comprise:
• Familiarisation of the team with current background documentation

• Producing a Project Initiation Document (PID) for the project
• Gaining Project Board approval for the PID
4.1.2. Development Stage
During this stage, the main activities will comprise:
• Revising the GP-GP Record Transfer framework

• Preparation for testing and evaluation
Identified work and deliverables (full descriptions in Appendix A) include:
Stage 1
A review of projects and their products in light of professional principles, which guide the keeping
of electronic patient records in UK General Practice and the operational requirements for transfer
of these records between practices
Deliverable: S1
Stage 2
Development of text-based message structures, based on the output of the Text-base Project.
.
Deliverable: S2
Stage 3
Development of partially structured message structures, to the level of the ‘composition’ within the
CEN TC251 pre-standard ENV 13606
Deliverable: S3
12
Stage 4
Development of fully structured message structure, based on ENV13606, in HL7 Version 3 format.
Deliverable: S4
Stage 5
In parallel, specification of supporting mechanisms and messages, including requesting,

acknowledgement and notification.
Deliverable: S5
Stage 6
In parallel skills transfer to the NHS Information Authority including specific training events and
direct involvement in meetings.
Deliverable: S6
13
4.2. Quality Plan
4.2.1. Approach to Quality Assurance
Internal product reviews will be performed where appropriate, via independent checks of
documents performed by the reviewer. Comments will be collated and resolved by the Project
Manager. Approval will be provided by the Project Board on the basis of a review of the document
and the comment / action list.
4.2.2. Responsibilities
Project and quality assurance responsibilities are identified in the Role Descriptions provided in
Appendix B.
4.2.3. Standards
The project complies with current NHS Information Authority standards. A compliance statement
is included in Appendix C.
The Information Authority compliance statement will be copied to The Clinical Data Standards
Board.
4.2.4. Product Quality Criteria
Quality criteria for products are described in the relevant Product Descriptions in Appendix A.
4.2.5. Change Management
Changes to project deliverables once approved will be authorised by the Authority identified in the
Product Descriptions.
Changes to the project objectives, constraints, and product descriptions will be agreed by the
Project Board.
14
4.2.6. Configuration Management
Version control will be applied to all key project document deliverables, as identified in the list of
Product Descriptions included at the end of this document.
The NHS Information Authority will maintain definitive copies of all Project deliverables.
Project filing will be held electronically where available and as paper copies.
The structure will be:
\Phase ...
\Control
\Correspondence
\Daily Log
\Organisation
\Plans
\Project
\Business Case
\Control
\Organisation
\Plans
\Risk Log
\Quality
\Lessons Learned
\Prod Descriptions
\Project Issues
\Quality Checks
\Specialist
\Correspondence
\Planning
\Products
4.2.7. Validation teams

The work contracted from the HIRI consortium includes three independent validation teams. These
teams will involve clinicians meeting the following criteria:
• Currently or recently practising

• Independent from the development
• Understanding of terminology and context
4.2.8. Project assurance
Project assurance will be undertaken from within the NHSIA. The Clinical Communications
Programme is in the process of establishing a project assurance team to cover all projects within
the programme. Representation of the following areas will be included:
• Clinical
• Technical
15
• Standards
• Management
• Security
• Stakeholder relations
• Ways of working
16
4.3. RESOURCES & TIMESCALES
4.3.1. Budget
£420,700 has been allocated to the HIRI Consortium between June 2001 – March 2003 for work
on behalf of the NHSIA.
The NHSIA will release staff as required to attend project meetings or to facilitate the required
skills transfer.
0.5 whole time equivalent will be made available for project management and support.
4.3.2. Timescales
The table below identifies the key timescales for the project, in terms of stages and completion of
major deliverables.
The timescales for the lower level deliverables are heavily dependent on the activities preceding
them, in particular stakeholder co-operation. The project manager and the HIRI consortium will ask
the board for approval of activities leading to lower level deliverables on a three monthly basis.
Stage 1 Deliverable Start Finish

A review of projects and their products S1 01/06/01 01/12/01
Stage 2
Development of text-based message structures S2 01/06/01 01/12/01
Stage 3
Development of partially structured message structures S3 01/06/01 01/06/02
Stage 4
Development of fully structured message structures S4 01/06/01 01/12/02 *
Stage 5
Specification of supporting mechanisms and messages S5 01/06/01 01/09/02
Stage 6
NHSIA skills transfer S6 01/06/01 01/06/03
A formal Project Plan using Microsoft Project (including Gantt chart) will be presented at each
Project Board meeting, identifying actions completed and areas of slippage.
* May be brought forward as a result of initial meeting with suppliers.
17
4.4. PROJECT CONTROLS
4.4.1. Checkpoint Meetings/Reports
The Project Manager will provide monthly reports and additional informal checkpoint reports as
required.
4.4.2. Work Package Management
Formal work package management is not being used, as a small team is undertaking the project
and work packages are simple in nature.
4.4.3. Highlight Reports
Highlight reports will be provided by the Project Manager on a quarterly basis to the Information for
Personal Health Programme Board, and subsidiary programme boards, and copied to the Project
Board. Highlight reports will also be circulated prior to Project Board meetings.
4.4.4. Exception Reports
Exception Reports will be generated if the Project Manager forecasts that the tolerances agreed
for any Stage, or the Project, will exceed those agreed with the Project Board, Information for
Personal Health Programme Board or any subsidiary programme boards.
4.4.5. End Stage Assessments
End Stage Assessments will be undertaken at the end of each Stage, and will be supported by the
key deliverables of each Stage.
4.4.6. Mid Stage Assessments
Mid Stage Assessments will be held in the event that an Exception Report needs to be presented
to the Project Board, Information for Personal Health Programme Board or any subsidiary
programme boards.
4.4.7. Project Closure
A final project report (S7) will be provided at the end of the project.
4.4.8. Change/Issue Management
All issues raised will be recorded by the Project Office in the Issue Log, and copied to the
Assignment Manager. The Project Manager will ensure issues are actioned appropriately during
the project, and any remaining issues outstanding at Project Closure are catered for in the Follow-
On Action Recommendations Report.
18
4.4.9. Tolerances
The Project Manager is required to raise an Exception Report for the attention of the Project Board
if it is anticipated that the project cannot be completed within 1 month of the scheduled date, or if it
is forecast that the project budget will be exceeded by 5%.
An Exception Report will be provided by the Executive of the Project Board to the Information for
Personal Health Programme Board, or subsidiary programme boards as appropriate, in the event
that it is forecast that tolerances agreed with the Information for Personal Health Programme
Board will be exceeded.
19
5. RISKS
5.1. Constraints
The GP-GP Record Transfer project is being initiated at a significant and early stage in the
development of the NHS Information Authority. This has a significant impact upon the project in
that the management and operational systems of the authority are in the process of development.
There are gaps in these procedures where interim solutions need to be found or new guidance
sought and this may have an impact upon the project timescales and costs.
5.2. Assumptions
The nature of all of the dependencies and interfaces cannot be established in detail at the point of
initiation. The development of important parts of the overall clinical information management
infrastructure and consequent guidance is at an early stage. This PID and project plan may need
to be amended in the future to take account of subsequent guidance. It is the responsibility of the
programme board to provide direction and guidance about interfaces and their impact.
The Project is being undertaken on the basis of a number of assumptions:
! Suitable NHS Information Authority resources are available within the time-scales
! That the assumptions in the Business Case are still valid
5.3. Initial Risk Assessment and Outline Contingency
The table below indicates risks identified to date, together with the corresponding management
actions:
20
Initial Risk Log
No. Summary Probability Severity Importance 5 Countermeasures 6 Status 7

(P x S)
1 State of willingness of system 3 3 9 Appropriate measures identified by

suppliers to co-operate is low NHS to ensure co-operation. These
would include consultation with e.g.
Primary Care Branch, RFA
2 A critical flaw is found in the clinical 1 3 3 Ensure that if critical difficulties are
requirement part way through the encountered, these are identified and
project reported at once.
3 A conflict between the suppliers 1 3 3 Ensure that if critical difficulties are
and the validation process is encountered, these are identified and
identified reported at once.
4 A critical dependency on another 1 3 3 Ensure that the programme strategy
project is identified is clear to everyone contributing to
the project. Ensure that where key
dependencies are discovered, these
are reported at once.
5
Probability / severity scored 1 (low) 2 (medium) 3 (high). Specific actions must be identified where Importance (= Probability x Severity) > 3.
6
Countermeasures should detail explicitly how risks are addressed.
7
Identified / Accepted / Superseded / Transferred / Avoided / Reduced / Occurred / Contingency Plan invoked - note categories are not mutually exclusive.
21
APPENDICES
22
Appendix A, Product Descriptions
Product Description for M1: Project Initiation Document
Purpose To define the project, to form the basis for its management, and the
assessment of overall success
Composition As defined in PRINCE 2 manual, to comprise:

• Background
• Project definition
• Assumptions
• Initial business case
• Project organisation
• Quality plan
• Initial project plan
• Project controls
• Exception process
• Initial risk log
• Contingency plans
• Filing structure
Derivation • Business case

• Project mandate
• HIRI consortium proposal
Quality Criteria • Correctly represents project

• Shows viable, achievable project in line with Strategy
organisation structure complete, with all roles considered, and
backed up with agreed job descriptions
• Clear and appropriate control, reporting and direction regime,
which is in line with scale, risk and importance of the project, and
meets the needs of the Project Board, Project Manager and
Team Leaders
• Clear relationships, lines of authority, and assignment of
responsibility
Type of Quality Check Approval by the project board

required
People / Skills required Project Manager
Format and MS Word, PDF (in standard NHS Information Authority format),
Presentation
23
Product Description for M2: Progress Reports
Purpose To inform the project board and the project manager of the activity of
the HIRI consortium on a monthly basis
Composition • Current activity

• Proposed activity in the next month
• Exceptions
• Issues
• Change controls
• Budget status
• Milestones status report
• Identification of:
• education and training needs
• issue that may have implications for dependencies and
wider programme management
• additional risks
Derivation HIRI consortium
Quality Criteria • Identifies problems

• Allows project board to escalate issues to programme level if
necessary
• Allows project board to anticipate final results and where
necessary identify resources to meet gaps in the project work
programme
Type of Quality Check Review by the project manager, with escalations to the project board
required
People / Skills required HIRI consortium
Format and MS Word, (format agreed between HIRI and NHS Information
Presentation Authority)
24
Product Description for S1: Specification of a general message and list of issues
Purpose To provide an outline patient message structure and guidelines for

review in consultation with stakeholders.
Composition Documentation of a general outline message structure for patient

record transfer
• A simple logical data model (following the conventions of UML)
• An XML Document Type Definition/Schema conforming to this
model
An initial set of guidelines
• Guidelines on how the general attributes of the initial outline
message should be populated with data.
• General aspects of system functionality concerned with the
creation and sending of GP electronic record messages.
• General aspects of system functionality concerned with the
receipt and integration of GP electronic record messages.
• General aspects of conformance testing and system
accreditation section
An initial list and plans for resolution of these issues relating to
• The data model
• Routing of data flows
Derivation • Review of previous projects

• Consultation with stakeholders
Quality Criteria • Completeness

• Accuracy
• Usability
Type of Quality Check Review by the project board and project assurance team
required
People / Skills required HIRI Consortium
Format and Textual documents in MS Word, PDF (in standard NHS Information
Presentation Authority format),
25
Product Description for S2: Specification of a text based record transfer
Purpose To present clearly laid out text from transferring systems for reading
by a receiving system.
To consider:
• Headings
• Technical standards
• Dynamic manipulation of text
Composition Documentation of each of the supporting messages

• UML logical data model
• XML Document Type Definition/Schema
• Specification of the technical structure of the text layout
• Specification of use of headings in the message
• Specification of limits on permissible formatting by receiving
system
• Sample messages
• XSLT Stylesheet to validate partially structured message
• XSLT Stylesheet to degrade partially structured message
Guidelines for text based message use
• Generation of a fully structured record message
• Access to and viewing and integration of received message
• Use of the text based record message by practices
Derivation • Review of previous project


• Accuracy
• Usability
required
26
Product Description for S3: Specification of a partially structured record transfer
Purpose To use some of the elements of international standards for patient

record architectures.
To consider:
• Agreement on structural elements
• Specification of a representation of the structure that is:
• Compatible with ENV 13606 and HL7 RIM
• Degradable to text based form
• Implementable without changes to architecture

• Specification of the technical structure of the text layout
• Specification of use of headings in the message
• Specification of limits on permissible formatting by receiving
system
• Sample messages
• XSLT Stylesheet to validate partially structured message
• XSLT Stylesheet to degrade partially structured message
• Use of the text based record message by practices
Derivation • International standards


• Accuracy
• Usability
required
27
Product Description for S4: Specification of a fully structured record transfer
Purpose To use some of the elements of international standards for patient

record architectures to provide a fully structured message.
To consider:
• General aspects of data structure based on ENV 13606 and HL7
• Terminology including Clinical Terms and SNOMED Clinical
Terms
• Headings
• Context

• Specification of naming conventions
• Specification of types of degradation
• Sample messages
• XSLT Stylesheet to validate fully structured message
• XSLT Stylesheet to degrade fully structured message
Guidelines for fully structured message use
• Use of the fully structured record message by practices
Derivation • International standards

• Accuracy
• Usability
required
28
Product Description for S5: Specification of supporting mechanisms and messages
Purpose In parallel with message specification the issues of routing the

messages and the additional messages necessary
To consider:
• Requesting transfer
• Authentication of requests
• Notification of transfer
• Acknowledgement of receipt

• XML DTD for each message
• Relationship between the fully structured message and the
general outline message
• Specification of code list or value ranges for elements
• Sample messages
• XSLT stylesheets to validate each message
Specification of the routing mechanisms and functional requirements
• Documentation relating to routing and handling of messages by
third party systems
• Documentation of necessary extensions to the Specification of
Clinical EDI Functions for GP Computer systems
• Generation and sending messages
• Receiving and responding to messages
Derivation • Review of current processes

• Accuracy
• Usability
required
29
Product Description for S6: Skills transfer to the NHSIA
Purpose To ensure the NHS is able to take forward the outcome of the project
Composition Areas of knowledge to include:

• XML
• International standards
• Clinical informatics principles
• Security
Derivation Methods of skills transfer to include:

• Direct involvement
• Specific training events
• Training for conformance testers
• Dissemination of documentation

• NHSIA skills
required Feedback from NHSIA participants
30
Product Description for S7 Final Project Report
Purpose To present the findings, conclusions and recommendations of the

project, to the project board
Composition • Background
• Introduction
• Summary of Methods
• Summary of Findings
• Conclusions
• Recommendations
Derivation Review of:

• Project reports
• Deliverables
• Board meetings
• Skills transfer
• Stakeholder consultations
Quality Criteria • Correctly represents outcomes of the project

• Confirms the status and conditions for submission of the
information standard
• Summarises the ways in which GP-GP Record Transfer has
been derived, tested, evaluated and the significance of the
results of the validations
• Recommends appropriate steps for the piloting and
implementation plans
• Recommends areas for evaluation and monitoring of the
standard in use
required
People / Skills required Project manager
Presentation
31
Product Description for Q1: Validation team reports
Purpose Demonstrate professional and technical validation of demonstrations

by suppliers
Composition Results of validations conducted in laboratory conditions between 2

– 4 suppliers .
Derivation Methods of skills transfer to include:
• Direct involvement
• Specific training events
• Training for conformance testers
• Dissemination of documentaion

• Accuracy
Type of Quality Check Review by the project board

required
People / Skills required To be sub-contracted by the HIRI Consortium
Clinical professionals:
• Currently or very recently practising GPs
• Not otherwise involved in development
• Adequate understanding of clinical informatics issues
Presentation
32
Appendix B, Notes of Project Organisation and Roles
PROJECT ORGANISATION
The following considerations apply to Project Organisation:
a) The Project Board should be small i.e. normally three but no more than six persons
b) Role Descriptions should be provided for each role
c) The Executive should be selected with specific reference to their responsibility for delivering
the business justification for the project
d) The Senior Supplier(s) should be selected with specific reference to their responsibility for
ensuring the feasibility of proposals for development, implementation and maintenance. They
should have the authority to commit additional resources. Examples of suitable candidates
are:
• An NHS Information Authority manager with responsibility for the Authority staff
undertaking the project, or who is responsible for the future implementation or
maintenance of the end-product
• The Assignment Officer, where external consultants are undertaking the work in a
“study” type project
• A manager from an external supplier organisation, where that organisation is making a
substantial or complex contribution to the project e.g. with a major IT development or
PFI service provider
e) The Senior User(s) should be appointed, with specific reference to their responsibility for
ensuring user needs are met
f) Where a project is one of a series of projects e.g. a scoping study for a programme of change,
the Senior User needs to take account not only of the immediate customer of project (i.e. the
audience for the scoping report), but also the users who will be impacted downstream by any
subsequent implementation
g) Where more than one Senior Supplier or Senior User is identified, indicate how
responsibilities are divided
h) Note that there is no reason why other individuals may not be appointed to / attend the
Project Board if this will contribute to the project e.g. a Technical Advisor may be appropriate
where a project wishes to receive specialist advice independent from the supplier
i) Note that Project Assurance is the responsibility of Project Board members – this may need to
be delegated to additional individuals as follows:
• business assurance, to support the Executive
• user assurance to support the Senior User(s)
• specialist assurance to support the Senior Supplier
j) An Assignment Officer needs to be identified in any project where external consultants are
used cf.: the IMG publication Guidance on Employing Consultants (1998)
33
k) Where external consultants are used, a decision is required as to whether the Project
Manager should be an NHS Information Authority employee. In this case the lead external
consultant will be performing the role of a Team Leader, responsible for the production of a
set of specified products. Alternatively, the external consultants may provide the Project
Manager, who will then need to liaise with an NHS Information Authority Assignment Officer
l) The source of any project support should be indicated
The Configuration Librarian is responsible for maintaining reference copies of all project
deliverables. Where this is nor an NHS Information Authority employee, the need for NHS
Information Authority to retain definitive copies of all products for reference and audit
purposes will need to be catered for.
34
ROLE DESCRIPTION
Role: Executive
Name: Dr Phillip Brown
Prime responsibility: The Executive is ultimately responsible for the project,

supported by the Senior User and Senior Supplier. The
Executive has to ensure that the project is value for money,
ensuring a cost-conscious approach to the project,
balancing the demands of business, User and Supplier.
Throughout the project, the Executive "owns" the Business

Justification.
Responsible to: Clinical Communications Programme Board
Specific Responsibilities: • ensure a tolerance is set for the project

• authorise Customer expenditure and set Stage
tolerances
• approve the End Project Report and Lessons Learned
Report
• brief the NHS Information Authority programme boards
about project progress
• organise and chair Project Board meetings
• recommend future action on the project if tolerances are
exceeded
• approve the sending of the notification of project closure
to corporate or programme Management
• overall business assurance, i.e. ensuring that the project
remains on target to deliver products which will achieve
the expected business benefits, and the project will
complete within the agreed tolerances for budget and
timescale
35
ROLE DESCRIPTION
Role: Senior Users
Name Paul Woolman
Dr John Nicholas
Prime responsibility: The Senior Users are responsible for the specification of the
needs of all those who will use the final product, User liaison
with the Project Team, and for monitoring that the solution
will meet user needs within the constraints of the Business
Justification.
The role represents the interests of all those who will use the
final products, those for whom the product will achieve an
objective, or those who will use the project to deliver
benefits. The Senior User role commits User resources, and
monitors products against requirements.
Each Senior User will be responsible for representing the

particular user constituencies as listed above:
Responsible to: Executive
Specific Responsibilities: • ensure the desired outcome of the project is specified

• make sure the progress towards the outcome required
by Users remains consistent from the User perspective
• promote and maintain focus on the desired project
outcome
• ensure that any User resources required for the project
are made available
• approve Product Descriptions and ensure that products
are signed off once completed
• prioritise and contribute User opinions on Project Board
decisions on whether to implement recommendations on
proposed changes
• resolve User requirements and priority conflict
• provide the User view on recommended follow-up
actions
• brief and advise User management on all matters
concerning the project
• ensure that the specification of User needs is accurate,
complete, and unambiguous
• ensure risks to Users are constantly monitored
• ensure the testing of the product at all stages has
appropriate User representation
• ensure quality control procedures are used correctly to
ensure products meet User requirements
• ensure User liaison is effective
36
ROLE DESCRIPTION
Role: Senior Supplier
Information for Personal Health Dr David Robinson

ERDIP Glyn Johnson
Prime responsibility: Represent the interests of those designing, developing,

facilitating, procuring, implementing, operating and
maintaining the project products. Has the authority to
commit or acquire Supplier resources.
Responsible to: Executive
Specific Responsibilities: • agree objectives for specialist activities

• make sure progress towards the outcome remains
consistent from the Supplier perspective
• promote and maintain focus on the desired outcome
from the point of view of Supplier management
• ensure the Supplier resources required for the project
are made available
• approve Product descriptions for specialist products
• contribute Supplier opinions on whether to implement
recommendations on proposed changes
• resolve Supplier requirements and priority conflicts
• brief non-technical management on specialist aspects of
the project
• advise on the selection of specialist strategy, design, and
methods
• ensure that any specialist and operating standards
defined for the project are met and used to good effect
• monitor potential changes and their impact on the
correctness, completeness, and integrity of products
against their Product Descriptions from a specialist point
of view
• monitor any risks in the specialist and production
aspects of the project
• ensure quality control procedures are used correctly, so
the product adheres to specialist requirements
37
Appendix C, NHS Information Compliance Statement
The table below identifies the extent to which the project complies with NHS INFORMATION
AUTHORITY standards.
Standard Comply Comments

Forms an integral and funded part of NHS Yes Budget agreed by NHS
Information Authority’s business and financial plan Information Authority
Information for Personal
Health Programme Board
Has an agreed and fully documented business and Yes See PID and Strategy Report
financial justification, where appropriate in the form
of a Formal Business Case
Follows established and agreed NHS Information Yes Use of PRINCE 2
Authority procedures for programme and project
management and control
Follows DH procurement guidance, and agreed NHS Yes
Information Authority procedures for 3rd party
consultancy recruitment and control
Has adopted agreed NHS data, technical, Yes As Applicable
networking, security, and other strategic standards
Data standards
Contract Minimum Data Set Standards
Data Interchange Standards
Other Technical and Networking Standards
Clinical Codes and Classifications
Groupings
Security
Other strategic standards
Has fully explored the overlaps and interfaces with Yes See PID
the various other existing or planned NHS
Information Authority programmes, projects, or sub-
projects and taken positive action to address these
overlaps, either through active co-operation, or
combined working on national and/or local project
activity as appropriate. This will be especially
relevant where projects are addressing the same (or
similar) business or technical processes and/or
where projects involve the same local sites.
38
Standard Comply Comments

Has adopted a communications strategy and plan Yes See NHS Information
which is consistent with: Authority communication
guidelines
(a) the overall NHS Information Authority
Communications Framework;
(b) the overall NHS Information Authority paper and
(when ratified) electronic publications policy;
(c) the overall NHS Information Authority publication
design guidelines.
39
Appendix D: IPU Commissioning Brief
National Information Partnership

Commissioning Briefs 2000/2001 Version 5
IPU Reference NHSIA Reference

DC08 Standards NIS 4/99
National Strategy for Electronic NPCIS 4/99
Clinical Message
Produce and implement national strategy for electronic clinical communications

(including:- Messaging, appointment booking, referrals, discharges, test results / results
and GP-to-GP record transfer)
Lead IPU Sponsor Stakeholder Representative Lead at NHS IA

Simon Old Chief Executive Forum Colin Price
Standards Boards
IT Suppliers
NHS Users
Key milestones for 2000/01 Agreed Messaging Strategy 31/03/00
GP to GP Record Transfer programme of work agreed 31/05/00
What is this commission

dependent on from
elsewhere? Dependent upon:
DC2
INF1 - core infrastructure being available
INF7 - agreement with professions on security of systems
carrying electronic records
DC4
INF3
What other commitments are

dependent on this Underpins EPR's and EHR's
commission?
Other Departmental Policy HSD - legitimising electronic records

Links
Product description Agree and set up a project board and scope Terms of Reference
Messaging Strategy by 03/2000
Establish a defined and agreed Messaging Programme by
04/2000
40
Key strategic dates for this

activity to 2005 Messaging Strategy by 03/2000
Implemented in full by 2005
Stakeholders (users or
potential NHS users) Whole NHS Community
Suppliers
Quality approach
mechanism, how the NHS is Establish sub project within Standards framework with specific
engaged quality assurance group
DC08
41
Appendix E: NHSIA Business Case
1. Strategic context
1.1 Clinical messaging

Clinical messaging, employing EDI, electronic data interchange, is the interchange of standard
formatted data between the computer application systems of partners with minimal manual
intervention.
"Between the computer applications systems of partners" includes communications within an

organisation and between organisations but excludes communications from data entry terminals to
host computers.
"Minimal manual intervention" is best achieved by automated electronic communications.
The benefits of EDI include
• Approved NHS clinical messages would undergo a rigorous vetting procedure by

professionals
• Messages can be extensively validated to ensure good quality of information
• Results of tests and letters from hospitals to GPs should arrive more quickly
• Mechanisms can be in place to confirm receipt of messages and to report on any missing or
rejected messages.
• Rigorous security mechanisms can be implemented, to protect patient confidentiality
• Requests for services and results can be generated without the need to enter the relevant
information again.
There have been a number of scoping and pilot activities in small domains in clinical messaging,
including:
• Pathology test results

• Discharge and Referral
• Radiology requests
There is ongoing or planned work in small domains including:
• Pathology test results

• GP prescribing
In order for all these messages to be transmitted, received and actioned appropriately and safely,
standards are essential to cover not just the structure and content of messages but also to indicate
how information should be transferred.
42
1.2 GP-GP Messaging

An estimated 70% 8 9of GPs hold at least part of their patient records electronically. At present it is
a statutory requirement for GPs to keep records on paper, although it is estimated that 10% 10
keep records only on computer.
Every year an estimated 10% of patients, around 600 per practice change their registered GP to a
new GP in another general practice in the UK. When this occurs, there is a well known, effective
mechanism for the transfer of the paper record (Lloyd George envelope or medical record
envelope, MRE) detailing the patient’s past care. There is no provision for the transfer of any
electronic component of the patient record
In order to transfer the electronic component of the patient record, common practice is to produce
a printout of the content of the medical record and to put it in the Lloyd George MRE at de-
registration. Anecdotal evidence is that few doctors study such printouts and that even fewer re-
enter any salient information so that it is available to assist future care. Thus, the increased use of
electronic records by GPs to improve the care of their patients has the paradoxical effect of
reducing the quality of the patient record passed to future GPs.
The EPR and EHR paradigm cannot exist without a reliable method of transferring electronic
patient records from a GP at one practice to a GP at another. The project should also address
issues which may have wider relevance. Negotiations with the General Practitioner Committee to
gain agreement to change GP terms of service are dependent on the establishment of a
mechanism for GP-GP electronic transfer.
Information for Health includes electronic transfer of patient records between GPs as one of the
four targets for longer-term implementation, by March 2005. This is one element of a wider
availability of the Electronic Health Record shared across care sectors, subject to appropriate
security.
GP to GP electronic transfer has been identified as a first priority work within National Standards
for electronic clinical information sharing. Historically work in this area has been carried out by a
small informal group of experts with links to Newcastle University, the Primary Healthcare
Specialist Group of the British Computer Society and the Royal College of General Practitioners. A
preliminary scope of costs to develop GP-GP transfer was performed from within this group for the
General Medical Services Group of the NHS Executive. The option appraisal (Section 4) supports
the need to reshape this proposal.
This group also has strong links to the Primary Care Division who have been involved in
negotiations with the General Practitioners Committee over the change to GPs terms of services to
allow GPs to maintain electronic patient records. Fundamental to this agreement was an
undertaking to fund development of GP-GP messaging specification. There has been pressure
from within the Primary Care Division both to commission the work as soon as possible, and to
commission all the work to this external group.
8
NHS Executive Computerisation in GP Practices 1996 survey
9
More recent figures are included in the main section of this PID (Section 1.2)
10
Evaluation of GP Computer Systems 1997
43
2. Existing work
The project would build on work undertaken in two recent projects:
2.1 The Textbase Project
This research was carried out by a partnership including the Sowerby Centre for Health
Informatics and the then four leading GP system suppliers AAH Meditel (now Torex Meditel) EMIS,
In Practice Systems and Torex (now Torex Meditel).
It was viewed as a pragmatic first step towards GP to GP transfer, aiming to establish a base level
message supporting EPR 11 transfer. The research was carried out in a laboratory environment,
using record with date & text entries being organised within these structures using HTML, and
transmitted using EDIFACT syntax. There was no encryption.
Three processes were evaluated:

• Generation of an outgoing message
• Process of an incoming message
• Display of processed message from a different EPR
2.2 The XML EPR Project
This study was carried out by the Royal College of General Practitioners in 1999. The principle
objective of the project was to enable professional validation of a working draft of the Provide
EHCR message 12. The work described in this report involved technical and clinical validation
involving four major GP systems suppliers and a group of clinical professionals representing the
RCGP. The suppliers populated instances of the message in the Extensible Markup Language
(XML) syntax and these were displayed for scrutiny by a team of clinical professionals.
A number of conclusions were made in particular:
• Clear and unambiguous implementation guidance will be essential for effective use of the
Provide EHCR message for GP to GP transfer of patient records within the NHS.
• The potential for automated support for implementation guidance, offered by particular
approaches to the use of XML, should be evaluated, with a view to the adoption of such
techniques.
• A number of difficult legal issues (for example, who is responsible for any change in meaning
resulting from the transfer) must be resolved.
11
Within these studies EPR refers to a generic electronic record and does not necessarily have the same
meaning as EPR in Information for Health
12
This message for healthcare record communication was the subject of a formal Request for Comments
from the European standards body CEN TC251
44
2.3 CEN TC251 ENV 13606

The Comité Européen de Normalisation Technical Committee 251 (CEN TC251) was responsible
for the ENV13606 pre-standard which has four parts:
• Part 1: Architecture
• Part 2: Domain term list
• Part 3: Distribution rules
• Part 4: Messages for exchange of information
All part have relevance to messaging, but especially Part 4, which specifies a number of
messages for requesting, acknowledging and responding to message requests.
Work is currently going on to harmonise all CEN work with that of Health Level 7 (HL7), which is
likely to become the de facto international standard.
45
3. Scope & deliverables

This project will deliver a set of messages and associated system specifications and supporting
documents to enable the implementation of electronic transfer in GP records. This project will
clarify and manage the interfaces between this outsourced work and the wider NHS Information
Authority programmes.
The scope of the project can be divided into two sections
3.1 GP-GP specific deliverables

The deliverables of the project would include solutions to the issues of two major streams
identified by the XMLEPR project and a range of messages that would support clinical
documentation for continuing primary care including a model to allow coexistence of:
• Unstructured (text-based) record content

• Partially structured record content
• Structured record content
3.2 Generic messaging deliverables
These deliverables relate to the messaging control process. The issues arising are likely to apply
to other messaging work, and at the least this should be integrated with other messaging work
areas. The OJEC process allows division of the work, and separate or internal NHSIA fulfilment of
these areas should be considered.
• The request by a GP practice for the record of a newly registered patient
• The authentication of a request by a GP practice by a trusted third party
• The notification of the transfer of a record to a responsible agency
• The acknowledgement of the receipt of a record by a requesting GP practice
• Such additional messages as are strictly necessary to support processes
46
4. Option appraisal
There are three potential approaches to the next phase of development of GP-GP electronic
transfer
1. Identify and/or develop in-house NHSIA knowledge and expertise

2. Contract to centres with expertise with NHSIA project management and knowledge transfer to
NHSIA
3. Contract all work to centres with expertise
Estimated costs of external contracting, benefits and risks are summarised in table1:
Option 1 2 3
External £370K £470K
Costs
Benefits Acquisition of skills Acquisition of skills and Known expertise and familiarity
and knowledge for knowledge for future with:
future clinical clinical messaging • previous work
messaging • standards e.g CEN TC251,
NHSIA control HL7
NHSIA control • message syntax e.g. XML
Integration with other
Integration with NHSIA work Stakeholder confidence
other NHSIA work
Stakeholder confidence
Risks Lack of appropriate Split responsibility Continued lack of skills within
skills within NHSIA. between NHSIA NHSIA
management and
Time to acquire external supplier. Loss of control
skills insufficient
Lack of integration with other
Lack of stakeholder NHSIA work
confidence
Rank 3 1 2
Table 1: Risk benefit analysis
There is currently insufficient NHSIA expertise to attempt Option1. Option 3 would have undoubted
benefits in terms of expertise and stakeholder confidence, however there is a risk it would
perpetuate the lack of NHSIA expertise and furthermore reliance on a small group of individuals.
Option 2 retains the benefits of Option 1 but has additional benefits in acquisition of NHSIA
expertise and co-ordination of the project.
47
5. Implementation timetable
An OJEC procurement process has been initiated, the first two stages, OJEC Notice and
Expressions of Interest have taken place.
Subsequent timings are provisional, based on approval being given at the NHSIA Board Meeting
on 1st November 2000
• OJEC notice 7th August 2000

• Expression of interest 15th September 2000
• Invitation to tender 6th November 2000
• Receipt of tenders 13th December 2000
• Evaluate tenders 20th December 2000
• Interviews 5th January 2001
• Assessment/negotiation 24th January 2001
• Award of contract 31st January 2001
48
6. Project organisation
6.1 Project Board 13
A unified board has been established to supervise all the activities supporting ‘Content framework’
within the Information for Personal Health section of the Service Delivery directorate:
• Headings
• Context of care
• Clinical messaging
• Episodes of care
The project board structure to oversee these streams is:
Executive Michael Thick NHSIA Stakeholder Directorate

Senior Users Martin Severs NHSIA Information Standards Board
Frances Martin Regional Head of Information
Sue Overill Nursing Professions
John Mason Medical Professions
Jackie Griffith Clinical Professions
Colin Gunner CSSA
Senior Suppliers David Robinson NHSIA Service Delivery Directorate
Toto Gronlund NHSIA Service Delivery Directorate
6.2 Project management
It is anticipated the project manager and business assurance co-ordinator currently assigned to
the Headings project will be assigned. An additional business assurance co-ordinator will be
recruited in the near future.
6.3 Interfaces
The project will establish links with other activities within the NHS Information Authority including:
• GP connect
• The Exeter System Development Team
• The Security and Confidentiality programme
• Context of Care
• Headings for Communicating Clinical Information
• SNOMED Clinical Terms
• Requirements for accreditation
13
The structure and membership of the board has changed since the business case was written
49
6.4 Stakeholders
• GP system suppliers
• Royal College of General Practitioners
• Primary Healthcare Specialist Group of the British Computer Society
• General Medical Council
• British Medical Association
• General Practitioners Committee
• Primary Care Division
• Information Policy Unit
• Health Authorities
• Primary Care Groups & Trusts
50
Appendix: Estimated proportion of costs
The following is a rough estimate of the relative costs of the two streams. This has been derived
from a document submitted to the General Medical Services by the RCGP. The same group is
likely to be tendering for the contract so further information has not been requested at this stage.
Three major work items be considered relevant to the GP-GP specific sections:
• Development of XML DTDs

• Development Text-based transfer
• Development Structured transfer
The estimated cost of these three sections was £272,000 out of a total of £470,000 (58%).
The OJEC advertisement has stated £370,000 as a guideline figure, as £100,000 was withheld
from the original budget to cover internal NHSIA management costs, and effect a skills transfer.
The proportionate cost of the GP-GP specific work would be approximately £215,000
A number of assumptions (e.g. distribution of management and administrative costs within

the estimate) have been made and these figures should be treated with caution.
51
Appendix F: Glossary
Term/Abbreviation Definition/Explanation
CEN Commité Européen de Normalisation – European Committee for
Standardisation
DTD XML Document Type Definition
EDIFACT Electronic Data Interchange for Administration Commerce and
Transport
Electronic Healthcare Record The term EHR is used to describe the concept of a longitudinal
(EHR) record of patient’s health and healthcare – cradle to grave. It
combines both the information about patient contacts with
primary health care as well as subsets of information associated
with the episodic elements of care held in EPRs.
Electronic Patient Record A record containing a patient’s personal details (name, date of
(EPR) birth),
their diagnoses or conditions, and details about the treatment
and assessment undertaken by a clinician. The EPR typically
covers the episodic care provided mainly by one institution.
ERDIP Electronic Record Development Programme. It is concerned
with co-ordinating the progress, as part of the NHS Information
Authority, of the EPR and EHR initiatives as promoted in the
NHS Information for Health strategy
HL7 Health Level Seven – USA organisation originally concerned
with messaging
standards but spreading its influence into vocabulary
HTML HyperText Mark-up Language.
Information for Health The NHS information strategy, detailing the future for IM&T in
(IfH) the NHS for 1998 – 20005. It was published in 1998.
ISO International Standards Organisation
NHS IA NHS Information Authority – the Special Health Authority set up
from 1 April 1999 to replace the NHS Information Management
Group. It leads the implementation of the NHS Information for
Health strategy.
PCG Primary Care Group. PCGs are new organisations which were
announced in The new NHS – modern, dependable publication
in 1997. They comprise all GPs in an area together with
community nurses who will take responsibility for commissioning
services for the local community. This will not affect the
independent contractor status of GPs. The new PCGs will
replace existing commissioning and fundholding arrangements.
All PCGs will be accountable to Health Authorities, but will have
freedom to make decisions about how they deploy their
resources within the framework of the Health Improvement
Programme. Over time, PCGs will have the opportunity to
become free standing Primary Care Trusts.
52
PCT Primary Care Trust. PCTs were announced in The new NHS –
modern, dependable publication in 1997. The Government will
bring forward legislation to establish a new form of Trust - a
Primary Care Trust - for Primary Care Groups which wish to be
freestanding and are capable of being so. Such Trusts may
include community health services from existing NHS Trusts. All
or part of an existing community NHS Trust may combine with a
Primary Care Trust in order to better integrate services and
management support.
PDF Portable Document Format.
PRINCE 2 PRINCE 2 is the project management methodology used by the
NHS Information Authority. It is owned and developed by the
Central Computer and Telecommunications Agency (CCTA),
part of the UK Government’s Office of Public Service.
Project Initiation Document A PRINCE 2 project management document. Its purpose is to
(PID) define the project and form the basis for its management and
the assessment of overall success. There are two primary uses
of the document:
• To ensure that the project has a sound basis before asking
the Project Board to make a major commitment to the
project
• To act as a base document against which the Project Board
and Project Manager can assess progress, change
management issues, and on-going viability questions
UML Unified Modelling Language - A widely accepted language for
object oriented analysis and design.
XML Extensible Markup Language, a formal recommendation of the
World Wide Web Consortium. A subset of HTML which can be
used for display but also for definition of data.
53
Notes on Appendices
Appendix A - Product Descriptions
Note the convention of previewing product identifiers with M for management products, S
for specialist products and Q for quality products.
Appendix B - Role Descriptions
These are being based on the PRINCE 2 template role descriptions, and have been
reviewed and tailored to suit the needs of this project. It is important that individuals
understand and accept their assigned roles.
Appendix C - NHS INFORMATION AUTHORITY Compliance Statement
This is a mandatory requirement in NHS INFORMATION AUTHORITY.
Appendix D – Information Policy Unit Commissioning Brief
Appendix E – Business Case
Included at the request of the Project Board. It should be noted that the figured quoted for
computerisation of GP Practices have been superseded by a more recent study, and that
timescales and the management arrangements have changes since this document was
produced.
54

GP2GP Pid101

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

GP2GP Pid101

Hochgeladen von

Copyright:

Verfügbare Formate

GP-GP Record Transfer - Project Initiation Document

GP-GP Record Transfer

Project Initiation Document

Information for Personal Health

Purpose of this document

To describe GP2GP Project in a manner which meets

Distribution Senior Management ,

© Crown Copyright 2001

1.1. Purpose of this document 5

1.3. Mandate and Project Brief 7

2.1. Purpose of the Project 8

3.2. Health Informatics Research International Ltd (HIRI) 11

3.3. Interfaces with Programme Management 11

4.1. Project Plan 12

4.2. Quality Plan 14

4.3. RESOURCES & TIMESCALES 17

4.4. PROJECT CONTROLS 18

4.4.6. Mid Stage Assessments 18

5.3. Initial Risk Assessment and Outline Contingency 20

Appendix A, Product Descriptions 23

Appendix B, Notes of Project Organisation and Roles 33

Appendix C, NHS Information Compliance Statement 38

Appendix D: IPU Commissioning Brief 40

Appendix E: NHSIA Business Case 42

1.1. Purpose of this document

The project will build on work undertaken in three recent areas:

The Textbase Project

Three processes were evaluated:

The XML EPR Project

A number of conclusions were made in particular:

CEN TC251 ENV 13606

1.3. Mandate and Project Brief

2.1. Purpose of the Project

The scope of the project is identified in the table below.

The Project Includes:

• A review of issues relating to text-based record transfer and specification

The Project Excludes:

• Piloting of the proposed GP2GP Message

The principal specialist products (Appendix A) will be:

• Main project report for the programme board (S7)

Quality Assurance, Consultation, Education (including skills transfer) and Communication

Management products include:

• Project Initiation Document (M1)

Detailed Product Descriptions are provided in Appendix A

! SNOMED Clinical Terms

! Also affect other Information for Personal Health projects

3.1. Project Management Structure

GP to GP Record Transfer Project Board Structure:

Role Name Organisation

Executive Dr Philip Brown NHS Information Authority

Senior Suppliers Dr David Robinson NHS Information Authority

Clinical Communications Programme Board Structure:

Role Name Organisation

Executive Michael Thick NHS Information Authority

Senior Suppliers Dr David Robinson NHS Information Authority

3.2. Health Informatics Research International Ltd (HIRI)

The core members of the team are:

• Professor Ian Purves (Sowerby Centre for Health Informatics at Newcastle)

• The Textbase Project

3.3. Interfaces with Programme Management

The GP-GP Record Transfer Project should maintain relationships with:

Information for Clinical