This is high level guidance and should not be used as a substitute for reading the legislation and full guidance from the MHRA and other bodies referenced in this SOP.

This guidance is not to be used in isolation. You cannot on your own acquire UK CA marking for a decision support tool built using the Right Decisions Platform.  InnoScot Health is the manufacturer which holds liability for all RDS tools categorised as medical devices. It is essential that you engage with the RDS team at an early stage in order to engage with InnoScot Health and:

• Determine whether your RDS decision support tool meets the criteria for a medical device.
• Determine the risk classification, if your decision support tool is categorised as a medical device.
• Work with InnoScot Health, the RDS team and Tactuum, the software company which develops and maintains the RDP, to produce documentation and follow processes to the required standards.

Decisions about medical device justification and classification need to be made on a case-by-case basis, and there are often different arguments and interpretations to be considered.

InnoScot Health takes the role of manufacturer (described in section 6 below) for RDS tools categorised as medical devices. InnoScot Health will take responsibility for registering the decision support tool as a medical device, and for managing the relationship with the British Standards Institute (BSI) and any audit requirements for medical devices classified as Class 2a and above.

If your proposed decision support tool meets the criteria for a medical device, InnoScot Health will extend its current Technical and Quality Agreement with the RDS team and Tactuum to include any areas of activity your organisation will be responsible for. For example, you might take responsibility for defining business requirements, for the usability plan and usability testing, or for the clinical evaluation.

Medical device justification

For software to be a medical device it must satisfy the following criteria. (Reference MedDev 2.1/6 July 2016).

Standalone software

1. Performing an action on data different from storage, archival, communication or simple search
2. Action is for the benefit of individual patients
3. Fits definition of medical device (93/42/EEC article 1.2a[1]) OR Accessory (93/42/EEC article 1.2b[2]).

Functional documents may also be considered a medical device (See MHRA guidance on software as a medical device).

A functional document is software that requires separate software to perform its function. Often this will be a general-purpose application such as Microsoft excel or word. In this context, a functional document will have a medical purpose.

Examples of Functional Documents include:

• A pdf that reproduces a treatment decision flow chart with logical links.
• Spread sheets - particularly if they provide complex functionality that is beyond that of existing paper charts e.g. an excel spreadsheet that calculates Glomerular filtration rate.
• Documents with macro or script enabled functions - complex medical applications can be written with languages such as visual basic.
• Interactive web pages - these can utilise programming languages such as JavaScript to produce medical applications.

Examples of general-purpose applications which are not considered functional documents according to MHRA guidance are: 

• Provides reference information to help a healthcare professional to use their knowledge to make a clinical decision
• Patient or professional medical education
• Monitors fitness/health/wellbeing
• Software to book appointments, request prescriptions, have virtual consultations i.e. administrative functions
• Stores or transmits medical data without change.

Medical purpose

For software to be classified as a medical device it must have a medical purpose (see MHRA guidance).

• Prevention of disease
• Diagnosis, monitoring, treatment or alleviation of disease, injury or handicap
• Compensation for injury or handicap
• Alleviation of Disease, injury or handicap
• Investigation, replacement or modification of anatomy or physiological process
• Control of conception.

Examples of software which does not have a medical purpose

• Patient or professional medical education
• Monitors fitness/health/wellbeing
• S/W to book appointments, request prescriptions, have virtual consultations i.e. administrative functions
• Stores or transmits medical data without change
• Provides reference information to help a healthcare professional to use their knowledge to make a clinical decision.

Decision Support Software

In general, decision support software is a computer-based tool which combines medical knowledge databases and algorithms with patient specific data. They are intended to provide healthcare professionals and/or users with recommendations for diagnosis, prognosis, monitoring and treatment of individual patients.

Decision support software unlikely to be a medical device:

• Reproduces paper document in digital form
• Follows path of procedure/treatment with no decision points
• Decision points where path is determined by clinician
• Offers lifestyle treatment choices or referral advice.

If the software satisfies requirements outlined above on Justification of Medical Device, it may be a medical device.

The following may be used to help inform the decision; however, each case must be considered on a case-to-case basis.

• Decision support software may not be considered a medical device if it exists only to provide reference information to enable a healthcare professional to make a clinical decision.
• If the software performs a calculation, interprets or interpolates data and the healthcare professional does not review the raw data then this may be considered a medical device.

Clinical Calculators

Many clinical calculators in principle meet the definition of a medical device but not all need to be UKCA marked. MedDev 2.1/6 allows some discretion for software performing a simple action.

MHRA guidance indicates that the following types of calculators are unlikely to be medical devices.

• Calculators without a medical purpose
• Simple scores/simple addition of assigned integer scores
• Simple calculations – basic functions of +, -, x, / which can be easily verified.

Calculators where the calculation/results cannot be easily verified are likely to be medical devices.

• Intermediate Calculations – more complex calculation with multiple variables using basic functions of +, -, x, / which cannot be easily verified.
• Complex Calculations which cannot be easily verified.
• Calculations with linked look up tables where the linked data is not displayed and the results cannot be verified.
• Calculators linked to specific drugs or devices are likely to be devices whatever the complexity of the calculation.
• Calculators pulling data from fields in an electronic patient record are likely to be devices if the simple calculation or data used cannot be easily verified.

When considering calculator classification, the intended user’s numeracy level should be taken into account. Evidence that the user can verify the calculation may be required through user studies. If the calculation cannot be easily verified by the intended user it is likely to be a device.

[1] 93/42/EEC article 1.2a ‘medical device’ Software 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 for 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.

[2] 93/42/EEC article 1.2b ‘accessory’ Software which whilst not being a device is intended specifically by its manufacturer to be used together with a device to enable it to be used in accordance with the use of the device intended by the manufacturer of the device.

Conformity Assessment for medical device regulation is determined by the classification of the device. Classification is a ‘risk based’ system based on the vulnerability of the human body, taking account of the potential risks associated with the devices. This approach uses classification rules which are set out in Annex IX of Directive 93/42/EEC.

The classification rules are based on criteria such as duration of contact with the patient, degree of invasiveness and the part of the body affected by the use of the device. All software is considered an active medical device.

Depending on the classification of the device there are a number of conformity assessment routes which can be used for the regulation of the device. These are outlined in 93/42/EEC, Article 11 and documented in the associated Annexes of the medical device directive.

For class I devices (non-sterile and without measuring function), the manufacturer is responsible for ensuring that products comply with the legal requirements. The manufacturer will compile a technical file with evidence of conformity and will sign a Declaration of Conformity. A UKCA mark is applied by the manufacturer and the device is registered with MHRA.

Where a Class I medical device is sterile or has a measuring function, assessment by a UK approved body is required for the functions relating to sterility or metrology.

Evidence

Directive 93/4/EEC Preamble

‘whereas the conformity assessment procedures for Class I devices can be carried out, as a general rule, under the sole responsibility of the manufacturers in view of the low level of vulnerability associated with these products; ‘

Directive 93/4/EEC, Article 11 Conformity assessment procedures, Section 5

In the case of devices falling within Class I, other than devices which are custom-made or intended for clinical investigations, the manufacturer shall, in order to affix the CE marking, follow the procedure referred to in Annex VII and draw up the EC declaration of conformity required before placing the device on the market.

(Annex VII – EC Declaration of Conformity)

European Legislation

Europe has transitioned to European Medical Device Regulation, also known as MDR (EU 2017/745). The MDR has introduced an additional classification rule which specifically relates to software. In many cases Class I medical device software will be upgraded to Class IIa or above.

This will require a different conformity assessment route.  The assessment route for devices with a classification higher than class I chosen by most manufacturers is the full quality assurance system (Annex II). The notified body reviews the technical documentation according to the regulatory requirements in the directives and the quality management system (ISO 13485). After a successful audit, the notified body issues two certificates - the QMS certificate and the CE certificate. Annual surveillance audits are conducted thereafter by the notified body.

Future UK Legislation

Although not published, it is anticipated that future UK legislation will mirror the MDR with respect to the introduction of a new classification rule for software.

Regulation of Higher Classification Devices.

It is important to understand that the level of documentation with respect to implementation of a Quality Management System and preparation of Technical File to provide evidence of conformity with the regulation/directive should be very similar for Class I and Class IIa devices. The key difference is that for Class I the manufacturer declares conformity while for higher classifications an external party will confirm conformity.

InnoScot Health implements and is accredited annually to ISO13485:2016 by BSi. As the legal manufacturer, should the software be reclassified the technical file could be assessed during annual surveillance audits.

Although not currently defined, it is anticipated there will be an appropriate transition windows for manufacturers who find themselves in the position of requiring external assessment.

InnoScot Health and the Right Decision Service have entered into a strategic partnership through which InnoScot Health takes the role of manufacturer for any Right Decision Service tools categorised as medical devices.

Manufacturer Responsibilities

InnoScot Health acts as manufacturer who draws up a declaration of conformity with the requirements of the Medical Device Directive and applies UK CA marking to the medical device. .

InnoScot Health performs the Manufacturer’s responsibilities as set out in various Clauses of the relevant legislation governing Regulation – i.e. to:

• Have a system for risk management
• Have a system for quality management
• Conduct clinical evaluations
• Compile technical documentation
• Apply a conformity assessment procedure
• Be responsible for devices once they are on the market
• Have systems in place to cover their financial responsibility for harm caused by defective devices.

Clinical Safety Issues

As a Manufacturer, InnoScot Health holds, and will continue to hold, product liability insurance to the value of £5m. The design, manufacture, verification and validation of medical devices will be the responsibility of the designers, clinicians and other participating parties under the terms of their respective contracts with SHIL. The legally binding contract SHIL will put in place with third party contractors will determine the roles, responsibilities and actions that are required to minimise any clinical risk associated with the device. Through a formalised risk management process any risks will be mitigated as much as possible and any residual risks documented. SHIL will provide oversight and scrutiny of fulfilment of these requirements by 3rd party contractors, thereby ensuring the rigor of the approach.

Quality Management System

As an organisation, InnoScot Health is accredited by BSi to ISO 13485:2016, a quality management system designed to meet the requirements for safe and effective design of medical devices. Risk management is integral to this process. In managing the design process, SHIL will be part of a development team and will set out the framework for the development process. This will result in a project plan with documented risk management assessments throughout the project. All design and development processes will be performed in accordance with appropriate ISO standards.

InnoScot Health, the Right Decision Service and Tactuum (software supplier for the Right Decision Service) have entered into a Technical and Quality Agreement which sets out all of the responsibilities of each party, including complying with the requirements of ISO 13485.

The design and manufacture of  DSS developed using the Right Decision Service complies with the requirements of ISO 13485:2016.

All technical documentation for decision support tools developed using the Right Decision Service is prepared in accordance with 93/42/EEC.

This framework for technical documentation has been set out and is compliant with both 93/42/EEC and EU 2017/745 regulatory approval. (It is anticipated that future UK legislation will align with EU legislation with some small deviations).

The technical file, which includes the manufacturer declaration of conformity which is registered with MHRA, is available for inspection by the Competent Authority (MHRA) or its designated UK approved Body.

Technical Documentation is sub-divided into two parts:

Part A:

Summary of essential technical data relevant to conformity assessment procedures

Part B:

Remaining technical documentation

(e.g.  risk analysis, test reports, standards, description of processes etc)

To give some insight into the detail of information provided, the technical file for Polypharmacy Decision Support contains the following information:

1. Introduction

2. Definitions

3. Referenced Documentation

4. Part A: Summary of Essential Technical Data

4.1. Name and Address of Manufacturer 

4.2. Identification of Device

4.3 Common or Usual Name

4.4. Device Classification

4.5. Name and Address of Facilities

4.6. Name and Address of Notified Body

4.7. Statement of the Conformity Assessment Procedure

4.8.  Declaration of Conformity

4.9. Brief Description of the Device

4.10. Intended Use

4.11. Label and Instructions for Use

4.12. Statement of Relevant Regulations

4.13. Identification of Technical Standard with which compliance is claimed

4.14. Brief Statement of Bench Testing and Clinical Data Obtained

Part B Technical Information

5.1. General

5.2. Technical Documentation

5.2.1. General Description of Device

5.2.2. Intended Use

5.2.3. Operation of Device

5.2.4. Devices incorporating a Medicinal Substance

5.2.5. Device incorporating Nonviable Materials of Animal Origin

5.2.6. Device requiring special consideration

5.2.7. Description of the methods of manufacture envisaged

5.2.8. Associated Equipment

5.2.9. Classification of the device under the relevant Directive

5.3. Technical Requirements

5.3.1. Rationale for Qualification as a Medical Device

5.3.2. Directive which applies to Calculator Suite

5.3.3. Applicable Essential Requirements

5.3.4. Solutions adopted to fulfil the Essential Requirements

5.3.5. Standards Applied

5.4. Design

5.4.1. Software Development Process

5.4.2. Result of Risk Analysis

5.4.3. Specification of Tools and Manufacturing Processes

5.4.4. Specifications

5.4.5. Specification of Production Tests

5.4.6. Performance and compatibilities intended by the manufacturer

5.4.7. Labelling - Instructions for Use

5.4.8. Shelf life reflected by any use-by dates or other lifetime of the device.

5.4.9. Results of bench testing

5.4.10. Clinical Data

5.4.11. Usability

5.4.12. Software

5.5. Administrative Details

5.5.1. Declaration of Conformity

5.5.2. Application for Conformity Assessment 

5.5.3. Declaration that no other Notified Body is used in Conformity Assessment

5.5.4. Notified Body Decisions and Reports

5.5.5. Manufacturer’s undertaking on procedure to review post-production experience

If any DSS software is reclassified and requires third party conformity assessment, this documentation is sufficiently robust to be submitted with minor amendments. This would be undertaken by InnoScot Health as part of on-going certification activities with BSi.