eQMS Technical Files, DMR, and Cross-Product Document Links

Buyers evaluating an eQMS for IVDR and FDA device work ask: how do technical files and the Device Master Record (DMR) stay linked when one design output changes? Manual copies in two folders go stale the day someone forgets a paste. The answer is not a deeper folder tree. It is explicit product-to-document relationships, shared vs product-specific ownership, and change control that shows which products inherit a revised design output.

What is the DMR in plain terms?

The Device Master Record (DMR) is the set of documents and specifications that define how a finished device is manufactured, packaged, labeled, and tested as applicable. In U.S. quality system language, the DMR is the manufacturing recipe set for the finished device—not the full story of how you designed it.

By contrast:

• The Design History File (DHF) records the design project: inputs, outputs, reviews, verification, validation, and design transfer evidence.
• The Device History Record (DHR) records what happened for a specific lot or unit: production history against the DMR.

Auditors walk the path from a design change to the DMR documents that must update, then to DHRs that show lots built under the new revision. If your eQMS only stores PDFs in product-named folders, that path is a scavenger hunt.

For primary U.S. references on device quality system expectations, consult the FDA Quality System regulation overview and the regulatory text on eCFR (including DMR-related requirements under the quality system rules applicable to your products). ISO-aligned organizations should map the same relationships to ISO 13485 documentation and medical device file concepts used in their markets.

What is a technical file in the EU context?

Under EU medical device and IVD frameworks, manufacturers maintain technical documentation (often still called a technical file in daily speech) that supports conformity assessment and post-market obligations. Structure and depth depend on classification and route, but the operational problem matches the DMR problem: many documents are shared across products, and a change must update every scope that inherits them without contradictory revisions.

A sound eQMS does not force you to pick “FDA view” or “EU view” as exclusive folders. It lets controlled sources feed:

• An FDA-oriented DMR index per product
• An EU technical documentation index per device or device family
• Shared libraries for SOPs, sterilization instructions, and platform component specs

Why cross-product links matter

Shared SOPs, shared component specifications, shared labeling templates, and platform software live under multiple products. Without explicit links:

• A change to a common sterilization instruction updates Product A’s pack and misses Product B
• Two products silently diverge on the same “shared” work instruction because someone saved a local copy
• Impact analysis for a change order becomes a memory test
• Auditors find different effective revisions for the “same” document title across sites

A sound eQMS lets you:

• Attach documents to a product / technical file / DMR scope
• Mark shared vs product-specific ownership
• See which products inherit a shared document revision
• Keep version history on each controlled attachment
• Run impact reports: “if I revise document D, which products and open changes are affected?”

Information model that holds up under change control

Think in objects and links, not paths:

1. Product / catalog item — commercial or regulatory identity
2. Document — controlled content with revisions and effective dates
3. Link type — DMR element (for example labeling, formulation, assembly, inspection), DHF evidence, training, or technical file section
4. Ownership — product-specific vs platform/shared library
5. Change request — proposes new revision and lists impacted products via links
6. Training / effective release — same revision ID the DMR index points to

Folder paths can still exist for human browsing. They are not the system of record for relationships.

DHF vs DMR without casual duplication

Teams often paste the same PDF into “DHF” and “DMR” libraries and then update only one. Prefer:

• Single controlled document object
• Multiple roles or link types pointing at it (design output vs manufacturing specification)
• Clear lifecycle: design output approved → transferred → becomes or updates DMR content under change control

Where a manufacturing specification must differ from a design report (redacted parameters, production-only tolerances), create an intentional derived document with a trace link—not a silent copy.

IVDR / MDR technical documentation vs DMR

They serve related but different purposes:

• EU technical documentation supports conformity and notified body / authority review across the device lifecycle.
• The DMR focuses on the manufacturing and related specifications for the finished device in the U.S. quality system sense.

Structure your eQMS so EU technical file packs and FDA-oriented DMR views can share controlled sources without contradictory revisions. Section mapping tables (which internal doc fills which technical documentation heading) beat parallel unlinked trees.

Related reading includes eQMS document management from draft to training and eQMS production batch and lot traceability.

How design changes should ripple

A healthy flow:

1. Engineer or RA opens a change affecting a design output.
2. System lists products linked to that document (and child documents if configured).
3. Change owner confirms or adjusts the impact list.
4. Reviews and approvals follow your quality procedure—including any product-specific approvers for high-risk devices.
5. On release, each product’s DMR / technical file index shows the new revision with effective date.
6. Training tasks fire for roles tied to that revision where required.
7. Lots manufactured after the effective date can be shown against the new governing set.

If step 2 is a manual email (“who uses this SOP?”), scale will break you.

Shared libraries: governance rules

Shared documents need stricter rules than product-local ones:

• Named library owner (platform quality or central documentation)
• Change notification to all consuming product quality leads
• Blackout windows when multiple products are in audit or launch freezes
• Ban on “save as” local forks without a new document number
• Periodic link integrity checks (broken links, obsolete children still marked effective)

Demo questions teams should use with vendors

• If I change a shared design output, which DMR documents and products are flagged?
• Can I open a product and list every governing document with revision and link type?
• How do you separate DHF evidence from DMR manufacturing specs without casual file duplication?
• Can I export a technical file index for a notified body pack with current effective revisions only?
• What happens to in-process lots when a DMR document becomes effective mid-campaign?
• How are permissions set so product A owners cannot silently edit product B’s specific specs?

Migration from folder chaos

Typical sequence:

1. Inventory top products and critical shared SOPs first—not the entire historical drive.
2. Create product objects and document objects for the critical set.
3. Link with types (DMR section, shared process, labeling).
4. Freeze new “save as” behavior via procedure and permissions.
5. Expand to full catalog after the first inspection pack export succeeds.
6. Retire parallel unofficial trees with read-only archive labels.

Do not wait for perfect metadata on every legacy file before linking the documents you use every week.

Common audit findings this structure prevents

• Cannot show which labeling revision shipped with which product configuration
• Shared process validation referenced by three products at three different revisions with no impact analysis
• Technical file PDF binder out of date relative to eQMS effective list
• Change order closed without updating all inheriting products
• Training completed on a document number that is not the DMR-effective revision

FAQ

Is a folder tree enough for a DMR?

Folders help humans browse. They do not prove relationships. Inspectors want the link between change order, revised document, and product—not a path string that anyone can reorganize.

Do IVDR technical files replace the DMR?

No. They serve related but different purposes. Structure your eQMS so EU technical documentation packs and FDA-oriented DMR views can share controlled sources without contradictory revisions.

Should every drawing live in both DHF and DMR?

Not as duplicate files. Link the controlled drawing with appropriate roles. If manufacturing needs a production issue with different stamps or redactions, create a controlled production issue with a traceable relationship to the design output.

How granular should product objects be?

Granular enough that labeling, UDI, and manufacturing differences are not forced into one overloaded record—and coarse enough that you are not maintaining thousands of near-identical clones. Many teams use device family plus configuration where regulations and manufacturing allow.

Can lot traceability use the same product links?

Yes. Product and document links are the backbone; lot records hang quality events and DHRs off the same product identity. See the lot traceability article linked above for batch-level detail.