How to Write a Design History File (DHF) When Your CEM Is Involved in Development

By Will Leverett | Connect on LinkedIn

If you're developing a medical device that includes electronics, you need a Design History File (DHF). It's a regulatory requirement under 21 CFR Part 820 (FDA) and ISO 13485, and auditors will ask to see it.

The DHF is the complete record of your device's design process: what you intended to build, how you verified it works, how you validated it meets user needs, and how you controlled changes throughout development.

When your contract electronics manufacturer is involved in the design and development process — not just building to your finished specification — the DHF becomes more complex. You need to capture their contribution, document their design inputs and outputs, and demonstrate that the design transfer to manufacturing was controlled and verified.

What a Design History File Actually Is

The DHF is the documented evidence that you followed a controlled design process. It proves that:

1. You defined what the device needed to do (design inputs)
2. You designed something that meets those requirements (design outputs)
3. You verified the design works as intended (verification)
4. You validated that it meets user needs in the intended use environment (validation)
5. You reviewed the design at planned intervals (design reviews)
6. You transferred the design to manufacturing under controlled conditions (design transfer)
7. You managed design changes systematically (design changes and configuration management)

For a medical device with electronics, the DHF will typically include:

• Requirements specifications (system, hardware, software, risk management)
• Design documentation (schematics, PCB layouts, BOMs, firmware source code)
• Verification and validation test reports
• Risk management files (ISO 14971 outputs: risk analysis, risk control measures, residual risk evaluation)
• Design review meeting minutes
• Design transfer documentation (manufacturing specifications, test procedures, work instructions)
• Design change records (ECOs, deviation reports, change justifications)

When a CEM is involved in development, their work needs to be integrated into this structure.

When Your CEM's Work Becomes Part of the DHF

Not every interaction with a CEM triggers DHF documentation. If you hand a finished design to a manufacturer and they build it to your specification, their work is part of the Device Master Record (DMR) and Device History Record (DHR) — the manufacturing documentation — not the design history.

But if your CEM is involved in any of these activities, their output needs to be captured in the DHF:

• Design for Manufacture (DFM) review that results in design changes — if the CEM identifies a footprint issue, component obsolescence, or thermal management problem that requires a design revision, that's a design change and needs to be documented
• Component selection or qualification — if the CEM recommends alternative components, qualifies suppliers, or conducts environmental testing on parts, that's design input/output activity
• PCB layout or routing decisions — if the CEM is doing the PCB layout (not just fabricating from your Gerbers), that's design work
• Test fixture or test procedure development — if the CEM develops functional test procedures or builds test fixtures as part of the design process, those are design outputs
• Process validation for manufacturing — if the CEM is validating assembly processes (e.g., reflow profiles, conformal coating application), that may be part of design transfer or process validation, both of which feed the DHF

If the CEM is making design decisions or producing design documentation, it belongs in the DHF.

Section 1: Defining Design Inputs When the CEM Is Involved

Design inputs are the requirements your device must meet. When a CEM is involved in development, they may contribute to defining those requirements — particularly around manufacturability, testability, and component availability.

What should be documented:

• CEM input on design constraints — if the CEM highlights manufacturing limitations (e.g., "we can't reliably place components smaller than 0402," or "lead times on this microcontroller are 52 weeks"), that input should be captured as a design constraint and referenced in your requirements specification
• Testability requirements — if the CEM identifies test points, access requirements, or functional test coverage needed to verify the design at production scale, those become design inputs
• Component availability and lifecycle — if the CEM provides data on component end-of-life risk or recommends long-lifecycle alternatives, document this as part of risk management (it affects availability risk under ISO 14971)

How to document it:

Create a Design Input Review Log or Stakeholder Input Register that captures CEM recommendations, the date received, the design requirement affected, and whether the input was accepted or rejected (with justification). This shows the auditor that CEM input was considered systematically, not ad hoc.

Example entry:

• Input Source: ABL Circuits (CEM)
• Date: 2024-03-15
• Input: Recommended alternative voltage regulator (TI TPS62912) due to 18-month lead time on originally specified part
• Affected Requirement: REQ-HW-015 (Power supply stability)
• Action Taken: Accepted. Component substituted and verified equivalent performance in benchtop test.
• DHF Reference: Design Change Notice DCN-024

Section 2: Design Outputs — Capturing CEM-Generated Documentation

Design outputs are the documented results of the design process: the schematics, layouts, BOMs, drawings, and specifications that define what gets built.

When the CEM produces any of these, they need to be controlled as design outputs and included in the DHF.

What should be documented:

• PCB layouts (Gerber files, ODB++) — if the CEM is doing the layout, the final Gerber files are design outputs and must be version-controlled and reviewed
• Assembly drawings — if the CEM produces assembly drawings showing component placement, orientation, and polarity marks, these are design outputs
• Manufacturing work instructions — if the CEM writes process-specific instructions (e.g., conformal coating masking, potting procedures), these are design outputs for the manufacturing process
• Test procedures and test fixtures — if the CEM develops functional test procedures or designs test fixtures, these are design outputs that enable verification and production testing

How to document it:

All CEM-generated design outputs should be reviewed and approved by your design team, version-controlled in your document control system, and traceable to design inputs.

Create a Design Output Review Record that logs when CEM-generated documents were received, who reviewed them, what was checked, and whether they were approved or required revision.

Section 3: Verification and Validation — Documenting CEM Test Activities

Verification proves the design outputs meet the design inputs. Validation proves the device meets user needs in its intended use environment.

If the CEM is conducting verification testing — such as first article inspection, functional testing, or environmental testing — those test results need to be captured in the DHF.

What should be documented:

• First article inspection reports — dimensional checks, component verification, solder joint inspection (IPC-A-610 compliance)
• Functional test reports — if the CEM performs functional testing using agreed test procedures, the test data and pass/fail records are verification evidence
• Environmental stress testing — if the CEM conducts temperature cycling, thermal shock, vibration, or other environmental qualification tests, those results are verification data
• Process capability studies — if the CEM provides data on process yield, defect rates, or statistical process control (SPC) during pilot runs, this supports design verification

How to document it:

Include CEM test reports in your Verification and Validation Plan (V&V Plan) and reference them in the Design Verification Summary Report. Each test should be traceable back to a specific design input or requirement.

If the CEM performs testing under their own quality system, ensure you have documented evidence that:

1. The test procedure was reviewed and approved by your team
2. The test equipment was calibrated and suitable for the measurement
3. The test results were reviewed by your team and accepted as verification evidence

Design Reviews — Including the CEM as a Stakeholder

Design reviews are formal, documented evaluations of the design at planned stages. When a CEM is involved in development, they should participate in relevant design reviews — particularly those covering manufacturability, testability, and design transfer.

When to include the CEM in design reviews:

• Preliminary Design Review (PDR) — if the CEM has input on feasibility, component availability, or manufacturing constraints
• Critical Design Review (CDR) — if the CEM is reviewing final PCB layouts, BOMs, or assembly drawings before design freeze
• Design Transfer Review — always; the CEM needs to confirm they can manufacture to the design as documented

What should be documented:

• Meeting minutes capturing CEM attendees, topics discussed, concerns raised, and action items assigned
• Action item log tracking CEM-raised issues to closure
• Sign-off confirmation from CEM representatives that they have reviewed the design and identified no barriers to manufacturing (or documented any concerns)

If the CEM identifies issues during a design review (e.g., a component is obsolete, a tolerance is too tight), those issues need to be tracked and resolved before the design proceeds to the next stage.

Section 4: Design Reviews — Including the CEM as a Stakeholder

Design reviews are formal, documented evaluations of the design at planned stages. When a CEM is involved in development, they should participate in relevant design reviews — particularly those covering manufacturability, testability, and design transfer.

When to include the CEM in design reviews:

• Preliminary Design Review (PDR) — if the CEM has input on feasibility, component availability, or manufacturing constraints
• Critical Design Review (CDR) — if the CEM is reviewing final PCB layouts, BOMs, or assembly drawings before design freeze
• Design Transfer Review — always; the CEM needs to confirm they can manufacture to the design as documented

What should be documented:

• Meeting minutes capturing CEM attendees, topics discussed, concerns raised, and action items assigned
• Action item log tracking CEM-raised issues to closure
• Sign-off confirmation from CEM representatives that they have reviewed the design and identified no barriers to manufacturing (or documented any concerns)

If the CEM identifies issues during a design review (e.g., a component is obsolete, a tolerance is too tight), those issues need to be tracked and resolved before the design proceeds to the next stage.

Section 5: Design Transfer — The Handoff to Manufacturing

Design transfer is the process of moving a design from development into production. When your CEM is the manufacturer, you need to document that the transfer was controlled and verified.

What should be documented:

• Design transfer plan — defines what needs to be transferred, to whom, and what acceptance criteria must be met
• Manufacturing specifications — all documents the CEM needs to build the device (Gerbers, BOMs, assembly drawings, test procedures, work instructions)
• Design transfer review meeting — formal review confirming the CEM has received all documentation, understands the requirements, and is ready to begin production
• Manufacturing readiness checklist — confirmation that the CEM has verified component availability, tooling readiness, test fixture availability, and process capability
• First production build verification — documented evidence that the first production batch met all design specifications and acceptance criteria

How to document it:

Create a Design Transfer Package that includes:

1. All manufacturing documentation (controlled copies or version references)
2. A Design Transfer Checklist signed by both your team and the CEM confirming readiness
3. First Article Inspection Report from the first production build
4. Design Transfer Acceptance Report confirming the transfer is complete and production can proceed

This package should be reviewed and approved by your design team and filed in the DHF before full-scale production begins.

Section 6: Design Changes — Managing ECOs When the CEM Is Involved

Design changes are inevitable. When a CEM identifies a need for change — or implements a change during manufacturing — it needs to be captured and controlled.

What triggers a design change in the DHF:

• Component substitutions — if a component becomes obsolete or unavailable and the CEM recommends an alternative, that's a design change (even if electrically equivalent)
• DFM-driven design revisions — if the CEM identifies a manufacturability issue that requires a layout change, pad modification, or assembly process adjustment, that's a design change
• Nonconformance and corrective action — if a manufacturing defect is traced back to a design issue (e.g., insufficient solder pad size), the corrective action may require a design change

How to document it:

All design changes should be processed through your Engineering Change Order (ECO) or Design Change Notice (DCN) system, regardless of whether they originate from your team or the CEM.

Each change record should include:

• Change request source (CEM-identified issue, customer feedback, internal review)
• Justification (why the change is necessary)
• Impact assessment (what requirements, tests, or documentation are affected)
• Approval (design team sign-off)
• Verification (confirmation the change was implemented correctly and doesn't introduce new issues)

If the CEM implements the change, include documented evidence (updated Gerbers, revised assembly drawings, updated test procedures) in the DHF.

Common DHF Gaps When Working with a CEM

Based on regulatory audits and notified body reviews, these are the most common gaps we see when medical device companies work with contract manufacturers:

1. CEM-generated documentation is in the Device Master Record (DMR) but not referenced in the DHF
If the CEM produced design outputs (layouts, test procedures), they need to be in the DHF, not just the DMR.

2. Design changes initiated by the CEM are documented in the CEM's system but not in the DHF
Even if the CEM has their own ECO process, you need a corresponding design change record in your DHF that references it.

3. Verification testing performed by the CEM is documented in their test reports but not linked to DHF requirements
Test reports are only verification evidence if they're traceable to design inputs. Your DHF needs a traceability matrix showing which CEM tests verify which requirements.

4. Design reviews include the CEM as an attendee, but their input isn't documented
Meeting minutes should capture what the CEM reviewed, what concerns they raised, and how those concerns were addressed.

5. Design transfer is assumed, not documented
"We sent them the files" is not design transfer. You need documented evidence that the CEM received, reviewed, and accepted the design package, and that the first production build met acceptance criteria.

Maintaining the DHF After Launch

The DHF continues to grow after the device launches. Design changes, process improvements, and component substitutions all require DHF updates.

When working with a CEM, establish a DHF update protocol that defines:

• How often CEM-generated documentation is reviewed and incorporated
• Who is responsible for updating the DHF when the CEM makes changes
• What triggers a DHF update (new test data, design changes, process improvements)

For long-lifecycle medical devices, the DHF may span years and include multiple CEM partners, process changes, and component substitutions. Keeping it current requires ongoing discipline.

Working with a CEM That Understands DHF Requirements

Many contract electronics manufacturers don't work under ISO 13485 or understand medical device design controls. If your CEM has ISO 13485 certification and medical device experience, they'll document their work knowing it feeds into your DHF.

At ABL Circuits, we work with medical device manufacturers on both PCB assembly and full box build assemblies under ISO 13485. We understand that design reviews, design changes, and verification testing conducted during development need to be captured in your DHF, and we document our work with that in mind.

If you're developing a medical device and need a CEM who understands design control requirements, get in touch to discuss your project.

Will Leverett is the director at ABL Circuits, a UK-based contract electronics manufacturer specialising in PCB assembly, box build, and NPI programmes across commercial, defence, medical, and EV sectors. Connect with Will on LinkedIn.