PACS Practical Experience-5570

PACS Implementation Guide
Programme
Sub-Prog/Project
Prog. Director
Sub Prog/Proj Mgr
Author
Version Date
PACS
National Prog
K Prangley
D Jennings
28/6/04
NPFIT
Version No
Status
DOCUMENT NUMBER
Org
Prog/Proj
Doc
PAC
GEN
PI
V0.03
Final
PACS Practical Experiences
Seq
0001
NPFIT-PRI-GMP-0001 V0.13
28 June 2004 Draft
Amendment History:
Version
V0.1
V0.2
Date
22/3/04
16/04/04
V0.3
01/06/04
Amendment History
First draft for comment
Updated version with information from PACSnet
and initial comments from NPfIT PACS
Facilitators
Updated version following comments from
formal Quality Review
Reviewers:
This document must be reviewed by the following.
Name
Signature
Title
Date of Issue
Version
Date of Issue
Version
Approvals:
This document requires the following approvals.
Name
Signature
Title
Document Location
This document is only valid on the day it was printed.
Controller for location details or printing problems.
Please contact the Document
This is a controlled document.

On receipt of a new version, please destroy all previous versions (unless a specified earlier
version is in use throughout the project).
Page 2 of 45
28 June 2004 Draft
Related Documents.
These documents will provide additional information.
Ref no
1
Doc Reference Number

NPFIT-NPO-GEN-IP-0067
Title
Glossary of Terms Consolidated.doc
Version
Latest
Glossary of Terms.
List any new terms created in this document. Mail the librarian to have these included in the
master glossary above [1].
Term
Acronym
Definition
Page 3 of 45
28 June 2004 Draft
Contents
PACS Practical Experiences..................................................................................................... 1
1.
Introduction.................................................................................................................... 6
1.1
Terms of Reference and Scope..................................................................................6
1.2
Audience..................................................................................................................... 6
1.3
Acknowledgement...................................................................................................... 6
1.4
National Programme for IT.........................................................................................6
1.5
An Introduction to PACS.............................................................................................7
2.
Road Map / Summary.................................................................................................... 7
3.
Lessons Learnt............................................................................................................... 8
3.1
Supplier Management.................................................................................................8
3.2
Executive and Clinical Commitmant...........................................................................8
3.3
Planning...................................................................................................................... 8
3.3.1
Standardisation of numbering and exam codes.................................................9
3.3.2
Migration of Data................................................................................................ 9
3.3.3
Reports and Outputs.......................................................................................... 9
Typical Queries....................................................................................................................... 10
5.
Project Planning........................................................................................................... 11
6.
Review Current Policies, Procedures and Working Practices.......................................11
6.1
Process Change and use of the Modernisation Agency............................................11
7.
System Testing............................................................................................................. 11
8.
Training Guidelines...................................................................................................... 12
9.
Technical and Interfaces............................................................................................... 13
10
Communication............................................................................................................ 13
11
Staffing during Implementation.....................................................................................13
12
Ongoing System Management.....................................................................................14
12.1 Maintenance of System / Database..........................................................................15
12.2 Looking after the Internal Users................................................................................15
12.3 Service Provision for External Users........................................................................15
13.
Supporting the Paperless Environment........................................................................16
14.
Identifying Potential Benefits........................................................................................ 16
15.
Go-Live Period............................................................................................................. 16
16.
Measuring Benefits / Post Implementation Review......................................................17
17.
Business Case Support See Appendix F...................................................................18
A Appendix A Film Digitisers............................................................................................ 19
A.1
Film Digitisers.......................................................................................................... 19
A.1.1
Camera............................................................................................................. 19
A.1.2
CCD (Charge-Coupled Device)........................................................................19
A.1.3
Laser................................................................................................................ 19
A.2
Digitiser Quality Control............................................................................................ 19
B Appendix B Project Planning........................................................................................ 21
B.1
An Example Summary of the rationale behind planning...........................................21
B.2
An Example of Supplier Commitment to Project Management.................................21
B.3 Example Project Plan.................................................................................................... 22
B.4
Example Multi Site Plan............................................................................................ 23
B.4.1
Example 1........................................................................................................ 23
B.4.2
Example 2........................................................................................................ 24
B.5
An Example of a PACS Implementation Reporting Structure....................................25
C Appendix C Technical and Interfaces............................................................................26
C.1
Networking................................................................................................................ 26
C.2
Communication Standards.......................................................................................26
C.2.1
DICOM (Digital Imaging and Communications in Medicine).............................26
C.2.2
IHE (Integrating the Healthcare Enterprise)......................................................26
C.2.3
HL7................................................................................................................... 26
C.3
Interfaces.................................................................................................................. 27
C.4
Digital Image............................................................................................................. 27
C.4.1
Digital Image Capture.......................................................................................27
C.4.2
Acquisition of Digital Data on to the PACS.......................................................28
C.4.3
The Database Server and DICOM Gateway....................................................28
C.4.4
Digital image display......................................................................................... 29
C.4.5
Digital image storage........................................................................................ 29
C.4.5.1
Networked Storage...............................................................................30
C.4.6
Film printers...................................................................................................... 31
Page 4 of 45
28 June 2004 Draft
C.5
Monitors.................................................................................................................... 32
C.5.1
Image Quality................................................................................................... 32
C.5.2
Displays............................................................................................................ 32
C.5.2.1
Quality Assurance of Display Devices..................................................33
C.6
Web Browsers.......................................................................................................... 34
D.1
Radiologist Office and Reporting Areas....................................................................35
D.2
Radiographer Zone................................................................................................... 36
D.3
PACS Computer Room............................................................................................. 36
E.1
An example of: How has the deployment of the PACS improved services'..............40
F.1
Introduction............................................................................................................... 42
F.2
The Business Case Templates.................................................................................43
F.2.1
Strategic Case.................................................................................................. 43
F.2.2
Economic Case................................................................................................ 43
F.2.3
Commercial Case............................................................................................. 43
F.2.4
Financial Case.................................................................................................. 43
F.2.5
Management Case........................................................................................... 43
F.3
The Toolkit................................................................................................................ 43
F.4
The Workshops......................................................................................................... 43
F.5
Summary.................................................................................................................. 44
Page 5 of 45
1.
Introduction
1.1
Terms of Reference and Scope
NPFIT-PRI-GMP-PI-0001 0.2
16-April 2004 Draft
This document discusses and outlines tasks, considerations, resources and aspects of
preparing to and implementing a Picture Archiving and Communications System (PACS) will
assist when the implementation of new systems or the expansion of current systems are
being considered.
It is intended to be a living document and will be updated by the NPfIT PACS Team as
lessons are learnt and processes develop. The intention is that implementation information
across the NHS can be collated into one document to increase knowledge utilising the
experience of others.
A Picture Archiving and Communications System (PACS) typically comprises data storage
devices, image display devices, database management software and links to image and/or
image data acquisition devices, connected by computer networks. There will be network
connections to other information systems such as the Hospital Information System (HIS),
Patient Administration System (PAS) and the Radiology Information System (RIS).
1.2
Audience
This document covers a wide range of areas and will be useful to Chief Executives, Chief
Information Officers, Directorate and Clinical Managers, Clinical practitioners, IT Teams and
the PACS Implementation Team.
1.3
Acknowledgement
This document has been completed based on the experiences of clinicians and IT personnel
who have undertaken PACS implementations in the past, or who have specific PACS
expertise, such as PACSnet. We acknowledge their help and thank them for taking the time
and effort they gave in supporting us to create this document.
1.4
National Programme for IT
The National Programme for Information Technology (NPfIT) is one of the worlds largest IT
programmes. To achieve this, the programme plans to ensure that the right information is in
the right place and at the right time. It supports the vision of the NHS Plan by modernising
information systems across the NHS in England. The programme aims to improve the
convenience and quality of care for users and providers of healthcare within the National
Health Service in England.
To take advantage of the possibilities offered by the National Programme, it is expected that
working practices will change.
There are four key elements to the National Programme. These are:
Electronic booking of appointments (eBooking)
NHS Care Records Service (NCRS)
Electronic Transmission of Prescriptions (ETP)
An underpinning IT infrastructure with sufficient connectivity and broadband capacity

to support national applications and local systems.
NCRS is the core component of the NPfIT and will completely change the way patient
information is collected, stored, communicated and used. It will provide clinicians across care
professions and organisational boundaries with access to integrated services that are based
around the patient. PACS images may be distributed by the network, but most of the
information will be about PACS images e.g. reports and the location of PACS images rather
that the images themselves. Most of the interaction is with the RIS.
1.5
28 June 2004 Draft
An Introduction to PACS
The investment in PACS will support the Governments vision for filmless diagnostic services.
Advances in digital technologies, particularly in the fields of computing, imaging and in
communication, have progressed to the point that it is now possible to acquire medical
images in digital form, archive them on computer systems, and display them in diagnostic
quality. The display monitor used to present the images can be at an adjacent or distant
location to the original point of acquisition. Indeed, there can be multiple monitors at multiple
locations, since once the master image file has been archived; it is only ever a copy of the
data that is transmitted for display.
The benefits of PACS are well documented and a table of benefits is included as an appendix
to this document.
Several standards have proved themselves useful in implementing a PACS, notably Digital
Imaging and Communications in Medicine (DICOM) and Health Level 7 (HL7). In a typical
radiology department, it is likely that a large number of steps are performed in the sequence
of events from the time that the patient is first registered in the department to the time that the
clinical report is issued. The required sequence is likely to be a process that has evolved over
many years, and it may no longer be the optimal process for a modern radiology department.
Installation of a PACS gives the opportunity to re-evaluate the workflow within the radiology
department. Rather than merely mimicking an existing, paper-based, system, a carefully
planned PACS implementation can encourage improved workflow, i.e. the more efficient flow
of information, images and patients through the department.
2.
Road Map / Summary
As all trusts will be starting the process from a different point the following Road Map is a
guideline.
Identify Need for PACS
Obtain Executive, Clinical and IT Commitment / Create Project Team
Identify PACS Community
Identify Benefits (include baseline)
Review current processes and define process change (Modernisation Agency involvement)
Approve Business Case

Create Implementation Team
Select Supplier/ System in conjunction with LSP including the process by which this happens
Review Suppliers Implementation Plan and Technical plan
Agree supplier/Trust Implementation Plan
Start site preparation (including staff aspects and technical architecture)
Implementation
On going maintenance / support
Post Implementation Review & Benefits analysis
Feed back to National Team

Page 7 of 45
3.
Lessons Learnt
3.1
Supplier Management
28 June 2004 Draft
Implementation is a joint task that involves a coordinated team effort. The suppliers are
experienced in the implementation of the PACS solution, but the NHS has the expertise of
business processes within the domain. It is in working together in one team utilising the skills
available that creates successful outcomes.
Working with the suppliers is not just an implementation activity, but also an on going
relationship through the provision of support over the life of the service contract.
3.2
Executive and Clinical Commitment
Executive commitment is imperative for the success of the project, the CEO and board should
be fully briefed on the progress of the project. Finance and IT should also be represented on
the project board.
It is important to recognise that PACS is a clinical system that will be widely used and should
be managed as a clinical project with IT support. Clinical commitment and support to the
project from its conception is vital so that there is acceptance and ownership throughout the
clinical setting.
PACS is not solely a Radiology tool and will be utilised by many clinicians across the PACS
arena, a clinical champion within radiology and at least one from another department will help
the project.
Having clinicians involved in the decision making and the project significantly helps the
adoption of the system and supporting processes.
3.3
Planning
Prior to implementing PACS
A network survey must be done, the bandwidth of both backbone and branches must
be assessed and any upgrading work undertaken. Advice on minimum network
requirements should be obtained from the PACS supplier. They may also be helpful
during the network survey process.
Ensure the Radiology Information system (RIS) can meet the requirements of a PACS
installation and address this as an urgent priority. Have a clear view as to how non
radiological (potentially non RIS entered studies) images will be incorporated into the
system.
A unique patient identifying number is vital to a Trust and Community wide PACS
system, e.g. NHS number or Hospital Registration number.
Which pieces of equipment is DICOM conformance statement? Which DICOM data

elements are supported?
What is the cost of upgrades to DICOM equipment to enable interoperability?
What needs replacing? For non DICOM equipment that will not be replaced how can
the images be sent to PACS? (You may need to provide space to accommodate an
image gateway computer and desk and network point and power socket)
It should never be assumed that a piece of equipment supports the

required DICOM communication (i.e. service classes). Therefore,
always check with suppliers that the new and existing equipment
should interoperate.
Page 8 of 45
28 June 2004 Draft
3.3.1 Standardisation of numbering and exam codes

PACS is not a stand alone solution (see below) and therefore when implementing the
solution you will need to discuss with other projects that may be going on throughout the Trust
or SHA. In particular, review if there are coding standards or patient numbers that should be
considered.
If there are multiple departments involved you may need to agree on standardised coding for
examinations, a mapping exercise may be required.
It cannot be stressed highly enough how big a job this will be for most Trusts, particularly
those with multiple sites and potentially multiple RIS.
The NHSIA is currently working on the standardisation of imaging examination codes.
Stakeholder engagement includes the Royal College of Radiologists, the design authority of
the NPfIT (workflow and messaging), NPfIT PACS Implementation Advisors and some Cluster
Team representation.
The underlying coding structure that is being considered is SNOMED Clinical Terms, which
will also be used for messaging with the data spine.
The understanding is that while the standardisation of local exam codes will be needed to aid
work in the PACS clinical community, having a National code is not essential for the visions
and ambitions of the NPfIT PACS program.
3.3.2 Migration of Data

Decisions regarding the migration of existing digital archives, both images and radiology
exam requests, must be taken locally. There are various models that have been successful,
but in each case it requires clearly defined, agreed and documented processes that must be
adhered to.
At the beginning of the project it is important to define any interfaces and data
conversions/migration required for PACS. Data migration refers to the acquisition of data on
historical events and patient demographics from existing systems to new systems. Data
acquisition and transfer refers to the acquisition of current data to the PACS.
Previous PACS installations have taken different approaches to film migration: See section 14
No prior images digitised and no data migrated.
Scan on demand where the PACS is introduced and from that point on film-based
patient records are scanned when a patient enters active care within a Trust.
Planned migration where the digitisation of images is started (using the active
records approach above) in advance of PACS being introduced, use a local RAID
store to create an initial archive.
Target group migration where groups of patient records (for example cancer
patients, children, etc) are scanned en masse into a PACS store.
Full migration where films are scanned in to a PACS store in large quantities.
Digitised films will need to be reconciled in PACS and RIS.
The PACS NPfIT Team would be happy to discuss the various models with you, and share the
pros and cons of the approaches. Appendix A contains information on aspects of film
digitisers.
3.3.3 Reports and Outputs

System reports can be obtained from the PACS being implemented. Check what standard
(both statistical and workload examination based) reports are supplied with the systems and
ask to see examples.
Any new local requirement for additional system reports should be checked for validity as they
are usually at an extra cost, combine reports using fields from other reports if that is effective.
Review any current reports and ensure there is not duplication, or if a given report is required,
reports need to reflect the processes that are being put in place.
Page 9 of 45
28 June 2004 Draft
Typical Queries
The suppliers should provide answers to these questions and others appropriate to local
needs. If advice is sought or concerns raised these should be directed to NPfIT
Implementation Advisors throughout the Implementation phase.
What support will there be from the supplier at go live and for how long?
How long will there be application support
What will be the commitment of the integration specialists
What is the long term support? From
PACS supplier is it 24/7?
CR /DR supplier is it 24/7?
In house Network supplier is it 24/7?
In house local IT is it 24/7?
PACS Systems Administrator is it 24/7?
What are the standard system reports?

What training does the supplier provide?
Will the training be cascade
Will they train all end users
Will there be documentation

o
of training manual
of the training done
How are the reference files populated?
Which reference files are pre-populated by the supplier
Which reference files need populating by Systems Administrator
Who enters user and security settings (passwords and privileges)
Who is responsible for the data conversion or interfaces? (including mapping)

Who is responsible for Benefits Analysis?
Benefits Base line
Set date for review and report
Who will agree sign off criteria before implementation?

Who is responsible for setting sign off date for acceptance and the acceptance criteria?
How are future software developments managed?
Automatic upgrades
Local requests
Statutory requirements
Page 10 of 45
28 June 2004 Draft
How is ad hoc reporting managed?
What tool is used
Are all data items accessible
Are there sufficient viewing workstations for imaging staff to view previous soft copy
images prior to X-ray? This can be done by record checking, in individual cases it
may be necessary to view the previous images.
5.
Project Planning
Project planning adheres to PRINCE 2 Project Management Procedures and Processes.

Project plans are shared between the customer and the supplier and are joint working
documents and will reflect the tasks required for a particular project. The approach will vary
whether it is a multi or single site approach, but in either case one must always plan with the
wider future requirements in mind.
While there are no standard plans as such, the individual plans are often developed from a
suppliers template. Appendix B has some example project plans.
Appendix B also documents an example project reporting structure and example
deliverables/key milestones, but again these will tend to locally reflect structures put in place
by the Cluster and LSP Teams.
6.
Review Current Policies, Procedures and Working

Practices
To implement PACS correctly an understanding of current working practices is required and

reviewing current policies and written procedures. These then need to be considered in light
of process redesign and the changes that will need to be made to successfully utilise the new
solution. Change management is a critical factor in the success of PACS projects.
New policies and procedures for the use of the system should be carefully documented with
specific reference for planned and unplanned downtime for consistency of operation and data
recovery.
6.1
Process Change and use of the Modernisation Agency
The Radiology service improvement team (Associate Director, 4 National Managers and 4
National Clinical Leads) are part of the Modernisation Agency. Their role is to provide
expertise and advice on service improvement to clinical teams, Trusts and SHAs.
The National Framework for Radiology Service Improvement (July 2003) was developed in
partnership with the MA, DH and Professional bodies to ensure an integrated approach to
Radiology service improvement. It promotes a clinically lead approach which ensures all
aspects of Radiology Modernisation are aligned, including - Changes in workforce;
Equipment; Education; and IT strategies which includes PACS.
To support the above framework a Radiology Service Improvement toolkit is available. This
aims to provide a basis for multidisciplinary redesign, based on proven service improvement
methodology and learning from a number of pilot sites.
The National teams can provide support to any clinical team to ensure that service
improvement is integrated across the whole systems of care including the service redesign
opportunities that can be delivered as part of the implementation of PACS.
7.
System Testing
During implementation prepare some testing scenarios for the system, take them from real life
and test a combination of input events, ensure that the outputs are as expected.
e.g. Check:
That the system identifies duplicate examinations.
Page 11 of 45
28 June 2004 Draft
Patient image history is displayed
Attempt to enter invalid data e.g. a name in a date field and evaluate the outcome.
Images acquired to the system are matched to the correct examination
Images are displayed in the appropriate orientation
Examinations are retrieved and images displayed within the required time
Worklists display the appropriate examinations
The supplier should be able to provide example test scripts, but you will need to adapt them
for local use and test your working practices as well as test the system. This could be a safe
test environment on your installed system.
Enquire of the supplier as to the availability of a test system environment. It may be possible
to perform tests on equivalent hardware and software prior to installation on site, or to carry
out the tests on a partitioned area of the system after installation. A test environment can be
a duplicate database on the installed system; it need not be a separate installation.
8.
Training Guidelines
Disparate groups of staff will require training to different levels. Level of access will depend on
the role of the individual across the Trust. Discussion with the supplier will help formulate the
training strategy.
Determine how many trainers are available and the number of available areas to train people.
Training ideally should happen as close to the go live as possible; to ensure staff retain the
information, and ideally a maximum of 8 trainees at a time, and 2 trainers should attend each
session.
Then take each group of staff and decide the length of time their training will take.
It is usually possible to do group training for most staff members, workload permitting, this
may require 1 to 1 sessions for consultant and more senior staff.
Ensure that the composition of the groups is carefully considered as the training session
should be relevant for the entire group, e.g. dont try to train nurses and radiographers at the
same time as their use of the system will be very different.
Ensure that people sign up for sessions as a free for all drop in session often means that
people arrive late or leave early which can disrupt the group.
Develop training guidelines for the users, ensuring that these are short and to the point, large
manuals are not easily read.
Some credit card size laminated guides are useful as people can keep them in their pockets
or attach them to the terminal for easy reference.
Allow for extra sessions to train people who were unable to attend their allocated session.
Users should not be assigned a PACS account and password until they have completed a
training session satisfactorily. Schedule training sessions as part of a staff members normal
working day to ensure maximum attendance.
Have trainer and trainee evaluation forms for the sessions to ensure that there is a record of
any difficulties people may have experienced or any policy decisions that need to be followed
up from the session.
If a member of staff has had issues during the training ensure that they are offered additional
training or extra help over the go live period. PACS training should be an integral part of junior
Doctors Induction Training
Identify keen users during the sessions as they will provide good support to other staff
members in their areas.
Allow users access to a training system once they have completed their session to practise
before go-live, better to have mistakes there than in the real system.
Page 12 of 45
9.
28 June 2004 Draft
Technical and Interfaces
The Output Based Specification (OBS) for the Integrated Care Records Service (now the
National Care Records Service) and the relevant technical information in section 115 - Digital
Imaging Including Specification for a Picture Archiving and Communications System (PACS)
Solution defines technical requirements and integration standards. The OBS can be found on
the
Department
of
Health
website
at
http://www.dh.gov.uk/assetRoot/04/0716/32/04071632.pdf
In addition the Project Initiation Document (PID) for PACS also references recommendations
for networking. See OBS available on www.dh.gov.uk
There should be real time interfaces between PAS, RIS and PACS this reduces the
requirements for patient demographics to be re-entered on different systems. The RIS/PACS
interface should pass the examination details automatically to the PACS
Details on technical aspects can be found in Appendix C.
10
Communication
Clear communication is essential to the whole Trust.
Ensure that all staff are aware of the PACS implementation, through news letters
and/or lunch and learn sessions, encourage people to ask questions.
Projects that involve change often cause concern to staff and in particular in a PACS
implementation there are likely to be staff changes and some relocation of resources.
Make sure that these concerns are addressed.
The following lists some observations from sites that have installed PACS:
Plan implementation meetings on quieter days or parts of the day to ensure fewer
interruptions.
When implementing a PACS there are practical considerations to be taken into account
regarding the department layout that need to be thought through as part of the project.
Service re-design should incorporate these considerations.
Involve the estates department at the beginning of the planning process for a PACS
installations to ensure appropriate use of accommodation and facilities e.g. to assist with
planning equipment moves, air conditioning.
Health and Safety issues must be considered in department redesign and documentation to
assist with this is available from the local Estates department.
When looking at these practical designs there are three main areas to focus on: Radiologist
office/Reporting area; Radiographer zone; Computer Room. The Radiologists offices and the
reporting areas may be quite separate and may have quite different requirements. Please
see Appendix D
Consider whether the implementation approach is to be Big Bang or Phased. Each have
their specific advantages. Sites should determine which approach best suits their needs
Ensure that the Trust puts in enough funds to pay for what is needed, such as networking,
allowing for contingencies that become apparent once implementation is under way.
Ensure good communication with IT colleagues to explain the true implications to all
radiography and other clinical staff. PACS does not just 'plug and play'.
11
Staffing during Implementation
During the implementation phase the amount and type of resource will vary depending upon
the size, phase and scope of the project. You will require multi-skilled staff with a range of
competencies.
The following table documents some suggestions for the core skills that you will be looking for
along with some of the expected key roles. The supplier should be able to provide their views
Page 13 of 45
28 June 2004 Draft
on the particular skills that they see as critical to a successful implementation along with the
time commitment they see as appropriate.
Personnel
Project Manager
Key Competencies and Knowledge
PACS Coordinator (s)

And
System Administrator post
live
PACS Technical Lead
Knowledge of PCs and MS Windows

Project management skills, principles and practices
PRINCE II practitioner
Clinical background (helpful not mandatory)
Strong communication and interpersonal skills, high level of initiative
and problem solving skills, Team player
System implementation experience
Acceptance by colleagues
Knowledge of organisations business needs
Ability to delegate responsibilities and tasks
Ability to commit time during the implementation process with focus,
detail, drive and enthusiasm
Ideally someone who will remain with the organisation throughout the
life of the project
Knowledge of PCs and MS Windows
Clinical background (Preferably Radiography)
Strong communication and interpersonal skills
System implementation experience (useful)
Departmental knowledge and organisational knowledge / enterprise
working practices
Organisational skills
Negotiating skills, Team player, Sense of humour
Able to deliver training and disseminate knowledge to address
requirements of all users in the enterprise
Decision making Authority
Acceptance by colleagues
Strong problem solving skills
Positive attitude
Knowledge of PCs, MS Windows and Desktop OS
Knowledge of networks and communication protocols
Understanding of network infrastructure and hardware
Ability to teach others
Troubleshooting/problem solving skills with analytical approach
Database administration knowledge
These personnel will require advice and support from others around them (e.g. IT, Training,
Supplier, clinical groups)
When looking at the Implementation Team, consider the cluster and SHA implementation
plans. Setting up an expert PACS Implementation Team at SHA level may be beneficial as it
is very likely that implementations through a SHA will be staggered. As the system roles out
you develop a core team of expertise that works at each site, utilising local expertise, and
then as the implementation matures, this core team can evolve to also provide system
support, training and maintenance.
12
Ongoing System Management
A System Administrator / Manager will be required to provide ongoing system management.

The amount of time this takes will vary upon the maturity of the system and the size and
scope of the installation.
The role may be split between IT services and clinical personnel, but it is important that there
is a person responsible to those in the clinical arena. This person needs to be involved from
Page 14 of 45
28 June 2004 Draft
the formation of the PACS Project team. They should be responsible for facilitating the
provision of the following type of services:
Design of working procedures to be implemented during periods of system downtime
Training new staff and maintaining knowledge base
System maintenance
Data Integrity
QA
Main contact point and support
Trouble shooting
System Testing and training for subsequent upgrades
Specific examples of tasks undertaken by people already in this role are documented below.
12.1
Maintenance of System / Database
Design of working procedures to be implemented during periods of system downtime

whether such downtime is planned or unplanned
Ensuring that the PACS and RIS databases are updated and synchronised as soon
as possible after the resumption of normal service.
Maintaining integrity of database e.g. ensuring there are no unprofiled examinations.
Ensuring that correct images for the exam are contained in the relevant folder.
Checking that changes to any information on RIS are completed on PACS.
Ensuring that empty orders do not occur e.g. pelvis/spine images not all in pelvis.
Checking exams are verified to allow appearance on reporting worklist.
Creation of codes on RIS e.g. exam codes/radiographer codes/reporting codes etc.
Resending failed orders from RIS to PACS.
Checking system back-up on daily basis.
Auditing input errors RIS/PACS.
Correct any faults sent to PACS e.g. exams marked completed in error.
Keeping accurate and timely records with regard to all aspects of system etc.
12.2
Looking after the Internal Users
Providing effective training, with follow up if required.
Provision of User ID and password to acceptable users following training.
Keeping full records of training, user Ids etc.
Ensuring that users have correct privileges for system.
Setting up Academic (manual) Folders, and providing training on the same.
Creating protocol for input of new doctors twice yearly, and dropping leaving doctors
from the system.
Creation of compact discs etc for multi-disciplinary meetings/case studies etc.
Addressing user application problems.
Monitoring systems remotely to ensure correct usage/users logging out etc.
Page 15 of 45
28 June 2004 Draft
12.3
Service Provision for External Users
Managing the printing of films for other hospitals (patient transfers), controlling access
rights for those carrying out the activity.
Creation of compact discs with images for other hospitals/clinics.
Setting up Web Browser access for GP surgeries/clinics/hospices.
System demonstrations.
Department tours, to include explanations of post involvement.
Liaising with other hospitals and departments re any service involving PACS.
Responsibility for ensuring continued connectivity and interoperability with cluster

storage and with the NCRS
13.
Supporting the Paperless Environment
The significant proportion of communications both between and within departments is still
paper based and it is recognised that this will continue. However, the long term aim should
be the move to electronic based communications.
The reduction in paper is supported by electronic order communications and results reporting,
the electronic capture of all relevant and appropriate clinical information and the overall vision
of NCRS, of which PACS is a component.
Decisions about the migration of any existing analogue archive have to be made in the light of
the Trusts PACS wider role i.e. sending and receiving data from other PACS and the NCRS.
Patient demographic data also needs to be migrated with the amount of information migrated
being at least commensurate with the image data migrated.
14.
Identifying Potential Benefits
PACS can provide many benefits, some can be financially measured but many are aspects
that improve the quality of service and patient care, and indeed some improve the work
environment and the environment as a whole.
Each site will need to identify their expected benefits as a part of their business plan as the
type and volume of benefits achievable will depend upon local variances such as service
redesign , physical geography and services provided.
See appendix E for a table of example benefits.
Appendix E also includes an example from a site where the deployment of PACS has
improved services.
15.
Go-Live Period
The go-live date needs to be part of the implementation plan. Most clinical departments will
require between 6 12 weeks confirmation notice. When choosing a go live date consider
the timing of this in relation to workload (sometimes a go live over a weekend is preferable,
but it must be ensured that support staff are available either on site or on call) or reducing
workload from all areas (e.g. clinics) for a few days in advance is advisable, if appropriate.
Notices for patients and communications to all other staff and GPs are essential to explain
that a new system is being implemented.
The supplier should provide extra go live resources during this period and likewise the site
should provide extra staff. Extra supporting documentation / crib sheets should be made
available at workstations.
During this period it is important that you have a clear process for handling questions, issues
and general support calls, often a dedicated go live log is used. Typically the Project Manager
should be responsible for the escalation and resolution of the issues, while the System
Administrators will be key in actually resolving many of them during this time. A tier system
should be defined for the escalation of issues.
Page 16 of 45
28 June 2004 Draft
Any deviation from the go-live date should be communicated across the Trust at the earliest
opportunity.
Page 17 of 45
16.
28 June 2004 Draft
Measuring Benefits / Post Implementation Review
Typical areas included in a Post Implementation Review would cover:
Executive Summary
Introduction
Need for PACS
Match with Business Strategy
Match with IM&T Strategy
Technical solution delivered
Benefits realised against targets
Benefits delivered
Unexpected benefits delivered
Costs incurred against projection
Business risks
Technical risks/considerations
Business satisfaction
Suggested changes for the future
Recommendations
A post implementation review provides the opportunity to revisit what was done, and consider
any changes to processes that may be useful.
Page 18 of 45
17.
28 June 2004 Draft
Business Case Support See Appendix F
Page 19 of 45
Appendix A Film Digitisers
A.1
Film Digitisers
28 June 2004 Draft
Film digitisers perform the task of taking an image stored on film and converting that image
information into a digital data file suitable for storage on a computer. This file can
subsequently be stored, manipulated, compressed, transmitted and displayed like any image
file acquired to the PACS direct from an imaging modality.
The image resolution obtained after digitising a film depends on the scanner used. The
resolution used for a particular scan may also be selectable on the scanner. The ACR
(American College of Radiology) recommends a resolution of 2.51 1p/mm, 10 bits deep for
film digitisation for primary needs (American College of Radiology Standard for Digital Image
Data Management, 1998).
Film digitisers are built using one of three different technologies.
A.1.1 Camera
Light is shone through the film being digitised, and a digital camera captures the information.
This is a low-cost solution, but it is also a low-quality solution, and digitisers built around this
technology are probably not suitable for medical imaging work.
A.1.2 CCD (Charge-Coupled Device)

Light (usually from a specially-designed fluorescent tube) is shone through the film, and is
collected by a CCD array. A CCD is a sensitive electronic device that is capable of turning
light into electrical signal; in turn, this signal can be turned into digital data. The quality of the
image depends on the sensitivity of the CCD array, and the size and spacing of each element
within the CCD array.
A.1.3 Laser
A very thin beam of laser light is shone through the film; the beam is scanned across and
down the film until the whole image area is covered. The light transmitted through the film is
collected by a photomultiplier tube, which turns the light energy into electrical signal which is
then digitised. It has the advantages over CCD of producing a sharper image, and of having a
greater dynamic range, but the ultimate resolution is comparable to CCD. It is the most
expensive of the three options.
Film digitisers will typically be attached to the PACS network in a similar manner to other
acquisition devices, and images acquired from film digitisers onto the PACS should be
managed in the same way. This will include the creation of an examination on PACS to send
the image data to. One difference is that no local storage will be required, since the original
film acts as its own data store. Care should be taken to ensure that when the examinations
are displayed or listed on the PACS, the examination date is the actual date of the original
examination and not the date that the examination was digitised.
A.2
Digitiser Quality Control
Just as traditional processors require QA, film digitisers require regular checks to ensure that
they are performing adequately.
These checks should include:
Linearity of response of output pixel value to film optical density.
This ensures that a change in the optical density of the film from one region on the film to
another produces an appropriate change in the pixel data value stored in the image data file.
Pixel values of particular areas in the image data file can be determined using the tools
available on most PACS workstations, and the optical density of the corresponding region of
the film can be measured with a densitometer.
Consistency of response of output pixel value to film optical density.
Page 20 of 45
28 June 2004 Draft
This ensures that regions within a film - or on different films - that have the same optical
density produce equal pixel data values in the image data file. Again, pixel values in the
image data file can be determined using a PACS workstation, and the films optical density
can be measured with a densitometer.
Spatial resolution.
This is a measure of the ability of the digitiser to detect small features in an image or to
differentiate between two closely-spaced, but separate, features. A test film containing images
of suitable test objects, e.g. line-pair test tools, can be scanned and the digital image
produced can be visually inspected.
Contrast resolution.
This is a measure of the ability of the digitiser to produce a change in pixel data values for
regions in the image that are of similar, but different, optical densities. The testing method is
similar to that for the test for linearity of response, above.
Geometric distortion.
This is a test of the ability of the digitiser to create digital images which retain the proportions
of the original image. In particular, all straight lines in the original image should remain straight
when viewing an image reconstructed from the digitised image data
Page 21 of 45
28 June 2004 Draft
Appendix B Project Planning
Successful installation and implementation of a PACS system relies on good preparation and
planning. Plans are constructed by identifying the products required, the activities and
appropriate resources necessary to deliver them. Keep plans relevant, be aware of the
audience for the prepared set of plans and aim to provide an appropriate level of detail for
tasks and activities.
Time must be allowed for planning because it is a time consuming exercise. Planning for the
next stage should start towards the end of the current stage.
It is easier and more accurate to plan short stages than long ones. Plans should cover all
aspects of the project, giving everyone involved a common understanding of the work ahead.
Consider the following initial steps
Decide what activities should be done and by whom, All activities should be thought
through in advance and to a consistent level
Estimate how much effort each activity will consume
Estimate how long the activities will take and agree tolerance levels for this plan
Produce a time based schedule of activities
Calculate what the overall effort will cost, produce the budget from the cost of the
effort plus any materials and equipment that must be obtained
Assess the risks contained in the plan
B.1
An Example Summary of the rationale behind planning
The key areas of the project plan have been designed to:
Highlight key milestones during implementation.
Achieve core RIS and Modality integrations early to enable a smooth plug and play core
PACS installation.
Start archiving as soon as possible.
Allow for Theatre workstations to be installed over a holiday period, so as not to disrupt
services.
Install local workstations last so as to allow a build up of the digital archive before
softcopy reporting.
Deliver temporary CR installations during enabling works to allow for continuity of service.
Allow flexibility, as once the core system and interfaces are installed the remaining PACS
roll-out phases can be easily tailored.
B.2
An Example of Supplier Commitment to Project Management
Supplier commitment is vital to the success of the project. However, there may be more than
one supplier involved in the PACS project and the commitment must be from all the suppliers.
The Company commits to working with the Trust to Project Manage the PACS
implementation utilising the PRINCE 2 methodology.
The Company commits to delivering an on-site Project Manager as reasonably required,

to deliver the Project within the timelines detailed in Project Plan included as an
appendix to this Schedule.
The Company commits to this Project Manager attending on-site project meetings.
Should the Project Manager be absent from work a suitably trained and briefed
deputy will be appointed.
Page 22 of 45
28 June 2004 Draft
Full details of the Company Project Manager is given and so are details of all Company
personnel involved in delivering this project.
Third parties will be managed by the Companys Project Manager via agreements made
with these companies when a purchase order is raised for their required input.
Round table meetings with these vendors will be hosted by the Company, as
required, to ensure timely delivery of resources and manage the implementation
process.
B.3 Example Project Plan

ID
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Task Name
PACS Install
Contract signed
PACS room designated
Drawings for PACS room
Proposal drawings submitted
Draft Drawings supplied
Drawings Accepted
Delivery
Delivery methodology
Deliver PACS Site A
Deliver PACS Site B
Installation
Install core components Site A
Install core components Site B
Integrate Dicom modalities
Integrate non Dicom modalities
Mirror Broker
Remove temp broker
Test web functionality
Distribute Workstations
Test workstations
Installation Accepted
Training Program
System Admin
Web core training
Radiologists training
Training Acceptance
GO LIVE
Go live support
System Acceptance
Duration
169 days?
1 day?
1 day?
20 days
2 wks
2 wks
0 days
80 days?
1 day?
16 wks
16 wks
21 days?
2 wks
1 wk
5 days
5 days
5 days
1 day?
1 day?
1 day?
1 day?
0 days
15 days
5 days
5 days
5 days
0 days
0 days
5 days
0 days
Start
Mon 12/05/03
Thu 01/01/04
Mon 12/05/03
Tue 13/05/03
Tue 13/05/03
Tue 27/05/03
Mon 09/06/03
Fri 02/01/04
Fri 02/01/04
Fri 02/01/04
Fri 02/01/04
Fri 23/04/04
Fri 23/04/04
Fri 23/04/04
Fri 07/05/04
Fri 07/05/04
Fri 14/05/04
Fri 21/05/04
Fri 14/05/04
Mon 17/05/04
Tue 18/05/04
Tue 18/05/04
Wed 19/05/04
Wed 19/05/04
Wed 26/05/04
Wed 02/06/04
Tue 08/06/04
Tue 08/06/04
Tue 08/06/04
Tue 08/06/04
Finish
Thu 01/01/04
Thu 01/01/04
Mon 12/05/03
Mon 09/06/03
Mon 26/05/03
Mon 09/06/03
Mon 09/06/03
Thu 22/04/04
Fri 02/01/04
Thu 22/04/04
Thu 22/04/04
Fri 21/05/04
Thu 06/05/04
Thu 29/04/04
Thu 13/05/04
Thu 13/05/04
Thu 20/05/04
Fri 21/05/04
Fri 14/05/04
Mon 17/05/04
Tue 18/05/04
Tue 18/05/04
Tue 08/06/04
Tue 25/05/04
Tue 01/06/04
Tue 08/06/04
Tue 08/06/04
Tue 08/06/04
Mon 14/06/04
Tue 08/06/04
Qtr 1, 2004
Jan
Feb
Mar
Qtr 2, 2004
Apr
May
Q
Jun
18/05
08/0
08/0
08/0
Page 23 of 45
B.4
28 June 2004 Draft
Example Multi Site Plan
Below are two detailed project plans from multi site installations. The level of detail is greater,
note the provision of temporary imaging solutions to facilitate continuation of service.
B.4.1 Example 1
ID
1
Task Name
Phase 2 install
Duration
80 days
Start
Tue 08/06/04
May '04
Finish
Mon 27/09/04
Phase 1 sign off
0 days
Tue 08/06/04
Tue 08/06/04
Order CR
10 wks
Tue 08/06/04
Mon 16/08/04
Order workstations
16 wks
Drawings
20 days
Tue 08/06/04
Proposal drawings CR
2 wks
Tue 08/06/04
Mon 21/06/04
Proposal drawings workstations
2 wks
Tue 08/06/04
Mon 21/06/04
Draft drawings submitted
2 wks
Tue 22/06/04
Mon 05/07/04
Drawings Accepted
0 days
Mon 05/07/04
Mon 05/07/04
18 days
Tue 17/08/04
Thu 09/09/04
11
Temp install CR
12
refurb CR area
13
5 days
Tue 17/08/04
Mon 23/08/04
3 wks
Tue 17/08/04
Mon 06/09/04
Re-site CR
3 days
Tue 07/09/04
Thu 09/09/04
14
Acceptance test CR
0 days
Thu 09/09/04
15
Installation Workstations
21 days?
16
Refurb radiologist offices
17
Install Workstations
18
Test workstations
19
Site 1
Tue 07/09/04
Mon 27/09/04
Tue 28/09/04
Mon 04/10/04
Tue 05/10/04
delivery of CR
1 day?
Fri 10/09/04
Fri 10/09/04
Provide temporary imaging solution
4 days
Mon 13/09/04
Thu 16/09/04
22
Refurb Imaging area
5 days
Fri 17/09/04
Thu 23/09/04
23
Install CR Solo +unix Dips station
2 days
Fri 24/09/04
Mon 27/09/04
24
Configure cluster+training
5 days
Tue 28/09/04
Mon 04/10/04
25
Acceptance of install
1 day
Tue 05/10/04
Tue 05/10/04
26
Install workstation at site 2
5 days
27
Test all links
0 days
47 days?
Wed 06/10/04
Train CR core trainers
5 days
Tue 24/08/04
Mon 30/08/04
Core web training
5 days
Tue 31/08/04
Mon 06/09/04
31
Train Radiologists 1day per Radiologist
32
Training Acceptance
0 days
33
GO LIVE
1 day?
34
Go Live support
5 days
Task Name
PHASE 3
Duration
147 days
Start
Wed 16/06/04
Wed 06/10/04
Sign off Phase 2
0 days
Fri 29/10/04
Fri 29/10/04
Order CR
10 wks
Fri 29/10/04
Thu 06/01/05
4
5
Phase 3 PACS Accepted
16/06
Drawings
0 days
Wed 16/06/04
Wed 16/06/04
15 days
Fri 29/10/04
Thu 18/11/04
Oct '04
Predecessors
Fri 29/10/04
Thu 04/11/04
Site 3 CR
5 days
Fri 29/10/04
Thu 04/11/04
Site 4 CR
5 days
Fri 29/10/04
Thu 04/11/04
Site 5 CR
5 days
Fri 29/10/04
Thu 04/11/04
10
Site 6CR
5 days
Fri 29/10/04
Thu 04/11/04
11
Draught copies of all Drawings
10 days
Fri 05/11/04
Thu 18/11/04
6,7,8,9,10
12
All Drawings Accepted
0 days
Thu 18/11/04
Thu 18/11/04
11
14
Site 2
Fri 07/01/05
Wed 23/03/05
20 days?
Fri 07/01/05
Thu 03/02/05
15
Temp Install CR
2 days
Fri 07/01/05
Mon 10/01/05
3,4
16
Refurb Imaging area
5 days
Tue 11/01/05
Mon 17/01/05
15
17
Install CR
2 days
Tue 18/01/05
Wed 19/01/05
16
18
Install Printer from Hexham
1 day?
Thu 20/01/05
Thu 20/01/05
17
19
0 days
Thu 20/01/05
Thu 20/01/05
18
20
Training
10 days
Fri 21/01/05
Thu 03/02/05
19
Thu 03/02/05
21
22
Train Core trainers

Site 3
10 days
Fri 21/01/05
11 days
Fri 04/02/05
Fri 18/02/05
23
2 days
Fri 04/02/05
Mon 07/02/05
24
Refurb Imaging area
5 days
Tue 08/02/05
Mon 14/02/05
23
25
Install CR Solo
2 days
Tue 15/02/05
Wed 16/02/05
3,24
26
Configure cluster+training
2 days
Thu 17/02/05
Fri 18/02/05
25
27
Acceptance of Install
0 days
Fri 18/02/05
Fri 18/02/05
26
28
Site 4
12 days
Mon 21/02/05
Tue 08/03/05
3 days
Mon 21/02/05
Wed 23/02/05
27
30
Refurb Imaging area
5 days
Thu 24/02/05
Wed 02/03/05
29
31
Install CR Solo
2 days
Thu 03/03/05
Fri 04/03/05
30
32
Configure cluster+training refresh
2 days
Mon 07/03/05
Tue 08/03/05
31
33
0 days
Tue 08/03/05
Tue 08/03/05
32
Site 5
11 days
Wed 09/03/05
2 days
Wed 09/03/05
Thu 10/03/05
33
36
Refurb Imaging area
5 days
Fri 11/03/05
Thu 17/03/05
35
37
Install CR Solo
2 days
Fri 18/03/05
Mon 21/03/05
36
38
Configure cluster+training refresh
Tue 22/03/05
Wed 23/03/05
37
39
Wed 23/03/05
Wed 23/03/05
38
0 days
09/09
12/10
19/10
25
Nov '04
01 08
15
22
Dec '04
29 06 13
20
27
Jan '05
03 10
17
24
Feb '05
31 07
14
21
Mar '05
28 07
14
21
28
Ap
0
18/11
20/01
18/02
08/03
Wed 23/03/05
35

2 days
05/07
21
29
34
08/06
29/10
5 days
54 days?
25
Site 2 CR
Installation
N
18
Wed 27/10/04
13
Oct '04
04 11
Wed 20/10/04
Thu 21/10/04
27
Tue 19/10/04
Wed 20/10/04
20
Tue 19/10/04
Tue 19/10/04
Finish
Thu 06/01/05
Sep '04
30 06 13
23
Tue 12/10/04
30
ID
1
16
Wed 27/10/04
29
10 days
Aug '04
02 09
Tue 12/10/04
Tue 12/10/04
Tue 24/08/04
26
Tue 12/10/04
21
Training
19
Tue 05/10/04
Fri 10/09/04
20
28
12
Tue 05/10/04
1 wk
23 days?
Jul '04
28 05
Thu 09/09/04
Tue 07/09/04
3 wks
1 day?
21
Mon 05/07/04
Installation CR
14
Mon 27/09/04
Tue 08/06/04
10
Jun '04
31 07
Page 24 of 45
23/03
28 June 2004 Draft
B.4.2 Example 2
ID
Task Name
XXX HOSPITALS NHS TRUST
Duration
July
Contract Discussions
Sign Contract
1 day
Order Equ ipment
80 days
IMPAX
16 wks
ADC
12 wks
PAXPORTS
6 wks
HARDCOPY
6 wks
Sign off functional specification
11
Install 'Ghost Broker'
2 day s
12
Conf iguration and Testing with Torex
4 wks
13
Deliv ery of Broker Hardware
1 day
14
Migration to new Hardware
15
Testing
16
Acceptance tests and sign off
17
NON-DICOM MODALITY INTEGRATION
7 day s
Test images arriv ing at PAXPORT
3 day s
21
Acceptance and sign of f
23
DELIVER/INSTALL CORE PACS
22/11
27/12
21/07
25/08
October
29/09
03/11
January
08/12
12/01
16/02
April
22/03
26/04
31/05
July
05/07
09/08
October
13/09
18/10
22/11
27/12
25/08
October
29/09
03/11
April
22/03
26/04
31/05
July
05/07
09/08
1 day
25
Installation
3 day s
26
Install CS5000 into Theatres
3 day s
27
Broker Messaging and Testing
3 day s
28
Connection/Testing NON DICOM Images
3 day s
29
Connection/Testing DICOM Images
3 day s
Task Name
30
1 day
Duration
July
Acceptance and Sign Of f
1 day
MILESTONE 2:ROLL-OUT DS3000 AND CS500026.5 days
32
Deliver to site A
33
Install Basement Reporting MRI
34
Testing Images and Desk-Top Integration
35
Acceptance Tests
36
Install Reporting CT
37
38
Acceptance Tests
39
Install CT Scanner Reporting
40
41
Acceptance Tests
42
Install Ground Floor Reporting
43
44
Acceptance Tests
45
Install and Test CS5000 Workstations
46
Deliver to site B
47
Install CT Reporting
48
49
Acceptance Tests
50
Install Consultant Station
51
52
Acceptance Tests
53
Install and Test CS5000 Workstations
54
Deliver to site C
55
Install Seminar Room
56
57
Acceptance Tests
58
Install Radiology Seminar Room

Task Name
59
60
Acceptance Tests
61
Install Reporting Area
62
63
Acceptance Tests
MILESTONE 3: CR IMPLEMENTATION
1 day
0.5 day s
1 day
1 day
0.5 day s
1 day
1 day
0.5 day s
1 day
1 day
0.5 day s
1 day
1 day
2 day s
1 day
0.5 day s
1 day
1 day
0.5 day s
1 day
1 day
2 day s
1 day
0.5 day s
1 day
1 day
0.5 day s
Duration
July
16/02
October
13/09
18/10
22/11
January
27/12
31/01
1 day
0.5 day s
1 day
1 day
25 days
Pre-Installation Work site A ITU
1 day
66
Deliver site A ITU
1 day
67
Installation site A ITU
68
Additonal training, testing, acceptance
2 day s
69
Temp. Installation site B A&E
2 day s
70
Pre-Installation site B A&E
2 day s
71
Installation site B A&E
2 day s
72
3 day s
73
De-Install temporary install
1 day
74
Temp. Installation site C
2 day s
75
Pre-Installation site C
2 day s
76
Installation site C
2 day s
77
78
De-Install temporary install

MILESTONE 4: WEB ROLL-OUT
January
08/12
12/01
1 day
65
84
October
13/09
18/10
3 day s
Deliv er to site
83
09/08
22 days
24
82
July
05/07
1 day
Test worklist arriv ing f rom Broker
22
81
31/05
15 days
20
80
26/04
1 wk
Install PAXPORTS to modalities
79
April
22/03
1 wk
Deliv er PAXPORTS to site
64
16/02
3 day s
19
ID
January
08/12
12/01
10 day s
18
31
October
29/09
03/11
MILESTONE 1: BROKER/CORE PACS/PAXPORTS

102 days
10
ID
25/08
1 d ay
21/07
194.5 days
1 day
3 day s
1 day
30 days
Roll-out of web based imaging to all clinical locations

6 wks
MILESTONE 5: ACCEPTANCE
Acceptance testing
MILESTONE 6: FINAL ACCEPTANCE
Final acceptance rev iew
5 d ays
5 day s
5 d ays
5 day s
Page 25 of 45
B.5
28 June 2004 Draft
An Example of a PACS Implementation Reporting Structure
Communications is an important part of the Implementation process, detailed below is an

example of a reporting structure. Not all implementations would necessarily follow this
structure as the teams and practice would differ between sites.
SENIOR MANAGEMENT
TEAM
SUPPLIER TEAM: Healthcare Director
TRUST Project Sponsor: Medical Director for
Clinical Services
Monthly Report
Issue Resolution
THIRD PARTY SENIOR

MANAGEMENT
Issue Resolution
Issue Resolution
PROJECT STEERING COMMITTEE

SUPPLIER TEAM:
Informatics Business Manager
Business Analyst
Informatics Account Manager
Project Manager
TRUST TEAM:
Trust Project Manager
General Manager Imaging
Radiology Service Manager
Lead Radiologists
Monthly Report to
steering committee
Issue resolution
IMPLEMENTATION TEAM
SUPPLIER TEAM:
Project Manager
Informatics Account Manager
Regional PACS Specialist
Regional Service team leader
Lead Engineer
TRUST TEAM:
Project Manager
Implementation Radiographer
Report to
Implementation team
-Purchase
orders
-On-site
commitment
-Integration
-Acceptance
THIRD PARTIES
RIS Suppliers
PAS Suppliers
HIS Suppliers
Modality Suppliers
PM feeds
implementati
on team
Implementation Team
feeds Installation Team
INSTALLATION TEAM
INSTALLATION
TEAM
SUPPLIER TEAM:
Engineers
SUPPLIER TEAM
TEAM: (incl LSP and PACS Vendor)
Applications
Engineers Specialists
Applications Specialists
TRUST TEAM:
Project
TRUST Manager
TEAM:
Project Manager
PM Manages
Third Party
Companies:
This structure reflects experience in single

Trust Implementations.
It is recognised there is less experience of
implementing multi-site PACS
Page 26 of 45
Appendix C Technical and Interfaces
C.1
Networking
28 June 2004 Draft
The OBS states that The Contractor shall check that the Authority networks and connections
are satisfactory to deliver the performance described in Section 4.3 (Solution Requirements)
and the Contractor shall state whether any changes are required to Authority networks. The
Contractor shall state the minimum network and connections required to deliver the
performance described in section 4.3.
In addition The Contractor shall be required to warrant the performance of their system over
the network, or propose enhancements if the network is not adequate.
It should be noted that the NPfIT PACS Project Initiation Document (PID) suggests that A
robust LAN is essential. PACS must not be installed on a network less than 100Mbps
Ethernet.
The PID also recognises the dependency of N3 for the Delivery of Wide Area Network (WAN)
network infrastructure work to provide required PACS bandwidth and availability (which will
provide services for more than just community PACS). Image data volumes have been shared
with N3 to aid their capacity planning.
So in summary the supplier will typically undertake a survey of the local Area Network and
make recommendations. An example of one is available from the NPfIT if required.
C.2
Communication Standards
C.2.1 DICOM (Digital Imaging and Communications in Medicine)

The DICOM standard was established to aid the distribution and viewing of digital medical
image data. Conformance to the DICOM standards helps devices within a PACS to
communicate. It should be noted that merely conforming to DICOM does not guarantee that
any two devices will be able successfully to communicate; it must be ensured that the
devices particular implementation of DICOM is complementary.
The OBS dictates that The Service shall adhere to DICOM 3.0 and its successors to enable
interoperability of multiple suppliers equipment in a network environment. It documents at
length the various capabilities the supplier is required to deliver.
C.2.2 IHE (Integrating the Healthcare Enterprise)

Again the OBS covers this requirement, The service provider shall provide as part of the
response to this document a conformance table for all of its products in relation to the
'Integrating the Healthcare Enterprise' (IHE) standard profiles and the date that these were
tested and proven. Any development paths to aspects of HIPAA compliance relevant in the
NHS shall be stated.
C.2.3 HL7
IHE (Integrating the Healthcare Enterprise) is a global initiative designed to advance the data
integration in healthcare. It aims to develop a framework to ease the integration of, and
information flow between various medical information systems, with the ultimate goal of
ensuring that all required clinical information is correct and readily available to the relevant
users. Currently, interfacing systems can be difficult due to the different standards and
implementation of those standards employed by such systems. IHE aims to define how
existing standards may be used in order to facilitate communications between computer
systems used in healthcare; initially, IHE will concentrate on DICOM and HL7 but mat extend
to other standards if necessary.
The OBS states that The Contractor shall ensure that the PACS service shall be fully
integrated with other systems within the Authority and must confirm that the IHE, DICOM and
HL7 standards are the basis for the integration with other systems. Also where appropriate
The Contractor shall migrate communications to HL7 v3.
Page 27 of 45
C.3
28 June 2004 Draft
Interfaces
When designing and implementing a PACS it is important to give detailed thought to storage,
management and acquisition of non-image data (e.g. patient demographic data, examination
details, clinic appointments, etc).
Much, if not all, of the non-image data required by a PACS is available on external systems
such as Radiology Information Systems (RIS), Patient Administration System (PAS) or
Hospital Information Systems (HIS). The standards described above should be used for the
sharing of this data and the sort of information required includes aspects of examinations on
RIS, current patient location and forthcoming appointments (HIS, PAS and RIS)
To allow for efficient communication between an external information system and a PACS, it
may be necessary to use an interface engine. An interface engine is a computer system
which sits between two (or more) information systems, and reformats the output from one
system into a form readable by the receiving system. In a PACS implementation, this interface
engine is generally referred to as a PACS Broker. It typically receives information on patient
demographics and examination bookings from a RIS and/or a HIS, and passes this data on to
the PACS, following appropriate reformatting by the broker. Data can also flow from the PACS
to an external system should the external system have the ability to use data from the PACS
(for example information from an imaging modality regarding the acquisition status of an
examination). The PACS broker may maintain its own database of information derived from
information acquired from the attached devices.
The advantages of integrating other hospital information systems with a PACS include:
A single point of entry for data means consistency, and avoids duplication of effort
Access to scheduling information aids image data storage management. Information

on scheduled clinic visits or radiological examinations can be sent from the HIS or the
RIS to the PACS. The PACS can then use this information on which patients will be
attending the healthcare institution to ensure that all relevant images for those
patients are available in on-line storage in time for their attendance.
Access to patient location information allows for filtered worklists. PACS can obtain
information on patient status and location from the HIS, and use this to present useful
worklists to radiologists and clinicians. For example, a list of examinations for all
patients on a particular ward can be created.
C.4
Digital Image
One of the key features of a PACS is its ability to store and transfer image data. This is a
digital representation of the original image, and all image data acquired onto the PACS must
be digital.
Many imaging modalities already produce data in digital form (for example, CT or MR) and
these modalities may be attached directly to the PACS (although it is possible that some
intermediate interfacing unit will be required). Other modalities generate image data as
analogue film (for example, traditional x-ray) or video display (e.g. older ultrasound scanners)
only and this analogue data must be converted to digital form before it can be sent to the
PACS.
Images produced on traditional film can be converted to digital form using a film digitiser (See
Appendix A2) and indeed video displays can use frame grabbers to be converted to digital
output.
In recent years, Computed Radiography (CR) and Direct Radiography (DR) have become
increasingly important for plain x-ray imaging. Both CR and DR, together with modalities such
as CT and MR, produce digital data.
C.4.1 Digital Image Capture

To capture a digital image using, for example, computed radiography (CR), there is a similar
chain of events to those in capturing an image to film.
load an unexposed imaging plate into a cassette
Page 28 of 45
28 June 2004 Draft
expose the plate to x-ray radiation
produce the image by passing the plate through a CR plate reader
create and store a computer file containing the image data
Other imaging modalities will form the image by processes appropriate to that modality, but
however the image is formed, the end product is a computer file containing the image data.
The only exception to this is where computed radiography is used to print film, with the
creation of an image data file being a temporary step towards production of the film.
C.4.2 Acquisition of Digital Data on to the PACS

Once data is in digital form, it can be transmitted to PACS storage. This storage may be
centralised, with a single on-line storage facility that can accept data from anywhere in the
institution and similarly distribute the data, or local storage, where image data from the local
modality can be stored, for subsequent distribution as necessary. Following acquisition, image
data is likely to be stored on on-line storage. The data may subsequently be saved on nearline or off-line archive storage.
It should be noted that different imaging modalities produce images requiring different
amounts of data for their representation. A typical chest examination generated by CR, for
example, can be of the order of 8 MB, whereas a single CT slice image may only be of the
order of 0.5 MB. Note that the figure for CT is for a single slice; modern multi-slice scanners
can generate many hundreds of slices and can therefore place heavy demands on the PACS
network and data storage facility.
Calculation of the amount of data required for an image is straightforward: it is the size of the
image in pixels multiplied by the number of bits required to store each pixel. For example, for
a typical CR chest image:
Image width:
1760 pixels
Image height:
2140 pixels
Number of bits/pixel:
16 bits
Thus to store a single CR chest image requires 1760 x 2140 x 16 bits = 60262400 bits.
Assuming 8 bits per byte, 1024 bytes per kB and 1024 kB per MB, this calculates to 7.2 MB
per image. Lossless compression can typically reduce the storage requirements by about a
factor of 2.
In order to calculate the archive storage requirements for a PACS, the data on the typical
image sizes for each modality can be used. For each modality, multiply the typical image size
by the average number of images per exam, and multiply this figure by the number of
examinations performed in a year. This will give the annual storage requirements. This figure
can be modified according to the amount of compression to be used on the data.
C.4.3 The Database Server and DICOM Gateway

The main PACS server within a healthcare enterprise holds a database of all patient
examination information, which is usually a copy that the PACS server receives from the RIS.
This database includes details of patient demographics, and the examinations the patient has
had since the PACS was installed (and possibly earlier examinations, if digitised). It also
contains the information necessary for the PACS to be able to find the images for those
examinations, and to direct copies of the images to local storage as required (depending on
the architecture of the system). For systems connected to the NHS spine, there may also be
the facility to request patient information and image data stored elsewhere in the NHS.
The PACS server also performs routine scheduled tasks required for system maintenance,
and allows the system administrator to carry out manual tasks and system tuning as required.
The regularly scheduled tasks can include daily and/or weekly backups, pre-fetching of
historical images for review purposes, flushing of the on-line storage. Manual tasks can
include management of user accounts, reconciling discrepancies within the database, and
managing interfaces with external information systems.
Page 29 of 45
28 June 2004 Draft
The storing of image data uses the DICOM standard. Most medical image acquisition devices
produce image data compatible with the DICOM standard. There may be occasions when
imaging acquisition devices that are not DICOM-compliant will be required to send images to
a PACS. It can be possible to acquire images onto the PACS by use of a DICOM gateway.
In a similar manner to which a PACS broker allows information flow between a PACS and
external information systems, a DICOM gateway can allow image data to flow from imaging
devices to the PACS.
C.4.4 Digital image display

Once the image data file has been created, the image can be displayed by transmitting this
data file to a viewing workstation. Here the image data is rendered to form the image, and this
image is displayed on the workstation monitor. Typically, display monitors are less bright than
conventional light boxes, but they have image processing capabilities that allow for contrast
resolution enhancement across the range of brightness. Display monitors and workstations
are discussed in more detail later.
C.4.5 Digital image storage

Digital images can be stored on a number of different types of media, including computer hard
disks, tapes, optical discs, compact disc. Reasonable care should be taken that the
environmental conditions are appropriate for the type of storage. Generally this means
avoiding extremes of temperature and humidity, and keeping the environment clean and dustfree. Management of the images is much simpler than with film, since the PACS management
application will log all stored files and their location. The problem of lost films should be much
reduced, since all original image data files remain permanently in PACS storage (it is only
ever a copy of stored data files that is transmitted over the network for display), and there
should be no manual misfiling problems.
PACS has the ability to archive image data files and make the image data available for
viewing at one or more remote viewing stations, the image data being transmitted over a
computer network. The image archive may be centralised (i.e. a single, large repository for all
the image data acquired from the various imaging modalities around the site) or distributed (a
number of archive devices attached to the PACS network).
Medical imaging can create large amounts of image data, both in terms of the number of
images generated and the size of the image files. It therefore follows that large amounts of
storage are required for the image files.
An archive identifies stores and protects data, whether this data is in electronic form or in
traditional paper and film form. Whatever form the archive takes, decisions have to be made
regarding the amount of storage space needed physical storage space for archiving of
traditional media or computer storage space for archiving of digital data. Thought must be
given both to immediate and to future needs. Thought should also go into the requirements
for the back-up of image data.
On-line storage. A storage device that makes images available immediately on demand. It is
generally a RAID (Redundant Array of Inexpensive Disks) device, consisting of a large
number of hard disks. Its advantage is that data can be found and delivered very quickly. The
price of RAID storage has decreased dramatically in the last few years and their storage
capacity has increased. Although disks that have high access times and have a high build
quality are still more expensive than the disk in a PC, it is now economically feasible when
tendering for a PACS to specify an Everything Online (EOL) RAID. This usually allows the
trust to maintain at least one to two years of examination data online.
Near-line archive. A large-capacity storage that is capable of storing more data than the online storage, often several years worth of data, which may be sufficient to store a sites entire
image archive. The near-line archive is the primary archiving device for storing the master
copy of acquired image data files; it delivers copies of these image data files to the on-line
storage when required. Delivering data from the near-line archive to the on-line storage takes
a short but appreciable period of time, generally in the order of minutes or tens of seconds.
Near-line archive devices can be built using a number of different technologies, e.g. tape or
disc.
Page 30 of 45
28 June 2004 Draft
Off-line archive. Should the near-line archive become full, a third line of storage can be
used. Space is freed in the near-line archive by removing archive media that become full, and
replacing them with blank media. The removed media can be stored on a shelf, and replaced
in the near-line archive device should the data contained upon it be required. Note that this
replacement will require manual insertion by PACS support staff, and it could be several hours
before the data becomes available. The removed media should be stored in a safe place, and
needs to be managed properly so that the disk or tape containing the required data can easily
be found.
Recent increases in the capacity of systems, together with price falls, are leading to a shift in
thinking away from the above definitions of storage (which are focussed on the ease of
accessibility of the data), to definitions based on the lifetime of the data within storage
classes. As disk-based systems increase in capacity, it becomes feasible to store several
months data on-line, with the complete archive being stored near-line in a tape or diskbased archive. Thus storage can be thought of as being in one of two categories: short-term
or long-term.
The most common types of hardware used to provide storage solutions are those using
magnetic and optical technologies. This can be further broken down into disk (e.g. RAID,
DVD, Magneto Optical Disk (MOD)), and tape (e.g. Advanced Intelligent Tape (AIT), Digital
Linear Tape (DLT), Linear Tape Open (LTO) Digital Audio Tape (DAT)) technologies.
The media used in archive storage are housed in a device known as a jukebox. A jukebox can
contain one of many types of media (CD-ROM, tape or disks). The jukebox moves the media
from its storage location, by means of a robotic mechanism or carousel, to a reading/writing
area; the time for this movement of disk to read is usually in the order of 10 30 seconds.
C.4.5.1
Networked Storage
Computer networks can be attached to two types of networked storage topologies, known as
Network Attached Storage (NAS) and Storage Area Network (SAN). These storage topologies
are becoming increasingly common in PACS.
Network Attached Storage (NAS)
In NAS, the storage device is usually a RAID attached directly to the network, below
illustrates the NAS attached to a LAN.
It is controlled by a NAS controller, which is a processor with an operating system, for

example a UNIX computer. This will see all the other devices on the network allowing each to
be able to access and store data on the disk array.
Page 31 of 45
28 June 2004 Draft
Storage Area Networks (SAN)

The implementation of a PACS, either radiology or hospital wide has a significant impact on
the hospital LAN. The size of the image files can cause a significant deterioration in the
transfer of data, which has a subsequent effect on the operation or workflow of the radiology
department.
The inevitable integration of PACS with the information systems of a trust (HIS & RIS) the
large image data files are transferred on a dedicated network, freeing up the hospital wide
LAN bandwidth for the transmission of patient related information.
The SAN allows the hospital to implement the PACS whilst retaining its legacy systems
reducing the cost of implementation. The ease of implementation and the seamless scalability
of a SAN makes this technology an excellent solution to the storage and backup for a PACS.
A Storage Area Network (SAN), is a network that sits behind the local area network (LAN)
connecting the servers into centralised disk storage and backup libraries, a schematic is
shown in fig 1 below. This allows for a scalable storage solution where each server has
access to the storage pool creating an optimal and cost effective storage environment. The
SAN uses a different protocol to transfer the data, this is known as Fibre Channel Protocol
(FCP).
Storage Area Network (SAN) Schematic
C.4.6 Film printers

It is likely that even a filmless PACS will retain the ability to print to film or other hardcopy
devices. The need to print film can arise under a number of conditions, including planned
system down-time for maintenance or upgrades; unplanned downtime should failure of the
system or a key component occur, etc.
Film printers require regular checks to ensure that they are performing adequately. These
checks should include such tests as:
Linearity of film optical density to pixel value.
This ensures that a change in the pixel data value in the image data file produces an
appropriate change in the optical density of the printed film.
Consistency of film optical density to pixel value.
Page 32 of 45
28 June 2004 Draft
This ensures that regions in the image that have the same pixel value have the same optical
density when printed to film.
Spatial resolution.
This is a measure of the ability of the film printer to print small features in an image or to allow
two closely-spaced, but separate, features in an image to be visualised separately on a film.
This is a measure of the ability of the film printer to produce a change in optical density for
regions in the image that are of similar, but different, pixel values.
This is a test of the ability of the film printer to print films which retain the proportions of the
reconstructed image. In particular, all straight lines in the original image should remain
straight on the printed film.
Other hardcopy printing devices may be appropriate; these devices include inkjet printers,
thermographic printers and laser printers. These devices also require regular checks to
ensure that they are performing adequately, and these checks will be similar to those
described above for film printers.
C.5
Monitors
Guidance is often asked for on recommended workstations for image display. The information
below has been collated to assist people who are considering their requirements for PACS
workstations.
It is hard to be prescriptive as the types and numbers required will depend upon the source of
the images (e.g. CT, plain x-ray), local workflow and clinical process. Careful consideration
must also be given to the ergonomics and environmental conditions of the areas in which the
workstations are to be placed.
Workstations comprise a combination of base station (most often, a PC), software to allow the
display and manipulation of medical images from the PACS and a display device. This
guidance note concerns the display device component of workstations only.
The most important factor is that the display device should be fit for use, be available at
required clinical locations and maintained in appropriate condition. It should be the Suppliers
responsibility to work in conjunction with you to provide or recommend the appropriate
devices in the relevant locations to meet the clinical needs of the service that is being
provided. Note that specialist displays and/or workstations may also be required for remote
access to images, e.g. on-call consultants reporting from home. Where there is a monitor that
does not meet the required standard it is recommended that it is identified as 'Unsuitable for
PACS diagnostic use' and marked in an agreed way locally. Users should be told not to use
monitors so marked for diagnostic work.
C.5.1 Image Quality

As stated above fitness for purpose is essential. The image presented should be suitable for
its intended purpose, whether this be for diagnosis, review or treatment planning. Medical
image display quality is of fundamental importance to the overall effectiveness of a diagnostic
imaging practice, and it is vital that the softcopy displays do not compromise image quality.
Note that it is not only the display device that determines displayed image quality. Quality of
image acquisition and storage of the image after acquisition (e.g. if compression is used) also
have a major effect.
C.5.2 Displays
The following documents actual experiences from sites that have implemented PACS
workstations and can be used as an indicative guide.
Displays purchased for diagnostic use are generally monochrome. This is because
monochrome displays can be manufactured to be significantly brighter than colour displays,
Page 33 of 45
28 June 2004 Draft
thus improving the contrast ratio and so the contrast resolution of the display. Typically a
contrast ratio of at least 400:1 is desirable for a diagnostic display.
Colour screens may be appropriate in less demanding situations (i.e. for image review only)
or when colour information is present in the original image. Note that as well as being less
bright, colour displays may also demonstrate reduced spatial resolution when compared to a
monochrome display.
A choice is available between traditional Cathode Ray Tube (CRT) displays and the new
Liquid Crystal Displays (LCD). For most purposes the image quality of the two devices is
comparable and other factors may sway the decision on which type of device to purchase
LCD flat-panel displays are lighter, take up less space and produce less heat when compared
to CRT displays, but may be more expensive. At the high end of the market (5 mega pixel
devices) CRT displays still have a small edge in quality compared to LCDs.
For reporting workstations: 2 or 3 mega pixel (2k or 3k) 17 or 19 portrait monitors are
typically used. (An example size seen is 2048 pixels x 1560 pixels). These displays are most
often used in pairs, to allow for comparison of two or more images at full resolution. 5 mega
pixels screens are seen for mammography.
Review / web workstations: SVGA quality, with web browser software adapted for access to
images and textual reports is typical. These are usually devices of around 1 mega pixel (1k)
display size.
It is important to have a high-quality video display card in the base workstation to drive the
display screens. Standard PC display cards will not be able to provide data of sufficient quality
and resolution to allow a diagnostic quality display to perform at its maximum capability.
Advice should be sought from the display vendor as to the availability of appropriate display
cards.
Further information on displays can be obtained from PACSnet (contact information can be
found at http://www.PACSnet.org.uk) who provide a free PACS technical service to the NHS.
C.5.2.1
Quality Assurance of Display Devices
It is essential to ensure that all workstations and screens used for diagnosis and review are
performing adequately for their designated tasks.
Tests that can be carried out on display monitors include:
Luminance.
Peak display brightness should be within specification the brightness should be measured at
several points on the screen, and all points should be within a specified range.
A test image containing a number of steps of different brightness should be displayed. It

should be possible to discern each step. Particular attention should be paid to the top and
bottom end of the range. The SMPTE test image is a useful image to use for this test.
Focus.
A visual inspection of a test image should be made to ensure that the image is adequately
sharp over the display area.
A test image which includes straight lines and circles should be displayed. Ensure that
straight lines are straight to within defined limits, and similarly that circles are circular to within
defined limits.
Flicker.
The display should be judged for unacceptable amounts of flicker. Significant amounts of
flicker can result in user fatigue.
Dropouts.
Page 34 of 45
28 June 2004 Draft
Visually inspect the entire screen area for artefacts. CRT tubes may suffer from small areas
where dark spots are apparent, due to a lack of phosphor on the screen at this area. LCD
displays can have dark or light spots where individual crystals are malfunctioning
Investment of resources into performing QA checks must not be underestimated, remember
that maintaining records of test results in order to evaluate any deterioration in performance
over time is also important.
C.6
Web Browsers
As part of their product lines, most PACS vendors offer the possibility of using web browsers
to view images and clinical reports in addition to the use of dedicated PACS workstations. A
web browser is a standard piece of software most commonly used to display pages from the
World Wide Web, for example Netscape Navigator or Microsoft Internet Explorer. The use of
web browsers has several advantages, both for the purchaser and for the user:
Web browsers are a simple, robust technology. They have been under development for
many years, and, provided they can access the required data reliably, perform well.
They provide a low-cost, high functionality application.
Web browsers can run on relatively low specification computers, often on computers that
already exist within a healthcare institution.
Many users will already be familiar with web browsers through use of the World Wide
Web, and so it is possible that little additional training will be required.
Hospital I.T. support staff are likely to have familiarity with the use and installation of web
browsers.
However, although it is possible that a PACS web browser will run on a standard desktop
computer, as discussed above thought should be given to the display used to look at the
images. The standard monitor may not be of adequate quality for the viewing of PACS images
and it is important to consider the intended use of images displayed on a web browser.
Another point to consider is the functionality provided by the web browser for the display and
manipulation of images: although the features offered by web browsers have become
increasingly sophisticated in recent years, web browsers are still unlikely to match the
software available in a dedicated manipulation and viewing application.
In order for web browsers to be able to obtain the image data files required for the display of
images, it is usual for a PACS that supports web browsers to include a web server. This is a
computer that is responsible for the delivery of image data to those web browsers that request
it, and may be a machine separate from the main PACS server and image data store. The
server can also deliver the workstation software to the workstation and thus allow software
upgrades to be maintained centrally.
There may be concern regarding the security of using web browsers. Although standard web
browsers are used, of the same type as those used to access the World Wide Web, this does
not mean that everyone with access to the internet can view the data. It is possible to limit
access to particular computers or areas of the hospital network. In addition, it will be
necessary to type in a standard username and password before images can be displayed.
Page 35 of 45
28 June 2004 Draft
Appendix D Practical Environment Requirements
D.1
Radiologist Office and Reporting Areas
The primary function is image viewing and one has to consider the following to comply with
Health and Safety issues and ensure diagnostic accuracy.
Workstation ergonomics
Take into account the needs of the individual; consider how tasks will be performed with
particular regard to Health & safety issues e.g. RSI and the need for regular breaks.
o
Power and network points
Carefully plan adequate power and network points in appropriate position

o
Desk height, size etc. to take into account
PACS monitor(s) footprint

Separate RIS/ multifunction PC & monitor & associated keyboard &
mouse (this is the norm for most departments)
Paperwork
Task lighting
Seating
Needs to appropriate for desk height and safe working
Environment
Ambient lighting and reflection

o Diffuse lighting upwards
o Common plain wall colours to avoid reflections from pictures, patterned wallpaper
etc.
o Task lighting
o Reduce shadows cast from windows, doors, corridor etc
o Avoid reflections from other monitors
o Windows should have blinds. Lighting should be controllable i.e. dimmer switches
should be installed
o Radiologists training should include education on how to control lighting to the best
advantage and explanations why it is important to do so
Temperature
Air conditioning needs to be considered in conjunction with the Estates Department
Noise Pollution
Acoustic screening can be effective in shared offices
If you have a grouped reporting Room

As well as the above consider the relative positions of multiple reporting workstations
Teaching and lecture areas

o These environmental principals above should be applied in conference rooms,
lecture theatres and training locations
o A dedicated room such as thus will reduce noise and disturbance from visiting
clinicians within the main department and reporting areas
Education
o
PACS users should be instructed in the most beneficial use of the equipment.
This training should cover the areas listed above, in particular, instruction on
Page 36 of 45
28 June 2004 Draft
posture and adjustment of PACS equipment and the control of ambient

lighting are very important.
D.2
Radiographer Zone
Same considerations as discussed apply
Lack of space may be an issue reconsider your current workflow when positioning
monitors
Ambient lighting is important for image QA, and for aspects of Red Dot reporting
D.3
PACS Computer Room
Ideally this should be sited as close to Radiology to quickly assist with urgent access e.g.
system restart required by the system engineer and PACS system Administrator
Air conditioning will be required. Many items of computer equipment are sensitive to
temperature and may have safety cut-outs that will operate at high temperatures or
may have components that will malfunction at high temperatures (e.g. disks in a RAID
storage device). It is important that the temperature in the computer room is
controlled and monitored.
Fire Prevention control equipment, using appropriate distinguishers
Access to equipment will be required use proper racking
Physical Security of access and hardware and unauthorised access to data
Disaster recovery - Back up hardware needs to be stored in a separate building
PACS Administrator would be expected to have an office with sufficient space to allow for
independent access to multiple systems.
Page 37 of 45
Savings in film and chemical budgets

Saving in above maintenance contracts
Reduction in length of stay (quicker and
multiple / simultaneous viewing and
remote reporting)
Saving in admin time searching and filing
films
Saving in Hospital space for film storage /
chemical storage
Savings in porter / transport time of films
Y
Y
Saving in Dark room techs
Qualitative
Benefits
Quantitative
non-cash
releasing
Appendix E Table of Example Benefits
cash
releasing
28 June 2004 Draft
Who benefits
Trust / SHA
Trust / SHA
Patient
Trust / SHA
Trust / SHA
Trust / SHA
Trust / SHA
Reduction in litigation
Trust / SHA
Trust / SHA
Waste disposal savings
Reduction in cost of copy films
Trust / SHA
Environmental
Trust / SHA
Stationery savings packets and labels
Trust / SHA
Reduced on call requirements as remote

reporting can be done.
Trust / SHA
Reduction in radiation exposure (repeats

(windowing allowed) and lost films) and
(Patient and staff) and less wasted time
Patient
Staff
Quicker results
Patient
Trust / SHA
Staff
Increased patient through put.
Reduced waiting time and LOS
Patient
Trust / SHA
Patient
Trust / SHA
Patient
Staff
Reduced admissions and events as films

always available
Perception of modern service with a
patient centred delivery
Patient
Trust / SHA
Page 38 of 45
Reduction in pt journeys as images done

locally and sent away for expert opinion /
dx
Patient
Staff
More images will be reported reducing

clinical risk
Patient
Trust / SHA
Better reporting resulting in more accurate

and timely Dx (image manipulation and
enhancement, availability of remote expert
opinion) (Remote expert opinion saves
clinical travel time) (Again 24/7 reporting
remotely)
Previous views always available in any
location and simultaneously (no lost films)
Patient
Trust / SHA
Patient
Trust / SHA
Patient
Trust / SHA
Trust / SHA
Staff
Links to EPR / NCR
Patient
Health community wide viewing of results
Patient
Trust / SHA
Patient
Trust / SHA
Benefits
cash
releasing
Qualitative
28 June 2004 Draft
Quantitative
non-cash
releasing
Remote reporting by specialists available
Referrers spend less time chasing

images / visiting imaging department in
prep for ward rounds etc.
Experienced clinical staff retention
Who benefits
Less time wastage (staff and pt)

associated with clinic appt aborted as
images not to hand
Patient
Trust / SHA
Staff
Remote learning and case studies / multi

disciplinary teams simultaneous remote
viewing (not driving = cash releasing)
Patient
Trust / SHA
Staff
Patient
Trust / SHA
Trust / SHA
Better pt info on image reducing clinical

errors
Smoothing of workload to deliver equity of
service / release staff for more high value
(remote reporting expert opinion) PAN
Community reporting
Page 39 of 45
Patient / image / consultant in same place

at same time
Patient
Trust / SHA
Increases job effectiveness, (using right

people in right job) performance and
quality = flexible working which is part of
the EU working time directive.
Process realignment
Staff
Trust / SHA
Staff
Removal of chemicals (COSHH)
Trust / SHA
Environment
Staff
Benefits
cash
releasing
Qualitative
28 June 2004 Draft
Quantitative
non-cash
releasing
More spacious environment
Who benefits
Clinical governance / auditing
Trust / SHA
Staff
No carrying heavy / bulk film packets

around (staff and patients)
Patient
Staff
Staff can personally develop and further

improve IT skills
Staff
Tangible and Value for Money
Trust / SHA
Trust / SHA
Trust / SHA
Trust / SHA
Trust / SHA
Cancer waits and other targets more

achievable
Reduction in litigation costs
Staff retention in NHS (reduction in

advertising costs)
Secure viewing by authorised users
Page 40 of 45
E.1
28 June 2004 Draft
An example of: How has the deployment of the PACS improved

services'
With the opening of its new hospital in 2001 this Trust installed both a PACS (a computerised
x-ray archive system), CR (a facility to digitise standard x-rays) and various items of x-ray
equipment that produce digital images (CT Scanner, MRI, angioscope, fluoroscope). At the
same time the Trust installed a wide bandwidth network and improved monitors to enable
clinicians in wards and departments to view these x-rays.
A full benefits realisation appraisal has not been completed so this discussion is incomplete
and partially anecdotal.
Improved reporting time by radiologists

o
The radiologist now has much speedier access to images and there has been
a reduction in the time between an inpatient or casualty patient being x-rayed
and his report being available.
Additionally the Trust has radiology services on more than one site. The
PACS system means that the radiologist does not need to be at the remote
site to report on the image again improving reporting times.
Improved radiological diagnosis

o
Although the image presented to the radiologist is not as detailed as a traditional

x-ray, this lack of resolution is beyond the capability of the human eye in any
event
The digital image gives the radiologist the ability to manipulate that image, to
compare two or more images and to view a series of cross-sections as a
single moving image. This certainly helps the radiologist who would otherwise
have to hold the images in his mind and may result in more accurate
diagnosis.
Reduction in radiological hazard

o
Fewer images need to be taken because images can be manipulated by the

radiologist, there are less exposure failures and less lost films. This will result
in a lower overall radiological hazard to patients.
Availability of images to clinicians

o
Images are now available where the clinician requires them and when the
clinician requires them.
In the past the clinician has had to await delivery of the x-rays to the ward
and to rely on clerical procedures delivering x-rays to outpatients at the same
time as the patient. In both cases if the consultant needed access to historical
x-rays this resulted in further delay.
Now the clinician has immediate access to x-rays from any workstation.
This results in an improvement to speed of clinical diagnosis, in an earlier

start to informed patient treatment and potentially in an improvement to the
health of the population.
Specifically for outpatients this will mean a reduction of repeat appointments

due to missing x-rays.
Remote consultation
o
When one health professional seeks advice from another, this can now be
done interactively. This could be a radiologist seeking advice from a
colleague. They no longer need to meet for both to view the x-ray together
thus improving the speed with which a diagnostic report is issued.
Page 41 of 45
GP Patient admission
o
28 June 2004 Draft
It is possible now for a GP to contact a medical clinician asking whether a

patient whose x-ray he has received should be admitted and for the medical
clinician to view the x-ray and respond positively, prioritising the patients'
admission, whilst the patient is still in the GP's surgery. Not only is the speed
of admission improved but also the GP's service to his patients.
Availability within EPR

o
The digital nature of PACS will enable it to be included within the patients'
EPR. This will mean that the clinician will be able to find it alongside the
patients' other electronically held data again improving the delivery of
healthcare.
PACS is very popular with clinicians and improves their morale. Making their
job easier because x-rays are available where and when they need them to
facilitate efficiency and effectiveness.
Page 42 of 45
28 June 2004 Draft
Appendix F Business Case Support
This section is a working draft and is based on the best available information. The detail of the
Business Case Templates may change as decisions on central funding and detailed local
contractual arrangements are put in place, but this does provide a way forward for addressing
the local service specification, costs, benefits, and implementation planning. It will be updated
to reflect process changes as they emerge.
F.1
Introduction
The process assumes a business case is required at individual NHS organisational level. It
can however be aggregated if a number of organisations want to work together. This may be
where local business needs are best met by a group of Trusts working together. Alternatively
an SHA may wish to proceed with all its Trusts as part of the same exercise.
Local Trusts will have to pay for elements of the implementation and the running costs over
the lifetime of the contract. Each Trust either acting individually or as part of a group will need
to understand and accept the financial consequences of their PACS implementation. The
process ensures that Trust specific figures will be available whatever consortium approach is
adopted.
The financial model envisages a mixture of capital investment and revenue. Decisions on
central capital funding for local PACS implementation are yet to be made.
The process consists of 3 elements:
A set of Business Case Templates pre populated.
A toolkit which is used to drive the detailed local specification and financial model.
A workshop(s) run by the central team to facilitate the completion of the templates.
The whole package is aimed at enabling NHS organisations to speedily proceed to PACS
implementation. It represents the minimum requirement consistent with good practice.
The Templates are based on the standard 5 case model as detailed in the Treasury Green
Book and the Department of Healths Capital Investment Instructions.
The process can therefore satisfy local requirements for strong governance on investment
decisions. It provides the necessary business justification for Board consideration and
approval to proceed.
The requirements of the detailed local PACS specification will be met through the Local
Service Provider. There will be no need to undertake any separate procurement activity.
Individual Clusters will provide information on how these arrangements will work in practice.
This means that an Outline Business Case is not required and this process produces in a
single stage the case for local approval.
Page 43 of 45
F.2
28 June 2004 Draft
The Business Case Templates
The aim is to provide an easy to use set of guidance for NHS Users. The written material
coupled with the workshops is intended to enable the rapid development of a business case
in house.
The templates cover the 5 sections of the standard model. Wherever possible they are pre
populated with information which is common to all locations. They contain guidance and
prompts to assist in the local customisation
F.2.1 Strategic Case

The majority of the material will be common based on the national strategic drivers. This will
have to be given a local context with an explanation of priority, e.g. service reconfiguration,
new build, other related IT infrastructure issues.
F.2.2 Economic Case

The options are appraised within the context of costs, risks and benefits to the organisation
making the investment. This will focus on the National Programme arrangements for the
provision of additional services (i.e. those not fully centrally funded). A common set of Critical
Success Factors are provided
F.2.3 Commercial Case

The toolkit provided enables the generation of a detailed local service specification. This is
derived from the National Specification contained in section 115 of the OBS for the Integrated
Care Record Service. It addresses the key contractual detail supporting the local investment.
The National Programme will produce a standard approach for contracts for additional
services.
F.2.4 Financial Case

The tool kit provides a cost model. It is driven by information from the local service
specification and the component costs for implementation provided by the cluster LSP.
F.2.5 Management Case

This provides a high-level implementation plan for local customisation. Including a model of
possible local project management arrangements. These are provided as a start point but will
need to flex to reflect local preferences, e.g. SHA wide steering groups and other cluster
specific arrangements.
F.3
The Toolkit
As described above this provides the framework within which the key data is captured and
manipulated to develop the Financial Case. The data is clearly defined and will be available
from sources within the Trust. Much of the data has already been collected within the context
of the Modalities surveys and the work on the Financial Templates. This information is
required for the Toolkit.
F.4
The Workshops
These support the use of the written and interactive material described above. There is a
common structure, which can be modified to meet the specific requirements of individual Trust
or groupings.
The process is aimed to assist the author of the business case and their attendance is critical.
That individual will have a different title according to the local approach. It may be the SHA or
Trust lead or both.
In addition a senior Radiology User is needed to lead on the local service specification. This
may be the Radiology Services Manager but once again it is for the local project to nominate.
A finance representative from each participating Trust will be needed to assist with elements
of the costed benefits and the financial template
Page 44 of 45
28 June 2004 Draft
There may be other interested parties such as the Senior Clinical Sponsor who wish to
attend. The above list is the suggested minimum and the detail of the workshop package and
attendees will be agreed as part of the Initial Contact.
F.4.1
Initial Contact
This can be by phone or meeting. The aim is to explain the process and agree how to
proceed. The discussion will identify:
How the generic process maps onto the local user requirement
The key players and local constituencies
Specific local issues, e.g. existing PACS contracts, PFI, immediate operational requirements
Funding flows
Agree timescales and attendees for workshop/s.
Workshop 1
The first workshop provides:
Overview of the whole process
Use of toolkit for local service specification
Development of the Cost Model
Identification and resolution of specific local issues
Workshop 2
The second workshop provides:
Validation of the service specification
Validation of cost model
Benefit and Risk appraisal
Development of Implementation Plan
Handling specific local issues
Workshop 3
The third workshop provides:
Review of all templates
Benefit realisation plan
Preparation for Approval, e.g. Board Summary
Post approval and National Programme issues.
In addition to the workshops a help line will be provided by the Central PACS team to assist
users with all elements of the Business Case Templates as required. Initially Mark Freeman
on 0113 280 6489
The PACS facilitators attached to each cluster are also available to provide support on
implementation and associated issues.
This suggested programme can be flexed and adapted to meet the specific requirements of
the Trust or group developing the PACS business case.
F.5
Summary
NHS Users wanting to arrange an Initial Contact should contact their local PACS Facilitator or
use the help line number provided. The latest documentation will then be sent and an Initial
contact arranged.
Page 45 of 45

PACS Practical Experience-5570

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PACS Practical Experience-5570

Uploaded by

Copyright:

Available Formats

PACS Implementation Guide

PACS Implementation Guide

PACS Practical Experiences

PACS Practical Experiences

Please contact the Document

This is a controlled document.

PACS Practical Experiences

PACS Practical Experiences

Doc Reference Number

PACS Practical Experiences

PACS Practical Experiences

PACS Practical Experiences

PACS Practical Experiences

PACS Implementation Guide

Terms of Reference and Scope

National Programme for IT

Electronic booking of appointments (eBooking)

NHS Care Records Service (NCRS)

Electronic Transmission of Prescriptions (ETP)

An underpinning IT infrastructure with sufficient connectivity and broadband capacity

PACS Practical Experiences

PACS Practical Experiences

Road Map / Summary

Obtain Executive, Clinical and IT Commitment / Create Project Team

Identify PACS Community

Identify Benefits (include baseline)

Approve Business Case

Review Suppliers Implementation Plan and Technical plan

Agree supplier/Trust Implementation Plan

Start site preparation (including staff aspects and technical architecture)

Post Implementation Review & Benefits analysis

Feed back to National Team

PACS Practical Experiences

Executive and Clinical Commitment

Prior to implementing PACS

Which pieces of equipment is DICOM conformance statement? Which DICOM data

What is the cost of upgrades to DICOM equipment to enable interoperability?

It should never be assumed that a piece of equipment supports the

PACS Practical Experiences

PACS Practical Experiences

3.3.1 Standardisation of numbering and exam codes

3.3.2 Migration of Data

No prior images digitised and no data migrated.

Digitised films will need to be reconciled in PACS and RIS.

3.3.3 Reports and Outputs

PACS Practical Experiences

How long will there be application support

What will be the commitment of the integration specialists

What is the long term support? From

PACS supplier is it 24/7?

CR /DR supplier is it 24/7?

In house Network supplier is it 24/7?

In house local IT is it 24/7?

PACS Systems Administrator is it 24/7?

What are the standard system reports?

Will the training be cascade

Will they train all end users

Will there be documentation

of the training done

How are the reference files populated?

Which reference files are pre-populated by the supplier

Which reference files need populating by Systems Administrator

Who enters user and security settings (passwords and privileges)