Download Specification

Renal Information Technology
System
Output Based Specification (OBS)
Version No: 0.60
Issue Date: 20th July 2011
Version No: 0.60 20/07/2011
Output Based Specification
Renal IT System Replacement
Purpose of this Document
The purpose of this document is to define Nottingham University Hospital’s (the Trust) requirements
for a replacement of or upgrade to the current Renal IT System in order to inform potential suppliers
and aid the procurement and evaluation process.
Document Approval
Role
Name
Organisation
Signature
Date
Head of Service
Dr Simon Roe
NUH
20th July 2011
General
Manager
Nikki Pownall
NUH
20th July 2011
Confidentiality
All information contained in this document is confidential to Nottingham University Hospitals NHS
Trust and the NHS National Programme for IT or any member organisation of NHS East Midlands and
is intended only for use within the NHS.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 2 of 69
Output Based Specification
Renal IT System Replacement
CONTENTS
SECTION A – SUPPLIER GUIDANCE
7
1.
IMPORTANT INFORMATION
1.1 Audience
1.2 Procurement Procedure
1.3 Reliance on information and liability of the Trust
1.4 Confidentiality and publication of information
1.5 Publicity
1.6 Sub-contractors
1.7 Contract
7
7
7
7
8
8
8
8
2.
GUIDANCE TO RESPONDENTS
2.1 Format of the Response
9
9
3.
EVALUATION
3.1 Compliance Matrix
3.2 Risk Transfer
3.3 Response Template
3.4 Evaluation Matrix
3.5 Approach to the Procurement and Provisional Timescales
10
10
10
11
12
14
SECTION B – CONTEXT OF THIS PROCUREMENT
15
4.
BACKGROUND
4.1 Nottingham University Hospitals NHS Trust
4.2 Renal and Transplant Services
4.3 Children’s Renal Unit
4.4 Existing IT systems
4.5 Trust Data Warehouse
4.6 Existing Electronic Interfaces:
4.7 Existing Information Flows
4.8 Staffing
15
15
15
15
15
16
16
17
17
5.
THE INVESTMENT CASE
5.1 Business Context
5.2 Aims and Benefits of the Procurement
19
19
19
6.
SCOPE OF THE REQUIREMENT
6.1 Business Processes
6.2 Organisation
6.3 Location
6.4 Data
6.5 Applications
6.6 Technology
21
21
21
22
22
22
23
7.
TRUST INFRASTRUCTURE AND STANDARDS
7.1 General
7.2 Major Systems
7.3 Connecting for Health (CfH)
7.4 Patient Master Index (PMI) and Patient Identifiers
24
24
24
27
27
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 3 of 69
Output Based Specification
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
Interfacing Standards
Networking Standards
Wireless Network Standards
Desktop Standards
Printer Standards
Server Standards
Support Standards
Security and Information Governance Standards
Renal IT System Replacement
28
28
29
29
30
30
32
32
SECTION C - TRUST’S DETAILED REQUIREMENTS
34
8.
FUNCTIONAL REQUIREMENTS
8.1 Overview
8.2 System Look and Feel
8.3 Information Flows and Interfaces
8.4 Interfacing
8.5 Data Extracts
8.6 Information Reporting and Analysis
8.7 Printed Output
8.8 Reference Tables
8.9 Dates and Times
8.10 Online Help and Validation
8.11 Deleting and Merging Records
8.12 Patient Demographics
8.13 General Clinical Records
8.14 Care Plan/Nursing Record
8.15 Pathway/Protocol Management
8.16 Electronic Prescribing
8.17 Admissions
8.18 Clinic Visits
8.19 Procedures
8.20 Transplant
8.21 Peritoneal Dialysis
8.22 Haemodialysis
8.23 Vascular Access for Haemodialysis
8.24 Chronic Kidney Disease (Low Clearance)
8.25 Dietetic Assessment
8.26 Psychosocial Issues
8.27 Clinical Alerts
8.28 Clinical Communication
8.29 Clinical Correspondence
34
34
34
34
38
39
39
40
40
41
41
41
42
42
43
43
43
44
45
45
45
46
46
46
47
47
47
47
47
48
9.
TECHNICAL REQUIREMENTS
9.1 Security Requirements
9.2 System Access
9.3 Audit Trail
9.4 Separate Live Training and Testing Environments
9.5 Networking Requirements
9.6 Desktop Requirements
9.7 Printer Requirements
9.8 Server Requirements
9.9 Database Requirements
49
49
49
50
50
50
50
51
51
52
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 4 of 69
Output Based Specification
Renal IT System Replacement
9.10 Database Management, Backup and Recovery
9.11 CfH Requirements
52
52
10.
IMPLEMENTATION SUPPORT AND DEVELOPMENT
10.1 Project Management
10.2 Approach to Implementation
10.3 New Ways of Working and Benefits Realisation
10.4 Installation and Technical Support during Implementation
10.5 System Configuration and Set-up
10.6 Data Migration
10.7 Training
10.8 Business Continuity & Disaster Recovery
10.9 Documentation
10.10 System Go-Live and Verification Period
10.11 Handover to Operational Management
10.12 System Support
10.13 Product Development
53
53
53
53
54
54
54
55
55
55
56
56
56
56
11.
COMMERCIAL REQUIREMENTS
11.1 Delivery Requirements
11.2 Timescale
11.3 Software Licenses
11.4 Management and Maintenance of Contract
11.5 End of Contract Support
11.6 Extension to Contract Term
58
58
58
58
58
58
59
12.
FINANCIAL REQUIREMENTS
60
13.
APPENDICES
13.1 Appendix A – Details of Stand Alone Databases
13.2 Appendix B – Major Systems Interfaces
13.3 Appendix C – Migration of Existing Data
61
61
63
63
GLOSSARY
64
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 5 of 69
OUTPUT BASED SPECIFICATION (OBS)
FOR A
RENAL PATIENT INFORMATION SYSTEM
This Output Based Specification (OBS) describes the requirements for a new electronic healthcare
system to support the delivery of renal services at Nottingham University Hospitals NHS Trust (‘NUH’
or the ‘Trust’).
The OBS is divided into three sections:



Section A describes the procurement approach and guidance to suppliers.
Section B provides relevant background about the Trust and the context of this procurement.
Section C contains the Trust’s detailed requirements to which suppliers MUST respond in the
format stipulated.
All sections are supported by a number of appendices.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 6 of 69
SECTION A – SUPPLIER GUIDANCE
1.
IMPORTANT INFORMATION
1.1
Audience
This section of the OBS is intended to give clarification to respondents regarding the Trust’s
procurement approach and evaluation criteria. Suppliers should note the guidance contained
in this section regarding the format of the response required by the Trust.
1.2
Procurement Procedure
The Trust is inviting prospective suppliers under the Official Journal of the European Union
(OJEU) to submit proposals in response to the requirements set out in this OBS. Tenders will
be evaluated on the basis of the most economically advantageous offer that meets the
requirements of the Trust in accordance with the evaluation guidance set out in section 3
below.
The Trust expressly reserves the rights:
(i) Not to award any contract as a result of the procurement process;
(ii) To make whatever changes it may see fit to the content and structure of the tendering
competition within the OJEU remit.
In no circumstances shall the Trust be liable for any costs incurred by a respondent in
relation to the procurement process or the entering into of a contract for the provision of
any products or services.
By participating in the procurement process respondents agree and accept that they are
bound by all the terms of this OBS.
1.3
Reliance on information and liability of the Trust
The information in this document and any other information provided by the Trust is
provided in good faith. Such information is intended only as an explanation of Trust
requirements and is not intended to form the basis of a respondent’s decision as to whether
or not to enter into a relationship with the Trust.
The information does not purport to be all-inclusive or to contain all the information that a
respondent may require. Respondents and their advisers must take their own steps to verify
any information that they use and must make an independent assessment of the
opportunities described in this document after making such investigation and taking such
advice as they consider necessary.
The Trust, its officers, employees, agents or advisers make no representation or give any
warranty as to the adequacy, accuracy, reasonableness or completeness of the information.
Respondents considering entering into a relationship with the Trust should make their own
enquiries and investigations of Trust requirements.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 7 of 69
Neither the Trust nor its professional advisers shall be liable for any loss or damage arising as
a result of reliance on the information, nor for any expenses incurred by respondents at any
time.
Any advisers appointed by the Trust, whether legal, financial, and technical or otherwise, will
not be responsible to anyone other than the Trust for providing advice in connection with
the procurement.
1.4
Confidentiality and publication of information
The information is made available on condition that it is treated as confidential (except any
such information as may already be in the public domain or may come into the public
domain otherwise than by reason of a breach of a confidentiality obligation).
The respondent (and any party related to the respondent) must not disclose, copy,
reproduce, distribute or pass any information to any other person at any time without the
prior written consent of the Trust.
Respondents acknowledge and agree that at certain stages in the procurement exercise, the
Trust will be obliged to disclose detailed information in relation to any proposals by a
respondent and make key documents available for private inspection for the purposes of the
procurement exercise. Whilst the Trust will be reasonable to regard to the protection of
commercially sensitive information, they can only do so in the light of the latest published
guidance in this area and the Freedom of Information Act 2000.
1.5
Publicity
Respondents must obtain approval from the Trust before any disclosures are made to the
press or any other public domain in respect of this procurement exercise. Respondents must
not undertake any publicity activities in relation to the procurement without the prior and
expressed written permission of the Trust.
1.6
Sub-contractors
Where a respondent intends to use sub-contractors, it will be its responsibility to provide
such sub-contractor with all necessary information relating to the procurement. Where
information about a potential sub-contractor is requested in submissions and clarifications
such information must be given about all potential sub-contractors.
1.7
Contract
The subject matter of any procurement document shall only have contractual effect when it
is contained in the expressed terms of an executed written contract. However, the
provisions in this OBS bind each respondent.
The Trust will refer details of the evaluation process and selection of respondents at any
stage to appropriate persons for approval. Notwithstanding any necessary approvals having
been obtained, the Trust reserves the right to reject any proposal from respondents and/or
terminate discussions and negotiations with any one or more of them.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 8 of 69
2.
GUIDANCE TO RESPONDENTS
2.1
Format of the Response
This OBS forms part of the formal procurement process and this guidance sets out in how
suppliers must respond.
Throughout the entire invitation to tender package (including this OBS), the following
applies:

Requirements containing the word MUST are particularly important to the Trust and will
be treated as mandatory requirements which a supplier must be capable of satisfying;

Requirements containing the word SHOULD are considered by the Trust to be important
but may (but will not necessarily) be treated as non-mandatory in justifiable
circumstances.
Respondents will be expected to complete the following:
1. Compliance matrix
2. Risk transfer spreadsheet
3. Response template
4. Cost template (see section 12)
The response to each should demonstrate how the supplier will deliver the requirements
which are set out in this OBS. Additional information may be included within the tender
response, however, the Trust is not obliged to review any other supplementary information
or appendices other than those that the supplier explicitly makes reference to within their
answers.
Responses to each of the three components must be presented in the format requested and
on the templates provided. Failure to do so may result in the response being excluded from
evaluation. The supplier must provide two printed copies of their tender response.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 9 of 69
3.
EVALUATION
3.1
Compliance Matrix
The compliance matrix spreadsheet embedded below will form the first part of the
evaluation process. It is intended for suppliers to use to give a concise summary of the level
of compliance of the supplier’s proposed solution to the Trust’s high-level requirements.
Suppliers must be unequivocal in declaring, in respect of all of the sections of this document,
the level of compliance to the stated requirement. The response method is detailed below:

Fully compliant: solution completely satisfies the stated condition, need or requirement.

Non compliant: solution does not completely satisfy the stated condition or requirement
or does not or cannot provide the required need.
The supplier response will be evaluated on a pass/fail basis. Failure to provide a response
will result in the supplier not being evaluated any further in the procurement exercise.
Failure of the supplier to be ‘fully compliant’ in any of the requirements listed in the
compliance matrix will result in the supplier being eliminated by the Trust from further
competition in the tender.
Compliance
Matrix.xls
3.2
Risk Transfer
The risk transfer spreadsheet embedded below summarises the anticipated key risks for the
implementation and operation of the Renal Information Technology System from the design
stage to contract termination/system replacement. For each risk suppliers should confirm if
they are prepared to:
a)
b)
c)
d)
Accept full responsibility (Supplier)
Not accept any responsibility (Trust) ie Trust retains sole ownership of the risk, or
Accept shared responsibility (Joint), and
Detail any actions they propose to take in order mitigate the probability and/or impact of
each risk (under heading ‘Supplier Comments’).
The suppliers response to the embedded spreadsheet will be evaluated during the evaluation
process and scores will be added to the evaluation matrix (see detail in section 3.4 below).
Risk Transfer.xls
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 10 of 69
3.3
Response Template
Suppliers who successfully pass the compliance matrix will be evaluated against their
responses to the requirements in the response template spreadsheet embedded below. The
response template cross references requirement statements found in this OBS using the
paragraph reference number(s).
Suppliers should note that:
a) Each response MUST be embedded within the response template against the
appropriate paragraph reference. Each response MUST contain one of the following
statements:
1. Fully Compliant - Respondent's product or service completely satisfies the stated
condition or need.
2. Partially Compliant - Respondent's product or service only partially satisfies the
stated condition or need.
3. Non-compliant - Respondent's product or service does not satisfy any part of the
stated condition or does not or cannot provide the services needed.
4. Noted & Accepted - Where a clause provides only information that does not
otherwise require a response.
5. Alternative Proposal - The respondent’s product can be modified to meet the stated
condition or can provide an alternative to the services needed.
b) In addition the supplier MUST, for each response, add a concise explanation of how the
requirement is met by their proposed solution;
c) Where the supplier response is “Alternative Proposal” additional details MUST be
provided for the proposed alternative including:




Estimated costs for such modification or service alternative;
Time required to perform the alternative proposal;
Issues relating to the limitations, drawbacks, shortcomings or collateral issues to the
alternative proposal; and
Any other matters essential to support the Trust’s consideration of the proposed
alternative.
Text and diagrams may be provided to illustrate the supplier’s proposal and understanding of
the requirement (these must be clearly referenced and presented to the Trust). Any
additional or supplementary information that should be reviewed by the Trust must be
explicitly referenced on the response template in the appropriate section. Any material
presented but not referenced on the response template may not be reviewed.
Response Template
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 11 of 69
3.4
Evaluation Matrix
In evaluating responses the Trust will determine which response represents best value to the
Trust without exposing the Trust to undue risk. The Trust will assess against the evaluation
criteria referred to below and complete the embedded evaluation matrix spreadsheet.
Evaluation Matrix
Responses will be evaluated and scored on a scale of 0 (zero) to 4 (four) where:
Score
0 (zero) = Poor
1 (one) = Area for Concern
2 (two) = Fair
3 (three) = Good
4 (four) = Excellent
Characteristics of Response
Question not answered.
Unclear.
Confused.
Inconsistent.
Unsubstantiated.
Supplier cannot meet requirements particularly important to
the Trust.
No consideration of the project risks/dependencies.
Significant gaps in response.
Superficial.
Insufficient level of detail.
Assumptions not identified.
Lack of evidence that supplier can meet the requirements
particularly important to the Trust.
Proposed solution does not address the Trust’s needs.
Limited consideration of the project risks/dependencies.
Minor gaps in response.
Makes reference to supporting information.
Meets the requirements particularly important to the Trust.
Some consideration of the project risks/dependencies.
Clear.
Concise.
Relates answer to previous experience.
Meets all of the requirements that are particularly important
to the Trust and some of the requirements that are important
to the Trust but will be treated as non-mandatory.
Consideration of the project risk/dependencies.
Clear and easy to read response.
Comprehensive.
Well evidenced (in terms of robust response and links to
previous relevant experience).
Evidence of thorough evaluation and detail to substantiate
assumptions.
Meets the Trust’s requirements in full.
Thorough consideration for project risks/dependencies.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 12 of 69
Please note the following points:
1. Cross-referencing between responses within the document is not encouraged. Each item
must have its own response.
2. Website references will not be reviewed.
3. The Trust is not obliged to review any other supplementary information or appendices
other than those that are explicitly requested.
4. Weighted scores for each response will be calculated by multiplying the score by the
associated weighting.
Responses will be subject to both a financial and non-financial evaluation. Costs contained
within the responses will initially be reviewed in the evaluation process at an early stage to
gauge whether they fall within the cost envelope determined by the Trust in order to ensure
that time is not wasted on proposals which will not provide an affordable solution.
Following this initial, high-level financial review, the responses will be subject to a nonfinancial evaluation to demonstrate how well the respondents can deliver the requirements
stated in the specification. On the evaluation matrix each area has been weighted to
indicate its relative importance to the Trust (also see table below). It is expected that the
respondent shall make every effort to provide as much information as possible on their
capabilities in respect of all of the areas listed below.
Criteria
Evaluation Group
Fitness for
purpose
(including
quality)
Functional requirements
(OBS, section 8)
Technical requirements
(OBS, section 9)
Commercial requirements
(OBS, section 11)
Supplier presentations & user trials*
Implementation support & development
(OBS, section 10)
Risk transfer (OBS, section 3.2)
Financial requirements
(OBS, section 12)
Total
Delivery
Costs
Non-Financial
Weighting
30%
Final
Evaluation
Weighting
60%
20%
10%
15%
25%
-
40%
100%
100%
* Supplier presentations and user trials will be arranged during the tender process (see provisional
timescales in section 3.5 below).
The total weighted score for the non-financial evaluation will be converted to a percentage
of the maximum total weighted score available. This percentage score will be used in the
final element of the evaluation, the value for money calculation. The value for money
calculation will attribute 60% of the available score to the non-financial evaluation and 40%
to costs.
Costs will be evaluated for all respondents that:
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 13 of 69
1. Pass the initial cost review to ensure the proposal is within the cost envelope determined
by the Trust.
2. Pass the compliance matrix.
The respondent must complete the pricing table in section 12 with all appropriate cost
information for Trust review and to inform the tender evaluation.
When evaluating cost, the respondent who submits the lowest price will score 100% of the
available marks for cost. A calculation will then assess by how much each of the other
respondents exceeds this lowest price and each respondent will be awarded marks. The
calculation will be carried out on the following basis. The lowest price bid will score 100% of
available marks. All other bids will then score 100% of available marks less the percentage of
available marks by which their price exceeds the lowest bid. All bids that are 100% or more
in excess of the lowest bid shall score zero for cost. For clarity an example has been
provided.
3.5
Respondent
Price
A
B
C
D
£100
£120
£150
£200
Difference to
Lowest Bid
0%
20%
50%
100%
Percentage Score
100%
80%
50%
0%
Approach to the Procurement and Provisional Timescales
The procurement will be conducted in accordance with Trust Standing Financial Instructions.
The Trust expects follow the outline timescales detailed below:
Milestone
ITT issued
Site visits (as appropriate)
Receive responses to ITT
Supplier presentations and user trials
Completion of tender evaluation
Trust secure formal approval to award
contract
Notify successful bidder and unsuccessful
bidders
Standstill period (alcatel)
Intention to award contract
System implementation
All invoices received
Date
26/07/2011
To be confirmed
05/09/2011
w/c 05/09/2011
16/09/2011
28/10/2011
w/c 31/10/2011
31/10/2011 – 11/11/2011
w/c 14/11/2011
21/11/2011 – 16/03/2012
w/c 19/03/2012
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 14 of 69
SECTION B – CONTEXT OF THIS PROCUREMENT
4.
BACKGROUND
4.1
Nottingham University Hospitals NHS Trust
NUH is one of the country’s largest and busiest acute teaching Trusts. It provides acute and
specialist services to 2.5 million people within Nottingham and surrounding communities
from the Queen’s Medical Centre (QMC) and the Nottingham City Hospital (NCH) campuses.
It has an annual budget in excess of £682 million and employs over 12,000 staff. It currently
has approximately 2,100 hospital beds.
Activities include general hospital services for the local population and a wide range of
specialist services for patients across the East Midlands and beyond.
In 2008/09 NUH cared for around:

755,000 first and follow-up outpatients;

160,000 emergency attendances;

90,000 non-elective admissions; and

90,000 day case and elective inpatient admissions.
The NUH vision is to be the best acute teaching Trust in the country by 2016 with six strategic
aims as the markers for success: clinical outcomes; patient experience; staff satisfaction;
research; teaching and training; and value for money.
4.2
Renal and Transplant Services
Renal and Transplant services (also referred to as ‘Services’ in the remainder of this OBS), are
a part of the Directorate of Diabetes, Infectious Diseases, Renal and Cardiovascular Diseases
(DIRC), one of the nine Clinical Directorates responsible for delivering clinical services at
NUH.
4.3
Children’s Renal Unit
The Children’s Renal Unit (included within the ‘Services’ as defined in section 4.2 above) for
the Trust is based at QMC and is a regional centre for children and young people with kidney
problems. As one of only 12 children’s renal units in the country, the unit covers the whole
of the East Midlands and East Anglia. The Children’s Renal Unit are part of the Directorate of
Family Health at NUH.
4.4
Existing IT systems
Renal and Transplant services at NUH currently use the following computer packages to
support its patient record administration:
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 15 of 69
4.4.1
Renal Proton (RS6000):
This is the department’s main clinical system. It is a legacy renal information system used
since 1982, and has a support contract through Clinical Computing, UK (CCL). The system is
highly configurable and has been customised extensively in-house over the last three
decades to support the provision of clinical services. This system is used by both the adult
and paediatric nephrology teams.
4.4.2
Renal Speciality Standalone Databases:
The following standalone databases are currently being used and the Trust is seeking to
replace these with the new system.






Peritoneal dialysis database
Transplant database - File based Microsoft Access database
Vascular access database - Project Microsoft Access database on SQL server
Live donor database
┐
Deceased donor database File based Microsoft Access databases
Retrieval database
┘
These standalone databases are described in more detail in appendix A.
4.4.3
Trust Corporate Systems:
These are described in detail in section 7.2.
4.5
Trust Data Warehouse
In line with its Management Information Strategy, the Trust is building an integrated
corporate data warehouse solution fed by both its clinical and non-clinical systems to provide
a single source of summary business and clinical information for the Trust. The Trust aims to
incorporate data from the Renal Information System into this solution.
4.6
Existing Electronic Interfaces:
The electronic interfaces to Proton are summarised below. For further information please
see appendix B which is a detailed schema of the major systems used at NUH including the
Renal system, Proton.
4.6.1
Patient Demographics
Proton has a demographic interface to the Hospital Information Support System (HISS). The
Patient Administration System (PAS) feeds HISS. The Proton link with HISS is a
'query/response' link that works by hospital number only (not patient name/dob/sex) which
allows a Proton user to “pull” demographics for a patient on demand from the master index
into the Renal system index. The query/response link updates automatically for all Renal
patients over each weekend. There is however no 'unsolicited update' link to allow
demographic changes to be “pushed” to the departmental system in an event driven way ie
when a change is made directly to data on the hospital patient master index.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 16 of 69
4.6.2
Electronic Orders:
There is no electronic orders interface to Proton and no requirement for this to be included
in the new system. Staff place electronic patient orders and bulk clinic orders using a special
module available in the HISS and the Nottingham Information System (NotIS) which produces
a specimen label and sends the order to the lab electronically.
4.6.3
Electronic Results:
The results interface transfers unsolicited results ie results are “pushed” to the Renal system
when they are output/authorised from the Pathology system, hence they are event driven
with no delay. Not all results are transferred electronically.
Both the demographic and results interfaces use Transmission Control Protocol
(TCP)/Internet Protocol (IP) connections. The messages that are exchanged are proprietary
format (not Health Level 7) but the events that are triggered are actually standard/equivalent
to Health Level 7 (HL7) events.
Electronic results from King’s Mill Hospital (KMH) are currently manually entered into Proton
as there is no existing electronic interface.
4.7
Existing Information Flows
The electronic information flows from Proton are summarised below.
4.7.1
Renal Patient View
Data is extracted from Proton to enable patient access to key information. Please see
www.renalpatientview.org for more information.
4.7.2
Renal Registry
Data is extracted from Proton and used for national statistical purposes.
www.renalreg.com for more information.
4.8
Please see
Staffing
The Renal and Transplant specialty employs approximately 233 staff whose roles are
summarised in the following table:
Renal Staff Group
Carrel ward
Bramley ward
King’s Mill satellite unit
Transplant
Outpatients
CAPD
Dialysis unit
Ilkeston
Number of Staff
29
30
24
6
4
6
70
17
Location
NCH
NCH
KMH
NCH
NCH
NCH
NCH
Ilkeston Community Hospital
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 17 of 69
Renal Staff Group
Renal management
Renal administration
Medical
Number of Staff
4
21
22
Total
233
Location
NCH
NCH
NCH
The Paediatric Nephrology specialty employs 30 staff whose roles are summarised in the
following table:
Renal Staff Group
Medical
E17 ward nurses
Renal nurses
Number of Staff
8
12
10
Total
30
Location
QMC
QMC
QMC
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 18 of 69
5.
THE INVESTMENT CASE
5.1
Business Context
As a specialty, the Renal and Transplant service has been at the forefront of using
information technology for day-to-day patient care and would be considered as an
information driven and dependent specialty.
The Renal and Transplant service provides a comprehensive range of services to kidney
patients locally, including the management of acute kidney injury and chronic kidney disease.
NUH is the main provider of outpatient, dialysis and transplant services for Nottingham and
Nottinghamshire. The majority of services are provided from a purpose built unit at the NCH
campus. NUH have satellite haemodialysis units at KMH in Mansfield, Ilkeston Community
Hospital and at the QMC campus in Nottingham. Paediatric nephrology service is based
wholly at the QMC campus with outreach clinics across the East Midlands, South Yorkshire
and East Anglia.
Renal and Transplant service’s patients require frequent and demanding checking of
biochemical, haematological and other investigations that underpin decisions about
treatment planning and management. In a large unit such as NUH, it would be impossible to
effectively manage patients without access to information provided in a reliable, accurate
and accessible format.
From an IT perspective, the strategic ambition is to ensure IT systems better monitor patient
and clinical outcomes, patient level costs and efficiency measures so that we can confidently
pursue our aim to provide excellence in care.
5.2
Aims and Benefits of the Procurement
5.2.1
Organisational Objectives
5.2.1.
1
Generate the full National Renal Dataset required by the Maximise use of resource.
Department of Health (DoH) for both Renal and Transplant
Organisational compliance.
Services and the Children’s Renal Unit.
5.2.1.
2
Produce and improve other essential electronic outputs (eg Improved service delivery &
Renal Registry monthly data, NHS BT returns, Renal maximise income.
PatientView, CQUIN standards, National Vascular Access
Audit).
5.2.1.
3
Enhance the capability to conduct clinical research and Maximise use of resource.
audit.
5.2.1.
4
Retain Business Continuity.
Maximise use of resource.
5.2.2
Operational Objectives
Benefits
5.2.2.
1
Minimise the manual entry of data (eg haemodialysis Maximise use of resource
sessions) and duplication.
and reduce clinical risk.
5.2.2.
2
Eliminate need for manual entry of activity data (eg Increase efficiency,
haemodialysis sessions) into PAS.
maximise resource & reduce
clinical risk.
Benefits
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 19 of 69
5.2.2.
3
Eliminate manual entry of results (inc. results from
peripheral clinics).
5.2.2.
4
Rapid selection of patients’ records – barcode readers and Maximise use of resource.
tagged patient groups.
5.2.2.
5
Less reliance
administration.
5.2.2.
6
Permits remote access working by clinical staff.
Maximise use of resource &
reduce clinical risk.
5.2.2.
7
Ease of report generation and workload planning.
Maximise use of resource.
5.2.2.
8
More configurable screens and reports.
Maximise use of resource &
reduce clinical risk.
5.2.3
Clinical Objectives
Benefits
5.2.3.
1
Improve communication between clinicians and other Improved care.
healthcare professionals.
5.2.3.
2
Flagging system to highlight investigations due or to act Improved care & reduce
upon a result, with recording of response. Schedules, clinical risk.
reminders and safety reports.
5.2.3.
3
Electronic prescribing – expand from current capabilities.
Improved care & increase
use of resource.
5.2.3.
4
Wireless systems - near-patient access to lab results.
Improved care & increase
efficiency.
5.2.3.
5
Comprehensive
treatment.
5.2.3.
6
Provision of individualised data for patients to improve Improved care & reduce
patient compliance.
clinical risk.
5.2.3.
7
Automated audit of patient pathway.
5.2.3.
8
Improve access to electronic laboratory and diagnostic Reduce clinical risk.
imaging reporting.
5.2.3.
9
More capturing of real time data.
Maximise use of resource &
reduce clinical risk.
5.2.3.
10
Ease of evaluation of impact of treatment changes.
Reduce clinical risk.
on
paper
up-to-date
records
and
information
Maximise use of resource &
reduce clinical risk.
associated Maximise use of resource.
at
point
of Improved care.
Improved care & reduce
clinical risk.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 20 of 69
6.
SCOPE OF THE REQUIREMENT
The project scope1 is detailed in the sections below in terms of six domains of change:






6.1
Business Processes
Service Organisation
Service Locations
Data
(IT) Applications
Technology
Business Processes
Below is a high level flow diagram intended to indicate the typical major processes employed
by the Renal and Transplant service.
GP referral
Clinic
Consultant
referral
Acute Renal
Emergencies
Chronic Disease
Management Caseload
Discharged
Test /
diagnostics
Renal Replacement
Therapy
Conservative
management
Transplant
Haemodialysis
PD
Continued monitoring and
follow up
6.2
Organisation
The organisational areas of NUH impacted by this initiative span a number of Clinical
Directorates and include the following specialties: Vascular Surgery, Diabetes and
Endocrinology, Renal and Transplant, Urology, Dietetics, Pathology, Pharmacy, Radiology,
Medical Physics, Clinical Engineering, Children and Young People, ICT Services and
finance/commissioning (due to improved activity monitoring).
1
This procurement is part of the overall project ambition and scope described here.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 21 of 69
The scope of changes to the culture, capabilities, roles, team structure and organisational
units of the people and organisations involved in the change are:



6.3
Implementing the changes required to take advantage of the new facilities. This will
include the opportunity to standardise the organisation as there will be an enhanced,
shared Renal Patient Information service.
Defining the training requirements and developing the training approach. In order to
achieve the benefits training will be required to some degree by the majority of staff
across the Renal and Transplant Service, satellite units and the Children’s Renal Unit (see
section 4.7).
It is anticipated that the Supplier will train nominated members of Trust staff trainers
who will then deliver the training to all staff affected by the changes.
Location
The NUH locations impacted by this initiative are where Renal and Transplant services are
delivered or supported and include: Carrel and Bramley Wards, Main Dialysis Unit, Centenary
Wing, Renal Outpatients and CAPD unit all on the City campus, Ward E17 (Children’s renal
ward), nephrology outpatient clinics at KMH and the satellite haemodialysis unit at QMC
campus, KMH and Ilkeston Community Hospital.
6.4
Data
The scope of the changes required to the data content, structure, relationships and business
rules used by the business processes, applications and organisation are2:






6.5
Definition of the data to be cleansed and migrated to the new Renal Information System
(Trust).
Data cleansing and extraction from the existing Proton system (and others, eg
standalone systems). This will include reconciliation and validation of patient records
where appropriate (Joint – Supplier and Trust).
Identification and manual setup of local reference data that cannot be migrated
automatically and agreeing protocols (Trust).
Transformation and loading of the data extracted into the new system including mapping
data (Joint - Supplier and Trust).
Quality assurance of migrated data (Trust).
Testing of migrated data files prior to go-live with the new solution (Joint – Supplier and
Trust).
Applications
The scope of the capabilities, structure and user interface of software application
components used to support the change is:

2
Provision of reference data (extract) for the new Renal patient information solution
(Trust).
The responsible party is shown in parentheses ().
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 22 of 69



6.6
Provision of inbound and outbound interfaces into Java CAPS (Trust integration engine)
with the message content necessary to support the functional requirements set out in
section 8.3 (Joint).
Provision of access to Renal data to enable the NUH Data Warehouse to generate
existing and new reports and support detailed data analysis (Supplier).
Modification of existing in-house developed systems to ensure their continued running
within the context of the modifications to the interface environment (Trust).
Technology
The scope of the hardware, system software and communications infrastructure used to
enable and support the solution includes:






Provision of wireless enabled Local Area Network (LAN) access points in the required
areas (Trust)
Provision of appropriate numbers and types of WiFi devices in the required areas (Trust).
Provision of an additional number of Personal Computers (PCs) and printers in clinical
areas (Trust).
Changes to hardware servers (Trust).
Additional LAN connectivity to dialysis machines etc. (Trust).
If required, enhanced NHS network (N3) and local community (COIN) Wide Area Network
(WAN) services (Trust).
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 23 of 69
7.
TRUST INFRASTRUCTURE AND STANDARDS
7.1
General
7.1.1
This section describes the Trust’s IT environment under the following headings:











7.2
Major Systems
Connecting for Health
Patient Master Index (PMI) and Patient Identifiers
Interfacing Standards
Networking Standards
Wireless Network Standards
Desktop Standards
Printer Standards
Server Standards
Support Standards
Security and Information Governance Standards
Major Systems
The major clinical information systems used by the Trust are listed in the table below. The
schematic immediately below shows a high level view of the connectivity between these
systems. Please also see the schematic in appendix B which shows Trust-wide systems
including the data warehouse solution.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 24 of 69
QMC CAMPUS
Demographics
ADT
Results
Orders
Other
NCH CAMPUS
PACS
CRIS
WinPath
Interface
Manager
Trust Integration
Engine
ORMIS
(QMC)
PAS
CNT
All-in-One
Java CAPS
(formally ICAN)
DataGate
EDIS
HISS/NotIS
CNT
Medical Office
ORMIS
(NCH)
KEYSTONE
EXTERNAL
GP
Systems
Name/Acronym
All-in-One
CAB
CNT
CNT
CRIS
DataGate (aka e-Gate
and SeeBeyond)
EDIS
HISS
SUS/
Clearing
Service
Description
Proprietary word processing and
document storage system linked to
PAS.
Choose and Book. Integrated with
PAS. Supports patient choice agenda.
Case Note Tracking (QMC Campus).
Module of PAS.
Case Note Tracking (NCH Campus).
Module of HISS (Defunct).
Computerised Radiology Information
System.
Trust Integration Engine. Predecessor
to ICAN – legacy system. Everything is
migrating into Java CAPS.
Emergency Department Information
System.
Hospital Information Support System.
Includes inpatient admin at NCH.
Used at QMC and NCH.
Supplier
McKesson
National Application Service Provider
(NASP)
McKesson
In-house
HealthCare Software Systems (HSS)
iSOFT (Stand-alone core product
provided via Accenture)
In-house (originally a joint
development with Oracle. It has a
common user interface and Oracle
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 25 of 69
Interface Manager
Java CAPS (formally
ICAN)
Keystone
Medical Office
NotIS
ORMIS
PACS
PAS
WinPath
Application Programming Interface to
manage message transactions into
and out of PAS – configurable by ICT.
Trust Integration Engine.
Software solution for clinical and
administrative messaging between
laboratories, GPs, PCTs and Secondary
Uses Service (SUS).
Application to create and manage
clinical documents – uses Microsoft
Word for document production and is
linked to both HISS and NotIS.
Nottingham Information System –
essentially a GUI front end to HISS.
Operating Room Management
Information System.
Picture Archiving and Communication
System.
Patient Administration System –
“TotalCare” includes in-patient admin
at QMC and out-patient admin at
QMC and NCH.
Pathology Laboratory Management
System (aka LIMS). Comprises Clinical
Chemistry, Haematology,
Immunology, Blood Transfusion
(Blood Bank), Microbiology and
Cellular Pathology (Gynae, Non
Gynae) and Histopathology. WinPath
is also used by KMH although this is
no longer part of the NUH system.
back-end)
McKesson
Oracle
Indigo4
In-house
In-house
iSOFT (Stand-alone core product
provided via Accenture)
Agfa (Core service provided via
Accenture)
McKesson
CliniSys
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 26 of 69
7.3
Connecting for Health (CfH)
7.3.1
In principle, the Trust is committed to CfH. However, the Trust is awaiting the successful
conclusion of the LSP Early Adopter programme before committing to an implementation
date for the LSP Electronic Care Record system, Lorenzo.
7.3.2
The Trust’s PAS is Choose and Book (CAB) compliant, and CAB is being implemented across
Trust services.
7.3.3
The Trust has implemented the Computerised Radiology Information System (CRIS) from
Accenture/HSS and the Picture Archiving and Communication System (PACS) from
Accenture/Agfa.
7.3.4
The Trust is actively building the required CfH infrastructure in terms of Single Sign-On etc.
Potential suppliers will be required to conform to this.
7.3.5
Suppliers may be required to complete an online questionnaire demonstrating they meet
NHS Information Boards Standards and they will be contacted at a later date with details.
7.4
Patient Master Index (PMI) and Patient Identifiers
The McKesson PAS system automatically generates a K (Korner) number for each patient that
is registered on the system. Registrations can come in through a variety of routes eg
electronically via CAB or EDIS, or manually, eg via letter or telephone, and entered by clerical
staff. The K number is a unique identifier that is held on the Trust’s shared PMI and used by
both campuses. It is the primary identifier used in interface messages with, for example, the
Pathology System.
For paper casenotes the QMC campus mainly uses S (South) numbers as a casenote identifier
and for casenote tracking; the NCH uses N (North) numbers for its casenotes for similar
purposes and casenote tracking is done using PAS.
Additionally, there are a number of departmental casenote numbers that can be assigned to
patients, depending on departmental systems and processes (eg Eye casualty, Radiotherapy,
etc.), and these are manually recorded on PAS as additional identifiers.
All patient demographic changes are entered directly onto PAS. The departmental systems
cannot update the PAS PMI using interface messages ie PAS PMI is ‘master’, all departmental
system patient indexes are ‘slaves’.
It is suggested that the K number is the primary key but patients must be searchable on NHS,
South, North, Eye Casualty and Radiology numbers. The Nottingham DTC (Treatment Centre)
will also have a requirement for searching against a T number.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 27 of 69
7.5
Interfacing Standards
7.5.1
The Trust uses a Sun Java CAPS integration engine. This environment is used to provide
interfaces between applications for all new developments and also provides interfaces to
departmental applications. Implementation of point to point interfaces is discouraged.
7.5.2
The Trust expects new developments to use the HL7 V2 interface messaging standard.
However, many of the existing interfaces do not use HL7. The Trust would be able,
pragmatically, to consider interfacing standards other than HL7 if necessary.
7.6
Networking Standards
7.6.1
The Trust’s network is based largely round the use of Cisco components in a ‘3-tier topology’
deployment of core, distribution and access layers. The core network consists of resilient
meshed rings of Cisco 6500 series layer 3 switches. The distribution layer consists of Cisco
4500/3750 series layer 3 switches and the edge devices which are mainly Cisco 3750 devices
which are Power over Ethernet (PoE) enabled. Migration to a full Cisco converged network is
in progress. The edge switches are mainly 100 Mb/s to the desktop but 1Gb/s is also
supported where necessary. The Trust is over time implementing resilient links to the edge
switches by the use of geographically separated diverse links from the edge device to the
distribution layer. Priority is being given to critical areas such as imaging or laboratories. The
Trust’s data centres have Cisco 4900 data centre switches and server connection speeds of
10/100/1000/10,000 Mb/s are supported.
7.6.2
The Trust has two main campuses. Within each campus, buildings are linked together with
private optical and copper (Cat 5e/6) cables and the 10Gb/s backbone network structure.
There are two geographically separated leased gigabit data circuits between the two main
campuses. In addition to this a 100Mb/s Community of Interest Network (COIN) is deployed
as a dual resilient ring to other healthcare organisations in the Nottinghamshire region.
7.6.3
The Trust has adopted a client/server deployment model. Servers or server clusters for
critical applications such as imaging, PAS systems or laboratory systems can either be
physical or virtual. These servers or clusters are housed in one of the Trusts data-centres for
use by all clients in the Trust. In some cases, the backup server for an application is housed
at the opposite site.
7.6.4
There are no cross site fibre channel circuits but the Trust is now replicating cross-town with
the use of Internet Small Computer System Interface (iSCSI) based Storage Area Networks
(SANs). The Ethernet cross site bandwidth is adequate to support specific implementations
of cross-site replication but care is needed with the associated design. There are large SAN
environments on both campuses. Future strategy includes the implementation of full
replication between these environments.
7.6.5
The Trust has two dedicated computer rooms on each campus. Single-mode and multi-mode
fibre optic cables are available between the computer rooms and Disaster Recovery (DR)
rooms on a given campus. Hence the use of these different computer rooms is arranged
wherever possible to provide resilience.
7.6.6
The Trust’s data network has two connections to the NHS private network “N3”. Inbound
and outbound data flow between the Trust network and N3 is controlled by a firewall.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 28 of 69
Network Address Translation (NAT) is used at this firewall. The Trust also has a direct
Internet connection that is controlled to the standards required in association with N3.
Internet remote access requires the use of strong authentication tokens. Internet remote
access is usually provided via Cisco ASA and Citrix technologies and a full ‘fat-client’ Virtual
Private Network (VPN) link will not normally be provided.
7.7
Wireless Network Standards
7.7.1
This procurement does not involve wireless network related hardware. However, it is
anticipated that mobile devices such as laptops, tablets, Mobile Clinical Assistants (MCAs) or
smartphones/Personal Digital Assistants (PDAs) may be used in association with the Renal
Information System. The following information is provided to give the background.
7.7.2
The Trust has strategy to implement a comprehensive wireless networking infrastructure. At
present, the trust is approaching the end of a 2 year, Trust-wide deployment of an
802.11a/b/g network based on Cisco Aironet access points via PoE. The access points are
configured to support roaming voice and data site-wide and Radio Frequency Identification
Device (RFID) tracking to 10m (triangulated) in certain areas. Cisco security including Cisco
Network Admission Control (NAC) is deployed.
7.7.3
The Trust is not at present using RFID technology, but RFID tracking will be implemented as
part of the Trust-wide wireless network. All existing tracking systems use bar code
technology.
7.8
Desktop Standards
7.8.1
NUH has over 7,000 desktops connected to a Microsoft Windows Active Directory enabled
LAN. Brief current specification is:






(Minimum) Intel P4 2.8Ghz processor
2 Gb RAM
80Gb HDD
Optical mouse
Smart card reader keyboard
17" TFT flat screen monitor.
7.8.2
The Trust deploys a standard XP desktop image, which the majority (over 90%) are Windows
XP Service Pack 3. Microsoft Vista is not being considered at present but future plans include
the deployment of Windows 7. Standard desktop software is Microsoft Office 2003, Internet
Explorer version 7, Microsoft Outlook 2003, LANdesk and Sophos anti-virus, which is about to
change to Kapersky.
7.8.3
All new desktops are ‘cloned’ using standard images. Microsoft Operating System updates
and service packs are automatically deployed to desktops via Windows Server Update
Services (WSUS). Client software for specific applications is remotely installed using LANdesk.
7.8.4
The Trust is evaluating a future desktop PC strategy based on the concept of a “virtual
desktop” environment using a combination of thin client technology and application
provision via VMware Virtual Desktop Infrastructure (VMview).
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 29 of 69
7.8.5
The following table provides a list of Trust requirements for client software:
Software
Operating System
Must be supported
Windows XP Service Pack 3
Windows 7 Professional
Windows Server 2008 R2
Remote Desktop Services
Web Browser
Microsoft Internet Explorer
7.0 and above
Silent
LANdesk
Microsoft Office 2003
Service Pack 3 and above
Support new version of
Windows within 1 year of
release
Installation process
Deployment
Microsoft Office
Future Windows Upgrade
Should be supported
Microsoft Virtual Desktop
Infrastructure (VDI)
VMware view
VMware Thinapp
Citrix XenApp
Same
MSI
Microsoft App-V 4.6
Microsoft Office 2010
Support new version of
Windows with 6 months
7.9
Printer Standards
7.9.1
The Trust has a contract with Ricoh to provide a managed service in relation to standard
printers used in the Trust. This contract includes the provision of Ricoh workgroup
multifunction printer/copiers. Ricoh do not support special purpose printers such as barcode
label printers or printers connected to laboratory or medical devices. All printers should be
TCP/IP ready and have remote management capability.
7.9.2
The Trust uses Windows, Virtual Memory System (VMS) and Linux (Redhat) based Print
Servers where appropriate.
7.10
Server Standards
7.10.1 Most of the Trust IT systems run under the Windows operating system. UNIX/Linux and
OpenVMS are also present.
7.10.2 All Windows Servers are incorporated into a Trust-wide Active Directory environment. This
Active Directory environment is the default environment for controlling user access to
networked PCs and Windows based applications.
7.10.3 The Trust uses VMware for all new Windows Server installations. Multiple VMware datacentres exist, each providing load-balancing and high-availability features, such as VMotion
and Storage VMotion.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 30 of 69
7.10.4 The Trust has found that it is no longer practicable to support the concept of implementing a
dedicated Windows Server environment for each application or for each system Supplier.
The Trust expects that all new software applications should be capable of running in a shared
environment. The Trust expects that new applications will use the shared Microsoft SQL
Server, Internet Information Services (IIS) and file-storage environments. The Trust may
choose to reject any proposal to implement a system that would not be fully supported by
the supplier when run under the Trust’s VMware environment.
7.10.5 Where a “Training Environment” is implemented, then the Trust expects this to be capable of
running on the same server environment as the “Live Environment”. The Trust implements
separate shared virtual servers for “Test Environments” and the Trust expects that Test
Environments can be easily re-installed as required.
7.10.6 The Trust uses Microsoft SQL Server for most database applications. Individual applications
are assigned to one or more of the shared SQL database environments. Full SQL Server
environment administration rights are not provided to suppliers. The Trust is unable to
support any database environment other than Microsoft SQL Server and the Trust may
choose to reject any proposal to implement a system that uses a database other than
Microsoft SQL Server.
7.10.7 The Trust uses Symantec, EMC and VMware products for data management, including
backup and recovery. This software will be installed on servers as appropriate. No other
backup and recovery software will be permitted. The Trust undertakes standard daily
backups and stores a number of copies enabling recovery from multiple points in time.
7.10.8 Remote access to specific server environments is normally provided via the use of Microsoft
Terminal Services and Remote Desktop Protocol. The Trust expects that applications should
be supported via the NHS private network “N3”. The Trust also uses Internet based remote
access VPN links that require the use of strong authentication tokens for ‘anytime’ access.
Pre-arranged Webex sessions can be arranged within office hours for hosted remote support
sessions but suppliers would be expected to provide reasons why N3 could not be used in
the first instance.
7.10.9 The Trust will normally endeavour to apply critical patches to both shared and dedicated
platforms within one month of release, following suitable testing in a test environment. The
Trust will also endeavour to apply service packs to the same platforms within six months of
release, following suitable testing in a test environment. Suppliers will be expected to
support all such patches and service packs within the above timescales in order for the Trust
to maintain the security and stability of all desktop clients and shared environments.
7.10.10 In order to guarantee the availability of security hot-fixes, suppliers must ensure their system
is capable of operating correctly on a platform which is current and supported. For Microsoft
products this requires operating system and applications, such as SQL Server, to be within
Microsoft’s mainstream of extended supported phases
.
7.10.11 The following table provides a list of Trust requirements for software installed in a Server
environment:
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 31 of 69
Software
Operating System
7.11
Must be supported
Windows Server 2008
x64/x86 Service Pack 2
Should be supported
Windows Server 2008 R2
(x64)
Support Standards
7.11.1 The NHS has adopted Information Technology Infrastructure Library (ITIL) as the De Facto
standard for Service Management, and suppliers working under CfH are working towards
achieving BS15000 (ISO20000).
7.11.2 The Trust has embedded Service Management principles into the IT support infrastructure
through the use of the ITIL framework.
7.11.3 Landesk Service Desk is the toolset used to record and monitor incidents from identification
through to closure. Landesk is also used to remotely manage clients.
7.11.4 Support for Trust corporate systems is provided by the IT Services Service Desk which is the
first point of contact for all incidents and requests associated with these systems. The
Service Desk is responsible for the recording and classification of incidents and will perform
an initial triage to establish as much detail as possible eg symptoms, impact etc.
7.11.5 If the incident cannot be resolved locally then it is passed to one of the second line support
teams eg Desktop or Network Support. Incidents that cannot be resolved at the second line
are passed to the more advanced technical support groups. The Service Desk Manager has
access to Landesk Service Desk to manage and track incidents.
7.11.6 The Trust will expect the Supplier to develop a support contract to underpin the service to
the end user that builds on the ICT services offered locally. Within the support contract ICT
Services and the user department will work with the Supplier to develop a detailed Service
Level Agreement (SLA) with Key Performance Indicators to ensure that the support service is
robust and meets the needs of the users and ICT. This will be finalised during the
implementation stage and be available to all parties at the time the application goes live.
7.11.7 The IT Service Desk is currently open between the hours of 8:00am to 8:00pm Monday to
Friday. Outside these times an on-call service is available for urgent incidents affecting
critical services.
7.12
Security and Information Governance Standards 3
7.12.1 The Trust expects Information Security standards associated with systems used in the Trust
to be compliant with the controls detailed in ISO/IEC 27001:2005 and conform to the Code of
Practice as detailed in ISO/IEC27002.
7.12.2 The Trust expects systems used in the Trust be compliant with the Information Governance
Assurance Framework (IGAF) security accreditation, information quality and confidentiality
and data protection requirements (this includes undertaking privacy impact assessments for
new systems). Where data encryption is required, then Advanced Encryption Standard (AES)
3
Ref: Nottingham University Hospitals - Information Governance Assurance Framework Strategy
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 32 of 69
256 bit encryption compliant with Federal Information Processing Standard (FIPS) 140-2 must
be used.
7.12.3 The Trust expects systems used in the Trust to conform to the British Standards Institute
(BSI) Code of Practice for Legal Admissibility and Evidential Weight of Linking Electronic
Identity to Documents.
7.12.4 There are appropriate procedures for retrieving and reproducing personal data and
responding to individuals’ requests for access to their personal data.
7.12.5 Audit procedures are in place to monitor and report access to confidential personal
information.
7.12.6 The confidentiality of service user information is protected through use of pseudonymisation
and anonymisation techniques where appropriate.
7.12.7 The Trust is currently implementing an NUH-wide Single Sign On (SSO) solution, Imprivata
One-Sign, that will enable staff, once they have logged onto the network, to log onto the
additional systems that they use without the need to type in their user names and
passwords. An additional SSO feature that is being considered is the use of biometric devices,
eg fingerprint readers, as a productivity aid.
7.12.8 All Trust laptops have installed the “Safeend Encyptor” installed together with “Safeend
Protector” to prevent sensitive data being lost from unencrypted removeable storage
devices.
7.12.9 The Trust uses the Webmarshall M86 product to stop data leakage from the desktop device
via the browser and so prevent transmission of sensitive data via hotmail or similar services.
7.12.10 The Trust has implemented a single Trust-wide Microsoft Active Directory environment. This
environment is the default environment for controlling user access to networked PCs and
Windows-based applications.
7.12.11 The Trust has implemented departmental and functional groups within Active Directory. The
Trust expects that applications should use Active Directory groups wherever possible.
7.12.12 The Trust has implemented CfH applications such as Picture Archiving and Communications
System (PACS). User access to these national applications is controlled by NHS smartcards.
Operating and application information systems (under the organisation’s control) support
appropriate access control functionality and documented and managed access rights are in
place for all users of these systems.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 33 of 69
SECTION C - TRUST’S DETAILED REQUIREMENTS
8.
FUNCTIONAL REQUIREMENTS
8.1
Overview
8.1.1
Suppliers MUST provide an overview of the proposed solution, including:
 The name of the proposed solution.
 A brief history of the origin, development, marketing and future plans for the solution.
 A brief description of the hardware, software and communications environment in
which the solution operates.
 A full list of existing users with contracts for the proposed solution.
The proposed solution MUST comply with all relevant requirements described in the BSI
Code of Practice for Legal Admissibility and Evidential Weight of Linking Electronic Identity
to Documents.
8.1.2
8.2
System Look and Feel
8.2.1
SHOULD be consistent across all modules and functions with regard to screen design, and
the use of keyboard strokes and mouse clicks.
SHOULD enable access to functions via navigation through a structured menu and SHOULD
also allow shortcuts to commonly used functions.
SHOULD minimise the need for repeated data entry by retention of context data, such as a
patient's identifying details, for re-use at a higher level when a lower level function has been
invoked and completed.
MUST operate with UK terminology, characters, date and time formats etc.
The Trust, as an equal opportunities employer, employs individuals with disabilities.
Suppliers MUST give outline details showing how a range of disabled personnel can access
the system.
MUST include keyboard shortcuts which allow users to navigate around quickly.
SHOULD show a graphical timeline of key events and diagnoses.
SHOULD allow configuration of data according to individual user requirements ie
haemodialysis nurses can access a haemodialysis screen with one click and transplant staff
can access transplant screens with one click and so on.
The details of the patient selected MUST be visible whatever screen you are accessing. This
MUST include surname, forenames, hospital number, verified NHS number and date of birth.
8.2.2
8.2.3
8.2.4
8.2.5
8.2.6
8.2.7
8.2.8
8.2.9
8.3
Information Flows and Interfaces
The new Renal system must replicate all the interfaces that exist between Proton and the
Trust systems. Some new or improved interfaces are planned at the time of implementation
of the system. Other future interfaces are envisaged but it may not be possible to have them
in place when the system goes live. Where possible these interfaces should be included in
the system planning.
It is necessary for the Renal system to acquire data from other Trust systems. The Trust’s
preference is for the data to be captured from the most appropriate system. The diagram
below shows the anticipated movement of data and system access required to support the
clinical and business processes.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 34 of 69
“TO BE” Renal Information Flows v 0.3
External users
External Registries
International
Registries
NUH Home
worker
Via login access
Patients
via
( Renal Patient
View)
Via electronic messaging
Via database access
K – renalview
daily feed
UK Renal Registry
C - Login
access
(Renal)
A – Renal registry
Data extract
NUH based Renal and Transplant Service
D – Patient
Activity data
NUH managed systems
NotIS
Electronic orders
E–
electronic
orders
City campus
Ilkeston
QMC campus
Renal Clinics
King’s Mill
G – electronic
results
Theatres
(ORMIS)
ICAN
L–
demographics
N - Theatres
data
Pharmacy
(ASCRIBE)
Joint Clinics
(paed and
young adult)
F – Login access
(Renal)
Dialysis Units
QMC
(Diaverum)
Renal System
H – Instrument
Feeds (1)
Weight & BP
measurements
Centenary
Wing
O - Pharmacy
data
I – Instrument
Feeds (2)
PACS
(Agfa/Accenture)
NUH Satellite
Haemodialysis Units
Inpatient
Wards
Pathology
(Winpath)
Radiology
(HSS)
Contracting/
Commissioning
systems
QUIZ (NUH data
Warehouse)
UK Transplant
Dialysis Machines
McKesson PAS
J – login access
To Medical Office
Community Services
Peritoneal Dialysis
Systems
M – Peritoneal Dialysis
Medical Office
(WebHISS)
MB
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 35 of 69
27/06/2011
8.3.1
Interface A - Renal Registry Data Extract
8.3.1.1 MUST provide quarterly, all required data to the UK Renal registry
http://www.renalreg.com.
8.3.1.2 MUST collect, store and extract all information required for compliance with the National
Renal Dataset.
8.3.1.3 MUST provide assurance of future compliance with all mandatory elements of the
National Renal Dataset introduced during the life of the service contract. Such compliance
MUST be achieved at no extra cost beyond the Supplier’s annual software support charge.
8.3.2
Interface K – Feed to “Renal PatientView” system
8.3.2.1 MUST interface with the Renal PatientView system to enable patients to see letters,
results, drugs and demographic information within Renal PatientView.
8.3.3
Interface L – Patient Demographics
8.3.3.1 MUST have an interface “with JCAPS" or "with TIE" - TIE = Trust Integration Engine, JCAPS
has replaced ICAN in order to ascertain patient demographics for PMI. This interface
MUST include a Query-Response option in order to register new patients into the
application.
8.3.3.2 SHOULD include an inbound trickle-feed of demographic updates for patients registered
on the Renal Information System.
8.3.4
Interface D – Patient Activity Information
8.3.4.1 Currently patient activity information, eg patient hospital attendances for haemodialysis
treatment, is recorded both on Proton (to form part of the clinical record) and also on PAS
in order to compile activity and contracting data for commissioners. The Trust is seeking to
eliminate this dual entry process by creating an interface between the new Renal IT
System and the Trust’s data warehouse.
8.3.4.2 The Supplier MUST confirm that they will provide a copy of their system's data dictionary
and read-only access to all of the underlying data structures. This will enable the Trust to
populate the Trust’s data warehouse with the required patient activity data. The Supplier
MUST support the Trust in transferring data to the Trust’s data warehouse.
8.3.4.3 The Supplier MUST confirm that any changes to the system's data dictionary and/or
underlying data structures as part of future releases will be communicated to the Trust in
a timely manner, to enable the Trust to prepare corresponding changes to its ETL (Extract,
Transform, and Load) routines and the data warehouse data structures.
8.3.5
Interface E – Electronic Orders (Pathology and Imaging)
8.3.5.1 This interface is not relevant as part of this procurement process as the Trust do not intend
to use the Renal Information System for electronic orders.
8.3.6
Interface G – Electronic Results
8.3.6.1 MUST provide at least the same functionality as the existing interface with WinPath as
described in section 4.6.3.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 36 of 69
8.3.6.2 MUST be able to accept and to present to the user:
- Reports in their entirety (including all comments in both textual and numerical form note that comments may be at the level of samples, profiles and tests);
- Amended reports;
- Supplementary reports;
- Provisional reports (unstructured);
- Units for each result. Also it must be possible to store a reference range for each
result;
- Purely textual reports – as for much of Microbiology or Histology.
8.3.6.3 It MUST be possible in the future to configure the inbound results interface to allow
transfer of additional types of results, eg Cardiology etc.
8.3.6.4 Some lab results contain partially tabulated data (eg microbiology results). The system
MUST be able to import and display such results correctly.
8.3.6.5 SHOULD automatically pull historical laboratory data from, for example, the laboratory
interface into the new system for new patients. The Supplier SHOULD give details of how
this has been achieved with other installations.
8.3.6.6 On patient registration the system MUST be able to accept and present to the user all
relevant historical pathology results.
8.3.7
Interface C – External Login Access to the Renal System
8.3.7.1 NUH staff working from home SHOULD be able to gain secure full system access, ie the
same level of access as provided from their normal place of work.
8.3.8
Interface F – Login Access to the Renal System (NUH and Satellite Units)
a. By campus based renal and transplant staff (including wards and clinics)
b. By staff at NUH satellite units:
-
Centenary Wing (NCH)
Ilkeston Community Hospital
King’s Mill Hospital (Mansfield)
QMC - currently operated by Diaverum UK Ltd
8.3.8.1 MUST provide remote full system access to all Renal staff working at all Trust Renal and
Transplant facilities (both campus-based and satellite units).
8.3.8.2 The Supplier MUST be capable of developing interfaces to renal systems in place at any
new NUH satellite dialysis units that open in the future (regardless of whether these units
are provided by the NHS or the independent sector).
8.3.9
Interface J – Login Access to Medical Office
The Trust currently uses an in-house developed and supported product, “Medical Office” for
the generation, storage and access of clinical documents and correspondence currently
produced using NotIS.
8.3.9.1 MUST be able to view clinical documents and correspondence stored within Medical
Office via the Renal Information System.
8.3.9.2 MUST be able to export clinical documents and correspondence generated within the
Renal system to Medical Office.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 37 of 69
8.3.10 Interface H – Instrument Feeds (1)
a. From weight and
b. From blood pressure measurement devices
8.3.10.1 SHOULD be capable of capturing data from suitable configured weighing scales in the
haemodialysis treatment areas of all dialysis units to enable electronic recording of preand post-dialysis weights.
8.3.10.2 SHOULD be capable of capturing data from suitable configured electronic blood pressure
measurement devices whether these are freestanding or integrated into haemodialysis
machines.
8.3.11 Interface I – Instrument Feeds (2)
From haemodialysis machines
8.3.11.1 MUST be capable of interfacing with the haemodialysis machines, automatically entering
the session time and fluid removal. The interface MUST also capture and store all the data
from the dialysis sessions (eg machine number, blood volume processed, ultrafiltration
volume, blood pressure, online clearance etc.).
8.3.12 Handheld Wireless Input Devices
8.3.12.1 SHOULD be able to interface with handheld wireless input devices ie PDA, Tablet PC. These
devices MUST be supported with the necessary software.
8.3.13 Interface M – Peritoneal Dialysis Systems
8.3.13.1 The solution SHOULD interface with the peritoneal dialysis database system (described in
more detail in appendix A). Alternatively, suppliers SHOULD offer a solution that
replicates all elements of the existing system and makes it redundant.
8.3.14 Interface N – ORMIS
8.3.14.1 SHOULD support the capture from ORMIS (Theatre Management system) of operative
procedures and related details for audit purposes and compliance with the National Renal
Dataset.
8.4
Interfacing
8.4.1
The Supplier’s offering MUST be compatible with the Trust’s interfacing standards described
in section 7.5.
Suppliers MUST carefully explain what interfacing is included in their offering and MUST
explain their approach to the configuration and testing of required interfaces.
Suppliers MUST explain their expectations of the Trust’s responsibilities in relation to the
provision and testing of interfaces.
MUST have a mechanism for validating incoming data from an interface prior to it being
loaded to the Renal Information System. The System Administrator MUST be provided with
8.4.2
8.4.3
8.4.4
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 38 of 69
8.4.8
sufficient information to enable investigations of failed record loads to be completed.
MUST be able to correct rejected input and be able to re-submit input to the database after
corrective action has been performed.
MUST have a way of informing the System Administrator or “super-user” group when the
proposed interfaces are not operational.
MUST ensure that when interfaces are re-activated, the Renal Information System will handle
retrospective interface file feeds in a controlled and strictly chronological manner.
MUST have intuitive screens for the manual entry of data if interfaces fail.
8.5
Data Extracts
8.4.5
8.4.6
8.4.7
The Trust requires a system that can act as the data source for a number of data submissions
to various national and local bodies. The known data submissions are listed below. The Trust
requires a facility for setting up further data extracts as the need arises.
8.5.1
8.5.2
8.5.3
8.5.4
8.5.5
8.5.6
8.5.7
8.5.8
8.5.9
8.5.10
8.6
MUST provide all required data to the UK Renal registry www.renalreg.com (see
requirements in section 8.3.1).
MUST provide transplant information to the NHSBT (Bristol) system.
MUST provide daily data to Renal PatientView www.renalpatientview.org.
MUST provide an extract of data in support of the National Renal Dataset as well as being
fully compliant http://www.isb.nhs.uk/docs/national-renal/.
MUST provide data extract for the CQUIN standards and MUST be configurable to allow
storage of local codes to support this. Please see
http://www.dh.gov.uk/en/Publicationsandstatistics/Publications/PublicationsPolicyAndGuid
ance/DH_091443 for further details about CQUIN standards.
MUST provide a flexible data extract facility, enabling the Trust to add new extracts and alter
existing extracts without Supplier input eg extract data for research or commissioning.
MUST provide a means of scheduling data extracts which is under Trust control.
MUST demonstrate ability to extract data in a range of formats, however, the standards
described in section 7.5 should be noted.
MUST comply with the applicable current and future standards from the Department of
Health Information Standards Board for Health and Social Care (ISBs)
http://www.isb.nhs.uk/use/index_html.
The Supplier MUST provide the capability for the anonymisation and pseudoanonymisation
of service user information when it is extracted or exchanged for non-healthcare related
reporting purposes, eg Secondary Uses Services (SUS).
Information Reporting and Analysis
The supplied system MUST provide users with standard customisable reports fitting the
needs of local Clinicians and Managers as well as the Trust’s requirements and those of
external agencies/partners. The requirements include but are not limited to the following:
8.6.1
8.6.2
8.6.3
MUST provide activity data in support of the Trust’s administration, auditing and financial
billing activities. These reports should contain details of procedures, admissions, transplants
and dialysis sessions as specified by the Trust.
MUST provide facilities to allow any data item recorded in the system to be used for
reporting or to be extracted for external storage and analysis.
The above reporting and extracting MUST also be possible for any data items resulting from
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 39 of 69
8.6.4
8.6.5
8.6.6
8.6.7
8.6.8
8.6.9
8.6.10
8.6.11
8.6.12
8.6.13
8.6.14
8.6.15
local tailoring of the system.
There MUST be the ability to “clone” and customise standard reports.
There MUST be a facility for “super-users” to develop on screen and custom reports which
appear as an integral component of the application.
The solution MUST make every data item in the system available for use in screens and
reports.
There MUST be support for graphical presentation of information.
MUST incorporate the generation of outputs suitable for inclusion in medical case notes.
MUST provide a means of holding local code structures which map to national code
structures.
Some fields will be text based; ie relatively large quantities of free-form text such as a
radiology or microbiology report. The system MUST ensure that when text based fields are
used in reports (either printed or displayed on screen) the report formatting is preserved.
SHOULD be capable of producing Statistical Process Control Charts.
MUST be able to provide an audit trail of any data item in the system.
MUST be able to provide summary reports for clinics and Multi-disciplinary Teams (MDT’s).
MUST be able to provide a list of patients overdue for screening/testing eg patients whose
blood borne virus screening results are out of date.
MUST be able to provide a list of patients whose results are out of range as well as allowing
users to specify other out of range parameters locally.
8.7
Printed Output
8.7.1
8.7.2
8.7.3
8.7.4
8.7.5
Reports MUST be able to output to a printer.
The reports MUST use a default printer and allow the user to select a different printer.
Reports MUST be available for preview on screen with the option to print.
All printed output MUST include the date and time printed and page numbering.
The user MUST be given the option to specify the number of copies required with a default of 1
copy.
All printed output SHOULD include a reference number linking it with the system function
triggering its production.
SHOULD enable further ad hoc analysis and reporting using SQL or third party reporting tools.
All patient specific printed output MUST include the patients name, date of birth, hospital
number and verified NHS number.
8.7.6
8.7.7
8.7.8
8.8
Reference Tables
8.8.1
It is important for the Trust to maintain consistency of coding standards among corporate
systems for common reference data, such as Specialties, Consultants, Wards and other
Locations, and to minimise the volume of reference data that needs to be manually
re-keyed. The Supplier MUST supply details of any such data files and items where it would
be advantageous for them to be loaded electronically, subject to feasibility and agreement
of a detailed specification, together with any constraints that would apply.
MUST allow for the use of national coding standards where they exist, but SHOULD also
allow locally defined codes to be used where appropriate. However, any outputs from the
System MUST comply with national coding standards as documented in the NHS Data
Dictionary, NHS Information Standards Notices (ISN’s), and other similar official
publications. Such compliance MUST be achieved at no extra cost beyond the Supplier’s
8.8.2
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 40 of 69
8.8.3
8.8.4
8.8.5
8.8.6
8.8.7
annual software support charge.
MUST provide the ability to display and select from sorted lists of reference codes and
descriptions to support users in data entry.
SHOULD allow rapid access to such coded tables through indexing and partial entry (eg
entering first few characters of required item and possible matches being displayed).
MUST provide system management facilities for viewing and printing reference data files
and SHOULD allow flexibility in selection of data, sequence and format when viewing or
reporting.
MUST allow electronic loading of reference data files (eg local ward list, DoH current drug
list) as an alternative to manual data input where such data is either published as a national
resource or is already available within the Trust.
MUST be able to hide old reference data values so they are not accessible in validation lists
for example, but still store them persistently so that they can be accessed for
auditing/reporting.
8.9
Dates and Times
8.9.1
MUST allow recording, processing, display and printing of dates in the 19th, 20th and 21st
centuries without ambiguity as to the century, while imposing the minimum overhead for
data entry.
MUST record the current date and time from a central clock for the whole System, not from
clocks on individual PCs.
SHOULD allow default recording of the current date to "today" and time to "now" for
activities which are normally performed on-line. However, the System MUST also allow this
default date and time to be overridden manually for retrospective data entry.
SHOULD also provide a general short-hand function for recording of the current date and the
current time and for recording dates and times relative to "today" and "now".
8.9.2
8.9.3
8.9.4
8.10
Online Help and Validation
8.10.1 SHOULD provide extensive online help functions, both in context and as an indexed help
facility.
8.10.2 MUST ensure that all data entry is of the correct format, length and cross-data item
compatibility - displaying a meaningful error message if not.
8.10.3 MUST ensure that clinically important data items are subject to further validation checks for
range, and SHOULD display a meaningful warning message where data entered is valid, but
outside of a normal range.
8.10.4 MUST allow manual entry and override of captured data by other methods ie correcting an
erroneous weight.
8.11
Deleting and Merging Records
8.11.1 MUST describe how the system handles record merging and deletion of erroneous records.
This description MUST include details of facilities for appropriately trained users to merge
records and details of manual or automatic procedures to reconcile conflicting data items.
8.11.2 MUST be able to store PAS Merge and Delete messages in a quarantine area for System
Manager intervention. The Supplier MUST describe how PAS Merge and Delete messages
are processed.
8.11.3 The system MUST provide an auditable trail of deletions, merges and changes sufficient to
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 41 of 69
comply with the BSI Code of Practice for Legal Admissibility of Evidence.
8.12
8.12.1
8.12.2
8.12.3
8.12.4
8.13
8.13.1
8.13.2
8.13.3
8.13.4
8.13.5
8.13.6
8.13.7
8.13.8
8.13.9
8.13.10
8.13.11
8.13.12
8.13.13
8.13.14
8.13.15
Patient Demographics
It MUST be possible to record the demographic history of patients records, eg previous
names, addresses etc.
SHOULD record and permit searching on aliases.
It MUST be possible to search for a patient from a number of known values, eg hospital
number, name, NHS number, sex, date of birth, post code etc.
It MUST provide a warning that there is more than one patient known to the service with
the same name.
General Clinical Records
Data MUST be entered on forms whose content and layout can be specified by clinical
users.
MUST allow clinical data to be linked together (eg to indicate that a blood pressure was
taken during a procedure which was performed during an admission).
The history of all changes MUST be maintained so that a record can be viewed as it
appeared at a previous date (eg previous surname and status) and are accessible by the
user.
The current date and time and users electronic signature MUST be attached to all changes
and MUST be auditable.
All important data related to a specific event (eg procedure, admission, clinic visit) MUST
be visible together even if entered on different forms.
MUST allow data entry on fields to be marked as mandatory to ensure that they are
completed on the form.
It MUST be possible for the System Manager to configure fields for specific users/user
groups so that they can be stopped from changing specific data items.
Validation on data entry (eg not allowing systolic blood pressure over 260) MUST be
added easily and initially set up in accordance with NUH clinical requirements as part of
system implementation.
Clinical staff MUST be able to design new data entry forms and edit existing data entry
forms dependent upon local needs. It MUST be possible for the data entry forms to be
configured to accept numbers, dates, free text and selections from lists.
MUST be capable of recording the date and the details of telephone calls related to
patient care.
MUST record current diagnoses for each patient.
SHOULD allow images to be scanned in/saved eg exit site pictures, ECG’s etc. These
images SHOULD then be easy to find and access.
MUST record details about the patients’ transport provider and record all hospital
transport episodes and future bookings. MUST be able to produce a printed or email
report of a transport request.
MUST be able to generate automatic report to transport provider in event of patient’s
death or hospital admission.
MUST have a clinical timeline for each patient, consisting of an event date, the event
chosen from pick list (diagnosis, operation, other event – chosen by search on keyword
or partial keyword) and an attached field for free-text. Some of these events SHOULD
appear on the graphical timeline.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 42 of 69
8.13.16
8.13.17
8.14
8.14.1
8.14.2
8.14.3
8.14.4
8.14.5
8.15
8.15.1
8.15.2
8.15.3
8.15.4
8.15.5
8.15.6
8.15.7
8.15.8
8.15.9
8.15.10
8.15.11
8.16
MUST record date and type of MDT meeting and patient Annual Review; eg
haemodialysis MDT, transplant annual review. MUST record free-text and outcome
which can be incorporated into a letter to the GP.
SHOULD record details about patients with limited mobility, limited use of English
language and patients who are unlikely to have the capacity to give informed consent.
Care Plan/Nursing Record
MUST provide structured support for care plans.
MUST allow problem-oriented care-plans.
MUST produce reports of patients assigned to a named nurse.
MUST produce reports of due/overdue assessments.
Clinical staff MUST be able to design new care plans and edit existing care plans.
Pathway/Protocol Management
SHOULD provide structured support for protocols or clinical pathways.
MUST issue reminders when a pathway event is due (eg scheduled treatments,
investigation or review) and support national guidelines.
Patients MUST be able to be assigned to more than one concurrent pathway.
The pathway SHOULD include decision support rules (eg bone management algorithm).
Clinical staff MUST be able to design new pathways and edit existing pathways.
Any list of due events for a patient SHOULD include information that indicates which
pathway and rules are informing the events.
The steps which make up the pathway and any rules informing the decision support
SHOULD be easily visible to the user.
SHOULD allow scheduling of blood tests due, depending on the patient’s clinical status.
MUST clearly show screening eg MRSA, HBV serology.
MUST allow recording of infection status (eg MRSA, HIV, Hepatitis B).
SHOULD alert users to any pathways, protocols and procedures etc. that have specified
review dates within the system.
Electronic Prescribing
The Trust is in the preliminary stages of developing an investment proposal and specification
for a Trust-wide e-prescribing solution. The overall e-prescribing strategy which will consider
the role of specialist prescribing systems, including the existing Chemocare chemotherapy
drugs prescribing system, will be part of the strategic case within the investment proposal.
Responses to this section should be considered in the light of the Trust’s current position.
8.16.1
8.16.2
8.16.3
8.16.4
8.16.5
SHOULD allow recording of all drugs and doses validated against a list of licensed drugs
available in the UK (adult and paediatric).
MUST provide a facility for electronic prescribing of drugs and nutritional supplements.
MUST be compatible with the NHS prescriptions service.
MUST follow Dictionary of Medicines and Medical Devices (DM+D) identifiers for
prescribing, as per NHS protocols (http://www.dmd.nhs.uk/).
MUST provide a medicines reconciliation function, compliant with NPSA/NICE
requirements. It MUST record who, when and what references were used in obtaining
medication history.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 43 of 69
8.16.6
8.16.7
8.16.8
8.16.9
8.16.10
8.16.11
8.16.12
8.16.13
8.16.14
8.16.15
8.16.16
8.16.17
8.16.18
8.16.19
8.16.20
8.16.21
8.16.22
8.16.23
8.16.24
8.16.25
8.16.26
8.16.27
8.16.28
8.16.29
8.16.30
8.16.31
8.16.32
8.17
MUST contain a list of all licensed drugs which are prescribable in the UK.
MUST allow prescribing of unlicensed drugs and drugs for clinical trials.
MUST regularly update information for new/withdrawn drugs and license amendments.
MUST automatically check prescribed drugs against the patient’s list of known drug
allergies.
MUST highlight drug dosing outside licensed ranges.
MUST automatically check for contra-indications.
MUST automatically check for interactions between drugs.
MUST highlight duplicate prescriptions and SHOULD highlight drug class duplicate
prescriptions.
MUST allow drug dose prescribing outside licensed range in exceptional circumstances.
SHOULD allow facility for an online pharmacist’s clinical check on prescriptions.
MUST highlight extended scheduled drug administration eg weekly/monthly etc and
provide reminders for when the next dose is due.
SHOULD be able to generate a paper discharge prescription.
SHOULD highlight controlled drugs and address additional legal requirements when
prescribing.
SHOULD have links to the British National Formulary (BNF)/renal drug handbook for drugs
information (including the BNFc for children).
MUST offer the ability to audit prescribing history.
SHOULD differentiate the different renal modalities eg Renal Replacement Therapy type,
Transplant and Chronic Kidney Disease (CKD) stage.
SHOULD link to Renal specialty’s and Trust’s prescribing policies.
SHOULD highlight specialist pharmacy needs eg compliance aids.
SHOULD allow the facility for the prescribing and electronic sign off of delivery for drugs
related to haemodialysis (erythropoietin, iron, anticoagulants, fluids and line-lock
solutions).
SHOULD support full inpatient electronic drug prescribing and delivery.
SHOULD allow import of a drug list from, and export to any future Trust inpatient electronic
prescribing system if 8.16.25 is not implemented.
SHOULD record drug delivery.
SHOULD generate patient information leaflets.
SHOULD support drug delivery recorded by barcode scanning.
SHOULD link to the Pharmacy ASCRIBE system (formally JAC system).
MUST allow for prescribing of a limited list of drugs by certain users.
SHOULD support the existing Proton-based prescribing decision support system for
anaemia management for haemodialysis patients which produces dose recommendations
for intravenous iron and erythropoiesis-stimulating agent (ESA) doses based on current and
historical haematological parameters.
Admissions
8.17.1 MUST pull clinical details of each admission into the Renal Information System through
interface with PAS via ICAN.
8.17.2 MUST allow discharge summaries to be prepared automatically from information entered by
clinical staff and these should include coded items from the system eg co-morbidities.
Discharge summaries MUST be generated in Microsoft Word or pdf format so that they are
able to be imported into Medical Office or Sunquest ICE products for onward distribution to
GPs.
8.17.3 The electronic record of admission MUST be sufficient to guide clinical care without needing
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 44 of 69
supplementary paper records.
8.17.4 MUST generate a discharge summary as a structured document which includes take-home
drugs. This list of drugs SHOULD be communicated electronically to the hospital pharmacy.
8.17.5 MUST maintain a current inpatients list from ward rounds and handovers.
8.18
Clinic Visits
8.18.1 MUST record clinical details of each visit eg bloods, blood pressure, weight, height etc.
8.18.2 Components of the clinic data MUST be incorporated into the clinic letter automatically eg
current drugs, changed drugs, recent laboratory results, clinic weight, clinic blood pressure,
clinic height (for paediatric patients), known diagnoses, date of next clinic appointment etc.
Clinic letters MUST be in either Microsoft Word or pdf format so that they are able to be
imported into Medical Office.
8.18.3 The electronic record of the clinic visit MUST be sufficient to guide clinical care without
needing supplementary paper records.
8.18.4 The clinic visit is handled by a structured process which captures all information required.
The system MUST record this data in an intuitive manner.
8.18.5 SHOULD allow electronic identification of patients using barcodes in the weighing room with
direct entry of the patients’ weight & blood pressure via interfaces with the scales and
sphygmomanometers. It may also prompt the nurse for direct entry of urine analysis
results.
8.19
8.19.1
8.19.2
8.20
Procedures
MUST record clinical details of each procedure.
SHOULD record identifiers of any devices inserted and disposables used.
Transplant
8.20.1
8.20.2
MUST capture details of the transplant work up process.
MUST maintain a list of patients at key stages of the workup process (eg awaiting
suitability decision, waiting for investigations, active on the list, etc.).
8.20.3 MUST maintain a list of suspended transplant patients with the reason and review date as
well as date of suspension.
8.20.4 MUST maintain the details of the live donor and the donor workup, and appropriate links
between the live donor and recipient.
8.20.5 MUST capture details of the transplant operation including Human Leukocyte Antigen
(HLA) and virology details.
8.20.6 MUST capture details of any immunosuppressant agents given in theatre or as a single
dose.
8.20.7 MUST capture demographic and clinical details of deceased donors, including donor cause
of death.
8.20.8 MUST capture details of the condition of the donor organ.
8.20.9 MUST support the structured pathway for post-transplant care (to include a record of
rejection episodes, immunosuppression changes, revision surgery/interventional radiology,
virological complications, new onset diabetes, osteoporosis, cardiovascular disease,
transplant dysfunction etc.).
8.20.10 SHOULD support the pathway with clinical alerts in the event of changing laboratory
parameters (eg viral titres, eGFR, proteinuria) and scheduled events (eg screening tests for
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 45 of 69
virology, alloantibody, osteoporosis etc).
8.20.11 MUST capture all data required by NHS BT and the UK Renal Registry.
8.21
Peritoneal Dialysis
8.21.1
8.21.2
8.21.3
8.21.4
8.21.8
8.21.9
MUST capture details of the patient’s education and preparation for dialysis.
MUST capture information regarding the peritoneal catheter, its function and care.
MUST capture information on any access related infections.
MUST produce a patient specific peritoneal dialysis prescription (APD, CAPD and assisted PD,
full range of dialysis solutions and tidal PD).
SHOULD be able to model urea and creatinine clearance from the dialysis prescription.
MUST calculate and display peritoneal function (transporter status and PET test results),
renal and urea clearance, and display ultrafiltration volume and urine output as
recommended by the UK Renal guidelines. SHOULD display the results in tabular and
graphical form.
SHOULD have a structured pathway for peritoneal dialysis care (eg screening and treatment
of catheter related sepsis, peritoneal dysfunction, renal anaemia, renal bone disease etc.).
SHOULD be able to display the peritoneal dialysis catheter exit site visual inspection score.
MUST comply with national renal dataset for peritoneal dialysis related access.
8.22
Haemodialysis
8.21.5
8.21.6
8.21.7
8.22.1
8.22.2
8.22.3
8.22.4
8.22.5
8.22.6
8.22.7
8.22.8
8.22.9
8.22.10
8.22.11
8.22.12
8.22.13
8.23
MUST capture information on the dialysis access used for each treatment.
MUST capture information on any access related infections.
MUST handle the haemodialysis prescription and include all required data items in a
format that can allow a printed version of the haemodialysis prescription to be produced
for each dialysis session.
MUST allow for a full electronic record of each dialysis session to be recorded by the
nursing staff. This will include free text comments as well as a list of potential
complications which may occur during treatment (eg episodes of intradialytic hypotension).
SHOULD predict dialysis adequacy from the variables contained within the dialysis
prescription (eg dialysis time, blood flow rate, dialysis flow rate, needle guage).
MUST calculate dialysis adequacy (eKt/V/urea reduction ratio) as recommended by UK
Renal guidelines and display this on the printed dialysis prescription.
SHOULD support the structured pathway for haemodialysis care (eg screening and
treatment of catheter-related sepsis, renal anaemia, renal bone disease etc.).
SHOULD maintain details required for planning home deliveries (disposables required,
storage space, contracts applicable etc.).
SHOULD support the allocation of patients to care teams.
MUST allow easy selection of haemodialysis patients based upon the dialysis area they are
assigned to (including home haemodialysis patients).
MUST capture dialysis treatment details eg dialysate flow rate, blood pump speed,
duration of treatment, machine number, arterial and venous pressure measurements etc.
MUST show patients undergoing treatments at any time by area.
MUST capture all current data required by the UK Renal Registry.
Vascular Access for Haemodialysis
8.23.1 MUST comply with the National Renal Dataset for haemodialysis access.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 46 of 69
8.23.2 MUST enable a vascular access timeline to be created detailing all vascular access related
procedures (including surgical procedures, interventional radiology procedures such as
fistula intervention and central venous catheter based procedures) and record all
complications associated with vascular access.
8.23.3 MUST enable pathway information to be stored and analysed (eg date of referral for access
surgery, time from referral to surgery etc.).
8.23.4 MUST capture information on vascular access monitoring to be captured and reviewed in a
tabular and graphical manner.
8.24
Chronic Kidney Disease (Low Clearance)
8.24.1 MUST capture details of the patient’s education and preparation for renal replacement
therapy.
8.24.2 MUST capture information on the patients’ choice of dialysis (including conservative care).
8.24.3 SHOULD predict the date for starting dialysis.
8.24.4 SHOULD support the structured pathway for dialysis workup eg anaemia management, bone
management.
8.24.5 MUST capture details of home visits and assessments.
8.25
Dietetic Assessment
8.25.1 SHOULD record advice given and by whom.
8.25.2 SHOULD record current dietary intake.
8.25.3 MUST record a prescription of dietary supplements.
8.26
Psychosocial Issues
8.26.1 SHOULD be able to record details of home visits and assessments.
8.26.2 SHOULD be able to record details of input by the young adult/youth worker and
psychologist.
8.26.3 MUST be possible to set customisable alerts against individual patients for staff to see when
they access the patients record eg do not see alone.
8.26.4 SHOULD allow the recording of anthropometric measurements eg triceps skin fold
thickness, hand grip strength.
8.27
Clinical Alerts
8.27.1 MUST give automatic notification to the appropriate staff member when specific new
laboratory results are out of range.
8.27.2 SHOULD be user programmable to allow clinical advice prompts.
8.27.3 MUST be configurable to issue reminders if investigations are overdue.
8.28
Clinical Communication
8.28.1 MUST allow internal messaging to any system users.
8.28.2 Messages SHOULD import patient details and be possible to link to test results or report
page.
8.28.3 MUST store all messages in the patient’s record.
8.28.4 MUST display messages, alerts and tasks for a user when accessing the system as well as
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 47 of 69
when the message is sent whilst already using the system.
8.29
Clinical Correspondence
The Trust currently uses an in-house developed and supported product, “Medical Office” for
the generation, storage and access of the majority of clinical documents and correspondence
currently produced using NotIS. Departmental systems (including the Renal system), if used
to separately create clinical documents and correspondence, will therefore need to generate
this material in a suitable format to be imported into the Medical Office environment.
8.29.1
8.29.2
8.29.3
Clinical letters produced MUST be compatible with Microsoft Word or pdf format.
SHOULD be able to handle scanning and storage of incoming letters/documents.
Clinical letters generated MUST be capable of being automatically uploaded to Trust
systems, currently Medical Office, if required.
8.29.4 Various letter templates MUST be available which automatically include other fields such as:
Current Drugs, Changed Drugs, Latest lab results, Address, Name, Hospital number, verified
NHS number etc.
8.29.5 SHOULD allow multiple carbon copies of letters to be sent and record to whom they were
sent on the system.
8.29.6 MUST allow letters to be easily viewed retrospectively.
8.29.7 MUST allow the facility for letters to be reprinted at a later date.
8.29.8 MUST include a spell check and the ability to add words to the spell check dictionary.
8.29.9 Correspondence to GP’s SHOULD include a headed section entitled ‘Specific Actions for GP’.
8.29.10 The system MUST manage all aspects of clinical correspondence so as to comply with the
BSI Code of Practice for Legal Admissibility of Evidence.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 48 of 69
9.
TECHNICAL REQUIREMENTS
9.1
Security Requirements
9.1.1
The Supplier’s offering MUST be compatible with the Trust’s security standards described in
section 7.12.
9.1.3
In particular the System MUST incorporate the following security countermeasures:
 Physical security measures (eg located in a secure room etc).
 Logical measures for access control and privilege management.
 Network security measures (eg firewalls, network segregation, etc).
 Other (including authentication or certification arrangements, security testing, and
audit).
Information Security standards associated with the System MUST be compliant with the
controls detailed in ISO/IEC 27001:2005 and conform to the Code of Practice as detailed in
ISO/IEC27002.
MUST stipulate how the System minimises the risk of disclosure of confidential information.
9.2
System Access
9.2.1
MUST be compatible with and exploit the NUH-wide Single Sign On (SSO) solution, Imprivata
One-Sign, including the potential use of biometric devices, eg fingerprint readers.
MUST only allow access following entry of a valid username and associated secret password.
Passwords MUST not be displayed on screen.
MUST allow authorised administrator(s) - (ie System Manager or other designated ‘Super
User’) - and no other user - to create new usernames and allocate or redefine security
access profiles (ie levels of user access).
MUST only allow access to those functions enabled within the security access profile
associated with the username.
SHOULD integrate with the Trust Microsoft Active Directory environment so that the Active
Directory user details and password are used when accessing the System.
If not using Active Directory passwords, then:
MUST allow individual users to define their own passwords, subject to System-wide
minimum standards, and to change their password at any time;
MUST force a change of password after the elapse of a locally defined period of time;
The password MUST be stored in an encrypted form.
It MUST be possible to uniquely identify all users of the System.
SHOULD produce a report detailing each user’s access rights.
It MUST be possible to create user ‘Roles’ which define the level of access to the application
database.
It MUST be possible to restrict access to any level of the menu (ie program items or menu
items) based on user Role.
If third party query tools are used, then access to the System database via these query tools
MUST be password controlled.
MUST automatically logout users after a user-defined period of inactivity without affecting
system integrity (apart from loss of data on unsaved screens).
MUST limit the number of attempted login failures in order to provide an intruder detection
and lockout facility.
9.1.2
9.2.2
9.2.3
9.2.4
9.2.5
9.2.6
9.2.7
9.2.8
9.2.9
9.2.10
9.2.11
9.2.12
9.2.13
9.2.14
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 49 of 69
9.3
Audit Trail
9.3.1
MUST record a comprehensive Audit Trail of all significant database updates, which MUST
include user, date, time, and if practicable Active Directory Workstation Name.
9.3.2
MUST comply with all the terms in the NHS Information Governance Board (NIGB) Care
Record Guarantee requirements (please see http://www.nigb.nhs.uk/guarantee/2009-nhscrg.pdf) and, specifically, record the user details, date and time for every instance that a
patient record is viewed, ie viewed only but not necessarily updated.
MUST provide functions to allow enquiry, reporting and printing from this audit trail, subject
to appropriate access rights.
SHOULD provide flexibility within these functions to allow parameterised analysis by
combinations of period of time, individual patient and individual user.
It MUST be possible for the audit trail to be retained indefinitely in order to cover legal
requirements.
If the System includes facilities to archive the audit trail, then the Supplier MUST describe
how this is done. Archived data MUST be easily retrievable and analysable.
MUST be able to store some types of changes from the PAS in a quarantine area for system
manager intervention, ie patient record deleted or merged.
9.3.3
9.3.4
9.3.5
9.3.6
9.3.7
9.4
Separate Live Training and Testing Environments
9.4.1
MUST provide separate database and access environments for live operations and for user
training.
MUST also provide a third database and access environment to enable the controlled testing
of new software releases and developments. The test environment MUST include all
electronic message interface components so that the impact on existing message interfaces
can be tested prior to release.
SHOULD provide the ability to copy, in a controlled manner, reference data between the live,
training and test environments, but otherwise the databases MUST be mutually discrete and
secure.
MUST comply with the standards for training and test environments described in section
7.10.
9.4.2
9.4.3
9.4.4
9.5
Networking Requirements
9.5.1
9.5.3
The Supplier’s offering MUST be compatible with the Trust’s networking standards described
in section 7.6 and section 7.7.
The Supplier MUST provide a system/technical specification to allow the Trust’s IT Services to
confirm that the proposed System will work across the Trust’s network.
SHOULD support handheld wireless devices for use by clinicians.
9.6
Desktop Requirements
9.6.1
The Supplier’s offering MUST be compatible with the Trust’s desktop standards described in
section 7.8.
The Trust may choose to move to a “virtual desktop” environment using thin client
technology. The Supplier SHOULD specify if there would be any issues with deploying the
System in such an environment.
9.5.2
9.6.2
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 50 of 69
9.6.3
9.6.4
9.6.5
9.6.6
9.6.7
9.6.8
9.6.9
9.6.1
0
9.6.1
1
9.6.1
2
9.6.1
3
9.6.1
4
9.6.1
5
9.6.1
7
The client software MUST work under standard Windows user privileges.
The client software MUST NOT require a lowering or modification of Active Directory global
security rights.
The client software MUST function correctly on an encrypted computer using technologies
such as McAfee SafeBoot, safend Encryptor or Microsoft Bitlocker.
Where client computers have encrypted hard disk drives then the client software MUST NOT
store data on an unencrypted volume.
The client software MUST NOT require anti-virus to be disabled at any time including for
installation.
Microsoft updates MUST be supported within one month of release. The Supplier MUST
provide details of their procedures for supporting Microsoft updates.
Where appropriate, .NET and JAVA version latest minor versions MUST be supported within
six months of release. The Supplier MUST provide details of their procedures for supporting
.NET and JAVA updates.
The client software MUST be provided with an installation package that allows unattended
installation and update. This installation package MUST function using standard user
privileges on the client device.
The installation MUST register correctly with Add/Remove Programs.
MUST be possible to fully uninstall silently and not require any manual clean up.
The application SHOULD have the ability to be deployed using Microsoft System Center
Configuration Manager 2007 R2.
The client software MUST NOT use hardware dongles (eg parallel port or USB devices) for
activation.
The application MUST NOT require individual clients to activate against internet based
servers.
MUST NOT use NetBIOS for name resolution.
9.7
Printer Requirements
9.7.1
9.7.2
9.7.3
9.7.4
The Supplier’s offering MUST be compatible with the Trust’s printer standards described in
section 7.9.
MUST be able to support standard Windows printers.
MUST use built-in Microsoft Print Drivers where possible.
MUST allow any print job to be aborted without adversely affecting the system.
9.8
Server Requirements
9.8.1
9.8.2
MUST be compatible with the Trust’s server standards described in section 7.10.
MUST have the ability to use a current Microsoft main stream supported operating system or
application.
It MUST be possible for any server or database components of the system to be run in a
VMware virtual environment and the Supplier MUST support the System when running in a
VMware environment.
The Supplier SHOULD be able to support the major version of VMware within six months of
release and VMware security patches within one month of release. The Supplier MUST
provide details of their arrangements for supporting a VMware environment.
9.8.3
9.8.4
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 51 of 69
9.8.5
Any software installed on a server MUST NOT require anti-virus to be disabled at any time
including for installation.
9.9
Database Requirements
9.9.1
The System’s internal database MUST be compatible with the Trust’s database standards as
described in section 7.10.
The System’s internal database SHOULD be based on a reputable Relational Database
Management System (RDBMS).
Where Microsoft SQL Server is to used then it MUST run on a shared server or Virtualised if
less than four CPU’s are required.
The System's internal database structure SHOULD be Open Database Connectivity (ODBC)
compliant.
It MUST be possible for the Trust to extract any data item from any database table for
transfer to the Trust’s clinical portal. This would typically be carried out by running a report
overnight or by a process based on database replication. The structure, format and contents
of the System's database tables and data items MUST be provided in sufficient detail to
facilitate this data extract (see also section 8.6)
9.9.2
9.9.3
9.9.4
9.9.5
9.10
Database Management, Backup and Recovery
9.10.1 MUST incorporate full backup and restore facilities. Audit trails for backup and restore
activities MUST be easily accessible for inspection purposes. The backup and restore
facilities MUST be compatible with the Trust’s backup standards described in section 7.10.
The Supplier MUST provide full details of the recommended backup and restore processes.
9.10.2 SHOULD provide the facility to carry out backups with the system in full functional and
operational use. The Supplier MUST state how this is done and what effect this has on the
system, data integrity and performance, and if this would impact on data integrity or system
performance.
9.10.3 The Supplier MUST provide full information on the recommended process for checking and
ensuring the successful completion of an unattended backup. This process SHOULD be
automated, reporting exceptions to the appropriate Trust IT Support staff.
9.10.4 The Supplier SHOULD provide details of any automated actions the proposed backup
processes will employ when a fault or error in performing the backup occurs.
9.10.5 The Supplier MUST stipulate how the System maintains data quality.
9.11
CfH Requirements
9.11.1 The Supplier MUST provide evidence of ability to work with NHS CfH and of their familiarity
with CfH’s long-term PAS/Care Records Service (CRS) plans.
9.11.2 The Supplier MUST conform to DSCN 142009 (30th December 2009), and DSCN 182009 (April
2010) issued by CfH Information Standards Board and intended to minimise risks to patient
safety in respect to the manufacture of health software products and in respect to the
deployment and use of health software products. Please see http://www.isb.nhs.uk/ for
further details.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 52 of 69
10.
IMPLEMENTATION SUPPORT AND DEVELOPMENT
10.1
Project Management
10.1.1
10.1.2
10.1.3
10.1.4
10.1.5
10.2
The Supplier is expected to deliver the requirements of this OBS to industry standard
Project and Quality Management methodologies. Suppliers MUST explain their approach to
a project of this size and scope.
Suppliers MUST be willing to adapt their project management procedures to fit with the
Trust’s pragmatic use of PRINCE2 and SHOULD outline how this has been achieved in
previous contracts.
The Supplier MUST allocate a Project Manager to oversee Implementation and to work in
partnership with the Trust’s project team. The Supplier’s Project Manager MUST be
experienced, pro-active, visible and readily contactable throughout the implementation
process. The proposed Project Manager’s CV SHOULD be provided with the Supplier’s
response. The Project Manager (or deputy) MUST be available for regular review meetings
for the duration of the project.
In case of absence of the Project Manager, the Supplier MUST detail appropriate deputising
arrangements and outline how this will be delivered.
To support the Project Manager the Supplier MUST provide an experienced Project Team
consisting of technical experts, subject matter experts, etc.
Approach to Implementation
10.2.1 Suppliers MUST outline their approach to providing support for the initial implementation.
This may include a brief outline of system set-up and configuration, training, change
management and benefits realisation.
10.2.2 Suppliers MUST state how the support for implementation will be delivered (eg how many
staff will be available, and for how many days?), and explain which are included in the price
quoted. Any additional costs MUST be quoted in the pricing schedule.
10.2.3 Suppliers MUST provide a high-level draft implementation plan, incorporating:
- Clearly defined project milestones that logically progress the completion of the overall
project.
- Clearly defined Supplier and Trust responsibilities to meet each milestone, including
resourcing, and the overall project timescale.
10.2.4 Suppliers MUST be willing to develop the approach and plan for implementation in
partnership with the Trust, to generate a jointly agreed plan to be approved by the Trust’s
Project Board.
10.3
New Ways of Working and Benefits Realisation
10.3.1 Suppliers MUST outline their expectations of the Trust’s responsibilities for the identification
and implementation of change, and the realisation of benefits including resources to be
made available by the Trust.
10.3.2 Suppliers MUST be willing to support the Trust in defining current ways of working
undertaking a comprehensive assessment of opportunities for new ways of working (‘to be’
processes).
10.3.3 Suppliers MUST be willing to support the Trust in the development of a change/benefits
realisation plan.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 53 of 69
10.4
Installation and Technical Support during Implementation
10.4.1 Suppliers MUST explain their approach to installation of hardware and software.
10.4.2 Suppliers MUST outline their expectations of the Trust’s responsibilities for installation of
hardware and software.
10.4.3 Suppliers MUST support implementation of the System through the provision of technical
consultancy services to install application software and also, if required, to configure the
hardware and system environment and this SHOULD be costed in the tender.
10.4.4 Suppliers MUST clearly identify any resources, expertise and facilities that they expect to be
provided by the Trust in order to enable installation and configuration of hardware, system
and application software.
10.4.5 Suppliers SHOULD supply software development resources, whose deployment is
coordinated within the project plan, to provide any local customisation or development of
the existing application software that are agreed as part of the Contract.
10.5
System Configuration and Set-up
10.5.1 Suppliers MUST explain their approach to system configuration and set-up and MUST
ensure that this will support the new ways of working identified during implementation.
10.5.2 Suppliers MUST outline their expectations of the Trust’s responsibilities for system
configuration and set-up.
10.5.3 Suppliers MUST support the Trust in understanding how the solution could be used to meet
its requirements.
10.5.4 Suppliers MUST provide configuration templates.
10.5.5 Suppliers MUST provide standard code tables that meet nationally defined minimum
standards as part of system configuration and set-up.
10.6
Data Migration
The Supplier is informed that an objective of the Trust is to replace or integrate local, stand
alone clinical databases where appropriate and thus reduce duplication and inconsistencies.
The Trust requires any solution to be able to accommodate and fully utilise historical data
held within the system(s). Such data forms the basis of national and local audit and research.
10.6.1
10.6.2
10.6.3
10.6.4
10.6.5
Suppliers MUST explain their approach to migrating and transformation of data from
Proton (and from the existing standalone databases detailed in appendix A) into their
solution and how this meets Trust requirements (eg how will the migration be managed
and what requirements are there for testing of data migration in advance, during and
immediately after the migration?). See section 8.9.
The Supplier is informed that an objective of the Trust is to replace or integrate local, stand
alone clinical databases where appropriate and thus reduce duplication and
inconsistencies. The Renal department has several such systems that are described in
appendix A. The Supplier SHOULD attempt to incorporate data and functionality from
these stand alone systems into their solution so they can cease to be used.
Suppliers MUST be willing to act as a prime contractor and to deal with any third parties
directly, if required.
Suppliers MUST outline their expectations of the Trust’s responsibilities for data migration.
Suppliers MUST be willing to test as much as required to enable data to be successfully
extracted, transformed and then imported into the new Renal Information System.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 54 of 69
10.6.6
The Supplier MUST be willing to work alongside a preferred third party support company in
order to extract the data from the current system.
10.6.7 The solution MUST import existing data from the current Proton system.
10.6.8 The solution MUST provide an environment that will support the correction of data where
appropriate.
10.6.9 It MUST be possible to transfer reference data such as local codes, and where relevant
transfer it from other sources, without the need for re-entry by the Trust.
10.6.10 It MUST be possible to clean data and report records that have proved impossible to
convert.
10.6.11 The Supplier MUST describe their approach to data import, conversion and validation. The
type of input required from the Trust must be specified.
10.6.12 The Supplier MUST describe their changing structure for data conversion. The Trust will
provide specifications of the source database.
10.7
10.7.1
10.7.2
10.8
10.8.1
10.9
10.9.1
10.9.2
10.9.3
10.9.4
Training
Suppliers MUST explain their approach to providing user training (eg What is the level of
training support for the system? On-site? Off-site? How many days? Any external courses
involved? Any follow-up training at a later date? What arrangements for training the system
administrator? Who pays for travel and accommodation costs? Supply of training).
Suppliers MUST outline their expectations of the Trust’s responsibilities for training.
Business Continuity & Disaster Recovery
Suppliers MUST support the Trust in developing robust Business Continuity and Disaster
Recovery Plans, and the testing and subsequent revision of such plans as necessary.
Documentation
Suppliers MUST supply appropriate, complete, up to date and sufficient copies of manuals
and other documentation to enable effective operation of the System, and to conduct
required support activities.
The documentation MUST cover all products supplied, including those originating from
third parties, and MUST include:
 Technical description and specification of hardware
 Hardware operation and maintenance
 Operating System software operation and maintenance
 Application software operation
 System screens, data structures, data items, codes, reports, and functions for local
tailoring and parameterisation
 Technical specification and operating instructions for interfaces to other systems.
All documentation MUST be updated for any changes made to the System during
implementation. Subsequent releases of software MUST be accompanied by timely
changes to the relevant documentation.
Suppliers MUST provide appropriate training documentation for system
managers/administrators and for end users.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 55 of 69
10.10 System Go-Live and Verification Period
10.10.1 Suppliers MUST explain their approach and planning for migration to the Trust’s live
environment for the new system.
10.10.2 Suppliers MUST support the Trust throughout the Go-Live period and outline how this is
delivered.
10.10.3 Suppliers MUST explain their approach to system acceptance and verification.
10.11 Handover to Operational Management
10.11.1 Suppliers MUST outline their approach to moving from the implementation phase to an
operational phase and how they will support the Trust in making a seamless transition.
10.12 System Support
10.12.1
The Supplier’s offering MUST be compatible with the Trust’s support standards described
in section 7.11.
10.12.2 The Supplier MUST state their approach to Service Management and identify any
standards that are in place with their offering.
10.12.3 The Supplier MUST provide a telephone Helpdesk facility with a stated minimum response
time. This will be accessed by the System Manager and the Trust’s IT Helpdesk. An out-ofhours support number is required in case of more serious faults.
10.12.4 The Supplier MUST indicate response times to software support calls, with the associated
time bands if support varies throughout the 24 hour period.
10.12.5 The Supplier MUST provide a framework and time scale for response to errors and
problems occurring with the system and MUST specify response times in the event of
system down time.
10.12.6 The Supplier MUST provide remote access support that is compatible with the Trust’s
remote access standards described in sections 7.6 and section 7.10. This support MUST use
the NHS private network N3.
10.12.7 The Supplier MUST offer an annual Service Level Agreement (SLA), which clearly states
who is responsible for ensuring that all traceability data is retained and readily accessible
for the nationally mandated period(s) of time.
10.12.8 The Supplier’s annual SLA MUST include provision (at no additional cost to the Trust) for
any database changes required in order to maintain compliance with mandatory national
datasets. Any database changes specifically requested by the Trust that do not form part
of the compliance with mandatory national datasets will be agreed on a case-by-case basis
(sample charges should be detailed in the Supplier’s tender response).
10.12.9 Suppliers MUST outline what technical support and maintenance arrangements are
available (eg gold, silver, bronze levels).
10.12.10 The Supplier MUST identify procedures for raising, progressing and monitoring of support
requests.
10.12.11 The Supplier MUST indicate how it will support ongoing systems integration, both internal
and external to the Trust.
10.13 Product Development
10.13.1 Suppliers MUST detail their future development plans for the Renal Information System, in
particular suppliers MUST outline how the Trust’s future processes for Renal (as described
in section 6) will be met.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 56 of 69
10.13.2 Suppliers MUST explain the approach to and management of software upgrades, which
would normally be expected to be part of the contract and state whether these are at no
extra charge or incur any additional costs.
10.13.3 Suppliers MUST explain their approach to the ongoing training and product support. This
should include:
 Ongoing training for new end-users
 Support and training for replacement system managers/administrators
 Refresher training for system managers/administrators and for end-users
 Specific training for major upgrades.
10.13.4 Suppliers MUST explain the approach and costing procedure associated with the
management of minor or major enhancements that are requested by the Trust and provide
a strategy for responding to these requests.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 57 of 69
11.
COMMERCIAL REQUIREMENTS
11.1
Delivery Requirements
Suppliers will be evaluated on the basis of their financial, technical and general
organisational viability to support the requirements of the Trust.
11.1.1
11.1.2
11.1.3
11.1.4
11.1.5
11.1.6
11.2
11.2.1
11.3
The Supplier MUST provide the registered name and address of the company.
The Supplier MUST provide the name, address, telephone number, fax number and email
address of the employee who will act as the main point of contact for this project.
Suppliers MUST demonstrate they have sufficient resources and expertise to support the
size and complexity of their proposed solution.
The Supplier MUST describe their internal arrangements for staff training and development
of their own staff.
The Supplier MUST provide contact names and addresses for reference sites in the UK
where its solution has been installed. The Trust may formally contact these sites without
first approaching the Supplier.
The Supplier MUST provide details of what confidentiality and security controls they have in
place as the Supplier may have access to patient information during testing, implementation
and/or support of the System.
Timescale
The Supplier MUST indicate how they plan to meet the Trust’s timescale.
Software Licenses
11.3.1 Suppliers MUST explain the range of licences required as part of this proposal (eg how many
types of licences will be needed? For application software? For operating systems?).
11.3.2 Suppliers SHOULD offer a Trust-wide license for the proposed solution.
11.4
11.4.1
11.4.2
11.5
11.5.1
11.5.2
11.5.3
Management and Maintenance of Contract
Suppliers MUST provide a single point of contact that will be responsible for the delivery
and maintenance of the contract for the lifetime of the solution.
Suppliers MUST agree a process with the Trust that will enable contractual changes to be
appropriately considered, and where agreed incorporated into the contract.
End of Contract Support
The Supplier MUST undertake to support the Trust to migrate from their solution to an
alternative solution at the end of contract (which may or may not be provided by the
Supplier) by providing a data extract to a pre-defined and documented specification.
Suppliers MUST outline their approach to this.
The Supplier MUST provide documentation to allow transformation of the data following
extraction.
The Supplier MUST maintain their data extract functionality and documentation in line with
system developments.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 58 of 69
11.6
11.6.1
11.6.2
Extension to Contract Term
Suppliers MUST explain their approach to extension of contract at the end of the contract
period.
The Supplier MUST be prepared to extend the term of the support contract at the end of
the initial contract period on a ‘like for like’ same cost basis, which can be increased in line
with the Retail Price Index.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 59 of 69
12.
FINANCIAL REQUIREMENTS
Respondents MUST provide indicative costs for their solutions in the format below and
MUST provide an explanation of the assumptions applicable to each of the cost lines:
Capital Costs
Year 1
£’000
Year 2
£’000
Year 3
£’000
Year 4
£’000
Year 5
£’000
Consultancy (including discovery,
site survey, audit &
documentation)
Renal System Software
Interfaces (A - N)
Data Migration
System Configuration
Development of Standard
Reports
Testing
Business Change Support
Training
Documentation
Project Management
On-site Support for Go-Live
Other (state)
TOTAL
Operating Costs
Year 1
£’000
Year 2
£’000
Year 3
£’000
Year 4
£’000
Renal System Software
Interfaces (A – N)
New Interface Development
New Report Development
DSCN changes
Consultancy Services (per day)
ESCROW
Other (state)
TOTAL
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 60 of 69
Year 5
£’000
13.
APPENDICES
13.1
Appendix A – Details of Stand Alone Databases
Peritoneal Dialysis Database (PDDB)






Microsoft Access database that holds details of peritoneal dialysis patients and their
medical/ treatment data.
Data is manually updated by medical and nursing staff.
The database is currently used to record patient demographics, patient PD prescriptions,
patient PD timeline records, peritonitis episodes, results from PD adequacy studies and
Peritoneal Equilibration Test (PET) results. It can also record blood test results,
medications and surgical procedures. As a research tool it records details of the
investigations and treatment of encapsulating sclerosing peritonitis.
All patients on this system also exist on Proton although not all of the data for each
patient is replicated across both systems.
The considerable overlap of information with Proton results in a high transcription
overhead, but it is currently used as a research tool as a branch of the Encapsulating
Peritoneal Sclerosis (EPS) Registry.
It is hoped that this system may become the default database through which the UK
Renal Registry receives PD data, though this idea has not progressed nationally.
Baxter Adequest Database





The database is currently used to calculate and record results from PD adequacy studies
and Peritoneal Equilibration Test (PET) results. It includes a module to allow staff to
model the likely effect of changes to an individual patient’s dialysis prescription.
Data is manually updated by medical and nursing staff.
All patients on this system also exist on Proton although not all of the data for each
patient is replicated across both systems.
The considerable overlap of information with Proton results in a high transcription
overhead.
It is planned to either incorporate Adequest’s functionality into the replacement system
or failing this to provide a bi-directional electronic interface with the new Renal IT
System.
Transplant Database







Microsoft Access relational database.
Contains detailed information about transplant patients (adults and paediatrics)
including operative details, early graft function, immunosuppressive drug doses,
admissions, complications (eg details of rejection episodes, biopsy results, malignancies,
pregnancies, infective episodes) and graft outcomes.
Generates statistics/data for audit.
Links to all donor databases.
All patients on this system also exist on Proton.
The system currently holds data on 1,434 patients (June 2011).
Ideally data from this database will be migrated into a new system for all active patients.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 61 of 69
Vascular Access Database






SQL server based database.
Contains information related to vascular access procedures (adults). This includes
pathway details such as time of referral for vascular access as well as information about
operative procedures. It also records information regarding tunnelled dialysis catheters
(such as date inserted and removed, complications, etc.). The database records details of
all radiological procedures carried out in relation to vascular access (both diagnostic and
interventional).
Generates reports/statistics, data for audit.
All patients on this system also exist on Proton.
The system currently holds data on approximately 11,000 patients (June 2011), of which
1,188 have detailed records (June 2011).
Ideally data from this database will be migrated into a new system for active patients to
maintain adequate history of vascular access related events.
Live Donor Workup Database







File based Microsoft Access database (relational).
Contains information relating to potential living kidney donors (630 work ups as of June
2011).
Entries relate to donor – recipient pairs (adult and paediatric recipients).
Records progression through the workup pathway including:
o Date and information related to each stage
o Outcome of the workup process
o Specific notes/comments
o Facility to record investigations and results.
Generates reports/statistics/data for audit.
Links to Transplant database.
Majority of potential donors exist on Proton.
Deceased Donor Database






File based Microsoft Access database (relational)
Contains information relating to deceased kidney donors for patients who have received
a kidney in Nottingham (adults and paediatrics). Includes details of 401 donors (June
2011).
Records all data entered on the UK Transplant registry KP4 form and NHS Blood and
Transplant Core Donor form.
Generates statistics/data for audit.
Links to Transplant database.
Deceased donors do not exist on Proton under their own entity number.
Living Donor Retrieval Database



File based Microsoft Access database (relational).
Contains information relating to living donors who have donated a kidney in Nottingham
(214 donors as of June 2011).
Records details of:
o Operative procedure
o Immediate post operative complications/outcomes
o Long term follow up.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 62 of 69


13.2
Generates statistics/data for auditing.
Majority of donors exist on Proton.
Appendix B – Major Systems Interfaces
Proton (labelled as Renal) is in top right corner of the schematic.
13.3
Appendix C – Migration of Existing Data
The Supplier MUST migrate a fixed data set for all currently active patients.




Our intention is to minimise the amount of data migrated to the new system. This is both
to contain the cost of migration and avoid encumbering the system with “messy data”.
Data to be migrated (or considered for migration) may include:
o Patient demographics
o Labs data
o Renal registry fields
o Renal PatientView fields
o Miscellaneous fields
Data not to be migrated will include:
o Deceased patients
Total number of patients on system (as of 25/05/11).
Category
Deceased (adult and paediatric)
Under GP care
Transferred to another unit
‘Active’ patients

Number
6,288
4,911
506
5,969
Comments
Not to be migrated
Should be migrated
Should be migrated
Essential to migrate
The Trust is in the process of reviewing data migration in more detail and will communicate
further information in due course.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 63 of 69
GLOSSARY
AES
Advanced Encryption Standard. A symmetric-key encryption standard.
APD
Automated Peritoneal Dialysis. Where a machine cycles the fluid in and out (usually
used overnight).
ADT
Admissions, Discharge and Transfer.
BNF
British National Formulary. http://bnf.org/bnf/index.htm
BSI
British Standards Institution. A multinational business services provider whose
principal activity is the production of standards and the supply of standards-related
services.
CAB
Choose and Book (electronic booking of patient hospital appointments).
http://www.chooseandbook.nhs.uk/
CAPD
Continuous Ambulatory Peritoneal Dialysis, sometimes referred to as PD.
CCL
Clinical Computing (UK) Limited. Supports existing Renal Information System.
CfH
Connecting for Heath. A government program to modernise the IT infrastructure of
the NHS.
CKD
Chronic Kidney Disease.
http://www.renal.org/whatwedo/InformationResources/CKDeGUIDE.aspx
CNT
Case Note Tracking. An electronic tracking facility for paper based healthcare
records. QMC uses a module within PAS; NCH uses a module within HISS.
COIN
Community of Interest Network.
CQUIN
Commissioning for Quality and Innovation payment framework. A means of receiving
additional payments from commissioners based on specific performance indicators.
http://www.institute.nhs.uk/world_class_commissioning/pct_portal/cquin.html
CPU
Central Processing Unit. The portion of a computer system that carries out the
instructions of a computer program, and is the primary element carrying out the
computer’s functions.
CRIS
Computerised Radiology Information System, developed and maintained by
HealthCare Software Systems (HSS).
CRS
NHS Care Records Service. Service provided by the NHS CfH which is developing
electronic care records that can be accessed across NHS organisations.
CUI
Common User Interface.
CV
Curriculum Vitae. An overview of a person’s life and qualifications.
Diaverum
A healthcare provider (formerly part of Gambro) who currently operate the QMC
satellite haemodialysis unit on behalf of NUH.
DIRC
The directorate of Diabetes, Infectious Diseases, Renal and Cardiovascular Medicine.
One of nine clinical directorates within NUH.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 64 of 69
DM+D
Dictionary of Medicines and Medical Devices. DM+D is a vocabulary dictionary
containing unique identifiers and associated textual descriptions for medicines and
medical devices.
DoH
Department of Health. Department of the United Kingdom government with
responsibility for government policy for health and social care matters.
DR rooms
Disaster Recovery rooms.
DSCN
Data Set Change Notice – now known as an Information Standards Board for Health
and Social Care (ISB). A notice of an Information Standard approved by the
Information Standards Board to which health and social care organisation in England
and their contractors must comply.
ECG
Electrocardiogram, a test that measures the electrical activity of the heart.
EDIS
Emergency Department Information System. A stand alone core product developed
by iSOFT and provided via Accenture.
eGFR
Estimated Glomerular Filtration Rate. Describes the flow rate of filtered fluid
through the kidney. A different calculation (formula) is used for adults and children.
eKt/V
A mathematical model to measure dialysis adequacy.
EPO
Erythropoietin. A glycoprotein hormone that controls red blood cell production.
ESA
Erythropoiesis-Stimulating Agent. Agent similar to the cytokine (erythropoietin) that
stimulates red blood cell production.
ETL
Extract, Transform and Load. A process cycle for migrating data between systems.
FIPS
Federal Information Processing Standard. FIPS 140-2 is a computer security standard
used to accredit cryptographic modules.
GP
General Practitioner. A medical practitioner who treats acute and chronic illnesses
and provides preventive care and health education for all ages.
HBV
Hepatitis B Virus. A species of the genus Orthohepadnavirus which is likewise a part
of the Hepadnaviridee family of viruses.
HDD
Hard Disk Drive. A computer device that stores digitally encoded data.
HISS
Hospital Information Support System.
HIV
Human Immunodeficiency Virus. A lentivirus (a member of the retrovirus family)
that causes acquired immunodeficiency syndrome (AIDS).
HL7
Health Level 7. A framework (and related standards) for the exchange, integration,
sharing, and retrieval of electronic health information.
HLA
Human Leukocyte Antigen. Name of the major histocompatibility complex in
humans. The super locus contains a large number of genes related to immune
system function in humans.
ICT
Information, Communication and Technology.
IGAF
Information Governance Assurance Framework. A Framework for health and social
care formed by those elements of law and policy from which applicable information
governance standards are derived, and the activities and roles which individually and
collectively ensure that these standards are clearly defined and met.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 65 of 69
ITIL
Information Technology Infrastructure Library. A set of concepts and practices for
information technology services management, information technology development
and information technology operations.
ISB
Information Standards Board for Health and Social Care.
iSCSI
Internet Small Computer System Interface. An Internet Protocol (IP)-based storage
networking standard for linking data storage facilities.
ISO
International Organisation for Standardization. An international standard setting
body.
IIS
Internet Information Services. Formerly called Internet Information Server. A web
server application and set of feature extension modules created by Microsoft for use
with Microsoft Windows.
Java CAPS
Trust’s integration engine.
KMH
King’s Mill Hospital (Mansfield) that along with Newark Hospital forms Sherwood
Forest Hospitals NHS Foundation Trust.
Korner number
District Korner number that is a unique identifier.
LAN
Local Area Network. A computer network that connects computers and devices in a
limited geographical area.
Low Clearance
A term used to describe kidneys functioning at less than 20% of their normal capacity
in CKD.
LSP
Local Service Provider. The LSPs act as integrators, ensuring existing local systems
meet national standards and that they facilitate data flow between the local and
national systems.
MCA
Mobile Clinical Assistant.
MDT’s
Multi Disciplinary Teams.
MRSA
Multidrug-Resistant Staphylococcus Aureus. Any strain of Staphylococcus aureus
bacteria that has developed resistance to beta-lactam antibiotics; especially
troublesome in hospitals, where patients with open wounds, invasive devices and
weakened immune systems are at greater risk of infection than the general public.
N (North) numbers
N (North) numbers are used as a casenote identifier and for casenote tracking for
NCH files.
N3
The broadband network for the NHS in the UK connecting all NHS locations and 1.3
million employees across England.
NAC
Network Admission Control. Refers to Cisco’s version of Network Access Control that
restricts access to the network based on identity or security posture.
NASP
National Application Service Provider.
NAT
Network Address Translation. The process of modifying network address
information in datagram (IP) packet headers while in transit across a traffic routing
device for the purpose of remapping one IP address space into another.
National Renal
Dataset
A detailed set of required fields and pick lists set out by the Department of Health
that all renal information systems should support.
http://www.ic.nhs.uk/services/datasets/dataset-list/renal
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 66 of 69
NCH
Nottingham City Hospital. One of the two main campuses comprising NUH.
NHS
National Health Service.
NHSBT (Bristol)
NHS Blood and Transplant at Bristol are responsible for the matching and allocation
of transplants in the UK.
NHSBT (Local)
NHS Blood and Transplant. The local site are responsible for tissue typing our
patients blood for transplant matching as well as Cytomegalovirus screening.
NICE
National Institute for Health and Clinical Excellence. A special health authority of the
NHS in England and Wales and a role model for the development of clinical
guidelines; the use of health technologies within the NHS; clinical practice and health
promotion and ill-health avoidance.
NotIS
Nottingham Information System. An in-house developed product that essentially is a
Graphical User Interface front end to HISS.
NPSA
National Patient Safety Agency. Leads and contributes to improved, safe patient care
by informing, supporting and influencing the health sector.
NUH
Nottingham University Hospitals NHS Trust. Also referred to as the ‘Trust’.
OBS
Output Based Specification.
ODBC
Open Database Connectivity. Provides a standard software interface for accessing
database management systems.
OJEU
Official Journal of the European Union. The gazette of record for the European
Union. For more information please see http://www.ojec.com/WhatIsTheOJEC.aspx.
OpenVMS
Open Virtual Memory System. High-end computer server operating system.
Contrary to what its name suggests, OpenVMS is not open source software.
ORMIS
An operating room electronic information system (iSoft) in use at NUH.
PACS
Picture Archiving and Communications System.
PAS
Patient Administration System. A generic term to refer to the main hospital patient
administration system.
PC
Personal Computer. Any general-purpose computer whose size, capabilities and
original sales price make it useful for individuals, and which is intended to be
operated directly by an end-user with no intervening computer operator.
PCT
Primary Care Trust. A type of NHS Trust that provides some primary and community
services or commissions them from other providers, and are involved in
commissioning secondary care.
PD
Peritoneal Dialysis. Treatment for patients with severe chronic kidney disease. The
process uses the patient’s peritoneum in the abdomen as a membrane across which
fluids and dissolved substances are exchanged from the blood.
PDA
Personal Digital Assistant. A mobile device which functions as a personal information
manager and has the ability to connect to the internet.
PMI
Patient Master Index. An index referencing all patients known to an area, enterprise
or organisation.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 67 of 69
PoE
Power over Ethernet. A system to pass electrical power safely, along with data, on
Ethernet cabling.
PRINCE2
A widely used project management methodology. http://www.prince2.com/
Proton
The name of the current renal information system in use at NUH. It is also
sometimes referred to as RS6000.
QMC
Queen’s Medical Centre. One of the two main campuses comprising NUH.
RAM
Random Access Memory. A form of computer data storage that allows memory to
be accessed in any order.
RDBMS
Relational Database Management System. A database system that is based on the
relational model.
Renal Patient View
A web interface that allows renal patients to view their latest laboratory results,
letters & transplant status. Currently in use at NUH.
https://www.renalpatientview.org/
Renal Registry
An independent organisation which audits and compares renal patient medical
statistics from renal units in the UK. Quarterly data extracts are sent to them
electronically from the Proton system. http://www.renalreg.com/
RFID
Radio Frequency Identification Device. Can be applied to or incorporated into a
product, animal, or person for the purpose of identification and tracking using radio
waves.
S (South) numbers
S (South) numbers are used as a casenote identifier and for casenote tracking for
QMC files.
SAN
Storage Area Network. Storage device accessible to servers so the device appears as
locally attached to the operating system.
SLA
Service Level Agreement. A part of a service contract where the level of service is
formally defined.
Smartphone
A mobile phone that offers more advanced computing ability and connectivity than a
contemporary, basic mobile phone.
SQL
Structured Query Language. A database computer language designed for managing
data in relational database management systems.
STEP
Standards Enforcement in Procurement. A process to assist local NHS organisations
undergoing IT procurements. It provides details on the standard to which suppliers
are expected to conform, together with supporting guidance.
SUS
Secondary Uses Service. A single source of comprehensive data to enable a range of
reporting and analysis.
TCP/IP
Transmission Control Protocol (TCP) and the Internet Protocol (IP), a set of
communications protocols used for the Internet and other similar networks.
TFT
Thin-Film Transistor. Special kind of field-effect transistor used in liquid crystal
displays.
Tidal PD
A type of Peritoneal Dialysis where not all of the fluid is drained away.
Transonic
A device that measures blood flow in haemodialysis patients and saves the data to a
corresponding database. http://www.transonic.com/
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 68 of 69
VDI
Virtual Desktop Infrastructure. Sometimes referred to as virtual desktop interface is
the server computing model enabling desktop virtualisation, encompassing the
hardware and software systems required to support the virtualised environment.
VMotion
Infrastructure that enables live migration of running virtual machines from one
physical server to another with zero downtime, continuous service availability and
complete transaction integrity.
VMS
Virtual Memory System. More formally known as OpenVMS.
VPN
Virtual Private Network. A network that uses a public telecommunication
infrastructure, such as the Internet, to provide remote offices or individual users
with secure access to their organisation's network.
WAN
Wide Area Network. A network that covers a broad area (ie any network whose
communications links cross metropolitan, regional, or national boundaries).
WiFi
A trademark of the Wi-Fi Alliance that manufacturers may use to brand certified
products that belong to a class of wireless local area network (WLAN) devices.
WLAN
Wireless Local Area Network. Links two or more devices using some wireless
distribution method and usually provides a connection through an access point to
the wider internet.
WSUS
Windows Server Update Services. A software update service for Microsoft Windows
operating systems and other Microsoft software.
Version No: 0.60
Date: 20 Jul 2011
Author: Mike Brooks and Mark Bolton
Page 69 of 69