Medical Device Manufacturing

Manufacturing Execution for FDA QMSR and ISO 13485

Qontiv is designed to slot into a Class II or Class III medical device manufacturer's quality system without rebuilding it. Native DHR generation, CAPA, MSA, and 21 CFR Part 11 e-signatures — all in one MES.

Request a Demo

QMSR has been in effect since February 2, 2026. FDA is using the new inspection process today.

FDA's Quality Management System Regulation (QMSR, 21 CFR Part 820 revised) took effect February 2, 2026, closing the 2-year transition window that began with the final rule on February 2, 2024. The Quality System Inspection Technique (QSIT) has been withdrawn and FDA inspectors are using the updated Inspection of Medical Device Manufacturers Compliance Program (7382.850). Manufacturers still aligning their QMS today need an MES that captures the records and signatures inspectors are looking for.

If your Greenlight Guru renewal came back higher this year, price is the trigger — but the reason to look is structural. A standalone QMS runs beside your shop floor; Qontiv is the shop floor. CAPA records reference the actual work order. DHRs auto-generate from production transactions. Genealogy is captured at the point of work, not reconstructed from spreadsheets — so the record is complete by construction, not assembled the week before the inspection. Migration from Greenlight Guru, MasterControl, or a paper QMS runs through a structured data-export playbook and a 4-week pilot.

Quality modules designed for ISO 13485 and 21 CFR Part 820

Device History Records (DHR)

Auto-generated PDF per serial or lot. Ten section composers cover DMR conformance, production operations, in-process inspections, acceptance activities, genealogy, NC/CAPA references, label reconciliation, and a signatures index. Immutable archive with SHA-256 hash and retention policy (ClassIII: 10 yr, ClassII: 7 yr). Re-generated automatically when linked quality events occur.

• 21 CFR Part 820 (QMSR) — device history records via incorporated ISO 13485:2016 §7.5.1 (the standalone §820.184 was removed 2026-02-02)
• 21 CFR Part 11 §11.50 — e-signature index with printed name + datetime + meaning

CAPA & Nonconformance

State-machine governed CAPA: Initiated → RootCauseAnalysis → ActionPlan → Implementation → EffectivenessVerification → Closed. Root-cause method tracking (5-Why, Fishbone, Fault Tree). NC trend thresholds with auto-CAPA creation — configurable rolling window and count trigger. E-signatures at gated transitions.

• ISO 13485 §8.5.2 / §8.5.3 — corrective and preventive action
• 21 CFR Part 820 (QMSR) — CAPA via incorporated ISO 13485:2016 §8.5.2 / §8.5.3 (the standalone §820.100 was removed 2026-02-02)
• IATF 16949 §10.2 / AS9100 Rev D §10.2

See CAPA module →

Risk Management (ISO 14971)

Risk file per part revision with severity × probability matrix. Risk re-assessment triggered on Engineering Change Order (ECO). Full traceability from hazard to control measure.

• ISO 14971 — medical device risk management
• ISO 13485 §7.1 — risk-based approach

Measurement Systems Analysis (MSA)

Gauge R&R per AIAG MSA 4th edition acceptance criteria (%GRR <10% Accepted, 10–30% Conditional, >30% Rejected). Gauge master records, calibration interval tracking, and status states (Active / Quarantined / AwaitingCalibration / Retired).

• IATF 16949 §7.1.5.1.1 — MSA requirement for gauges in control plan
• ISO 13485 §7.6 — monitoring and measuring equipment

See MSA module →

Lot Genealogy & Traceability

Full forward and backward lot genealogy. Recall scope determination query returns every affected serial or lot in seconds, not hours. Genealogy is captured at the point of work — not reconstructed after the fact.

• 21 CFR Part 820 (QMSR) — traceability for implantable devices via incorporated ISO 13485:2016 §7.5.9.2 (the standalone §820.65 was removed 2026-02-02)
• ISO 13485 §7.5.8–7.5.9 — identification and traceability

Electronic Signatures

21 CFR Part 11 §11.50 signing ceremony on every gated operation — printed name, datetime, and signing meaning are captured and stored. Immutable once signed. Surfaced in DHR signatures index.

Signature records are immutable at the interface level: they cannot be modified or deleted through the application's data layer at all. Each carries a SHA-256 digest that is recomputed whenever the record is read, and a mismatch writes a tamper-detection entry to the audit trail on a separate database connection, so the evidence survives even if the transaction that surfaced it rolls back. Each signature is associated with the record it signed, and that association is immutable and covered by the same tamper detection. This is e-signature binding implementing 21 CFR Part 11 §11.50 and §11.70 controls, with IQ/OQ/PQ templates for customer-executed validation — Qontiv does not and cannot perform your validation for you.

• 21 CFR Part 11 §11.50 — signature manifestations
• 21 CFR Part 11 §11.70 — signature-to-record association, immutable and tamper-detected
• 21 CFR Part 11 §11.10(e) — audit trail for operator actions

Validation Accelerator Pack

Every Qontiv release ships a Validation Accelerator Pack — a single archive built offline from the release itself and attached to it, so the artifacts you validate against are versioned with the software rather than assembled by hand after the fact. It contains the executable test scripts, with IQ/OQ/PQ templates for customer-executed validation; ten reference documents including a 21 CFR Part 11 mapping, an EU GMP Annex 11 mapping, a GAMP 5 categorization, a vendor audit packet, an AI feature scope statement, an EU AI Act Annex III determination, a traceability matrix, a risk-scoping guide, a use guide, and a cross-reference template for your own SOP numbering. Installation-qualification evidence comes from the release's own architecture-test results, injected by the build. The archive is hash-manifested and published with a SHA-256 checksum alongside it, and an administrator can pull the current pack, or a specific release's pack, from inside the product.

The part that changes your upgrade economics is the regression map. Each test script declares what it must be re-run on, and the map is built by matching those declarations against the actual file diff for that release. An upgrade therefore tells you which scripts need re-execution instead of leaving you to argue for re-validating everything. The traceability matrix is generated from the requirements registry rather than maintained by hand, and the build fails if the committed matrix has gone stale.

On GAMP 5: the pack ships the Category 4 determination as a reviewable artifact. Qontiv does not compute a categorization for you, and no vendor can — the determination is yours to accept or restate.

• GAMP 5 — Category 4 determination supplied as an artifact for your review
• 21 CFR Part 11 §11.10 — controls for closed systems, mapped clause by clause
• EU GMP Annex 11 — separate mapping document in the same pack

Validation Lifecycle

The pack hands you the scripts; the Validation Lifecycle module is where your executed evidence lives. Each run is an append-only record whose identity — run type, the test script it executed, the Qontiv release tag it was executed against, who executed it, and when it started — is frozen at creation and cannot be edited afterwards. Only the lifecycle fields move: completion time, result, status, notes, and the approval signature.

Result is captured separately from status, so a completed run can honestly record pass, fail, or partial pass without the workflow forcing a verdict. Six states and six legal transitions govern the record, and approval and rejection are reachable only from completed — each writing its signature and its status change inside one transaction, so a signed run and an unsigned status can never diverge. Requirement traceability rows are stricter still: fully immutable, each carrying a functional-requirement anchor and that anchor's risk tier taken from the same requirements registry the pack's traceability matrix is generated from. That shared anchor is the seam between the two modules.

• 21 CFR Part 11 §11.10(a) — validation of the system for its intended use, recorded per release
• 21 CFR Part 11 §11.50 — approval and rejection are identity-bound signatures

Periodic Reviews

Four review types ship, each tied to the clause that requires it: a user access review (§11.10(g)), an audit trail review (§11.10(e)), an SOP and work-instruction effectivity review (§11.10(j) and ISO 13485 §4.2.4), and a validation status review (§11.10(a)). All four are provisioned for every tenant at quarterly cadence by default, and each can be set to monthly, quarterly, semi-annual, or annual.

The generator computes the most recently closed period and waits seven days past the period end before producing the packet, so late-arriving records land inside the period they belong to instead of falling through the gap between reviews. Generation is idempotent on review type and period start, so a restart cannot produce a duplicate. What it captures is concrete: active users with their role grants, last login, and multi-factor status; a genuinely random sample of audit-trail rows — ten percent with a floor of twenty-five by default — stored with the population count alongside it so the sampling ratio is itself auditable; approved work instructions whose effectivity window overlaps the period; and the validation-lifecycle runs started in the period with their type, status, result, script, and release tag.

The packet is append-only with its content snapshot fixed at creation. Six transitions govern it, and approval and rejection each write the signature and the status change in a single transaction. A review that is deferred stays deferred — closing it out means generating the next period's packet, not quietly reopening a past one.

• 21 CFR Part 11 §11.10(e) / (g) / (j) — audit trail, authority checks, and written-policy review
• ISO 13485 §4.2.4 — control of documents, reviewed on a defined cadence
• EU GMP Annex 11 §9 — periodic review of computerized systems

Veeva Vault QMS connector

Not available yet, and we would rather tell you that here than in week three of a pilot. The connector is written — four object types against Vault's REST API, covering controlled documents and SOPs, deviations, CAPAs, and training records — but it is not enabled in the shipped build, so it synchronizes nothing today. Treat Veeva coexistence as something we scope with you, not as a capability you can switch on.

The design decision behind it is worth knowing anyway, because it is the one question an eQMS coexistence discussion always reaches: when the two systems disagree about a document, which one is right? Our answer is the eQMS wins — the opposite of how the maintenance connector resolves it. If Vault is the system of record for a controlled document, a shop-floor edit should not quietly outrank it; the disagreement gets recorded with both versions and queued for a human rather than resolved by timestamp.

Post-market surveillance and management review

The post-market side of ISO 13485 is where a standalone QMS is weakest, because the inputs it needs — nonconformances, device history exceptions, CAPA status, risk-file changes — are production data it does not hold. Qontiv holds them, so these records compose from the floor instead of being re-keyed for a meeting.

Management Review

Twelve ISO 13485 §5.6.2 input categories, of which nine populate themselves from live MES data when the review is opened: audit results, customer feedback, process performance, product conformity, CAPA status, prior-review follow-up, supplier performance, QMS changes, and risk-file status. Supplier performance is its own input rather than a paragraph inside process performance, and risk status is its own input as well. Three remain deliberately manual — improvement recommendations, post-market surveillance narrative, and regulatory requirements — because those are management's judgment, not a query result.

Outputs follow §5.6.3's three categories — QMS improvement, product improvement, and resource needs — and each carries a decision, an owner, a due date, and a status, so the next review's follow-up input has something real to read. Closing a review requires an electronic signature, and closing it schedules the next occurrence from the configured cadence: annual, semi-annual, quarterly, or biannual. The record is append-only.

• ISO 13485 §5.6.2 / §5.6.3 — management review inputs and outputs
• ISO 14971 — risk-file status carried as a review input in its own right

Complaint handling and reportability

Complaints are append-only records with a retention field keyed to device lifetime plus two years. The flow is intake, investigation, response, closed, with a cancellation off-ramp from every non-terminal state, and each step is guarded rather than advisory: severity must be set before investigation, a documented root cause before a response, and both a sent response and a written closure justification before closure. Three of those transitions require an electronic signature. A trend evaluator watches item, cause code, severity, and complainant organization, with a cooldown of half the threshold window so one cluster does not fire repeatedly.

Reportability is decided in the open. At intake, incoming narrative is scanned for the language that maps to the serious-incident definitions at 21 CFR §803.3 and EU MDR Article 2(65) and flagged for a human decision. Downgrading a flagged complaint to not-reportable requires a written justification and is refused without one — §803.52's expectation, implemented as a hard block rather than a field label. A reporting deadline is then computed at triage from the confirmed severity and the destination regulator, and where both regimes apply the earlier deadline governs. A seven-day window ahead of that deadline drives an alert rule, so the clock is visible before it runs out rather than after.

The day counts themselves stay your regulatory determination, not ours. FDA and EU MDR each set tiered clocks — 21 CFR §803.50 and §803.53 for the FDA, EU MDR Article 87 for the EU, with separate tiers for a serious public-health threat and for death — and the tier that applies turns on facts about the incident that only your regulatory affairs team can settle. Qontiv's job is to compute a date from the determination you record, surface it before it expires, and keep the evidence of both. We will map your reporting schedule during the pilot rather than asking you to inherit ours.

• ISO 13485 §8.2.2 — complaint handling
• 21 CFR §820.198 — complaint files
• 21 CFR §803.3 / §803.52 — serious-injury definitions and the reportability justification
• EU MDR Article 87 / Article 2(65) — vigilance reporting and serious-incident definition

eMDR and EU MIR report generation

A reportable complaint generates its regulatory report from the record rather than from a re-typed form. The FDA path produces an HL7 v3 individual case safety report in the ICH E2B(R2) form used by 21 CFR Part 803. The EU path produces a Manufacturer Incident Report XML at schema version 3.0.28, with the administrative, manufacturer, device (including basic UDI-DI), incident, manufacturer-investigation, and submission sections populated. The generated XML is stored on the vigilance report record itself.

Two things we will not overstate. Both generators are schema-shaped and golden-file-locked — their output is regression-tested against committed sample files so a code change cannot silently reshape a submission — but Qontiv does not assert that it validates them against a regulator's published schema, and you should validate before you file. And submission is a manual upload to the regulator's portal, not an automated transmission: Qontiv gives you the file, and records the acknowledgment number you get back so the audit trail closes.

• 21 CFR Part 803 — medical device reporting, HL7 v3 ICSR in ICH E2B(R2) form
• EU MDR Article 87 / MDCG 2023-3 — MIR structure, schema version 3.0.28

PSUR — periodic safety update reporting

Fifteen sections, split honestly. Eight compose themselves from live records: the header, the complaint summary, adverse events, the nonconformance summary, device history record exceptions, CAPA status, risk-file changes, and serious incidents. Seven are authored by your regulatory team — sales volume, post-market clinical follow-up findings, the benefit-risk reassessment, regulatory changes, published and unpublished literature, and conclusions — and the report does not pretend otherwise.

The PDF is byte-deterministic: the same inputs produce an identical file, because the generation timestamp is passed in rather than stamped by the renderer, and that property is pinned by a test rather than asserted in a datasheet. A SHA-256 of the produced PDF is stored with the report, devices are grouped by basic UDI-DI for multi-device reports, and approval is an electronic signature. Cadence is annual or biannual.

• EU MDR Article 83 + Annex III — the post-market surveillance system this report draws on
• 21 CFR §814.84 — FDA annual report, served by the same composed record
• ISO 13485 §8.2.1 — feedback as a post-market surveillance input

Which plan carries this

Core — production tracking and work orders, lot and serial genealogy, electronic signatures, and the tamper-evident audit trail. The per-release Validation Accelerator Pack, with its IQ/OQ/PQ scripts for customer-executed validation, ships on every tier including Core.
Professional — full SPC, document management with approval workflow, worker training and competency, maintenance management, and the advanced analytics and alerting engine that the complaint reporting-deadline alert runs on.
ISO 13485 + FDA QMSR compliance package — CAPA and nonconformance workflows, risk management, device history records, complaints, incoming inspection, and supplier corrective action. Available today, and available on every plan as a priced annual add-on including Core — not bundled into a tier and not Enterprise-gated.
21 CFR Part 11 compliance package —available on request and scoped per engagement. The packaged validation wizard and clause-mapped controls report are not built. What ships today, on every tier, is the underlying substrate: immutable electronic signatures carrying a §11.50 meaning, the tamper-evident audit trail, append-only enforcement on every application write path, and the per-release validation packs.
Not itemized on the published price list — management review, PSUR, periodic reviews, and the Validation Lifecycle module are not separately priced line items. We scope them with you before the order form rather than quoting a number here that we would then be held to.

There is no free trial and no self-signup. Evaluation runs as a paid four-week pilot on one of your lines, at a published fee that credits in full against a first annual contract — the ladder and the pilot terms are atqontiv.com/pricing.

What this is — and what it isn't

Qontiv is not certified to ISO 13485 — the certification belongs to the manufacturer. Qontiv is designed to be compatible with a medical device manufacturer's certified quality management system, providing the records, controls, and traceability that auditors and inspectors look for. Your MDSAP or ISO 13485 certification body audits you; Qontiv supplies the evidence.

FDA QMSR is in effect. Are you ready?

Auto-generated DHRs, native CAPA, and MSA — designed for ISO 13485 and 21 CFR Part 820.

Request a Demo See compliance details