Datawell is an innovative informatics platform that enables health data to beshared and provides Greater Manchester, East Cheshire and East Lancashirewith a development resource that accelerates the delivery of improvements inhealth outcomes and costs effectiveness. Datawell consists of twocomplementary programmes: The Datawell Exchange and the DatawellAccelerator. a) The Datawell Exchange will enable efficient sharing of d...
Datawell is an innovative informatics platform that enables health data to beshared and provides Greater Manchester, East Cheshire and East Lancashirewith a development resource that accelerates the delivery of improvements inhealth outcomes and costs effectiveness. Datawell consists of twocomplementary programmes: The Datawell Exchange and the DatawellAccelerator. a) The Datawell Exchange will enable efficient sharing of data andprovide the appropriate safeguards for privacy, in order to provide a platformwhich member organisations, including clinicians and researchers, will be able tobuild on to create innovative solutions for care. This will be the coretechnological environment that will need to be developed to make the existingground-breaking innovation routine and simple for all members. b) The DatawellAccelerator will be a collection of project-driven partnerships combining resourcefrom NHS members, our Universities and industry to create an affordable,enhanced capability to run evaluations and pilots of new ideas. Thesepartnerships will build on existing locality plans and support better knowledgesharing 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 NodeStorage 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 ExchangeManaged 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 functionalityStandards 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 DevelopmentA 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 GroupBridgewater 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 FTBlackburn 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 CouncilThe 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.
Login
