How V5 Ultimate runs a medical device site, end to end.

Every component lot, every cleaning record, every operator e-signature, every deviation, every counter-reading on a assembly station: if it isn't connected forward to the released batch and backward to the lot of starting material that fed it, the batch is unsafe at law. 21 CFR 820.184 doesn't ask for 'a record' — it asks for the complete history. EU MDR 2017/745 Chapter III on identification and traceability reinforces this.

Most medical device stacks treat traceability as an afterthought — bolt-on reports stitched together at audit time from paper logbooks, MES exports, LIMS spreadsheets, and a hand-typed DHR. V5 Ultimate inverts that: traceability is the spine the platform is built around. Every action on the floor, in QC, in the warehouse, on a supplier portal — writes one immutable record, with the lot, batch, operator, instrument, and timestamp baked in at the moment it happens.

The customer experience that follows is the obvious one: a recall that takes seconds, an inspector who asks for the DHR and gets a tab-complete answer, a CAPA that closes with linked evidence instead of a Word document and a prayer.

Read left-to-right. Every node writes to the same immutable ledger, and every node carries forward the lot, batch, operator, and instrument context from the node before it. Nothing is re-keyed; nothing is reconciled at the end.

V5 holds the supplier master with the qualification status, scope (material × site × grade), audit dates, and approved alternates. New suppliers go through a portal-driven onboarding: company info, regulatory licences, GMP/GDP certificates, allergen and BSE/TSE statements, change-notification commitments. Quality reviews, signs, and the supplier moves to 'Approved (scoped)'.

Re-qualification runs on a calendar — V5 chases expiring certificates automatically through the supplier portal and escalates if a document misses its window. The release engine refuses to consume any material whose supplier × material combination isn't currently approved. There is no 'override and ship' button; there is a quarantine-pending review.

A receiving operator scans the delivery, V5 checks the supplier/material combination against the approved master, prints (or e-stamps) a quarantine label per container, and creates lot records with a 1:1 link to the CoC, the PO, the carrier's docs, and the temperature log if the material is cold-chain. Status is Quarantine until QC dispositions it.

Sampling is driven by a sampling plan derived from material class (active component, excipient, primary packaging, label). V5 generates the sample request, prints the sample labels with traceable IDs, and the LIMS bridge carries the results back to the same lot. Disposition flips the lot to Released, Rejected, or Conditional — and every kiosk in the plant sees the change in real time.

Every bin, every container, every split lot carries a status: Quarantine, Released, On-Hold, Quarantine-Excursion, Rejected, Expired. Pickers see only what's pickable for the current work order — V5 hides the rest. FEFO is enforced by default; overrides require a documented reason and a second signature.

Movements (putaway, transfer, decant, split) write to the same ledger as the rest of the platform. A lot can be split into N child containers, each inheriting parentage; when you trace forward later, every child remembers the parent and the operator who did the split.

Cycle counts, recall sweeps, and stock-take reconciliations are filterable by status and supplier — a recall doesn't start with a spreadsheet, it starts with a query.

The DMR for a finished device holds the BOM and approved alternates, the routing (sub-assembly and final-assembly stations, fixtures, torque values, bonding/welding/soldering parameters, firmware image, environmental conditions), the in-process inspection plan with sampling rules, line-clearance and ESD controls between builds, the labelling and UDI artwork, and the release specification including the functional/final acceptance test (FAT). Every field is a structured slot the kiosk can render and the DHR can snapshot.

DMRs go through a two-signature approval workflow (author + QA approver, identity-verified e-signatures, Part 11). Once Effective, the DMR is locked; any change goes through change control (see §10) and produces a new minor or major version with effective dates. The release engine binds the work order to a specific DMR version; you cannot 'use the latest' by accident.

When planning releases a work order, V5 binds it to a specific DMR version and copies that version into the batch's DHR shell. Even if the DMR is revised next week, this batch will always reference what was Effective at release time. The snapshot includes BOM, approved alternates, routing across sub-assembly and final-assembly stations, fixture and tooling IDs, torque/bond/weld parameters, firmware image hash, IPC plan, line-clearance steps, labelling/UDI artwork, and the final acceptance test.

Operator availability, training currency, instrument and fixture calibration status, ESD-station verification, and clean-room (ISO 14644) certification status are all checked at release. A work order cannot be released to a station with an out-of-cal torque driver, an uncalibrated tester, or an operator whose training expired yesterday. The check is automated and immutable.

Build flows the way the DMR routing describes it. Components and sub-components are kitted against the work order, then move through sub-assembly stations (bonding, ultrasonic welding, soldering, screw/torque, potting, programming) before reaching final assembly. At each station the operator scans the work order and the parent serial or sub-assembly ID; the kiosk presents the exact step from the snapshotted DHR — torque value and window, weld parameters, fixture ID, firmware image to flash, ESD wrist-strap check — and refuses to advance until the connected tool or tester returns an in-spec result.

Where the process uses a smart driver, leak tester, vision system, ICT/functional tester or programmer, V5 captures the reading directly from the instrument — no hand-typed values. Out-of-window torques, failed welds, leak failures, FAT failures, or a missed line-clearance step hold the unit on the spot, open a non-conformance, and route it to rework, MRB or scrap with full genealogy preserved. Genealogy is built serial-by-serial: every sub-assembly's serial becomes a child of the parent device's serial, and the DHR remembers which operator, fixture and tool touched each one.

In-process inspections (dimensional/CMM, torque audit, weld pull or peel, leak/burst, ICT and functional test, vision/AOI, programming verification, cleanliness or particulate sampling for cleanroom builds) are scheduled by the DHR's IPC plan. V5 raises the sample or test request, prints a label with the traceable ID or binds it to the device serial, and accepts the result — entered at the kiosk by a trained inspector or returned automatically from the tester, CMM or LIMS bridge.

The final acceptance test (FAT) — functional, electrical safety, sterility/bioburden sampling where applicable — is the last gate before the unit can be packed. Any failure triggers an automatic hold on that serial (and a containment query across siblings built on the same fixture or from the same component lot) and opens a non-conformance. Trending across builds is continuous (CpK, control charts) so a drift toward the spec limit gets escalated before a single unit fails.

When the kiosk holds on an out-of-tolerance build-step, an OOS IPC, or a temperature excursion, V5 opens a Deviation linked to the work order, the step, the operator, the instrument, and the affected lot. QA triages, classifies (planned / unplanned, minor / major / critical), runs an impact assessment against other batches, and routes for CAPA if needed.

CAPAs are tracked to root cause with effectiveness checks at agreed intervals. Change control governs everything from DMR revisions to supplier substitutions to instrument firmware upgrades — each change with a risk assessment, validation impact, training impact, and a controlled effective date.

Packaging routings run the same way as manufacturing: a kiosk-led step list, reconciled label counts, line-clearance checks before any new batch enters the line, and a verified label artwork against the DMR. Serialisation (GS1 GTIN + serial, aggregation through bundle / case / pallet) writes to the same ledger; every SSCC carries the parent batch and a full hierarchy upward.

EU MDR UDI / EUDAMED (2D Data Matrix where applicable) and US FDA UDI (21 CFR 830) + GUDID (GUDID submission) are first-class outputs, not adapters. When a customer asks 'which case is this serial in, on which pallet, on which truck?' the answer is one query.

By the time the last step is signed, the DHR is complete: every build-step, every IPC, every deviation, every CAPA reference, every cleaning record, every operator e-signature, every instrument calibration evidence. QA reviews by exception — V5 highlights anything that wasn't a clean pass, and the reviewer disposition is the second of a two-signature release per procedure.

Release is gated by: all deviations dispositioned, all OOS closed, all open CAPAs assessed for impact, expiry date calculated from the established shelf-life model, and a stability commitment registered if applicable. A released batch generates the Certificate of Analysis from the same data — no re-typing.

Released batches ship with full pedigree under FDA UDI (21 CFR 830) + GUDID / EU MDR UDI / EUDAMED: every serialised unit's chain of custody is in the ledger before the truck leaves. Complaints land via a customer portal or a CSM ticket, route to QA, and link forward to a complaint investigation file that can spawn deviations and CAPAs.

When a recall is triggered, V5 answers four questions instantly: which lots of which materials are implicated, which batches consumed them, which units shipped from those batches, and which customers received which units. A trigger from any node propagates in seconds; no analyst, no spreadsheet, no overnight reconciliation.

User roles & permissions, training matrix with currency enforcement, instrument calibration with auto-hold on lapsed cal, validated cleaning protocols with verification swab results, environmental monitoring with trended alert/action limits, supplier qualification status, deviation & CAPA workflow, change control, internal audit program, management review with KPI dashboards. Each is a first-class object with its own lifecycle and audit trail.

The platform doesn't 'support' the QMS — the QMS is what the platform is. Every action everywhere checks the QMS state and refuses to proceed if a control is missing or expired.

V5 ships a full Document Management System: hierarchical taxonomy (Quality Manual → Policy → SOP → Work Instruction → Form), document numbering rules per site, draft / in-review / effective / superseded / obsolete statuses, and configurable workflow (e.g. author → SME → QA → site head). Read-acknowledgement assignments push the new SOP to every affected role and block kiosk login until the operator has signed the read-and-understood.

Periodic review is calendar-driven — V5 raises a review task at the configured cadence (typically 12, 24 or 36 months), routes it to the document owner, and escalates if it slips. Change requests link to deviations, CAPAs, audit findings, or change controls so the 'why' is always inside the file. Redlines are diff-tracked between versions; the audit trail captures who saw what, when, on which device.

V5 holds the training matrix as role × competency × currency. New hires get a curriculum auto-assigned on day one (induction, GMP basics, gowning, ESD, site safety, role-specific SOPs); completion is recorded with quiz scores, observation sign-offs from a qualified trainer, and a re-qualification interval. Competencies are linked to physical actions: assembly station sign-off, torque & test audit, line clearance, DHR review, supplier audit.

The kiosk and DHR enforce the matrix at the moment of action. An operator whose 'assembly station operation' competency expires at midnight can't start a press / weld shift the next morning until requalified. Trainer qualifications are themselves competencies — only qualified trainers can sign off another operator's competency record. Re-training is auto-scheduled when an SOP is revised, when a deviation root cause cites training, or when a metric (e.g. operator-attributable defects) trends adverse.

21 CFR 820.20 (Management responsibility, US) and ISO 13485 §5.6 (Management Review) both require a written annual review covering at minimum: every batch produced and its release outcome, all in-process and finished-product test results with trends, all deviations and OOS, all returned / complained / recalled product, all changes made to the product, the qualification status of equipment and utilities, and stability programme results.

Because every one of those data points is already in the ledger, V5 maintains a live Management Review workspace per product per year. Trend charts (CpK, OOS rate, deviation by category, recovery yield) refresh nightly. At year-end, QA reviews the assembled draft, adds the executive summary and the proposed actions, signs the report, and exports a regulator-ready PDF — typically a week of work instead of a quarter.

V5 holds the audit programme: scope (internal area, supplier, contract manufacturer), risk-based frequency, lead auditor assignment, checklist library aligned to ISO 13485, ISO 19011, and applicable GMP chapters. Audit execution captures findings inline with photographs, evidence references, classification (critical / major / minor / observation), and immediate corrections.

Findings auto-route to the affected area, link to the CAPA workflow, and stay open in the management dashboard until effectiveness is verified at the configured interval. Regulatory inspections (FDA, EMA, MHRA, local authority) use a dedicated Investigator Mode — a read-only scoped view with one-click evidence export, an inspection log capturing every document shown, and a real-time response workspace for the inspection team to draft, review, and submit Form 483 responses or equivalent.

V5 holds product risk assessments (FMEA, HACCP-style hazard analysis, PHA), process risk assessments per routing, supplier risk profiles, and computer-system risk assessments per IEC 62304. Each risk has owner, severity / occurrence / detectability scores, current controls, residual risk, mitigation actions, and review cadence.

Risk drives behaviour. Sampling plans are scaled to material risk class. Change controls inherit a default risk assessment template by change type. Validation depth (URS → IQ/OQ/PQ effort) scales to GAMP category. Audit frequency for a supplier scales to that supplier's risk profile and historical performance. When residual risk crosses a threshold, V5 raises a CAPA automatically.

V5 hosts the stability programme per device family / pack configuration / climate zone (ISO 11607 stability + IEC 60601 service life). Protocols are versioned: ISO 11607 accelerated + real-time pack-aging, ASTM F1980, IEC 60601 service-life testing. The pull schedule is generated automatically and surfaces in the QC kiosk on its due date; samples carry the originating batch context so any trended drift can be traced to its source.

Results land in the same trend engine as in-process QC — Arrhenius and shelf-life projection models flag any test approaching spec before it crosses. Out-of-trend (OOT) triggers an investigation; out-of-spec (OOS) triggers a market-impact assessment, a stability commitment review and, if warranted, a controlled recall workflow.

V5 ingests EM data from particle counters, viable air / surface plates, RODAC sampling, glove-print monitoring, and continuous instruments (T, RH, ΔP, dew point, TOC for purified / WFI water, microbial / endotoxin trends). Sampling plans are gridded to the clean-room (ISO 14644) map and scheduled per area grade (ISO 5/A, ISO 7/B, ISO 8/C, etc.).

Alert and action limits are codified per location; excursions auto-route to QA, link to the batches in production at the time, and gate release if the impact assessment is open. Annex 1 (2022) contamination control strategy (CCS) is supported as a living document — each control referenced back to the data feed and the SOP that owns it.

V5 manages the cleaning matrix: every product pair × shared equipment train, with the carry-over limit calculated from ISO 10993-17 tolerable intake (biocompatibility carry-over), the worst-case soil, the validated cleaning SOP, swab and rinse sample plans, and the analytical method. Changeover at the kiosk follows the protocol step by step; results return from the lab and a clean-status flag flips on the equipment train.

Released equipment carries a 'clean window' — if the next run isn't kicked off inside it, V5 forces a re-clean or a hold-time validation reference. Periodic re-validation is calendar-driven and re-triggered automatically when a new product enters the train or a cleaning SOP is revised.

V5 holds the asset register: equipment ID, location, manufacturer, model, qualification status (DQ / IQ / OQ / PQ with linked validation packs), calibration plan, PM plan, change history, criticality classification. Calibration certificates are stored with as-found / as-left values; any out-of-tolerance triggers a back-look assessment against batches the instrument touched since the last successful calibration.

PM is scheduled by runtime hours, calendar, or condition (vibration, particle count). Open work orders for an instrument prevent its scheduling on a production routing. Spare-parts inventory is linked; minimum stocks per critical asset trigger a purchase requisition before a breakdown. Decommissioning is a controlled workflow with data-archive and verification.

V5 ingests complaints from the customer portal, sales / CSM channels, and a generic component for external case-management or call-centre systems. Each case opens with reporter, product, lot / serial (look-up enforced), category (quality / labelling / packaging / suspected adverse event), severity and reportability assessment. The case auto-links to the DHR for the implicated batch and to any other open complaints on the same lot.

Investigations route to QA with a structured root-cause workflow (5-Why, fishbone, Ishikawa templates). Returns are reconciled against the original shipment, with disposition (re-stock / re-work / destroy) recorded against the same ledger. Suspected adverse events feed a medical devicecovigilance intake module — case narrative, MedDRA coding, expedited reporting decision (CIOMS / E2B), and audit trail of every regulator transmission.

Attributable — every action is bound to an identity-verified user account. Legible — every record renders in human-readable form on demand, with the original raw value retained. Contemporaneous — actions write at the moment they happen, not at end-of-shift. Original — raw instrument readings are captured and retained; transformations are versioned. Accurate — tolerances, calculations, and validation rules are codified, not described.

Plus: Complete (no fragmenting across spreadsheets), Consistent (one ledger), Enduring (immutable audit trail, time-stamped), Available (queryable for the full retention period). IEC 62304 CSA is the validation posture — risk-based testing focused on patient impact, with documented evidence the system does what the URS says.

Supplier portal for CoCs, audits, change notifications, and document acknowledgements. Customer portal for DoCs, shipment pedigree, complaint submission, and document subscriptions. QA dashboard for KPIs (RFT, OOS rate, deviation cycle time, CAPA closure rate, audit-finding age). Investigator-mode for FDA / EMA / MHRA / local inspectors — read-only, scoped to the inspection window, with one-click evidence export.

Reports are generated from the live ledger, not built from an export. When a regulator asks 'show me batch X', the answer is a URL, not a PDF emailed at 11pm.

Onboarding follows a fixed playbook: site discovery → import of supplier master / material master / DMR library → role mapping → kiosk hardware list → validation pack tailored to your products → operator training → go-live walk-through. Most sites are running first batches on V5 inside three weeks; full QMS migration completes inside a quarter.

Support is tiered: a 24/7 incident channel for floor-stopping issues, a CSM for adoption and change control, a regulatory advisor for inspection prep, and a quarterly platform review to surface emerging risks and KPI drift.

This is the abbreviated mapping. Each link below opens the full readiness guide for that regulation.