DEVICE
DHF, DMR, DHR, and EU Technical Documentation / File
John E. Lincoln, Principal Consultant, J. E. Lincoln and
Associates LLC
December 01, 2025
This is an update / expansion to a post on the same subject published April 27, 2016 (below).
Caveat. There are many ways to meet the requirements
of the Design History File (820.30), or the Design and Development File (ISO
13485, 7.3); the Device Master Record (DMR, the device “recipe”, 820.181);
and the Device History Record (DHR, the device’s lot record, 820.184),
required by the Device CGMPs as well as comparable documentation and Technical
Documentation required by the EU and other countries other than the USA .
The following is one field tested approach, vetted over many years by
various regulatory agencies and Notified Bodies (in inspections / audits,
submissions, responses / remediations).
This brief discussion covers the general basic device
documentation for regulatory, quality assurance and production requirements
worldwide. Usually only the terminology changes.
In addition to starting a new DHF for a new device, a
requirement, many companies start a new DHF for major changes to their
existing devices. If minor changes they handle under the CGMPs (Change
Control, 820.40(b)). Moderate changes and similar could also be handled
by an addendum to the existing DHF. Of course the DHF can be open for the life
of the device (which I view as a change control nightmare); I recommend the DHF
be closed at Design Transfer, when all final versions of documentation are
approved and sent to their appropriate areas in the company, ready for device
production.
As with most of the points discussed herein, there are more
than one correct approach.
Generally I recommend to my clients if they ask, that the
DHF be used for newly developed devices or major changes to an existing device
(with each new major change an addendum to the original DHF, or a new,
cross-referenced DHF), which require some type of control of a series of
development changes per 820.30. For a minor / simple change, I recommend
change control under the CGMPs (820.40(b)), which at most companies is under a
Change Request / Change Order (the CR when approved, can become the CO).
To it are attached the verification / test information / references,
e.g., test report number / Lab Book Project number, etc., to justify the
change, or in very simple changes, the actual data on the CR / CO. The CO
needs to have a block referencing a check doing the analysis (of the change itself, and of all the changes done since the last FDA submission) for the need to file a new 510(k) per two
FDA Guidance Documents on changes to a device requiring a new 510(k) (replacing
the old Memorandum K97-1), and also tied to some kind of list / log of changes
for a cumulative change review as well per those same Guidances. All this
is filed in Document Control, usually under QA (as would a closed out DHF, in
many companies). Of course this requires that document changes be defined
in such a way in an SOP to allow device changes (which are usually driven by a
document change anyway, e.g., drawing change, specification change,
etc.).
When there is fielded software (firmware or software) and a revised version is
created under change control, how does this affect the DMR and/or DHR?
Any change to a product, hardware or software, requires a change to the DMR
(under change control, 820.40) for that product). Often the DMR includes a
DHR template / blank (may be a "traveler" template / blank, or
in addition to a traveler), which would also be changed, or would at least
drive a change to the DHR anyway, reflecting the new Revision / Release numbers
of the software so changed (unless the Revision / Release Number entry is a
fill-in blank).
“Travelers” often address and document actual equipment
settings (as opposed to ranges established by validation and outlined in SOPs,
etc.), line clearance verification / sign-off, label count reconciliations,
filled in BOMs (with lot numbers and quantity), inspection results and
sign-offs by QC, non-conformance resolutions and approvals, deviations /
completion / verification and approval, et al, and a final DHR / lot review and
sign-off by QA.
Consider the situation where a company has updated
software that is then sent out to their customers. In such a case, one
possibility is that both (DMR and DHR) are updated (the DMR drives DHR
content), assuming that the software is changed across the board. If
you're changing software for one customer at a time, then you're furnishing
custom software, each program unique to each customer, and your entire CGMP
system would have to be designed under that system. My discussion is focused
on the assumption that the software is a revision / release, where all
customers for that particular software get the same updates, new changes / revisions
/ releases. Of course, all changes (custom or generic) are done under
change control.
To clarify the role of the DHF, DMR and DHR: The DHF shows the
development of the device proving that the eight* other requirements of 820.30
Design Control or of ISO 13485 7.3, Design and Development Planning, have been
met in its development from the "start" date (usually when serious
money is committed by the company to commercialize a previous R&D research
project).
The DMR is one result or design output from the DHF
documented activities. The DMR (820.81) is the device description, or
"recipe": basically a list of all controlled records ("living
documents") that define the device, to allow it's replication as defined
in the FDA clearance (510(k)) or approval (PMA) documents. The DMR might
list device drawings, assembly work instructions / SOPs, test instructions /
SOPs, BOM blanks (part numbers and part / component descriptions with blanks
for quantity and lot numbers), blank travelers (which may list applicable
validated / verified equipment settings with blanks to be filled in with the
actual settings, operator or QC signatures and dates, and similar), reference
other device specific SOPs, labels, Instructions for Use. Some DMRs may
list the generic SOPs that also apply to that device (and other devices), but
don't have to. It would include the DHR template if additional to the above,
e.g., traveler.
Additional on the DMR (the device "recipe"): Although riskier, you
could structure the DMR to list the device controlling documents without
their current revision nos. / dates (e.g., list Drawing No. 0123,
"current revision"; or SOP XYZ, "current revision” ). Then
the DMR would not always have to be updated when the device or software has
minor changes, or even some major changes. However, the actual DHR template
would have to be updated to reflect using the most current documents / settings
/ parts , et al, during manufacture of a lot. All such changes would be
under Change Control per 820.40.
The DHR (820.184) is the lot build history for one
production lot; a record of how one lot / batch (lot number), or one serial
number was built, quantities, RM lot numbers, dates, personnel involved where
appropriate, proving that lot followed the "recipe" outlined in the
DMR. It would have the filled in / signed BOM, a filled / signed traveler
(which could be a "DHR template blank"), samples of labels / IFUs
included, sterile lot info (if sterilized), etc., showing / proving conformance
to the DMR developed by the manufacturing process recorded in the DHF. Prior to
release of that lot to the field, it would be reviewed and signed by QA, who
would assure its accuracy and completeness of data and required enclosed
documents.
In essence: -- the DHF > DMR > DHRs.
See also "Definitions", 820.3. These terms will change with the
new US QMSR (new 21 CFR 820, which includes ISO 13485 and ISO 9000, Clause 3,
by reference) replacing the old US QSR (old 21 CFR 820).
Technical Documentation / Files: This is a EU MDR term used to describe the
documentation used to prove compliance to the EU MDR, especially the old MDD
“Essential Requirements”, now referred to in the new MDR as the “General Safety
and Performance Requirements”, and the rest of the MDR and any applicable
standards or other regulatory requirements for that family of devices. It’s closest comparison would be the US FDA’s
510(k), DeNovo, or PMA. These are US FDA marketing authorizations, showing how the device meets its regulatory
requirements in their respective countries and the vehicle to seek government
regulatory clearance or approval for sale in those counties. Both are reviewed by either the US FDA, or a Certified
Notified Body (outside the US), prior to receiving permission to market in
their respective countries. The
applicable manufacturing and quality / regulatory QMS is determined by the
country(ies) where the device is to be marketed (no matter where manufactured).
The ultimate approach taken by a company must be defined by
an SOP(s) and then followed!
*The 8 Design Control requirements (same for the CGMPs and ISO; I also use these as the subheadings in a DHF):
1. Design and Development Planning (e.g., a
Gantt Chart);
2. Design Input;
3. Design Output;
4. Design Review;
5. Design Verification;
6. Design Validation;
7. Design Transfer;
8. Design Changes;
The remaining 2 elements of Design Control (total of 10):
9. Design Control SOP;
10. Design History File (DHF).
Note: The above is available from JEL as a 90 minute (or longer) webinar for your company, or if a group desires it. Inquire about availability and costs. Thanks. - John
- jel@jelincoln.com, 12/01/2025
