Consultation outcome

Chapter 10 - Software as a Medical Device

Updated 26 June 2022

Software as a medical device (SaMD) - being standalone software and software included in wider hardware and including artificial intelligence (AI) as a medical device (AIaMD) - has grown in market share, public health significance and complexity in recent years. It has applications in health and social care that could not have been envisioned when existing regulations around medical devices were developed, and it is anticipated that these applications will continue to increase in coming years.

The current medical device regulations contain few provisions specifically aimed at regulating SaMD or AIaMD. The proposals outlined in the consultation would amend the UK medical devices regulations to both better protect patients and support responsible innovation in digital health. The proposals aim to ensure that the regulation of SaMD is clear, effective, and proportionate to the risks these medical devices present. The majority of change required in this area is likely to be in the form of guidance rather than legislation and the questions asked in the consultation helped to draw out the distinctions between the two approaches.

Section 57

Section 57 of the consultation set out some background information regarding the current regulatory approach to SaMD and AIaMD. This section did not contain any proposals or questions.

Section 58 - Scope and definitions

58.1 Proposals and feedback

The consultation asked whether the UK medical devices regulations should introduce the following definition of the term ‘software’ to the UK medical devices regulations: “a set of instructions that processes input data and creates output data”. This definition is consistent with the definition in the EU’s MEDDEV 2.1/6. Out of 208 responses:

• 83% supported the introduction of this definition
• 10% did not support the introduction of this definition
• 7% did not know or had no opinion

In regard to whether there are other definitions that need to be added to, or changed in, the UK medical devices regulations to further clarify what requirements apply to placing SaMD on the UK market, 198 responses were received, of which:

• 51% felt that further definitions were needed
• 19% did not feel that any further definitions were needed
• 30% did not know or had no opinion

Within this, a larger proportion of those who responded as part of an organisation supported the use of further definitions (55%), compared to 37% of individual respondents who in contrast responded don’t know or had no opinion.

Other information provided in comments from respondents relating to defining the term ‘software’ revealed no reasons to change the proposed policy position as set out in the consultation document. There was a consistent set of additional terms which should be defined, although not necessarily in the regulations.

The majority of the comments covered the need to:

• align definitions with EU, International Medical Device Regulators Forum (IMDRF), Medical Device Co-ordination Group (MDCG) or international standards
• provide additional clarity around the definition of ‘software’
• provide additional clarity in guidance rather than in the regulations
• extend the definition of ‘software’
• include other definitions

Some respondents commented that the proposed definition of software was too vague and did not address the distinction between software as a medical device and software in a medical device.

Those who were not supportive of the introduction of the definition of ‘software’ into the regulations cited these comments:

• there is a need for clearer explanations
• use IMDRF definitions
• specifically consider in vitro diagnostic medical device (IVD) software
• use only International Organization for Standardization (ISO) and/or International Electrotechnical Commission (IEC) definitions
• suggested definition is too vague
• define AI separately
• list specific exclusions

Other definitions that respondents suggested for inclusion in regulations included, but were not limited to:

• software as a medical device
• software in a medical device
• cyber security
• predetermined change control
• software accessory
• IVD software
• AI
• software driver
• input data
• output data

58.2 The government response

After careful consideration of the responses, it remains the government’s intention to proceed with the proposal to clarify the meaning and scope of the term ‘Software’, by adding a new definition of Software to the UK medical device regulations.

As proposed, we plan to add the following definition of ‘Software’ to the UK medical devices regulations: “A set of instructions that processes input data and creates output data”.

The MHRA recognises that there is interest in defining other terms related to software and will ensure there is sufficient clarity of these as we produce supporting guidance in this area.

Section 59 - Distance sales

59.1 Proposals and feedback

The consultation outlined that SaMD can be deployed in the UK by websites hosted in other jurisdictions. The consultation sought views on whether there is a need for greater/clearer requirements with regards to such deployment. Of the 161 responses:

• 78% were in favour
• 11% were not in favour
• 11% did not know or had no opinion

The consultation invited views on whether the definition of ‘placing on the market’ could be modified to clarify when SaMD deployed on websites, app stores (for example Google Play and Apple stores) and via other electronic means accessible in the UK, amounts to ‘placing on the market’. Of the 158 responses received:

• 74% supported the proposal
• 16% did not support the proposal
• 10% did not know or had no opinion

There was an overall positive response to the accompanying free-text questions in this section, reflecting significant interest in having greater clarity around the requirements for deploying software as a medical device to the UK market through websites hosted in other jurisdictions, with considerable support for further clarifying the term ‘placing on the market’. There was a call for a ‘level playing field’, which would see manufacturers who place software products on the UK market needing to meet the same requirements as manufacturers of physical devices.

Several respondents suggested there is a need for greater clarity on the use of the terms:

• ‘placing on the market’
• ‘operational use’
• ‘deployment’
• ‘putting into service’
• ‘software as a service’
• ‘making available’
• ‘being available’

Several references were also made to the need for additional guidance to further clarify the role of app stores. Reference was also made to the need for alignment with existing definitions set out in the EU Blue Guide or by the Medical Device Coordination Group. Other points referred to the management of open source coding, cloud-based services and to managing app stores and vendors.

59.2 The government response

Having considered the views of respondents the government is minded to explore further, the scope to proceed with the above possible changes and will have further cross-government discussions to ensure our approach aligns, where appropriate, with similar measures in place for other products placed on the UK market. See Section 9 in the Economic Operators Chapter (Chapter 4) and section 56 of the IVD Chapter (Chapter 9) for further details on Distance Sales.

As set out above in the Economic Operators chapter (Chapter 3), the MHRA will further consider the scope to clarify and strengthen regulatory requirements and guidance applicable to medical devices sold via distance sales. While the MHRA do not currently see the need for SaMD-specific regulation change in relation to distance sales, the MHRA recognises there may be a need for suitable guidance that makes clear to what extent SaMD provided to the UK market via distance sales is subject to requirements under the UK medical devices regulations.

The MHRA also acknowledges that there is interest in defining a range of terms related to placing software as a medical device on the market and will consider providing greater guidance on such terms.

Section 60 - Classification: risk categorisation

60.1 Proposals and feedback

We asked whether the classification rules in UK medical devices regulations should be amended to include the IMDRF SaMD classification rule (with supporting definitions and implementing rules), and to set out their rationale and any impacts they expected this change would have. Of the 189 responses:

• 82% were in favour of the proposal
• 10% did not support the proposal
• 8% did not know or had no opinion

Many respondents provided further detail of their opinion of this framework, including their rationale for their answer and any impacts expected from the possible change. The main reason for following the IMDRF framework is to further for international alignment and that it was seen as a logical, clear, proportionate method for SaMD risk classification. The main impact that was mentioned by respondents was re-classification. Further comments included that the IMDRF framework does not include any information for SaMD that drives or influences the use of a device in the same way as implementing rule 3.3 in the EU MDR and stated that clarity would be needed for this.

Respondents also noted how the wording for implementing rule 3.3 could be edited to make it compatible with the SaMD definition. In addition, it was noted that the IMDRF framework does not distinguish between SaMD regulated as a medical device and an in vitro diagnostic medical device (IVD) and further clarity is needed to understand how this would work in the UK medical device regulations.

There was a theme of responses stating the need for clearer definitions, including of:

• ‘diagnose / treat’
• ‘driving patient management’
• ‘informing clinical management’
• ‘prediction’ / ‘prognosis’

It was also emphasised that definitions need to allow for future technological advancements.

60.2 The government response

After careful consideration of responses, it remains the government’s intention to proceed with the proposal to amend the classification rules in UK medical devices regulations to include the IMDRF SaMD classification rule for general medical devices, not IVDs (with supporting definitions and implementing rules).

The MHRA wants to ensure the scrutiny applied to SaMD is more commensurate with their level of risk and therefore better protect public health.

In addition, GB is currently out of alignment with other major regulators in relation to software as a medical device classification. The MHRA wants the UK to be in international alignment. This will likely have a positive affect with respect to the availability of these devices and the UK being regarded as a favourable place in which to research, develop, and manufacture these devices.

A move to follow this IMDRF categorisation framework we consider a logical, clear, proportionate method for SaMD classification (excluding for IVDs) which allows for international alignment. This classification was supported by a clear majority of respondents to the public consultation. We have chosen not to include IVDs at this stage because this significantly diverges from the EU IVDR classification system.

Taking into account the responses from the public consultation, we propose to adopt the risk categorisation in the IMDRF Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations for classifying SaMD that are general medical devices (not IVDs) with consequential implementing rules and definitions and clear guidance.

Section 61 - Classification: airlock classification rule

61.1 Proposals and feedback

Introducing an ‘airlock classification rule’ is a provision that would allow for a temporary classification to be applied to some SaMD (which is likely to involve monitoring and restricting the SaMD as if it were a high-risk device) where the risk profile is unclear. This could allow early access to market for novel and innovative SaMD whilst ensuring the safety of users and patients until the risks of the device are properly understood.

We invited views on whether the UK medical devices regulations should introduce an airlock classification rule for SaMD with a risk profile that is not well understood. 163 responses were received, of which:

• 60% were in support of the proposal
• 14% did not support the proposal
• 26% did not know or had no opinion

Of those who were in favour of introducing an ‘airlock classification rule’, the most common rationale for this was to support innovation and access. In addition, respondents also noted that a system was required and that this approach seemed logical.

However, other responses mentioned that there could be alternatives to the airlock rule, for example conditional approvals, and that this type of pathway could also be used for IVDs and other medical devices.

Many responses also mentioned that, for this to work, there would need to be clear guidelines for manufacturers and for patient safety. Comments included recommending stakeholder feedback to refine the proposed change in detail and recommending a similar process to the U.S. Food and Drug Administration (FDA) De Novo pathway. Further responses cautioned that if additional requirements are too burdensome, this rule could actually increase cost and slow down innovation.

Those against the introduction of an airlock classification, emphasised that risk should be understood, and risk controls established before being placed on the market, and that if IMDRF classification rules are clear enough this rule may not be needed. In addition, it was noted that medical device regulation already allows for quicker access to market than for medicines and therefore this rule is not warranted.

61.2 The government response

Having considered the responses provided in relation to introducing an airlock classification rule for SaMD with a risk profile that is not well understood, the government remains interested in the potential to introduce an airlock conditional authorisation and intends to consider this further, taking into account the feedback raised by consultation respondents.

The MHRA plans to scope further detail about this possible change and include it in a future possible public consultation in order to obtain further feedback from stakeholders before potentially adding it to the UK regulations. This is necessary because many respondents commenting on it, whilst supportive, felt that further details would be required to come to a decision on whether to take an airlock classification rule for SaMD forward.

Section 62 - Pre-market requirements

62.1 Proposals and feedback

Participants were asked whether additional essential requirements should be in place (beyond those that apply to medical devices more broadly) to assure the safety and performance of SaMD specifically. Of the 172 responses received:

• 61% supported the proposal
• 26% were not in support of the proposal
• 13% did not know or had no opinion

A higher proportion (83%) of respondents who classed themselves as ‘individuals’ considered that additional essential requirements should be in place compared with 55% of those who responded as part of an organisation. Conversely, 30% of organisations responded ‘no’ compared with only 10% of individuals.

We invited consultees to set out reasoning for their response to the above question and any expected impacts, with 121 responses provided. Those who supported the introduction of additional essential requirements to assure the safety of SaMD specifically, the most common was rationale given was that many want the UK to align with EU MDR/IVDR, specifically General Safety and Performance Requirement (GSPR) 17 in the EU MDR. Some respondents gave non-specific recommendations, noting that extra essential requirements are needed for SaMD, but did not elaborate further.

Respondents suggested possible additions/alterations, including:

• cyber security
• data protection, privacy, or confidentiality
• better alignment to core Data Coordination Board (DCB) standards
• GSPRs specific to AI

A minority of respondents commented that the current essential requirements were sufficient to cover SaMD. Whilst the government broadly agrees with this point, it is felt there are necessary additions to be made.

Multiple respondents commented that they thought guidance was better placed to cover requirements for SaMD. The government will ensure that any additional and current essential requirements specific to SaMD are supported by guidance but disagrees that we can adequately protect patients and public merely through guidance alone; additional essential requirements are necessary.

The consultation invited views on whether the regulations should set out SaMD essential requirements separate from those for other general medical devices. Out of 168 responses:

• 49% were in favour of the proposal
• 37% were not in favour
• 14% did not know or had no opinion

We also asked whether regulations should set out SaMD essential requirements separate from those for other general medical device types. Many responses requested the essential requirements to be subdivided for SaMD rather than separate to general medical devices. Of the respondents that identified as being part of an organisation, 42% thought that SaMD essential requirements should not be separate from those applicable to other general medical devices, versus 18% of those who responded as an individual.

The majority of respondents in favour of the regulations setting out SaMD essential requirements separate from those for other general medical devices gave justification relating to the clarity and ability to clear define which essential requirements apply to SaMD in particular.

Conversely, most respondents not in favour of the regulations setting out SaMD essential requirements separate from those applicable to other general medical devices, cited the need to harmonise with the EU MDR. Many commented that such separation would be confusing, arguing for sub-division not separation, or that there was no need for essential requirements for SaMD in particular.

A clear majority of respondents were in favour of sub-division rather than having separate essential requirements for SaMD. They typically were in favour of:

• harmonisation with EU MDR/IVDR, with the SaMD GSPRs being a sub-division of the general GSPRs
• a desire to avoid having separate essential requirements for SaMD, noting a preference for wanting sub-division

62.2 The government response

Having considered the views of respondents, the government wants to ensure that a SaMD receives adequate pre-market scrutiny to assure its safety, quality and performance and to ensure that appropriate essential requirements are in place meet this need. In light of this, the government intends to proceed with the proposal to introduce further essential requirements to assure the safety and performance of SaMD specifically.

The government has considered key themes raised, as follows:

• Cyber security - our policy position is to include cyber security as an essential requirement.
• Data protection, privacy, or confidentiality - we will work closely with the Department for Digital, Culture, Media & Sport (DCMS), Information Commissioner’s Office, the National Data Guardian, and the Health Research Authority to ensure that patient data is protected.
• Better alignment to Data Coordination Board (DCB) standards - shifting essential requirements to match DCB standards would risk international divergence for the benefit of national convergence. We shall instead work with NHS Digital and NHSX to map and align where possible, also using guidance to better harmonise with these standards.
• We consider requirements specific to AI as a medical device are best clarified via guidance on how to meet a GSPR akin to EU MDR’s GSPR 17.2 (which includes verification and validation) rather than setting up a separate essential requirement/GSPR specific to AI as a medical device.

As highlighted in responses, a key feature of this approach will be the introduction essential requirements/GSPRs that closely mirror EU MDR, Annex I, GSPR 17 (and its EU IVDR equivalent in relation to IVDs).

The MHRA considers that other suggested essential requirements for AIaMD specifically, as expanded on above, are generally better captured by GSPR 17 and guidance clarifying how it applies to AI in particular.

Further to this and after careful consideration of responses, it is the government’s intention not to separate out essential requirements/GSPRs for software but to subdivide the essential requirements/GSPRs for software largely mirroring the EU MDR/IVDR. It is the government’s view that this is the preferred position, as it:

• protect patients and the public through updating the essential requirements/GSPRs to better capture safety requirements for SaMD; and
• minimise burdens to industry through close alignment with the EU MDR/IVDR, which could help ensure that the UK market remains an attractive place for medical devices

Section 63 - Post-market requirements

63.1 Proposals and feedback

The consultation set out proposals for the MHRA to:

1. allow accurate and swift reporting via the digital Yellow Card Scheme – noting that SaMD should have a hyperlink to MHRA endorsed websites where a person can ‘report an adverse incident with a medical device’ where appropriate, and
2. provide for certain SaMD change management processes such as ‘predetermined change control plans’ (PCCPs).

We invited views on whether the UK medical devices regulations should mandate a ‘report adverse incident’ link. 178 responses were received, of which:

• 51% were in support of the proposal
• 31% were against this proposal
• 18% were not sure or had no opinion

Consultees were asked to provide reasoning for their responses to the above question. Of those who supported the mandating of a ‘report adverse incident’ link, the majority commented that it would make it easier to report incidents due to accessibility, it would encourage more people to report incidents, it will allow analysis of large volumes of information, and it will allow for easier investigations of potential faults.

Respondents also highlighted that this approach may give valuable insight into areas where reporting is higher, which could highlight areas where additional regulatory changes may be needed, and that a similar link is used by other worldwide health agencies including FDA.

Other respondents commented that the current system for Yellow Card has certain challenges and may not be understood by some patients. Therefore, requiring manufacturers to provide a link could raise awareness of the scheme and make it clear that the MHRA expects adverse events to be reported through this route.

Respondents who were unsupportive of mandating the link commonly reasoned that not all SaMD will have the user interface necessary to support the link. It was suggested that the link could be included in the user manual. However, some respondents indicated that this would not be applicable for software that do not have access to internet.

Other respondents indicated that a ‘report adverse incident’ link would be a country specific software feature, which could cause complexity in the development of SaMD and may be overly burdensome. They noted that a requirement here could impact the software build, verification and validation process, which could prove difficult for manufacturers. Some responders were concerned that issues could arise from the link - for example, if the destination address were to be changed by the MHRA or the link were to break, the manufacturer would have no knowledge. It was also noted that the proposal is not in alignment with other international jurisdictions.

Multiple respondents commented that issues should be raised with the manufacturer directly instead of being reported to the MHRA. Here, respondents reasoned that the manufacturer should first have an opportunity to triage and determine which events are in fact reportable. A number of responses also raised concerns that users may send false complaints or may abuse the link and encourage false reporting, which could create excessive amount of work for both manufacturers and the MHRA.

Many of those who were unsure about whether a ‘report adverse incident’ link should be required stated that the MHRA would need to clarify how such a requirement would be implemented in order for them to provide an informed view as to whether or not they supported such a policy.

The consultation invited views on whether the regulations should enable predetermined change control plans (PCCPs). Of the 168 responses:

• 50% were in favour of the proposal
• 14% were not in favour
• 36% did not know or had no opinion

Of those who supported the introduction of PCCPs, many noted that they would improve performance and safety, and promote innovation. Others reasoned that PCCPs could simplify regulations for expected changes that do not impact intended use - such as software updates, bug fixes, user interface/user experience (UI/UX) changes and routine updates for security. Others commented that there should be a structured change control plan that is well documented, which should be dependent on the manufacturer’s Quality Management System (QMS) which is routinely evaluated and certified by an Approved Body.

Further responses indicated that we should align with the FDA and PCCP frameworks within other countries. Respondents suggested that the PCCP should be:

• based on FDA’s framework by including the SaMD Pre-Specifications and the Algorithm Change Protocol
• utilised across all SaMD, in contrast with the FDA which only focuses on modification for Artificial Intelligence / Machine Learning
• aligned with the FDA and limited to AI / Machine Learning model only

Respondents who were not in favour of proposals to introduce the introduction PCCPs highlighted that once software has been tested and approved, it should not be changed. Here, respondents noted that:

• minor code change could have unpredictable effects
• it may slow clinical risk response
• PCCPs will limit the creativity and innovation of companies
• it would be harder for regulators to observe issues

One respondent indicated that the FDA is still exploring this method and it may take time to fully develop, suggesting postponement on this basis.

Over a third of respondents answered ‘don’t know or no opinion’ to this question - and the majority of these responses indicated that they were unsure what PCCP would entail or what types of change would be required as this was not defined in the consultation.

Those who were supportive of PCCP also suggested certain topics that they considered should be covered in guidance:

• define PCCP and include representation examples
• clarity is needed regarding regulatory expectations and what change management documents need to be provided
• types of change that would not require pre-market approval
• types of changes that would require pre-market approval
• specify how and how often software would be updated
• how and when significant changes are reported and recorded

63.2 The government response

Having considered the responses provided in relation to the UK medical devices regulations mandating a ‘report adverse incident’ link, the government does not intend to adopt this possible change at this time.

Although there was support for mandating a ‘report adverse incident’ link, with many respondents noting that this would ease reporting of incidents, would encourage more people to report incidents and that it may give valuable insights into areas where reporting is higher; there was no clear consensus view on this possible change.

In light of this, we plan to further explore this possible change further, which will include further consultation to explore, in particular, what devices would be best suited to mandatory reporting link requirements and implementation considerations.

Currently, data suggests that the MHRA receives only a weak safety signal with respect to SaMD. It is clear that this safety signal does not represent a lack of SaMD incidents - rather a lack of reporting. The MHRA has observed that, where a ‘report an adverse incident’ has been mandated via the exceptional use authorisation process, this had led to an appreciable increase in reports. Therefore, requiring the manufacturer to provide a link in future would raise awareness of the scheme and make it clear that the MHRA expects adverse events to be reported through this route.

After careful consideration of responses, it remains the government’s intention to proceed with the proposal to enable predetermined change control plans (PCCPs). In implementing this approach, we intend to work with international partners wherever possible.

Currently, change management processes require all ‘significant’ or ‘substantial’ changes to be reported, either to the MHRA or to the relevant Approved Body. However, the proper interpretation of these requirements is difficult to find in guidance (for instance, in Notified Body Operations Group Best Practice Guidance), which can be cumbersome for manufacturers of software and AI. In light of this, a clear legislative foothold to manage change for software is required. Predetermined change control plans are one method to streamline these processes.

PCCPs will be enabled but on a voluntary basis, the MHRA recognises that there is a need to encourage the use of PCCPs in guidance and may consider the potential to mandate PCCPs in the future.

The government considers that proceeding with the consultation proposals on PCCPs will

• implement a robust post market surveillance and MHRA market surveillance system that produces a strong and clear safety signal, allowing for quicker and thorough capture of adverse incidents for SaMD
• utilise real world evidence to provide further assurance that SaMD functions as intended, maintains performance, and continues to provide assurance with respect to safety
• articulate clear change management requirements for SaMD
• encourage assured changes to SaMD and AIaMD that improve the performance of the devices

Section 64 – SaMD cyber security

64.1 Proposals and feedback

The consultation invited views on whether the UK medical devices regulations should include cyber security and/or information security requirements. Of the 170 responses received:

• 88% were in favour of this approach
• 5% were not in favour
• 7% did not know or had no opinion

The consultation asked those in favour of introducing cyber security/information security requirements to outline what this should entail and why, as well as the expected impacts. 132 respondents provided feedback. Many respondents recommended alignment with other international regulators, existing frameworks and existing standards.

Many respondents noted that the EU MDR Annex I 17.4 comprises the ideal set of requirements and commented that, ideally, the UK follow would these. Respondents reasoned that this would avoid an unnecessary increase in the regulatory burden placed on UK manufacturers. Respondents suggested that liaison with other national regulators in this space, such as NHS Digital, NHS Transformation Directorate and Information Commissioner’s Office (ICO) would be beneficial.

Several respondents advocated the need for specific essential requirements/templates to be established (minimum requirements to be set out, such as minimum safety standard and encryption), and to comprise part of the risk management process for manufacturers.

Other key comments included:

• There is a need for guidance. Including examples, to help navigate the requirements
• Requests to implement cyber security requirements on a risk-based approach, in order to avoid excessive regulatory burden for lower risk class products
• Acknowledgment that cyber security should be an ongoing process for the lifetime of the device. Suggestions were made for this process to be revisited in appropriate time intervals to ensure its effectiveness. Cyber security assessment/evaluation should also take into account the use of the device in specific environments and in relation to other systems
• General acknowledgment that cyber security is a collective and shared responsibility between manufacturers, healthcare establishments and users. Respondents highlighted the need to identify specific roles/responsibilities in this ongoing process (identification of liability was also identified as a concern, as this is often difficult to establish). In particular, importance must be given in considering interaction/risks with other systems connected with the medical device (for example, when these are deployed in hospitals or in other specific operating environments)
• The need for cyber security to be a central part of post market surveillance activities. This aspect was highlighted in several comments, with the aim of allowing post market surveillance to play a key part in ensuring the cyber security of medical devices is maintained throughout their lifecycle

Of those not in favour of introducing cyber security/information security requirements or those who did not know or had no opinion, the main themes raised were:

• cyber security should not be part of medical device regulations, but guidance would be helpful
• cyber security is already addressed by the essential requirements
• cyber security should be part of the QMS/Risk Analysis process

64.2 The government response

The government wants to ensure that sufficient cyber security and information security measures are in place for SaMD - both for the purposes of the direct safety of the device (e.g., whether its functioning could be tampered with) and consequent impacts on patients and the public, and also the security of personal data held on or in relation to the device.

After careful consideration of responses, it remains the government’s intention that manufacturers of SaMD will be required to meet certain minimum requirements relating to security measures and protection against unauthorised access.

The position on cyber security is linked to that set out the Pre-market Requirements section of this Chapter. The government intends to introduce a requirement akin to EU MDR General Safety and Performance Requirement (GSPR) 17.4 (for medical devices) and EU IVDR GSPR 16.4 (for IVDs) covering cyber security and associated requirements. Having considered the views of respondents, the government notes that its introduction would form a sound basis to bring forward guidance. There is a strong argument, as set out by consultees, to retain alignment with the EU in this area, unless divergence is necessary for the protection of UK patients.

Compared to other device categories, SaMD often exhibits a novel risk profile in a number of respects, this includes the premise that connected medical devices facilitate continuity of service but are also vulnerable to cyber-attack, thereby also presenting a novel risk profile. The objectives of applying relevant GSPR requirements are to further safeguard peoples’ health, including by:

• ensuring that cyber security is adequately reflected in SaMD requirements and in post market surveillance requirements
• clarifying, bolstering, and making consistent, reporting requirements for cyber security incidents and vulnerability that might translate to adverse events from manufacturers

We anticipate that the addition of provisions akin to the EU MDR’s GSPR 17.4 and IVDR GSPR 16.4 will also help ensure that the UK is harmonised with other jurisdictions that require similar evidence, thereby protecting patients and the public. In addition, we consider that the approach will have a neutral or positive impact on the UK’s ability to access these devices and upon the UK as an attractive destination to innovate and supply devices.

Section 65 – AI as a Medical Device

65.1 Proposals and feedback

Artificial Intelligence as a medical device (AIaMD) is a subset of software as a medical device (SaMD). With this in mind, the MHRA considers that the changes outlined in the SaMD chapter above would also be beneficial for the regulation of AIaMD.

Consultees were asked whether there are additional statutory changes required to effectively regulate AIaMD over and above the changes detailed for SaMD in the sections above. Of the 169 responses received:

• 38% supported additional statutory changes
• 24% did not support statutory changes
• 38% did not know or had no opinion

The consultation invited those who considered that additional changes are required to effectively regulate AIaMD to outline the changes that should be introduced. Of the 122 responses, the majority did not support legislative changes in particular, but instead wanted to highlight areas of concern relating to AIaMD. There were several recurrent themes, for example: adaptivity, bias, interpretability, autonomy, all of which have been picked up in the wider SaMD scope and we intend to address through guidance.

Beyond these comments, other respondents provided specific areas where legislation should be utilised, including:

• to define AIaMD
• to mandate explainable AI
• on separate design requirements/essential requirements for AIaMD

Further analysis of both the supportive comments and comments from those who were unsure about whether additional requirements should be introduced, revealed that only a very small number of respondents actually supported additional statutory changes. Instead, respondents commented that they supported the use of guidance and flexibility over statutory changes.

The consultation outlined that the MHRA is considering making additional changes to the regulations specific to AIaMD. This included a proposal to require performance evaluation methods for diagnostic AI which would take a comparable approach to performance evaluation methods used for IVDs in terms of requiring demonstration similar to that of scientific validity along with analytical and clinical performance. This approach would build upon IMDRF’s Software as a Medical Device (SaMD): Clinical Evaluation.

Participants were asked whether they considered the use of IVDR-type performance evaluation methods (akin to scientific validity, analytical performance, and clinical performance) for diagnostic software but especially AI (even where no IVD data is used) to be appropriate. Of the 165 responses received:

• 56% supported this approach
• 11% did not support this approach
• 33% did not know or had no opinion

The follow-up question asked whether the UK medical devices regulations should be amended to require this, with a similar spread of responses. Of the 160 responses received:

• 51% were in favour
• 13% were not in favour
• 36% did not know or had no opinion

A review of the free-text comments provided in relation to questions in this section suggests that almost the responses (both positive and negative) were in fact supportive of the proposal - with only a couple suggesting that mandating AI requirements would be heavy handed. This discrepancy seems to have arisen from respondents combining their free text responses to these questions with the following question (regarding logging) in the consultation.

Therefore, there is support for requiring the use of IVD performance evaluations methods and we wish to proceed with the proposed policy position.

Participants were asked whether the UK medical devices regulations should mandate logging of outputs of further auditability requirements for all SaMD or just AIaMD for traceability purposes. Out of 161 responses:

• 37% were supportive of this proposal
• 21% were not supportive
• 42% did not know or had no opinion

We invited consultees to set out their reasoning for responses in this section. Of those who were supportive of the proposals, a few caveated their response with the need for further clarity and proportionality to avoid overburdening the market.

Feedback from respondents who indicated a lack of support for these proposals is summarised below:

• agreement with mandating for AIaMD but not SaMD
• concerns about cost and complexities of storage of “outputs”
• need more detail on what is meant by “outputs”
• concerns over data protection/privacy of stored data
• supportive of the intent but details are needed in guidance
• impact of this on legacy software

This leads to quite a mixed response to summarise, however there appears to be general support for empowering traceability, auditability and PMS, especially in AIaMD products for safety reasons. However, there are also many questions relating to the practicality and implementation of such a process should it be mandated, highlighting the need for highly detailed guidance.

65.2 The government response

Having considered the responses provided in relation to whether other statutory changes are required to effectively regulate AIaMD over and above the changes detailed for SaMD in the sections above, the government does not intend to introduce any AIaMD-specific requirements in legislation.

The government does not propose to define AIaMD or set specific legal requirements beyond those being considered for SaMD, as this would risk being overly prescriptive.

Some respondents indicated that further guidance may be necessary to effectively regulate AIaMD, and the MHRA is aligned with market concerns on the themes identified and will address these through robust guidance.

The government has carefully reviewed the consultation responses and we do not consider that there is a need for further AIaMD-specific legislative change. Instead, the MHRA will achieve the objective of encouraging clinical performance evaluation methods (akin to that outlined by IMDRF’s Software as a Medical Device (SaMD): Clinical Evaluation document) for SaMD by producing guidance that makes plain that this is expected as part of meeting a combination of GSPRs or essential requirements or state of the art.

Having considered the responses provided in relation to mandating logging of outputs to enable auditability for SaMD and AIaMD, the government does not intend to introduce this requirement at this time.

Broadly, the consultation responses were supportive of the above proposal on grounds of traceability and auditability for safety purposes, but many highlighted that an informed response would require specific details of what such a provision would encompass.

Accordingly, the government is of the view that this requirement should be considered further as part of a future possible targeted public consultation.