Regulatory infrastructure
Every change to a cleared device forces the same call: new 510(k), or Letter‑to‑File?
Galen turns a code change, ticket or ECO into a cited, review-ready regulatory decision — a drafted Letter-to-File, or a flag that a new submission is likely required — in minutes rather than days.
The cost of getting it wrong
$50K–$250K+
Over-file
Burned on testing and submission prep for a 510(k) that a defensible Letter-to-File justification would have covered. A single misjudged filing costs more than a year of the review work it was meant to avoid.
Warning letter
Under-file
A change that needed a new submission documented as a Letter-to-File instead — surfacing years later in an inspection, with a recall as the downside case.
The decision leans on two dense FDA guidance flowcharts for device and software changes, your own change-control SOP, and quality records scattered across systems — the design history file, risk files, prior 510(k)s, verification and validation reports — plus live context from git, Jira and Polarion.
Today that work is manual, slow and inconsistent: hours per change, done by RA and QA staff or outside consultants billing $75–$450 an hour.
Both directions are expensive. The judgment itself is the bottleneck — not the paperwork.
How it works
Five steps from a change landing in your tracker to a signed record in your quality system.
- 01
Ingest
QMS and DHF records, prior 510(k)s and Letters-to-File, risk files — plus live context from git, Jira and ECOs.
- 02
Evidence dossier
Only the records this one change turns on, each excerpt traced back to its source.
- 03
Decision tree
FDA's change guidance as explicit, versioned logic. Every node cites what it branched on.
- 04
Cited draft
A .docx Letter-to-File — or a flag that a 510(k) is likely required — every field linked to its evidence.
- 05
Review and sign-off
Field-by-field accept, edit or reject. A separate approver signs. Galen never submits.
Galen drafts and cites. A named reviewer decides, and a second approver signs.
Why you can defend it
The realistic failure mode for a tool like this is a plausible-sounding, unsupported justification landing in a regulated record that an investigator reads years later. Galen is built against that specific outcome.
Every field carries a citation
An auditable decision tree, not a prompt
An assistant, not a system of record
A human decides, on the record
Built to be validated the way your QA team validates other quality-system software — QMSR §4.1.6 and ISO 13485 §4.1.6.
Every claim traces to a document. Every decision traces to a person.
Who it's for
An engineer ships a change. Someone now has to decide whether it is a Letter-to-File under 21 CFR 807.81(a)(3) or a new 510(k) — and defend that call to an auditor years from now.
That someone is usually an RA manager, a QA director, or a VP of regulatory affairs.
- Regulatory affairs and quality teams at medical device and medtech software companies.
- Active 510(k)-cleared product lines making frequent software or design changes.
- Single-product mid-market companies through to large multi-line device makers.
If that call lands on your desk more than a few times a quarter, Galen is built for you.
Design partners
Galen is in development.
We are onboarding a small number of design partners — RA and QA teams willing to put real change-control decisions in front of the pipeline and tell us where it falls short.