DHSC: Medical Technology - Products Information Management System - Beta phase

Description

Work done so far We completed an in-house discovery phase which involved speaking with over 25 stakeholders from across the health system to better understand user characteristics, needs, and journeys. This included representatives from NHS Trusts (patient safety, procurement, and clinical engineering teams), MHRA, NHS Scan4Safety, NHS Supply Chain, NHS England Medical Device Outcome Registry, NHS Digital, devolved governments and health bodies, manufacturers, and medical device data bodies. The pain points investigated in the PIM discovery were about medical device data being hard to find, of poor quality or missing entirely and that accessing this data is slow and inefficient for both data consumers and data providers. The discovery confirmed that there is a viable service DHSC could build that would make it easier for users to do the thing they need to do and that it is cost effective to pursue the problem. Continued on the Context and Requirements Attachment due to word count limits Which phase the project is in Beta Existing team The existing DHSC team consists of an analyst, senior analyst, and head of analysis. The existing DHSC team can assist with knowledge transfer throughout the beta. In the alpha phase, the Senior Analyst took the position of the Service Owner (but the delivery team also provided a product owner) and the Head of Analysis acted as a Subject Matter Expert at times. The internal DHSC has resource to dedicate to helping the delivery team but this is likely to be between 30-50% capacity. The internal team can help with putting the delivery partner in contact with subject matter experts and key stakeholders from across health system, which includes colleagues from the MHRA who will be closely involved, particularly in areas including understanding data flows and providing architecture assurance. The beta phase does not involve working with another supplier but will involve using the learnings and recommendations from the alpha (delivered by the alpha supplier). It will also involve gathering the requirements for the long term delivery team which may involve engaging with external parties. We require the supplier to provide a temporary hosting arrangement for the duration of the beta phase. This cost is to be included in the price of the bid. The supplier will also be required to fulfil the roles of a MHRA team which should consist of subject matter experts from the business and from a technology perspective, an architect, software/data and DevOps engineers to develop the pipelines, a delivery manager to manage the relationship with the project and change management and service management to deploy the service Address where the work will be done Work can be undertaken remotely. The DHSC team have offices in London (39 Victoria Street, Westminster, London, SW1H 0EU) and Leeds (Quarry House, Quarry Hill, Leeds, LS2 7UE), should in person working arrangements take place. MHRA also have offices in London (10 S Colonnade, London E14 4PU). As we will use UK regulatory data, we require data to be kept within the UK. The solution provider will therefore be required to be UK based. Working arrangements The supplier's staff will be expected to be available during the typical working hours of Monday to Friday (9.00am to 5.00pm) to maximise collaboration and knowledge sharing. We require the supplier to conduct the usual agile ceremonies, weekly updates, 'show and tell' workshops, planning sessions, and any additional sessions as required. A supplier that can help develop the internal teams project delivery is also preferred. This will include producing resources and documentation of work undertaken to provide a clear record of what has been done and decisions made. We expect clear and continual communication between the supplier and the DHSC team to ensure a joined-up approach. Sessions will take place remotely unless otherwise agreed. Collaborative in person workshops may be arranged as necessary in an appropriate location. Supplier is required to cover travel at their own expense. The contract will be managed in line with DOS 6 call-off contract requirements and using DHSC’s contract management guidance. By integrating the Digital Outcomes and Specialists framework guidelines with DHSC's specific contract management guidance, the call-off contract can be tailored to meet the department’s unique needs while ensuring compliance with procurement regulations and best practice. The contract will include a break clause at least between private and public beta. Following agile principles, we will use sprint cycles to progress and agree each stage of the project. Throughout the contract period, we'll use established methodologies to monitor timelines, expenditures, and work outputs. Continued on the Context and Requirements Attachment due to word count limits Provide more information about your security requirements: Baseline Personnel Security Standard (BPSS) Latest start date 2025-03-30 Enter the expected contract length: 1 year Extension period: 6 months Special terms and conditions Full value of the contract will only be unlocked after a successful beta stage, including passing GDS service assessment Write the term or acronym: MedTech Write the term or acronym: MHRA Write the term or acronym: DHSC Write the term or acronym: NHSE Write the term or acronym: NHSSC Write the term or acronym: PIM Write the term or acronym: UDI (DI) Write the term or acronym: GMDN Write the term or acronym: NETIS Write the term or acronym: SCS Write the term or acronym: MDOR Write the term or acronym: MPC Write the term or acronym: NHS eClass Write the term or acronym: PQP Are you prepared to show your budget details?: Yes Indicative maximum: 1600000 Provide further information: This contract is for the private and public beta with a break clause to be included at the end of private beta. The success of the Public Beta will be dependant on a GDS / CDDO service centre assessment, which the provider will need to be involved in. Confirm if you require a contracted out service or supply of resource Contracted out service: the off-payroll rules do not apply Summary of work To use the learnings and recommendations from the alpha phase to develop a digital service for collecting and providing medical device data. This digital service aims to improve access to medical device product information for those in the health sector who need it. The service should collate medical devices data from multiple sources (a mix between free, publicly available data, subscription-based data and secure data) and collect data itself. It should enable data consumers to access data via a range of means, including a user interface, downloads of data and API access, enable data consumers to flag data errors and request missing data and enable data providers to proactively submit data directly to PIM, update regulatory data by guiding users to the MHRA Device Registration Service, respond to data consumers’ error flags, and respond to data consumers’ requests for data. Some of the activities required are detailed in the beta roadmap and the technical backlog (available upon request). Activities in the first instance will include engaging with key stakeholders (including MHRA, NHS SC, GMDN, NHS trusts and medical device manufacturers), further research to identify core standard data fields, design and build database and data pipelines, recruiting private beta cohort, designing, testing and building core functions (like search, flag errors, request missing data, add data), establishing data protection and governance principles and processes and building approach to protecting/mitigating against fraudulent activity. After building and trialling the service with the private beta cohort, activities will include refining all previous steps, ongoing usability testing, accessibility audits, defining and implementing analytics, designing and building APIs, conducting and passing the beta service assessment. Continued on the Context and Requirements Attachment due to word count limits Where the supplied staff will work No specific location (for example they can work remotely) Why the work is being done This work is being done to improve the accessibility and quality of medical product data that is currently dispersed throughout the healthcare system in the UK. This is one of the aims of the Department of Health and Social Care's Medical Technology Strategy (https://www.gov.uk/government/publications/medical-technology-strategy) which sets out how the department will ensure the health and social care system can reliably access safe, effective, and innovative Medtech. Priority 3 of the strategy, titled ‘Enabling Infrastructure’, emphasises the need for improving Medtech data standards and encouraging proactive data collection. It also highlights the need for a common product language, standardised product information, improvements to be made in data systems, and a collaborative role between DHSC and industry. This work is also listed as a key initiative of the strategic framework for NHS commercial (https://www.england.nhs.uk/long-read/strategic-framework-for-nhs-commercial/#digital-and-transparency) under the digital and transparency pillar. This work also supports the current government's health mission of shifting from analogue to digital to aid efficiency across the NHS. The need for this work has been emphasised repeatedly in our discussions with stakeholders including NHS Trusts, the MHRA, NHS England, and the wider MedTech industry and has existed as early as 2014 when it was referenced in the NHS eProcurement strategy (https://assets.publishing.service.gov.uk/media/5a7ebfa3e5274a2e8ab47f34/NHS_eProcurement_Strategy.pdf). Continued on the Context and Requirements Attachment due to word count limits The business problem you need to solve Medical technology (Medtech) is a broad field, encompassing all the equipment and consumable products used in healthcare. There is significant complexity and scale in the market, with over three million Medtech products registered for use in the UK and the NHS spending an estimated £10bn a year on purchasing devices. Data on Medtech products is of poor quality and is dispersed throughout the healthcare system. This fragmentation leads to significant inefficiencies as NHS trusts make multiple and repeated information requests to suppliers. Trusts often receive only partially completed information which can have severe patient safety implications and lead to wasted/inappropriately used devices. At the same time, Medtech suppliers have to respond to multiple and overlapping requests, often coming in different templates that may not align with their internal business structure. Overall, this is a resource-intensive and burdensome process. This lack of data is a barrier to making effective decisions as there is no common understanding of the Medtech products currently available and being used. This can also lead to patient safety risks, as standard product characteristics, such as whether an implanted device is MRI safe or whether a consumable item contains latex is not readily available. Continued on the Context and Requirements Attachment due to word count limits First user type: Head of engineering at a large NHS Trust First user type: Analyst in a government organisation First user type: Systems manager in a procurement partnership First user type: Commercial representative in a medical device manufacturer First user type: Customer service support in a large manufacturer