Download PACS Specification - UK Imaging Informatics Group

SPECIFICATION FOR RADIOLOGY PACS
Introduction: The below document describes specifications for a radiology PACS for
storage & appropriate display of radiology images (CR/DR, CT, MRI, US, Fluoroscopy, etc).
If the same PACS is used for display of other images—ophthalmology, cardiology etc, please
ensure standards for storage & display of the types of medical images are reviewed &
incorporated into the specification.
Current day Radiology PACS Systems perform 2 basic functions
1. DICOM Image Archive & Manager—i.e. long term store of images—(this can be either
provided by a Vendor Neutral Archive or the PACS)
2. DICOM Image Display—display of images stored in the image archive above---This can
be either a part of PACS or a separate image viewer.
PACS= DICOM Image Archive/Manager + DICOM Image Display`
PACS integrates with the following IT systems :
 PAS (Patient Administration System) for demographics, current location, current
responsible consultant/GP
 RIS (Radiology Information System) for scheduling information & report information
 Modalities—receives images & image related information
1. DEMOGRAPHICS & ADT INFORMATION CONSISTENCY—All demographics &
ADT (Admission Discharge & Transfer information) must be kept up-to-date on all clinical
IT systems within any organization. Any demographics update or patient merges on PAS
must realtime update PACS systems.
IHE Standards--Patient Information Reconciliation (PIR) Profile: “PIR handles:
unidentified/emergency patient, demographic information updates ( e.g patient name changes
(marriage, etc.) , correction of mistakes, ID space mergers). Such changes are reliably
propagated to all affected systems, which update all affected data. The result is a complete
patient record. “
a) PACS
b) RIS
c) PAS
Must all comply with PIR Profile of IHE.
2. PATIENT BANNER INFORMATION---The patient demographics and ADT
information for a patient MUST be consistently displayed on the top demographic banner of
any clinical system (PACS, RIS & Ordercomms)---real-time demographics synchronization
with PAS is mentioned above. This is hugely important for patient safety & care –ensure that
timely communication, ensuring correct ID, timely action can be taken:
a. Name
b. DOB
c. Sex
d. NHS No.
e. PAS No.
f. Current Patient Location
g. Current Responsible Consultant
3. SEARCH CRITERIA FOR A SINGLE PATIENT or GROUP OF PATIENTS: It
should be possible to search for a single/group patients using one or any combination of the
following criteria:
a. Name
b. DOB
c. Sex
d. NHS No.
e. PAS No.
f. Current Responsible Consultant
g. Requesting Responsible Consultant
h. Current Patient Location
i. Operator
j. Reporter
k. Workflow Status of study (see section--)
l. Modality
m. Exam Description
n. Exam Room
o. Date or date Range (for exams)
4. CLINICAL DATA FIELDS DISPLAY on Images: Below describes Information that
needs to be stored & available for display for the clinical user/Radiologist viewing the PACS
image. This also identifies what clinical data fields should be transmitted as metadata fields
or tags to XDS registry/repository (if XDS is made the standard for including radiology
images into the EPR). The terms used for describing data fields must reflect terms in use in
NHS ( e.g.—Responsible Consultant/GP etc)
A. PATIENT DEMOGRAPHICS (synchronized with PAS)
a.
b.
c.
d.
e.
Name,
DOB,
Sex,
PAS No.,
NHS No. (CHI number for Scotland)—NHS number may not be
present in 100%exams sent to PACS
B. REQUESTER—synchronized with RIS
a. Name of Requester
b. Grade of requester
c. Contact number of requester
d. Requesting **Responsible Consultant/GP (Team)—(Also
RECIPIENT)
e. Requesting Speciality/Department/GP surgery
f. Requesting Institution
g. Date & time of request made
C. IMAGE DOCUMENT—synchronized with RIS & modalities
a. Modality
b. Exam Description---(National Exam Codes & Descriptions)
c. Date & Time image acquired on modality
d. Date & time of image sent from modality
e. Date & time received on PACS
f. Exam Room (where the exam has been performed)
D. OPERATOR/IMAGE CREATOR –synchronized with RIS & modality
a. Name of Operator
b. Grade of Operator
c. Contact number of Operator
d. Performing Responsible Consultant
e. Performing Department/Speciality--Radiology
f. Performing Institution/NHS Trust
E. REPORTER—synchronized with RIS
a. Name of Reporter
b. Grade of reporter
c. Contact number of reporter
d. Reporting Responsible Consultant
e. Reporting Department/Speciality
f. Reporting Institution/NHS Trust
g. Date & time report verified
F. WORKFLOW data fields
a. Workflow status
b. Workflow priority
It is important that the relevant data fields are synchronized between PAS, RIS,
modalities & PACS.
5. WORKFLOW STATUS: This is a key concept for driving a workflow within the
radiology department. The status must be synchronised between Ordercomms, RIS, PACS &
Results Acknowledgement systems.
a. Requested (ORDERCOMMS)
b. Request Vetted (RIS)
c. Request held/deferred--with reason (RIS)
d. Scheduled or appointment given (RIS)
e. Cancelled (RIS/ORDERCOMMS) with reason
f. Arrived (RIS)
g. Did Not Attend (RIS)
h. Exam started (RIS)
i. Exam Completed (RIS)
j. Exam not performed --with reason (RIS)
k. Report Dictated (RIS)
l. Unauthorised report (RIS)
m. Authorised/Verified Report(RIS)
n. Amended Report (RIS)
o. Report Viewed (Ordercomms/RAS)
p. Report acknowledged (ORDERCOMMS/RAS)
q. Review requested (Ordercomms)
r. Was not brought (RIS)
s. Housekeeping (RIS)
6. CULLING OF IMAGES
The PACS MUST be able to cull data based on local policies relating to data retention
periods. The deletion of culling of exams will be based on patient level retention
requirements or exam level retention requirements.
PACS must be hold these 2 data fields
a. Patient level date of deletion
b. Exam Level date of deletion
Whenever there is a mis-match in the date of deletion –patient level & exam level. The later
date must be used by the system for culling that image data
For example a simple logic which maybe applied for arriving at the date of culling:
A. Patient level Image Deletion date will be based on
a. 25 years after date of birth
b. 8 years after date of last exam
c. Manual extension to the date of deletion (medico-legal, oncology, research trials etc)
whichever is the later date
B. Image Level Image Deletion date
a. Obstetric exams –after 25years
b. manual extension to date of deletion (slow growing tumour, hip replacement etc).
Whenever there is a mis-match in the date of deletion –patient level & exam level. The later
date must be used by the system for culling that image data
A more complex logic-- to include 3 years after date of death maybe included in the logic in
Scotland.
The Logic for image deletion maybe applied on any IT system whether ---PACS itself, RIS,
PAS or an independent IT system used for applying the logic. Irrespective of the system used
to arrive at the date for culling, PACS vendor must be capable of populating & updating the
data fields :
a. Patient level date of deletion
b. Exam Level date of deletion
from the IT system that provides these dates.
If PACS itself can provide this logic & record the reason why a deletion date is manually
extended. This data (exam level data of deletion & patient level date of deletion) must be
migratable at the end of contract.
Please see the DOH guidance on records retention for details.
7. IMAGE RETRIEVAL & DISPLAY PERFORMANCE: Display of images for
reporting & comparison should be within 3-5secs on all radiologists workstations. This is a
well-accepted clinical standard. Access to images is dependent on server capacity, network,
display hardware spec etc. PACS vendor must specify network, server capacity, display
hardware appropriately.
However, if we are storing images simply for legal reasons then we need to store them as
cheaply as possible---e.g DVDs in a locked cabinet etc. As there is more time available to
retrieve images for medico-legal purposes---1-2 weeks. Number of retrievals required for
medico-legal reasons will be minute (compared to retrievals required for clinical assessment).
We need to inform radiologists & clinical community that images stored are not for clinical
usage.
8. DICOM MODALITY WORKLIST—When a patient arrives within a department a
modality (CT, MR, US etc) needs to be “aware” that the patient is in the department & pull
the relevant demographics & study information across to the modality (to avoid manual data
entry on the modality). In simplistic terms, DICOM Modality Worklist(DMWL) is a list of
patients on RIS who have an “arrived” status. As the scheduling system RIS is responsible
for scheduling patients & ensuring logging patients arrival into the department. Each
modality will continuously query the RIS (which should provide a DMWL) for any exams
–based on modality & Exam Room. Normally the DMWL provider is the scheduling system
used for scheduling information to a modality (In Radiology RIS provides a DMWL for
radiology modalities). The following information needs to be provided by RIS to
modalities.
a. Patient Demographics
i. Name,
ii. DOB,
iii. Sex,
iv. PAS No.,
b. Modality
c. Exam Description---(usually National/Local Exam Codes & Descriptions)
d. Exam Room
e. Accession No. (RIS generates this for every exam)
f. Study UID (RIS generates this for every exam)
The modalities query the RIS & display a list of patients--- related to one or more Exam
rooms who have “arrived” workflow status. Once the status is changed to “exam performed”
or “exam not performed” on RIS,-- the exam should drop off the DMWL and no longer be
visible to modalities.
Once the exam is completed on the modality, radiographers must be able to send images to
PACS.
“IHE Standard—Scheduled Workflow Profile-- Scheduled Workflow establishes a
seamless flow of information that supports efficient patient care workflow in a typical
imaging encounter. It specifies transactions that maintain the consistency of patient
information from registration through ordering, scheduling, imaging acquisition, storage and
viewing.
Modalities (as acquisition modality actor),
RIS (as departmental system scheduler actor),
PACS (as Image Manager & Image display)
must all support to Scheduled Worklfow Profile of IHE”
A standardised approach to DMWL provision is key to supporting long term storage of
DICOM images from non-radiology modalities like—cardiology, retinal images etc
Current Situation in NHS--In many hospitals in NHS, PACS Brokers (often called
Connectivity Managers, RIS Gateway, PACS Broker etc) provide DMWL functionality. This
could be related to the inability of RIS to provide a DMWL or PACS vendors insist on
including brokers as part of their PACS solution. However, if a RIS is capable of providing a
DMWL there is no need for creating an additional weak link between RIS and modalities--thus introducing an additional point of failure. Use of PACS Brokers is a non-standard
implementation. Hence, PACS replacement is a time for NHS to review their PACS
implementations so that they adopt global standards—which are key to ensuring plug & play
interoperability & reducing price of NHS IT.
Exceptional circumstances where a PACS broker may be required: If there are 2 or more
separate information system scheduling for the same modality—e.g. NBSS & RIS for a
mammography modality, Ultrasound modality used for cardiac echoes & radiology i.e.--scheduled by RIS for radiology & CIS for Cardiac Echoes. Use of brokers should only be on
exceptional circumstances.
9. CONSISTENT IMAGE QUALITY (FROM MODALITIES to PACS)---Images once
created in modalities will be sent to PACS for long term storage. Radiographers ensure that
images are of good quality before transmitting to PACS. It is important that image quality is
kept intact during transmission from the modality to PACS. Adherence to DICOM standards
& IHE will ensure that quality of images & data are not compromised.
IHE Standards— Consistent Presentation of Images Profile of IHE
“Consistent Presentation of Images maintains the consistency of presentation for grayscale
images and their presentation state information (including user an notations, shutters,
flip/rotate, display area, and zoom). It also defines a standard contrast curve, the Grayscale
Standard Display Function, against which different types of display and hardcopy output
devices can be calibrated. Thus it supports hardcopy, softcopy and mixed environments.”
Acquisition Modalities &
PACS (as Image Manager & Image Display Actor)
must support Consistent Presentation of Images Profile of IHE
10. THREE CLICK REPORTING WORKFLOW---SINGLE SIGN-ON (SSO) , DESKTOP
INTEGRATION (DTI) OR CONTEXT SYNCHRONIZATION, AUTOMATIC DISPLAY RELEVANT
PRIOR—
3 click reporting workflow should be possible from the RIS & PACS integration.
a. Draw up a RIS worklist for reporting
b. Launch a patient’s exam for reporting on RIS on left RIS monitor—automatic
display of current images on PACS on middle monitor with automatic display of
relevant prior on right monitor---dictate/VR a report on RIS
c. Click on the next exam on RIS worklist—which closes the previous PACS images
& launches the next patient on RIS & PACS
SSO-Process of logging in should be quick & slick. The system should support single sign-on
process as used in a hospital. As a minimum, additional user name and password should not
be required when using RIS & PACS. When a user logs into RIS for reporting the user
credentials must be passed onto PACS with no need for additional user name and password
input.
Desktop Integration (DTI) must be at EXAM level with Information Systems: Desktop
Integration with RIS is well established with PACS.
a. Automatic RIS to PACS Integration. In most NHS Trusts RIS is used for
reporting of radiology images. For clinical reasons there should be automatic
display of relevant radiology images when an exam is picked up for
reporting on RIS.
b. Manual PACS to RIS integration—when images are displayed on PACS, it
should be able to display the RIS for that episode. This would be important at
MDTMs, or when a request is made for a 2nd opinion etc, to allow for an
addendum to be recorded on RIS.
Similarly DTI is required with other Information Systems, CIS, Ophthalmology
System, Breast Screening System, Endoscopy Systems, if these images get stored on
the same PACS.
Automatic Display of relevant prior Image & Report: This is hugely important for
reporting Chest X-rays, oncology CTs in particular. It is well recognised that automatic prior
image and report display will increase the accuracy of radiologists report & improves patient
care. A good dynamic display protocol is required which automatically displays the prior
similar exam on the right hand monitor of PACS (with the middle monitor displaying the
current image for reporting). The associated report needs to be displayed automatically as
well. Making these display automatically increases the chance of prior images & reports
being reviewed & compared. This improves patient care & clinical quality.
11. BASIC RADIOLOGY IMAGE DISPLAY & MANIPULATION TOOLS: The type
of display dictates the user experience of PACS:
a. user must not be overwhelmed ---“”Workflow is inversely proportional to the number of
buttons on the PACS desktop”
b. number of steps to common tasks minimised
c. consistency of display of tools
The PACS needs to be operable by the least technically-savvy radiologist. Large number of
tools to choose from on the display can be frustrating for a user. Intelligent display of
commonly used image manipulation tools—windowing, measure, zoom, scroll etc should be
activated with 1 mouse click/step. The tools when configured by user for a modality should
be consistently displayed for each modality. (Should not require set-up every time one logs
on.)
 CR--windowing, measure, zoom etc



CT—scroll, windows presents, link studies, measure, zoom etc
MRI—synchronized scrolling with position between series in different planes etc
Thumbnails should be displayed for every series
Advice—Drive before you buy.
However, Basic Image Review profile of IHE will ensure that your PACS display at least
has the bare minimum features required for radiology image display.
IHE Standard: Basic Image Review"Compliant software must provide a predictable user interface and functionality sufficient
to review images for the purpose of clinical decision-making by ordering physicians:
display of grayscale and color images from any modality, visual navigation of the
available series of images through the use of thumbnails, side-by-side comparison of at
least two sets of images (with synchronized scroll, pan and zoom for cross-sectional
modalities) annotation of laterality, orientation, and spatial localization, annotation of
demographics, management and basic technique information for safe identification and
usage simple measurements of linear distance and angle cine capability for images that
involve cardiac motion (e.g., cardiac US, XA, 500 CT or MR)"
PACS ( as Image Manager & Image Display actors) must support Basic Image Review
Profile of IHE.
12. CT Image DISPLAY REQUIREMENTS: CT scanners are the main reason for data
volume explosion in Radiology. Cardiology, Oncology, Colon & Trauma are the specialities
where there has been CT data explosion. Storing of very thin axial slices has become the
norm and will continue.
a. PACS must have an automatic & seamless loading of MPR when thin CT slices are
loaded (stand-alone modality workstations waste radiologists time & are inefficient) –
automatic loading of MPR will save on unnecessary storage costs (currently many hospitals
store MDCT images in 3 planes—rather than have real time MPR on CT display)
b. Allow for synchronized scrolling in 3 planes for cross sectional imaging esp MRI
(CT/MRI).
c. Automatic display of relevant prior
d. Synchronized scrolling with prior scan
e. Ability to create 3D images or via a plug-in—trauma imaging, CT colonoscopy, cardiac
f. During MPR/3D viewing, super-user like radiologists should ability to save some key
images(a coronal image/sag image that shows the key lesion) as a separate series for
reference to the report.
g. User ability to define slab thickness and create images of different thickness real-time
h. Ability to measure distance, circumference, angle, and volume of lesions. This should be
easy & intuitive.
i. Ability to measure Hounsfield density (e.g. average density of a lung nodule, with
maximum & minimum density). This task should be intuitive & easy for any radiologist.
j. Scrolling speed –even with >1000 images the users should be able to scroll through images
very smoothly. Cine display must be present.
k. Scrolling speed over slow networks. CT is the commonest type of imaging done on-call.
Scrolling speed over slow networks is key to usage of PACS on-call. Local caching maybe a
way to improve performance over slow networks.
13. DISPLAY for REMOTE REPORTING & ON-CALL: Remote working is no longer
limited to private teleradiology companies. Increasingly NHS Trusts are encouraging
radiologists to do on-call from home (as this is more cost-effective for a tax funded health
service). Whilst on-call radiologists MUST be able to report from home (there must be a 3
click reporting workflow for use at home as well as in the hospital as described above with
SSO, DTI etc). A verified report on PACS prevents needs of verbal reports documented on
paper notes, and mis-understandings, and thus improving patient care & safety. In the future
we will see some radiologists requesting for part working from home. Technology needs to
support this.
a. access to any image from any location (including home)
b. consistent user interface (in or outside hospital)--with the full set of image
manipulation tools as if within hospital
c. Adaptive Loading---smooth scrolling speed through CT/MRI images. It is
important that over slow networks the solution is able to cache images (or use similar
technology), so that once loaded the radiologist is able to smoothly scroll through
even 500 to 1000 images very smoothly without any “jumps” or skipping of
images. Customer may request for this to be tested prior to buying they system
d. Consistent DICOM image quality of images (even when reporting remotely)
e. Access to other information--Request cards, scanned doc, clinic letters etc
f. Ability to DICOM push to other hospitals even when working remotely (neurosurgical centres etc).
14. PLUG-INS & WORKFLOW SUPPORT for PLUG-INs-: Radiology PACS suppliers
(which is largely a DICOM image archive with a basic image display) should show a
willingness to integrate with specialist best of breed specialist display systems (called
PLUG-Ins) chosen by the customer. However, a 3 sec launch of images of the specialist
display systems or PLUG-IN from PACS must be maintained. PLUG-INs will allow for
post-processed 3D image, Templated image, Image with CAD analysis, Images of vessels
with measurements/assessments etc to be created. If a user wishes to save an image created
on the plug-in, the system should allow user to save images in a DICOM format as a separate
series within the PACS study. Adoption of DICOM Application Hosting API standard (Or
Supplement 118 of DICOM standard) will allow an open standard for integrating plug-ins
into the basic radiology PACS. It is important supplier adopts open standards for support
plug-in integration.

MPR plug-in for MDCTs (usually this should be a standard element of a basic
PACS---see section 12)
 Mammography display plug-in (normally this should be part of standard PACS
display without need for plug-in—see section 16)
 PET-CT fusion display plug-in (Normally this should be part of standard PACS
display without need for separate plug-in---see section 36)
 CT colonoscopy plug-in
 Cardiac CT plug-in—calcium scoring, coronary artery analysis etc
 CAD for mammography plug-in
 Orthopaedic templating plug-in
 CT Vessel Analysis plug-in
 3D CT plug-in etc
Having access to best of breed plug-ins in key to improving user experience of the display
software.
CONTRACT CLARITY: Supplier must provide clarity of
a. which of the above plug-ins are standard part of their display.
b. which plugs-in are provided by the supplier as an optional extra & what is the cost
c. Is there a willingness by the PACS supplier to allow integration with 3rd party plug-ins and
what will be the cost on their side for each plug-in integration.
d. What would be the technical requirements for integrating plug-ins?
e. Does the supplier support open vendor neutral standards for integrating plug-ins---i.e.
DICOM Applicating Hosting API standard (or supplement 118 of DICOM standard)?
f. Confirm that images created in the plug-in would be saved as a separate series within the
PACS study.
15. NUCLEAR MEDICINE IMAGE STORAGE & DISPLAY: In most NHS hospitals
radiologists perform NM Image reporting amongst the other radiology reporting activities. It
is inefficient & costly for a tax-funded health service, if a radiologists have to move to
different workstations or equipment to report NM, Mammography, CT, MRI, CR etc. Hence,
it is vital that the PACS is able to store & display NM images adequately. There is also a
move from diagnostic display from monochrome to diagnostic display with colour which is
adequately able to display both NM & CR adequately (see section 25)
Nuclear Medicine Profile : The Nuclear Medicine profile is a set of specifications as to how
NM systems (Gamma cameras etc) and PACS systems should interact when dealing with NM
data. The primary focus deals with storage and display of such data on PACS systems.
PACS (as Image Manager & Image Display actors)
Gamma Camera etc (as Acquisition Modality actor)
must conform to of Nuclear Medicine profile of IHE.
16. MAMMOGRAPHY IMAGE STORAGE & DISPLAY: In most NHS hospitals
radiologists perform Mammography reporting amongst the other radiology reporting
activities, and also ultrasound, MRI & ultrasound form a group of modalities used in
combination for breast radiology. It brings about in efficiencies if a radiologists have to
move to different workstations or equipment to report Mammography, US, MRI, etc. Hence,
it is vital that the PACS is able to store & display Mammography images adequately.
Mammography Image Profile: Efficient mammography reading requires specific display
quality, behaviour, layout and annotation of images, as well as convenient
comparison of prior with current images. The IHE Mammography Image Profile was
developed specifically to define the necessary mammography requirements.
PACS ( as Image Manager & Image Display actors)
Mammography CR/FFDM (as Acquisition modality actor)
must conform to Mammography Image Profile of IHE.
17. RADIOLOGY REPORT & REQUEST DISPLAY (HL7 CDA display support):
Radiology Report & Radiology Request are documents which are created in other clinical
systems—RIS for radiology report & Ordercomms for radiology requests. The emerging
global document standard for clinical documents is HL7 CDA (Clinical Document
Architecture) & is being adopted by NHS. PACS must be able to display radiology reports &
requests as CDA documents which are transmitted to it. Radiology images, requests &
reports must always be linked together (in the same way as the traditional film packets in
NHS contained both these documents.) With 1 mouse click these linked documents must be
displayed along with the images.
Displayable Reports (DRPT) Profile of IHE: manages creation and distribution of “display
ready” (PDF or CDA) clinical reports from the creating application, to the department, and
to the enterprise.
PACS must be a report reader actor for Displayable Report Profile (with option of report
repository)
18. VIEWING OF IMPORTED IMAGES in TEMPORARY FOLDER: Currently in
most PACS systems when images are sent from another hospital via DICOM push, they
arrive into a Temporary folder (often referred to as a unverified folder). A RIS entry (called
fixing) which validates the demographics needs to be created before it can be assimilated
properly into the PACS store. However, it is important these images (called unverified
images) can be viewed by clinical users (this is important for emergency care of patients).
An alert must pop-up warning the user that a demographic check must be performed. It must
be possible to delete these temporary folders if Trust does not wish to include them in the
permanent PACS store.
19. PART of ELECTRONIC PATIENT RECORD---Radiology images must become part
of a wider clinical record (Electronic Record). With next generation PACS it is important that
we move away from a radiology data silo & make radiology a part of the holistic patient
record. Adoption of global standards is key to this concept:
PACS must act as an XDS-I source actor of Cross Enterprise Document Sharing
Profile-Imaging of IHE
PACS must act as XDS &XDS-I Consumer actor of Cross Enterprise Document
Sharing Profile-Imaging of IHE. This will allow viewing of other clinical
documents/images that are registered on XDS registry (will allow an EPR view of the
patient record)
Adoption of XDS by PACS will allow radiologists & other clinical users access to
integrated view of ALL clinical doc & images-ECG, Medical photographs, radiology
images, Discharge summaries, through an viewer that is XDS consumer compliant.
IHE Standard--Cross Enterprise document sharing for Imaging—XDS-I--- Sharing
imaging documents between radiology departments, private physicians, clinics, long
term care, acute care with different clinical IT systems & thus make it possible for
radiology images to become part of the patient’s EPR.
20. IMAGE SHARING BEYOND INFORMATION GOVERNANCE BOUNDARIES.
Sharing of images is vital for continuity of patient care particularly with centralization of
services (cancer, stroke etc).
Current Sharing solutions beyong IG boundaries include
a.DICOM push (direct or via IEP), &
b.Burning of encrypted CDs.
c.Import of CDs containing DICOM images
There needs to be transparency on costs if new DICOM push links are required & these
costs are clearly defined in the contract.
FUTURE IMAGE SHARING NEEDS: DICOM push & IEP require prior knowledge and
requires huge manual process for sharing. As we move into next generation PACS—adoption
of XCA-I will enable secure exchange of images beyond IG boundaries, which are timely &
automatic & easy---at the time of reporting of images. PACS images must be able to follow a
patient’s journey. XCA-I concept is key to this approach.
IHE Standard—Cross Community Access for Imaging—“The Cross-Community Access
profile supports the means to query and retrieve patient relevant medical data held by other
communities.”
21. TEACHING FILES CREATION: NHS Radiologists support patient management, but
also provide another important function --train the radiologists of the future. Hence teaching
files is integral to NHS radiology work. Interoperability standards are key to creation of
teaching files. If a non-standard approach is adopted, then there is a good chance that
radiologists will lose their teaching files, if the PACS vendor is replaced at the end of a
10year contract.
IHE Standard --- Teaching Files & Clinical Trials Export Profile (TCE Profile) of IHE. The
IHE TCE profile describes a method for using existing standards to simplify and standardise
the export of key medical images for education, research, and publication.
To ensure teaching files are future proofed:
PACS MUST be compliant with Export Selector & Export Manager Actors of TCE Profile of
IHE
If a Radiology PACS is going to be used as a teaching files server, then make sure that it is
specified that it is Receiver actor for TCE Profile. (Alternatively one could use the free
MIRC (from RSNA) --http://mircwiki.rsna.org/index.php?title=Main_Page as the teaching
file server which is compliant with receiver actor of TCE profile of IHE.)
22. AUDIT TRAILS/VIEW LOG—every time a patient’s image is accessed by a user. This
should be logged and the “view log” should be accessible to any user to see. This will remind
users that their data access is logged & thus improve patient confidentiality.
IHE Standard: PACS must support Audit Trail & Node Authentication Profile of IHE
“The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security
measures which, together with the Security Policy and Procedures, provide patient
information confidentiality, data integrity and user accountability. “
23. RADIATION DOSE MONITORING---It is important that radiology departments are
able to monitor doses to an individual patient, group of patients (e.g. children, women,)
specific modality, specific exam type etc--- to compare with national averages/standards.
IHE Standard: PACS must support REM Profile of IHE as an Image Manager Actor
“Radiation Exposure Monitoring (REM) facilitates the collection and distribution of
information about estimated patient radiation exposure resulting from imaging procedures.
The REM Profile requires imaging modalities to export radiation exposure details in a
standard format. Radiation reporting systems can either query for these "dose objects"
periodically from an archive, or receive them directly from the modalities.”
Modalities (as Acquisition modality actor)
PACS (as Image Manager actor)
Must support Radiation Exposure Monitoring Profile of IHE.
This will allow feeding of such information into a national radiation-monitoring registry for
NHS in the future.
Current situation in the NHS: Currently radiation dose information is entered in RIS
manually. Support of this profile will provide more accurate information as there wont be any
errors related to manual data entry into RIS & will also improve efficient working for
radiographers who will no longer be required to enter that data manually.
24. PACS DATA MINING: In addition to the DICOM image with DICOM tags, the
following data also need to be sent to PACS from modalities.
a. Date & Time image acquired on modality
b. Date & time of image sent from modality
PACS should also record the time images arrive on PACS. This information is important
for auditing the performance of PACS & networks--time it takes for images to arrive on PACS after they are sent,
quantify PACS downtime etc.
It is important that the following data is easily available for System Administrator/PACS
Managers—
a. time of image creation to arrival on PACS,
b. number of exams of a modality per room
c. time from image arrival on PACS to verified report etc
25. PACS HARDWARE: STORAGE & DISPLAY :
Storage Hardware: The PACS vendors can define the specifications of the storage
hardware—to ensure that image display parameters & performance can be achieved.
However, they should not insist on being the supplier of storage hardware. NHS Trusts must
be able to look at storage with a holistic view, for all storage requirements.
Display Hardware: PACS vendors need to specify the display hardware requirement for
adequate display of the images—grey scale, graphics card etc. However, Trusts must be able
to must be able to buy the hardware at open market competition. The PCs must not be limited
to PACS display only. It must be a multipurpose equipment.
Diagnostic Display Hardware Specification: Current (2011) specification for a multipurpose diagnostic radiology reporting workstations (to enable reporting of CR, PET-CT,
NM, CT on the same workstation) should meet the following minimum hardware
specifications with colour diagnostic monitors becoming standard:
a. Windows 7 OS (64 bit only)
b. Graphics 2GB
c. RAM 6 GB with ECC
d. Quad-core CPU of at least 3 GHz.
e. 3MP colour diagnostic monitors
26. PACS CLIENT SOFTWARE DISPLAY & dependencies--PACS client software (or any 3D, or any other plug-ins) must be able to take advantage 64 bit
CPU & Operating System Software. It is well known that PACS display client will be present
on the same workstation as RIS, EPR, VR/DD etc. If the PACS client is dependent on OS,
Java, Internet explorer etc, then this may result in conflict with different versions used by
other software used on the same workstation. This issue needs to be managed in a mature
way by the PACS supplier (PACS supplier must not simply ask the user to remove all other
software). One suggestion maybe to encapsulate the client with its required browser/Java/OS
patch and run as a virtual machine.
27. PACS STORAGE ASSESSMENT & MODALITY CONNECTIONS—PACS
supplier will make as an assessment of the volume of storage required
a. Duration of storage—(most patients 8years of on-line storage as per DOH requirements)
b. Number & type of modalities connected
c. Number of exams performed per modality type
CONTRACT CLARITY---Within a department new modalities will be added in radiology
during the contract period. There needs to be explicit clarity of the costs of connecting a new
modality & revenue consequence which maybe based number of exams generated from an
additional modality or volume of storage.
Non-DICOM modalities—The supplier must be capable of connecting some old nonDICOM modalities.
There maybe a requirement to store & display non-radiology images in DICOM--cardiac,
retinal images, endoscopy images etc . Adoption of relevant standards is key to scalability of
the PACS solution. Adopting a broker-less solution for PACS will allow scheduling to be
done on scheduling systems (Cardiac Information System, Ophthalmology Information
System etc)The contract should be transparent on this issue & both sides aware of additional
costs of DICOM connectivity of additional modalities & desktop integration with other
information systems.
28. USE OF PRIVATE DICOM TAGS (by PACS & Modality vendors)--Vendors must
use standard DICOM tags as far as possible. In exceptional circumstances when standards
tags are not available, then private DICOM tags maybe required. The vendors must provide
FULL documentation for ALL private elements they generate, including the circumstances in
which it is added, and the exact meaning and purpose of every individual element. When a
standard tag become available then PACS supplier must convert the private tag to a standard
one. Customer should be able to get the private DICOM documentation analysed by an
independent DICOM expert.
29. END OF CONTRACT DATA MIGRATION AGREEMENTS— PACS supplier must
support migration of all the stored image data (Storage should be in DICOM part 10 file
format preferably). Read-only access to data must be allowed to a Migration Service
Provider. PACS Supplier must provide explicit information about format of images stored &
if any proprietary compression is used. Information about how annotations & image flips etc.
is recorded must be provide upfront by vendor (? Private tags? Other format). Database
dumps must be permitted for migration if required. Supplier must support both DICOM push
& bulk data migration of data migration technologies.
PACS supplier must support Image Archive/Image Manager for Content Migration Profile
of IHE when/if this becomes available.
If PACS vendor chooses to store radiology reports & radiology requests, then they must be
stored in standard CDA format. This will ensure that reports & requests can also be migrated
into the new vendors PACS. (Normally it would be considered to be the role of RIS to
migrate/store reports—not PACS).
30. TESTING & TRAINING SYSTEM: There should be a separate test & training system,
which is separate from the live environment. This should act as a test-bed for
integration/testing new feature prior to roll out into live environment
For training—
a. There should be an e-learning tool provided. The system should be intuitive enough
so as require minimal training.
b. Single user interface –this is key to reducing the training and support needs for
customer & suppliers. (Separate radiology PACS display for radiologists & other
clinical users are more cumbersome for training).
c. Separate test system available for training (so that training does not need to be
performed on a live system)
31. LOCAL CONFIGURATION OF USER ROLES- User roles should be defined
locally:
a. Clinical Users: All medical users should be able to view images & Reports
b. Radiologists & Radiographers should be able to send images to another
DICOM destination (on-call neurosurgical unit)
c. System Administrators-delete images, correct attributes etc
32. SUPPORT, BUSINESS CONTINUITY & DISASTER RECOVERY
a. Support
i. 24/7 support
ii. 1 phone number to call
iii. Dedicated team of qualified engineers receiving call with ability to
directly deal with Network manager to distinguish whether network or PACS issue
iv. On-line tracking of issues raised
v. Transparency on response time to type of support calls
vi. Remote & on-site support capabilities
vii. Support should include integration to 3rd party systems
viii. Monthly data for support calls must be identified.
b. Business Continuity & Disaster Recovery: there should be no need for a
planned or unplanned downtime. Business continuity should be aimed for.
There should be a disaster recovery plan identified in the contract
33. STABILITY: Software display should be stable & show a consistent display once a
display protocol is set-up by the user. Software errors may occur, but there needs motivation
within the supplier to correct the errors in a timely manner. The supplier must have easily
accessible developers who are involved in the product development, who will be able to
understand the user needs & correct errors that maybe present.
34. PRODUCT DEVELOPMENT during contract lifetime:
a. The customers must have input into future system design/ functionality
updates. The supplier MUST have a vibrant user group including an electronic forum (with
both clinical users & system administrators involved) which suggests & votes on product
enhancement features
b. There MUST be a rolling agenda for product enhancement during the 10year contract.
Number of product development days for each customer must be defined at the start of the
contract period.
c. Clarity on how will the next upgrade version of the product be rolled out. (customers must
not be charged for software upgrade)
d. A software developer must be present at the User Group meetings and involved in the
electronic discussions to have an honest dialogue between users & suppliers about what
enhancement suggestions are viable for the supplier.
e. There should be a regular/monthly scheduled telephone conference between PACS
Manager & vendors support & development team (Clinical Users should also be welcomed if
they wish to have an input in a particular teleconf). This will allow for good relationship
building between supplier & Users.
35. PACS HOUSEKEEPING WORKFLOW--Sometimes images may arrive into PACS for an exam episode after an exam has acquired a
dictated/unauthorised/authorised workflow status.
This maybe due to
a. Radiographer completing exam on RIS prior to sending complete set of images to PACS
(requires user training)
b. Network delays/problems from modality to PACS
In both these cases, radiologists are reporting on an incomplete set of images & thus an
incorrect report maybe issued. PACS supplier must provide a solution to address this issue.
Option may include the ability to put exams into a housekeeping folder or change the status
to “housekeeping” for issues to be sorted. The PACS manager/administrator can decide to
either fix it with the study or change the RIS status to “exam completed/unreported” so that
the reporter has the opportunity to change the report if required.
PACS solution must be able to distinguish between the above scenario & post-processing
workflow- (where additional images added as part of post processing (orthopaedic
templating, MPR/3D images, are added) to just enter into PACS as a separate series after the
study has acquired a dictated/authorised/unauthorised status. Ideally, PACS should be able
recognise additional images arising from post-processing software without any problems.
36. PET-CT DISPLAY—Nowadays PET-CT is part of general NHS radiologists work –
whether it be for reporting PET-CT, display of PET-CT at MDTM, or reviewing PET-CT
images done previously whilst reporting follow-up MRI, CT etc. Hence, it is important that a
basic radiology PACS is capable of storing & displaying PET-CT images adequately.
 Colour display is essential on diagnostic workstations
 Display on monitor of >= 2 MP important (so display on the “RIS” 1 MP colour
monitor not really adequate)—Please see section 25 on hardware display of diagnostic
workstations
 Ability to change blend of PET and CT in combined display (Image Fusion)-- There




must be support of the DICOM Blending Presentation State
MIP, especially of PET
MPR of both CT and PET
Triangulated navigation
Flexibility of display formats (e.g. transverse, coronal & sagital of both modalities
simultaneously, or combination of some of these with MIP, etc)

37. PACS SERVICE LEVEL AGREEMENTS
A Business Continuity Model for PACS is required. Enterprise wide downtime (planned &
unplanned) is unacceptable for clinical practice. Any enterprise wide unplanned downtime
attributable to PACS lasting for more than a certain duration will invoke penalty (for e.g.—
loss of 1 month support revenue for a 4 hour downtime) and this will need agreement
between both parties. What kinds of SLAs does the PACS vendor support & what is the cost
for each time of SLA. Simple language must be used to describe the different types of SLAs
by vendors.
38. PACS COSTS
Supplier must provide a breakdown of deployment charges & revenue charges as below
A. DEPLOYMENT CHARGES
a.. Migration from old PACS
b. Modality integration--as per DMWL---(based on number of modalities provided in
appendix 1)
c. Back end HL7 data fields integration with RIS (list of RIS fields in section 4)
d. Desk-top Integration with RIS (spec provided in OBS)
d. ADT HL7 integration with PAS (as per section 2)
e. 3 MP colour monitor workstation hardware costs. Does this need to be bought from PACS
vendor?
f. Server & Storage hardware costs . Does this need to be bought from PACS vendor?
g. Integration with existing or new plug-ins from 3rd party--Advanced visualization plug-in,
Ortho-templating plug-in, CAD plug-in etc
h. Training--System Admin, Training of the trainers, etc
i. Supplier end Project Management
j. Software Deployment Charge
k. Optional Plug-ins provided by the PACS vendor
l. Any other deployment costs not included in the above breakdown
B. REVENUE CHARGES for a defined Service Level Agreement:
Please define the SLA and the associated service charges:
a. Support & Maintenance charges for PACS for different types of SLAs if supplier provides
different types of SLAs to customers:
PACS Software support & maintenance
Integration support to RIS, PAS, 3rd party Plug-ins, etc
Workstation Hardware support per workstation (if provided & supported by PACS
vendor)
Storage Area Network Support---(If provided & supported by PACS vendor)
Application Server Support
Any other support changes that may have been omitted. PACS supplier to clarify.
b PACS Licensing--there are various types of licensing provided by different PACS vendors-some are based on total number of users, some total number of concurrent users, others
based on number of images stored, some based on number of images retrieved for display,
others the total volume of data stored etc---it is useful to get clarity of the software revenue
charges as they will differ with each vendor
c. Licensing for plug-ins if provided by the PACS vendor-- (Ortho-templating, 3D, CT colon
etc)
d. Any other regular revenue charges
C. ADDITIONAL OPTIONAL COSTS
a. Software upgrade charges when it is available--some charge others include it in overall
revenue
b. Plug-in software upgrade costs
c. Pre-Term contract exit costs:
d. End of contract handover of data in DICOM part10 format charge
d. ANY OTHER CHARGES---not covered above.
39. EXAM LAUNCHED VIA a url.
It must be possible to launch the relevant images from a clinical IT system which contains the
report (like an Ordercomms—Results Reporting System, GP system etc) through a url which
contains the accession number within the url.
Compiled by Dr. Neelam Dugar
Consultant Radiologist
Chairman of RCR Imaging Informatics Group
17/10/11
Acknowledgements: the content of the document is largely provided by members of the
RCR Imaging Informatics Group discussions. Special mention given to the following
PACS Managers: Mr. Parveaz Khan, Mr. Glyn Davies, Mr. Simon Waddington, Mr. John
Parker, & Richard Bulmer & the following radiologists, Dr. William Saywell, Dr. Jon
Benham, Dr. Mark Griffiths, Dr. Peng Hui Lee, Dr. David Robinson, Dr. Andrew
Downie & Dr. Padhriac Connelly who were speakers at the Group meeting on the
topic—Next Generation PACS –”What Radiologists & PACS Managers need” at the
Autumn 2010 meeting of the Group & other members who have participated in the forum
discussions include Mr. John Skinner, Dr. Dave Harvey, Mr. Ed Mcdonagh, Mr. Gareth
James, Mr. Grant Shaw, Mr. Ben Johnson, Mr. David Granger, Mr. Paul Ganney, Dr.
Mark Radon, Mr. Oliver Daly, Mr. Adam Davis, Dr. John Brunt, Mr David Clunie and
many others who contribute to forum discussions
APPENDIX 1
Specifying the IHE standards for PACS
1. PACS must be an Image Manager actor for PIR profile of IHE
Patient Information Reconcilliation (PIR) Profile: “PIR handles: unidentified/emergency
patient, demographic information updates ( e.g patient name changes (marriage, etc.) ,
correction of mistakes, ID space mergers). Such changes are reliably propagated to all
affected systems, which update all affected data. The result is a complete patient record.”
2. PACS must conform to Image Manager & Image Display actor for SWF profile of IHE
Scheduled Workflow Profile-- Scheduled Workflow establishes a seamless flow of
information that supports efficient patient care workflow in a typical imaging encounter. It
specifies transactions that maintain the consistency of patient information from registration
through ordering, scheduling, imaging acquisition, storage and viewing.
3. PACS must conform to Image Manager & Image Display actors for Basic Image Display
profile of IHE
Basic Image Review Profile:
"Compliant software must provide a predictable user interface and functionality sufficient to
review images for the purpose of clinical decision-making by ordering physicians: display of
grayscale and color images from any modality, visual navigation of the available series of
images through the use of thumbnails, side-by-side comparison of at least two sets of images
(with synchronized scroll, pan and zoom for cross-sectional modalities) annotation of
laterality, orientation, and spatial localization, annotation of demographics, management
and basic technique information for safe identification and usage simple measurements of
linear distance and angle cine capability for images that involve cardiac motion (e.g.,
cardiac US, XA, 500 CT or MR)"
4. PACS must conform to Image Manager & Image Display actors of Consistent Presentation
of Images Profile of IHE.
Consistent Presentation of Images Profile of IHE
“Consistent Presentation of Images maintains the consistency of presentation for grayscale
images and their presentation state information (including user an notations, shutters,
flip/rotate, display area, and zoom). It also defines a standard contrast curve, the Grayscale
Standard Display Function, against which different types of display and hardcopy output
devices can be calibrated. Thus it supports hardcopy, softcopy and mixed environments.”
5. PACS must conform to Secure Node/Secure application actor of Audit Trail & Node
Authentication profile of IHE.
“The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security
measures which, together with the Security Policy and Procedures, provide patient
information confidentiality, data integrity and user accountability.”
6. PACS must conform to XDS-I source & XDS/XDS-I consumer actors of Cross Enterprise
document sharing profile of IHE.
Cross Enterprise document sharing for Imaging—XDS-I--- Sharing imaging documents
between radiology departments, private physicians, clinics, long term care, acute care with
different clinical IT systems—thus contributing to the development of an electronic patient
record concept.
7. PACS must conform to Export Selector & Export Manager actors of Teaching Files &
Clinical Trials Export Profile (TCE Profile) of IHE
The Teaching Files & Clinical Trials Export Profile TCE profile describes a method for
using existing standards to simplify and standardise the export of key medical images for
education, research, and publication.
8. PACS must conform to Image Manager Actor of Radiation Exposure monitoring profile
of IHE
“Radiation Exposure Monitoring (REM) facilitates the collection and distribution of
information about estimated patient radiation exposure resulting from imaging procedures.
The REM Profile requires imaging modalities to export radiation exposure details in a
standard format. Radiation reporting systems can either query for these "dose objects"
periodically from an archive, or receive them directly from the modalities.”
9. PACS must conform to Image Manager & Image Display actors of Nuclear Medicine
profile of IHE.
Nuclear Medicine Profile : The Nuclear Medicine profile is a set of specifications as to how
NM systems (Gamma cameras etc) and PACS systems should interact when dealing with NM
data. The primary focus deals with storage and display of such data on PACS systems.
10. PACS must conform to Image Manager & Image Display actors of Mammography Image
profile of IHE.
Mammography Image Profile: Efficient mammography reading requires specific display
quality, behavior, layout and annotation of images, as well as convenient comparison
of prior with current images. The IHE Mammography Image Profile (IHE Mammo)
was developed specifically to define the necessary mammography requirements.
11. DICOM
TAGS (Standard & Private)—Images must be stored in DICOM format.
Vendors must use standard DICOM tags as far as possible. In exceptional circumstances
when standards tags are not available, then private DICOM tags maybe required. The vendors
must provide FULL documentation for ALL private elements they generate, including the
circumstances in which it is added, and the exact meaning and purpose of every individual
element. When a standard tag become available then PACS supplier must convert the private
tag to a standard one ASAP.
12. PACS must be a Report Reader actor for Displayable Report Profile (with option of
report repository)
Displayable Reports (DRPT) Profile of IHE: manages creation and distribution of “display
ready” (PDF or CDA) clinical reports from the creating application, to the department, and
to the enterprise.
HL7 CDA display: PACS must be able to display radiology reports & requests as CDA
documents which are transmitted to it. Radiology images, requests & reports must always be
linked together.
13. DICOM Application Hosting API (Supplement 118 of DICOM standard)---PACS
must support DICOM application Hosting API standard for integrating specialist display
plug-ins.
http://www.ihe-europe.net/external/framework.htm
This link identifies number of vendors participating in worldwide connectathons to show interoperability.
APPENDIX 2
IHE Specifications for RIS
1. RIS must be an Department System Scheduler actor for PIR profile of IHE
Patient Information Reconcilliation (PIR) Profile: “PIR handles: unidentified/emergency
patient, demographic information updates ( e.g patient name changes (marriage, etc.) ,
correction of mistakes, ID space mergers). Such changes are reliably propagated to all
affected systems, which update all affected data. The result is a complete patient record.”
2. RIS must conform to Department System Scheduler actor for SWF profile of IHE
Scheduled Workflow Profile-- Scheduled Workflow establishes a seamless flow of
information that supports efficient patient care workflow in a typical imaging encounter. It
specifies transactions that maintain the consistency of patient information from registration
through ordering, scheduling, imaging acquisition, storage and viewing.
3. HL7 CDA support—RIS must be able to create & transmit radiology reports in HL7 CDA
format. RIS must be able to display HL7 CDA request document produced in an
ordercomms.
http://www.ihe-europe.net/external/framework.htm
This link identifies number of vendors participating in worldwide connectathons to show interoperability.
APPENDIX 3
IHE Specification of Acquisition Modalities
1. Modalities must conform to Acquisition Modality actor for SWF profile of IHE
Scheduled Workflow Profile-- Scheduled Workflow establishes a seamless flow of
information that supports efficient patient care workflow in a typical imaging encounter. It
specifies transactions that maintain the consistency of patient information from registration
through ordering, scheduling, imaging acquisition, storage and viewing.
2. Modalities must conform to Acquisition Modality actor of Consistent Presentation of
Images Profile of IHE.
Consistent Presentation of Images Profile of IHE
“Consistent Presentation of Images maintains the consistency of presentation for grayscale
images and their presentation state information (including user an notations, shutters,
flip/rotate, display area, and zoom). It also defines a standard contrast curve, the Grayscale
Standard Display Function, against which different types of display and hardcopy output
devices can be calibrated. Thus it supports hardcopy, softcopy and mixed environments.”
3. Nuclear Medicine modality must conform to Acquisition Modality actor of Nuclear
Medicine profile of IHE.
Nuclear Medicine Profile : The Nuclear Medicine profile is a set of specifications as to how
NM systems (Gamma cameras etc) and PACS systems should interact when dealing with NM
data. The primary focus deals with storage and display of such data on PACS systems
4. Mammography modality (CR/FFDM) must conform to Acquisition Modality actor of
Mammography Image profile of IHE.
Mammography Image Profile: Efficient mammography reading requires specific
display quality, behaviour, layout and annotation of images, as well as convenient
comparison of prior with current images. The IHE Mammography Image Profile (IHE
Mammo) was developed specifically to define the necessary mammography
requirements.
5. Modalities must conform to Acquisition Modality Actor of Radiation Exposure
monitoring profile of IHE
“Radiation Exposure Monitoring (REM) facilitates the collection and distribution of
information about estimated patient radiation exposure resulting from imaging procedures.
The REM Profile requires imaging modalities to export radiation exposure details in a
standard format. Radiation reporting systems can either query for these "dose objects"
periodically from an archive, or receive them directly from the modalities.”
http://www.ihe-europe.net/external/framework.htm
This link identifies number of vendors participating in worldwide connectathons to show interoperability.