RELATIONSHIPS:  DEVICE  DHF, DMR, DHR

Caveat.  There are many ways to meet the requirements of the Design History File (820.30); the Device Master Record (DMR, 820.1811); and the Device History Record (DHR, 820.184) required by the Device CGMPs.  The following is one field tested approach.
Many  companies start a new DHF for major changes to their device.  If minor changes they handle under the CGMPs (Change Control, 820.40(b)).  
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 major changes (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  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 info'n / references, e.g., test report number / Lab Book Project no. 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 Memorandum K97-1, and also tied to some kind of list / log of changes for a cumulative change review as well per that same K97-1.  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 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 nos. of the software so changed (unless the Rev / Release No. entry is a fill-in blank). 
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 rev / rel where all customers for that particular software get the updates, new revs / releases. 
  
To clarify the role of the DHF, DMR and DHR:  The DHF shows the development of the device proving that the 8 other requirements of 820.30 Design Control have been met in its development from the "start" date.  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 nos, dates, personnel involved where appropriate, proving that 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.
The ultimate approach taken by a company must be defined by an SOP(s) and then followed!
-- John E. Lincoln, jelincoln.com

Note:  FDA's K-97 has been replaced by two FDA Guidance Documents  on changes to Devices / Software Requiring a new 510(k). JEL

Further updates: 06/20/2022 - JEL

PART 11 and ANNEX 11

Some arguments on blogs and forums state that the EU's Annex 11 goes beyond the US FDA's 21 CFR Part 11.  They cite four key areas of differences:

01. Supplier / service provider audits;

02.  IT infrastructure qualification;

03.  Product Risk Management; and

04.  System operations and storage integrity.

A key point to keep in mind re. Part 11, is that it is not to be considered a "stand alone" requirement.  It is one part of the requirements imposed upon a company regulated by the CGMPs, e.g., 21 CFR 111 for dietary supplements, 21 CFR 211 for pharma, 21 CFR 820 for devices, 21 CFR 4 for combo products and so on.  And only where applicable (as mentioned below). 

Viewing Part 11 as such (part of the the overall CGMP requirements), the CGMPs then supply the so called "missing requirements" for supplier audits, the company's infrastructure and its qualification, incorporation of product risk management considerations into product development and subsequent activities, integrity of operations and data storage, throughout process and product life cycle from development to decommissioning.   

Failure to consider Part 11 as only part of the "bigger compliance picture" will guarantee FDA Form 483 observations during a CGMP compliance audit of a company.  

It must be noted, however, that Part 11 compliance is reviewed as part of such audits only if electronic records and/or electronic signatures are used by the company to fulfill some element of CGMP compliance documentation, record keeping or approvals, which involve e-records / e-sigs, in lieu of paper records / documents and/or manual signatures to fulfill such CGMP actions / documentation requirements.  

In reality, both systems (Part 11 or Annex 11) should not be considered as "stand alone" systems requirements, but as one small part of the entire QMS (quality management system) / regulatory environment.   Doing so makes understanding the requirements of Part 11 / Annex 11 easier, and compliance (and its resulting business benefits) complete.

-- John E. Lincoln, jelincoln.com

DQs

A reader asked a question re:  "Design Qualification", as in DQ, IQ, OQ, PQ.  "This is a term I am not
familiar with. I have not seen it in 21 CFR and could not find any references on FDA.Gov. I also do not remember seeing it in 13485. I would like more clarification and examples, also to understand where this requirement comes from."

To answer the question: Go to www.fda.gov and search IQ OQ PQ.  You will not find DQ or Design Qualification.  However, you will find guidance documents on software V&V and process V&V that discuss the terms, define them, and state the FDA's requirements for their use.  And IQ, OQ, PQ presuppose proper requirements against which the IO, OQ, and PQ test cases would be developed to prove the Requirements have been proven to exist and function as expected.

If you enter "DQ validation" or "Design Qualification" into Google, you will find definitions similar to the one I give below.

The "c" in CGMP means that 21 CFR XXX is the rock bottom minimum they require, but that they expect companies to use practices in their industry that are "c" or "current". IQ, OQ, and PQ have been around for decades. DQ is less frequently used, but it is still used somewhat frequently in FDA regulated industries.  DQ generally means verifying that user / functional requirements are valid and complete. it is an additional step after development of the Requirements, to ensure no valid requirement is missing, including applicable standards and/or guidance documents.  While this is often done "intuitively", such a DQ action should be documented, since an auditor or other reviewer would expect that Requirements are somehow qualified or verified for appropriateness / completeness.

If you choose to follow ASTM E2500, then you won't necessarily use these terms, but are still expected to perform what they stand for. All US FDA investigators / notified-body auditors (ISO 13485 ...) expect the same. 

In order to properly validate equipment, software, processes, you would have to do them (Rqmts. / DQ, IQ, OQ, PQs, or identical equivalents / activities). The principles are not optional, i.e., you have to prove you installed X correctly / per spec (IQ against DQ / Rqmts Specs), you set it up and optimized parameters (e.g., DOE) for X correctly (OQ against DQ/Rqmts Specs), and you proved that X ran repeatedly, over extended periods of time, with varying conditions / inputs ("worst case" conditions / inputs), robustly (PQs against DQ/Rqmts Specs, 3 or more runs).  

So, while the acronyms can vary, the activities they represent cannot. 

--  John E. Lincoln, jelincoln.com