Medical device post-market surveillance is the safety check after launch: watch the field, catch what the trial missed, and feed the file. Clinical trials are a closed track. PMS is the road.
If you meant QMS / CAPA → medical device quality management system. If you meant living risk file → medical device risk management. If you meant FDA approval → FDA medical device approval process.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the regulatory agent / QMS vendor / GTM shop.
Proactive vs reactive
Proactive surveillance is the guard on patrol: you go get data to confirm the device is still safe and to spot a drift before it is an event. Reactive vigilance is the alarm: a complaint, an MDR, a malfunction — you investigate and close it.
You need both. A complaint-only system is late. A survey-only system misses the fire. The loop is: collect → analyse → report → change the device, the label, or the process → put the change back in the risk file.
PMCF, PMSR, PSUR, complaints
| Piece | What it is | Typical home |
|---|---|---|
| PMCF | Post-market clinical follow-up — studies or structured use data that keep the clinical evaluation current | EU MDR, most devices; useful evidence everywhere |
| PMSR | Post-market surveillance report — a short conclusions file | EU Class I |
| PSUR | Periodic safety update report — full benefit–risk from the period | EU Class IIa / IIb / III (annual or biennial by class) |
| Complaint / MDR | Reactive arm: intake, investigate, report when the rule says so | FDA 21 CFR 803; EU vigilance |
PMCF is not a leftover clinical trial. It is how you keep claiming the same indication after real users, real hospitals, and years on the clock. Complaints are not a call-center metric. A usability complaint can be a design input for the next revision and a CAPA in the QMS — that hand-off is QMS / CAPA.
FDA vs EU MDR
| FDA | EU MDR | |
|---|---|---|
| Stance | Mostly event-driven (MDRs, MAUDE, tracking for some devices) | Proactive lifecycle: PMS plan + PMCF plan as living documents |
| Reports | MDRs on a clock (often 30 days); periodic reports mainly on PMAs | PMSR or PSUR on a fixed class schedule |
| Risk file | Update when a new issue lands | Update from all incoming PMS data. The method is ISO 14971 |
If you build one global system, build it to the MDR bar. You will have the FDA data as a subset. Do not run two databases and reconcile in a spreadsheet the week the PSUR is due.
Where the data comes from
Passive: complaints, service records, MAUDE and peer literature, distributor returns. Cheap, biased toward the loud failure, under-reports the quiet one.
Active: PMCF studies, registries, structured user surveys, targeted literature. You ask a question. EU MDR expects this for most devices; FDA will take the same evidence.
One intake. Code the event. Trend it. Decide: label, design, process, or no action with a written reason. Then close the loop into CAPA and the risk file. That is the job. The 510(k) / PMA decision that got you here is already done — FDA approval process.
FAQ
Is PMS the same as a recall system?
No. A recall (or field safety corrective action) is one possible output. Most PMS cycles never get there. If you only stand up PMS when you need a recall, you are late.
Do Class I devices skip this?
No. The report is lighter (PMSR in the EU; fewer FDA periodic reports), not absent. Complaints still land. The risk file still moves.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the regulatory agent / QMS vendor / GTM shop. Case studies.