MHRA 04130 - PACS evaluation: Agfa PACS at Queen Elizabeth

Transcription

December 2004
MHRA 04130
PACS Evaluation: Agfa PACS at
Queen Elizabeth Hospital NHS Trust,
Woolwich
best choice • best practice
www.mhra.gov.uk
nww.medical-devices.nhs.uk
About MHRA evaluation reports.
What you can expect.
The Device Evaluation Service (DES) aims to provide independent and objective evaluations
of medical devices available on the UK market. Specialist centres, mainly in NHS Trusts, do
the evaluations under long term contract to, and in accordance with protocols approved by,
the Medicines and Healthcare products Regulatory Agency (MHRA). The evaluations are
usually of a unit supplied by the manufacturer. We would expect this unit to be
representative of the product on the market but cannot guarantee this. Prospective
purchasers should satisfy themselves with respect to any modifications that might be made
to the product type after MHRA’s evaluation. The reports are intended to supplement, not
replace, information already available to prospective purchasers.
The MHRA DES does not have access to any information held by the Agency in its capacity
as the Competent Authority for the UK, apart from any information already in the public
domain. The reports will contain data given by the manufacturer on the regulatory status of
their devices but, apart from this, they are not an indicator of the regulatory status of a
product. Occasionally, DES refers products to the regulatory arm of the MHRA for
considerations of breaches of the legislation governing medical devices. DES plays no
further part in any regulatory investigation that ensues and does not have advance
notification of any regulatory action that may follow.
How to obtain MHRA reports.
To order evaluation reports, a copy of the publications catalogue or to sign up for our e-mail
alert service contact:
MHRA
Orders Department,
Room 1207,
Hannibal House,
Elephant & Castle,
London,
SE1 6TQ.
T:
020 7972 8181.
F:
020 7972 8105.
E:
des@mhra.gsi.gov.uk
Visit www.mhra.gov.uk for a comprehensive list of publications, details of forthcoming
evaluations, services and contacts.
Colour reports.
Full colour versions of all reports published after 2002 are available from the NHSnet at:
nww.medical-devices.nhs.uk
PACS Evaluation: Agfa PACS at
Queen Elizabeth Hospital NHS
Trust, Woolwich
Alan R. McBride, Jonathan E. Turner, Annelise Wilken, Keith Stean,
Dewinder S. Bhachu & Saida Jivani
PACSnet
BENCE-JONES OFFICES (PERIMETER RD.)
ST. GEORGES’S HOSPITAL
LONDON
SW17 0QT
TEL: 020 8725 3315
FAX: 020 8725 3293
WEBSITE: HTTP://WWW.PACSNET.ORG.UK
© Crown Copyright 2004
Apart from any fair dealing for the purposes of research or private study, or criticism, or review, as permitted
under the Copyright, Designs & Patents Act, 1998, this publication may only be reproduced, stored, or
transmitted in any form or by any means with the prior permission, in writing, of the Controller of Her Majesty’s
Stationery Office (HMSO).
Information on reproduction outside these terms can be found on the HMSO website (www.hmso.gov.uk) or
e-mail: hmsolicensing@cabinet-office.x.gsi.gov.uk.
The MHRA is an executive agency of the Department of Health.
ISBN 1 84182 902 1
MHRA 04130 PACS Evaluation: Agfa PACS at Queen Elizabeth Hospital NHS Trust, Woolwich
Contents
1. Introduction
1.1 Purpose of the review
1.2 Workload
1.3 PACS Supplier (Agfa-Gevaert Ltd.)
2. Acquisition modalities
3. General PACS description
3.1 Agfa PACS Software
4. Image Storage
4.1 Storage philosophy
4.2 Storage Hardware
4.2.1 Online Image Storage Hardware
4.2.2 Web Server Storage Hardware
4.2.3 Nearline Image Storage Hardware
4.3 Storage retrieval times
4.3.1 Online Storage Retrieval Times
4.3.2 Nearline Storage Retrieval Times
4.4 Web Server Storage Capacity
4.5 Storage Hardware Redundancy
5. Integration with external systems
6. Backup Management
7. System recovery
7.1 Data Recovery
7.2 Recovery from electrical interruption
8. Reliability, Error Management and Support
8.1 Hardware
8.2 Maintenance and Support
8.3 Training
9. QEHT Network Configuration
9.1 Anti-Virus Software
9.2 Network Management
9.3 Network Security
9.4 Redundancy Provisions
9.5 Disaster Recovery
9.6 Issues
9.7 Future Developments
10. Image distribution
10.1 DS3000 Reporting Workstations
10.2 Review Workstation
10.3 Web-based distribution
10.3.1 Searching on Main Archive from the Web 1000
10.3.2 Conferencing on Web1000
10.3.3 Web1000 Functionality
10.3.4 Training and Helpdesk support for Web1000
10.4 Reporting Room
1
1
1
1
2
3
5
6
7
7
8
9
9
10
11
11
14
15
19
20
22
23
25
25
25
27
27
27
28
29
31
31
32
32
33
33
33
34
34
35
35
37
37
37
37
38
10.4.1 Reporting Room Temperature
10.4.2 Reporting Room Illumination
10.5 Workstation Monitors
11. Printers and Digitisers
11.1 Printers
11.2 Film Digitisers
12. Security
13. Workflow
13.1 Acquisition Workflow: Data entry to PACS
13.2 System Failure
13.3 Retrieval of historical films
13.4 Reporting
14. Future Developments
15. Conclusion
16. Manufacturer’s Comments
Web Server Capacity 4.3
Training and Support Section 9.3
Internal Support
Ongoing Communication
References
Glossary
2
38
41
42
43
43
45
46
47
47
47
48
48
49
50
51
51
51
51
52
53
54
1. Introduction
Queen Elizabeth Hospital NHS Trust provides acute hospital services to the areas of
Greenwich and Bexley, in south-east London, which have populations of 214,540 and
218,000 respectively[1]. The Trust is a new build hospital, built under the government’s
Private Finance Initiative (PFI), transferring to its present site in April 2001. The PFI
partners are responsible for all the facilities management, with separate PFI
arrangements in place for medical equipment. The Trust has 485 admitting beds with a
throughput of patients in finished consultant episodes (FCE) of 48,190, it has an annual
A & E attendance of 77,321 and an annual outpatient throughput of 169,808, which
includes all first and follow up appointments[1]. The results are summarised in the table 1.
The total number of staff in the trust is 2210, this being broken down into 1622 clinical
and 588 non-clinical.
Table 1: General Information on Queen Elizabeth Hospital NHS Trust
Beds
485
Admitting beds
Annual FCE’s
48,190
excluding well babies
Annual A & E
Attendances
77,321
Annual Outpatient
Attendances
169,808
1st and follow-up appointment Consultant Outpatient Appointments
Source: Commission for Health Improvement (CHI)
[1]
1.1 Purpose of the review
The review and analysis of the PACS sets out to examine
1.
2.
3.
4.
5.
The resources of the Trust, its size and layout.
The equipment used to implement and support the PACS to fulfil the radiological
needs of the Trust.
The network infrastructure of the Trust.
The service the system gives to users, including speed of retrieval.
Workflow.
1.2 Workload
The radiology department performs approximately 120,000 examinations per year. The
table below, table 2, shows the patient throughput in number of examinations for the
financial year 2002 – 2003, when a total of 123,126 studies were performed. Note that
separate details are not available for mobiles and theatres; these data are included in the
total for plain x-ray examinations.
1
Plain
Fluorography
Ultrasound
CT
MRI
Angiography
Nuclear
Medicine
Mobiles
Theatres
Mammography
Dental
Other
Table 2: Radiology Workload of QEH NHS Trust
74885
2821
32070
4861
1936
1261
2565
N/A
N/A
1559
N/A
1168
Source: QEHT
1.3 PACS Supplier (Agfa-Gevaert Ltd.)
Agfa can trace its roots to Aktiengesellschaft fur Anilinfabrikation (a dye factory started in
1867) and to L. Gevaert & Cie (a photography-paper supplier started in 1890). The
present Agfa-Gevaert Group has its headquarters in Mortsel, Belgium. It makes and
markets imaging systems for photographic, graphic arts, motion picture, and medical
imaging processes. Agfa-Gevaert’s consumer products include film, photographic paper,
and equipment for photofinishers and labs. Its medical equipment includes films,
chemicals, software, and printers for digital radiography and other medical applications.
Agfa are well-established in the UK, with a significant number of PACS installations.
2
2. Acquisition modalities
The following image acquisition devices, table 3, are attached to the PACS:
Table 3: Modalities attached to the PACS
Modality
X-Ray Equipment
DR
Fluorography
Angiography
CT
MRI
Mobiles/Theatre
Mammography
Ultrasound
Nuclear Medicine
2 Philips
4 Siemens
1 Xograph OPG
1 Hologic DEXA
1 GE
1 Siemens Polystar
1 Sireskop Fluoroscopy
1 Siemens Angiostar
1 Siemens AR Star CT
1 Philips Gyroscan Intera 1T
1 Siemens Image Intensifier ISO-C
1 Siemens Image Intensifier SM
Compact
1 Philips Image Intensifier BV300
1 Siemens Mobilette
4 GE Mobiles AMX4+
Toshiba
2 Toshiba Aplios
1 Toshiba PV600
3 ATL 5000
1 ATL 3500
1ATL 3000
1 Aloka
1 GE Millenium
Source: QEHT
Modalities that are DICOM conformant communicate directly with the PACS using the
DICOM standard messaging protocols; those modalities that are not DICOM compliant
send data initially to an Agfa “Paxport,” a device which will convert the data to DICOM
format and send it to the PACS.
Table 4, shows the quantity of data generated by each of the acquisition modalities. This
information is used to calculate the storage and networking requirements of the PACS.
3
Table 4: Quantity of data created by each examination
Modality
Computed Radiography (CR)
Computed Tomography (CT)
Magnetic Resonance Imaging
(MRI)
Nuclear Medicine (NM)
Ultrasound (U/S)
Fluorography
Angiography
Average Number of
Images per Exam
Average Data/Matrix
size per Image (Mb)
Average Data/Matrix
size per Exam (Mb)
1.4
40
7.5
0.5
10.5
20
118
0.14
16.52
30
13.5
14
14
0.003
0.06
2
0.5
1
0.81
28
7
Source: QEHT
4
3. General PACS description
The Queen Elizabeth Hospital Trust (QEHT) is a single site trust. The system installed in
the QEHT, figure 1 is the Agfa IMPAX Release 4.1 SP3, running Oracle V.8.0.5 as the
image database. The IMPAX software was first introduced into the UK for evaluation in
January 2001 and was available generally in March 2001.
Figure 1: Conceptual network diagram of Agfa PACS at QEH
Source: Agfa-Gevaert Ltd4
The system at QEH was accepted on 31st July 2001 and the service contract came into
effect on 1st August 2001. The system has had the planned upgrades laid out in the
contract with Agfa, the latest such upgrade taking place in April 2004.
The PACS is based at one site, the main Queen Elizabeth Hospital NHS Trust site in
Stadium Road, Woolwich, London. The configuration of the PACS is hospital-wide and
has a central PACS cluster for storage, archive and distribution.
The system software runs on the Archive and the workflow servers, and as with many
software products, is controlled by a licence key - if the licence key is in place then the
computer can run the software. At Woolwich the software licence key is linked to the
Media Access Control address[3], more commonly known as the MAC address, an
identifier unique to each computer.
5
3.1 Agfa PACS Software
The system relies on both UNIX and Windows NT operating systems:
Operating System Software:
PACS server
Solaris 2.6
Web server
Windows NT 4 Server
Reporting Workstation
Windows NT 4 Workstation
Web Browsers
Review Stations
Agfa Impax 4.1 SP2 this was upgraded to SP4 in September
Agfa Web 1000 3.1 (QEH)
PACS Software:
Reporting Workstation
2004
Review stations
6
4. Image Storage
4.1 Storage philosophy
The PACS installation at Woolwich has centralised storage and distribution for image
data. It is designed to provide an “everything online” service for images viewed on PACS
reporting workstations. Image data is stored on a 1 TB RAID (sufficient for approximately
18 months’ image data) with archive storage available on a 6TB Digital Linear Tape
library.
Images viewed via web browsers are served from a separate web server which is
designed to store approximately six months’ image data.
When a patient is booked in on at the RIS – Patient and study data sent to the Workflow
server which adds the study to the modality worklist for the particular modality and the
Database Manager creates an entry for the patient on the database archive ready to
receive the images.
The images acquired by the modalities are matched to the workflow server and the
database manager stores the images to the Archive server. This then stores a copy of
the images onto the RAID archive and copy is also sent to the web server for web
distribution.; The images are backed up to the tape jukebox as a batch job overnight, this
process is highlighted in figure 2.
Figure 2: Image storage flow
Image Data
Study Data
Patient Entry on RIS
Workflow server
Imaging Modality
Database Server
Archive Server
Image Archive RAID
Web Server RAID
7
Jukebox Archive
The storage was initially designed to provide an EOL service for 18 months of storage.
There are a series of ‘Autopilot Rules’ set up by the user to manage the storage of image
data. These are pre-defined instructions to be carried out at defined storage levels.
1.
2.
3.
4.
Nothing can be deleted from the archive unless flagged as archived
No deletion takes place until the cache is 90% full
The system will provide 48 hrs of free space, which is calculated on
the rate at which the system is currently filling.
At present the oldest or least used files are removed
There is a constant evaluation of the storage space required at the QEHT and as part of
this process there is a discussion on the move to a policy of pre-fetching.
At this stage QEHT is actively seeking the purchase of a new Multi-slice CT scanner
which both QEHT and Agfa-Gevaert Ltd. are aware will have an impact on the operation
of the system. Any impact will be in the area of data management would alter the storage
policy between web storage and the main PACS archive.
The web server at the QEH uses Agfa’s Web1000 software to manage the distribution of
image data to the workstations in the wards and clinics of the Trust. The rules for storage
of the images on the web cache are similar to the main archive, however only there is
only six months of continuous image data on the web server.
As with the main Archive server a similar set of ‘Autopilot Rules’,a series of study
management protocols using the AGFA Autopilot function, which have been set-up for
web storage. These are pre-defined instructions to be carried out at defined storage
levels.
1. Nothing can be deleted from the archive unless flagged as archived
2. No deletion takes place until the cache is 90% full
3. The system will provide 48 hrs of free space, which is calculated on the
levels the system is currently filling.
4. At present the oldest or least used files are removed
4.2 Storage Hardware
The IMPAX PACS operates an “Everything Online” (EOL) storage philosophy (see
Glossary) with an installed RAID size of 1.02 TB. The PACS archive storage hardware is
a SUN A5200 RAID (see figure 3, table 5) with a SUN enterprise 450 server, both of
which are set-up with RAID level 5 protection. This provides a distributed parity over all
the disks[2] providing a high level of protection against data loss and allowing for the
continued storage and retrieval of data should one of the disks in the RAID fail.
Additional RAID level 5 storage is available on the Workflow server which has 364 GB of
storage and on the archive server which has a 509 GB internal RAID, these servers are
both SUN enterprise 450 servers.
8
4.2.1 Online Image Storage Hardware
Figure 3: SUN A5200 RAID
Table 5: SUN A5200 RAID setup
RAID
Manufacturer
Product
RAID Level
Capacity
SUN
A5200
5
1.018TB
Source: QEHT & Agfa-Gevaert Ltd
Courtesy of SUN Microsystems™
4.2.2 Web Server Storage Hardware
The web server at the QEH uses Agfa’s Web1000 software to manage the distribution of
image data to the workstations in the wards and clinics of the Trust.
The web server runs on a Dell PowerEdge 2400 server, with associated image data
stored on a Dell PowerVault 211S RAID storage system (referred to by Agfa as the “web
cache”), see Figures. 4 and 5 respectively. The initial size of the PowerVault disk storage
was 208 GB; this was increased to 524 GB in September 2003. Table 6 details the
configuration of the Web server.
Figure 4: Power Edge 2400
Figure 5: PowerVault 211S
Courtesy of Dell Inc.
Courtesy of Dell Inc.
9
Table 6: Web server and storage configuration
Hardware Manufacturer
Hardware used
RAID Level
Size (GB)
Capacity
No of Exams stored online
Months data online
Software used
4.2.3
Dell
Power Edge 2400 and PowerVault 211S
5
524 GB
37,237
6 months
Agfa Web 1000
Nearline Image Storage Hardware
Table 7: DLT Jukebox configuration
Figure 6: Storagetek L180 Tape Library
DLT Jukebox
Manufacturer
Product
Type Storage
Capacity
Other Information
Storagetek
L180
DLT 7000
6.23 TB
Tape capacity 35GB, 174 SLOTS
Expected Lifetime: 10 years
Courtesy of StorageTek™
The nearline archive at QEH utilises a Digital Linear Tape (DLT) jukebox, see figure 6
and table 7. The jukebox has 180 slots, 174 of which are used for image data storage
with the six remaining slots used for diagnostic purposes or for cleaning tapes. The tape
storage utilizes a robotic system, see figure 7, which moves the tapes from the holding
position to the read or write drive. The time to take the tape from its location in the
jukebox to the read drive is dependant on its position in the jukebox and can vary from
10 to 21 seconds from removal of tape to ready to read state. The L180 has redundancy
provision built into the system; it has three read/write drives which each have their own
independent power supply and controller.
10
Figure 7: Storagetek L180 internal robotics
Courtesy of StorageTek™
4.3 Storage retrieval times
The timings for the retrieval of images from the storage media as described in the
contract between QEHT and Agfa-Gevaert Ltd are shown in table 8.
Table 8: Table of storage retrieval times
Storage Type
Online Storage
Nearline Archive
Contracted Exam Retrieval Time
2 – 3 seconds
3 – 4 minutes
Source: Agfa-Gevaert Ltd & QEHT
4.3.1 Online Storage Retrieval Times
To determine the actual retrieval times for the PACS in operation under a variety of
conditions, a series of measurements were taken from a variety of studies: CT;
ultrasound; CR and Fluorography (see figures 8 a-d).
11
Figure 8a: CT Time data
Average Time to obtain CT examination from Archive
3.50
3.00
Time (secs)
2.50
2.00
1.50
1.00
0.50
0.00
0
10
20
30
40
50
60
70
80
90
100
Avg Time 09/10/03 (20 Images)
Avg Time to Last Image (90 images) (10/10/03)
Avg Time to Last Image (20 images) (10/10/03)
Figure 8b: Ultrasound time data
Average Retrieval Time for US from Archive
4.00
3.50
3.00
2.50
Time (secs)
No of Images
2.00
1.50
1.00
0.50
0.00
10
11
12
13
14
15
16
17
18
19
No of Images
Avg Time 09/10/03 (TOD 1120)
Avg Time 10/10/03 (TOD 1020)
12
Avg Time to Last Image 10/10/03 (TOD 1020)
20
Figure 8c: CR time data
CR Retrieval Times from Archive for one image studies
3.00
Measured Time (sec)
2.50
2.00
1.50
1.00
0.50
0.00
0
2
4
6
8
10
12
Sample No
Avg Time 09/10/03 (TOD 1740)
Avg Time 10/10/03 (TOD 0940)
Figure 8d: Fluoro time data
Average retrieval time from Archive for Fluoro Images
3.50
3.00
2.50
Time (sec)
Avg Time 09/10/03 (TOD 1030)
2.00
1.50
1.00
0.50
0.00
0
2
4
6
8
10
No. of images
Average Time 09/10/03 (TOD 1130)
Average Time 10/10/03 (TOD 1030)
13
Time to Last Image 10/10/03 (TOD 1030)
12
4.3.2 Nearline Storage Retrieval Times
Measurements were also taken for the Nearline Archive; these are shown in figures 9a
and 9b. All the studies measured were CR images, and all were shown to be within the
stated times described in the contract between QEHT and Agfa-Gevaert Ltd. However
there were two exceptions. One study took 461 seconds to be retrieved; this may have
been due to the image data being on a tape at the furthest point from the read drive and
being at the end of the tape.
More significantly another study failed to be retrieved at all from the nearline archive.
This was attempted twice and after 11 minutes each time the system ‘timed out’.
However it proved possible to retrieve the image from the RAID, suggesting that the
study had, in fact, been retrieved but that notification of the retrieval failed. It is not
understood why such a failure occurred.
Figure 9a: Nearline Storage retrieval Times (Time of Day (TOD) 14.10 – 14.25)
Time to retrieve Images from Nearline Storage (TOD 1410 - 1425)
200
160
140
120
Time (secs)
180
100
80
60
40
20
0
0
1
2
3
4
No of Images
14
5
6
Figure 9b: Nearline Storage retrieval Times (TOD 15.40 – 17.35)
Average Retrieval Time for US from Archive
4.00
3.50
3.00
Time (secs)
2.50
2.00
1.50
1.00
0.50
0.00
10
11
12
13
14
15
16
17
18
19
20
No of Images
Avg Time 09/10/03 (TOD 1120)
Avg Time 10/10/03 (TOD 1020)
Avg Time to Last Image 10/10/03 (TOD 1020)
4.4 Web Server Storage Capacity
In the original contract the web cache was required to store six months’ of online image
data. However, before the start of evaluation, QEH reported to PACSnet that they had
been having problems with their online Web storage. The system was only storing
approximately three months of online data rather than the specified six months. The
problem was diagnosed as a miscalculation in the disk size required for web storage as
the storage rules had not been clearly defined. Agfa-Gevaert Ltd immediately increased
the size of the disk space, this being installed shortly before PACSnet attended QEH for
the evaluation period.
At the time of PACSnet’s attendance at QEH, concern was expressed by the Trust that,
despite the recent addition of extra disk space, the web cache was still not storing the
expected 6 months’ of data. It was discovered that although the extra disk space had
indeed been installed, additional data had not been copied over and so this new disk
space was filling up only at the rate at which new data was being acquired. PACSnet
were able to demonstrate that the increase in data on the web cache was consistent with
6 months’ of storage space now being available. A return visit to the site some time after
the initial evaluation period confirmed that the web cache had filled as expected. Figures
10a – 10h graphically show the increase in online storage of image data over time.
See Manufacturer’s comments section 16
15
Figure 10a: CR initial
% CR Examinations on Web Cache vs Date
120.00
% CR Examinations Stored
100.00
80.00
60.00
40.00
03
03
/2
0
01
/0
3
/0
4
01
01
/0
5
/2
0
/2
0
03
03
/2
0
15
/0
5
/2
0
/0
6
02
16
/0
6
/0
7
03
03
/2
0
03
/2
0
03
01
15
/0
7
/0
7
/2
0
/2
0
03
03
22
/0
8
01
/0
8
15
/0
9
01
/2
0
03
/2
0
03
/2
0
03
/2
0
/0
9
15
/1
0
01
15
/1
0
/2
0
/2
0
03
03
0.00
Date
Figure 10b: CR after 8 months
% Archive CR Examinations on Web Cache
100.00
80.00
% CR Examinations Stored
20.00
60.00
40.00
20.00
0.00
/06
23
04
/20
/06
16
04
/20
/05
12
04
/20
/0
14
4
00
4 /2
/03
10
Date
16
04
/20
/0
11
4
00
2 /2
/01
07
04
/20
/1
10
3
00
2 /2
Figure 10c: CT initial
% CT Exams on Web Cache
120.00
100.00
%CT Examinations
80.00
60.00
40.00
03
03
/2
0
01
/0
3
/0
4
01
01
/0
5
/2
0
/2
0
03
03
/2
0
15
/0
5
/2
0
/0
6
02
16
/0
6
/0
7
03
03
/2
0
03
/2
0
03
01
15
/0
7
/0
7
/2
0
/2
0
03
03
01
22
/0
8
/0
8
15
/0
9
01
/2
0
03
/2
0
03
/2
0
03
/2
0
/0
9
15
/1
0
01
15
/1
0
/2
0
/2
0
03
03
0.00
Date
Figure 10d: CT after 8 months
% Archive CT Examinations on Web Cache
100.00
80.00
% CT Examinations
20.00
60.00
40.00
20.00
0.00
/06
23
04
/20
/06
16
04
/20
/05
12
04
/20
/0
14
4
00
4 /2
/03
10
Date
17
04
/20
/0
11
4
00
2 /2
/01
07
04
/20
/1
10
3
00
2 /2
Figure 10e: MR initial
% MR Exams on Web Cache
120.00
100.00
% MR Examinations
80.00
60.00
40.00
20.00
03
03
/2
0
01
/0
3
/0
4
01
01
/0
5
/2
0
/2
0
03
03
/2
0
15
/0
5
/2
0
/0
6
02
16
/0
6
/0
7
03
03
/2
0
03
/2
0
03
01
15
/0
7
/0
7
/2
0
/2
0
03
03
01
22
/0
8
/0
8
15
/0
9
/2
0
03
/2
0
03
/2
0
03
01
15
/0
9
/2
0
/2
0
01
/1
0
/2
0
/1
0
15
Date
Figure 10f: MR after 8 months
% Archive MR Examinations on Web Cache
100.00
80.00
% MR Examinations
03
03
0.00
60.00
40.00
20.00
0.00
/06
23
04
/20
/06
16
04
/20
/05
12
04
/20
/0
14
4
00
4 /2
/2
/03
10
Date
18
4
00
/0
11
4
00
2 /2
/01
07
04
/20
/1
10
3
00
2 /2
Figure 10g: US initial
% US Exams on Web Cache
120.00
100.00
% US Examinations
80.00
60.00
40.00
20.00
00
3
00
3
/0
3
01
/0
4
/2
/2
00
3
01
15
01
/0
5
/0
6
/0
5
/2
/2
00
3
00
3
/2
00
3
16
02
/0
6
/2
/0
7
01
/0
7
/2
00
3
00
3
/2
00
3
15
22
01
/0
7
/2
/0
8
/0
8
/2
00
3
00
3
/2
00
3
01
15
/0
9
/2
/0
9
15
/1
0
01
/2
00
3
00
3
/2
00
3
/2
/1
0
15
Date
Figure 10h: US after 8 months
% Archive US Examinations on Web Cache
100.00
80.00
% US Examinations
0.00
60.00
40.00
20.00
0.00
23
/06
/20
04
16
/06
04
/20
/ 05
12
04
/ 20
/04
14
04
/ 20
19
/03
10
Date
/20
04
11
/02
/20
04
07
/01
/20
04
/12
10
03
/ 20
Online Storage
All image and text data are stored on RAID level 5. Typically two key areas that
fail in a RAID are the power supply and hard disks. The RAID units feature built-in
redundancy, with dual power supplies and spare disks. The spare disks can be
‘hot-swapped’ if any disks fail; they will come into operation automatically and
send an alert signal to the system administrator if this event occurs.
Workflow and Archive Servers
There are redundancy features built in to allow for some continued operation of
the PACS in the event of the failure of any of the main components. If the archive
server were to fail, the workflow manager would be able to continue to function in
the short term to store the image data, relying on its 509 GB internal RAID. This
provides short term online storage capacity only: there would be no access to the
Main Cache or DLT Backup. However, images will still be able to be stored on the
Web Cache as usual.
Should the Workflow server fail there will be no contact with archive and so all
images will remain stored locally at the modality storage.
Nearline Storage (DLT Jukebox)
The DLT jukebox has three read/write drives each with its own independent power
supply and controller. In the unlikely event that all three read/write drives fail it will
not be possible to retrieve any images from the jukebox or back up data until the
unit is repaired. Other components of the PACS are fully functional i.e. it will be
possible to store images to and retrieve images from the RAID.
PACS Broker
The PACS broker provides the DICOM worklist and should this fail there would be
no worklists available and all studies would have to be manually verified. This
entails entering the patient details manually on to the PACS. Only verified images
are sent to the Web server, therefore failure of the PACS broker would mean that
no new studies would be able to be stored onto the Web Cache. There is a
manual override available to the Systems Administrator to allow sending either by
batch or singly, any unverified image, but iti is important that theses are verified
subsequently, which would be a manual process.
Web Server
If the Web server fails studies can not be viewed around the hospital using the
Web clients however, it is still possible to operate the PACS for image acquisition
and image display within the Radiology department on PACS workstations. A
solution to this (or any critical component failure) is the printing of images to film
as hardcopy, which can be achieved from any of the modalities. Agfa DRYSTAR
3000 printers are used, which are discussed in section 11. In the initial tender
document Agfa-Gevaert Ltd proposed the implementation of a second web server
as a redundancy feature, although QEHT decided not to implement this as part of
their PACS solution.
The only other possible loss of storage hardware would be a catastrophic loss of all
equipment through fire or criminal activity to the server farm, destroying all the
equipment. Should this unlikely incident occur a new cluster would be set-up and
installed in the QEHT and the database rebuilt from the backup tapes. As a worse case
20
scenario up to three weeks of image data might be lost, depending on the last mirror
tape removed to the secondary storage, held in the imaging department. However, it
should be stressed that to gain access to the server farm requires a member of staff to
show an ID badge, sign for a key, open three doors, each of which have a code, one of
which requires two keys, and one of which requires a swipe card. Then another code has
to be entered to deactivate the alarm in the computer room.
21
5. Integration with external systems
The Agfa IMPAX PACS is integrated with the McKesson “STAR” system, a combined
Hospital Information System (HIS) and Radiological Information System (RIS). The
specification of the STAR system is shown below in table 9.
A Mitra PACS broker acts as an interface between the McKesson STAR system and the
Agfa Impax system. The Mitra PACS Broker uses Health Level 7 (HL7) Version 2.3 to
communicate with the HIS/RIS and the PACS. The broker runs on a Dell 2400
PowerEdge server which has dual 733MHz Pentium III processors and redundant data
storage using RAID 5 with two power supplies. The broker is backed up every night to
tape. Should the broker fail it would still be possible to obtain data and reports since
PACS has been operational from the backup tape; however pre-PACS reports would not
be attainable as these are stored on the HIS.
Table 9: Description of the information systems used in the trust which engage with the
PACS
Manufacturer/Supplier
McKesson
Product Name
STAR
Database Used
Mumps
Version (RIS)
5.0
Version (HIS)
4.5
Date of Installation
September 1991
Operating System
UNIX
Middleware/Interface engine
Fully integrated into HIS
DICOM Service Classes
(Enabled)
N/A
HL7 Compliance
Yes
HL7 version, if compliant
HIS is HL7 version 2.3 compliant
N/A
Messaging protocol if not HL7
Date of last upgrade
2003
22
6. Backup Management
Backups are performed three times during the day, once for each server, on Monday to
Friday at the times shown below. The tape is replaced at the beginning of each day for
that night’s backup, however because of no out of hours working; the backup for the
weekend Saturday and Sunday overwrites the Friday tape. The weekend backup for the
database server overwrites the database server tape instead of the Friday backup.
Mitra Broker
2230 – 2255
Database Server 2300 – 0100
WEB 1000 Server 0400 – 0415
The backup process is carried out automatically and can be monitored remotely by the
on-call computer operator. Backup tapes are manually removed from the server farm and
stored in a locked cabinet on-site.
During the backup process the backup software carries out integrity checks on the data
and the backup will only complete the process when the information is stored correctly.
There is an integrity check carried out between the image and demographic data on an
annual basis. QEHT use software provided by Agfa-Gevaert Ltd for this task.
The backups are scheduled to operate out of normal hours as it could not be guaranteed
that the backup process would have no effect on the operation of the PACS, although
Agfa-Gevaert Ltd were confident that no effect would be measured. As part of the
evaluation process PACSnet investigated the change in retrieval times of a range of
images at various times during the day. Tables 10 – 14 list the times for retrieval of
images at various times of the day including the backup period and there was no
statistical difference between any of the times measured. Times were recorded for
images retrieved from both the main archive and the Web1000 cache.
Table 10: Average Time of
retrieval of CR chest images at
various times of day
Date
09:10:03
09:10:03
10:10:03
20:10:03
20:10:03
Time
(secs)
2.08
2.40
2.26
2.32
2.24
Table 11: Time to retrieve CR data
sets during normal and backup
running
Time of Day
(TOD)
1030
1740
0940
2215
2235
Date
20:10:03
20:10:03
20:10:03
23
Time
(secs)
2.46
2.18
2.24
Time of Day
(TOD)
2155
2228
2235
Table 12: Time to retrieve CT data sets during normal and backup running
Date
20:10:03
20:10:03
20:10:03
20:10:03
Time (secs)
1.80
1.53
1.43
2.75†
Time of Day (TOD)
2211
2215
2241
2243
No of Images per study
93
20
93
93
†
Time to Last Image
Table 13: Retrieval times for CR studies
from Web 1000 cache compared with
normal running and during backup of Mitra
broker.
Date
Time of Day
(TOD)
2247
2305
Date
09:10:03
20:10:03
20:10:03
Time
(secs)
1.43
0.87
0.92
Time of Day
(TOD)
1152
2253
0410
Figure 11 graphically highlights the retrieval times of images from the archive server
measured over the backup and non backup TOD; as is observed there is no significant
difference.
Figure 11: Retrieval Time of CT image data to first and last image from archive server with
backup running
CT Retrieval Time from Archive Server
4
3.5
3
2.5
Time (sec)
20:10:03
20:10:03
Time
(secs)
1.06
0.85
Table 14: Retrieval times for Angiography
studies from Web 1000 compared with
normal running and during backup of Mitra
broker and the Web 1000 archive
2
1.5
1
0.5
0
0
10
20
30
40
50
60
70
80
90
No of Images
normal (TOD 2210)
backup running (TOD 2240)
Time to last image:Backup running (TOD 2243)
24
normal (TOD 2215)
100
7. System recovery
7.1 Data Recovery
Should the database server disks fail and data is lost, then the database would have to
be restored from the database backup. The tapes for the database backup process are
changed daily, and the backup of the data is carried out at 01:00 each morning. Should
the database server fail prior to the backup procedure then the system would have to be
restored from the previous backup, potentially losing up to almost one day’s data., these
being able to be recovered from CR and the various image modalities local short-term
storage.
If the DLT jukebox fails the PACS will continue to function. However there is now a risk of
permanent loss of newly-acquired image data since no backup of this new data will be
carried out until the DLT jukebox is repaired.
Recovery of image data from the tape jukebox will be required if there is any catastrophic
loss of data from the image online archive RAID. This process should be straightforward,
once the image archive has been repaired.
Any recovery of the PACS broker server would be carried out by Mitra, the supplier. They
have a record of the QEHT set-up and would be able to restore this set-up by dialling into
the broker. If the PACS broker fails there will be no worklist and the information
associated with the patient from the RIS will be entered. All patients’ images will be
unverified and these will have to be verified manually before being sent for hospital wide
transmission.
The recovery of the Web1000 server following any failure would be achieved in similar
manner to the database server, i.e. using the tape back-up, with any missing studies
being copied from the PACS archive. This can be achieved as there is a built in single
command, at the command line interface (CLI).
Agfa-Gevaert Ltd as part of their initial tender bid advised the QEHT to buy a second
web server which could run in parallel with the first, adding resilience to the system. At
present if the web server fails all films will be printed.
7.2 Recovery from electrical interruption
As stated above all the essential equipment is fitted with two internal power supplies. All
servers are also fitted with an uninterruptible power supply (UPS) which allows for a
system shutdown in a safe, controlled manner should there be a sudden loss of mains
power. When mains power is lost a message is sent to all terminals that there will be a
shutdown of the PACS in five minutes. Should the power return before the five minute
warning period, the system will send an ‘all clear’ message informing the users there will
be no shutdown of the system.
The shutdown of the system has to take place in a specific order to prevent loss of
information on the system. The system shutdown starts by stopping the queues in the
workflow manager; the workflow manager is now safe to shutdown. The archive server is
25
then shutdown followed by shutting down of the database server. The system is restarted
in the reverse order. As a matter of standard practice the database server is re-booted
every 60 days.
When a database is operating correctly this will “commit” transactions at various stages
of producing an image, e.g. verifying an image is making a commitment to a transaction.
If the Oracle database ‘crashes’, when it is restarted this will automatically roll forward
any committed transactions i.e. move to the next step in the process or will rollback any
uncommitted transaction i.e. move to the previous step in the process.
26
8. Reliability, Error Management and Support
8.1 Hardware
Table 15 outlines the maintenance contract for the hardware as part of the contract
between QEHT and & Agfa-Gevaert Ltd. The maintenance contract charges include all
spare parts, labour, travel and accommodation.
The terms and conditions of the service response are:
Service Priority 1 = Service Cover 24 hours per day 365 days per year with
a 2-hour response time.
Service Priority 2 = Service Cover Monday – Friday 09:00 – 17:00
excluding Bank Holidays with a four hour response time.
Table 15: Detail of equipment under service contract
Equipment Description
Qty
Database Manager
Radiologists Workstation Dual 2k 21” Portrait
Radiologist’s Workstation x 8 Dual 1k 21” Landscape
Archive Manager
Archive server 509 GB Sun RAID array
Workflow Manager
Workflow server 509 GB Sun RAID array
DLT Archive Storage
Web Server
Mitra PACS Broker
Sun A5200 1 TB RAID
Service
Priority
Preventative
Maintenance Visits
/ year
1
2
2
1
2
1
1
2
1
1
2
2
2
2
2
2
2
2
8.2 Maintenance and Support
The maintenance and support of the Agfa PACS software is provided by site visits and/or
Agfa’s Remote Global Support Service. The Global Support service provides 24 hours a
day, 365 days per year, remote support via a WAN connection in accordance with the
NHS Information Authority’s (NHSIA) requirements for secure connection protocols. It
provides a means for Agfa to support their software via a remote connection to the PACS
from one of their international service response centres.
27
Table 16: Results of call-outs due to problems in the last three months
No. of User Calls per month
No. of problems recorded per month
Avg. time to reply to major problems
Avg. time to reply to intermediate
problems
Avg. time to reply to minor problems
Avg. time to resolve major problems
Avg. time to resolve intermediate
problems
Avg. time to resolve minor problems
QEHT
12 (average no. of calls per
month over a 4 month
period.)
15 (average no. of calls per
month over a 4 month
period.)
Within 1 hour.
Within 1 hour.
Within 1 hour.
Agfa
For all IMPAX products, i.e.
Database, archive, workflow,
broker; Review stations, RAID,
Broker and Web Server. This
includes calls for Applications ,
Repair and Technical support:
7.66 calls per month.
As above
38 minutes
67 minutes based on 27 calls
over March – June 2003.
67 minutes (as above)
58 minutes (past 4 months)
N/A
N/A
The reliability of the PACS was an important area of interest. QEHT and Agfa-Gevaert
Ltd were both asked to give their answers to a series of questions on all aspects of the
PACS reliability. Table 16 shows the call-out times over the last 4 months and these are
within the contractual obligations.
As part of the contract Agfa-Gevaert Ltd agreed to the system having 99% uptime, i.e.
the system will perform as stated in the contract 99% of the time. The figures for this are
calculated over a three month period and at present the system has an uptime of 99.9%,
as calculated by Agfa. This translates to a downtime of 8.76 hrs/year.
8.3 Training
As a major part of any PACS installation Agfa-Gevaert Ltd schedule a team of trainers
which includes both Clinical Application Specialists and Technical Specialists.
During the initial stages of any project prior to the date the system is operational in the
trust, Agfa-Gevaert Ltd trained a number of key staff. These included a number of core
trainers selected from senior staff or those who were competent and familiar in dealing
with the technology.
The training fell into several distinct areas as appropriate for different staff groups:
Hospital Systems Managers
Radiographers
Radiologists
Clinical and Ward staff.
All Equipment
ADC/Hardcopy systems
Diagnostic / Clinical Review Workstations
Clinical Review Workstations
When the system was rolled out on a hospital wide basis the core trainers helped train
the relevant staff in conjunction with Agfa-Gevaert Ltd. Therefore at all the times there is
a significant knowledge base for all the system components.
See manufacturer’s Comment Section 16
28
9. QEHT Network Configuration
The network at the Queen Elizabeth Hospital was installed in April 2000, with the PACS
integrated into the Trust’s local area network (LAN). The LAN has a distributed star
topology, and consists of two Cisco Catalyst 6006 series switches, which are linked by a
fibre optic 1 Gbps link to the 60 x 3500 series switches which are located throughout the
hospital, and a 2 Gbps backbone fibre link. There are 22 wiring closets around the
hospital which contain these 60 switches, from which run 100 Mbps CAT5E cable links to
the desktop, see figure 12. The switches have either 24 or 48 ports and run Cisco
Internal Operating System (IOS) version 12.
Figure 12: QEHT Switches Configuration
29
The two main switches are in separate locations in the Trust: the server farm, which
contains the PACS servers and also has a Primary Rate Integrated Services Digital
Network (ISDN) backup line to the Memorial Hospital (which houses the main hospital
data centre) and the Undercroft, which has the following external links:
-
100Mb BT LAN extension service to the Memorial Hospital
2Mb link to Greenwich Council; 128Kb link to Oxleas NHS Trust
a 64Kb link and an ISDN backup link to Trend Communications.
The network topology is shown in figure 13.
Two Cisco 1800 routers (not illustrated) are used for the hospital’s NHSnet connection.
These are managed entirely by BT and the Trust does not have access to these. These
routers are scheduled for replacement in the near future, but it is not known when or
what will replace them.
Figure 13 QEHT Network Topology.
The Memorial Hospital, located a short distance away from the QEH, is the main data
centre both for itself and for the QEH. This is where the majority of the IT department are
located. The data centre provides network connections to other health care services via
a Cisco 3640 router and also modem support. These are entirely separate links from
PACS. The Memorial data centre network topology is included for information only, see
figure 14.
30
Figure 14: Memorial Data Centre Network Topology
There are approximately 1700 devices attached to the QEHT network. Table 17 provides
a breakdown of these devices. The QEHT is directly connected to the NHSnet network
and as a result of this security is strict. All user desktops are “locked down”, which means
no software can be added or removed from any workstation on the network.
Table 17: Devices attached to the QEHT Network
Device
Quantity
PCs
Printers
PACS Devices
Other Devices (Switches/Routers)
1100
450
50
100
9.1 Anti-Virus Software
The IT department updates all network devices with the latest anti-virus software
updates. They are currently using Command AntiVirus version 4.64 as their anti-virus
software. There is a standalone server connected to the internet which looks for antivirus updates; if any are found these are downloaded to the server and installed as
required. All PCs on the network check with this server for updates, either via a login
script or a “push” from the server (dependant upon PC configuration) and are therefore
automatically updated. Anti-virus updates for PACS devices are not performed by the IT
department, but are performed by the Trust’s Operations department. These updates are
performed manually and the anti-virus software used is Norton Anti-Virus.
9.2 Network Management
Management of the network is controlled by a third party, Trend Network Services (part
of Trend Communications Ltd, High Wycombe, Bucks, UK), who use the network
monitoring tool “NETcontrol” provided by International Network Services (Santa Clara,
California, USA). Trend Communications perform all network monitoring and inform
QEHT of any problems or issues encountered.
31
Network reports are available as part of the managed service contract and the IT
department are able to view these on the Trend Communications website, after logging
in with user name and password. They can also, upon request and payment of a fee,
receive a more detailed utilisation and network health report. The QEHT IT department
have some network monitoring tools available; they have Simple Network Management
Protocol (SNMP) enabled on all network switches, which enables them to perform local
monitoring of any of the switch ports, and can also see any network errors. The IT
department also have various cable testing equipment, and they also have experience in
the use of network ‘sniffers’ (tools to monitor network activity). These ‘sniffer’ tools are
not employed on a regular basis, only as and when required, and involve the purchase of
additional software and resources.
All traffic using the network is controlled by Virtual LANs (VLANs, see glossary). VLANs
are allocated per department so all PACS related traffic is on its own VLAN. Since traffic
on the network is minimal there has not been a need to implement packet prioritisation
on the network. Network utilisation is well below 10%.
9.3 Network Security
The network at QEHT has several security measures in place: firewalls are used which
are created and managed by Check Point software (Check Point Software Technologies
Ltd, Ramat Gan, Israel); audit logs are in place for network traffic and these are regularly
checked by Agfa. The network does not have any Intrusion Detection System (IDS) in
place, and no penetration testing or risk analysis has ever been conducted on the
network. However, access to the network is strictly controlled: hardware devices can not
be added to the network unless these have been authorised by the IT department. Any
unapproved devices added to the network, such as a laptop plugged in to a network port
by a user, will not work. No software can be added to PCs on the network as the desktop
is locked down. These measures ensure that the network is “clean” to permit direct
connection to NHSnet.
The QEHT also implements a strict data security policy: no digital media is permitted to
be removed from the site. Films are printed at non-profit for legal purposes (e.g. solicitors
etc), and for patient transfer to a non-PACS hospital. Patients can also purchase images.
Impax 4.1 does not have the capability of transferring DICOM images to CD.
9.4 Redundancy Provisions
The network at QEHT has built in redundancy. The two main switches (Catalyst 6006)
have dual fibre optic links to each of the 3500 switches in the 22 wiring closets, Figure
12. All servers have dual CPUs as well as Uninterruptible Power Supply (UPS) units
which normally provide 30 minutes back-up power, allowing enough time to shut the
servers down safely or to get the main power facility working. The QEH has two links to
the Memorial Hospital; a BT LAN extension link and also a Primary Rate ISDN backup
link should the BT connection fail.
Within the imaging department all devices (including all PACS related equipment) are on
the emergency power supply circuit.
32
9.5 Disaster Recovery
At present there are no disaster recovery procedures in place. The tape jukebox used for
archiving the image data is situated adjacent to the RAID and so there is no resilience
against major disaster occurring. This could easily be rectified. If the tape jukebox, which
is currently located in the server farm along with the PACS archive and RAID, was
moved to the Undercroft this would geographically separate it from the server and would
introduce some disaster resilience, and by using fibre SCSI to connect it to the archive
server would also speed up backups.
9.6 Issues
The IT department were asked what issues they had so far experienced with the
implementation of the network and PACS. The major issues encountered were design
issues. As previously noted, the network at QEHT is scaleable; increasing the number of
network devices is limited largely by the design of the building. The size of the wiring
closets means they can only hold a finite number of switches, and an increase in the
quantity of electrical equipment installed in a relatively small space can increase the
room temperature dramatically, which can have adverse effects on the reliable operation
of the equipment.
Concern was also raised with regard to the QEHT datacentres. The Undercroft and the
Server farm are not staffed units, so if a tape change needs to be performed the key to
unlock the server farm needs to be obtained and signed for from the main QEH
reception. There is then a 5 min (approx.) walk before reaching the server farm. After
unlocking the outer door, alarms have to be deactivated before the interior door can be
opened, and access to the server and tape library is granted. Whilst this might not seem
a long time if you are already at QEH however, if you are at the Memorial Hospital this
could take well over 15 minutes.
9.7 Future Developments
The QEHT network has been predicted to perform adequately until 2005, after which
future upgrading of the infrastructure will be required. Currently the network is fully
scaleable and since the network traffic is minimal many more devices could, in theory, be
added to the network. All Cisco switches/routers are scaleable and can have more
modules added to deal with any new devices.
The IT department are proactively considering the future development not only of the
network, but also of other technologies that use the network. The role of wireless
equipment, such as wireless tablets and Personal Digital Assistants (PDAs) is one such
consideration, which could prove immensely practical in areas such as wards, which
have limited space for network cabling, and would benefit from the mobility and flexibility
wireless devices provide. However, the security implications associated with wireless
transmission mean implementation of this technology has yet to be developed.
At present the future development of the network and its technologies is on hold until the
implications of the National Programme for Information Technology (NPfIT) and the
National Care Record Service (NCRS) programme have become clear.
33
10. Image distribution
The images are distributed across the network and are manipulated and shown on three
types of workstation:
Reporting workstation (Agfa’s model DS3000)
Review workstation (Agfa’s model CS5000)
Web Browser (Trust’s own PCs)
10.1 DS3000 Reporting Workstations
Table 18: Specifications of the reporting workstations in QEHT
Specification
Manufacturer
No of Units
Type & Speed of CPU
Type & speed of RAM size
Type & speed of Hard Drive
NIC Manufacturer
Bandwidth speed
Video Card (Full Specification)
Resolution supported
Dell
9
Pentium 3 - 733 MHz
256MB
IDE 10 GB
3 Com
100 MHz
Dome MD2 Graphics Board
1280 x 1024 x 8 bit dual screen
High Brightness
Source:QEHT & Agfa-Gevaert Ltd
Table 18, highlights the specifications of the reporting workstation, of which the QEHT
has nine in total. The workstations run Microsoft® Windows NT™ version 4.00.1381 and
use the Agfa-Gevaert Ltd Impax DS3000 software SP2 SU7 (SP: service Pack; SU:
Software Update). The software has a licence to enable the application to run and - as
with the server software - activation of this software licence is linked to the MAC address
of the workstation.
The workstations use CRT portrait monitors to display and manipulate the images. The
measurement of luminance on a sample set of the monitors was carried out and is
discussed in section 10.5.
The QEH has two types of reporting display; the 2048 x 2560 (2K x 2K) and the 1280 x
1024 (1K x 1K) display. The 1K displays are all CRT and come in landscape layout, while
the 2K displays are also CRT and come in portrait mode
34
10.2 Review Workstation
Table 19: Review workstation used in the general processing area to examine images
prior to acceptance.
Manufacturer
No of Units
Type & Speed of CPU
Type & speed of RAM size
Type & speed of Hard Drive
NIC Manufacturer
Bandwidth speed
Video Card (Full
Specification)
Resolution supported
Agfa Minimum Specification
QEHT in place
Customer Supplied Hardware
(Recommended minimum
Requirements listed below)
1
Pentium 3 - 300MHz
256 MB
IDE or SCSI 20MB
3 Com
100MHz
Matrox / Dome
Dell
1024 x 768
1
350 mhz Pentium 2
SDRAM 256 MB
8GB
3 Com
100MHz
4 MB INTEL 810 CHIPSET
GRAPHICS DRIVER PU2.1
1280 X 1024 X 8
The CS5000 review workstation described in table 19, is based in the Imaging
Conference room and uses the Agfa CS5000 software. This is a cut-down version of
Impax 4.1, and is linked to a projector so that it can be used and viewed by many people
for MDM Meetings.
10.3 Web-based distribution
The general distribution of images throughout the QEHT is from the Web 1000 server to
Web 1000 web clients. The web client runs on a series of relatively low specification PCs
which run Internet Explorer.
As part of the PACS installation, QEHT purchased 100 concurrent licences to run on the
web server. This means that at all times the web server keeps a record the number of
users logged onto the system - should this number reach 100 the system will not allow
any more users to log in via the Web1000 client. As a result of this it is essential that all
users log out after use and this is heavily emphasised in the Web1000 user manual
produced by the QEHT. At present there is an automatic timeout of 15.5 minutes for
Web1000 users. The trust reported no problems with users being allowed to log into the
system using the Web 1000 despite the 100 user licence limit.
The two methods of image distribution require two passwords. The Impax reporting
software password is required to be changed every 60 days and the Web1000 password
is required to be changed every 90 days.
35
Figure 15: User interface to Web1000 Client
Figure 15 illustrates the Web1000 client interface, which allows the user to view images
on the ward or clinic.
Searching can be undertaken on a series of fields, one of the most common is by date.
The format of the date entered into the Web1000 is in the form, Year–Month-Day, which
was different to the format required by the Impax reporting software which was DayMonth-Year. This date format does lead to confusion; this topic affects more than one
Agfa Impax installation and has been reported to Agfa through their Impax national users
group meetings.
Problems were discovered when searching both the Web cache and the main archive
using the Web1000. The Web1000 allows the user to select the archive to search for the
patient giving the options “Web cache,” “main archive” and “All Locations.” When
searching “All Locations” (i.e. Web cache and main archive) a complete list of all studies
should be given, however this only gives the list of studies on the web cache. of all
studies is given, including related studies that are scheduled on the RIS, unverified
images as well as images on the Web cache , and the image cache.
One of the options when searching the web cache is to search by referring physician. It
was noticed that names of some referring physicians were appearing more than once in
the list of available names for this field. Choice of particular instance of a duplicated
name affected the search results, sometimes returning no patient names at all. It is
important to ensure that naming conventions within the RIS system are maintained.
36
10.3.1 Searching on Main Archive from the Web 1000
If the user selects to search the main archive, they will search on the required subject
fields and obtain a list of patients. The user selects the required exam to display the
images and a message is shown on the screen informing the user if the images need to
be fetched from nearline storage (i.e. the tape jukebox). After the images have been
transferred to the web server the user is informed. However if the images are already on
the web cache the user gets no notification at all. If the user should retry displaying the
images, the user receives the original message, informing them that the images need to
be retrieved. The user then clicks on the YES box and a message box informs the user
that the images have been retrieved and can be displayed.
The information given to the user during the above process is confusing. The system
makes it unclear to the user when and from where it is obtaining the data. If the image
already exists on the web cache and the user is searching the main archive then this
could lead to problems. This problem has probably gone unreported or unnoticed as any
user will probably repeat the command which would inform them the image was ready for
display.
10.3.2 Conferencing on Web1000
The Web1000 has conferencing facilities where the initiator invites other users to join a
conference, and this invitation can either be accepted or rejected by the invitee.
The mouse can be used as a pointer by all users and any changes or mark-ups to the
image displayed during the conference will be seen by all conference delegates. The
conference opens up a messaging box which allows the conference delegates to discuss
the study. A delegate to a conference can disconnect and all the other delegates are
informed of this departure in a message box displayed on-screen. If the conference
initiator disconnects, this closes down the conference and disconnects the other
delegates.
10.3.3 Web1000 Functionality
The Web1000 Client offers standard features such as window width and level,
magnification and zooming.
Cine and scout views are available to users when viewing studies which would benefit
from their use, therefore the cine is only available to studies such as CT and MR. At
present the scout view can only be used with CT images however by May 2004, MRI
studies will also be able to use this facility.
The Web1000 has the facility to print an image, however the training manual and the
Imaging Department actively discourages printing off the web. The manual does not
make clear if there is a hierarchy of users with access to the Web1000 of which only a
limited number can use the print facility or if all users have this facility.
10.3.4 Training and Helpdesk support for Web1000
The training and helpdesk for the Web1000 are supported by the IT department of the
QEHT. The department regularly runs training sessions for new members of staff and
has produced a good pocket guide for users new to the system.
37
10.4 Reporting Room
In many trusts the plans for the image reporting areas, such as radiologists’ offices or
multi-user reporting area, fail to take into account the operational requirements or the
needs of the users. As part of the evaluation at QEHT, PACSnet examined the reporting
rooms, which were the radiologist’s offices. As part of this process PACSnet examined
the temperature, illuminance and furniture of the workspace environment.
At QEHT the image reporting is carried out in the radiologist’s offices, however the
offices were designed before PACS was approved. Each of the offices has a bench
running the length of the room with a small desk at the doorway giving an L-shaped work
space. In each room there was a standard specification PC which was functioning as a
web browser and a dual monitor workstation running Impax which was used as a
reporting workstation.
A series of measurements were undertaken examining the illuminance in the reporting
rooms and the luminance of the CRT screens in place. The measurements were
obtained using a Hagner S3 luminance meter. Results of the measurements can be seen
in the table in table 20.
10.4.1 Reporting Room Temperature
The ambient temperature of the reporting room is vital to the efficient operation of the
equipment and the comfort of the operator. To create a proper operational environment
heavy, light-proof, black blinds, figure 16, have been installed in the radiologists’ offices.
However if the blinds are closed (as will be appropriate when reporting) there is no
ventilation available through the windows. No air-conditioning has been installed in the
offices and there is no other ventilation available and so the rooms can get very warm.
Figure 16: Room Blinds used to stop reflection
The reporting rooms at QEH are on either side of a corridor with the windows facing
North and South, figure 17.
38
Figure 17: Architect’s drawing of Radiologists’ offices
Source: Agfa-Gevaert Ltd
PACSnet discussed with the radiologists any problems they had with the reporting
environment with their overriding complaint being excessive room temperature.
PACSnet measured the temperature in one of the consultants’ offices over a two day
period where the outside temperature was approximately 18 oC on bright sunny October
days. Figure18 shows the measurements taken on day one where the windows, blinds
and doors were open; the measurements were taken at hourly intervals over the working
day. The graph shows a continual rise in temperature throughout the day, which puts
stress on both the computer hardware and the users. In general PACSnet would advise
the installation of air conditioning in all reporting rooms.
It should be noted that the reporting offices were designed before the PACs was
approved. No changes were made to the plans for these rooms to allow for any specific
PACS requirements.
39
Figure 18: Room temperature over the working day with door and window open.
Reporting Room Temperature
09:10:03
25.5
25
24.5
Temperature (oC)
24
23.5
23
22.5
22
21.5
21
20.5
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
Figure 19 illustrates the more rapid increase in temperature in the reporting room with
the door and window closed, in order to create optimal viewing conditions. If the viewing
conditions were set optimally for the entire working day then the temperature in the room
appears likely to exceed the 30 oC maximum working temperature stated on the
architect’s drawings.
Figure 19: Room temperature over the working day with doors and windows closed
Reporting Room Temperature
10:10:03
28
Windows and Door Open
27
26
Temperature (oC)
Time
25
24
Windows and Door Closed
23
22
21
09:20
10:00
11:00
12:20
13:20
Time
40
14:00
15:00
16:35
16:50
10.4.2 Reporting Room Illumination
The measurement of room illumination was carried out in consulting room 4. The
illumination was measured under three lighting conditions and is measured in Lux; in all
lighting conditions the screen was white.
Table 20: Results of the illumination measurements in the reporting room
Position
Desk by Door
Keyboard by Web
1000
Keyboard by Impax
At Impax Screen
Facing Viewer
Condition 1
illuminance (lux)
598
Condition 2
illuminance (lux)
583
Condition 3
illuminance (lux)
16
566
568
16
610
590
49
Left
235
Right
350
Left
322
Facing Up
760
Facing
227
Screen
Facing
228
Viewer
Condition 1: Door Open, Blinds Open, lights on
Condition 2: Door Closed, Blinds Down, lights on
Condition 3: Door Closed, Blinds Down, lights off
Viewer at
60 cm
from
screen
Right
365
Left
14
Right
14
810
5
248
68
250
5
Figure. 20: Reflections from Door and window (with both door and window blind open)
41
Table 20 and figure 20 highlight the significant reflection from the various sources in the
reporting room, the values measured almost being as much as that in an overcast sky
(1000 lux [3]). There is a significant reduction in illumination and reflection when both the
door and the blinds are closed which is clearly demonstrated in the results obtained from
condition 3. This is the reason that QEHT added the heavy duty blinds and as a result of
doing this the illuminance levels in the reporting rooms were shown to be half that of late
twilight.
There remain some minor problems with the offices at QEH. The two major features are
the walls and the bench which are both white and therefore reflective of any light in the
room. A third design consideration is the use of lighting. The light switches in the rooms
are not dimmer switches, therefore the lights are either on or off which does not allow the
user to create the optimal lighting conditions when reporting. However the reporting
areas in many PACS implementations in the UK are similar, with the majority of the
reporting rooms using the same or similar benching and white walls with no dimmer
switches; QEH is better than many sites for having effective light-proof blinds.
10.5 Workstation Monitors
The displays used for the viewing of images on the Web1000 are standard PC displays.
The images viewed on these monitors are already reported. No analysis of viewing
conditions or of screen uniformity or luminance was undertaken. The displays used for
the reporting of the radiology studies are listed below in table 21.
Table 21: Reporting Monitors used in QEHT
Type
Reporting Workstations
Review Stations
Image Display
Device
Image Display Device
CRT
8 Dual Screen 1 MP DS3000
1 Dual Screen 2 MP DS3000
1 CS5000
Source QEHT & Agfa-Gevaert Ltd
The displays listed in table 21 are used for reporting and are located in the radiologists’
offices. PACSnet measured the luminance from these displays with the results shown in
table 22.
It should be noted that the results are consistent and well-matched between all the
consulting rooms. These results are also within the expected values for the type of the
display. The displays were also examined for both geometric distortion and uniformity in
image display and all were found to be consistent and within expected values.
Table 22: Luminance levels (cdm-2) measured for White and Black in three reporting
rooms.
White
Consulting Room
1
2
3
Impax L
129.4
131.7
130.6
Black
Impax R
129.9
130.9
130.7
42
Left
2.2
2.6
3.8
Right
2.7
2.4
2.6
11. Printers and Digitisers
11.1 Printers
The QEH has four Agfa Drystar printers: two Drystar 3000 printers which are housed in
the review area and near the screening room, and two Drystar 2000 printers which are
housed in outpatient department and Accident and Emergency. Figure 21 and table 23,
describes the physical and functional properties of the Drystar 3000 printer. Both sets of
printers are used to provide backup facilities in the event of PACS failure, printing of
images for patients who are being moved off-site and the printing of images for medicolegal cases.
Figure 21: Agfa-Gevaert Ltd Drystar 3000 Printer
Table 23: Table of Information on Drystar 3000
Footprint
(W x D x H)
(cm)
60 x 41 x 137
Film size
(inches)
14 x 17
11 x 14
No. of Pixels
Throughput
(sheets/Hr)
4352 x 5298
3418 x 4352
50
70
Source Agfa-Gevaert Ltd
43
Printing Resolution
Geometrical
Resolution
(ppi)
Contrast
Resolution
(bits)
320
12
The film used by the Drystar 3000 printer is not sensitive to light but to thermal energy.
The film is composed of a 175 micron polyethylene terephtalate (PET) base, coated with
silver salts and a protective top layer.
Since film is sensitive only to thermal energy, the printers use heat to create the image
on the film. This allows for the system to be loaded in daylight conditions. All the printers
are connected to the network, hence the image data can be routed from any of the CR
readers or modalities to any of the printers; using the DICOM print management service
(DICOM PMS).
The Drystar 2000 is a table top printer that produces images of 8″ x 10″ diagnostic quality
films in colour and greyscale, figure 22 and table 24.
Figure 22: Agfa Drystar 2000 Printer
Table 24: Table of Information on Drystar 2000
Footprint
(W x D x H)
(cm)
Film size
(inches)
46 x 68 x 37
8 x 10
Throughput
(sheets/Hr)
Black &
White
Colour
Shades/Colours
55
20
Black &
White
Colour
1024
Print
Resolution
(ppi)
200
16.7 M
Source Agfa-Gevaert Ltd
The film used in the Drystar 2000 printer again uses a thermal technique to produce the
image, In addition, the Drystar 2000 is capable of printing colour images The technique
used is Thermo-Sublimation. This technique can be used in full daylight and requires two
44
components, an “acceptor” and a “donor”, to carry out the process. Heat is used to
transfer the dyes from the donor to the acceptor sheet.
11.2 Film Digitisers
The Lumiscan 75, figure 23, is used for the digitization of the film at QEH. The digitizer
provides the required density and resolution for the digitization for all resolutions of
clinical images. The lumiscan 75 has a linear density function ranging from 0.03 to 4.1
OD, capturing data in a 12 bit monochrome image. The specification is listed in table 25.
Table 25: Specification of the
Lumiscan 75 Digitiser
Figure 23: Lumiscan 75 Digitiser
X-ray Size
Width from 7" to 14"
Length from 7" to 36"
Geometry of
Pixel
Spot Size: 100 microns
square
Pixels : 1024 to 4096
Speed of
scan
Optical
Density
45
115 lines per second
Rank: 0.03 to 4,1 OD
Light Source
Scanned He-Ne Laser
Dimensions
21"x 13" x 27"
12. Security
As discussed earlier, in section 10 (Image Distribution), users require separate
passwords to gain access to the system from the Impax or from the Web1000.
The system administrator monitors the access to the system through a series of
programs. The number of failed attempts by a user to login to the Impax is monitored and
the system administrator is warned if the number of failed attempts exceeds a set
number . The Web1000 does not have this capability and as there are many more login
points to the system throughout the QEHT this provides a greater risk of unauthorised
users gaining access.
The Human Resources department also help in the security of the system by regularly
informing the PACS system administrator of staff changes within the QEHT. Staff
members are added or deleted from the system as required, ensuring that only
appropriate QEHT employees have live accounts on the PACS.
The central PACS hardware (the servers and the storage devices) are kept in a
dedicated computer room. Access to this room is limited to authorised personnel only.
46
13. Workflow
PACSnet examined the workflow at QEHT. This was done by conversations with staff
and a walk through the complete process by the superintendent radiographer.
13.1 Acquisition Workflow: Data entry to PACS
The patient data information is input to the RIS by the reception staff. A resource code is
allocated which represents the room or modality and this data is then available to the
DICOM worklist on the PACS. The radiographer x-rays the patient and performs the data
entry, views the image, carries out the post-processing and archives the image. There
are several statuses which are attributable to the examination, these are: “requested,”
“checked-in,” “in-progress,” “exam ended,” “completed,” “report signed” and “cancelled.”
The reception desk in the X-Ray department at QEHT is staffed until 2000 hrs. After this
time the radiographers enter the patient data themselves. There have been no reported
problems with the data transfer throughout the systems. However if the patient data does
not appear at the CR reader there is a procedure by which the radiographer can enter
the data directly into the PACS.
After image acquisition, information concerning the examination is entered into the RIS
(examination room, radiographer, radiation dose, etc). The examination request form is
then given to the secretaries so that the information can be typed for use in the
radiologists’ reporting worklists.
Once all the images for an examination have been acquired they are viewed by the
radiographer in the processing area on a review workstation. Any further images can be
acquired as necessary until the radiographer marks the examination as “closed” and at
this point the images are sent to the PACS.
The images are viewed in the processing area on flat-panel LCD displays. The review
workstations provide post processing options for the radiographer to manipulate the
images prior to them being sent to PACS. At this time should an image be rejected it is
placed in the deleted folder which can be examined in greater detail later. CR is more
forgiving than film to over- or under-exposure and the majority of repeat images are now
mostly due to patient movement and not incorrect exposure.
13.2 System Failure
The QEHT has two Agfa Drystar 3000 printers and two Drystar 2000 printers. These are
located in the central processing area, CT, the outpatient department and A & E and in
the event of system failure printing is carried out.
In the event of a HIS or RIS failure, or the failure of any interface to the HIS/RIS,
although the images are printed the patient demographic and examination information is
stored on the downtime form storing together with a sequential series of numbers, called
Patient Demographic (PD) numbers. The patient demographics are entered onto the
Preview and Identification Station (PRIDS) manually, and then are reconciled by the
PACS administrator at a later date when the system is operational so the images can be
47
seen on the web. The images can then be named and sent to the Diagnostic Image
Processing Station (DIPS), where they can be printed. The above mechanism for printing
is also required to be implemented if there is a failure with the workflow manager.
During a failure period mobile CR studies are brought back to the x-ray department and
processed in usual way, however films are not returned to ward.
13.3 Retrieval of historical films
Trust policy is that historical films are not digitised into the PACS. They can be copied
using the digitiser and printed, if required by an outside source. Images on film sent to
the QEHT by other trusts can be added to the PACS from the digitiser, however there is
no standard policy in this area and if the clinician requests the image on film it is copied
and printed from the digitiser.
To archive images onto the PACS, the film is scanned into the digitiser database and the
images are transmitted over the network to the PACS archive, where they are stored as
unverified images. A request labelled ‘other hospital images’ is placed on the HIS and
the image and request are then verified together. At this juncture more detailed
information is then added to the request, stating the hospital and time and date of the
examination. The examination can now be viewed as normal using both the Impax and
Web1000 software.
13.4 Reporting
The worklists for the radiologists are organized by the clerical staff. They type the
information regarding examinations for each worklist into their computer and save this
information to an appropriately-labelled floppy disk. This floppy disk contains the GP
worklist, in-patient worklist, etc, as required, and disks are generated for individual
consultants.
The floppy disk containing the worklist is delivered to the radiologist who loads this into
the computer using the Impax software. The worklist is displayed at the bottom of the
screen and the radiologist can open the exams as required by selecting them from the
worklist.
Reports on examinations are dictated to tape by the consultant and each exam is
marked on the PACS as the dictation is completed. The radiologist then moves on to the
next examination. The completed tape containing the reports goes to the secretaries for
typing. The exams are marked on the system that a report has been dictated; however
there is no timestamp or information on who has reported the study.
48
14. Future Developments
New Agfa RIS including Voice Recognition software.
The QEHT has a policy of gradual upgrade, and since the evaluation has taken place
there have been two updates to the Impax software and they are now using, and are now
using Impax 4.1 SP4, and the Web1000 has been upgraded to Web1000 3.1.
The QEHT set aside money to upgrade or change any existing IT software or hardware,
and this was given to the radiology department to renew the RIS which includes the
addition of voice recognition
49
15. Conclusion
The system is entirely filmless and has been since August 2001, with the exception of
mammography which is still on film. There was a general feeling that the system was
well liked by the staff and that it achieved its required purpose. As well as the QEHT
being happy with the Agfa-Gevaert Ltd PACS there is an overall commitment to PACS
from the Trust.
50
16. Manufacturer’s Comments
Web Server Capacity 4.3
The web was designed to have 6 months of continuous images. It was assumed that
this would be suitable and sufficient for the clinical staff. However, the reality is that
clinicians do retrieve a significant number of images greater than 6 months old back to
the WEB1000, and this has reduced the volume of latest images on the WEB1000.
The Trust has tried to educate the clinicians and to manage the retrievals so far as is
reasonable possible to do. Some clinicians do require clinically relevant images that may
go back 18 months, or 2 years or more.
Potential solutions include:
implement pre-fetching routines to be run overnight.
Install a web cache that will deal with the “Clinically relevant images”
These solutions are being reviewed between Agfa and the Trust .
The approach to populate the Web server at the daily acquisition rate was agreed at a
meeting between Agfa and the Trust.
Training and Support Section 9.3
Internal Support
The trust employs a mix of clinical staff and IT staff to support the system. This support
models effective and efficient use of resources, allowing the support teams to provide
their specialist skills in the appropriate areas.
The Clinical System Administrator Roles includes the following non exhaustive list :
•
•
•
•
•
•
•
Monitor the system queues,
checking unverified images,
adding users within the Radiology System,
adding DLT tapes (as required) and unloading the mirrored tapes for storage
offline,
training Radiology staff on the Web and or DS3000 as required,
General housekeeping including the management of images archived by mistake,
or if the incorrect annotation was added to an image and;
Management of printing from PACS
51
The IT systems Administrators Role includes the following non exhaustive list:
•
•
•
•
•
The Administration of new and deleted users on the WEB1000,
monitoring log files for errors (daily) (e.g. disk failures),
ensuring backups are complete,
changing backup tapes (Mon – Fri),and ;
1st line out of hours support.
Ongoing Communication
Agfa and the Trust have taken the responsibility of maintaining good communication very
seriously. There have been consistent and regular meetings to discuss and monitor
ongoing issues and processes. These meetings have included the following personnel:
The Trust representatives:
• Director of IM&T
• Head of IM&T
• Clinical Director of Radiology
• Clinical Systems Administrator
• IT system administrator
Agfa Representatives:
• Account Manager
• Regional Service Manager
• Agfa Site Support Engineer
• Project Manager (As required)
Agfa have found that the internal support model adopted by QEH has been very effective
in the support of the system.
52
References
Commission for Health Improvement (CHI) Queen Elizabeth NHS Trust March
2003, ISBN 0 11 703133 X
2.
PACS Components: Westek R3810 IDE RAID, Alan R. McBride et al., MDA
02163, MHRA, ISBN 1 84182 646 4
3.
Electronic Display Measurement: Concepts, Techniques & Instrumentation, Peter
A. Keller, Wiley, ISBN 0-471-14857-1
1.
53
Glossary
Computed Radiography (CR) CR uses an imaging plate instead of film to capture an
image. The plate is made of a storage phosphor that captures and stores incident x-ray
energy. When scanned with a laser the plate releases the stored energy as light. This
light is captured by the plate reader in order to build up an image.
Cathode Ray Tube (CRT) A cathode ray tube is a specialized vacuum tube in which
images are produced when an electron beam strikes a phosphorescent surface.
Data Compression Data compression is used widely in the storing of data such as in
backups and also in database management. Data compression also aids data transfer
because devices are able to transmit the same amount of information using fewer bits,
thus placing less overhead on the network. Data compression is performed by algorithms
which reduce the size, and reversing the algorithm returns the data to its original form
(lossless compression) or an approximation of its original form (lossy compression).
Digital Imaging and Communications in Medicine (DICOM) The ACR-NEMA standard
protocol adopted by all manufacturers of equipment associated with medical imaging.
The standard provides a method of linking a series of heterogeneous modalities,
workstations and printers without the need for customised hardware to allow them to
communicate and transfer images (See http://medical.nema.org/dicom.html).
Digital Linear Tape (DLT) A magnetic tape storage device used in the backup of large
amounts of data. A DLT tape cartridge can store from 20 to 40 GB of data and has a
transfer rate of 6 MB/sec. The DLT system has been improved to super DLT (S-DLT)
which has a maximum storage of 110 GB with a transfer rate of 11 MB/sec.
Everything Online (EOL) A PACS design where all exams are available in online
storage, irrespective of the age of the exams. The RAID is backed up with an archive
storage device such as DVD or tape.
Hospital Information System (HIS) A computer system which stores demographic
information on all patients attending the hospital. It may also store such items as
appointment details, clerical data or pathology reports.
Integrated Services Digital Network (ISDN) An international communications standard
for sending voice, video, and data over digital telephone lines. There are two types of
ISDN: Basic Rate (BRI) ISDN, which consists of two 64-Kbps B-channels and one Dchannel for transmitting control information. Primary Rate (PRI) ISDN, which consists of
23 B-channels and one D-channel (U.S.) or 30 B-channels and one D-channel (Europe).
Jukebox A data storage device that contains a large quantity of storage media of a
single type (e.g. DVD, tape). The media are moved from their rest location within the
jukebox by means of a robot or carousel to a reading /writing area. The time for this
movement of disk to read varies according to the type and size of device but is typically
10 – 20 seconds.
Local Area Network (LAN) A computer network that spans a small area, e.g. an office,
with each computer being a node on the network.
54
Lossless compression A data compression technique which results in data being
returned to its original form without any loss of information when it is decompressed. The
decompressed file and the original file are identical.
Lossy compression This is a data compression technique which results in data not
being returned to its original form when it is decompressed. The benefit of using this
technique is that it provides a higher degree of compression than lossless compression,
thus saving on storage space and transmission time over a network.
Media Access Control (MAC) address This is a unique serial number residing in the
firmware of a network interface card that identifies the network card on the network.
MP Mega Pixel See Pixel
National Health Service Information Authority (NHSIA) This is a special health
authority whose remit is to setup a national infrastructure and facilities for information
systems in the NHS (http://www.nhsia.nhs.uk).
Pixel This is a word defined from the term “picture element” and is the smallest viewable
element, rectangular or square in an image or display. A monitor is often defined by the
number of mega pixels (MP) in the viewable area. 1 megapixel is approximately 1 million
pixels. The function of a workstation will determine the number of pixels required in its
display.
Radiology Information System (RIS) A computer system which stores patient
demographic information and examination booking information for a radiology
department and may be linked to the HIS. A PACS may receive exam booking
information and demographics from the RIS to form worklists and perform other
database tasks.
Redundant Array of Inexpensive Disks (RAID) A RAID is a multi disk system where
one or more of the disks provides fault tolerance. A RAID should be able to withstand
disk failure and have the ability to reconstruct the data stored on a failed disk.
Simple Network Management Protocol (SNMP) The protocol governing network
management and the monitoring of network devices and their functions.
Small Computer System Interface (SCSI) A parallel interface that provides fast data
transmission.
Uninterruptible Power Supply (UPS) A device which provides back-up power in the
event of failure in the primary power supply system. If there is a power-cut or drop-out
the UPS will keep the system running for a finite period of time, allowing the primary
power supply to be repaired and/or the system to be powered-off gracefully. This
protects the equipment and the stored data.
Virtual LAN (VLAN) a network of computers that behave as if they are connected to the
same wire even though they may actually be physically located on different segments of
a LAN. VLANs are configured through software rather than hardware, which makes them
extremely flexible. One of the biggest advantages of VLANs is that when a computer is
physically moved to another location, it can stay on the same VLAN without any
hardware reconfiguration.
55
Worklist The list of patient studies sent from the RIS and displayed at the appropriate
acquisition modality.
56

MHRA 04130 - PACS evaluation: Agfa PACS at Queen Elizabeth

Transcription

Similar documents

Untitled

Radiologist / Technologist Dataflow

RIS PACS Advanced Workflow Management

CBCC Achieves Imaging Efficiencies with PowerServer

Reporting Form - Yellow Card Scheme

Starkstrom TCP Panel eBrochure

digital slides

PACS Web Training Documentation

Experiences in moving from CRT to flat panel LCD monitors for

:DOTRIX TRANSCOLOR