Regulatory Open Forum

 View Only
  • 1.  Device History Records (DHR)

    Posted 08-Mar-2024 21:08
    My company currently maintains our Device History Records (DHR) on Salesforce by having a product (asset) page and attaching all the documentation needed in a DHR in a single PDF; however my company is moving to NetSuite for a new ERP system, and will be moving away from Salesforce. I’ve always been under the impression that a DHR was supposed to be one document that includes all the documentation at the time of production/manufacturing, but I’ve been told that is not the case as long as the documents are in a validated system. Could someone advise if it is okay for the documents for a DHR be multiple files, in several different locations in a validated system or should the multiple files be put together in one document? Or maybe provide some guidance on how to maintain a DHR when using NetSuite?

    Thank you in advance!

    ---------------------------------
    Nicole Thibodeau
    Regulatory Affairs Specialist II
    Hamilton Thorne Inc.
    Beverly MA
    United States
    ---------------------------------


  • 2.  RE: Device History Records (DHR)

    Posted 09-Mar-2024 13:16
    Edited by Kevin Randall 09-Mar-2024 13:34

    Hey Nicole,

    Great questions! Your variegated scenario has several regulatory aspects that need to be addressed and synchronized.  In a nutshell, the DHR may consist of multiple documents and thus doesn't need to be formatted as a single document. And yes, it is possible to use NetSuite to support the generation and keeping of the DHR.  Here is some supporting background:

    • The DHR may be generated and kept as multiple files/documents clerically speaking. In other words, there is no requirement that the DHR be put together in one single document unless your SOP requires such consolidation. Yet the DHR for each device unit or batch is a single regulatory entity.  For example, when referring to the various acceptance records making up the DHR from various separate stages of the product realization process, FDA's 21 CFR 820.80(e) reminds us that these records [plural] shall be maintained as part of the DHR [singular].  As another example, FDA has stated in guidance that the device history records [plural] are all the records [plural] for the production history of a finished device [singular] [emphasis added].  Likewise, FDA has in guidance stated that the DHR consists of the records [plural] for a specific manufactured device [singular], device lot or batch. In a classic FDA guidance now withdrawn but still useful, FDA reminded us that product evaluation is performed to show with documented evidence that a component, in-process unit, or finished device was manufactured according to the device master record (DMR) and meets all of the acceptance criteria/acceptance specifications in the DMR, thus fundamentally showing that the DHR consists of documents from various separate stages of the realization process prescribed by the DMR.

    • The flexibility we have for the clerical format of the DHR (e.g., one single document vs. a compilation of multiple documents) is not directly governed by whether the format or the system is validated.  While true that, whatever approach is taken, it does need to be appropriately qualified and where applicable (e.g., with respect to automated DHRs like NetSuite DHRs), be validated, this qualification/validation requirement isn't the primary determinant of our intrinsic regulatory permission for having our DHRs in whatever format works for our organization.  Instead, the driving force is FDA's paramount fundamental for flexibility in the quality system documentation.  Specifically, when promulgating its current QS Regulation, FDA clarified that it wrote the regulation with flexibility to allow manufacturers to design a quality system that is appropriate for their devices and operations and that is not overly burdensome, giving us the flexibility to determine the controls that are necessary commensurate with risk, and leaving it to us to describe [via corresponding standard operating procedures (SOPs) established by us] the types and degree of controls and how those controls were decided upon.

    • This same fundamental QMS documentation flexibility is built into ISO 13485 even though its DHR analog (clause 7.5.1 final paragraph) speaks in more singular terms.  I rely on ISO 13485's fundamental overarching flexibility clause to give me the operating flexibility I need with respect to DHR format. Thus, I maintain the same flexible approach under an ISO 13485 QMS, and therefore in an MDSAP QMS, and also under FDA's new QMSR (which incorporates ISO 13485 by reference) that will become mandatory in February 2026.

    • Your maintenance of the DHR and corresponding software validation (and other qualification) requirements when using NetSuite will be based on precisely how you're using NetSuite for your DHR. For example, if you are using NetSuite's Advanced Manufacturing module with adaptations/modifications/customizations vs. without such alterations vs. using a different NetSuite module(s), then these specifics will have a defining impact on your required compliance strategy and tactics. My software validation team would need to see more details about your particular NetSuite desires, plan, and objectives to give definitive direction on those deep waters.



    ------------------------------
    Kevin Randall, ASQ CQA, RAC (Europe, U.S., Canada)
    Principal Consultant
    Ridgway, CO
    United States
    © Copyright by ComplianceAcuity, Inc. All rights reserved.
    ------------------------------



  • 3.  RE: Device History Records (DHR)

    Posted 09-Mar-2024 13:32

    Just made a few clarification edits; be sure to read the latest.



    ------------------------------
    Kevin Randall, ASQ CQA, RAC (Europe, U.S., Canada)
    Principal Consultant
    Ridgway, CO
    United States
    © Copyright by ComplianceAcuity, Inc. All rights reserved.
    ------------------------------