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 

 

 

 

 Check out a new FDA subject website, www.talkfda.com.  It's designed to be interactive and provide a forum to discuss compliance problems, see featured webinar offerings, timely short articles, and similar.  Currently it's a work in progress. No charge to sign-up. - John 10/31/2025

 My response to my recent "Device Changes and the 51(k)" webinar question from an attendee:

Ques:  If you are transferring production from a current CMO to a brand-new internal facility with in-house process, does that require a full new 510k submission?

 

Ans:  Same as before.  Moves of production locations/personnel, changes in production equipment, etc., can generally be addressed by specific-to-the-move (not just routine) validation, showing any changes in equipment, personnel, location, and similar, had no negative effect on the outgoing product, i.e., it still met specification. 

 

This is in line with my comments during the webinar on the FDA's default to your QMS (in this case production validation's strong positive results) negating the need for a new 510(k) - see related discussion on the role of your QMS in negating a need for a new 510(k), in the referenced Guidance Documents. 

 

The key issue is no negative change in "safety and efficacy" of the product. Generally this can still hold true even if you make some major changes to the type of equipment / processes used, all well documented / explained, backed up by any Device Risk Management File (ISO 14971) updates, all under change control of course.

-- jel@jelincoln.com  10/15/2025

Urgent Reminder!

The FDA deadline for the change from Medical Device QSR to the new QMSR is fast approaching -  February 02, 2026!  FDA CGMP Compliance Inspections are currently being conducted to the old QSR/QSIT (old 21 CFR 820) up to February 02, 2026, but after that date will be conducted to the new QMSR - the new 820, Subparts A and B, ISO 13485 in its entirety, and Clause 3 of ISO 9000.

This requires that a company's Quality Manual, QMS SOPs, and training be updated to the new QMSR and be completed with all QMS systems ready to go live on February 02, 2026.

We are rewriting QMs and SOPs for clients, to conform to these new requirements and would be happy to assist your company in doing so.

- JEL, jel@jelincoln.com 

In it's Preamble to the new 21 CFR 820, the FDA has stated that the switch should cause no discernable change in your actual QMS, but primarily in your SOP references (to the ISO 13485, rather than to the old 820) and in terminology (per ISO 9000, not 9001, Clause 3).  If you determine that you think a change is required in your QMS as to how you perform a task, revisit your thinking! - JEL 11/30/2025  

Questions received from a recent seminar on Post-Market Surveillance - MDR's

QUES: In "Become aware" - it says "including any trend analysis." This suggests that non-public information is included in all this. Please speak to any difference between public and company-private (secret) information?

ANS:  The FDA has not made a distinction between public and private information in a MDR investigation and response.  And they repeatedly require trending of CAPA / Complaint data in their 483’s (I have also seen this personally) and have sometimes done it themselves (the trending) when such data is missing.  You do have the right to indicate what information you supply that you desire to be treated as “confidential” and/or redacted from FOI responses from them (21 CFR 803.9(b)(1)).  They may or may not agree/comply. 

QUES: Manufacturer Reporting Requirements –

A reportable death, serious injury, or malfunction is based on information a manufacturer receives or otherwise becomes aware of, from any source.

• Here and throughout subsequently, it appears that this includes company-internal information. Okay. But, what does that mean in practice? Of course, it does not mean everything, such as lunch-cooler conversations. Is there some easy definitions, such as information that is subject to audit? Or, something else?

ANS:  If you become aware of any instance of your device causing a death or serious injury, or could cause such, from any source, you are required to report it – the only qualifier is the following on “reasonably suggests” (which could even apply to your lunch-cooler example, depending…).  21 CFR 803.03 “Become aware means that an employee of the entity required to report has acquired information that reasonably suggests a reportable adverse event has occurred.” You start an investigation, first to determine if it is true, and report the findings up to the time you report initially to the FDA at/within the timeline required, with the information you have at the time.  If incomplete, you then continue your investigation until you have gone as far as you can in good faith efforts, reporting what is verifiable to the FDA as supplements / updates to the original MDR.  

In cases where you determine that the problem is not MDR-reportable, you should still record it as a complaint, and include the investigation data leading to the conclusion not to report, retained in your complaint file (such as your example of serious event lunch-cooler talk found to be incorrect).  

QUES:  The “Manufacturer” - Manufactures components or accessories that are medical devices.

• Consider product produced inside and outside US either by true manufacturer or under license by another.

Consider illicit versions (copies) produced not by or under license of the true manufacturer.

Produced not in US, used not in US.  I.e., MDR reporting:

• Is FDA involved?

 ANS:  The FDA is involved in devices produced in the US, no matter where sold, if the conditions of an MDR submission are met. Same for product produced outside the US but marketed and/or used (e.g., IDEs …) in the US.

Counterfeit devices in complaints that were presented to you as yours by the user, initially as your product (and third party reprocessed SUDs where you are the OEM and not the reprocessor but thought to be the one responsible due to old labeling…) are reportable to the FDA by you, if you're the one who becomes aware of the problem, and if they meet the requirements of MDR submission, with the subsequent findings (and follow-on MDR update / submission to the FDA) that the product is not yours with justification / facts proving so.

QUES: “Become aware” - 1

You said: "You can't blow this stuff off."

• No question, but this was a key takeaway that prompted my questions.

 “Become aware” – 2

• You talked about "delay."
• The following question comes up often for us. Can you answer or provide a resource to answer this question:

Is there a difference between a Delayed Result < 24 hours vs. Delayed Result >= 24 hours?

This question is in the context of a lab instrument giving a result to the doctor: bacterial identification, antimicrobial susceptibility, blood work, etc.

Where the typical answer is on the order of < 24 hours response time.

 ANS:  I don’t remember saying “You can’t blow this stuff off”, but I agree with the thought.

I did not discuss anything on any “delayed result<24 hours vs. delayed result + or > 24 hours”, and am not sure of the question.  If this is a manufacturer-defined malfunction, which is a reportable category for the MDR if that was a requirement for the product and it didn’t meet it - it malfunctioned. Your MDR SOP should define how to handle, but the FDA doesn’t want splitting hairs on timing of problems, etc.  If a problem occurred at a certain time interval, it’s possible / assumed it could occur sooner or later the next time, absent test data to the contrary. However this is a specific product question which I cannot address in this general context further.

The only "delay I would have talked about is a "become aware" delay, i.e., the information may have related to an event that occurred much earlier, but was delayed in getting to you / the company.  You are obligated to send the MDR once you become aware of it, even it it actually occurred considerably earlier - days, weeks, months (I haven't seen a time limit, as long as the version of the device causing the problem is still on the marketplace - there's still a risk posed to the potential users, hence the need for the MDR).   

QUES:  “Caused or contributed” to death / serious injury

• If someone using the device makes a mistake? This is easily understood as: reportable.
• What about off-label use? You said: reportable. Okay.
• What about an actor that is purposely doing it wrong? I understand this to be same as off-label use: reportable.
• What about a bad actor? That is, someone purposefully using the device to cause harm?

ANS:  All the above are reportable, including the last bullet point.  Your findings of such (such as bad actor / willful misuse) would then be included in your MDR to the FDA.  Most risk and use / human factors requirements include user error as a consideration, but purposeful misuse is not (in use / risk analysis, unless done by a doctor who can use a device in any way they deem necessary to benefit a patient, usually with the patient’s agreement after informed of the benefit / risk – ISO 14971 …), as I mention in other presentations on use / human factors engineering and/or device risk management.  So you would still report a “a bad actor” in your findings and if you have solid proof, you would have no way to prevent that (as you have no way to prevent a doctor from their “off label” use of the same product), which would become part of your findings (cite as part of your rationale the references cited above).  

 QUES:  The most famous case at our company internally: A device analyzing blood running in a hospital lab would beep when it needed attention. There was an instance where the device was beeping at night, which bothered a person somewhat like a janitor, someone not in the lab hierarchy. They knew how to and did  turn off the beeping. When the morning shift came in, the machine was not beeping so they missed doing what they need to with it, and did not report a result to the doctor as they would have if they had known to address it. A death occurred.

• Was this a mistake? No. Was this an actor-purposely-wrong? Probably. What if this had been a bad actor, purposely causing harm?
• Perhaps you have other examples (or a book or articles I could read) about this topic? 

ANS:  Sorry, I don’t have a reference for such a book.  However, ICH 62366-1 on Usability Engineering and ISO 14971 on Device Risk Management discuss briefly purposeful misuse.

However, since a death could (and did) occur, the MDR requires that it be reported.  The findings reported to the FDA would be as indicated above.  The organization having that incident and their legal department, et al, and senior management, would have to determine corrective actions to be taken internally regarding controls and behavior of company personnel to prevent such from recurring – e.g., both the janitor who made an unauthorized change to the device, AND the morning shift who should have verified it’s operation first thing.  Your IFU’s may have to address the fact that such events could compromise results.

Be aware that any change to your labeling for your products’ field problems may require a new marketing submission, e.g., 510(k), especially a caution or warning.  See the two guidance documents on Device Changes and the 510(k):

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/deciding-when-submit-510k-change-existing-device

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/deciding-when-submit-510k-software-change-existing-device

 - jel@jelincoln.com

Added "i.e., ..." above, Ques 3, 11/30/2025 - JEL

 Can other companies use one company's 510(k) to market their own device?

For a question from one of my clients

Ans:  The company that owns the 510(k) is the only one to use that 510(k) to market the device in the US.  It is also the only one who can make regulatory decisions about that device and its 510(k) content, e.g., device changes and when its necessary to submit a new 510(k).  The submitting company (unless the 510(k) was sold along with the device to another company), is the one solely responsible for its content and "updates" / submissions to the FDA, and the FDA checks for this during each inspection; if the last inspection had no problems with the product / its 510(k), it's safe to say that the device / 510(k) has no problems (unless new data received by the company, e.g., complaints, test data, or similar) say otherwise.  

Is another company (other than distributers) trying to use the device owner company's 510(k) to sell products to other companies? If so, that would not be permissible.  Each company ordering that type of device for themselves for resale under their own name has to have their own 510(k), or, in the case of a procedure tray/kit, have a 510(k)  themselves for the kit, and per the 510(k) for kits from the FDA, maintain a file for every class 2 device in the kit, each having it's own 510(k) or one covered by the kit's 510(k),  providing the device hasn't been modified, retains its original labeling / primary packaging;  Sterilization / re-sterilization may be allowed if test data shows no device degradation and maintains its proper function and sterility (part of the data submitted to the FDA for review of the kit 510(k)).  

Further, companies manufacturing devices for sale to other companies cannot use someone else's 510(k) for their customer's use (they or their customer has to have at least one applicable 510(k) for that device in order to market it).

- jel@jelincoln.com

Note:  The above is pertaining to one company using another company's 510(k) to sell the first company's product (which doesn't have a 510(k); it not discussing one company selling another company's device which has it's own 510(k), e.g., a kit packer / procedure tray manufacturer. - JEL 07/02/25

When to Use Device Risk Management and/or Human Factors in Device Design

IEC 62366-1 outlines a process (9 stages) to follow to perform a Use Engineering / Human Factors analysis.  The specifics for the actual UE/HF tests (formative / verification or summative / validation) is found in other standards and guidances.  UE/HF is only needed where the user interface presents challenges of use[r] error and/or the device is specifically listed by the US FDA as needing such. 

In other cases it does not have to be used, e.g., where the use(r) interface (device shape, weight, color, knob usage, graphic output, alarm output, keyboard input, on-unit labeling, etc.), is intuitive, familiar, not prone to excessive use[r] error, et al.  

On the other hand, device Risk Analysis / Management per ISO 14971 (patient / user / environment  safety (and regulatory compliance), is always required, for both new product development as well as in significant changes - this will be more emphasized with the new device QMSR (new 21 CFR 820), but it is a current expectation of the FDA.

Both these tools, when used, are to be used to feed into any new designs or design changes, to use the design process to reduce use risk or use error or both. 

Possible UE/HF File Format (IEC 62366-1):  1) Intro, device description, approvals, discussion of device under evaluation, executive summary of findings, and similar background; 2) A section on each of the 9 stages in IEC 62366-1 (discuss specific tests used under Stage 5 -  5.7.1, 5.7.2 and 5.7.3 - of IEC 62366-1 in the UE/HF File); 3) Conclusions (mitigations...).

Possible Device Risk Management File (ISO 14971, or ICH Q9):  Intro, as above, assumptions, risk management team, preferably including a clinician familiar with the device's use; 2) Hazard Analysis; 3) Expand Hazards with a Fault Tree Analysis; 4) Expand Hazards with three FMEAs / FMECAs:  I) Design FME[C]A, II) Process FME[C]A, and III) Use  FME[C]; 5)Review/Report - Residual Risks, Benefit / Risk analysis / statement.   Use FTA and FME[C]As with the addition of a "Normal Usage Causing Problems" Matrix.  This format has been reviewed in detail by the FDA in 2003 and extensively used and subject to FDA and Notified Body inspections and remediation projects since then with no negative comments / findings / 483s. 

-- John E. Lincoln

Guidance on when to apply Use Engineering / Human Factors (not always required):

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices

Risk management, ISO 14971 for devices, is always required for new or significant changes to a device.

- JEL, 11/30/2025