Story Highlight
– MHRA introduced UK regulatory framework for software as medical devices.
– Clear intended use statements are critical for compliance.
– Clinical investigations required if evidence isn’t sufficient.
– New post-market surveillance rules effective from June 2025.
– NHS must conduct local safety assessments despite MHRA registration.
Full Story
In a recent webinar organized by techUK, significant insights into the UK’s regulatory landscape surrounding software as a medical device (SaMD) were shared by specialists from the Medicines and Healthcare products Regulatory Agency (MHRA). The objective of the session was to provide clarity for developers, manufacturers, and NHS personnel, particularly as innovations in software and artificial intelligence (AI) pose new challenges with regard to compliance, the gathering of clinical evidence, and ongoing market obligations.
Experts from the MHRA offered a detailed exploration of the regulatory process involved in bringing medical software products to market. This journey encompasses several critical phases: from the initial assessment of whether the software qualifies as a medical device, through the necessary clinical investigations, to the enhanced post-market surveillance measures that will come into effect in 2025. Throughout the presentation, there was a strong emphasis on the MHRA’s dedication to assisting innovators in navigating a regulatory framework that is becoming increasingly intricate and rapidly evolving.
The session began with an overview of the legislative context for medical devices operating in the UK. The MHRA explained the difference in regulations between Great Britain and Northern Ireland, noting that while UKCA or CE marking is accepted in Great Britain, Northern Ireland adheres to EU Medical Device Regulations. Developers were encouraged to clearly delineate their target markets, especially in light of ongoing discussions regarding the future of CE recognition within Great Britain.
A focal point of the discussion was the concept of intended purpose, defined as the key determinant that establishes whether a piece of software is classified as a medical device. The specific statement of intended use is crucial as it informs a range of regulatory procedures, covering elements such as software design, risk management strategies, and the evidence necessary for clinical evaluations as well as post-market responsibilities. MHRA representatives stressed the necessity of precise, targeted intended use statements, as they are foundational to all regulatory decisions.
To aid the industry, the MHRA has released extensive guidelines and a software flowchart. These tools are designed to assist manufacturers in determining if their products fall under the definition of medical devices and how various applications—such as clinical calculators, decision-support tools, and AI systems—should be viewed within the regulatory framework.
The session also addressed the expectations surrounding the generation of clinical evidence. It is mandated that all medical devices demonstrate safety and effectiveness. If adequate evidence is not available through existing scholarly research or equivalence claims related to similar devices, manufacturers must undertake regulated clinical investigations to establish the necessary safety and performance standards.
Several key points regarding clinical investigations were highlighted:
1. Any clinical investigation must obtain approval from the MHRA within a 60-day statutory timeline before it can commence.
2. Submission of applications must occur through the Integrated Research Application System (IRAS), accompanied by essential documentation, aligning with ISO/IEC 62304, which offers best practice guidance for software development in medical contexts.
3. Research sites must secure a Letter of No Objection before beginning any study.
4. Investigations require additional ethical approval from a Research Ethics Committee.
The MHRA team highlighted the distinction between pre-market clinical investigations, which are regulated, and post-market studies, which, while unregulated by the MHRA, still necessitate ethical oversight. Participants particularly sought clarity on grey areas involving digitised clinical calculators, next-generation AI technologies, and how equivalence claims could potentially lessen regulatory burdens.
Looking ahead, significant modifications to post-market surveillance will be implemented by June 2025, affecting both CE-marked and UKCA-marked devices introduced to the market after this date. The goal of these reforms is to enhance traceability, ensure consistency in reporting, and facilitate swifter regulatory reactions to emerging safety issues.
The changes will feature:
– Compressed reporting timeframes, requiring that serious incidents be reported within a maximum of 15 working days, with reduced windows for fatalities and public health risks.
– Mandated disclosure of a broader category of incidents, including specific adverse effects.
– Increased oversight of field safety corrective actions, which must be submitted within three working days upon request.
– A requirement for pre-publication reviews of Field Safety Notices by the MHRA.
– An obligation to gather real-world data, which is especially pertinent to software and AI tools that may evolve post-deployment.
All reporting concerning incidents must be submitted via the newly established MORE online portal that allows for systematic tracking and risk analysis.
For both developers and NHS organizations, the key takeaways from the session were significant. Manufacturers were advised to:
– Define a clear intended purpose from the outset, backed by guidance from the MHRA.
– Determine when clinical investigations are necessary and orchestrate evidence gathering accordingly.
– Comply with the forthcoming requirements for enhanced post-market surveillance.
– Utilize the flowcharts and guidance published by the MHRA to alleviate uncertainty in the process.
For NHS bodies involved in the procurement or deployment of SaMD, the MHRA reiterated that the designation of a product as a medical device does not negate the necessity for thorough local clinical safety evaluations, including DCB 0129/0160 assessments. While products listed on the MHRA register confirm adherence to regulatory standards, local assessments remain imperative to judge their compatibility with existing workflows, risk management protocols, and overall integration.
Looking to the future, the session underscored the MHRA’s ongoing commitment to fostering open communication with innovators and the health and care sector. As software and AI-integrated tools become increasingly central to clinical practices, the regulator is set to refine guidance, enhance transparency, and tackle emergent areas where industry participants require additional support.
In collaboration with MHRA, techUK aims to create practical resources that summarize essential guidance, address frequently asked questions, and illustrate examples that arise from member discussions, thereby equipping developers for the challenges ahead.
Our Thoughts
The article highlights a proactive approach by the MHRA in addressing regulatory frameworks for Software as a Medical Device (SaMD). To prevent potential non-compliance or safety incidents, several key measures could be emphasized:
1. **Enhanced Clarity on Intended Purpose**: Manufacturers must ensure their intended purpose statements are precise and comprehensive from the outset, as these determine compliance requirements under the UK Medical Devices Regulations.
2. **Rigorous Clinical Investigations**: It is critical for manufacturers to take the necessary steps to establish clinical evidence, particularly when existing literature is insufficient. This includes understanding when MHRA approval for clinical investigations is obligatory.
3. **Post-Market Surveillance Compliance**: Adhering to the new post-market surveillance requirements is vital. Manufacturers should be prepared for stricter reporting timelines and practices to ensure ongoing safety and performance monitoring.
4. **Local Clinical Safety Assessments**: NHS organizations must conduct thorough local assessments beyond regulatory compliance; this is essential for integrating SaMD into clinical workflows effectively.
5. **Training and Guidance Utilization**: Developers and NHS stakeholders should utilize MHRA’s resources and training materials to navigate regulations and enhance compliance, thus mitigating risks inherent in fast-evolving technologies.
Failure to adhere to these practices may breach the UK Health and Safety at Work Act and the Medical Devices Regulations 2002, placing patient safety at risk.
