On software products and medical devices.

Scarlet’s approach is designed for assessing medical software

Certifying a medical device can be:

• time intensive; and
• costly.

This is especially the case with medical device software which has the capacity to change frequently.

It is therefore natural for manufacturers to explore regulatory strategies that:

• minimise the number of devices they are developing;
• minimise the number of interactions they have with conformity assessment bodies; and
• squeeze as much potential functionality as possible into a single intended purpose statement in order to future proof the device.

The result is medical devices that have broad scopes, often spanning multiple:

• clinical conditions;
• user groups;
• modes of action; and
• patient populations.

Why is this a problem?

It makes compliance with regulatory requirements harder. For example, the purpose of clinical evaluation is to identify or generate clinical data to support the safety and performance of the device when used according to its intended purpose. Where an intended purpose is excessively broad, the ability of a manufacturer to acquire the necessary clinical data to support that intended purpose in a timely manner is reduced.

This approach to structuring devices is commonplace and has not changed even with increased interest in medical device software.

Is there a better way?

Scarlet invites manufacturers to think about, not the device(s) they are developing, but rather the product(s) they are developing. Most companies, healthcare-focussed or otherwise, are developing a product, a service, or a combination of both.

Establishing how best to structure a device needs to start with a deeper analysis of the features or components that comprise a product:

Product: 
- Feature 1 
- Feature 2 
- Feature 3
- Feature 4 
- Feature 5 
- Feature 6 

Features might be simple software modules (e.g. software to login a user), complex software modules (e.g. an AI algorithm that generates a triage recommendation), or perhaps hardware (e.g. a smartwatch).

Unfortunately, many manufacturers will attempt to claim that all the features that comprise their product or service are part of their medical device:

Device: 
- Feature 1 
- Feature 2 
- Feature 3 
- Feature 4 
- Feature 5 
- Feature 6 

For the purposes of a conformity assessment, the manufacturer will need to provide regulatory data relating to all these features, which may or may not be necessary.

This leads to an unnecessarily complex device.

Instead, by understanding and analysing the functionality of the features that comprise a product, a manufacturer can start to add labels to their features:

Product: 
- Feature 1 <- has medical purpose (for patient group A) 
- Feature 2 <- has medical purpose (for patient group B) 
- Feature 3 <- has medical purpose (for patient group B) 
- Feature 4 <- helps (1) and (2) achieve their medical purposes 
- Feature 5 <- no medical purpose 
- Feature 6 <- hardware 

Then, they can start to think about how best to compose those features into appropriate regulated concepts like devices and accessories:

Product:
 
- Medical device 1 
  ↳ Feature 1
 
- Medical device 2 
  ↳ Feature 2 
  ↳ Feature 3
 
- Accessory 
  ↳ Feature 4
 
- Non-certifiable software 
  ↳ Feature 5
 
- Hardware 
  ↳ Feature 6 

In this scenario, although there are now two medical devices, the resulting conformity assessments will only need to consider regulatory data for a smaller number of features.

Now consider when the manufacturer wants to create a new feature with new functionality. As before, they can determine the nature of this feature:

- Feature 7 <- has medical purpose (for patient group A)

They can then establish how it should be incorporated into the wider product:

Product:
 
- Medical device 1 
  ↳ Feature 1 
+ ↳ Feature 7
 
- Medical device 2 
  ↳ Feature 2 
  ↳ Feature 3

- Accessory 
  ↳ Feature 4
 
- Non-certifiable software 
  ↳ Feature 5
 
- Hardware 
  ↳ Feature 6 

In this scenario, only 'Medical device 1' is modified and requires additional assessment and certificate modification. Medical device 2 and the Accessory are unchanged.

Scarlet’s ‘product-first’ approach has the following advantages:

• it allows manufacturers to make more concrete claims in relation to their product;
• it sets clearer expectations on what regulatory data is required to support those claims; and
• it provides manufacturers with a clear mechanism to develop their product over time.