To develop and implement the Datawell Platform

To develop and implement the Datawell Platform

Datawell is an innovative informatics platform that enables health data to be shared and provides Greater Manchester, East Cheshire and East Lancashire.

United Kingdom-Salford: IT services: consulting, software development, Internet and support

2015/S 108-196688

Contract notice

Services

Directive 2004/18/EC

Section I: Contracting authority

I.1)Name, addresses and contact point(s)

Salford Royal NHS Foundation Trust
Summerfield House, 544 Eccles New Road
For the attention of: Sarah Golby
M5 5AP Salford
UNITED KINGDOM
Telephone: +44 1612123716
E-mail: sarah_golby@nhs.net

Internet address(es):

General address of the contracting authority: http://www.sbs.nhs.uk/

Address of the buyer profile: https://uk.eu-supply.com/ctm/Supplier/CompanyInformation/Index/39

Electronic access to information: https://uk.eu-supply.com/app/rfq/rwlentrance_s.asp?PID=12475&B=NHSSBS

Electronic submission of tenders and requests to participate: https://uk.eu-supply.com/app/rfq/rwlentrance_s.asp?PID=12475&B=NHSSBS

Further information can be obtained from: The above mentioned contact point(s)

Specifications and additional documents (including documents for competitive dialogue and a dynamic purchasing system) can be obtained from: The above mentioned contact point(s)

Tenders or requests to participate must be sent to: The above mentioned contact point(s)

I.2)Type of the contracting authority

Body governed by public law

I.3)Main activity

Health

I.4)Contract award on behalf of other contracting authorities

The contracting authority is purchasing on behalf of other contracting authorities: yes

As indicated below in II.1.5)

Section II: Object of the contract

II.1)Description

II.1.1)Title attributed to the contract by the contracting authority:

To develop and implement the Datawell Platform.

II.1.2)Type of contract and location of works, place of delivery or of performance

Services
Service category No 7: Computer and related services
Main site or location of works, place of delivery or of performance: Salford.

NUTS code UKD

II.1.3)Information about a public contract, a framework agreement or a dynamic purchasing system (DPS)

The notice involves a public contract
II.1.4)Information on framework agreement

II.1.5)Short description of the contract or purchase(s)

Datawell is an innovative informatics platform that enables health data to be
shared and provides Greater Manchester, East Cheshire and East Lancashire
with a development resource that accelerates the delivery of improvements in
health outcomes and costs effectiveness. Datawell consists of two
complementary programmes: The Datawell Exchange and the Datawell
Accelerator. a) The Datawell Exchange will enable efficient sharing of data and
provide the appropriate safeguards for privacy, in order to provide a platform
which member organisations, including clinicians and researchers, will be able to
build on to create innovative solutions for care. This will be the core
technological environment that will need to be developed to make the existing
ground-breaking innovation routine and simple for all members. b) The Datawell
Accelerator will be a collection of project-driven partnerships combining resource
from NHS members, our Universities and industry to create an affordable,
enhanced capability to run evaluations and pilots of new ideas. These
partnerships will build on existing locality plans and support better knowledge
sharing between members.
The minimum requirements of the solution are set out below. Bidders must be able to demonstrate their ability to meet all of these minimum requirements.
Datawell Node
Storage of structured and unstructured data.
— The system must allow the storage of structured and unstructured data, including free text, coded data and semi-structured information
— Data must be searchable by patient or data types. For example the results returned may be for a selected patient, or select data for all patients matching set criteria such as diagnosis or pathology result.
— The application must be able to use NHS numbers to identify patients.
— Each Dataset Definition and Dataset must have a unique reference identifier within the Exchange. All individual data items (Attributes) within a Dataset Definition must be associated with a corresponding entry from the Universal Data Dictionary. The same Attribute may be referenced in any number of Dataset Definitions.
— Data will include health data sources and ETL processes must link to existing systems as data sources with near live updates of information.
Metadata catalogue of available data and metadata/entity management
— A catalogue of available data and data types must be available and searchable to support the generation of new Dataset definitions, and to support the ability to compare related or similar data.
Universal data dictionary — OpenEHR, HL7, ICD9, ICD10, Read, SnomedCT
— A standard semantic data dictionary must be defined to enable disparately sourced data to be linkable across the Exchange regardless of its originating representation. For example, a data source may record a patient’s blood pressure in a database table with a column named ‘BP’, whilst another data source may record the same information in a database table column named ‘BloodPressure’. Critically, we must be able to interpret both these attributes as equivalent, by mapping both such attributes onto the same semantic term ‘Measurement. BloodPressure‘, and also ensure that the value representation is consistent — one source system might record blood pressure as mmHg (millimetres of Mercury displacement, UK) whilst another might use kPa (kilopascals, USA).
— The Universal Data Dictionary forms the domain of attributes, known as Archetypes, that can be selected from to form a Dataset Definition. The Universal Data Dictionary will evolve over time with the accrual of new Archetype definitions. Such changes must be carefully managed and a scheme implemented to enable Nodes to maintain synchronised versions of the Universal Data Dictionary.
— Healthcare information such as medications, procedures, diagnoses, lab tests etc, are normally encoded with reference to a well-defined vocabulary. Examples of such coding schemes currently in use include SNOMED-CT, ICD-10, LOINC. The Universal Data Dictionary must make reference to such vocabularies as part of the semantic definition for an Archetype.
— Medical ontologies are versioned and updated on a regular basis. Exchange Nodes must have a mechanism that enables them to accrue such updates over time, and for this to be synchronised across all Nodes in the Exchange.
Security and access
.
— Exchange nodes must maintain data query and transfer logs for reporting on information flow to enable governance audit, systems performance and security monitoring.
— The system must enforce the principle of “least permission respected” when assessing whether a use or system has access to an individual data item, taking into account user authentication and authorisation against roles permissions and data sharing agreements. “Break the Glass” scenarios may override this but must be appropriate alerted and audited.
Adminstration Portal
— Each Exchange Node must have its own secure administration portal to enable all aspects of the system to be controlled and maintained by local users (Administrators) with the specific authority to do so.
— The portal must provide all aspects of system monitoring for performance and user behaviour tracking, and for configuration and management of the various components and associated metadata that constitute the Node.
— All changes effected by Administrators to the system configuration must be logged, and made visible within the portal and available for separate audit report.
— The web user interface must include meaningful visual dashboard presentation to show the current state of the system, to generate alerts where parts of the system may not be functioning correctly, and to highlight where End User or external system behaviour is outwith normal operating parameters.
— All data transfer activity that passes through the Exchange Node must be logged and made accessible within the Administration portal, providing tabular presentation and visual graphs over time and enabling instantaneous reporting through dynamic selection and aggregation on the various dimensions of Requests/Responses such as Requester, Responder, EndUser, Query, Status etc.
Basic analytics capability for reporting of data
— The node must have a core set of web-based applications that are available “out of the box” in order to demonstrate immediate value and capability for the node.
— One application must have the ability to view all data, or a defined type of data, about a single patient. For example, to be able to show a complete medical history, or a list of pathology results.
Exchange Node Clocks
— A common time reference must be used by all Nodes throughout the Exchange, namely Co- ordinated Universal Time (UTC) resolvable to the calendar date (century, year, month, day) and time of day (to the nearest millisecond). Although leap days/seconds must be incorporated, no adjustment for daylight savings is required — UTC is equivalent to Greenwich Mean Time (GMT).
— Individual Node clocks must be kept in sync to the nearest millisecond.
Datawell Exchange
Managed sharing
— The Exchange must directly implement managed sharing, connecting each participating organisation’s Exchange Node and filtering data transfers to enforce the rules defined through the combination of data sharing agreements from organisational through to an individual’s permission settings.
— The Exchange must immediately honour any changes made to the deployed sharing agreements, whether to restrict or to expand.
— The Exchange must also provide the facility to transform data before delivery, specifically to apply de-identification according to the rules defined in the Data Sharing Agreement currently in effect between the sender and receiver.
Governance audit
— Exchange nodes must maintain data query and transfer logs for reporting on information flow to enable governance audit, systems performance and security monitoring.
Flexible data exchange
— The Exchange must support different modes of transfer including: pull requests, for small scale on demand distributed queries for individual data item sets (e.g. for servicing a patient point-of-care application); push requests, for large scale scheduled bulk dataset delivery (e.g. for servicing a secondary population research analysis).
— The Exchange must support both standard core Dataset Definitions to drive a minimum level of application functionality
Standards conforming
— The Exchange must implement a range of healthcare interoperability standards including but not limited to: NHS Information Toolkit (ITK), HL7-V2, HL7-FHIR, ITU- T-H.860, IHE XDS, OpenEHR as required to support a range of downstream applications.
Security and Audit
— All data transfers between nodes must be encrypted ‘in flight’. Transfers between specific pairs of Exchange Nodes should be encrypted with different keys, such that compromise or publication of a key pair does not expose data exchanged between other pairs of Nodes. In case of such a security breach, it must be possible to invoke an immediate change of encryption keys used throughout the Exchange.
— The data transfer logs must record sufficient information to enable audit of who/when/what for each transfer event, but also for unusual patterns of access to be identified and flagged for further investigation. FairWarning is an example of a commercial product, currently used by the NHS, for analysing data access logs for potentially inappropriate activity.
— An Exchange Administrator must have the facility to immediately disable responses being generated to queries originating from a specific End User across the entire Exchange.
End User Registry
— An End User Register must be implemented across all Nodes in the Exchange to ensure a consistent view of the same user is maintained regardless which Organisations they may be employed by over time, or their level of site to site mobility that may be a characteristic of their job. The same single unique identifier must apply to the same user irrespective of their original registration Node. This requires Exchange Nodes to participate in shared End User Register updates and to implement a scheme for resolving potential duality of user identity.
— The Administration and Audit Portal must support the creation, update, suspension and deletion of an End User, recording a range of descriptive and contact information for each person.
Repeatability
— Whilst the Transfer Log does not make record of the Response Datasets generated, it must capture sufficient information to enable the Request to be rerun under the same system-wide state in order to generate the same Response Datasets, and in particular the same cohorts of individuals.
Break the Glass
— Certain AccessRoles, e.g. a consultant in A&E, must be able to be given the special permission ‘Break-The- Glass’. This follows the standard procedure within the medical profession, whereby an EndUser with this permission can access an individual’s data after interacting with a separate challenge and response mechanism within an EHR application for example. Break-The-Glass events are typically separately monitored and audited with professionals having to justify their use. The Exchange must be able to support this scenario.
Datawell Exchange API
— A set of open Datawell APIs must be defined for specifying on-demand broadcast data transfer queries, scheduled transfer queries, audit queries, data sharing agreements and system management such as registration/withdrawal of Nodes from the Exchange network.
— The Datawell APIs must include a separately secured Administration API and Data Transfer API. Only the basic requirements for these APIs are described in the following sections, additional capabilities remain to be defined.
Data
— In order to support the successful use of the Datawell Exchange bidders must have or develop a common information architecture that defines the format and definition for health information to be shared. This definition will constitute the minimum core dataset for the exchange, and provide the core structures that will need to be mapped to individual systems within Exchange member environments. The benefits of this common data architecture must include:
— Identify and source the data needed to share between organisations and to support the development of new applications
— Make it possible to uniquely define a new data element within a minimum data set
— Establish the derivation of a given data element from its root sources.
— Build common business rules about data and have them apply across the conurbation.
— The key purpose in developing the Data Architecture must be to support the software applications that will use and access shared data across the Exchange. It will also facilitate the ability to link datasets between different sources and 3rd party datasets.
— The model must balance this flexibility against the need to provide a concrete software implementation that can be assured to meet external data standards and be optimised to provide rapid, appropriate and secure access to data.
— A recommended data model must be flexible enough to accommodate multiple types of use, including export for inclusion in other clinical record systems, point of care use, research, clinical audit, business intelligence and quality and safety monitoring
— The node solution must provide a basic dataset definition in line with national and international standards such that access to the data by the data owners is always possible. There are a number of standards for the storage and interchange of health data for use by electronic health record systems. Examples of Reference Models include HL7, NHS Interoperability Toolkit (based on HL7), XDS, EN13606 European Standard for Health Informatics, and openEHR.
— The data owner must always be able to extract or completely remove their own data
— The data owner must always be able to add additional datasets based on own data sources and extend the nodes data catalogue as required. Data that can be included in the node will cover: PAS, pathology, medications and prescribing, health resource utilisation, critical care, speciality data, out patient information, emergency admissions (A&E), community and intermediate care, mental health, social care, GP and other primary care.
— It must not be possible for any system to access data, either locally or via the Exchange, without the appropriate information sharing agreements permitting use. Patient consent models must also be respected.
Analytics and Business Development
A core objective for Datawell is to support the innovative use of data to improve outcomes for patients and the efficiencies of the whole GM health and social care system. Therefore there is a requirement for provision of business analysis and data analysis support of the program, as well as provision of specific support to members during roll-out to help identify value and project opportunities created by the Datawell platform.
Specific tasks must include:
— Map current organisational data flows, both internal and external, that are relevant to Datawell projects. At a minimum this must include Hospital Episode Statistics, pathology, prescribing, admissions, diagnosis and other patient episode data.
— To identify metadata definitions and potential quality issues to create dataset definitions and metadata that will help Datawell users in accessing and using the data. Create a metadata catalogue that must define data content, including coding schemes.
— Establish working groups internal to members in order to develop informed knowledge about the use and purpose of the data, identify requirements for data sharing and requirements that may be relevant to future Accelerator projects
— Identify and document local value propositions, within the framework established in the Business Case, and develop bespoke business cases for Accelerator projects that will support the development of Datawell and demonstrate its effectiveness in improving patient safety and outcomes, reducing costs and creating efficiencies.
— To identify and map existing applications and APIs within member organisations.
— Support the development of data models for use in the Nodes and Exchange.
— Maintain the programme governance framework, including reporting to Board meetings, setting up and maintaining the Reference group and maintaining Public Patient Involvement plans.
— Develop an information governance framework and common information sharing agreements for use in the Datawell Exchange. Where possible existing best practice should be maintained.
— Create a catalogue of existing data sharing agreements and establish a plan where migration to a new data sharing agreement is required.
— Ensure that the design of the Datawell programme complies with essential legal and ethical frameworks and supports national and local initiatives for data sharing. Links with appropriate national and local groups, including HSCIC, the GM Informatics Board, local Health and Wellbeing Board, Directors of Public Health, and others, should be maintained and reported. Datawell must also fit with Local Authority plans, directed by AGMA, and the future development of Devolution in Greater Manchester.
— Continue the promotion of the objectives of the Datawell programme through member engagement, local workshop and conference activity.
— Develop a Datawell Business Model which will create a sustainability plan for beyond the initial three year funding plan.
.
This service is being potentially being procured on behalf of:
Bolton Clinical Commissioning Group, Bury Clinical Commissioning Group, Central Manchester Clinical Commissioning Group, Eastern Cheshire Clinical Commissioning Group, Heywood Middleton and Rochdale Clinical Commissioning Group, North Manchester Clinical Commissioning Group, Oldham Clinical Commissioning Group, Salford Clinical Commissioning Group, South Manchester Clinical Commissioning Group, Stockport Clinical Commissioning Group, Tameside and Glossop Clinical Commissioning Group, Trafford Clinical Commissioning Group, Wigan Borough Clinical Commissioning Group
Bridgewater Community Healthcare NHS Trust, Central Manchester University Hospital NHS Foundation Trust, East Cheshire NHS Trust, East Lancashire Hospitals NHS Trust, Greater Manchester West Mental Health NHS Foundation Trust, North West Ambulance Service NHS Trust, Pennine Acute Hospitals NHS Trust, Pennine Care NHS Foundation Trust, Royal Bolton Hospitals NHS Foundation Trust, Salford Royal NHS Foundation Trust, Stockport NHS Foundation Trust, Tameside Hospital NHS Foundation Trust, The Christie NHS Foundation Trust, Wrightington, Wigan and Leigh NHS Foundation Trust, University Hospital of South Manchester FT
Blackburn with Darwen Borough Council, Bolton Council, Bury Council, Cheshire East Council, Manchester City Council, Oldham Council, Rochdale Metropolitan Borough Council, Salford City Council, Stockport Metropolitan Borough Council, Tameside Metropolitan Borough Council, Trafford Council, Wigan Council
The duration of the contract is 30 months with the option to extend for an additional 36 months and then a further 24 months if required. The innovation partnership procedure is being adopted. It is intended that 3 economic operators will be taken forward following PQQ.

II.1.6)Common procurement vocabulary (CPV)

72000000

II.1.7)Information about Government Procurement Agreement (GPA)

The contract is covered by the Government Procurement Agreement (GPA): yes

II.1.8)Lots

This contract is divided into lots: no

II.1.9)Information about variants

Variants will be accepted: no
II.2)Quantity or scope of the contract

II.2.1)Total quantity or scope:

Estimated value excluding VAT: 6 000 000 GBP

II.2.2)Information about options

Options: no

II.2.3)Information about renewals

This contract is subject to renewal: yes

II.3)Duration of the contract or time limit for completion

Duration in months: 090 (from the award of the contract)

Section III: Legal, economic, financial and technical information

III.1)Conditions relating to the contract

III.1.1)Deposits and guarantees required:

Performance Bonds, parent company guarantees, warranties, retentions and/or other forms of security may be
required.

III.1.2)Main financing conditions and payment arrangements and/or reference to the relevant provisions governing them:

To be set out in the tender documentation specifically the contract and associated schedule.

III.1.3)Legal form to be taken by the group of economic operators to whom the contract is to be awarded:

The Authority requires that any contract awarded shall be entered into by a single legal entity on the part of the
successful candidate.

III.1.4)Other particular conditions

The performance of the contract is subject to particular conditions: no
III.2)Conditions for participation

III.2.1)Personal situation of economic operators, including requirements relating to enrolment on professional or trade registers

Information and formalities necessary for evaluating if the requirements are met: : As set out in the PQQ which is available from the date of this advert at [ 03/06/2015].

III.2.2)Economic and financial ability

Information and formalities necessary for evaluating if the requirements are met: As set out in the PQQ which is available from the date of this advert at [ 03/06/2015].

III.2.3)Technical capacity

Information and formalities necessary for evaluating if the requirements are met:
Please refer to the Pre-Qualification Questionnaire (PQQ) and associated materials.
As set out in the PQQ which is available from the date of this advert at [ 03/06/15].
III.2.4)Information about reserved contracts
III.3)Conditions specific to services contracts

III.3.1)Information about a particular profession

Execution of the service is reserved to a particular profession: no

III.3.2)Staff responsible for the execution of the service

Legal persons should indicate the names and professional qualifications of the staff responsible for the execution of the service: no

Section IV: Procedure

IV.1)Type of procedure

IV.1.1)Type of procedure

Negotiated
Some candidates have already been selected (if appropriate under certain types of negotiated procedures) no
IV.1.2)Limitations on the number of operators who will be invited to tender or to participate

IV.1.3)Reduction of the number of operators during the negotiation or dialogue

Recourse to staged procedure to gradually reduce the number of solutions to be discussed or tenders to be negotiated no
IV.2)Award criteria

IV.2.1)Award criteria

The most economically advantageous tender in terms of the criteria stated in the specifications, in the invitation to tender or to negotiate or in the descriptive document

IV.2.2)Information about electronic auction

An electronic auction will be used: no
IV.3)Administrative information
IV.3.1)File reference number attributed by the contracting authority:

IV.3.2)Previous publication(s) concerning the same contract

no

IV.3.3)Conditions for obtaining specifications and additional documents or descriptive document

Payable documents: no

IV.3.4)Time limit for receipt of tenders or requests to participate

6.7.2015 – 16:00
IV.3.5)Date of dispatch of invitations to tender or to participate to selected candidates

IV.3.6)Language(s) in which tenders or requests to participate may be drawn up

English. Romanian.
IV.3.7)Minimum time frame during which the tenderer must maintain the tender
IV.3.8)Conditions for opening of tenders

Section VI: Complementary information

VI.1)Information about recurrence

This is a recurrent procurement: no

VI.2)Information about European Union funds

The contract is related to a project and/or programme financed by European Union funds: no

VI.3)Additional information

Bidders should note that the Trust retain absolute discretion as to whether to accept any offer following evaluation.
The Trust is not bound in any way to accept any and reserves the right to make no further contract award under this procurement process.
The Trust shall not be held liable for any liability or cost or expense incurred by any bidder in relation to this project whatsoever, including, without limitations, in relation to the preparation of their tender and any subsequent clarification or any legal or other expenses.
This opportunity is being procured as a single lot given the innovative nature of the requirement does not enable multiple providers to provide the solution.
The term of this contract is for an initial 30 months, with the option to extend for an additional 36 months and then a further 24 months if required. The proposed contract term is necessary to allow time for the selected supplier to develop the solution, roll it out and to cover the level of investment needed. The initial 30 month period covers the remaining term of the GM AHSN’s licence. Bidders should note that at the expiry of the GM AHSN licence, the contract that is the subject of this opportunity may be novated or assigned to a successor body if applicable.
VI.4)Procedures for appeal
VI.4.1)Body responsible for appeal procedures

VI.4.2)Lodging of appeals

Precise information on deadline(s) for lodging appeals: The Trust will incorporate a minimum ten day standstill period at the point information on the decision to award the contract is communicated to bidders. Any bidder wishing to appeal the decision to award the contract, or after the award of the contract appeal the contract, shall have the rights set out in Part 3 of the Public Contracts Regulations 2015.
VI.4.3)Service from which information about the lodging of appeals may be obtained

VI.5)Date of dispatch of this notice:

3.6.2015

Enjoyed this post? Share it!