EoE SNSDE for R&D - Solution to support data harmonisation, cohort discovery, de-identification, and linkage

Description

Summary of work We are looking for a solution which supports a federated approach to data harmonisation, cohort discovery and de-identification and linkage. During this engagement's proof of concept (POC) stages, this solution will operate on subsets of data from NHS data providers. This solution should be designed with the Office for National Statistics (ONS) Five Safes principle firmly at its core. We are looking for an approach which will promote interoperability, scalability and integration with NHS data provider systems. It should provide advanced yet user-friendly tooling to support research and innovation. The selected provider will adapt existing software to deliver a novel solution, alongside operational documentation, to create an extensible MVP within the SDE cloud-based environment and each NHS data provider’s own infrastructure. The solution will be adapted in partnership with the EoE SDE team and the NHS data provider Digital and Information Governance teams. This solution will enable researchers to discovery and gain approved access to a suitable cohort of patient data from the East of England and use it to better understand health care outcomes and drive forward new an innovative solutions while also meeting all information governance requirements. Where the supplied staff will work East of England Who the organisation using the products or services is The host Contracting Authority is Cambridge University Hospitals NHS Foundation Trust. The East of England Collaborative Procurement Hub is working on behalf of the Contracting Authority. This is being procured for the East of England Integrated Care System: NHS CAMBRIDGESHIRE AND PETERBOROUGH (C&P) NHS NORFOLK AND WAVENEY (NWPC) NHS SUFFOLK AND NORTH EAST ESSEX (SNEE) NHS BEDFORDSHIRE, LUTON AND MILTON KEYNES (BLMK) NHS HERTFORDSHIRE AND WEST ESSEX (HWE) NHS MID AND SOUTH ESSEX (MSE) Why the work is being done Our vision is to deliver a Sub-National Secure Data Environment for Research and Development (SNSDE for R&D) for the East of England (EoE) that: 1. Accelerates research to improve the quality of life and reduce health inequalities for people living within our region, promoting the benefits to secure public advocacy and support. 2. Generates new opportunities for research by providing a simpler, faster, and streamlined research user journey while enhancing the quality and quantity of research – including integration with existing advanced, multimodal data assets. 3. Exemplifies patient and public involvement and engagement in research by working with patients and the public in progressive ways to shape local research efforts, thereby enhancing public trust in how their data is used and protected. 4. Drives economic growth by contributing to the attractiveness of the East of England as a place where life science and tech companies want to locate and fund research. 5. Delivers a technical solution which takes measures to minimise its environmental footprint. The East of England is home to a world-renowned clinical, academic, and life sciences community. It is well-placed to harness longitudinal healthcare data at scale to deliver research and innovation that transforms health outcomes. The existing SDE can provide Project Research Environments (PRE) where Researchers can interact via a Virtual Desktop Interface. The SDE platform design is based on the Standardised Architecture for Trusted Research Environments (SATRE). This interface currently provides Researchers with: • Access to their approved research cohort, which is created via a manual process. • Access to software libraries via package managers like PyPI and CRAN. • The ability to ingress de-identified anonymised data to use alongside the approved research cohort, which is de-identified at source. • The ability to egress anonymised results with oversight by an SDE Data manager. The business problem We are looking for a solution which supports a federated approach to data harmonisation, cohort discovery and de-identification and linkage. During this engagement's proof of concept (POC) stages, this solution will operate on subsets of data from NHS data providers. This solution should be designed with the Office for National Statistics (ONS) Five Safes principle firmly at its core. We are looking for an approach which will promote interoperability, scalability and integration with NHS data provider systems. It should provide advanced yet user-friendly tooling to support research and innovation. The primary needs of these POCs and Minimal Viable Product (MVP) will need to fulfil are: • Data Harmonisation: Electronic Patient Record (EPR) and other data from NHS data provider organisations will be mapped to the OMOP common data model and vocabulary to provide researchers with a shared language when using these data. • Cohort discovery: To support researchers in exploring whether the East of England NHS data providers have enough patients to meet their research requirements. • De-identification and linkage: To remove and/or minimise personally identifiable information in the selected/approved cohorts being surfaced on EOE-SDE to meet information governance rules and guidelines and provision harmonised data with OMOP schema, original records and transformation scripts within a researcher’s Project Research Environment (PRE) on the SDE. The chosen partner must work with the SDE technical team and NHS data providers to develop and deliver a synthetic data POC by 28 February 2025, a live data POC by 31 March and then the MVP production service by 30 June 2025. The people who will use the product or service User type: Personas and User Stories Definition: Descriptions of personas and user stories can be found in 00_EoE-SNSDE_Data_harmonisation_Ptr_spec, Appendix 1, SDE Personas and User stories. Which phase the project is in Beta Existing team Description and organigram of the existing team is set out in Appendix 3 SDE Delivery Team Information. Address where the work will be done Remote plus some in person meetings at: Health Innovation East, Unit C, Magog Court, Shelford Bottom, Cambridge, CB22 3AD Working arrangements The supplier team is expected to keep to the delivery team's core working hours (09:00-17:00), to maximise knowledge transfer and time available to work collaboratively across organisations. As a minimum we require the supplier to engage with fortnightly sprint cycles, with two stand-ups per week with the SDE programme management office (PMO) and technical teams. Work is expected to be conducted largely remotely, but the supplier team will need to be able to travel to the Health Innovation East office (in Cambridge) as some in person meetings are expected. Reasonable travel expenses (excluding air travel due to carbon impact) to support the working arrangements will be reimbursed, subject to prior approval. EOECPH and the Trusts shall not be liable for or pay any costs, expenses or losses, whatsoever which may be incurred by any Tenderer in the preparation of their Tender submission. Security and vetting requirements No security clearance needed Latest start date 5 December 2024 Expected contract length Contract length: 0 years 6 months 0 days Optional extension: 0 years 3 months 0 days Budget Indicative maximum: The contract value is not specified by the buyer Indicative minimum: The contract value is not specified by the buyer Contracted out service or supply of resource? Contracted out service: the off-payroll rules do not apply Terms and acronyms Term or acronym: EoE Definition: East of England Term or acronym: SDE Definition: Secure Data Environment Term or acronym: PRE Definition: Project Research Environment, the area a approved research can use to interact with their approved data via a virtual data interface Term or acronym: OMOP Definition: Observational Medical Outcomes Partnership Term or acronym: EPR Definition: Electronic Patient Record Term or acronym: CDM Definition: Common Data Model Term or acronym: UAT Definition: User Acceptance Testing Term or acronym: ETL Definition: Extract, Transform, Load, a pipeline to extract data from multiple locations, transform it and load it into a new data warehouse Term or acronym: POC Definition: Proof of Concept Term or acronym: MVP Definition: Minimum Viable Product Questions and Clarifications 1. You are asking suppliers to keep the tender documentation confidential. Can we share the tender documentation with potential technology partners or sub-contractors? We can confirm that the tender documentation can be shared with technology partners or sub-contractors, however any partners engaged must keep the documentation confidential and not share with any other parties. Last Updated : <strong>16/09/2024</strong> 2. What is the anticipated budget envelope? We are not able to share the budget envelope for this project. Pricing proposals should be submitted by shortlisted bidders as part of their stage 2 responses. Last Updated : <strong>16/09/2024</strong> 3. Who delivered the Discovery and Alpha stages? Following a procurement exercise, Kainos Software Limited were awarded the contract to design and build the MVP for the East of England Secure Data Environment. What they, with close collaboration and involvement of AWS Professional Services, have delivered is covered in section 1.2 of 00_EoE-SNSDE_Data_harmonisation_Ptr_spec. As this engagement will combine the MVP SDE platform and existing functionality from the chosen partner, we felt this best matched the beta definition from https://www.gov.uk/service-manual/agile-delivery#phases-of-an-agile-project Last Updated : <strong>16/09/2024</strong> 4. Which assets are required to be live by March? By March, we expect regional data assets, particularly secondary care, from trusts within the East of England region. Last Updated : <strong>17/09/2024</strong> 5. Do you plan to onboard national assets by March? This work is focussed on supporting cohort discovery across participating NHS Trusts in the region. We may separately bring in national data assets to the EoE SDE in this timeframe, but they are out of scope for this discovery infrastructure work. Last Updated : <strong>17/09/2024</strong> 6. Given that vendors will eventually access PLD after the initial stage of the proof of concept, are you comfortable with using a combination of on-shore and off-shore resources (European and non-European)? If so, then are there any restrictions you have in mind with regards to conducting work off-shore (e.g. only on test data or de-identified data) and locations (e.g. Europe or UK Data Partnership countries only)? All resources must be within the UK. It is not acceptable for any data to be transferred or accessed outside of the UK for any purpose. Last Updated : <strong>18/09/2024</strong> 7. Is it correct to assume that you will be the data controller and that vendors will act as data sub-processors on your behalf, using your systems and infrastructure? Cambridge University Hospitals is the data controller for the East of England Secure Data Environment (and lead organisation). Relevant Data Processing Agreements will be put in place where required. Last Updated : <strong>18/09/2024</strong> 8. You are looking for a proven solution: Could you please outline where you would like that solution to sit on the continuum between fully packaged and delivered as a Service versus being more open-source based using commodity components assembled on your behalf? Any combination would be considered. However, there is a requirement to use existing and proven products that can be "knitted" together in a novel way that meets the specification. Use of open-source tooling is not discouraged, however support response should be considered. Last Updated : <strong>18/09/2024</strong> 9. In the data harmonization section, there is a requirement of “Transform and load (ETL) services which can harmonise synthetic EPRs from the NHS data providers into the Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) v5.4.” Please could you expand on what synthetic EPRs are? Synthetic or "dummy" data will be created to mimic the data we will receive from the requested data fields within the Electronic patient Record (EPR) systems that each data provider are using. The data fields are likely to differ between EPRs. Synthetic data will be used to test the data harmonisation between different providers and the OMOP Common Data Model, prior to tests on live data. Last Updated : <strong>18/09/2024</strong> 10. Please could you provide an indicative budget that will enable us to submit with budget considered. We are not able to share the budget envelope for this project. Pricing proposals should be submitted by shortlisted bidders as part of their stage 2 responses. Last Updated : <strong>18/09/2024</strong> 11. Can you please confirm whether the 750 character limit is for each question on each section (essential skills and experience section and nice to have skills and experience section), i.e. Q1.1 750 characters, Q1.2 750 characters and so on or whether the 750 character limit is cumulative for each section, i.e. 750 characters in total for the essential skills and experience section and 750 characters in total for the nice to haves skills and experience section. We can confirm that the 750 character limit is per question and applies to each question in both essential skills and experience and nice to have skills and experience. Last Updated : <strong>18/09/2024</strong> 12. What is the information governance status in relation to Section 251 CAG and REC Approval for the permission to de-identify assets for the purpose of research? Applications have been made both to the Research Ethics Committee and the Confidentiality Advisory Group to seek ethical approval for the SDE as a database and for the permission to de-identify assets for the purpose of research, respectively. Last Updated : <strong>18/09/2024</strong> 13. What assets will be covered by the CAG and REC approval for the SDE? Assets covered by the approval and so made available through the EoE SDE include all data from patients who have an EPR at participating NHS organisations based in the EoE and who haven’t opted out. The data available through the EOE SDE will initially include structured clinical data collected as part of routine care, subject always to approval from the EOE SNSDE Data Access Committee. Last Updated : <strong>18/09/2024</strong> 14. What is the information governance status of the local information governance framework for the onboarding of local assets? The proposed local information governance framework for the SDE is included within the database protocol which is currently under review by REC and CAG. Last Updated : <strong>18/09/2024</strong> 15. The timeframe for submission of stage 1 suggests submission is on 26/09/2024 at 12:00 but in 4.1 of the tender document it specifies 25/09/2024 as the submission date. Please can you confirm that the correct date is the 26/09/2024 for Stage 1 Submission. We can confirm that the correct date for the Stage 1 Submission is 26/09/2024 at midday. Apologies for the error in 4.1. Last Updated : <strong>19/09/2024</strong> 16. Does the buyer want the supplier to provide the platform and software or to deliver our software on the buyer’s existing platform? For OMOP transformations and surfacing data for discovery within NHS provider organisations, a platform agnostic approach suitable for local deployment would be preferable (or requirements made clear if this needs to be standardised). Tooling to aggregate responses from the data providers and link to the national system via API would ideally sit within the existing SDE footprint. However adjacent infrastructure on AWS, but administratively managed by the SDE, is acceptable. Last Updated : <strong>19/09/2024</strong> 17. The specification suggests “extracting the required information from their record systems including Electronic Patient Records (EPRs) and pathology/pharmacy records.” Can you confirm what LIMS/PIS systems you require a supplier to integrate with? We are currently engaged with different NHS provider organisations to confirm who is participating in this POC and MVP. These organisations all use different systems so what is certain is this system will need to be able to interact with different types of LIMS and PIS systems. We expect the proposed solution to be flexible enough that it can be adapted to new systems as and when these are integrated. Last Updated : <strong>19/09/2024</strong> 18. The specification suggests that the Live Data PoC must integrate with at least 2 different types of EPR data such as EPIC and Cerner. Can you confirm if the PoC/MVP will be required to integrate with others? The POC and MVP will need to integrate with multiple different EPR systems across the East of England as different trusts use different systems. We expect there to be an expansion of systems as we move from POC to MVP. The precise list of systems is still being defined. Epic and Cerner have been given as examples as these are systems in use across East of England Trusts currently. Last Updated : <strong>19/09/2024</strong> 19. How many users do you expect to undertake MVP testing with? We expect the MVP testing to be with at least 3 NHS provider organisations and at least 10 researchers using the Cohort Discovery and delivery services. This may change once use cases have been refined. Last Updated : <strong>19/09/2024</strong> 20. Are you able to share the size and complexity of the datasets (Synthetic and Live) you will be using for both the PoC and MVP delivery. A target dataset for one trust would cover approximately 100,000 patients in one disease area - longitudinal patient records covering ~10 years. This would be split across half a dozen or so tables and take up a few GB of space inflated (uncompressed). This will vary slightly between trusts as the coverage will vary around the number of patients records include, the data fields available, and the length of time that electronic records are available for. The synthetic dataset will be a smaller subset, covering the same breadth of data but likely fewer patients over a shorter time period. Last Updated : <strong>19/09/2024</strong> 21. Can you clarify your build preference for example, would you expect a supplier to adapt existing open-source tools and frameworks (e.g., OMOP transformation scripts) or would you expect a supplier to adapt a commercial-off-the-shelf solution? Any combination would be considered. However, there is a requirement to use existing and proven products that can be "knitted" together in a novel way that meets the specification. Use of open-source tooling is not discouraged, however how actively supported the tool is should be considered. Last Updated : <strong>19/09/2024</strong> 22. Can you clarify your MVP requirement in relation to ‘each NHS data provider’s own infrastructure’. Can each NHS data provider host one or more Kubernetes container images, or a Virtual Machine image, or do you expect new physical hardware and software to be required? Do you have a preferred deployment model agreed? Each NHS provider will provide infrastructure to support execution of a machine image within their compute & GDPR real-estate. We do not expect new physical hardware to be required, nor software beyond the proposed solution. Last Updated : <strong>19/09/2024</strong> 23. Please could an extension be granted that will take us to midday on the 30th September? Unfortunately, we are unable to grant an extension due to the tight timescales we have to deliver this project. Last Updated : <strong>19/09/2024</strong> 24. Can you please confirm where we should add that we are bidding with another firm? Please include your bidding model and company names at the top of the supplier response box for Essential Skills and Experience. Please note that this will not be included within the character count. Last Updated : <strong>25/09/2024</strong>