Digital
Health
Software is becoming medicine. We bring the evidence, endpoints, and regulatory strategy that turn a digital product into a cleared therapy.
Everything Downstream Depends on What Your Software Is.
Same codebase, four regulatory realities. Claim too much and you're marketing an uncleared medical device; engineer for too little and you carry a device QMS your product never needed. The classification call comes first, and it has to hold.
The same software can be a wellness app or a regulated medical device. The claim decides which.
General Wellness
Tracks fitness, sleep, or stress with no claim to diagnose or treat. Stays unregulated only as long as every screen, claim, and ad respects that line.
Clinical Decision Support
Informs a clinician who can independently review the basis for its recommendation. Miss one of the four statutory criteria and it's a device after all.
Class II SaMD
Diagnoses, drives, or informs treatment. Where most digital health products that matter actually land, and where most funding milestones live.
Class III SaMD
Sustains life or prevents serious harm: autonomous diagnosis, closed-loop therapy. Rare in software, and unforgiving when it applies.
The line moves. FDA redraws the wellness and CDS boundaries by guidance, not rulemaking, which means yesterday's safe harbor can become next year's enforcement letter. Our classification memos cite the guidance in force and are built to survive the next revision.
Ship. Clear. Keep Shipping.
A submission is a milestone, not the mission. The engagement is built around your release train — before the filing, through review, and long after clearance.
Software doesn't hold still after clearance. Neither can the regulatory file behind it.
Position
The strategy work that decides how hard everything after it will be: what the product is, which pathway fits, and what evidence the claim actually needs.
- Classification memo and regulatory strategy
- Pre-Sub briefing package and FDA meeting preparation
- Predicate analysis or De Novo positioning
- Clinical evidence plan sized to the claim, not the ambition
Clear
Submissions authored by people who have cleared software before — documentation matched to FDA's software guidance, cyber file complete, questions answered inside the clock.
- 510(k), De Novo, or PMA authored end to end
- Software documentation at the level the guidance demands
- Section 524B cybersecurity file: threat model, SBOM, SPDF
- Deficiency responses turned around inside the review clock
Keep Shipping
Clearance freezes a version; your roadmap doesn't. We run the change discipline that keeps releases moving without betting the clearance on any one of them.
- Change assessment every release: letter to file or new 510(k)
- Post-market surveillance built for software telemetry
- Real-world performance monitoring for AI features
- Annual cybersecurity and SBOM maintenance
Your Model Wants to Learn. Your Clearance Wants It Frozen.
A Predetermined Change Control Plan is how both win: describe tomorrow's model changes, the data that will drive them, and the tests they must pass — and FDA authorizes the roadmap, not just the snapshot.
Authorize the roadmap, not just the snapshot — so the algorithm can keep learning.
-
A PCCP written like engineering, not law
Modification descriptions concrete enough to code against, with acceptance criteria your CI pipeline can actually run — because a plan reviewers can't picture is a plan they won't authorize.
-
GMLP from dataset to deployment
Data provenance, representativeness, bias analysis, and drift monitoring aligned to Good Machine Learning Practice — the questions reviewers now ask by default, answered before they're asked.
-
Honest about the frontier
Generative and adaptive systems face review questions with no settled answers yet. We tell you what's knowable, engineer margin for what isn't, and keep the file current through our AI & ML compliance practice.
The Standards Are a Stack. We've Built Every Layer.
Naming the standards is easy. The job is wiring them into a ten-engineer team's sprint cadence without stalling it — evidence generated by the pipeline, not typed in after the fact.
IEC 62304, cybersecurity, and change control, wired into the sprint instead of bolted on after it.
IEC 62304
Design controls mapped onto the development process you already run. Requirements, architecture, verification, and traceability live in your repos and trackers — not in a parallel paper world your engineers stop updating by the third sprint.
ISO 14971
Hazard analysis that understands how software actually fails — race conditions, silent data corruption, automation bias, the update that breaks an integration downstream. Not a hardware FMEA with the word "software" pasted in.
Section 524B + ISO 81001-5-1
Threat modeling, a machine-readable SBOM, and a secure development framework spanning the product's life — the file FDA now refuses to accept submissions without, and the postmarket plan that keeps it honest.
21 CFR Part 11
Electronic records and signatures handled at the platform level, so audit trails and integrity controls are designed once and inherited by every feature — the approach behind our Data Integrity & Part 11 practice.
QMSR / ISO 13485
A quality system sized for a software company: SOPs your engineers will actually follow, aligned to the QMSR transition, and ready for the audit that follows your first clearance — built with our QMS Implementation team.
In Europe, the Default Answer Is "Higher Class."
MDR Rule 11 was written specifically for software, and it shows: code that clears FDA as Class II — or escapes device status entirely — routinely lands at Class IIa or above in the EU, in front of a notified body.
Under Rule 11, almost any software that informs a clinical decision is at least Class IIa, and the AI Act now layers a second conformity assessment onto high-risk AI systems. The answer isn't two compliance programs run in parallel — it's one technical file architected from day one to serve both, with the deltas managed deliberately instead of discovered late.
-
One file, many markets
Technical documentation structured so MDR annexes, FDA sections, and UKCA or Health Canada requests are views of the same evidence base — not rewrites commissioned per market.
-
Notified-body fluent
Rule 11 classification rationale, clinical evaluation per MDCG guidance, and responses shaped to how notified-body software reviewers actually read — grounded in our EU MDR & IVDR practice.
-
The AI Act, without panic
High-risk classification mapping, harmonized-standard tracking, and a conformity plan sequenced with your MDR timeline as part of a coherent European strategy.
Somewhere in your backlog is the feature that turns your app into a medical device. Better to find it before FDA does.
Talk to an Expert TodaySenior Reviewers Who Speak Both Git and eCTD.
The consultant in your design review has shipped regulated software, and the one drafting your 510(k) has answered FDA deficiency letters about code — because they're the same person. That's the difference between compliance advice and engineering judgment: knowing which controls reviewers actually probe, which ceremony adds nothing, and how to tell those apart under deadline.
-
Embedded in your tools
Requirements, risks, and verification evidence live in your Jira, Git, and CI — reviewed in your pull requests, exported when the submission needs them, never retyped into a binder.
-
A memo that survives diligence
Classification and pathway rationales get re-read by investors and acquirers at every round. Ours are written for that second audience too — the same standard our M&A diligence team applies from the other side of the table.
-
Fixed scope, sprint speed
Engagements run as defined projects — scope, timeline, and price locked up front, sequenced to your release calendar, per how we work.
Bring Us the Product. We’ll Tell You What It Is.
Thirty minutes, under NDA, no obligation: an honest read on classification, the pathway we’d run, and what your next release cycle needs to survive review. If the answer is “you’re not a device, and here’s how to stay that way,” that’s still a good meeting.
We typically respond within one business day.