Library

Browse and search developer information

Urgent Care Clinical Dashboard Solution Architecture Guide

By Connecting for Health | 2011

Introduction

This article provides a technical guide to developers wishing to implement an Urgent Care Clinical Dashboard for a 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.

Functional Requirements

Conceptual Technology Services

The Conceptual Technology Services Model below in figure 1 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.

Figure 1 - Conceptual Technology Services Model.

Figure 1 – Conceptual Technology Services Model.

Channels – identifying the various routes through which information from the dashboard can be received:

  • Desktop User Interface – provide access via desktop application such as a web browser.
  • Large Panel Display – provide the ability to display dashboards on large screens in clinical locations for public or clinical consumption.
  • Portal – provide the ability to expose dashboard components via an existing portal.
  • Data Extract – provide a mechanism through which data can be exported on a scheduled basis in to standard formats such as CSV or XML.
  • Alerts – provide a notification mechanism for updates, alerts, errors, etc.

Application Services – identifying the key functionality to be supported by the dashboard application:

  • Extract, Transform and Load – provision of functionality to allow:
    • extract of data from source systems into a defined format,
    • transformation of the extracted data into the required formats for use by the dashboard (data warehouse and dashboard display), and
    • load of the data into the Clinical Dashboard data warehouse or Dashboard Display.
  • 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).
  • Reporting and Analysis – provision of functionality that allows analysis of the metrics in greater detail (analysis) and the creation of specialized reports summarizing this analysis.
  • Pseudonymisation / Anonymisation Service – provision of functionality that allows the removal or obscuring of sensitive patient or clinical data to ensure only authorized clinicians have access to this material.
  • 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.
  • Data Management – provision of a service that allows the clinical data to be created, updated, deleted, structured and summarized as required.
  • 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 a log of the transformations that have been performed on it.
  • 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.
  • Development Tools – provision of development tools to allow the dashboard to be modified as required by the Trust.

Infrastructure and Security – identifying the underlying services that support the delivery of the dashboard functionality through the defined channels:

  • 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.
  •  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.
  •  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.
  •  Directory Services – provision of support for the use of user identities and access profiles (roles and groups).
  •  Network Services – provision of services to manage secure connectivity to dashboard servers for clients.
  •  Identity and Access Management – provision of service the manage access to the dashboards through a role-based access control mechanism linked to the users identify.

Conceptual Information Flow

The Conceptual Information Flow Model below in figure 2 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 and Access Control – ensuring only authorised clinicians have access to the data,
  2. Audit and 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 and recovery, etc.
Figure 2 - Conceptual Information Flow.

Figure 2 – Conceptual Information Flow.

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.

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.

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 here.

The use of NHSmail is also possible for secure file transfers but it is not the recommended approach.

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 here.

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.

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 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

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 at the end of this article:

  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.

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:
    • 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, in particular the need for Information Sharing Agreements when data is being shared between organisations.

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 and 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.

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.

Dashboard and 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:
    • 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
    • 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.

Dashboard and 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 summarizing 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:

    • define both the detailed data and summarized data required from these systems,
    • define the format it is required in, and
    • implement the required data extraction and 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:

    • define the data required from these systems,
    • define the format it is required in, and
    •  implement the required data extraction processes.

Once the data has been extracted it can be loaded into the Clinical Dashboard data warehouse and summarized as required for display on the dashboards and output as reports.

Dashboard and 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.

Market Overview and 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.

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
  5. Maintainability – consider the effort needed to make specified modifications:
    • Analyzability
    • Changeability
    • Stability
    • Testability
    • Manageability
    • Reusability
  6. Portability – consider the ability of the software to be transferred from one environment to another:
    • Adaptability
    • Install ability
    • Conformance
    • Replace ability