The Fork: Non-Device vs SaMD

Executive Summary

The answer determines whether you are on a relatively fast, operational track — or a longer, more resource-intensive path through medical device regulation. Getting it wrong doesn't just delay projects; it can render years of work unusable.

• Intended use test: If a system claims to diagnose, monitor, prevent, or treat disease, it is likely SaMD (Software as a Medical Device).
• Two tracks: Operational tools (non-device) follow Data Security and Protection Toolkit (DSPT) / data protection governance; SaMD requires Medicines and Healthcare products Regulatory Agency (MHRA) registration, quality systems, clinical evaluation, and ongoing surveillance.
• Timelines diverge: Non-device systems may deploy in months; SaMD pathways typically extend projects by years, not weeks.
• Governance implications: SaMD projects trigger different Trust approval routes (medical devices committees, clinical engineering, specialist procurement).
• Risk management: Borderline cases and scope creep are common. Teams need a process for recognising and managing when a system crosses into SaMD territory.

The Intended Use Test

The clearest way to draw the line is to ask:

Does the system diagnose, monitor, prevent, or treat disease?

• If yes → it likely qualifies as SaMD.
• If no → it is more likely a non-device system.

The rules change the moment you claim a clinical function. An operational analytics platform that shares information is not a device. But add automated alerts suggesting clinical action, and it becomes one.

Practical Examples

FHIR Cube: An operational data-sharing platform. It helps Trusts connect systems and enable reporting, but it does not make clinical claims. This is non-device territory.

SteadyTrace: A monitoring platform that generates clinical alerts. Because it is designed to influence patient care, it sits firmly in SaMD territory.

What the Fork Really Means

At first glance, the two tracks look similar. Both require governance, both need safe data handling, and both must be trusted by clinicians. But the differences matter:

Operational Realities for Trusts

Timelines: SaMD compliance typically adds years rather than months. This must be reflected honestly in board papers and project updates.

Resources: Maintaining technical files, safety logs, and surveillance requires ongoing resourcing, not just one-off project effort.

Governance pathways: SaMD projects introduce new committees and stakeholders — clinical engineering, medical devices committees, and specialist procurement routes.

Liability: Device classification affects insurance, indemnity, and organisational risk management.

Cost Categories to Expect

Every project is different, but SaMD compliance typically brings three broad categories of financial commitment:

• Regulatory fees – MHRA registration and application costs.
• Quality management – implementing and maintaining ISO 13485 or equivalent.
• Ongoing surveillance – post-market reviews, audits, and safety monitoring.

These are not one-off hurdles; they create a sustained cost profile that boards need to plan for.

Expertise Requirements

SaMD compliance cannot be delivered with standard IT project resources. It requires:

• Regulatory affairs expertise – for device classification and MHRA engagement.
• Quality management expertise – to implement and run a compliant Quality Management System (QMS).
• Clinical evaluation expertise – to produce credible clinical evidence.

Most Trusts do not hold these skills in-house. This usually means partnering, procuring external support, or recruiting specialised staff — all of which require early planning.

Borderline Cases and Scope Creep

Not every system is clear-cut. Many sit in the grey area:

• Operational dashboards where clinical teams request diagnostic add-ons.
• Decision-support tools that start by "informing" but drift into "advising."

Good practice includes:

• Creating an "intended use statement" early and reviewing it regularly.
• Keeping a device determination memo on file.
• Logging clinical feature requests and formally deciding if they push the system into SaMD territory.
• Seeking MHRA advice early when in doubt.

Managing Transitions Mid-Project

Scope creep is common, and sometimes inevitable. If mid-project a system crosses into SaMD territory:

1. Pause and re-evaluate the intended use.
2. Decide whether to pivot into SaMD compliance (with timelines and resources updated accordingly).
3. Consider separating features into two tracks: operational (deployable now) and SaMD (longer-term).
4. Document the decision formally for governance and assurance.

This protects projects from drifting into regulatory non-compliance without anyone realising.

International Considerations

UK MDR compliance does not automatically enable EU MDR or FDA access. For Trusts and suppliers with ambitions beyond the UK, this divergence must be factored into planning from the outset.

Making the Right Choice

Both tracks are viable — but they are not equivalent.

• The non-device track is faster, lighter, and suitable for operational systems.
• The SaMD track is longer, heavier, and requires sustained resource and expertise, but it enables high-value clinical tools.

The discipline is in making the choice early, documenting it clearly, and resisting scope creep unless the organisation is prepared for the regulatory consequences.

Looking Ahead

In our next post, we'll explore deployment and vigilance — showing how living compliance keeps systems safe long after go-live.

Summary: The intended use test provides a clear fork in the road: operational system or SaMD. The difference is not just regulatory, but operational and strategic. Choosing the wrong path — or sliding into SaMD without preparation — risks wasted effort, compliance failure, and patient harm.