Quality assurance & UK CA marking

exp date isn't null, but text field is

This section summarises requirements for:

  • Quality assurance of RDS tools which are not categorised as medical devices.
  • UK CA marking of RDS tools which are categorised as medical devices.

Quality assurance of RDS tools which are not medical devices

Before the RDS team will support publication of any  RDS tool, you will need to demonstrate that it meets the following quality criteria:

1. Following essential  steps in the development process  – including:

  • Stakeholder consultation and engagement
  • Requirements analysis
  • Testing and test reports including usability testing

2. Risk Management

An assessment should be conducted of any clinical risks associated with the software and risks mitigated as far as possible. A risk report should be available. 

3. Accessibility standards

The RDS software is designed to comply with W3C AA standards. You will be required to confirm that the content you have added also complies with these standards - for example, through use of ALT-Tags, avoiding use of PDFs wherever possible.  Any exceptions to compliance should be noted in the accessibility statement within the tool. 

4. Evidence base

You should provide details of how the evidence base underpinning the tool has been identified and critically appraised. You should also note how the tool will be updated to reflect changes in the evidence.

5. Maintaining and reviewing content 

You should provide details of plans for maintaining and updating content.

6.Plans for collating feedback and complaints, and dealing in a timely way with any issues that arise that could constitute a source of clinical risk - e.g. content inaccurate or not available.

7. Information governance and information security

You should confirm that where required  a DPIA (Data Protection Impact Assessment) and  an SSP (System Security Policy) have ben submitted and approved by your  Information Governance team. The RDS team can provide generic documents to support this process. Note that even informational RDS apps may involve an element of data transfer, as the default Contact and Feedback form involves transmission of an email address.

You should also confirm that copyright permission has been obtained for all content - including text and images - used within the tool , and ensure that appropriate attribution is noted within the tool.

UK CA marking and registration as a medical device

The legal requirement

It is a legal requirement that software which meets the criteria for a medical device is developed to meet the 12 Essential Requirements and meet the clinical safety and quality standards required by the Medical Devices Directive 93/42/EEC (MDD) and Medical Device Regulations 2002 (MDR)

A  manufacturer who holds legal responsibility for the software and applies a quality management system to the process of developing and maintaining the software is required to maintain a technical file providing  evidence that the software complies with these standards.

A risk classification from Class 1 (low risk) to Class 3 (highest risk) is assigned to the software.  Depending on the risk level, the software should then be:

  • For Class 1 medical devices - Registered with the Medical and Healthcare products Regulatory Agency (MHRA) for Class 1 medical devices.
  • For Class 2a and above - Have documentation and processes reviewed by an external notified body such as the British Standards Institute for medical devices at a higher risk classification level. The notified body will also perform regular audits following release of the software.

Following the registration or review process, the manufacturer submits a declaration of conformity with the Essential Requirements and  is issued with a certificate of conformance which enables the UK CA mark to be applied to the medical device.

Under the current Medical Devices Directive which is the active legislation in the UK, most RDS tools are likely to be classified as Class 1 medical devices. However, this legislation and the accompanying regulations are under review, and processes and documentation should be developed to a standard which will enable transition to a higher risk classification in future. 

You should also be aware that in the European Union an updated version of the Medical Device Regulations is in force. This rates the majority of clinical software at Class 2a and above. 

When is software categorised as a medical device?

According to the Medical Devices Directive 93/42/EEC (MDD):

" ‘medical device’ means any instrument, apparatus, appliance,
software, material or other article, whether used alone or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer
to be used for human beings for the purpose of: 

  • diagnosis, prevention, monitoring, treatment or alleviation of disease
  • diagnosis, monitoring, treatment, alleviation of or compensation or an injury or handicap
    investigation, replacement or modification of the anatomy or of a physiological process
    control of conception,

and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means."

The Guidance document MEDDEV 2.1/6 provides further detail on qualification and classification of software as a medical device. This clarifies that:

  • To be categorised as a medical device, software should "perform an action on data" - i.e.  not a static informational resource. 
  • To be categorised as a medical device, software should be used to evaluate data to benefit the clinical care of individual patients. Examples of software which are not considered as being for the benefit of individual patients and therefore are not medical devices, are those which aggregate population data, provide generic diagnostic or treatment pathways, scientific literature, medical atlases, models and templates.
  • Software  limited to storage, archival, communication, and ‘simple search’ functions is not classified as a medical device.

What evidence is required for the technical file?

The specifics of documentation will vary from case to case, but the following is a core list. Note that  for each document there are underlying standards and guidance which define the processes  to be followed and in some cases provide templates for the documents.

It is important to remember that the underlying purpose of all the documentation and processes is to ensure that the software is clinically safe and of the quality required for care of individual patients.

  • Outline of business requirements
  • Technical requirements specification
  • Software architecture design
  • Software development plan
  • Configuration management plan
  • Software maintenance plan
  • Problem resolution protocol
  • Risk report - based on Failure Modes and Effects Analysis (FMEA) clinical risk assessment
  • Test plan
  • Test reports
  • Release note
  • Instructions for use
  • Usability plan
  • Usability report
  • Clinical evaluation report
  • Post market surveillance plan with schedule for production of post market surveillance reports

Documentation should be updated as the software changes and develops. If the change to the software means that the description on the certificate of conformity is no longer accurate, a new declaration of conformity needs to be submitted.

Right Decision Service model for UK CA marking

DHI has a strategic partnership with Scottish Health Innovations Ltd (SHIL) whereby SHIL takes the role of legal manufacturer holding liability  for decision support tools categorised as medical devices. As  part of its remit from Scottish Government to  support innovations involving the NHS, SHIL oversees the development and delivery process for these tools, ensuring that they meet the required standards. Throughout the process, SHIL provides expert advice on applying the medical device legislation and regulations. 

Organisations partnering with DHI to deliver decision support tools which are medical devices benefit from this strategic collaboration with SHIL.