RIS Business Case
Presented to IT Strategy Group on
2008
Purpose of this Document
This business case demonstrates the urgent requirement for the replacement of the
Radiology Information System (RIS)
Key issues



A RIS is a computer system designed to support the operational and business analysis
within a Radiology Department
The current contract will end March 2010. The Trust can either extend the contract, at an
unknown cost, for a maximum of 2 years or procure a new one.
The RIS is a repository for all imaging appointments, reports and results, to not have one
would affect the whole Trust.
Summary of Recommendations
To purchase a new RIS before the end of the contract and undertake full data migration of all
Radiology information.
Author and
Contact Person
Sponsor
Date to be
approved by
Trust Board
Version
Number
Issue Date
2.3
19/11/08
Review Date
Radiology
RIS Business Case
5.11.08
Executive Summary
Introduction
The purpose of this document is to set out the Business Case for the procurement of a
Radiology Information System (RIS) at.
A RIS is a computer system designed to support the operational and business analysis within a
Radiology Department. It is also a repository of all imaging reports and results, and in the future
will contribute to the Electronic Patient Record.
The RIS includes data on all Radiology imaging specialities. It is an essential component of the
modern imaging workflow and integrates closely with existing systems such as Picture
Archiving and Communications System (PACS) and Patient Administration System (PAS).
The business case for the implementation of the PACS identified and included rationale for the
replacement of the incumbent RIS. The benefits realisation and strategic plan for the PACS
project recognised that the two systems were critically linked. A future upgrade or replacement
of the RIS was essential to realise both the expected quality and financial benefits that the
implementation of PACS would deliver.
The replacement of the existing RIS system within Radiology is highly important and has a key
deadline date. This is due to notice being given to the Trust by the current vendor, that the
product currently used will no longer be supported by them from March 2012. Current vendor
are also ‘sun setting’ their resources on this product so any technical or developmental support
that is required up to this period will be difficult to source. An original date of March 2010 has
been extended to 2012 by negotiations with Connecting for Health (CfH). The programme
manager from CfH has stated to still aim for March 2010 as being the deadline date. This gives
a limited window to procure and install a new system. Without a RIS system the Radiology
department would find it impossible to function and so would have a major impact throughout
the rest of the Trust.
The procurement of a new RIS would facilitate:

Unification of the Trust-wide Radiology imaging information workflow (include MRI
reports and patients appointments on the system), and increase the stability and
robustness of these products

The Trust in the provision of a seamless Radiology service throughout the
organisation

Standardisation of the Trust wide Radiology datasets to facilitate improved quality of
data Management and financial reporting

Customisation of RIS functionality to meet Specialist requirements

Workflow optimisation within Radiology through RIS/PACS Desktop integration and
the adoption of Voice Recognition technologies in Radiology as well as continuation
of digital dictation which is being used fully. This in tern would improve report turn
around time and diagnostic wait time

The realisation of the full benefits of PACS in terms of efficiency
Page 2 of 78
Radiology
RIS Business Case
5.11.08

The provision of a reliable RIS/PACS Business contingency and Disaster recovery
plan

Seamless integration with existing trust System Technologies including, PAS,
eventual EPR, order comms and the Trust’s Contract and Financial Systems

Developments in telemedicine and teleradiology inside and outside the Hospital. This
process could be used for the delivery of oncology diagnostics, but also strategically
in development of future business opportunities

Clinical Governance by supporting clinical decision making

The continued guarantee that both diagnostic images and reports are available as
required, throughout the organisation, and externally at the point of need

Radiology to meet ever increasing activity levels, with reference to imaging access
and report turn around times and meeting 18 week pathway targets

Radiology in achieving a 4 week diagnostic wait target as stipulated by the Trust

The further development of a business model for Radiology, facilitating competitive
delivery of services for internal and external market forces.

Continuity of service by migrating historic Radiological data from the existing RIS
database, thereby facilitating complete Radiological diagnostic record

Performance monitoring of Radiology services with a robust performance framework
to deliver services in a sustainable and competitive manner
The document sets out the Business Case for the proposed investment and is based on a five
point business case model.
1.
2.
3.
4.
5.
Business Requirements
Strategic Case
Economic Case
Financial Case
Management Case
1.
Business Requirements
This section details the business requirements including the expected benefits, business and
user objectives, that will be realised following the successful implementation of a new RIS.
2.
Strategic Case
The procurement of a new RIS will equip the Trust with the software required to achieve
sustained improvements not only within Radiology but every other area that uses Radiology’s
services.
The key strategic rationale for the procurement of a new RIS is to:
Page 3 of 78
Radiology







RIS Business Case
5.11.08
Improve quality of care
Improve Radiology’s performance
Increase efficiency, productivity and eliminating waste
Improve patient experience
Improve patient safety and reduce clinical risk
Provide accurate and up to date management information quickly
Support decision making and management forecasts
There are also external strategic drivers which will impact upon business of both Radiology and
the Trust:


3.
18 Week Wait
Patient Choice
Economic Case
It is well established that the current legacy RIS has a limited future within the market place. Its
sustainability and resilience are under question. If there is no RIS system available to Radiology
then this will have disastrous effects on the whole Trust. No Radiology examinations would be
able to be booked, no reports would be available and no imaging would be available as the
PACS system would not continue to function.
The current functionality, although working well for Radiology, does have some severe
limitations which impact heavily on the clinical and business objectives of Radiology.
After evaluation of the current RIS market place, an option appraisal was conducted which
resulted in three clear potential routes:
Option 1:
Option 2:
Option 3:
Do nothing
Find a third party company to take on the product.
Procure a new RIS from the market place by going out to tender
Procurement of a new RIS was deemed to be the most appropriate economic decision.
Whilst the initial investment is greater and short term disruption of services is inevitable, the
quality and operational benefits will be far greater with procurement of a new system.
Any new and current business developments introduced will not be supported with the current
RIS infrastructure. The product will no longer be available from 2012 and there has been no
indication of the financial cost of the two year extension from 2010. These facts strongly
indicate that failure to carry out a full replacement of RIS before 2010 is not a realistic economic
option.
A new RIS is a sustainable investment and is therefore deemed to be the most appropriate way
forward.
4.
Financial Case
The purpose of this section is to provide an evaluation of the affordability of the preferred
option.
Page 4 of 78
Radiology
RIS Business Case
5.11.08
The original PACS business case (2006) recognised that a replacement RIS was essential to
realise the financial and operational benefits of PACS and within that case the RIS replacement
was scheduled for 12 – 18 months post deployment of PACS.
Within the financial analysis for PACS the funding allocation required for RIS was included, and
at that time was estimated at £. This was to provide a fully functioning and integrated RIS.
Unfortunately this amount now seems unrealistically low in today’s climate. Key items such as
data migration, voice recognition and business functionality must be purchased which will add
to the over all cost substantially. An estimated cost would be £for this project to be successful. *
A new RIS represents the most appropriate financial investment, both tactically and
strategically. Whilst there is an appreciation that the initial capital outlay is greater, the option
provides greater long term stability not only to Radiology but the Trust.
5.
Management Case
This final part of the business case explains how the implementation will be handled so as to
ensure successful delivery of the RIS implementation.
With an investment of the size and complexity of that proposed under this business case,
sound project management is recognised as being of paramount importance. The project will
therefore follow the PRINCE 2 project management pathway. The lead will have previously
gained experience in implementing a large scale radiology project.
A formal project team and organisational structure comprising staff from various parts of the
Trust and beyond will be established prior to the implementation phase of the project.
The project will need the support of Trust, senior executives and clinicians, and the key
decision-making and consultative bodies within the Trust.
Conclusion
It can be concluded from the Business Case that the procurement of a new Radiology
Information System is essential to support the Trust’s strategic objective of being a modern
paediatric healthcare provider of choice.
This business case seeks approval to proceed with purchase and implementation of a resilient,
modern, high functionality RIS. This will deliver all the required performance, qualitative and
financial benefits, expected in an efficient Radiology department.
* Cost worked out by previous information provided during PACS implementation and discussions with TRUSTIT department
Page 5 of 78
Radiology
RIS Business Case
5.11.08
Table of Contents
Executive Summary
1. Introduction
2. Background
2.1
The Hospital
2.2
Clinical Service Unit of Radiology
2.2.1 Overview
2.2.2 Workload
2.2.3 Image Reporting
2.3
Information Systems
2.4
PACS
2.5
Connecting for Health (CfH) and Central Data Store (CDS)
2.6
Scope of Procurement
2.7
Current Practice
2.8
IM&T Environment
3. Business Requirements
3.1
Business Objectives
3.2
Expected Benefits
3.3
User Objectives
4. Strategic Case
4.1
Key Performance Areas
4.2
Key Performance Indicators
5. Economic Case
5.1
Option Appraisal
6. Financial Case
6.1
PACS Business Case
6.2
Cash Releasing Benefits
6.3
Financial Option Appraisal
6.4
Financial Conclusion
7. Management Case
7.1
Project Management Structure and Methodology
7.2
Project Board
7.3
Project Team
7.4
Implementation Team
7.5
Team Members
7.6
Project Assurance
7.7
Audit
7.8
RSI Clinical Groups
7.9
Governance Procedures
7.10 Pre Implementation Planning
7.11 Implementation Plan
7.12 Benefits Management
7.13 Financial Cash Releasing Benefits
7.14 Financial Non-Cash Releasing Benefits Analysis
7.15 Appraisal of Qualitative Benefits
7.16 Modernisation Agenda
7.17 Training
7.18 Communications Management Strategy
7.19 Operational Staffing
7.20 Project Reviews
7.21 Post Implementation Reviews
2
8
9
9
10
10
10
11
11
12
12
13
14
14
15
15
15
16
16
17
17
19
20
22
22
23
24
24
25
25
25
25
25
26
26
26
26
26
26
27
27
27
28
28
28
28
28
28
29
29
Page 6 of 78
Radiology
7.22
7.23
7.23
RIS Business Case
Project Evaluation Reviews
Risk Management
Security and Confidentiality
5.11.08
29
29
29
8. Risk Register
30
9. Functional Specification
30
Appendices
31
Appendix 1 Risk Register
31
Appendix 2 Functional Specification
35
Appendix 3 Issues with Current RIS
77
Page 7 of 78
Radiology
RIS Business Case
5.11.08
Full Business Case
Replacement of Current vendor Radiology Information System (RIS)
1. Introduction
has embarked on a major upgrade to its Information Technology (IT) infrastructure in
Radiology. The project includes the procurement and implementation of a Radiology
Information System (RIS) and its integration with the Trust’s existing Picture Archiving and
Communications System (PACS).
The replacement of the existing RIS system within Radiology is highly important and has a key
deadline date. The replacement of the RIS is a high priority in the Trusts IT Strategy. This is
due to notice being given to the trust by the current vendor, that the product we use will no
longer be supported by them from March 2012. Current vendor are also ‘sun setting’ their
resources on this product so any technical support that is required up to this period will be
difficult to source. This gives a limited window to procure and install a new system especially
with the data migration which is required of all old RIS attendances and reports that are on the
current system.
RIS and PACS must be highly integrated to ensure the continuation and improvement of the
radiology departments work flow.
This business case supports the rationale and the benefits of replacing the RIS on a trust wide
basis.
The aims and objectives of replacing the existing RIS are:

Unification of the Trust-wide Radiology imaging information workflow (include MRI
reports and patients appointments on the system), and increase the stability and
robustness of these products

To enable the Trust to provide a seamless Radiology service throughout the
organisation

Standardisation of the Trust wide Radiology datasets to facilitate improved quality of
data management and financial reporting

Customisation of RIS functionality to meet Specialist requirements

Workflow optimisation within Radiology through RIS/PACS Desktop integration and
the adoption of Voice Recognition technologies in Radiology as well as continuation
of digital dictation which is being used fully

To act as a catalyst to realise the full benefits of PACS in terms of efficiency

To provide a reliable RIS/PACS Business contingency and Disaster recovery plan
Page 8 of 78
Radiology
RIS Business Case
5.11.08

To ensure a seamless integration with existing trust IT System Technologies
including, PAS, eventual EPR, order comms and the Trust’s Contract and Financial
Systems

To support developments in telemedicine and teleradiology inside and outside the
Hospital. This process could be used for the delivery of oncology diagnostics, but
also strategically in development of future business opportunities

To support Clinical Governance by supporting clinical decision making

To continue to ensure that both diagnostic images and reports are available as
required, throughout the organisation, and externally at the point of need

To enable Radiology to meet ever increasing activity levels, with reference to
imaging access and report turn around times and meeting 18 week pathway targets

To assist in the further development of a business model for Radiology, facilitating
competitive delivery of services for internal and external market forces

To ensure continuity of service by migrating historic Radiological data from the
existing RIS database, thereby facilitating complete Radiological diagnostic record

To monitor performance of Radiology services within a robust performance
framework to deliver services in a sustainable and competitive manner
2. Background
2.1 The Hospital
Trust has earned its reputation as a first class provider of healthcare.
The Trust provides a wide range of high quality services, delivered by skilled professionals who
are experts in the care of children, and young people. The Trust also has an excellent track
record in its overall performance and making strides towards delivering improvements in line
with the NHS targets.
The Trust aims to provide top quality and accessible services. It provides care and treatment of
the highest quality, which is accessible, evidence-based, effective, and safe exclusively for
children and young people. A further aim is to develop the range of specialist services,
strengthening our role as a national leader in the care of people with complex health problems.
is at the leading edge within the NHS in the investigation, treatment and care of a local
population within and the surrounding areas. As a tertiary centre the Trust also treats patients
from elsewhere within the United Kingdom and abroad.
has approximately 1800 staff and 128 inpatient beds.
The Trust successfully deployed the Local Service Provider (LSP) procured AGFA Impax v6.2
PACS in February 2007. This is currently linked to Current vendor which is a legacy RIS.
Page 9 of 78
Radiology
RIS Business Case
5.11.08
2.2 Clinical Service Unit of Radiology:
2.2.1 Overview
The Project Manager for the replacement of RIS and the Operational Manager for PACS is Mrs
Sara Elliott.
The General Manager of Clinical Radiology is Mr Stephen Howe
The lead clinician in Radiology is Dr Iwan Roberts, the Lead Clinician involved in PACS and
RIS is Dr Penny Broadley.
The Operational RIS Manager is Mrs Gillian Simpson
The Radiology imaging modalities available across the hospital includes Computed
Radiography (CR), Fluoroscopy (RF), Ultrasound (US), Computed Tomography (CT), Magnetic
Resonance Imaging (MRI), Nuclear Medicine (NM) and Theatre work (XA), Dental imaging
(DX), Dexa scanning (OT).
Currently the Trust clinicians require access to all imaging and diagnostic reports produced by
the modalities listed above. As of February 2007, following the implementation of the TRUST
wide PACS, extensive work was conducted to ensure that all modalities archive to PACS,
following registration on the local RIS.
There is no routine printing to film in Radiology at TRUST albeit the facility remains in the
department as an emergency back up. Where patients are transferred out from the Trust to
other organisations compact discs are, where necessary, created containing the patient’s
radiological history. Direct PACS to PACS electronic data transfer is also possible with some
local Trusts, using the N3 network.
2.2.2 Workload
In 2007/8 approximately 40,000 radiological examinations were undertaken by the Trust. A
detailed analysis of the workload is given in the table below. The workload in the department is
shown as being consistent in recent years, although there are significant increases in
more complex imaging technologies such as Multi Slice CT and MRI and a reduction in plain
film imaging. For that reason we would need to allow an annual growth of 5 % over the next 5
years.
Page 10 of 78
Radiology
RIS Business Case
5.11.08
Department
2007/2008
Radiographs including DEXA
Fluoroscopy
CT Scanning
Ultrasound
PET/CT
Nuclear Medicine
MRI
28915
1570
1983
6222
3
627
1432
Table 1.1
2.2.3 Image Reporting
Most clinicians require a report to accompany a diagnostic image, relying on the expertise of a
reporting radiologist to interpret the image and give a diagnosis. The replacement of RIS will
continue to ensure that once an examination has been reported, it will be available for viewing,
with its associated report, outside radiology without the delay of manually transporting the
report to the requesting clinician.
Current practise within radiology for an acute examination is for a hand written provisional
report to accompany the patient back to the ward. With a new RIS there is the opportunity for
an authorised report to be produced within the same time frame as the hand written report by
using voice recognition technologies. This would speed up the department’s report turn around
time as a second visit to the examination would not be required. The technology would be
especially useful for part time radiologists who, due to the days they work, are currently not able
to authorise all reports within the time available to them on the day of dictation.
In the event that an examination could not be reported within the standard timescale, for
example when images are taken out-of-hours, PACS will continue to ensure that the images
are released for viewing outside Radiology in the knowledge that they will still be accessible for
subsequent reporting.
2.3 Information Systems
The Trust currently has a Radiology Information System (RIS) in operation. The Radiology
Department uses the radiology module of the Patient Administrative System (PAS), licensed
and supported by Current vendor Information Solutions of Warwick.
The Current vendor radiology information system was installed in 1998 and is a non-windows
character based application. As an application it does not support Order Communications
Systems, comprehensive workflow data analysis, single user sign on for reporting or any of the
more recent IHE RIS workflow tools without further investment by the Trust.
The current RIS system used by Radiology only has a further two upgrades available and this
product will be not supported by Current vendor from March 2012. Connecting for Health,
(CfH), after consultation with Current vendor will extend the life of this product from 2010 to
Page 11 of 78
Radiology
RIS Business Case
5.11.08
2012. Currently there has been no indication of the financial cost to the Trust and they would
have to enter an extension of contract with the supplier. This current situation has been raised
and is monitored on the Diagnostic directorate’s risk register.
The new RIS will be required to interface with PAS through an interface engine, to enable the
transfer of patient demographic information, reports and where necessary to facilitate PAS/RIS
event triggered pre-fetching. Data inputted into the RIS must then be available back on an
interface engine to help both the coding and finance departments. Soon after go live it is
envisaged there will be a procurement and replacement of our current PAS system. Any new
provider of RIS must enable the Trust to use a new PAS provider without great financial costs
being incurred.
The historic RIS data from the Current vendor RIS will need to be migrated onto any new RIS.
This is the medico-legal repository for all patient result/report information, prior to PACS. It was
highlighted in a recent Current vendor user group meeting that if all Trust’s stayed with the
software product until the end it would take two and a half years for Current vendor to
undertake all of the data migration required. This is a further indication why this project must
start now.
The new RIS must have the potential to interface with any proposed Clinical Requesting/Order
Communication System. It should also be possible to link to other systems such as the clinical
coding or financial systems to facilitate the transfer of activity information from RIS for billing
purposes.
The interface between the new RIS and the PACS software will enable modality work lists and
fully integrated RIS driven reporting, using a combination of voice recognition and digital
dictation software.
The RIS will capture information generated by Imaging modalities, such as dose and images
taken, and will allow detailed data retrieval and statistical reports to be created. These will be
used to optimise workflow, support mandatory data returns/reports and facilitate more efficient
income recovery.
2.4 PACS
was the first hospital in the country to have a fully functioning PACS (film less radiology) in the
form of the AGFA Impax product using smart card technology. Both Connecting for Health
(CfH) and Accenture (the Local Service Provider), will support the system as the NPfIT solution
until 2013.
The proposed new RIS must integrate closely with the existing IMPAX product, provide bidirectional desktop integration and facilitate a RIS driven workflow with PACS.
2.5 Connecting For Health (CfH) and Central Data Store (CDS)
TRUSThas largely been included in the NHS’s CfH RIS/ PACS programme. In RIS terms the
Trust is described as a legacy site (because it has an existing RIS installation). No funding has
been made available under the CfH Programme for the upgrade or replacement of the RIS.
It was recommended at the time of PACS implementation that workflow optimisation could only
be achieved with upgrade of the existing RIS or a replacement with a modern alternative. It was
proposed at the time to upgrade the current RIS to include HL7 messaging, which would enable
Page 12 of 78
Radiology
RIS Business Case
5.11.08
digital dictation, working from work lists, and that the Trust would revisit the topic 12-18 months
post PACS deployment.
Image storage is done through local storage (SAN) and centrally on the central data store
(CDS). Within the PACS programme, legacy sites are entitled to store data in the centralised
CfH LSP CDS, following the essential upgrade of RIS. We have undertaken the relevant up
grades to our RIS and are now able to send our images to the CDS.
Local storage capacity has been recently increased from 12 to 36 months with funding from the
Strategic Health Authority (SHA) although the revenue costs for this fall to the Trust. After 36
months data will only be available from the CDS and forms our long term archive and backup.
It is essential that any replacement RIS is compatible with the CDS as expansion of the local
SAN is expensive whereas the CDS is currently free. It is also envisaged that CDS in the future
will allow Trusts to share images. There will be no charge to retrieve other Trusts images where
legitimate relationships have been created. Any RIS replacement therefore, must be compatible
with CDS use.
Strategically report sharing and image sharing will prove vital in the future provision of
Radiology services.
2.6 Scope of the Procurement
The proposed Contract is for the purchase, installation, implementation, maintenance & support
of software (including interfaces) and associated hardware, for a fully resilient RIS solution. The
solution must also incorporate comprehensive Disaster Recovery architecture.
The proposed contract will also include migration of existing RIS data.
The provision of an integrated desktop, including both RIS and PACS functionality, is a key
requirement of the Contract. It should also include staff training, long-term technical support
and maintenance of the System. The System will have the following outline functionality:
Radiology Information System

Record and store radiology appointments and attendances including relevant clinical
information, the proposed examinations and the professional vetting process

Capture and store examination details including dose levels as per legislative
requirements

Capture and store reports on examinations; the system should enable reports to be
entered by keyboard or voice, and include speech recognition facilities

Facilities to analyse and report on the workload of the Radiology Imaging
department, including easy access to mandatory data returns, reports and financial
management

Provide accurate data on patient and report tracking, performance monitoring to
support and develop business strategy

Interfacing with other essential systems such as PAS, Order Communications, EPR
Page 13 of 78
Radiology

RIS Business Case
5.11.08
Delivery of timely reports in alternative formats to improve service to commissioners
2.7 Current Practice
Currently requests for radiology examinations are received on paper forms and the radiology
staff enter the details into the TRUSTRIS/PAS radiology module.
The creation of a Radiology attendance on RIS facilitates a PACS connectivity manager
generated work list, which is available at discrete DICOM imaging modalities.
The operator selects the patient demographics from the modality work list to link the patient’s
details with the newly acquired images.
When the examination is complete the radiographic staff send the resultant images to the
PACS archive directly from the imaging modality.
Once the images are on PACS they can then be viewed throughout the Trust by any clinician
that has a smart card. The images are also available for radiologists to review and report.
When they have been reported they are then typed and returned to the radiologist for
authorisation.
At this point both images and reports are available to the wider clinical community on a single
interface.
Presently digital dictation is used to create a paper report via the RIS work list. The report is
also available to all users of RIS when they look in the text area of the examination in PACS.
2.8 IM&T Environment

The Trust runs version v20 of the Current vendor Total Care Patient Administrative
System(PAS). A new PAS system will be procured and installed before 2012.



The Trust has approximately 190 PCs connected to the Trust PACS network.
The PC environment is predominantly Windows XP and 2000 based
New PCs are specified at Intel Core 2 Duo, 2 Gb memory, 160 Gb sata hard drive
and all PC’s meet CfH minimum standards.
The LAN is based on a 1 Gigabit core network with 1 gigabit onboard card with
defined resilience.
The main networking components (core switches) have a high degree of reliability
and redundancy built in, with dual management cards, and multiple power supplies
There are 5 diagnostic work stations where radiologists and reporting
ultrasonographers use digital dictation to record their reports
There are approximately 25 PC’s within Radiology where RIS can be accessed.




3. Business Requirements
Page 14 of 78
Radiology
RIS Business Case
5.11.08
3.1 Business Objectives
The business objectives of this Contract are:

To continue to improve the delivery of care to patients by making radiological reports
and images available to clinical staff in a timely fashion. Relevant patient data will
then continue to be available throughout the Trust

To unify the processes supporting the delivery of Radiology Imaging across the Trust
by the deployment of a single Trust wide integrated RIS/PACS

To replace the end-of-life hardware of the existing RIS System and to migrate the
existing stored data onto an industry standard platform

To procure and deploy RIS architecture that will minimise disruption, and resultant
impact on service

To implement a robust RIS Disaster Recovery solution and contingency plan

To contribute in the future to the development of the Electronic Patient Record (EPR)
as a repository for all information collected during the process of patient care

To support developments in telemedicine and teleradiology within the local, national
and international Clinical communities

To provide upgrades and refresh over the life of the Contract to ensure that the
system remains leading edge and fit for purpose

To provide robust and sustainable data extraction business tools, for clinical coding
and financial returns

To facilitate a reduction in Radiology result/report turnaround times

To provide quality assurance mechanisms and performance monitoring of Radiology
services
3.2 Expected benefits
TRUSTalready benefits from the advantages of operating a trust wide film-less Radiology
service. However the Trust expects to gain the following benefits from the implementation of
RIS:

Improved quality of RIS data, supporting business processes and financial recovery

Improved accuracy of management reporting

Continuation of a film-less service

Improved access to images and reports through consolidation of the digital archive
and viewing application
Page 15 of 78
Radiology
RIS Business Case
5.11.08

Improved resilience from new a hardware platform, which manages the risks
associated with end-of-life kit, currently in situ

Improved data security with the implementation of a resilient Disaster Recovery
solution

Contribution towards the achievement of the 18-week pathway and a 4 week
diagnostic wait target set by the Trust

Risk management benefits from bi-directional desktop integration

Enable the service to re-design working environment through use of improved
technology

Enhance teaching and research through greater access to information (i.e. Images
and reports available together)
3.3 User objectives
The users of the System include clinical staff from radiologists, radiographers and clerical staff
within Radiology. Although outside of Radiology, staff do not have direct access to RIS, reports
are still sought by medical, nursing and support staff across the whole of the organisation.
Other non clinical areas within the Trust also require some level of access to help with financial
coding and mapping.
From the user point of view the System must be easy to use, intuitive, highly responsive, robust
and resilient. The successful Supplier will be expected to assist the Trust in its work on clinical
process mapping, so that the full benefits for users and the organisation can be realised.
The system should support single sign-on, simple user interface and maximise clinical flexibility.
The system should assist the Trust in its use of the CFH smartcard access model as part of the
National Programme for IT (NPfIT).
Data of old RIS reports and attendances must be transferred onto the new RIS system to
reduce any risk caused by them not being available in a live system.
4. Strategic Case
The procurement of a new RIS will increase the capability and confidence of Radiology to
compete in a market driven environment, where patients and commissioners have freedom of
choice.
The aim is to equip the Trust with a system that will improve the delivery of high quality, patient
focused service.
4.1 Key Performance Areas
The key strategic rationale for procurement of RIS is to:
Page 16 of 78
Radiology









RIS Business Case
5.11.08
Improve performance
Improve access times
Improve quality of care
Increased efficiency, productivity and eliminating waste
Improve patient experience
Improve patient safety, reduction of clinical risk
Provide accurate and up to date management information to maximise income
Support decision making and management forecasting
Integrate into the Trust’s IT Strategic plans
4.2 Key Performance Indicators

Increase the percentage of authorised reports available within 24 hours of appointment.
A bench marking exercise has been carried out to determine the percentage of
authorised reports available after 24 hours of the appointed examination being carried
out. With new technologies being implemented such as voice recognition it is felt that an
improvement on this report turn around time can be achieved. Therefore new targets
have been set for 2010, post implementation of the RIS system.
24 hours

October 2010
45%
Increase the percentage of authorised reports available within 2 weeks of the appointment
14 days

October 2008
27 %
October 2008
October 2010
95%
100%
100 % of all patient radiology examinations completed within 4 weeks from time of request
A significant proportion of waste can be eliminated by implementing new systems of
work and using modern technology to our advantage.
Currently the time from a request card being written to it arriving in the department often
takes 2 or 3 days and in some extreme examples this can be extended to several weeks.
By ensuring that a new RIS is able to integrate with an Order Comms system, requests
could be accepted electronically and any delays abolished.
Introduction of a RIS which incorporates greater functionality than the present software
will allow radiology to redesign it’s internal workflows and streamline it’s processes to
further reduce delays and improve patient access times.
Incorporating a business statistic package with the RIS will allow near real time
monitoring for diagnostic breaches and improve the management of waiting lists.
Currently this is a time consuming manual process. There is limited information available
to us about patients 18 week status and we are unable to track where they are in the
process. An improved statistics package would also be essential in the management of
other areas within Radiology such as room utilisation.
Page 17 of 78
Radiology
RIS Business Case
5.11.08

95 % of all patient MRI examinations completed within 2 weeks from time of request. All
completed within 4 weeks

Reduce the number of did not attend (DNA) examinations from 10% to 5%
Currently the departments DNA rate is around 10%. By using text message technology
to remind parents to bring their child for an examination it is hoped that this will reduce
substantially. The Radiology department also needs to look at the work flow of creating
an appointment could it be done differently and if so does it make an impact on the DNA
rate.

Reduce overall cost of each examination
Every time someone within Radiology makes a change to the patient’s RIS entry,
alteration to an appointment, look at images or types a report, this adds to the overall
cost of the examination. By reducing the number of times something is done will reduce
the cost of the examination and consequently increase efficiency.
By using voice recognition and authorising as soon as the report has been compiled
efficiency savings can be made. The voice file no longer has to go to a secretary for
typing and then return to the Radiologist for authorisation.

100% of examinations booked in using national examination codes
Using the national examination codes will enable correct clinical coding and therefore
financial billing will be easier to facilitate. Radiology should also be able to use the
patient 18 week pathway identification number to inform finance where the funding for
the examination is coming from.
Page 18 of 78
Radiology
RIS Business Case
5.11.08
5. Economic Case
It is a well established fact that the current legacy RIS, provided by Current vendor Information
Solutions, has an extremely short lift span remaining.
It was installed into the Trust in 1998 and has continued to be upgraded to keep up with
technology advancements. Due to a contract end date being issued to the Trust with regards to
this product it would be a false economy to invest in new technologies offered such as voice
recognition, business objects and single smart card sign on. These alone would create
significant improvements within the Radiology departments work flow but as the sustainability of
this product is in question there seems to be little reason to invest.
The current functionality, although working reasonably well for Radiology, does have severe
limitations which impact heavily on the clinical and business objectives of Radiology and
without further financial investment would not be resolved. (See Appendix 3)
There are three clear options:
Option 1:
Option 2:
Option 3:
Do nothing
Find a third party company to take the product on
Procure a new RIS from the market place by going out to tender
Page 19 of 78
Radiology
RIS Business Case
5.11.08
5.1 Option Appraisal
The option appraisal for the above three options are tabled below:
Option
Option 1: Do
nothing
Cost
Advantages
1. No additional cost
2. No training requirements for
staff
3. No data migration
4. Continued stability of existing
services
Disadvantages
1. No technical support from April
2012
2. An extension to the current
contract must be agreed
3. Sun setting of current product
4. Digital dictation integration is
unreliable
5. Request cards and voice files
not stored within RIS
6. Software intermittently ‘hangs’
for all end users
7. Reliant on PAS functioning so
RIS is accessible
8. Unable to record all of
radiology’s activity
9. MRI use a different
appointment system
10. Statistics are very difficult and
time consuming to pull off RIS
11. Unable to raise bills directly
from RIS
12. Not 24 hour support
13 Multiple log ins for radiologists
to start reporting
14.Not 100% integration between
RIS and scanned request card
being viewed
15. No voice recognition
technology available
Option 2: Find a
third party
company to take
the product on
Estimated 1. Known product so no
unknown additional training requirements
2. No data migration
1. Cost of contract unknown factor
2. No company may be interested
in taking on this product due to
market forces
3. Unknown service and support
mechanism
4. Extremely risky
5.Current vendor may not want to
sell product licence
6. Limited time scale will make
this extremely difficult
7. Current financial market may
mean that companies do not want
to expand into an unknown area
8. Unknown if other Trusts in the
same situation would want to go
ahead with this option.
Page 20 of 78
Radiology
RIS Business Case
Option 3: Procure Estimated 1. New system tailored to our
and install a new £
way of working
RIS evaluating all
2. Able to pull statistics quickly
RIS products by
and easily off RIS
going out to
3. Able to use voice recognition
tender
and digital dictation in a fully
integrated system
4. Will enable national
examination codes to be used
5. Can create billing accounts
and records
6. Can track CD’s that have been
sent to other trusts
7. Keep a full record of
radiology’s activity
8. Dictation could be fully integral
reducing the number of vendors
having to contact when there is a
problem
9. 24 hours support can be
provided making PACS reliability
greater
10. Request cards can be stored
against the attendance and in the
RIS data
11. Not reliant on PAS function to
create work lists for modalities
and for reporting to be carried out
12. Uni-directional link with PAS,
but all data sent to an Interface
Engine so radiology information
accessible to coding department
13. Whilst PAS system is being
altered old patients information
can be accessed on RIS
14. Efficient collection of
radiology data for government
statistic reports
15. Able to assess the market
and look at a wide range of
systems to make an informed
choice
16. Potentially a new generation
system with additional benefits
17. All of Radiology’s information
will be on one system i.e. MRI
information included in RIS
18. Bi directional link between
RIS and PACS
5.11.08
1. Increased disruption and
training needs
2. Cost
3. All old data must be migrated
onto the new system
4. Time taken to procure and
install a new system
5. Needs IT department resources
and commitment from the Trust to
implement
Page 21 of 78
Radiology
RIS Business Case
5.11.08
Option 1 – Do Nothing – Not Recommended
This option entails taking no action with respect to the existing RIS. Our position would depend
on discussions taking place between CfH and Current vendor, paying an unknown amount for
the extension of the contract. There is no guarantee that the software provider wants to
continue in the current market place.
It does have the benefit of not requiring any additional training requirements or disruption to the
current service offered. However, this option exposes the Trust to continued significant
business risk. It is therefore deemed to be an untenable option.
Option 2 – Find a third party company to take the product on – Not Recommended
This should only be considered with extreme caution. There is no guarantee that Current
vendor will want to sell the software licence and it is completely unknown if any other company
wants to invest in this solution especially in today’s market place. All major factors such as cost,
support and service are completely unknown variables.
Option 3 - Procure and install a new RIS evaluating all RIS products by going out to
tender - This is the recommended option
It allows the department to look and consider all radiology information systems in the market
place. Even though time is limited we must take this opportunity to evaluate all the different RIS
products available to this Trust so an informed decision can be made.
Whilst the initial investment is great, and the short term disruption of services inevitable, the
quality and operational benefits will be far greater with procurement of a new system.
6. Financial Case
The purpose of this section is to provide an evaluation of the affordability of the preferred
option (option 3)
6.1 PACS Business Case
In the original PACS Business Case which was produced in 2006 it was recognised that a
replacement RIS was essential to realise both the financial and operational benefits of PACS.
The RIS replacement was scheduled for 12 – 18 months post deployment of PACS.
Within the financial analysis for PACS the funding allocations required for RIS were included,
and at the time was estimated at £. This was to provide a fully functional and integrated RIS.
Unfortunately this amount now seems unrealistic in today’s climate. Key items such as data
migration, voice recognition and business objectives must be purchased which all will add to
the over all cost substantially. An estimated cost would be £for this project to be successful.
Please see the table below for a break down of this.
Page 22 of 78
Radiology
RIS Business Case
5.11.08
Description
Cost in £000
Capital Cost, hardware and software
Digital Dictation, voice recognition software, hardware and licences
Data migration and cleaning
Interface engine to link PAS to RIS
Upgrade to Trust’s network
Total
These costs have been worked out using previous information supplied during the PACS
implementation and discussions with IT.
Annual revenue costs for maintenance and refreshment will be approximately £or 10 percent of
the total implementation cost.
During implementation it is envisaged that there will be a requirement to backfill both a
radiographer and also a radiographic aide. This is so staff can be released to undertake project
management, training of Radiology staff and the configuration of the new system.
Additional resource
costs
Total Cost
£000
Revenue cost
Explanation
1 WTE Band 6 Radiographer for a 16 week period
1 WTE Band 3 Radiographic Aide for an 12 week
period
6.2 Cash Releasing Benefits
The expected financial returns, from the PACS Business Case have been successfully
delivered and some places exceeded. With the inclusion of a successful deployment of a new
RIS (Option 3) the estimated and agreed financial returns can be more than realised.
It is felt there are limited cash releasing benefits for a new RIS. This project needs to be done
out of necessity rather than the requirement to improve. If a new RIS was not procured and
installed then all of the benefits we have already realised through the PACS project would not
be fully retained.
There are non cash releasing benefits to this project.

For radiologists using voice recognition technology aid in quicker report turn around
times. By doing so this would have a direct effect on the 18 week patient pathway
and the 2 week diagnostic goal set by the Trust

Have the opportunity to link RIS with an interface engine to aid clinical coding and
finance departments have a full understanding of the patient’s route through the
Trust
** IT do expect some cost but this is unknown as the product is unknown and so the amount to improve is also unknown
Page 23 of 78
Radiology
RIS Business Case
5.11.08

National examination codes can be adopted so exact financial payments can be
compiled

Statistic reports can be easily compiled reducing the requirements for management
to do this manually.
6.3 Financial Option Appraisal
Option
Description
Capital
OPTION 1 –
- Nil - now
1. Software unsupported from March 2012.
Do nothing
Future
capital
costs when
SAN
expires
2. Increase revenue costs for support of
local archive
OPTION 2 –
Completely
unknown
cost
1. Failure that a company will take on the
RIS product leaving the Trust in a
vulnerable position.
Find another
software company
to take on the
product
OPTION 3 –
1. £K
Procure and deploy capital cost
new RIS
2.£K data
migration
and
cleaning
Revenue
Comments
1. If RIS system is not delivered than PACS
benefits that have already been realise will
be lost to the Trust
2. One off cost during the implementation of
the RIS project.
3. £K VR
and DD
software
licences
4. £K on
interface
engine
connection
6.4 Financial Conclusion
Option 3 represents the highest financial investment. It is the only realistic option both tactically
and strategically. Whilst there is an appreciation that the initial capital outlay is greater, the
option provides greater long term financial return and fulfils the objectives of Radiology and the
Trust.
Page 24 of 78
Radiology
RIS Business Case
5.11.08
7. Management Case
This final part of the business case explains how the implementation will be handled so as to
ensure successful delivery of the RIS implementation.
7.1 Project Management Structure and Methodology
With an investment of the size and complexity of that proposed under this business case,
sound project management is recognised as being of paramount importance. The project will
therefore be managed in accordance with PRINCE 2 project management technology.
A formal project organisational structure comprising staff from within radiology and also various
parts of the Trust has been established prior to the implementation phase of the project.
The project will need the support of Trust, senior executives and clinicians, and the key
decision-making and consultative bodies within the Trust.
7.2
Project Board
The Project Board will consist of:-
7.3 Project Team
The Project Team currently consists of:-
7.4 Implementation Team
The implementation team will be made up of the project team plus other key members within
radiology. These include
The following specialist areas have been identified: Organisational development lead, Interface
Specialist, Communications, IT Technical and Network, Benefit Assessment both pre and post
implementation, Project Management, Change Management, Data cleansing and migration.
7.5 Team Members
In addition to the resources defined above, representation on the project team will be required
from other specialist areas within Radiology – for example, Ultrasound, CT and MRI – to work
on the project at specified times during the implementation. These will be defined and specified
during the planning phase.
7.6 Project Assurance
The Project Assurance function will be the ultimate responsibility of the Project Board. Work
associated with Project Assurance may be delegated to this team throughout the Project.
Specific roles and responsibilities will be included in the stage plans.
Page 25 of 78
Radiology
RIS Business Case
5.11.08
7.7 Audit
This project will be subject to internal audit to ensure the continued business integrity.
7.8 RIS Clinical Groups
Lessons learnt from RIS implementations at other hospital Trusts have recommended that RIS
clinical groups be introduced. It is important to recognise that RIS is a clinical system and
during implementation will have an effect throughout the Trust, and should therefore be
managed as a clinical system with IT support. Clinical commitment and support to the project
from its outset is vital so there is acceptance and ownership throughout the clinical setting.
RIS is solely a Radiology tool, although the reports will be utilised by many clinicians throughout
the Trust. A clinical champion within Radiology, and at least one from another department
should be involved in the clinical groups to maintain bi-directional communication throughout
the life of the system.
7.9 Governance Procedures
An established project management methodology will be utilised which, brings these
requirements together into a structured process. The project management methodology used
in the project is PRINCE2 (which meets the requirements outlined above and promotes
arrangements to ensure both rigorous and structured planning and monitoring and the
appropriate involvement of senior staff).
7.10 Pre Implementation Planning
Prior to implementing RIS the following activities will be required: 
Installation of any local network components required to support the RIS
Implementation

Pre installation work within the computer server room to support software installation
and back-up

Data cleansing activities on the Radiology Information System (RIS). This has been
happening since September 2008 and we hope to have all information up to date
before April 2009.

A policy for report migration needs to be defined. This will require clinical
involvement and commitment – both within and outside of Radiology – to ensure that
the policy for data migration currently held on the existing RIS is reflective of a
clinical need. Once defined, any data migration policy must be strictly adhered to
ensure accurate data reconciliation between the RIS, PACS and CDS system. NB,
The migration process is very time-consuming

An ongoing programme of communications with all stakeholders and interested
parties will be undertaken.
7.11 Implementation Plan
A detailed implementation plan will be generated as part of the initial engagement with Supplier.
It will be built in accordance with the following principles:
Page 26 of 78
Radiology
RIS Business Case
5.11.08

The implementation project will start with site preparation, final workflow analysis and
the arrival on site of the main RIS components and some workstations that can be
set up for training purposes

Whilst the Trust is happy to have the supplier leading the project management it also
recognises that the contract should be a partnership. Both parties should act
together to make the project a success. To this end each component of the
implementation should be broken down into more manageable phases, with each
component part leading into the next phase of the project.
7.12 Benefits Management
The RIS implementations and it subsequent integration with PACS will realise benefits. The full
benefits realisation plan will clearly identify the detailed arrangements for achieving the
business change and driving out the benefits.
A detailed benefits realisation plan will be produced within the coming weeks. This will involve
detailed work to identify the scale of anticipated benefits for each of the following benefit types:



Financial cash releasing benefits
Financial non-cash releasing benefits
Quality benefits.
7.13 Financial Cash releasing benefits
These categories of benefits have already been discussed within the Financial Case, where the
outputs have been used to show how they can contribute to making RIS affordable.
7.14 Financial Non–Cash Releasing Benefits Analysis
Analysis must been undertaken of estimated non-cash releasing financial benefits. These
represent efficiency savings that would be generated within an integrated RIS / PACS
environment.
This should be a working document as it will need to be refined as the Trust’s experience with
RIS develops.
7.15 Appraisal of Qualitative Benefits
An appraisal of the qualitative benefits will also be undertaken.
7.16 Modernisation Agenda
A robust RIS/PACS infrastructure underpins and supports the migration towards full Electronic
Patient Records.
7.17 Training
The supplier will carry out initial training of key staff, using a ‘train the trainer’ approach.
Radiology has identified key trainers to undertake cascade training these are Gillian Simpson
and Melissa Bielby. The provision of a structured and adequately resources training programme
will be a key element to the successful implementation of a RIS system.
Page 27 of 78
Radiology
RIS Business Case
5.11.08
The Trust has a RIS system manager who will allow staff to develop the necessary skills and
expertise required for cascade training amongst Radiology users.
The training programme will be specified in conjunction with the RIS supplier.
It is envisaged that some support may have to be given outside of normal working hours during
the implementation phase, and that an ‘On call’ service for RIS may need to be provided. If so,
a limited overtime and Out of Hour’s budget may be required during this time.
The supplier will ensure that the training plan identifies the resources required for delivery of the
training (including the number of trainers; location and capacity of rooms; and infrastructure and
equipment requirements).
Training facilities will be required.
Work has already commenced within Radiology to identify requirements for RIS training. An
analysis must be completed to understand the baseline of training needs and identify training
locations.
7.18 Communications Management Strategy
The project team will develop Communications Strategy and Plan for the RIS Implementation
Project, which reflects the requirements of the Project Team, Radiology department and the
organisation as a whole.
7.19 Operational Staffing
Once the system is operational, the project staffing requirements will change to reflect the
switch from a project environment to an operational day-to-day service. To that end the
requirement for project management will gradually disappear and the overall running of RIS be
returned to the RIS manager, Gillian Simpson. The RIS Project manager will return to
managing the PACS system and undertaking clinical work but will be available to back up the
RIS manager when required.
7.20 Project Reviews
In accordance with good practice, the project has the following outline arrangements in place
for project reviews:
7.21 Post Implementation Reviews
Radiology will be keen to ensure the lessons learnt are fed back to improve the effectiveness of
those projects that follow within the Trust. This is especially important as the replacement of
other key IT systems will be occurring quickly afterwards.
7.22 Project Evaluation Reviews
The Project Implementation Team intends to undertake a post-project evaluation, using the
benefits detailed in this business case as the success criteria. The objectives of the evaluation
will be:


Identify how well the project aims and objectives have been achieved.
Determine if the project timescales were met, and what corrective actions, if any,
were taken.
Page 28 of 78
Radiology



RIS Business Case
5.11.08
Determine if the project costs were controlled and were within budget, both overall
and for each of the parts of the project, and what corrective actions, if any, were
taken.
Against the benefits realisation plan identify what benefits have been achieved (both
cash releasing, if any, and non-cash releasing) and seek the realisation of any
outstanding benefits, including the implementation of any procedural and process
changes.
Creation of a ‘snagging’ list post implementation which will be monitored by the
project team and addressed.
This will be carried out for the project at a defined period post project completion.
7.23 Risk Management Strategy and Framework
The project’s Risk Management Strategy will manage, mitigate and control risks.
As part of its project management approach the project team will develop a comprehensive risk
register to track and manage project, service and business risks.
Risks will be managed at the appropriate level with escalation to the RIS/PACS Project Board
when appropriate.
7. 24 Security and Confidentiality
Maintaining the confidentiality and security of patient information has been paramount in the
NCRS specification (see section 730 of the NCRS Output Based Specification), design and
procurement of the NPfIT solutions.
All known issues of security and confidentiality will follow Caldicott principles. The issues of
patient confidentiality have been taken into consideration when outlining requirements for the
system. This includes the requirement for system security that ensures that all those who
access and change patient information can be clearly identified through an audit trail.
8. Risk Register
The evaluation of risk is an important element of the business case, particularly in large-scale
transactions such as this where significant degrees of uncertainty may exist.
The potential risks that apply for the deployment and subsequent operation of the RIS service
are grouped into the main categories of:

Development/Implementation

Change Management

Operational management

Identification and quantification of each risk
The project group must determine what actions will be taken to manage each risk and who will
own each risk.
Page 29 of 78
Radiology
RIS Business Case
5.11.08
The results are shown in appendix 1.
9. Functional Specification
In order to fulfil the procurement objectives for the proposed new Radiology Information
System, a detailed functional specification has been created.
This incorporates information on the various modules and core functionality that will be required
to deliver the required level of service and integration.
The supplier must make the Trust aware of its competence, and any previous relevant
experience in this area of deployment.
The functional Specification is available in appendix 2.
Page 30 of 78
Radiology
RIS Business Case
5.11.08
Appendix 1
Risk Register
RIS Project
Version No 1: 1st October 2008
Risk
No
1
Risk Description
Explanation
Mitigating Factors
Risk Owner
Insufficient
technical,
procurement,
implementation
or project
management
skills
Insufficient NHS
training
resources
Utilise experiences of
other adopters. Detailed
analysis of project team
requirements and skills
required in the planning
phase.
3
Hardware
inadequately
sized,
performance poor
Detailed analysis of the
radiology department
requirements.
Communication between
Trust and supplier
technical team. Functional
specification clearly
identifies need
4
Trust requirement
for extra items
underestimated
Refer to others sites and
evaluate if further items
were required during
implementation
5
Integration with
existing new
systems more
difficult/expensive
than planned
Unplanned costs of getting
equipment on line with
RIS. Assessment of
impact analysis planning
programme.
6
Network
infrastructure
does not support
RIS requirements
Detailed specification from
supplier. Appropriate IT
Technical involvement
both from the Trust and
the Supplier. User
involvement and
acceptance testing prior to
go live. Identify review
2
Utilise experiences of
other adopters. Detailed
analysis of training
requirements and skills
required in the planning
phase
Page 31 of 78
Radiology
RIS Business Case
5.11.08
points to check progress.
7
Product
companies go
into
administration or
withdraw from the
UK market
Gain a long term
commitment from the
company for support and
up dates in the product
Assess company position
in the market place
8
Conflicting Trust
priorities means
that other
projects will take
precedent
Programme planning,
dedicated resources. A
realistic timescale for
implementation. Flexibility.
Call on additional
resources and IT
Trust commitment to the
project
9
Planned/Expecte
d funding
components not
realised
Detailed discussions with
finance
10
Physical space
requirements
within the trust
are under
estimated
Find other places to house
equipment. Identification
of all service users.
Supplier specifications for
equipment obtained early
in the planning phase.
New equipment purchases
should reflect 'need' and
not 'want'
11
Supplier failure to
deliver to
timescales
Agreement of realistic
project timescales.
Contingency planning.
Monitoring of planned v
actual.
12
Failure of the
organisation to
adapt to new
technology and to
accept changes
in working
practices
Training resources to be in
place for all end users.
Good project ownership.
Regular RIS meetings,
disseminate information at
other meetings through
out the trust. Utilise
experiences of early
adopters
13
Disruption to
radiology and IT
services during
Good communication to
staff as to what is
happening and when.
Page 32 of 78
Radiology
deployment
RIS Business Case
5.11.08
Have a thorough training
plan to minimise disruption
to department and rest of
Trust
Weekly staff meetings with
all staff within Radiology.
Monthly RIS meetings.
Look at new processes
and procedures.
Reference to Trusts
Functional Specification
and suppliers contact.
14
Poor
communication
15
Supplier failure to
deliver to Trusts
Functional
Specification
16
Original
specification
doesn't meet user
requirements
Reference to Trusts
Functional Specification
and suppliers contact.
Ensure that specification is
checked by all
stakeholders
17
RIS requirements
affected by
legislation
changes or other
changes driven
from within the
NHS
Communication links with
appropriate groups
responsible for legislative
change. Early liaison with
supplier
18
Unable to provide
support and
helpdesk
services
Discuss with IT to see if
we can incorporate this
within the IT help desk
19
Data migration
costs
underestimated
Contact negotiation with
supplier. Contingency
planning
20
Generally poor
service
performance,
including service
failure
Contact negotiation with
supplier. Contingency
planning
21
Excessive
inflation
increases
suppliers costs
Monitor inflation rate
Set the price for the
system once tendered
Page 33 of 78
Radiology
RIS Business Case
5.11.08
22
Suppliers
operational
service costs
underestimated
Requirements should be
identified in the planning
phase. Liaising with
suppliers. Review points
through out the project
23
Security
compromise/virus
threat
Appropriate specification
and monitoring of audit
trail requirements.
Adherence to national and
local policies for anti virus
software. Contingency
planning.
24
Department
performance
affected as a
result of the
implementation of
a system change
Effective change
management strategy.
Specification of future
processes.
Communication with
Technical teams - both
supplier and Trust
Page 34 of 78
Radiology
RIS Business Case
5.11.08
Appendix 2
Functional Specification
RIS Requirements
The functional specification of the Radiology Information System is described in sections below.
1. General Functionality
1.1 Information about Patients
The system must have the ability to acquire information about patients from PAS and/or enable
it to be directly entered if the patient is not registered on PAS. This is to include:
Para
Requirements
1.1.1
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
m)
n)
o)
p)
q)
r)
s)
t)
u)
v)
1.1.2
Suppliers
Compliance
Statement
Patient details;
Surname
Full given names,
Preferred Given Name,
Title,
Address,
Post Code,
Date of Birth,
Sex,
Telephone Numbers (daytime, evening and
mobile),
Email address,
Former Name,
Alias or Other Name,
Ethnic Origin,
Parent/guardian/next of kin
Date of Death indicator
GP details.
GP name GP address
Registered GP code
Practice code
Practice contact numbers
PCT
Hospital number.
The format is a mixture of alpha-numeric and characters
1.1.3
The Trust format must be supported and displayed.
NHS number including check digit.
RIS should have an algorithm, as defined in NHS I.T.
Standards Procurement version 5a, part 212, and section
2, to validate the new NHS number and confirm its
uniqueness within the database.
Page 35 of 78
Radiology
1.1.4
a)
b)
c)
d)
e)
1.1.5
1.1.6
a)
b)
c)
d)
1.1.7
1.1.8
1.1.9
1.1.10
1.1.11
1.1.12
1.1.13
RIS Business Case
5.11.08
Patient Type:
Inpatient,
Outpatient,
GP,
A&E,
Other.
Flag to state that information should not be divulged to
anyone
Patient’s current status
NHS
Private,
CAT II,
Research etc.
Current Location (e.g. Ward, Theatre) if an inpatient, or
clinic or GP if an outpatient.
Known allergies or medical alerts e.g. MRSA etc. It must
be possible to restrict the display of sensitive information
Other Relevant Clinical information e.g. aneurysm clips,
pacing wires, pace maker when requesting specific
examinations which should be configurable by the
Hospital.
Name, speciality and GMC number of Hospital Consultant.
Site of referral
The system should be capable of capturing the patients
relevant Unique Patient Pathway Identifier, with the ability
to both import directly from the PAS system (via a choice
menu of the existing UPPIs for that hospital number on
PAS) or to manually enter this number as necessary. The
format is an alphanumeric code of 25 characters. The
system must be capable of assigning multiple UPPIs to
one hospital number, and to associate multiple
Examinations or Attendances with each UPPI. The
system must be capable of exporting the appointments
and appointments history (including cancellations and
appointment offers) to the interface engine linked to the
UPPI. This is to allow radiology examinations to be linked
to the appropriate 18 Week pathway where there may be
several pathways operating concurrently, allowing
appropriate booking by Radiology in order to optimise the
flow of patients along their pathways.
The system must be capable of capturing current (not
future) Referral To Treatment Period status (RTT status)
for each relevant UPPI, with the ability to both import
directly from the PAS system or manually enter RTT
status as necessary, with any changes made to the PAS
system also being updated to the RIS system in real time.
The system should be capable of importing any locally
defined RTT status codes used by the PAS system,
including any created or updated in the future. This is to
allow identification of those patients who have an active
Referral To Treatment Period ("clock").
Page 36 of 78
Radiology
RIS Business Case
5.11.08
1.1.14
The system must be capable of capturing current 18
Week RTT Start Date for each relevant UPPI with the
ability to both import directly from the PAS system or
manually enter RTT Start Date as necessary, with any
changes made to the PAS system also being updated to
the RIS system in real time. This is to allow appropriate
booking by Radiology in order to optimise the flow of
patients along their pathways.
1.1.15
The system must be capable of displaying an 18 Week
RTT End Date for each UPPI with an active clock. The
End Date is on day 126 with the RTT Start Date as day
zero. This is the last day of the patient's 18 Week clock.
1.2 Maintenance of the Master Patient Index (MPI)
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
The interface between PAS and RIS is to be real time and
unidirectional.
The RIS database will contain a full list of patient
demographics irrespective of whether a patient has a
Radiological History
The RIS system must have the ability to prevent
duplication of the primary identifier.
The RIS system should accept update or merge modify
messages from PMI’s and automatically update the
changes to the RIS patient record and therefore up date
the record on PACS.
There must be a Patient Index purification administrative
function to identify potential duplicates on predefined
matching criteria, i.e. those that are not on PAS.
A daily report should automatically be generated to contain
this information.
The RIS system must have a secure system to allow the
manual merge of two registrations if these are found to
refer to the same patient.
An audit trail of changes made to a patient record either
“automatically” or with manual intervention should be
available for scrutiny. The RIS system must have a secure
system to allow the manual unmerge of two registrations if
these are found to refer to different patients.
1.2.6
The system must have the ability for suitably privileged
users or System management staff to correct any field in
the patient record.
1.2.7
The system must have the ability to search its patient
index by at least the:
a)
Barcode – using barcode to find patient
b)
Hospital number,
c)
NHS number
Page 37 of 78
Radiology
d)
e)
a)
b)
c)
d)
e)
f)
g)
h)
i)
1.2.8
a)
b)
c)
d)
e)
f)
g)
1.2.9
1.2.10
1.2.11
1.2.12
1.2.13
RIS Business Case
5.11.08
Patient name,
Date of birth.
The resultant list of matches must show the patient’s full
name, date of birth, 1st line of address and postcode.
A “selected record” must include
Hospital Number
NHS Number
Full Name
Title
Date of Birth
Sex
Address incl. postcode
Contact Numbers
If the patient still cannot be found, then the system must
have the ability to interrogate the current PAS Master
Patient Index to search for that patient.
If a patient cannot be found, at least the following should
be possible to be checked:
Surname as written;
Incomplete surname;
Each element of a multi-element surname;
Alias (e.g. maiden name);
Forename and surname interchanged;
Date of birth;
Wild card
The resultant list of matches must show the patient’s full
name, date of birth, 1st line of address and postcode.
If the patient is present on the current PAS Master Patient
Index then the RIS system must have the ability to update
its index with the patient’s demographic details and
identifying number etc. from PAS’ Master Patient Index.
It must be possible to register a patient on RIS separately
from PAS in the event of a Medical Emergency or when
the PAS, or the interface with PAS, is unavailable.
The RIS must have the ability to assign a temporary
identifier to a patient and subsequently transfer the data to
a permanent identifier.
The system must have the ability to record data items in
addition to those listed in 1.2.7 above, as defined and
selected by the department.
It must be possible to create a list of RIS patients without a
PAS number registered in a specified time period and to
query PAS to find out if they exist on PAS.
Page 38 of 78
Radiology
RIS Business Case
5.11.08
1.3 Patient Profiles
1.3.1
1.3.2
1.3.3
The system must have the ability to maintain details of
patient episodes showing date, type, location,
examination, status and referring/ordering doctor, and the
facility for editing these examinations.
The system must have the ability to present full details of
each examination by selection from the episode history
area.
The system must have the ability to present both current
episodes and full historical attendances.
1.4 Information about Examinations
An Order Communication System may be provided in the future and a new RIS must be able to
integrate with this. The supplier must give full details of how this is achieved, how many sites
they have this successfully running in and with which software suppliers. The vendor must also
give an estimated cost of how much this work would cost now.
1.4.1
1.4.2
1.4.4
1.4.5
1.4.6
1.4.8
1.4.9
1.4.10
1.4.11
1.4.12
1.4.13
1.4.14
1.4.15
1.4.16
1.4.17
The system must have the ability to enter examination
requests onto the RIS directly
Date and time
If the examination is required to be done as a portable
Patient location & whether an inpatient, outpatient or direct
referral e.g. NHS, Private, EU patient or Other
Examination codes and descriptions as defined by the
Radiology Department – the NHS National codes will be
adopted in the new system - discrete local coding system
is currently in place.
Single and multiple examinations per attendance must be
supported
An indication of whether the examination is urgent or not
or the timescale in which it is required e.g. 3 months, 6
months etc
Patient LMP as appropriate
Prompts regarding contradictions for specific examinations
i.e. a CT abdomen scan following a very recent barium
study
An area to record the height and weight of patient for a
nuclear medicine examination
Patient Infection control alert; Barrier Nursed etc.
Patient mobility (e.g. needs a wheel chair/ trolley, requires
oxygen, has drains & IV’s etc.).
Need for GA/ sedation.
A flag to indicate research patients
Free text field for additional information
Name, phone number, GMC number and affiliation of
referring clinician; Directorate, specialty and Bleep Number
if a hospital clinician. – Bleep number would have to be in
Page 39 of 78
Radiology
RIS Business Case
5.11.08
a free text area.
1.4.17
1.4.18
1.4.19
1.4.21
1.4.22
1.4.23
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
Referral source for contractual purposes.
The referral source Trust identifier and where applicable
the PCT must be recorded for each attendance.
The system must validate the entry, e.g. report the last
time this type of examination was ordered for this patient
and warn the user if it seems as though it is being ordered
again too soon, or if the examinations are being ordered in
the wrong sequence. This should be displayed to the user.
The RIS must assign a unique identifying number to each
examination. Where there is more than one examination
in an attendance there must be a unique number for each
examination so that PACS can function properly. This
should be assigned at the time the examination is first
referred to, e.g. at Appointment or Attendance, whichever
is made first. This will consist of numerical and
alphabetical characters. Between the appointment and
attendance this number must be consistent.
The system must assign a cost code to each examination
using a look up table, which can be maintained by the
Hospital.
The system must group Examinations into Attendances for
reporting purposes. Each Attendance must be assigned a
unique identifying number. Each examination within an
attendance needs to be uniquely identified e.g. using a
combination of attendance identification number and
examination identification number.
The system must provide details of which stage the
attendance is in. Possible status values include:
request sent;
request received / on waiting list;
partial booking
appointment made; (deferred/non deferred flag)
appointment suspended
patient arrived / Did Not Attend;
patient prepared for examination, e.g. sedation/
anaesthetic cream;
examination started;
examination completed;
examination prepared for reporting (e.g. postprocessing, matching with previous non-PACS
images);
preliminary report dictated;
preliminary report transcribed;
final report approved.
Clinician notified
Patient cancelled
Clinician Cancelled
Imaging Cancelled
Preliminary addendum added
Page 40 of 78
Radiology
RIS Business Case
5.11.08
Addendum approved
Status should be visible in the RIS and any interface
engine that the Trust has put in place.
1.4.25 The system must have the ability to print all the patient
letters, radiology forms and labels needed for the
examination either immediately or later if the examination
is scheduled for the future. Whilst it is not expected to
produce film identification labels, the system must have
the ability to produce such labels. At a minimum, for each
examination, labels must be printed for the following:
a)
Patient examination label
b)
Episode label
c)
Packet label
1.4.26
1.4.27
1.4.28
1.4.29
1.4.30
a)
b)
c)
d)
e)
1.4.31
The patient ID (NHS Number and Hospital ID) Attendance
Number must be on these labels. The format and quantity
of labels produced should be user defined.
The system must be capable of printing reminder letters
automatically at a time determined by the Radiology
Department.
The system must be capable of creating email reminders
or SMS texting to a patient automatically at a time
determined by the Radiology Department.
The system must have the ability to enter and edit records
of additional examinations per attendance and apply the
additional financial codes. Where an additional
examination is taken the examination information must
update/ create a modality work list entry.
The system must have the ability to capture all data
relating to an order, which are required for billing, audit,
and organisation of room occupancy.
The system must have the ability:
to automatically amend the status of examinations
from “ordered” to “done” or "cancelled" etc.,
to record the consumables used
and to record who is cancelling the examination and
for what reason.
The system must have the ability to enter examinations
retrospectively, e.g. for registration of films from another
hospital or following system downtime.
Page 41 of 78
Radiology
RIS Business Case
1.4.32
The system must have the ability for suitably privileged
users or System management staff to unauthorise and
correct any field relating to the examination, even after
examination completion. Any changes must be recorded
in a log file.
In the future the Electronic Patient Record (EPR) must be
updated by the RIS module and reflect the status of all
orders received by RIS.
1.4.33
5.11.08
The RIS system must send EPR a message when an
order has been generated/ on the receipt of the request.
The system must send out subsequent messages when
the status of the order changes such as an appointment is
made / the request is refused/ the order is cancelled/ the
patient has attended/ a report is available.
1.5 Scanned Requests
1.5.1
The system must have the ability to receive images of
request forms and additional information from document
image scanners and associate these images with their
appropriate examination requests/ order number. The
system must enable these document images to be viewed
through the application software.
Supplier is requested to state the types and number of
document scanner required and how they are interfaced in
to the system.
Any scanners proposed must have very short warm-up
times so that the reception process is not delayed.
Page 42 of 78
Radiology
RIS Business Case
5.11.08
1.6 Reception Module
1.6.1
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
1.6.2
a)
b)
c)
d)
e)
f)
1.6.3
1.6.4
1.
2.
3.
4.
1.6.5
1.6.6
1.6.7
a)
b)
c)
d)
e)
1.6.8
Reception Module must be capable of capturing Patient
Demographics with a minimum dataset as follows (see
1.2.7):
Hospital/ NHS Number/Temporary number;
Full Name;
Date of Birth (with an option to enter age if exact
date
is not known);
Sex;
Address / Post Code;
Contact numbers (day and night);
Name, address and telephone number of registered
General Practitioner;
Source of referral;
Contrast allergy, medical alerts, claustrophobia etc.
Reception Module must have the ability to:
Search (either by Hospital/NHS Number patient
name
or by date of birth) for pre-registered patients both
on RIS and PAS;
Register patients with a local RIS number where the
link to PAS is not available.
Reception Module must have the ability to receive
requests via conventional x-ray request form, in which
request is entered on RIS by Radiology staff preferably
using a patient barcode label or through manual entry.
Reception Module must have facility for examination
orders to be entered:
Directly (as for walk-in, general radiography
patients),
By linking the order with a previously-made
appointment.
Reception Module must produce labels for each
examination. It must be possible to ‘switch off’ this feature
and to make it configurable by examination.
The system must have the ability to record the patient’s
arrival time in the department and the time of starting the
examination.
For each modality, the system must be capable of
generating a list on paper and on screen This list should:
Indicate the appointment time,
Give patient name, ward, date of birth, examination
type and referrer etc.
Patient’s infection control status of patients due to
come to the Radiology Department.
Once the patient has arrived and been booked into the
Department, the order must appear on screen at the
appropriate modality for the Radiographer to view and
select.
Page 43 of 78
Radiology
1.6.9
1.6.10
1.6.11
1.6.12
1.6.13
1.6.14
1.6.15
1.6.16
1.6.17
RIS Business Case
5.11.08
Once the patient has been booked into the Department,
the relevant examination schedule and status information
must be communicated to PACS and to the Clinical
Requesting System/OCS if the request for the examination
originated from that system.
Where there are multiple studies booked into the system
within a single attendance there must be a discrete work
list entries on the Modality and discrete records on the
PACS archive.
The system must provide the ability to enter, edit, cancel
and re-enter examination orders, both those that have
been requested through the Clinical Requesting
System/OCS and those requested by letter, telephone, or
presentation without notice.
If an examination is cancelled, the reason for the
cancellation must be captured and stored, and an
appropriate message must be sent automatically to PACS
and to the Clinical Requesting System/OCS if the request
for the examination originated from that system.
The system must provide the facility to record failed
examinations, the reason for failure and an outcome e.g.
rebooking of the examination.
The system must provide the ability to amend the
attendance data e.g. adding an additional examination
during the attendance.
Once details of an examination have been sent to PACS, it
should not be possible to delete the examination from the
RIS irrespective of whether the examination has been
completed although we must be able to amend the
examination type.
The system must ensure that such cancelled examinations
are not included in statistics.
The system must provide active Dicom Worklists to convey
status tracking on all workstations.
1.7 Appointments Module
1.7.1
1.7.2
a)
b)
c)
d)
e)
f)
g)
h)
i)
The system must provide the ability to quickly allocate
referrals to a Waiting List prior to an appointment being
assigned.
It must be possible to assign the following status to
referrals:
Held
Referred
Cancelled
Rearranged by hospital
Rearranged by patient
Arranged
DNA
Attended
Cancelled by patient
Page 44 of 78
Radiology
j)
k)
l)
1.7.3
1.7.4
1.7.5
1.7.6
1.7.7
1.7.8
1.7.9
1.7.10
1.7.11
1.7.12
1.7.13
RIS Business Case
5.11.08
Cancelled by clinician
Patient chosen to wait
It must be possible to extract management reporting data
about these patients.
The system must have the ability to record multiple
suspensions for each waiting list entry as necessary. The
system must be able to categorise these as either clinical
or patient based and provide a free-text or drop-down field
to hold detail about the suspension reason. The system
must be able to record a start and end date for each
suspension period.
The system must provide the ability to make appointments
for patients to have radiological examinations in the future.
(Referred status).
The system must display the patient’s recent examination
history.
The system must allow an appointment to be made for
specified modalities and examinations and automatically
create a pending list of those appointments for vetting by
an appropriately authorised member of staff. It must be
possible to amend this list and, therefore, the actual
appointment and to produce an appropriate letter to the
patient or their carer. During the vetting process the x-ray
history of the patient must be available.
Appointment letters and pre-examination preparation
details must be generated by the system. This includes
the ability to print letters at the time of making an
appointment which inform the patient about time, date and
type of examination and of any preparation the patient may
need to do for this examination e.g. “Nil by Mouth from
midnight”.
Must be able to incorporate more than one request for the
same day on the same letter giving the relevant
preparation details i.e. Ultrasound, DMSA and MCU
Any patient letter that is generated by the system should
be recorded against the examination to which it relates.
This should be clearly visible to the appointments clerk.
The system must have the ability to set up certain rooms
for certain specific examinations and to determine the
length of the examination.
Examinations of variable length may need to be booked
into the same room during any one session.
The system must record the date and time that the
appointment was booked and the person booking it.
The system must have the capability of checking for the
availability of staffing resources, equipment resources and
stocks and supplies in addition to room time availability
during the process of booking and alert user if there is a
conflict.
The system must have the ability to automatically select
Page 45 of 78
Radiology
1.7.14
1.7.15
1.7.16
1.7.17
1.7.18
1.7.19
1.7.20
1.7.21
1.7.22
1.7.23
RIS Business Case
5.11.08
the first available date, time and appropriate room. The
system must have the ability not to accept the first
time/date slot offered if that is not convenient for the
patient.
The system must have the ability to recognise public and
statutory holidays and prevent bookings being made
automatically on those days, but allow bookings to be
made manually on them.
The system must have the ability to schedule the
examination for any modality, date and x-ray room.
The system must have the ability to cancel, rearrange,
and delete appointments and to record a reason for
cancellation, e.g. a hospital or patient cancellation. The
system must have the ability to record where a patient
Did Not Attend (DNA) an appointment and it must be
possible to manually convert an entry of DNA to an entry
of cancellation in retrospect if necessary.
There must be a complete audit trail about the patients
appointment history including all instances of appointment
rearrangement
The department must be able to enter notes with free text
in an electronic note pad area which is related to the
appointment.
The system must be able to send all appointment
information back to the interface engine to allow viewing,
tracking management and analysis of diagnostic
appointments/attendances as part of the entire 18 Week
pathway.
The system should be able to high light potential
appointment requests which could lead to a patient
breaching their diagnostic wait of 4 weeks
The system should be able to display a full appointments
history detailing all examinations offered to the patient
including dates and times and why they were declined or
pushed back to a later date
The system must have the ability to recalculate the waiting
time from date test requested to date examination
occurred (and/or date authorised report available) and
adjust this calculation based upon an algorithm utilising
information on appointment history, offer history and
suspension history.
The system should be able to alert a suitably privileged
user or system manager as to when an examination
request / appointment is near to breach it’s 4 weeks
diagnostic target, or what ever target is set by the Trust
Page 46 of 78
Radiology
RIS Business Case
5.11.08
1.8 Attendance Module
1.8.1
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
1.8.2
1.8.3
1.8.4
1.8.5
1.8.6
The RIS must include an Attendance Module in order to:
Collect data required by IRMER Regulations including
fields:
1 st Operator, 2nd Operator (optional), Practitioner
Record positive patient ID by operator
Confirm LMP asked of patient where appropriate
Confirm Allergies checked where appropriate
flag status of requests, e.g. patient arrived,
examination in progress, examination completed;
assess waiting times within the Department;
assess radiographer workload;
assess room occupancy;
facilitate stock control;
document x-ray exposures and screening times;
perform reject analysis.
Collect data to create Environment Agency Radioisotope
waste reports
When the patient is booked in for their examination this
must trigger a modality worklist entry
There must be a discrete entry for each examination even
when the patient is having multiple examinations within the
same attendance.
The Attendance Module must be capable of displaying a
real time tracking worklist of all current patients or a single
patient from the time of arrival and all stages until the time
of leaving the Radiology department and each intervention
between the two.
The Attendance Module must be flexible enough to allow
the maximum amount of data to be entered with the
minimum number of key strokes, incorporating the use of
intelligent barcode readers and default data, e.g. for
number of exposures, time of day, an on call period etc.
Where possible fields should be populated with “known”
data.
The Attendance Module should be capable of receiving
and storing relevant data from the Modalities & PACS
(number of images taken, number of images rejected,
reason for rejection, kVp, mAs, screening time, radiation
dose, etc.).
The Attendance Module must be capable of receiving and
storing information relating to Contrast and radioisotope
utilisation (e.g. contrast type, amount, batch number,
whom injected by, reactions, waste etc.)
For Contrast administration:
a)
Contrast administered,
b)
Batch number
c)
Contrast concentration,
Page 47 of 78
Radiology
d)
e)
a)
b)
c)
d)
e)
f)
1.8.7
1.8.8
1.8.9
1.8.10
1.8.11
1.8.12
1.8.13
RIS Business Case
5.11.08
Contrast volume,
Person administering.
For Radioisotope use there must be information capturing:
radioactivity administered,
radiopharmaceutical,
time of administered,
batch number vial ID,
multiple injections,
Person administering.
We must be able to make various fields mandatory for
certain examinations
Post examination data in Nuclear medicine such as
isotope used, quantity, who injected and batch number.
The RIS should accept radiation dose information
automatically from those modalities, which support MPPS
and allow manual entry of radiation dose information from
those, which do not support MPPS.
Ability to automatically flag out of hours cases
Free text field at attendance level to be accessible by
reporting radiologist
Radiographer completing the examination must be able to
assign the completed examination to a specific radiologist
or a General pool for reporting.
The nuclear Medicine department should be able to keep a
record of the stock and waste they use and create and be
able to produce reports of this data.
The system should alert Radiographers when an
examination has not been completed so that the
appropriate action can be taken
1.9 Media/ Film Tracking Module
1.9.1
Although the TRUSThas been film-less for almost two
years, the Trust will be dealing with removable media for
some time yet.
There is the requirement to track information about PACS
CDs and DVDs
1.9.2
1.9.3
It is essential, therefore, that the new RIS has the
capability of recording information about films and CD and
their locations.
The system must have the ability to enter and display the
location of any patient's X-ray packet or a patient’s CD
with the date of movement
The system must have the ability to enter and display the
identity and address of the recipient of any patient's X-ray
packet or CD with the date of loan and the reason for the
loan (e.g. for court cases) or export.
Page 48 of 78
Radiology
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
a)
b)
c)
d)
e)
f)
g)
h)
RIS Business Case
5.11.08
The CD Tracking Module must be capable of tracking
multiple master packets and also single examinations.
The system must have the ability to print reports of all
signed out X-ray film packets by recipient and by location.
The system must have the ability to generate overdue loan
lists.
The system must have the ability to generate an audit trail
of loans
All loan functions should be performed with a minimum of
keystrokes using barcode readers wherever possible.
Where a CD or DVD is generated and then tracked out to
a location the following information is to be captured:
Date of request
Requesting source
Requesting Location
Reason for Request
Date CD/DVD created
CD/DVD Operator/Dispatcher
Courier where appropriate
Encryption password
1.10 Examination Reporting Module
1.10.1
1.10.2
1.10.3
1.10.4
1.10.5
1.10.6
1.10.7
The RIS system must be fully integrated with PACS
software at the Reporting Workstation.
The interface between the two components MUST be bidirectional whereby selecting an examination on RIS will
automatically open and present the relevant images on
PACS and vice versa, opening a study on PACS will open
the relevant RIS information and present the reporting
screen to the radiologist.
Both databases must reflect the same status about an
examination. A study reported either in the RIS or the
PACS software should be mirrored in the other database
in real-time manner.
Radiologists must be able to report from worklists
It must be possible to call 3rd party viewing applications
from the PACS and reporting workstations.
Confirmation on whether the application will support
Clinical Context Object Workgroup, (CCOW) as defined by
IHE, must be provided.
CCOW uses "context management" so that each individual
application refers to the same patient, encounter or user
The system should allow the grouping of types of
examination to facilitate reporting by modality for reporting
purposes, but also should group Examinations into
Attendances.
The Brief Clinical Note / Reason for the Examination and
Known Allergies or Medical Alerts should be collated and
automatically presented to the reporting radiologist and
Page 49 of 78
Radiology
RIS Business Case
5.11.08
a)
b)
c)
d)
e)
f)
g)
placed at the head of each report.
A separate Report must be generated and sent to PACS
for each Examination, including the instances where a
patient has multiple examinations during one attendance.
The word processor must provide, at a minimum, the
ability to insert, delete, change, save and reinsert words,
lines and segments of text, and to search text for words
and phrases.
The Reporting Module should incorporate a recognised
word processor, e.g. Microsoft Word, with comprehensive
word processing facilities (e.g. spell checker).
If a recognised word processor is not used, Supplier must
give details of the functionality of the text editor used for
compiling reports.
The Reporting Module must be capable of documenting
the following:
Reporter / radiologist ID
status of reporter (e.g. radiologist or radiographer);
Additional/trainee radiologist IDs; IDs of
radiologists/radiographers who carried out the
investigation;
transcriptionist ID;
ID(s) of person(s) authorising report;
a)
b)
c)
d)
e)
The following should be automatic
date/time dictated;
date/time transcribed;
date/time verified and approved;
date/time additional/amended report issued;
Clinician alert flag/notification.
1.10.8
1.10.9
1.10.10
1.10.11
1.10.12
1.10.13
1.10.14
1.10.15
a)
b)
c)
d)
1.10.16
1.10.17
1.10.18
If batch reporting is being carried out then it should be
necessary to enter items a) – e) only once
The system must enable a user with appropriate authority
to change the values of the above fields (e.g. the name of
the reporting radiologist) where necessary
The system must have the ability to print multiple copies of
reports at several locations and to maintain a “send to” file
to facilitate circulation
The system must have the ability to track the progress of
reporting by recording the status:
report dictated
report transcribed
report authorised
report amended
A voice recognition system with the appropriate medical
dictionary for reporting is required. The system must
display the dictated text in real time to the Reporting
Radiologist.
DICOM structured reporting should be available.
All reports should go to a general typing pool for the
transcriptionists to select from
Page 50 of 78
Radiology
RIS Business Case
5.11.08
1.10.19 The system must have the ability to display listings of
reports by radiologist, which have yet to be approved, and
the facility for the radiologist to edit and approve the report
on-line at this stage.
The system must have the ability for transcriptionist’s to
edit and approve reports under the radiologist's direction.
1.10.20 The Reporting Module must have a facility for coding
individual examinations with a recognised clinical coding
system and the ability to support in-house coding
structures.
1.10.21 It must be possible to code individual examinations within
an attendance.
1.10.22 The ability to flag interesting cases as teaching files for
both Education and Research is required.
1.10.23
1.10.24
1.10.25
1.10.26
1.10.27
1.10.28
1.10.29
1.10.30
1.10.31
1.10.32
Please describe the software features provided.
The Reporting Module must have a facility for building up a
database of standard phrases and standard reports.
These must be easy to select and apply (e.g. by
mnemonics) when required.
Transcribed reports should automatically be queued for on
screen editing, verification and approval on the relevant
reporter's queue. Multiple approval queues may be
required (e.g. a report written by a Registrar may need
verification both by the Registrar and by a Consultant
Radiologist).
The facility to edit a report and to record the identification
of the transcriptionist and radiologist or author must be
provided.
The facility to record a second opinion to a report including
the details of both the 1st and 2nd originators.
Reported examinations should be listed by default in
reverse date order.
It must be possible to create worklists by radiologist and
also be able to divide this up into urgent and non urgent
cases
The system must have the ability automatically to re-direct
reports, which have not been approved within a specified
period to the queue of a designated member of staff for his
or her attention.
The system must have an auto verify function for all
studies where there is a local agreement in place for no
radiology report to be issued e.g. imported foreign films.
This activity should be triggered when the radiographer
has completed and confirmed the recording of the post
examination data in RIS.
Reports should be available for viewing as soon as they
are transcribed for radiology only, but a clear indication
must be given of the status of the report (e.g. preliminary,
unauthorised).
Verified reports must not be alterable; any changes must
Page 51 of 78
Radiology
1.10.33
1.10.34
1.10.35
1.10.36
1.10.37
RIS Business Case
5.11.08
be noted through addenda, which in turn require checking
and verifying.
Any report which includes addenda must be clearly
marked and the visible on the first page of the report. Both
on screen and in printed reports any addenda must appear
before the original report; if there is more than one
addendum they must be displayed in reverse date order.
This applies to all systems, which are used to display or
print reports.
There must be a facility for reports to be printed off in
batch or individually. For batch printing the sorting order
must be user defined (e.g. by Radiologist, by
transcriptionist, in chronological order, by modality, by
referring consultant etc.).
Reports must be communicated to PACS with the status of
the report. The most recent version only of the report,
including any addenda, must be available to the users of
PACS.
Reports must be communicated to any potential EPR
and/or Clinical Requesting System/OCS with the status of
the report. The most recent version only of the report,
including any addenda, must be available to the users of
proposed EPR and the Clinical Requesting System/OCS.
All unreported examinations must be listed by department,
examination type and date of examination after a period
determined by the type of modality.
These lists should be configurable by the user. Supplier is
to list available options.
1.10.38 It must be possible to employ user-defined report
templates for discrete specialities including Nuclear
Medicine and Ultrasound etc, including the use of pictorial
report templates.
The data collected in these report templates must be
available for management reporting.
1.10.39 It must be possible to incorporate a selection of jpeg
images and graphs into the report.
1.10.40 It should be possible to attach scanned documents
generated as part of the imaging examination and
associate it with the report/ examination.
E.g. Observation Chart for Nuclear Medicine
Graphs for MRI
1.10.41 The system must be able to flag a report as sensitive and
subsequently restrict access to it as defined by the user
1.10.42 The system must allow the Reporting Radiologist ease of
access to previous Radiology Reports on RIS and
associated ease of display historical images on PACS
1.10.43 The system should automatically alert a suitably privileged
user or system administrator as to when a report is waiting
to be completed or authorised for more than a set time as
Page 52 of 78
Radiology
RIS Business Case
5.11.08
required by the Trust
1.11 Teaching and Research
1.11.1
1.11.2
1.11.3
1.11.4
1.11.5
The system must have the ability to identify a patient as a
research patient either through the Clinical Requesting
System/OCS, or directly into the RIS or PACS.
The system must have the ability to assign a diagnostic
code for each examination using an on-line code finder
and the coding systems as appropriate..
The system must have the ability to search the records of
examinations carried out using the above codes.
The system must have the ability to search the text of
reports using plain text keyword fields.
The system should have the ability to support Multi
Disciplinary Team meetings, (MDT).
Both RIS client and web users should be able to add
patients to these lists
.
1.12 Setting up X-Ray Rooms
1.12.1
1.12.2.
1.12.3
1.12.4
1.12.5
1.12.6
1.12.7
1.12.8
The system must have the ability to define an X-ray Room
by code, name, type, place, rooms used, speciality,
contractual arrangement, and status.
The system must have the ability to allocate rooms to
defined radiologists and/or radiographers, taking account
of their availability.
The system must have the ability to attribute to each room
the days of the week on which it will be used, and also to
set up ad-hoc use.
The system must have the ability to allocate to each room
and session a structure of appointment slots, times,
durations, numbers of patients per slot, priorities of
appointments, special appointments, maximum numbers
and whether overbooking is permitted with appropriately
controlled access.
The system must have the ability to allocate to each room
a different structure of appointment slots.
The system must have the ability to redefine the sequence
of slots, and to transfer patients holding appointments in
the old structure to the new one.
The system must have the ability to close a room for all or
part of a day and record the reason for the closure and the
person responsible (e.g. for visits by maintenance
engineers).
The system must have the ability to enable suitably
authorised users to edit the details of any room and to
Page 53 of 78
Radiology
RIS Business Case
5.11.08
restrict the rooms.
1.13 Equipment Module
1.13.1
1.13.2
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
Equipment data must form part of the integrated RIS
database to enable reporting across the whole database.
The system must have a facility for capturing and reporting
on the following Capital Assets details for equipment
associated with the Radiology department:
Make / model / serial number/ service UID ,
Supplier
and contract number;
Generator / tube rating;
Use / room;
Date installed;
Life expectancy;
Replacement cost;
Service dates / service contract details, with a link
to booking / appointments;
Down time;
Log of problems with flag facility for recurring
problems;
Quality assurance test reports.
Trust asset number
1.14 RIS Data Take On / Conversion/System Sizing
1.14.1
1.14.2
1.14.3
1.14.4
1.14.5
1.14.6
1.14.7
The RIS will be required to take on 19 years of historical
data from SCH. The RIS must be sized to allow at least a
further 20 years of data.
The Supplier must provide full details of their general
approach to data conversion, including their method of
dealing with any partial, incomplete or duplicate records.
The Trust currently uses the Radiology module of the
Current vendor TcRAD. The Supplier must be prepared to
take on the historical data from this system into the new
RIS.
The Supplier must state whether they have previous
experience of converting data from the system mentioned
above.
The Supplier must be able to merge together data for the
same patient held in the current separate systems. NB:
This may be possible via the normal patient merge
function.
The Supplier must provide full details of their method for
mapping codes (e.g. exam code, ward, consultant) held in
the current radiology information systems into the new
System.
The Supplier must confirm that they are willing to take
responsibility for the data conversion exercise, including
liaison with the current Supplier and accurate transfer of
data between systems.
Page 54 of 78
Radiology
RIS Business Case
5.11.08
Page 55 of 78
Radiology
RIS Business Case
5.11.08
1.15 Query Tool
1.15.1
1.15.2
1.15.3
Supplier must describe their approach to providing query
facilities on a system which holds a large amount of data
and which requires consistent, high speed user response.
This must specify whether queries are run against the
online database or an extracted copy of the data. Supplier
must describe how online response times are guaranteed
while a large and complex query is run.
The RIS must provide a flexible and intuitive query facility
for key users. Supplier must provide full details of the
query tool available within their application including all the
facilities available.
Supplier must specify whether their query facility involves
the use of any third party product and if so the level of
training required for the users.
Supplier must specify if this training is included in the
purchase price.
1.15.4 The query tool must provide facilities for the specification
of fields to be displayed, selection conditions (including the
use of NOT, AND and OR), sort parameters (ascending
and descending) and fields to be used for grouping. In
addition it must be possible to use functions such as count,
maximum, minimum, average, sum etc. Supplier must
provide full details of all the features of their query tool.
1.15.5 There must be a facility to save a query.
1.15.6 It must be possible to save the query result in a number of
formats e.g. text, fixed columns etc.
1.15.7 It must be possible to rerun a saved query by calling it up
by name or from a menu.
1.15.8 It must be possible to enter run time parameters to a
saved query e.g. time period to run the query for.
1.15.9 It must be possible to print the result of a query and to
export it into a Microsoft Office application.
1.15.10 It must be possible to schedule queries to run at certain
times. Supplier should state if this is a feature of the query
tool or if there is a general scheduling tool used for this
purpose.
1.15.11 The query tool must have the ability to use any database
field element held by the system.
1.15.12 The Trust would like the ability to create additional tables
within the database, which could then be used as part of a
query. This would be useful for example where there is a
long list of particular patients against which a query is
required. Supplier should describe how they would satisfy
this requirement and whether the creation of additional
tables is possible.
Page 56 of 78
Radiology
RIS Business Case
5.11.08
1.16 Reporting Tool
1.16.1
1.16.2
1.16.3
1.16.4
1.16.5
1.16.6
1.16.7
1.16.8
1.16.9
1.16.10
1.16.11
1.16.12
1.16.13
1.16.14
a)
b)
c)
d)
e)
f)
g)
There must be a flexible and intuitive report writing facility
available to key users. Supplier must provide full details of
the report writer available in their system.
The report writer must have the ability to produce
formatted reports using any database field element held by
the system.
The report writer must provide facilities for the specification
of fields to be printed, selection conditions (including the
use of AND and OR), sort parameters (ascending and
descending) and fields to be used for grouping, subtotalling and totalling.
The report writer must allow the use of system variables
such as date, time and page number. The Supplier must
specify which system variables are available to the user.
Any reports defined on site must be able to be run from
menus or macros with the minimum amount of additional
data entry.
Users must be able to provide run time parameters to
previously defined reports e.g. reporting period.
The end user must not be able to amend a report in any
way, other than supplying parameters required to execute
the report.
The report writer should contain a facility for the automatic
scheduling of reports so that e.g. daily, weekly and
monthly reports are produced without user intervention
and as a background task so that users can continue with
other activities.
The report writer must allow the specification and use of
calculated fields within reports. Both data fields and
system variables must be allowed within a calculated field.
The report writer must provide facilities for the formatting
of reports in terms of page headings and footings, page
length, control break headers and footers, sub-totals and
totals.
The report writer must allow the option of displaying the
report to a screen rather than printing it.
Supplier will be expected to maintain and supply to the
Trust an up-to-date data dictionary to facilitate use of the
reporting tool.
It must be possible to specify the number of copies of a
report to be printed.
The system must be able to produce the following specific
reports:
Waiting list by PCT
Patients unknown to PAS
Duplicate patients
Incomplete examinations
Unverified reports
Invoice activity report (who was invoiced for what,
when they were invoiced, has the invoice been
Page 57 of 78
Radiology
RIS Business Case
5.11.08
h)
i)
j)
k)
l)
settled)
Inventory (stock status, utilisation history, supply
reorder notification)
Cumulative individual patient dose
Department of Environment radio-isotope disposal
report
Radiologist workload activity
1.16.15 The Supplier must ensure that the system is kept up to
date with all mandatory DOH reports at no additional cost
to the Trust.
2. PACS Requirements
2.1 Functional Overview
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
In order to gain access to a PC the user must be required
to enter a username, or account name, and password
combination, which must be unique to each user. The
password must not be displayed on the workstation
screen.
Access to PACS and RIS at each workplace must be
facilitated through Integrated Windows Authentication and
smartcard access.
The Trust has adopted Smart cards for CfH applications
that connect to the Spine please suggest how these could
be utilized in the RIS/PACS workstation environs. We
require one single log in for radiologist to be able to start
reporting with a fully integrated RIS/PACS system.
On workstations used for reporting images (diagnostic
workstations) it must be possible to display lists of
unreported examinations giving details including the
patient's name, age, sex, hospital number, date and time
of examination and type of examination.
The fields of the reporting work lists must be fully
configurable and must include department. Users must be
able to access all work lists at any time.
The RIS/PACS interface will operate in real time.
Standard interface protocols such as HL7, will be used for
the PACS interface. The particular protocols and revision
levels will be agreed during negotiations with the Supplier.
When patient records are merged on the RIS, the option of
sending a merge message from the RIS through the
interface to the PACS, and the PACS to automatically
merge the patient images.
While it is expected that all patient identification data will
enter the PACS via the RIS, the system will allow sufficient
manual entry of data to identify patients should the other
system or interface become unavailable. Software
facilities will exist to enable such manually entered patient
details to be reconciled with data on the RIS when the RIS
or interface is restored.
Page 58 of 78
Radiology
RIS Business Case
5.11.08
2.2 RIS System management facilities
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
2.2.8
The system must be supplied with easy to use utilities to
control and manage it; this includes tasks such as starting
and stopping the system, logging off users and terminating
tasks or programs, which are out of control.
User accounts must be created and managed centrally.
There must be a single account for each user.
Each discrete user account must be accessible from all RIS
workplaces.
The system must be supplied with easy to use facilities to
enable data and programs held on the system to be backed
up onto computer readable media for storage off line. Such
backups must involve a minimum, if any, time when the
system is unavailable for normal use, and it must be
possible to schedule them to run out of normal working
hours when the system will be unattended.
The system must be supplied with easy to use facilities to
enable data and programs to be recovered from off line
storage.
Facilities must be provided to check the integrity of the file
systems and databases which can be run during normal
system operation and report on these. Facilities must be
provided to correct any inconsistencies found.
Easy to use and intuitive facilities must be provided to
recover data from backup storage in the event of the loss or
corruption of on-line data.
Facilities must be provided for monitoring the availability of
disc space on the system to ensure that adequate space is
always available for system operation. Should disc space
become low, easy to use software facilities must be
provided to enable files to be moved between discs, or to
allow discs to be re-organised to release space.
In the event of a system failure in one part of the system,
Supplier must describe how the remainder of the system
behaves.
3. IT Requirements – RIS
3.1 Database
3.1.1
3.1.2
The Trust’s preferred standard for databases are SQL
2000/2005. Supplier must state the database used by the
RIS and whether it is relational and has an SQL interface. If
no SQL interface is available Supplier must provide full
details of the query language or tool provided.
The proposed DBMS must allow “hot” backups and point in
time recovery.
Page 59 of 78
Radiology
3.1.3
RIS Business Case
5.11.08
All transactions which result in changes to the data on the
system must be logged, and facilities must be available for
displaying, storing and purging the logs.
3.2 Application Software
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
The RIS must be supplied with a maintained test system,
which will be used for testing new releases of the software
prior to acceptance and issue on the live system with the
Trusts PACS system.
The RIS will also contain a training environment, which can
be used to mimic the live system for training purposes.
Supplier must provide details of how new releases of
software are migrated from the test system to the live or
training systems.
The Supplier must provide a 2 to 3 year development plan
for the System.
The Supplier must provide a retrospective schedule of
updates and new releases implemented over the past 2
years.
3.3 RIS Back Up
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
An efficient means of generating backup copies of all data
and programs with minimal operator intervention must be
provided.
The Supplier should provide a full explanation of any
backup procedures including media cycles, backup scripts,
backup cycles (day/time of backup and type of backup, e.g.
incremental), the data backed up, and the data excluded in
the backup, backup verification, error correction /reporting.
It should be possible to carry out incremental backups.
The Supplier should confirm whether the backup
procedures proposed are integral to the application, and
what restrictions the Trust would encounter if local tailoring
of the backup processes is required.
The Supplier must specify the time required to do a
complete backup of the whole system including the
operating environment (using the Supplier’s recommended
procedure).
The facility to carry out backups with the system on-line, in
full functional and operational use, must be provided. The
Supplier must state how this is done and what effect this
has on the system, data integrity and performance.
The proposed backup medium must be capable of backing
up the entire system, including any verification processes,
within the hours the system is least used.
The Supplier must explain how an overnight, unattended
backup of the system will be achieved, without on-site
Page 60 of 78
Radiology
3.3.9
3.3.10
3.3.11
3.3.12
3.3.13
RIS Business Case
5.11.08
overnight or weekend operator intervention. The Supplier
must provide details of the operational tasks associated
with the recommended backup processes.
If the backup requires special equipment this must be
indicated and included within the proposed system
configuration.
The Supplier must provide full information on the
recommended processes for checking and ensuring the
successful completion of an unattended backup. This
process must be automated, reporting exceptions to the
appropriate Trust IT Support staff.
The Supplier should provide details of any automated
actions the proposed backup processes will employ if a
fault or error in performing the backup occurs.
The backup and recovery facilities must be easy to use,
quick, effective and foolproof.
Any system maintenance tasks including back up which
require the system to be taken down (off-line) must be
stated, including duration of downtime.
3.4 RIS Recovery
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
The Supplier must provide full details on the recovery
procedures, appropriate to the recommended procedures
for backup.
An efficient means of re-constituting the on-line data and
programs following system failure with data corruption must
be provided.
The Supplier must state how recovery up to the point of the
last complete transaction is achieved, how data integrity
and security are maintained, and to what extent this is
independent of user intervention.
The Supplier must state the time required to reload and
recover fully from the backed up data once the hardware
and operating system are repaired or replaced.
The supplier must state the time required to repair
hardware and the operating system.
The Supplier must provide estimated timings for the
restoration from the backup of one year’s data following
system failure.
The Suppler must state as to where their system will
function in a virtual environment which will aid the Trust in a
disaster recovery situation
3.5 Housekeeping
3.5.1
The Supplier must provide full details of all proposed and
recommended housekeeping tasks required to maintain
efficient operation of service. The Supplier must provide
details on all housekeeping tasks identifying the following:
Page 61 of 78
Radiology
RIS Business Case
a)
b)
c)
d)
3.5.2
3.5.3
3.5.4
3.5.5
3.5.6
3.5.7
3.5.8
3.5.9
3.5.10
5.11.08
impact on the service error handling and reporting
task duration and recommended frequency
process of task initiation
task dependencies
This should apply to the operating system, database and
application.
The Supplier must state where these housekeeping tasks
are not provided as part of the package.
The Supplier should confirm whether the housekeeping
procedures proposed are integral to the application, and
what restrictions the Trust would encounter if local tailoring
of these processes is required.
If any housekeeping activities require special equipment
this must be indicated and included within the proposed
system configuration.
The Supplier must provide full information on the
recommended process for checking and ensuring the
successful completion of all housekeeping tasks. This
process should be automated, reporting exceptions to the
appropriate Trust IT Support staff.
The Supplier should provide details of any automated
actions the proposed housekeeping processes will employ
if a fault or error in performing them occurs.
The housekeeping utilities must be easy to use, efficient,
robust, effective and foolproof.
All housekeeping tasks must be fully documented.
Supplier must provide training for all housekeeping
routines.
The system should provide a job scheduler for performing
routine tasks at predefined times and days.
3.6 RIS Printing
3.6.1
3.6.2
3.6.3
3.6.4
3.6.5
The system must provide reprint facilities, controlled by the
user, for full or part reports, in the event of reports being
spoiled during output.
The system must provide the ability for users to redirect or
select alternative printers in the event of printer failure. The
Supplier must provide details on how this is achieved.
The application should not require the use of pre-printed,
continuous or multi-part stationery, or paper sizes other
than A5. Supplier must indicate any exceptions to this rule.
The Supplier must specify all special stationery
requirements other than plain A5 paper (e.g. labels) in
sufficient detail for stationery to be ordered.
The application must be able to use industry standard A5
laser or inkjet printers for the majority of printing
requirements. Supplier must clearly specify any nonstandard printers required e.g. label printers, colour
printers.
Page 62 of 78
Radiology
RIS Business Case
5.11.08
3.6.7
Supplier must be able to propose a range of printers, which
are supported by the software application to meet all output
requirements.
3.6.8
The application must be able to print locally and remotely.
3.6.9
Where printouts exceed one page in length, it must be
possible to print a specified range of pages.
3.6.10 The application should feature a ‘print preview’ facility,
allowing the user to see clearly the number of pages that
will be printed and the general appearance of each page.
3.6.11 The application must allow the user to quickly and easily
cancel a printing or spooling operation after it has begun.
3.6.12 It must be possible to print any given screen displayed as it
stands e.g. a screen dump (WYSIWYG).
3.6.13 The Supplier must provide options for printers some of
which must be capable of printing in colour and some of
which must be quiet.
3.6.14 If a colour printer is not being used, the system must
distinguish abnormal results by some alternative formatting,
e.g. bold type.
3.6.15 The RIS must be able to produce various printed
documents including:
a)
Diagnostic reports (text)
b)
Letters
c)
Modality worklists
Patient identification labels
3.7 Data Export
3.7.1
3.7.2
3.7.3
The system must have facilities for exporting data in a
format, which allows it to be loaded into commercial
software packages. The packages supported must include
Microsoft Word, Excel, Powerpoint and Access versions
2000 and XP and any future releases.
Supplier should describe the export facility and state
whether it is possible to define exports using the ad hoc
report generator.
Supplier must indicate whether there are any limitations on
the data items that can be exported.
The Trust may also wish to export data for use by other
Trust systems e.g. EPR. Suppliers should specify whether
this is possible and whether Trust staff can set up the
exports.
Page 63 of 78
Radiology
RIS Business Case
5.11.08
3.8 Error Handling and Robustness RIS
3.8.1
3.8.2
3.8.3
3.8.4
3.8.5
3.8.6
Error messages must be self-explanatory. The Supplier
must be prepared to edit unclear error messages on
request.
Error conditions detected by the application must result in a
meaningful diagnostic message, which alerts the user that
there is a problem, and provides sufficient information to
allow the nature of the error to be identified.
The application must be designed to minimise any loss of
data or functionality in the event of an error being detected.
The application must notify the user if an error has resulted
in loss of any data input during that transaction.
The application must notify the system manager if an error
has resulted in loss of any data committed to the database.
The application must create a log of errors and debug
messages depending on the Trusts requirements.
3.9 System Management & System Management Documentation
3.9.1
3.9.2
3.9.3
3.9.4
3.9.5
3.9.6
3.9.7
3.9.8
3.9.10
The system must be supplied with easy to use utilities to
control and manage it. This includes tasks such as starting
and stopping the system, logging off users and terminating
tasks and programs, which are out of control. Supplier must
provide full details of all system management facilities
within their system.
A comprehensive package of system and applications
management documentation must be delivered with the
system.
The Supplier must confirm that their documentation covers
the following for RIS:
System Overview - description of the package.
System Configuration - including all devices, system
software and package configuration parameters.
Start-up and Shutdown Procedures - including
system/application start-up scripts and processes including
dependencies.
Network Configuration.
File/Database Description - This should include a
diagrammatic layout of the installed system, with
descriptions of different directories/files purposes etc. The
database schema must be provided.
Housekeeping - All proposed, provided or recommended
housekeeping tasks must be documented, to include
dependencies, prerequisites, error handling, instructions,
operational initiation, frequencies, failure implications,
updates and output. Explanation and instructions on all
housekeeping management functions that should be
performed by either the system or application managers.
Page 64 of 78
Radiology
RIS Business Case
3.9.11
3.9.12
Backup/Recovery - As described in housekeeping above.
Print Queues - All print queues and printer management
issues.
Upgrades - Step by step upgrade instructions, including
prerequisites and recovery procedures.
Performance Management - Overview of performance
tuning and monitoring for maintaining optimum service.
Trouble-shooting Guide - Common faults, solutions and
fault analysis guide.
Security - Overview on how security functions within the
package. Explanation and instructions on all security
management functions that should be performed by either
the system or application managers.
Contact Information - Support contact details.
The Trust would like the ability to message all end users
from a central point.
The Trust would like automatic client up grades that don’t
require intervention from staff.
3.9.13
3.9.14
3.9.15
3.9.16
3.9.17
3.9.18
3.9.19
3.10
5.11.08
Reference Sites
3.10.1
3.10.2
3.10.3
3.10.4
3.10.5
The Trust wishes to understand in some detail various
aspects of suppliers’ experience
Suppliers must provide the name of hospitals or healthcare
organisations currently utilising the proposed system.
Suppliers must show the length of time each organisation
has been running the system.
Suppliers must give details of at least 2 reference sites,
which may contact/visit to see a current installation of the
proposed system and configuration.
Ideally the proposed site should demonstrate a
configuration including interfaces similar to that being
proposed in this tender.
4. Interfaces
4.1 Interfaces – General
4.1.1
4.1.2
4.1.3
The Supplier must state their general strategy with regard
to interfacing to other Trust systems such as PAS for
demographic data. This should include details of any “off
the shelf “ interfaces already in existence, any standards
imposed (e.g. HL7) and details of any APIs (Application
Programming Interfaces) available. Supplier should also
state their position with regard to the development of new
interfaces.
Supplier must list any third party products that will be
employed to achieve the interfaces
The RIS must be HL7 and DICOM compliant where
appropriate.
Page 65 of 78
Radiology
4.1.4
5.11.08
The Trust wishes to comply with the CfH and to send
patient and image data to the Spine. Supplier must provide
a general statement indicating their position regarding the
CfH and Spine compliance.
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
4.1.5
RIS Business Case
The system must be able to interrogate and/or receive data
from the Trust’s PAS system. The data must include:
Unique Patient Identifier
Patient Forenames
Patient Surname
Title
Date of Birth
Sex
NHS Number and status
Patient address including postcode, district of
residence, phone numbers (home, work, mobile),
email
Ethnic Group
Religion
Occupation
Category i.e. NHS, PP
Next of Kin details – name, relationship, address,
postcode, phone number
GP details – GP code, name, address, postcode,
phone number
Admitting Consultant
Admitting Specialty
As the Trust must alter it’s PAS system in the future the
Supplier must state how much this would cost and whether
there are any systems they are unable to work with
5. System Characteristics
5.1 System Performance - RIS
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.1.7
5.1.8
Supplier must provide details of the expected and
guaranteed response times of their system proposals with
reference to their experience in similar environments on
databases containing at least 3 years data. Figures to be
provided must include response times for a variety of
scenarios similar to those below:
Simple data entry or update
Retrieve a patient record - demographics and attendances
Switch between different screens for the same patient
Display a report
Perform a complex transaction updating multiple records
e.g. patient merge
Perform a simple query on patients attendances for the day
Perform a complex query using 3 years of historical data
Page 66 of 78
Radiology
5.1.9
5.1.10
5.1.11
5.1.12
5.1.13
5.1.14
5.1.15
RIS Business Case
5.11.08
Run a complex report
Perform a complex data extract
Supplier is requested to state the maximum time taken by
the system to store reports that have been sent from
workstations when working under full load.
The time taken to retrieve the first 20 results of any query of
the system database and display them on screen as a
worklist, folder or selection list ready for subsequent image
retrieval and viewing must not exceed two seconds.
The time taken to retrieve the image examination list of any
patient with a known key identifier, such as hospital
number, and display the first 10 entries on screen must not
exceed two second.
The time taken to retrieve a modality worklist from the
system and fully display the entries on the modality
workstation must not exceed 1.5 seconds under full load
conditions. This shall include the time taken by the
interface to convert messages to DICOM format.
The Supplier must give details, including calculations where
appropriate, to support claims that the proposed system will
meet these performance targets. The retrieval and display
times for different types of reports under different levels of
system loading must be tabulated.
6. System Availability
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
The system is expected to be available continuously 24
hours per day, seven days per week.
The Supplier must provide evidence in their proposals that
they are able to meet the availability specified above and
describe the infrastructure needed to achieve target
availability.
The availability in a given operational period is defined as:
(Length of operational time-Length of time system is
unavailable) over length of operational time
expressed as a percentage.
During the operational time 8:00 to 18:00 seven days per
week, including public holidays (i.e. 70 hours), the minimum
operational system must have an availability of 99% when
averaged over a calendar month period. The maximum
continuous period when the minimum operational system is
unavailable will not exceed one hour during the operational
time. The number of incidents which cause the minimum
operational system to be unavailable during the operational
time over a calendar month period will not exceed three. No
one item of equipment in the whole system during the
operational time will have an availability of less than 95%
when averaged over a calendar month period.
On the basis of continuous operation 24 hours per day,
seven days per week (i.e. an operational time of 168
hours), and the minimum operational system must have an
Page 67 of 78
Radiology
6.1.6
6.1.7
6.1.8
6.1.9
6.1.10
6.1.11
6.1.12
6.1.13
6.1.14
6.1.15
RIS Business Case
5.11.08
availability of at least 99% when averaged over a calendar
month period, including public holidays. During this
operational time, the maximum continuous period when the
minimum operational system is unavailable will not exceed
eight hours, and the number of incidents which cause the
minimum operational system to be unavailable will not
exceed three. No one item of equipment in the whole
system during this operational time will have an availability
of less than 90% when averaged over a calendar month
period.
Periods of unavailability will be measured from the time the
incident is detected or reported to the Supplier’s help desk
until the time the system, or particular item of equipment, is
restored to full operation.
During the hours 8:00 to 18:00 seven days per week,
including public holidays, the time to repair a priority 1 fault,
must NOT exceed 4 hours from the time the maintenance
organisation has been alerted to the failure.
Supplier must specify the remedies that will be applied
should the target availability not be achieved.
Supplier should outline manual contingency arrangements
such that the Trust is still able to provide care in the event
of system failure.
It is expected that the Supplier will use remote support via
the Trust’s firewall to enable upgrades, diagnostic tests,
and possibly remedial action, to be performed remotely.
The Trust will need to be assured that such arrangements
do not breach patient confidentiality guidelines, or its
obligations under the Data Protection Act. The trust must
be informed when suppliers dial into the system.
When acceptance tests are performed, the availability of
the system and its components will be measured and
compared with the standards specified herein.
Maintenance cover and technical support will be required
24 hours per day, seven days per week, including public
holidays. Any maintenance that is required MUST be done
outside of the Departments working day (8:00 to 18:00) if
downtime is required.
Supplier must specify, and cost as an option, any levels of
redundancy they feel are necessary to meet availability
requirements and prevent a single point of failure’s causing
the entire system to fail.
In the event of a failure in any interface (e.g. between an
image acquisition device and the PACS, the RIS and
PACS, or the RIS and PAS it must be possible to recover
and re-synchronise data acquired during the downtime.
The Supplier must state the degree of user intervention
required for the re-synchronisation.
The Supplier must provide a contingency plan to address
required recovery actions in response to failures in
interfacing systems, medium and long term storage
systems, workstations and other major components of the
Page 68 of 78
Radiology
RIS Business Case
5.11.08
system.
7. System Security
7.1.1
The Supplier must indicate if they are able to conform to the
Trust’s Security Policy.
7.1.2
If the application runs under Windows, then it must not be
possible for a user to gain unauthorised access to any part
of the database by using widely available office automation
tools. Supplier is reminded that any security features built
into an application might be circumvented if users are able
to access database files directly.
7.1.3
Supplier must state whether the security of their application
depends on denying user access to popular software,
including query tools, database packages and programming
languages.
7.1.4
The application must not contain any covert ‘back door’
facility that could be used to allow access to the system
without the Trust’s consent. Any attempt to embed such a
facility will be regarded as evidence of intent to gain illegal
access and may result in prosecution of the Supplier by the
Trust.
7.1.5
The application must not contain any covert facility that is
designed to stop the software from working or to modify its
functionality, whether this is based on elapsed time, number
of connections or transactions, a coded signal or any other
method. The Supplier must explicitly declare any in-built
restrictions on software usage.
7.1.6
Each authorised user must be allocated with a unique name
(user-id) and a personal password
7.1.7
Users must be able to maintain and change their own
password. A password expiry must be in place, the expiry
period to be configurable by the System Manager.
7.1.8
Supplier must give details of innovative use of technology
e.g. swipe cards / smart cards to ensure unique user
identification.
7.1.9
The designated system manager must have the facility to
create, maintain and delete users, or groups of users and
associated privileges.
7.1.10 The ability to limit the access must be provided as follows:
a)
specified workstations
b)
the access of individual and groups of users to
specific system functions or procedures
7.1.11 The designated system manager must have the facility to
limit the access of individual users to specific data entities
and/or attributes.
7.1.12 Individual users should be able to view on their screens
only those menu options or icons which they are entitled to
use.
7.1.13 Access to the data must be at a level consistent with the
user’s duties e.g. read/write, amend, execute.
Page 69 of 78
Radiology
7.1.14
a)
b)
c)
d)
e)
f)
g)
7.1.15
7.1.16
7.1.17
7.1.18
7.1.19
7.1.20
7.1.21
7.1.22
7.1.23
7.1.24
7.1.25
7.1.26
RIS Business Case
5.11.08
The package must provide the facility to report the
information on registered users. These must be listed with
details of allocated terminals and procedures open to them.
The list to be produced on request.
users currently registered on the system
expired users
future users
date created
date and time of last user session
group membership of each user
System and application privileges
The system must be able to produce a report showing
creation, amendments and deletion of users.
Any passwords stored by the system must be encrypted.
No one, including the system manager, must have the
facility to de-crypt these passwords.
User IDs and passwords must be subject to controls over
format and minimum length configurable by the System
Manager. It should not be possible to repeat the same
character more than twice within the same user id or
password.
User IDs and passwords must be subject to controls over
format and minimum length configurable by the System
Manager. It should not be possible to repeat the same
character more than twice within the same user-id or
password.
Where the system is used as part of a network, access
control must be available at the application level in addition
to that of the network.
It must be possible to create a generic user ID and
password for use by visiting clinicians which allows read
only access and limited data entry
At the end of a specified period of waiting, any user logged
into the application, but not active, must automatically be
logged out from the system and clear the application
window or screen, as appropriate, after having secured the
integrity of the database. The opened patient file should be
closed so other staff can enter it.
Following such a log out event, the application user must be
forced to log in again before being permitted to resume
processing. Details of the time-out to be recorded in the
audit log.
The timeout period must be configurable by the System
Manager.
It should be possible to set a different timeout for clinical
and administrative workstations.
The system should allow a user to logoff with a single
keystroke in emergencies, and require the user to re-login
subsequently.
The system must allow a secondary user to login without
requiring the primary user to logoff e.g. to permit a
Radiologist to authorise a report after the secretary has
Page 70 of 78
Radiology
7.1.27
7.1.28
7.1.29
7.1.30
7.1.31
7.1.32
7.1.33
7.1.34
7.1.35
7.1.36
RIS Business Case
5.11.08
typed it.
Users (clients) must not be allowed to exit from the
application system to the operating system unless they are
explicitly authorised to do so.
Strong precautions must be taken to ensure that computer
staff cannot manipulate data and programs. Supplier should
indicate how this is achieved.
Following a number of unsuccessful log in attempts
(configurable by the System manager) to gain access from
a workstation, the system must disable the user id for a
length of time set by the System Manager concerned.
Users must be able to modify their own passwords at any
time, and be forced to do so, after a period determined by
the system manager, if they have not already done so.
Supplier should state whether the system can support the
use of workstation access control technologies such as
swipe cards or thumb print recognition. If the system will
support such technologies, Supplier should describe how
they are used and the classes of workstation on which they
can be used
The system must maintain audit logs of all the additions,
changes and deletions to and, optionally, retrievals from,
the database with a record of the username of the user who
committed the transaction and the date and time of the
transaction. Details of the type of transaction with
appropriate data elements must also be recorded. It must
be possible for the system manager to display, print,
archive and purge the audit logs.
The system must record all attempts to gain invalid access.
If more than three consecutive attempts are made by the
same user, the system must make that users profile
unavailable for a period determined by the system
manager.
The system manager must be able to force any or all
workstations to log off the system in such a way that all
active processes being run through the workstation are
terminated in a controlled way that closes all open files and
does not corrupt the database.
If a workstation, or other peripheral device connected to the
system, is switched off, or fails as a result of power failure
or equipment malfunction, the system must close down any
active processes being run through the device or
workstation in a controlled way that closes all open files and
does not corrupt the database.
To ensure the security of data, including images, the
system must permit the copying of all data onto media
which can be stored remotely from the system and the
mechanisms for doing this will be specified.
Page 71 of 78
Radiology
RIS Business Case
5.11.08
8. General Requirements
8.1 Development
8.1.1
The Supplier will provide New Releases Leading Edge and
Technology Refresh during the period of the Contract.
The supplier must define how they will perform this task.
8.2 Product safety and electrical interference standards
8.2.1
8.2.2
All equipment supplied must comply with the appropriate
International and European approved standards for
product safety and electrical interference.
Supplier must list the standards to which their equipment
complies.
8.3 Quality of products and services
8.3.1
8.3.2
8.3.3
Supplier must satisfy the Trust that good software
manufacturing practices were followed during the
development of any program code to be delivered.
Acceptance testing is not a sufficient indication of software
quality.
The Supplier must be ISO 9001 accredited.
The project to implement the system will use a PRINCEbased methodology. The precise project management
methodology will be agreed during negotiations.
9. Service Requirements
9.1 Delivery, Installation and Demonstration
9.1.1
9.1.2
9.1.3
For the computer hardware being provided as part of the
proposal, the Supplier must provide details of the hardware
delivery, installation and acceptance process. The Supplier
must take full responsibility for these processes and must
indicate the involvement required in the process from Trust
staff.
The Supplier must provide details of the software delivery,
installation and acceptance process. The Supplier must
take full responsibility for these processes and must
indicate the involvement required in the process from Trust
staff.
The Supplier must describe the PC / client installation
process including any use of applets or security certificates.
The Supplier should state whether the client installation and
Page 72 of 78
Radiology
RIS Business Case
5.11.08
upgrade processes can be undertaken remotely and
whether they can be automated as batch processes from
centrally controlled servers.
The supplier must give full details of the minimum
specification required of any PC in order to run there RIS
product.
The contactor must give details of any incompatibilities of
RIS with any other product.
The Supplier must provide all system software, upgrades,
bug fixes, etc. on fully labelled and dated media (e.g. tape,
CD-ROM, DVD).
On delivery of the system the Supplier must provide
Release Notes with all information that is reasonably
required to install, configure and tune the application in a
networked environment.
Following delivery and installation the Supplier must
demonstrate to the Trust that the RIS application modules
are fully operational.
The supplier must give a fully detailed, including cost, of all
hardware required and state if the Trust was to purchase
the hardware what the implications for product support
would be.
9.1.4
9.1.5
9.1.6
9.1.7
9.1.8
9.1.9
9.2 Implementation Services - Technical Support during Implementation
9.2.1
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
Under the conditions of this procurement short listed
Supplier will be to tender for the following services:
Supply and installation of all equipment;
Supply of all software, including operating,
database, application and interface software;
Interfacing the PACS with the RIS, if the two
systems are not fully integrated;
Provision of a Integrated Windows authentication
Interfacing the RIS with the Current vendor PAS or a
new PAS purchased in the future by the trust
Integration of all hardware and software into a
fully functioning system which meets the
requirements stated in this Specification;
Transfer of data from the existing systems to the
new System;
Supply of all equipment, System, application
software and interface documentation in both hard
copy and electronic form;
Training of key staff in the Hospital covering both
equipment and system management and support,
and operational use of the system;
Project management to cover the supplier's
elements of this project, and liaison with the
Hospital's project manager;
Continuing maintenance and support of the system,
Page 73 of 78
Radiology
RIS Business Case
5.11.08
including upgrades, interfaces etc. throughout its lifetime.
The Trust will be responsible for the provision of the
physical environment required to support the system.
However, the Supplier must give full details of the physical
environment, including space, electrical, water, drainage
and cooling requirements for each item of equipment
proposed. The Supplier must warrant that the environment
provided by the Trust meets all its requirements.
The Supplier must state the project management
methodology it will use for the project.
9.2.2
9.2.3
The Supplier must provide details of their approach to
implementation and provide an implementation plan.
The Supplier must state the technical support roles, which
are required for each stage of the implementation, defining
the skills, abilities and experience for each role.
9.2.4
9.2.5
9.2.6
9.2.7
9.2.8
a)
b)
c)
d)
e)
f)
g)
h)
9.2.9
a)
b)
c)
The Supplier must state the staff that will be involved in the
implementation stating the time anticipated for the project
and the roles of its staff.
The Supplier must indicate what levels of technical support
and expertise they expect from the Trust referenced against
the roles defined above.
The Supplier must give the anticipated time on site for each
of these roles at each stage of the project.
The Supplier must provide details of the call logging
process they will employ during the implementation to
handle all faults and requests reported by the Trust. The
Supplier must indicate whether implementation problems
are handled by their standard Help Desk or by another
method.
The Supplier must provide details of the training provided
for specific user groups including:
Consultant Radiologists
Radiographers;
System Trainers;
Radiology Managers;
Operational System Manager;
Quality Assurance Radiographers;
Radiology Secretarial and Clerical Staff;
System Administration Staff.
The Supplier must provide a detailed training plan for each
of the staff group noted in 9.2.8 and
Ensure that all the training materials such as training
manuals, instruction books, audio-visual material, and
workstations be left with the Trust for continuing training by
the Trust staff;
Maintain a training presence during the period before and
after the first day of operation of each phase of the project;
supply information relating to time scales and resource
implications for the Radiology Department and the Trust of
the training programme;
Page 74 of 78
Radiology
RIS Business Case
5.11.08
d) liaise with the Radiology Department in assessing the
competency of staff for training;
e) indicate how they will support and update the System
Trainers for the duration of the contract;
f) supply training to cover all future developments of the
System;
g) liaise with the Trust’s PACS/RIS Project Manager regarding
the appropriate venues for user training;5 days of go live
support split into two blocks decided by the trust
h) create, in conjunction with the Radiology Department, a
dedicated training database of anonymous images,
because ‘live’ images cannot be used for training purposes.
9.2.10 The Supplier must have formal quality assurance systems
for the following areas:
a)
Software development
b)
Support
c)
Implementation
d)
Training
e)
Standards
The Supplier should outline these systems in its response.
9.3 Support Services
9.3.1
9.3.2
9.3.3
9.3.4
9.3.5
9.3.6
The Supplier must provide continuing support of the system
for the life of the system.
Support and maintenance for the system must cover
hardware and software maintenance, technical support,
regular software upgrades for all types of software on the
system, and updates to the system documentation to
ensure that it is appropriate for the current revision level of
the system throughout its lifetime which will be a minimum
of seven years from acceptance.
The Supplier must provide leading edge upgrades as part
of the maintenance and support agreements.
The Supplier must upgrade hardware in the event that a
software upgrade or a leading edge upgrade adversely
affects system response or availability.
Maintenance and repair services will be required to cover
24 hours per day, seven days per week, including public
holidays The Supplier must provide details of the
maintenance and support services provided.
Technical support will be required to cover 24 hours per
day, seven days per week, including public holidays.
Page 75 of 78
Radiology
9.3.7
RIS Business Case
5.11.08
The Supplier must guarantee the following support
response and fix times:
Priority
Fix Time
1
Response
Time
15 minutes
2
30 minutes
6 hours
3
60 minutes
7 days
4
7 days
10 days
4 hours
Priority Definitions:
Priority 1: This category covers any fault in the System that
prevents the Trust carrying out any planned workload on
the System
Priority 2: This includes errors which have a major impact
on the System, but which do not stop the Trust carrying out
its planned workload.
Priority 3: These errors are inconvenient for the users, but
can be endured for a while and do not disrupt the planned
workload.
Priority 4: These are errors that can be worked around
without too much difficulty, but must be fixed in the next
release.
Planned Preventative Maintenance for core components
will be done outside core working hours. System Upgrades
must be undertaken outside core hours and all efforts
made to minimise the impact on clinical downtime
9.3.8
9.3.9
The Supplier will be required to confirm that system
manager training will be available throughout the lifetime of
the system.
The supplier must indicate what assistance would be given
at the end of the contract period to allow the transition to a
new supplier service provider
10. Constraints
10.1 Strategic
10.1.1
It is essential that the System proposed in response to this
document fits into the Trust’s strategic context. As a
consequence it will have an architecture which permits
expansion and extension and the Trust must be assured
that it will be supported and developed for the foreseeable
future.
Page 76 of 78
Radiology
10.1.2
RIS Business Case
5.11.08
To provide this assurance the Supplier must assure the
Trust that he sees PACS and RIS as long term strategic
products of its company. The Supplier must also have a
good record in supplying successful systems of this type. It
is highly desirable that the Supplier has a support
organisation located in the United Kingdom.
10.2 Physical
10.2.1
10.2.2
The System will be located in various areas around the
Trust though it is expected that the servers will located in
the Trust’s existing computer rooms. The Supplier must
warrant that the environment provided by the Trust meets
all its requirements.
The Trust will install the services required to support the
System but it is not envisaged that any major structural
changes will be required to the buildings
Page 77 of 78
Radiology
RIS Business Case
5.11.08
Appendix 3
Issues with Current RIS
RIS Project
Version 1: 4th November 2008
Number
Current Issue / Problem
1
2
No voice recognition available to radiologists without further financial investment.
There are currently 4 logins required for a radiologist to start to report. This is time
consuming and aggravating. Current vendor do offer a single log in using the smart
card but this would have a financial cost to the Trust
3
The system frequently ‘hangs’ with either a white screen or egg timer on display. This
happens in many different modes no just reporting but also when booking in patients
and doing examination details
4
5
Reliant on PAS working for the RIS to be functioning and available for use
It doesn’t contain all of the department’s data as there is a separate system for MRI
appointment creation. This should be included within the data we have
Statistics are very difficult and time consuming to pull from the system. Business
object is available for the Trust but this again would require further financial
investment.
6
7
Very difficult to know what has not been completed with regards to examination details
or authorisation of reports. There seems to be no automatic reminders with the latter.
8
9
10
Can seem very slow sometimes
There is no where to put the patients 18 week pathway identification number
National examination codes are currently not used and so it becomes time consuming
and difficult to map examinations across to the correct coding level for finance and
mapping analysis
11
The electronic diary is very difficult to use and so paper diaries are still used through
out the department
12
Data from Radiology does not flow back to PAS so it becomes time consuming for
people to see in coding and finance what examinations patients have had
Page 78 of 78