DHF, DMR, DHR, and EU Technical Documentation Structure for Inspections, Audits, and Submissions

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.

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 for 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

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”,