The clinical product development process for healthcare SaaS is a staged sequence that converts a concept into a clinically validated, regulatory-ready piece of Software as a Medical Device (SaMD), backed by traceable requirements, verification and validation (V&V) evidence, and a documented post-market surveillance plan. If you run each stage correctly, you end up with a product that satisfies both FDA (CDRH) expectations and the software lifecycle discipline described in IEC 62304, not a patchwork of demos and hope.
- A staged roadmap from feasibility through post-market surveillance
- Requirements traceability and a V&V plan founders can start today
- A clear split between exploratory feasibility work and confirmatory testing
Treat feasibility and confirmatory validation as two separate projects, run by two separate mindsets. The Startup MD sees more regulatory rework caused by blending those two than by any single technical failure.
Key Takeaways
The clinical product development process succeeds when feasibility, design controls, and V&V are run as sequential, traceable stages rather than parallel guesswork.
| Point | Details |
|---|---|
| Separate feasibility from confirmatory testing | Run them as distinct projects with different success criteria and documentation standards. |
| Start traceability early | Link user needs to requirements to tests before your first design freeze. |
| Match validation pathway to claim | Retrospective, MRMC, prospective, or pivotal testing should reflect the strength of your actual claim. |
| Run the 520(o) test before study design | Confirm CDS exemption eligibility before investing in a full clinical study. |
| Bring in fractional clinical leadership early | The Startup MD's fractional CMO model connects clinical evidence planning directly to investor-facing readiness. |
Table of Contents
- The Clinical Product Development Process Explained Stage by Stage
- Running Feasibility Research Without Wasting the Work
- Building Design Controls and a Software Quality System Early
- Verification and Validation: Matching the Test to the Claim
- Do You Need an IRB, and When Does IDE Apply?
- Managing Data and AI/ML Lifecycle Controls
- What Counts as Market Readiness for a Clinical Software Product
- A Practical Timeline for the First 18 Months
- How The Startup MD Supports Your Regulatory Roadmap
- Sources
The Clinical Product Development Process Explained Stage by Stage
Seven stages carry a healthcare SaaS product from whiteboard to market, and each has a different owner and a different exit gate.
- Feasibility — owned by the founder or product lead, ends with a go/no-go decision on technical and clinical signal
- Design controls and QMS setup — owned by regulatory affairs or a fractional CMO, ends with an approved requirements baseline
- Verification and validation — owned by engineering plus clinical, ends with a completed V&V report
- Human testing and regulatory pathway selection — owned by regulatory affairs, ends with an IRB determination and a Q-Sub outcome
- Data and AI/ML lifecycle controls — owned by data science and regulatory jointly, ends with a locked model version
- Risk, usability, and market readiness — owned by product and clinical, ends with a completed readiness checklist
- Launch and post-market surveillance — owned by the executive team, ends with a live surveillance plan
Each transition is a decision gate. Skipping one doesn't save time; it just moves the rework downstream, usually right before a submission deadline.
Running Feasibility Research Without Wasting the Work
Feasibility testing exists to answer one question: does the underlying approach show enough technical and clinical signal to justify building the real thing? Write that question down as a formal success criterion before you start, not after you see promising numbers. A one-page feasibility protocol, with a defined sample, a defined metric, and a defined pass/fail threshold, keeps the team honest and gives you a real artifact for later.
Guidance on digital health product development recommends bringing in software quality-system elements during feasibility rather than waiting until you're closer to submission. That means tracking requirements per software module from day one, even while the product is still a prototype.
- Define feasibility success criteria in writing before testing begins
- Log requirements-in-progress even for exploratory builds
- Track software of unknown provenance (SOUP) components as you add them
- Capture user interviews and simulated-input tests as dated records
Pro Tip: Version everything, including the "throwaway" prototype. Six months from now, an auditor or investor will ask what changed between v0.3 and v1.0, and "we don't know" is not an answer anyone wants to give.
Building Design Controls and a Software Quality System Early
A risk-proportionate quality management system doesn't need to be heavy to be real. Most early-stage SaMD teams need three reference points: ISO 13485 for the quality system backbone, IEC 62304 for mapping the software development lifecycle, and ISO 14971 for risk management touchpoints that run alongside design work rather than after it.
Requirements traceability is the connective tissue. User needs flow into software requirements, which flow into architecture decisions, which flow into test cases. A simple three-column matrix (requirement ID, source need, verifying test) is enough to start; you can expand it as the product grows.
- Map every user need to at least one software requirement
- Link every requirement to the architecture element that implements it
- Link every requirement to the test that verifies it
- Review the matrix at every design change, not just at submission time
Pro Tip: Lock your intended use and intended user population before you write a single line of marketing copy. A vague intended-purpose statement is the single fastest way to trigger reclassification questions later.
Verification and Validation: Matching the Test to the Claim
V&V is not one test; it's a ladder. Unit and integration tests confirm the code does what it's supposed to do. Bench testing or simulation confirms the software behaves correctly against known inputs. Retrospective computational validation checks performance against held-out historical data. Prospective clinical validation, sometimes structured as a multi-reader multi-case (MRMC) study, checks real-world performance, and pivotal trials confirm claims strong enough to support a marketing submission.
A step-by-step validation map ties four validation pathways directly to the strength of claim you're making, which keeps teams from over-testing low-risk features or under-testing high-risk ones. Every single test on that ladder needs to map back to a specific functional or design requirement; a test with no requirement behind it is evidence for nothing.
- Match validation pathway (retrospective, MRMC, prospective, pivotal) to claim strength
- Confirm test data is fully separate from training data, no exceptions
- Report confidence intervals and subgroup performance, not just headline accuracy
- Watch for the common pitfall: retrofitting a requirement to justify a test you already ran
Statistic callout: Feasibility and confirmatory testing are treated as distinct regulatory activities, and testing datasets must stay separate from training datasets. Blending the two is one of the most common reasons submissions bounce back for rework.
Do You Need an IRB, and When Does IDE Apply?
Human subjects testing triggers Institutional Review Board (IRB) review, and the IRB determines whether your study is Significant Risk (SR) or Non-Significant Risk (NSR). An SR determination usually means you need an Investigational Device Exemption (IDE) before you can proceed. Getting this wrong late in a study design is expensive; getting it wrong before you've built anything is just a delay.
A founder's guide to SaMD clearance recommends running the 520(o) exemption test early to check whether your clinical decision support features even qualify as a regulated device, then filing a Q-Sub (pre-submission meeting request) before finalizing pivotal study design.
- Run the 520(o) test to check for CDS exemption eligibility
- File a Q-Sub or pre-IDE meeting request with FDA before locking study design
- Determine SR versus NSR status with your IRB before enrolling any subjects
- Confirm whether a predicate device exists, then choose 510(k) or De Novo accordingly
- Draft labeling and claims that match exactly what your evidence plan can support
- IRB review is required for essentially all human subjects research
- A Q-Sub meeting is nonbinding but dramatically reduces guesswork
- Claims that outrun your evidence plan are the most common source of review delays
Managing Data and AI/ML Lifecycle Controls
Training data and testing data are not the same asset, and mixing them is a regulatory red flag, not a shortcut. Document provenance for every dataset, check representativeness across the populations you intend to serve, and keep your preprocessing pipeline documented well enough that someone else could reproduce it.
Once your model performs well enough to move toward human testing, lock the version. Traceable model lineage, meaning you can point to exactly which weights, which training data, and which preprocessing steps produced the version under test, is non-negotiable for a clean submission. If you expect to update the algorithm after clearance, start designing a Predetermined Change Control Plan (PCCP) now; a PCCP needs a description of modifications, a modification protocol, and an impact assessment built in from the start, not bolted on later.
- Document data provenance and representativeness before training begins
- Separate training and testing data completely, with no leakage
- Lock the model version before starting human testing
- Draft your PCCP early if post-clearance updates are part of the plan
Pro Tip: Build subgroup analysis into your validation plan from day one. Regulators increasingly expect to see how your model performs across demographic and clinical subgroups, and retrofitting that analysis after the fact is far more expensive than designing for it upfront.
What Counts as Market Readiness for a Clinical Software Product
Risk-benefit analysis, grounded in ISO 14971 outputs, has to connect directly to the strength of your clinical evidence. A weak evidence base paired with an aggressive claim is the fastest way to draw extra review questions, or an outright rejection.
Usability validation under IEC 62366 covers both formative testing (early, iterative feedback) and summative testing (final validation with representative users). Human factors issues, confusing alerts, ambiguous data displays, missed critical values, are among the most common triggers for additional regulator scrutiny, so don't treat usability as a checkbox exercise near the end.
- Clinical evidence report tied to your original risk-benefit framework
- Completed requirements traceability matrix, updated through final design
- Cybersecurity artifacts, including a software bill of materials (SBOM) and a vulnerability management process
- Final labeling reviewed against your actual evidence, not your original ambition
- A documented post-market surveillance plan ready before launch, not after
Founders preparing for this stage often benefit from a structured look at market entry strategy alongside the regulatory checklist, since commercial and regulatory readiness need to land at the same time.
A Practical Timeline for the First 18 Months
Most teams underestimate how much of the first year should be spent on documentation rather than feature building. A rough sequencing helps set expectations with investors and hires alike.
- Months 0 to 3: feasibility protocol, initial requirements log, SOUP tracking, early QMS setup
- Months 3 to 6: design controls finalized, traceability matrix built out, V&V plan drafted, 520(o) analysis run
- Months 6 to 12: bench and computational validation, Q-Sub meeting, IRB submission, data lineage documentation locked
- Months 12 to 18: prospective or pivotal validation, usability summative testing, cybersecurity artifacts finalized, submission prepared
- Bring in regulatory counsel and a biostatistician no later than month 3
- A fractional CMO can own the clinical strategy thread across all four phases without a full-time hire
- Each gate above should produce a real artifact, not just a status update in a slide deck
How This Guidance Was Compiled
This playbook draws on published regulatory guidance, including the NIH's digital health regulatory framework and current SaMD classification standards, combined with practitioner experience advising healthcare SaaS founders through validation and submission planning. Paul Bergeron, MD, MBA, brings more than 25 years of combined clinical and startup leadership experience to that advisory work.
In one advisory engagement, a founder team had spent four months building toward a prospective clinical study before realizing their intended claim only required a retrospective validation pathway. A fractional CMO review reset the plan and cut roughly two months off the projected timeline to first submission.
- Author: Paul Bergeron, MD, MBA, The Startup MD
- Method: regulatory guidance review combined with direct fractional CMO engagement experience
- Case pattern: matching claim strength to validation pathway prevents over-building evidence
A Founder's Note on What Actually Goes Wrong
The mistake I see most often isn't technical. It's founders choosing a validation pathway based on what sounds impressive to investors rather than what their actual claim requires. A retrospective study done well beats a prospective study done rushed. Bring in clinical leadership before you lock your study design, not after your first Q-Sub meeting raises questions you weren't ready for.
How The Startup MD Supports Your Regulatory Roadmap
The Startup MD works as your fractional Chief Medical Officer rather than a general consultant, which means the same person who helps you interpret an IRB determination also helps you frame that evidence for investors. That dual lens, clinical and commercial in one seat, is the gap most healthcare SaaS teams are missing when they hit their first Q-Sub meeting.
Services include fractional CMO engagements, clinical strategy development, regulatory roadmap drafting, clinical evidence planning, and investor-facing evidence summaries built to withstand real diligence. If you're heading into a funding round, a revenue model and investment readiness evaluation can help you connect your clinical evidence plan directly to what investors will actually ask. Request a discovery call through The Startup MD's services page to get an evidence-gap assessment before your next regulatory milestone.
Sources
- Regulatory Knowledge Guide for Digital Health (NIH OER)
- FDA SaMD Regulation: A Founder's Guide to AI/ML Clearance
- Clinical Validation Pathways for AI/ML SaMD: A Step-by-Step Map — Pelican Tech Blog
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.