SaMD Development Support

When this is needed

• Intended use may place software in a medical device / SaMD category
• Engineering and RA need a shared plan before claims harden
• The product should be built to regulated-software expectations even if qualification is not yet filed
• Teams need a clear line between wellness / research tooling and medical device software
• AI-enabled clinical decision support raises both device and AI-governance questions

How we work

1. Intended use — claims, users, clinical vs non-clinical language
2. Qualification view — apply MDCG / FDA / IMDRF software tests to that intended use and state how likely medical-device / SaMD qualification is
3. Design as regulated software — lifecycle, risk, logging and evidence from the start when qualification is a reasonable possibility
4. Product and documentation plan — engineering collaboration suited to IEC 62304-oriented work
5. Coordination — device readiness and regulatory writing as needed; the client remains manufacturer and filing party

See How we work and Medical software for engineering standards (IEC 62304, ISO 14971, ISO 13485-aligned practices).

Qualification

Whether software is medical device software or SaMD is a test against intended use and published frameworks (IMDRF SaMD, MDCG software guidance in the EU, FDA device-software / SaMD guidance in the US). Those tests usually make the likely qualification clear well before any FDA marketing authorization or notified-body certificate. We apply them to the product and give a reasoned view.

• Medical purpose vs wellness, administrative or research-only language
• Users, clinical context and potential harm if the software fails
• Marketing claims vs what the software actually does
• What remains genuinely open vs what the rules already decide

A qualification view is not an FDA, notified-body or competent-authority decision. The client remains the manufacturer, submission holder and party of record for any filing.

Design-phase discipline

Where there is a reasonable chance the product will be SaMD or medical device software, we design and write it that way from the outset: software safety class, risk controls, change history, logs and documentation that a later technical file or DHF can use. That reduces the cost of redesign, retrospective logging and documentation catch-up if qualification is confirmed.

Lifecycle and documentation themes

• Software development planning, safety classification and requirements suitable for later technical-file / DHF inputs
• Risk management inputs (ISO 14971-oriented) tied to software failure modes
• SOUP / third-party component awareness and change control expectations
• Verification and validation evidence planning appropriate to risk class
• Cybersecurity and data-protection design themes proportional to product risk

In scope

• Reasoned SaMD / medical-device-software qualification against applicable frameworks
• Engineering and documentation from design onward when qualification is a reasonable possibility
• Coordination with regulatory documentation and device readiness workstreams

Example deliverables

• Intended-use and qualification notes with a reasoned SaMD / device-software view
• Planning artefacts for engineering and documentation tracks
• Lifecycle, logging and evidence inputs the client can take into QMS and filings
• Traceability and technical-file inputs when scoped with medical-software engineering

Out of scope

• Granting FDA marketing authorization, CE marking or any certificate
• Acting as a notified body, competent authority or the FDA

FAQ

Will you tell us if our app is SaMD?
Yes. We apply the applicable qualification tests to intended use and give a reasoned view of whether the software is likely medical device / SaMD software. That view is not a substitute for an FDA, notified-body or competent-authority decision. The client remains the manufacturer and filing party.

Why design as SaMD before a formal filing?
If qualification is a reasonable possibility, building to those lifecycle, log and documentation expectations from the design phase is cheaper than re-engineering after claims harden.

Is this the same as medical software engineering?
Closely related. SaMD support is the qualification view plus design-phase discipline when device rules may apply; medical software is the broader engineering and documentation depth.

Related

Medical software · Regulatory support · Device readiness · Digital health

For role boundaries (regulator, notified body, certification, outcomes), see Trust.