Programme
NHS CFH
Document Record ID Key
Sub-Prog /
Project
Change
Control
CD-HL-SG
Prog. Director
Status
Draft
Owner
Version
0.1
Version Date
20/2/2011
Author
Jim Lewis
Urgent Care Clinical Dashboard Toolkit
High Level Solution Guide
© Crown Copyright 2017
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
Amendment History:
Version
Date
Amendment History
0.1
First draft for comment by Jim Lewis
0.2
Reviewers:
This document must be reviewed by the following:
Name
Signature
Jim Lewis
Title / Responsibility
Date
Version
CfH Technical Architect
Document Status:
This is a controlled document. Whilst this document may be printed, the electronic version maintained
in the Clinical Dashboards Toolkit is the controlled copy. Any printed copies of the document are not
controlled.
Related Documents:
These documents will provide additional information.
Ref No
Title
Version
1
Extended ISO Model of Software Quality (QUINT2)
1.0
2
Information Governance Guide (CD-PILOT-01)
1.0
3
QIPP Urgent Care Business Requirements
1.0E
© Crown Copyright 2017
Page 2 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
Contents
1
2
Introduction..........................................................................................................4
1.1
Purpose .........................................................................................................4
1.2
Scope ............................................................................................................4
1.3
Content ..........................................................................................................4
Reference Models ...............................................................................................5
2.1
2.1.1
Conceptual Technology Services
5
2.1.2
Conceptual Information Flow
7
2.1.3
The Interoperability Approach
8
2.1.4
The Interoperability Transport Options
8
2.1.5
Interoperability flow specifications
9
2.1.6
Interoperability source system providers
9
2.2
3
4
Functional Requirements...............................................................................5
Non-Functional Requirements .....................................................................10
2.2.1
Security
10
2.2.2
Infrastructure
11
Solution Options ................................................................................................12
3.1
Dashboard & Reports accessing an existing Data Warehouse ...................12
3.2
Dashboard & Reports building a new dedicated Data Warehouse ..............13
3.3
Dashboard & Reports using Software as a Service .....................................13
Market Overview & Business Intelligence Products ..........................................14
Appendix A - QUINT2 ...............................................................................................15
© Crown Copyright 2017
Page 3 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
1 Introduction
1.1 Purpose
The purpose of this document is to provide technical guidance to any Trust wishing to
implement an Urgent Care Clinical Dashboard for their local health community.
A number of reference models to assist in scoping the capability required along with
practical guidance from the pilot projects that have already been delivered are
referenced.
1.2 Scope
This document has been written for the technical project members who will need to
determine the solution approach.
1.3 Content
This document will include the following topics:

Technical Overview of Dashboards covering:





Functional Requirements expressed as:

Conceptual Technology Services, and

Conceptual Information Flow.
Source system integration

Data Flow Specifications

Common source systems
Non-Functional Requirements, including specifically:

Security, and

Infrastructure.
Solution Options:

Dashboard & Reports accessing an existing Data Warehouse

Dashboard & Reports accessing a new dedicated Data Warehouse

Dashboard & Reports delivered using Software as a Service (SaaS)
Market Place Overview and Business Intelligence Products
© Crown Copyright 2017
Page 4 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
2 Reference Models
2.1 Functional Requirements
2.1.1 Conceptual Technology Services
The Conceptual Technology Services Model below provides an overview of the functional
services that the Dashboard Technology Solution should offer broken down into three
layers: Channels, Application Services, and Infrastructure and Security.
1. Channels – identifying the various routes through with information from the
dashboard can be received:
a. Desktop User Interface – provide access via desktop application such as a
web browser.
b. Large Panel Display – provide the ability to display dashboards on large
screens in clinical locations for public or clinical consumption.
c. Portal – provide the ability to expose dashboard components via an existing
portal.
d. Data Extract – provide a mechanism through which data can be exported
on a scheduled basis in to standard formats such as CSV or XML.
e. Alerts – provide a notification mechanism for updates, alerts, errors, etc.
© Crown Copyright 2017
Page 5 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
2. Application Services – identifying the key functionality to be supported by the
dashboard application:
a. Extract, Transform & Load – provision of functionality to allow:
i. extract of data from source systems into a defined format,
ii. transformation of the extracted data into the required formats for use
by the dashboard (data warehouse & dashboard display), and
iii. load of the data into the Clinical Dashboard data warehouse or
Dashboard Display.
b. Dashboard Presentation – provision of a display layer that allows the
dashboard data (metrics) to be presented in a variety of forms (textual,
graphical, etc) for consumption by a variety of users (clinicians, public, etc).
c. Reporting & Analysis – provision of functionality that allows analysis of the
metrics in greater detail (analysis) and the creation of specialised reports
summarising this analysis.
d. Pseudonymisation / Anonymisation Service - provision of functionality that
allows the removal or obscuring of sensitive patient or clinical data to
ensure only authorised clinicians have access to this material.
e. Data Integration Service – provision of a service that allows the automated
data extraction, transformation and load processes to be executed as
required. This includes the interoperability information flow specifications
and transport standards.
f. Data Management – provision of a service that allows the clinical data to be
created, updated, deleted, structured and summarised as required.
g. Meta Data Management – provision of a service to manage and provide
access to information about the data, e.g. the provenance of the data and
what a log of the transformations that have been performed on it.
h. Manual Data Entry – provision of functionality that allows data to be
incorporated into the dashboard through manual processes, e.g. manually
uploading a correctly formatted data file.
i.
Development Tools – provision of development tools to allow the
dashboard to be modified as required by the Trust.
3. Infrastructure & Security – identifying the underlying services that support the
delivery of the dashboard functionality through the defined channels:
a. Data Storage – provision of a data storage service in which the data
required for the dashboard (files, database, etc) can be stored and
accessed by the application.
b. Servers – provision of servers to deliver the data an application to the users
in the desired format and with the desired reliability, resilience,
performance, etc.
© Crown Copyright 2017
Page 6 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
c. Information Security – provision of mechanisms that can be used to secure
access to the data and ensure that only authorised clinicians can access
the data displayed by the dashboard.
d. Directory Services – provision of support for the use of user identities and
access profiles (roles & groups).
e. Network Services – provision of services to manage secure connectivity to
dashboard servers for clients.
f. Identity & Access Management – provision of service the manage access to
the dashboards through a role-based access control mechanism linked to
the users identify.
2.1.2 Conceptual Information Flow
The Conceptual Information Flow Model below provides an overview of the flow of
information from:
1. Source Systems (GP Systems, Patient Admission Systems, etc) extracted in
varying
2. Data Interchange Formats (XML, CSV, etc) through a
3. Extract, Transform, Load (ETL) and Data Architecture layer where the data is
transformed for display in the
4. Presentation Layer (Dashboard, Reports, etc) and
5. Display on the Dashboard or Output to a File, Printer, etc,
and the underlying functionality supporting this flow:
1. Security & Access Control – ensuring only authorised clinicians have access to the
data,
2. Audit & Logging – ensuring access is logged for auditing purposes,
3. Meta Data Management - provision of a service to manage and provide access to
information about the data, e.g. the provenance of the data and what a log of the
transformations that have been performed on it.
4. Service Management – provision of a service to support normal operation of the
solution that meets business needs for availability, performance, backup &
recovery, etc.
© Crown Copyright 2017
Page 7 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
It is worth noting that this is a conceptual model and different vendor solutions will
implement these capabilities in different ways, for example some of the new BI tools
make use of in memory databases and provide the automatic management of the source
input data, removing the need to explicitly design and build the fact and dimension data
structures.
2.1.3 The Interoperability Approach
The data integration approach needs to be considered as part of the project. The most
immediate thinking may be for a push based file transfer approach but there may be
longer term advantages to taking a pull based web services approach. Understanding the
longer term strategy for information sharing and exchange can help in the decision
making.
2.1.4 The Interoperability Transport Options
There are a number of transport options that need to be considered.
For a file transfer based approach it is recommended that the NHS DTS service is used
rather than a point to point secure file transfer as this typically requires firewall changes
on N3 and DTS is already setup and in operation to provide file transfer between NHS
Organisations. Further details about DTS can be found on the CFH website at
http://nww.connectingforhealth.nhs.uk/nhais/dts
© Crown Copyright 2017
Page 8 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
The use of NHSmail is also possible for secure file transfers but it is not the
recommended approach. If you do plan to use this approach please discuss it with the
national team.
If a secure FTP approach is decided to be adopted then it is recommended for security
reasons that an FTPS approach rather than SFTP is adopted.
The key reasons for the recommendation of DTS are:




Quick and easy to set up – DTS mailboxes are quick and simple to set up, plus
very simple “file drop” mechanism for transmitting files.
File Size – Easily support the typical data flows required, including any initial
historical loads
Speed – no need for ultra high-speed, typically an overnight batch file
transmission
Tracking – DTS features for tracking the file, confirming progress etc. can be very
useful
The files will typically contain bulk Patient Identifiable data, therefore it is recommended
that the ordinary DTS security be supplemented by also encrypting each file before
transmission.
For a more real-time or pull approach the use of Interoperability Toolkit Specification Web
Services is recommended. Further details can be found at url below, however if you do
plan to take this approach the national team will help to link you with the ITK team as
some of the specification development is currently under development.
http://www.connectingforhealth.nhs.uk/systemsandservices/interop
2.1.5 Interoperability flow specifications
A number of message specifications are being developed to support the information
flows required for urgent care dashboards. The current set of specifications is as follows:




Patient Master Index (PMI)
Walk In Centre or Out of Hours Encounters
Accident & Emergency Attendances
Inpatients Admissions & Discharges
The messages are based on the data items used for the NHS Bolton implementation but
are being updated to fully align with the NHS Data Dictionary and to be specified using
an HL7V3 approach using a message model. The resulting message specifications will
be XML rather than CSV based to support future use for more realtime flows and
exchanges using web services.
The PMI feed is expected to be used from all settings that are providing encounters or
attendances. Therefore from each source system there would be a daily or more frequent
transfer of PMI and Encounter/Attendance data.
2.1.6 Interoperability source system providers
There are a number of commonly used source systems in the urgent and emergency
care settings and work is in progress to engage with these suppliers. The aim is to
complete one off development with each supplier such that the data feed as defined in
© Crown Copyright 2017
Page 9 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
the specification above is available for deployment on each urgent care dashboard
project without any development work. There will however be deployment, testing and
on-going support activities for each project.
The current supplier and systems is as follows:
Adastra
Ascribe Symphony
TPP SystmOne
2.2 Non-Functional Requirements
In addition to the Functional Requirements the Non-Functional Requirements for the
selected solution also need to be given consideration.
An approach to this is to use the Extended ISO 9126 Model of Software Quality
(QUINT2) as a checklist to consider if the characteristics are applicable to the desired
solution and if they are how they are being addressed. QUINT2 covers the following
characteristics and is described in greater detail in Appendix A:
1. Functionality - the systems functions and their specified properties.
2. Reliability - the systems capacity to maintain its level of performance under stated
conditions for a stated period of time.
3. Usability - the effort needed for use, and the individual assessment of such use, by
a stated or implied set of users.
4. Efficiency - the relationship between the level of performance of the software and
the amount of resources used, understated conditions.
5. Maintainability - the effort needed to make specified modifications.
6. Portability - the ability of the software to be transferred from one environment to
another.
There is a << Statement of Requirements (SOR) >> provided in the Clinical
Dashboards Toolkit which includes Section 3.3 covering the key non-functional
requirements for the solution implemented during the Pilot Programme.
Any non-functional requirements considered here should also be reviewed in conjunction
with the following specific requirements around Security and Infrastructure:
2.2.1 Security
The requirement for a detailed level of Security requirements around access to both the
dashboard and to the clinical data held within the dashboard solution is highly important
from a clinical safety and patient privacy perspective.
As such the following items should be considered as part of the solution:
1. Use of HTTPS (TLS v1.0) to encrypt all data transfers between the dashboard
servers and the client applications.
2. Use of secure transport mechanisms for any cross organisational data transfers
required by the dashboard solution.
3. The use of encryption to protect any data while in transit.
4. User Authentication options:
© Crown Copyright 2017
Page 10 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1

Typically authentication of users is performed via Active Directory Domain
based authentication of users but this could create issues for any off domain
users, e.g. Primary Care Trusts and GP’s.

NHS Smartcard based authentication could be deployed for off domain users
but required additional infrastructure and software. If Smartcards are not used
then review of the approach and strength of authentication mechanism must be
considered.
5. Information Governance should be considered as described in the Clinical
Dashboard Pilot Programmes – Information Governance Guide which highlights
the need for Information Sharing Agreements when data is being shared between
organisations (Section 4.3.3).
2.2.2 Infrastructure
The analysis and agreement of the infrastructure required for the urgent care dashboard
solution is also a key activity. A number of factors will determine the approach including
the local strategy, existing infrastructure and BI capability.
As such the following items should be considered as part of the solution:
1. Single Server setup – is a single server scenario appropriate for the needs to the
Trust. For example, this may be a lower cost option but could it support high
numbers of concurrent users and meet availability and resilience requirements?
2. High Availability setup – is a multiple server scenario appropriate for the needs to
the Trust. For example, this will be a higher cost option but could provide better
levels of performance for high numbers of concurrent users, and higher availability
and resilience for dashboards considered to be of a critical nature?
3. Virtual Machines setup – is a virtual server scenario appropriate to make better
use of existing hardware, support availability and resilience requirements, and
allow simple and rapid creation of multiple environments for testing, support and
production?
4. Workstation & Browser Compatibility – are there requirements for the server
solution to be compatible with currently deployed workstation operating systems
and web browser versions.
5. Storage (Local Server Disk vs. Storage Area Network (SAN)/ Network Accessible
Storage (NAS) - all the Pilot Projects used local server disk for storage as the
additional cost and overhead to make use of SAN or NAS solution were not
justifiable. However trusts should consider how best to fit the extra data storage
requirements into their existing infrastructure plans.
© Crown Copyright 2017
Page 11 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
3 Solution Options
During the Pilot Programme a number of solution variants have been deployed as a
result of differences in local information strategy and capability. It is recommended that
any clinical dashboard project takes time to understand their existing systems landscape,
technical capability and information strategy as key inputs to their high level solution
architecture.
This section provides a summary of the different solutions and within them the options for
handling data processing and summarisation in the information flow from source
system(s) to the dashboard.
3.1 Dashboard & Reports accessing an existing Data Warehouse
If an existing data warehouse contains some or all of the clinical data required to support
the dashboard requirements then one approach is to build and deploy the dashboard and
reporting functionality making use of the existing data warehouse.
Such an implementation can take a number of forms depending on the exact content of
the data warehouse:
1. If all the required data is present in the existing data warehouse consider building any
further data processing into the existing data warehouse and connecting the
dashboard directly to the existing data warehouse.
2. If some of the required data is present in the existing data warehouse and some
needs to be extracted from other systems consider either:
2.1. extracting the data from the other source systems and loading into the existing
data warehouse so that all required data can be presented consistently to the
dashboard application from a single location, or
2.2. configuring the dashboard application to extract the data directly from both the
data warehouse and other systems, and then either display/report the data as
required.
In these scenarios there are options as to where any summarisation of the data occurs
prior to display on the dashboard or output to a report:
1. The summarisation could be performed as part of the Extract, Transform and Load
(ETL) process within the existing Data Warehouse, or
2. The summarisation could be performed as part of the extraction process from the
source systems.
The extent to which existing dashboards and reports are delivered to the same types of
users will make a difference to the delivery. If there is no portal or delivery mechanism to
make the dashboard and reports available in the GP Practices this will need to be setup
as part of the project.
© Crown Copyright 2017
Page 12 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
3.2 Dashboard & Reports building a new dedicated Data Warehouse
If there is no existing data warehouse then the recommended approach is to create a
new dedicated Clinical Dashboard data warehouse that focuses on collating and
summarising the required clinical data from the existing Trust systems.
Such an implementation can take a couple of forms depending on the existing systems
and the Trusts supporting skills:
1. If the existing system support teams are able to provide both data extract and
summarisation from the existing Trust systems as part of the provision of the data
from the source system then the approach should be to:
1.1. define both the detailed data and summarised data required from these systems,
1.2. define the format it is required in, and
1.3. implement the required data extraction & summarisation processes.
Once the data has been extracted it can be loaded into the Clinical Dashboard data
warehouse with minimal further data processing required for display on the
dashboards and output as reports.
2. If the existing system support teams are only able to provide basic data extracts from
the existing Trust systems then the approach should be to:
2.1. define the data required from these systems,
2.2. define the format it is required in, and
2.3. implement the required data extraction processes.
Once the data has been extracted it can be loaded into the Clinical Dashboard data
warehouse and summarised as required for display on the dashboards and output as
reports.
3.3 Dashboard & Reports using Software as a Service
There is a third option for the delivery of the dashboard solution and that is using a SaaS
provider. This approach is becoming more common and there are several companies
who are already providing BI solution to the NHS using the SaaS model. There are pros
and cons of this approach which need to be carefully considered before making a
decision, but in cases where there is limited infrastructure and BI capability locally or
limited capital funding to develop an in house capability an outsourced and revenue
based solution can be an attractive option.
© Crown Copyright 2017
Page 13 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
4 Market Overview & Business Intelligence Products
During the Pilot Programme two business intelligence solutions were used across the 11
Trusts. The main solution was based on the Microsoft business intelligence product stack
with some healthcare and dashboard specific pre-configuration provided by System C
Healthcare who were used as the main systems integrator and BI solution supplier. The
alternative pilot solution, which as deployed at 1 Trust, was based on an existing
Business Objects solution. This included an extensive data warehouse and reporting
solution that was enhanced with the Business Objects Xcelius dashboard tool to deliver
the front end solution. Both of these solutions have been successfully deployed and
would provide suitable solutions for other clinical dashboards.
There are a wide range of other business intelligence products and solutions available on
the market that we have not been able to test, but we would expect could also provide
effective dashboard solutions. The following provides a view of a number of BI vendors
that are active in the healthcare industry and who we would expect to have the majority
of the capability required to deliver the data layer and dashboard/reporting elements of
an urgent care dashboard solution.
Ardentia
Dynistics
MedeAnalytics
PiBenchmark
QlikView
HealthAnalytics
It is also worth noting that a number of the GP System suppliers are also developing
Dashboard and Reporting solutions such as TPP, EMIS, and In Practice and in some
situations using the GP system to deliver the urgent care dashboard could be a good
approach.
© Crown Copyright 2017
Page 14 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG
21/03/2011 / Draft / 0.1
Appendix A - QUINT2
Reviewing each of the characteristics and sub characteristics provides the opportunity to
consider if they are applicable to the desired solution and if they are how they are being
addressed:
1. Functionality – consider the systems functions and their specified properties:
 Suitability
 Accuracy
 Interoperability
 Compliance
 Traceability
2. Reliability - consider the systems capacity to maintain its level of performance
under stated conditions for a stated period of time:
 Maturity
 Fault Tolerance
 Recoverability
 Availability
 Degradability
3. Usability – consider the effort needed for use, and the individual assessment of
such use, by a stated or implied set of users:
 Understand ability
 Learn ability
 Operability
 Explicitness
 Customizability
 Attractiveness
 Clarity
 Helpfulness
 User-friendliness
4. Efficiency – consider the relationship between the level of performance of the
software and the amount of resources used, understated conditions:
 Time behaviour
 Resource behaviour
6. Maintainability – consider the effort needed to make specified modifications:
 Analyzability
 Changeability
 Stability
 Testability
 Manageability
 Reusability
7. Portability – consider the ability of the software to be transferred from one
environment to another:

Adaptability
© Crown Copyright 2017
Page 15 of 16
Urgent Care Clinical Dashboards High Level Solution Guide
CD-HL-SG



21/03/2011 / Draft / 0.1
Install ability
Conformance
Replace ability
© Crown Copyright 2017
Page 16 of 16