Leanabl Logo
Contact Us
plmproduct-lifecycledesign-controlsiso-13485

PLM Implementation for ISO 13485 Compliance

7 min read

Most medical device manufacturers run PLM at 30% of its potential because the deployment was scoped to engineering rather than to ISO 13485 design controls. A guide to bridging the gap.

Leanabl Editorial
PLM Implementation for ISO 13485 Compliance

The PLM-as-CAD-Vault Trap

A typical medical device PLM deployment story: engineering needed a place to manage CAD files and BOMs, IT procured a PLM platform (Windchill, Teamcenter, Arena, Solidworks PDM), the deployment focused on engineering needs, and the platform shipped with CAD vaulting, BOM management, and engineering change orders (ECOs) live.

Quality and regulatory affairs were not deeply involved in the deployment. The platform technically supports design controls integration, traceability matrices, and regulatory file generation — but those modules are not configured. Engineering uses PLM daily; quality and RA continue using document control systems (Veeva, MasterControl, Greenlight Guru) plus spreadsheets.

The result: PLM is running at maybe 30% of its potential, and the design history file (DHF) lives in three or four systems with manual reconciliation. ISO 13485 §7.3 design controls are technically met, but the audit defensibility is weak because traceability is reconstructed at audit time rather than maintained continuously.

What PLM Should Do for ISO 13485

A PLM platform — properly configured — can serve as the operational backbone for ISO 13485 §7.3 design controls. Specifically:

Design Planning (§7.3.2)

The PLM holds the design plan as a structured object, not as a PDF deliverable. Phases, deliverables, design reviews, and resource allocation are tracked with status. When the design plan changes, the change runs through controlled revision.

Design Inputs (§7.3.3)

Design inputs are structured items in PLM, each linked to:

  • User needs (upstream)
  • Risk control measures (cross-reference)
  • Applicable standards and regulatory requirements (cross-reference)
  • Design outputs that fulfill the input (downstream)

This linkage is what produces the traceability matrix automatically rather than as a maintained spreadsheet.

Design Outputs (§7.3.4)

Design outputs are the engineering deliverables — drawings, code, specifications, materials lists, manufacturing instructions. The PLM holds them with version control, approval workflow, and effectivity dates. Each output references the design inputs it fulfills.

Design Review (§7.3.5)

Formal design reviews are conducted as structured events in PLM. Participants, agenda, decisions, action items, and outcomes are captured. Approval signatures (electronic, Part 11 compliant) gate phase transitions.

Design Verification (§7.3.6)

Verification protocols and reports are PLM objects, linked to the design inputs they verify. The link establishes the traceability from input to verification evidence. Verification results inform the design output release.

Design Validation (§7.3.7)

Validation protocols and reports — including human factors / usability validation per IEC 62366 and clinical validation per ISO 14155 — are PLM objects linked to user needs (not just design inputs). Validation traces back to the higher-level user need or intended use element being validated.

Design Transfer (§7.3.8)

Transfer from design to production is a controlled event. Work instructions, manufacturing process specifications, and production tooling specifications are released from PLM. The MES (production execution system) consumes these as the authoritative source.

Design Changes (§7.3.9)

Design changes flow through ECO/MCO (Engineering Change Order / Manufacturing Change Order) workflows in PLM. Impact analysis — what is affected by this change — is automatic based on the linkage between objects. Changes require approval workflow before release.

The Configuration Gap

Most PLM deployments cover the engineering core (BOM, CAD, ECO) but leave gaps in:

  • User needs management — typically tracked in a separate requirements management tool or in Word/Excel
  • Risk management — typically tracked in a separate risk tool or in Excel
  • Verification/validation traceability — typically reconstructed from V&V folders, not maintained as live links
  • Clinical evaluation linkage — typically separate from design controls entirely
  • Regulatory submission generation — done manually from PLM exports, not generated natively

Closing these gaps usually does not require a new platform. Modern PLM platforms support these capabilities; they need configuration and content migration.

A Practical Configuration Plan

For a manufacturer with existing PLM scoped to engineering and wanting to extend to full ISO 13485 design controls:

Phase 1: User Needs and Intended Use (Months 1–2)

Migrate user needs and intended use statements into PLM as structured objects. Establish the linkage from user needs down to design inputs.

If user needs currently live in a separate requirements tool (DOORS, Jama, ReqIQ), evaluate whether to:

  • Migrate them into PLM (single system, more integration)
  • Maintain the requirements tool with bidirectional sync to PLM (best-of-breed, more integration complexity)

For mid-size manufacturers, migration into PLM is usually the right answer. Requirements tools justify their own existence only at significant scale.

Phase 2: Risk Management Integration (Months 2–4)

Migrate the ISO 14971 risk file into PLM, structured as:

  • Hazards (objects)
  • Hazardous situations (linked to hazards)
  • Risk controls (linked to hazardous situations and to design inputs)
  • Residual risks (linked to risk controls)

The risk file becomes a live system in PLM with traceability to design inputs and design outputs. Risk file updates trigger impact analysis automatically.

Tools like Greenlight Guru offer focused risk management capabilities that some manufacturers prefer to keep separate from PLM. The integration consideration is the same as for user needs.

Phase 3: V&V Traceability (Months 3–6)

Migrate verification and validation protocols and reports into PLM, with explicit links to the design inputs (for verification) and user needs (for validation) being addressed. The traceability matrix becomes a query, not a maintained document.

Phase 4: Clinical Evaluation Linkage (Months 6–9)

For Class IIb and III devices, link the clinical evaluation report (CER) and the periodic clinical evaluation update to the relevant design inputs and risk controls. This integration is required by EU MDR but is often missing in legacy PLM deployments.

Phase 5: Submission Generation (Months 9–12)

Configure PLM to generate structured technical file content for FDA, EU MDR, and MFDS submission formats. The submission itself is not generated by PLM (the cover letter, regulatory-specific phrasing, and packaging are submission-specific), but the technical content modules can be drawn directly from PLM.

The benefit at this stage is real: submissions that took 12 weeks to prepare from a fragmented document system can be prepared in 4–6 weeks when PLM produces the technical content directly.

What This Looks Like at Audit

A well-configured PLM-anchored design controls system produces an audit experience that differs from spreadsheet-based DHF defense:

  • Auditor asks for the traceability from user need to verification — produced in two clicks from PLM, with live linkage.
  • Auditor asks for the design change history of a specific component — produced as a structured timeline from PLM.
  • Auditor asks for the risk control measures applied to a specific hazardous situation — produced from PLM with full traceability to verification evidence.
  • Auditor asks for the latest approved BOM as of a specific date — produced from PLM with effectivity dates.

The audit becomes a queries-against-the-system exercise rather than a folder-hunting exercise.

Where the Resistance Comes From

Three sources of resistance to extending PLM beyond engineering:

  1. Quality team comfort with existing tools. Veeva, MasterControl, Greenlight Guru have mature workflows quality teams have invested in. The migration cost is real.

  2. Engineering ownership of PLM. Engineering "owns" PLM in many companies; extending PLM scope feels like ceding ownership to quality/regulatory. This is a governance issue more than a technical one.

  3. Integration with adjacent systems. A unified PLM means changes to integrations with eQMS, MES, and ERP. The integrations work, but they have to be redesigned.

These are real concerns, not blockers. The decision is whether the audit-defensibility and submission-efficiency benefits justify the migration investment.

Where Leanabl Plugs In

The Platform PLM service runs PLM platform selection, configuration, and migration for medical device manufacturers — specifically scoped to ISO 13485 design controls rather than to engineering-only deployment. For design output and design history management directly, Design Output handles ongoing operational support. For broader PLM-MES-eQMS integration, Platform eQMS and Platform MES plug in. Upstream design controls work that feeds clean content into PLM runs through Discovery & Design.

Have a regulatory question?

Talk to a Korea regulatory specialist about your device, your timeline, or your next submission.

Talk to a specialist