F&G StrategyF&G Strategy Academy
← All modules
Module 4

The Multi-Modular Minefield

Intermediate45 to 60 min

Before asking what class a product is, ask how it should be structured for regulation. Getting this wrong can turn Class IIa into Class III, a 9-month timeline into 30, and a manageable technical file into an unmanageable one.

Common issues: When to separate modules for regulation versus bundle them as one device.

Progress: 0 of 8 sections complete0%

A. The core principle

A medical device is defined by its intended purpose. Two functions with different intended purposes, different intended users, and different risk profiles can be regulated as two separate medical devices even if they live in the same application.

Two functions with the same intended purpose serving the same users in the same clinical context should generally be regulated together.

  • The classification of a bundled product is determined by its highest-risk function. Bundle a Class I function with a Class IIb function and the entire product is Class IIb. Every part must then meet Class IIb requirements, including the Class I function that would otherwise need only self-certification and a simple technical file.
  • The classification of a separated product is determined by the highest-risk function within each separate device. The Class I module is self-certified. The Class IIb module goes through Approved Body conformity assessment. The Class I module can be updated freely without triggering change control for the Class IIb module.

B. When separation is right

Separation is worth considering when at least one of the following is true.

Materially different risk profiles

A symptom tracker (Class I) bundled with an AI clinical decision support tool (Class IIa) drags the tracker into Class IIa unnecessarily. Separating them means the tracker stays at Class I and only the clinical decision support tool needs Approved Body involvement.

Different intended users

A consumer-facing wellness app and a clinician-facing dashboard serve different users with different expertise and different decision-making contexts. These are almost always better regulated as separate products.

The consumer app may not be SaMD at all. The clinician dashboard probably is.

Different development cycles

If the AI model is updated monthly but the psychoeducation library is updated annually, bundling means every AI update triggers change control review for the entire product. Separating means AI updates are managed under the AI module's change control only.

Could be commercially separated

If you could sell one function independently and it would still make clinical sense, it is a candidate for separation. If the functions are meaningless without each other, they belong together.

C. When bundling is right

Bundling is better when the functions form a single clinical pathway that would create interface risk if separated. The clearest example is an assessment tool that feeds directly into an intervention tool.

A symptom screener that determines which CBT module a user should complete next cannot meaningfully be separated from the intervention it drives. Separating them creates a regulatory interface between two devices that function as one clinical system, and that interface creates new risks that are harder to manage than the risk of bundling.

If the functions share the same intended purpose, the same intended users, and the same clinical context, separating them is artificial and will create complications rather than simplify them.

Separation decision matrix

The separation versus bundling decision otherwise rests entirely on adviser judgement, so this matrix exists as a structured triage tool rather than a definitive rule. Two or more yes answers indicates separation is worth pursuing as a serious option, but this is a threshold for further analysis, not a rule that mandates separation.

For each candidate split, run through these five questions. Separation is worth pursuing if you answer yes to two or more.

QuestionIf YES → consider separatingIf NO → consider bundling
Can modules function independently?One module works without the othersModules depend on each other
Are risk profiles different?One is IIb, others are I/IIaAll similar risk
Are intended purposes distinct?One for diagnosis, one for treatmentAll serve the same clinical purpose
Do development cycles differ?Frequent updates to one module onlyUpdated together
Is separation commercially viable?Modules are sold separately anywayThe bundle is the product
Self-assessment
A company has a CBT-based intervention app for adults with mild to moderate anxiety. The app contains a fixed-content psychoeducation library updated annually and an adaptive symptom-tracking module that flags clinical deterioration and is updated quarterly as the underlying detection model is refined. Both features serve the same adult anxiety population. Is separation worth pursuing? A — yes, separation is worth pursuing; B — no, bundle as a single product.

Pattern 1 — Foundation plus add-on

The base product is a mood diary, psychoeducation library, or wellbeing tracker. This is Class I or not SaMD.

The company adds an AI coaching feature generating personalised recommendations based on user data. This feature is Class IIa or higher.

Wrong approach

Regulate the whole product as Class IIa. The mood diary and psychoeducation library now need a full ISO 14971 hazard log, IEC 62304 software lifecycle documentation, and Approved Body review.

The development team cannot update the psychoeducation content without triggering change control.

Right approach

Keep the foundation as a non-SaMD or Class I product regulated separately. Regulate the AI coaching module as the SaMD only.

The foundation updates freely. The AI module has its own technical file, hazard log, and change control process.

Commercial implication

The developer can launch the foundation fast, build a user base, and introduce the regulated AI module once certification is complete. This is a commercially superior strategy as well as a regulatory one.

Pattern 2 — Assessment plus intervention

A symptom screener generates a clinical output. The same product then delivers a personalised intervention based on that output.

Both functions are Class IIa or higher. The screener output directly determines the intervention pathway.

Wrong approach

Separate them to reduce apparent complexity. Separation creates a regulatory interface that is harder to manage than the combined product and raises new questions about who is responsible for safety at the handoff.

Right approach

Regulate as a single bundled Class IIa or higher device. The technical file covers both functions.

The hazard log addresses the risk at the screener level, the intervention level, and the interface between them.

Clinical implication

The developer cannot shortcut this by labelling one function one product and the other another if they function as a single clinical pathway. The MHRA and Approved Bodies look at how the product is actually used, not how it is labelled.

Pattern 3 — Consumer version plus clinical version

The company builds a consumer wellness app with no SaMD qualification and a separate clinical version with a clinician dashboard, risk flagging, and NHS integration that is Class IIa.

Wrong approach

Regulate the consumer version under the clinical version's technical file. The consumer version is now a medical device by association and must meet Class IIa requirements even though its functions do not.

Right approach

Two entirely separate products with separate intended purposes, separate intended users, and separate regulatory documentation. The consumer version may need no MHRA registration at all.

The clinical version has its own technical file and Approved Body conformity assessment.

Commercial implication

The company can iterate and market the consumer version freely while the clinical version goes through certification. They can also price and distribute them differently.

The Kova case study

Kova as designed has three features: conversational AI (Class III under EU MDR Rule 11), weekly mood check-in trend chart (Class I under UK MDR, Class IIa under EU Rule 11), and parent dashboard (Class IIb, Class III arguable). The overall bundled product is Class III, driven by the conversational AI.

Timeline to certification: 24 to 30 months. Estimated cost: £300,000 or more.

The developer has an alternative architectural option.

Kova re-architecture — one Class III product into a manageable split
Kova as designedBundled · Class III · 24–30 months · £300k+
Separate the carer dashboardAssessed as its own product (IIa/IIb).
Restrict AI scope; crisis suspends the AIMain product falls toward IIa/IIb.
ResultMain product IIa/IIb + carer tool · 9–18 months · cost ÷3 to 5
Step 1 — Separate the carer dashboard

Remove the parent dashboard from Kova and make it a distinct product: the Kova Carer Tool, regulated separately. Assess the Kova Carer Tool independently.

It may be Class IIa or IIb rather than Class III depending on how clinician oversight is structured into the dashboard design. Classification position after this step: the main Kova product remains Class III because the conversational AI scope is unchanged and continues to drive the bundled classification.

The carer tool is now a separate product to be assessed independently, potentially Class IIb rather than Class III depending on oversight design.

Step 2 — Redesign the AI scope

Redesign the conversational AI to restrict its scope to psychoeducation and skills content only. Introduce a crisis detection function that suspends the AI and displays fixed crisis resources rather than generating AI responses to crisis content.

Reassess: does the redesigned AI still reach Class III, or does it fall to Class IIb or IIa? Classification position after this step: if the conversational AI is successfully restricted to psychoeducation and skills content with crisis detection suspending the AI rather than generating responses, the main product likely falls to Class IIb or Class IIa.

Which of the two depends on whether the residual risk of an incorrect AI output could directly cause serious deterioration in the adolescent user population (Class IIb) or only significant deterioration manageable through standard clinical pathways (Class IIa).

Step 3 — Decide on the mood chart

The mood check-in trend chart is either bundled with the redesigned AI module (Class IIa or IIb) or separated as a Class I feature. Given it functions as an input to the AI module, bundling is the more defensible approach.

Classification position after this step: the final architecture is the main Kova product (redesigned AI plus bundled mood chart) at Class IIa or IIb, and the Kova Carer Tool at Class IIa or IIb assessed separately. Class IIb is the more defensible position for the main product given the adolescent population and the residual risk of the AI module even within a restricted scope.

Possible result

Kova main product Class IIa or IIb, Kova Carer Tool Class IIa or IIb assessed separately. Timeline falls to 9 to 18 months.

Cost falls by a factor of three to five. This is a strategic design decision worth hundreds of thousands of pounds to the developer.

It cannot be made after the product is built. It must be made before significant development investment is committed.

This is what a regulatory positioning review surfaces.

Exercises

Form your own view first. Reveal the reference answer to compare reasoning.

Exercise — The meditation app expansion

A company starts with a basic meditation app: a library of fixed guided audio sessions, a usage tracker, and a streak counter. No personalised outputs, no clinical claims — not SaMD. The company plans to add four features. (1) Personalised meditation recommendations generated by an algorithm that analyses usage patterns and self-reported mood ratings to suggest the next session. (2) Wearable sleep integration pulling nightly sleep duration and HRV from a consumer wearable, displayed as a weekly summary chart. (3) An AI guidance chatbot users can talk to about stress, sleep, and mood; it adapts to conversation history and usage data and suggests specific coping strategies. (4) A clinician dashboard for therapists showing session completion, mood, sleep data, and a weekly AI-generated summary used to inform session planning. Choose the best regulatory architecture. Form your own view first.

What is the best architecture?
Pick an option for each question to compare against the reference answer.

Self-assessment — The GP weekly summary feature

A company has a direct-to-consumer mental health app (not SaMD) and wants to add a feature allowing users to share their data with their GP, who receives a weekly summary report with a clinical risk flag. Should this be a new feature in the existing app or a separate product?

Best regulatory architecture?
Pick an option for each question to compare against the reference answer.

Downloadable resources

Print-friendly companions to this module.

Separation Decision Workbook (PDF) ↓
Structured worksheet for working through the separation decision on a real product: feature inventory, the five separation questions, alternative architectures, and a recommendation field.
Regulatory Architecture Map Template (PDF) ↓
One-page visual template: feature inventory, blank architecture diagram with module boxes and labelled data-flow arrows, and a summary table of class, route, timeline, and cost.
Bundling vs Separation Quick Reference Card (PDF) ↓
Two-column reference: five reasons to separate, five reasons to bundle, the three patterns, and the key principle on highest-risk function classification.

Educational resource. Not formal regulatory or legal advice.