FWL.ai home / Solutions / Post‑market & vigilance: overview (PMS / PMCF / PSUR)

Post‑market & vigilance: overview (PMS / PMCF / PSUR)

High‑level, source‑linked notes on post‑market obligations and readiness. No enabling implementation details; delivery packs are shared privately.

What this covers

  • PMS system & planning (including PSUR/PMSR where applicable)
  • PMCF planning & reporting (where required)
  • Vigilance & incident triage (trend signals, reportability, timelines)
  • Complaint handling ↔ CAPA linkage (audit narrative, not firefighting)
  • Evidence & integrity: versioned outputs, change logs, verification

This page is informational and points to official sources. It does not provide enabling implementation details.

How we support

  • Acceptance criteria first. Define what “done” means before building workflows or packs.
  • Traceable evidence. Controlled inputs, versioned outputs, and evidence that survives audit questions.
  • Private detail sharing. Templates, mappings, and operator runbooks are shared under scoped agreement.

Who is affected

Manufacturers and (where applicable) authorized representatives and other economic operators may have post‑market obligations. Scope depends on role, device class, and jurisdiction. Always validate against official guidance.

  • EU MDR/IVDR: PMS/PMCF/PSUR + vigilance reporting (role‑dependent)
  • Switzerland: swissdamed‑linked duties and Swissmedic guidance (as applicable)
  • US (where relevant): complaint handling + MDR reporting readiness

What to prepare

  • Role clarity: who submits, who approves, who owns timelines
  • Data hygiene: consistent identifiers, controlled vocabularies, traceable sources
  • Decision gates: reportability criteria, trend monitoring, escalation paths (thresholds kept internal)
  • Evidence: change logs, integrity manifests, approvals (who signed off, when)

Operationalization (high level)

  1. Scope and roles (portfolio triage, jurisdiction, responsibilities)
  2. Define gates (definition of done, timelines, escalation criteria)
  3. Build controlled inputs (datasets, logs, evidence sources)
  4. Package outputs (submission/report packs + audit narrative)
  5. Attach verification (checksums, manifests, approvals)

We publish structure and principles publicly. Enabling implementation details are shared privately.

Related updates

Context notes and primers. For current build and integrity artifacts, see Status.

Deliverables (public vs private)

Public

  • High‑level notes and primers (structure, boundaries)
  • Checklists and readiness categories (avoid rework)
  • Integrity‑verifiable downloads (where published)

Private detail sharing

  • Templates, mappings, operator runbooks (scoped)
  • Submission/report packs + evidence packs
  • Audit‑defensible handover trail (approvals, logs)