Why doesn't the BOM go in the DHF?

[ga2qa23]

Hello all, I'm a newbie and I'm having incredible difficulty understanding the difference between the DHF, DMR, and where the BOM (Bill of Materials) is supposed to fit into both of them. I would greatly appreciate some real-life examples, because all these vague regulatory definitions are of zero help when trying to do it in the real world.

I have an electrical medical device with a circuit board inside and its own software. It's a simple Class 2 device on the low-risk side. We coded the software ourselves. We're not building anything in-house. I'm purchasing everything (custom-made circuit board, hardware, a plastic shell, etc.) from third-party contract manufacturers, and it'll be send to a separate vendor for final assembly, packaging, and sterilization.

I read through the FDA regulations, webinars, and guidances on design controls. It says that the "Design Outputs" of the Design History File (DHF) are the assembly drawings, component drawings, and source code.

In this FDA webinar: fda DOT gov/media/89241/download
FDA states the following:

• Design Outputs are included in premarket submissions as Device Specifications.
• The finished design output is the basis for the Device Master Record (DMR).
• The total finished design output consists of the device, its packaging, labeling, and the Device Master Record (DMR).

Then in this separate FDA webinar: fda DOT gov/media/118202/download
FDA states that the DMR includes "Device Specifications" which include the following:

• Bill of Materials
• Drawings and schematics
• List of Ingredients
• Component Specifications
• Material Composition
• Formulations
• Assemblies
• Software specifications

OK so what does this all actually mean in the real world?

A Bill of Materials (BOM) is a list of all the product's parts, right? In my DHF, I already have a traceability matrix that is listing all my part drawings as "Design Outputs" against my "Design Inputs" requirements. The way my project is working is that we'll create the part drawings ourselves (hardware, circuit boards, plastic shell, etc.), and send the part drawing along with a PO to a contract manufacturer to create the part for us. So the part drawings are the "Design Outputs" of the DHF. So the BOM is just a list of all our parts, each of which have an approved part drawing. So why wouldn't the BOM go into the DHF as well as the DMR?

On top of that, where is the cut-off between the DHR and DMR in terms of part drawings, selecting contract manufacturers, manufacturing parts for verification/validation testing, and then manufacturing finished product after FDA 510(k) approval? It seems to me that it's a giant mish-mash of unhelpful vague nothingness. I keep reading that the DHF and DMR are often conflated at different companies, there's no requirement to actually have them separate, and that the "Design Transfer" process can start at any point (because you need to manufacture parts for verification/validation testing in order to get FDA approval in the first place).

 

[yodon]

You ended up asking where the BOM "goes" - DHF or DMR.

To maybe help your mindset, think of the DMR as the "recipe" for building the device. Whatever manufacturing needs to properly and consistently build the device is appropriate for the DMR. (The DMR is really just a list of everything - with revision identification for each item as well as for the DMR itself.)

The DHR (DEVICE History RECORD - not to be confused with the DHF) is the evidence that the device was built per the recipe (DMR).

The DHF is all the design history. What you list above is accurate but there's generally more in the DHF; e.g., Plans, V&V materials, etc.

I DO have the BOM in the DMR. It's feasible to manage it in the DHF and just then reference it in the DMR. It's kind of straddling the fence.

A couple of things in your post also caught my eye:

the "Design Transfer" process can start at any point (because you need to manufacture parts for verification/validation testing in order to get FDA approval in the first place)

Design verification does not need to be done with production parts so they don't need to be done per the DMR. Validation needs to be done with production or production equivalent devices. Again, you don't HAVE to have production devices if you can establish equivalence.

We coded the software ourselves.

I hope you're familiar with either IEC 62304 (software lifecycle / FDA recognized consensus standard) or at least the relevant FDA guidance docs (submission & validation... and possibly the cybersecurity ones).

 

[ga2qa23]

I DO have the BOM in the DMR. It's feasible to manage it in the DHF and just then reference it in the DMR. It's kind of straddling the fence.

So the BOM is a version-controlled document with its own document ID number, right? I understand that the BOM must be referenced by the DMR, but the BOM is just a list of the "Design Output" drawings from your DHF, right?

So are you creating your BOM during the DHF-phase, approving your BOM during the DHF-phase, but not actually referencing the BOM in your DHF?

As per your other points...

• Yes I understand that Verification/Validation can be done with "production equivalent" devices but you still need to approve part drawings for that to happen. And those part drawings (or their final versions) would then show up in the BOM.
• Yes we know about IEC 62304. We have procedures written for those, and we plan to have a vendor perform a cybersecurity assessment for us.

 

[yodon]

So the BOM is a version-controlled document with its own document ID number, right?

When we do it, it is absolutely a version-controlled document! I can't see NOT doing that and being successful.

the BOM is just a list of the "Design Output" drawings from your DHF, right?

No, the BOM is the list of all the items that go into the assembly, down to the last screw and adhesives used. It tells the manufacturer exactly what to get, typically from whom to get it (possibly with alternate suppliers), what the specifications are, and often what the cost is.

 

[Ed Panek]

Agree with Yodon. Any output like a BOM must be controlled. The BOM lists the components in the product. BOMs can be updated based on complaint data, supplier issues, optimizations etc. All those changes must go through a controlled change process and the new BOM is an output of that change.

 

[indubioush]

So the BOM is a version-controlled document with its own document ID number, right?

There is no requirement that you have the BOM as a separate document. In fact, I don't usually see this. Here are some ways it can be done:

The DMR is a manufacturing flow chart that lists all materials used for each assembly. In this way, the BOM is incorporated into the DMR itself.

The DMR references instructions and specification drawing for each subassembly. The subassembly drawing contains the BOM for that particular subassembly. Here, the BOM is in the specification drawings only.

The DMR is the device history record form, which contains all DMR information. Each process has a hardcoded list of materials (i.e., BOM). The filled out history record form is the device history record for that batch of devices.

The reason why the BOM is not necessarily included in the design history file is because the DMR is the higher level document that will always provide reference to any kind of BOM you use.

However, depending on your system, it may be useful to include a BOM in your design history file. I have done this before in order to document the "frozen design." This way, you can easily go back and trace all changes that occurred while doing design verification. This can be useful if your manufacturing processes are not finalized and you are far away from having any kind of DMR.

 

[indubioush]

(The DMR is really just a list of everything - with revision identification for each item as well as for the DMR itself.)

I usually agree with absolutely everything you write, but I do want to say that it is possible to have a DMR that does not list the revisions. The change control process should dictate when to change a part number, and that would affect the DMR. Minor changes in this case would not prompt a DMR revision, and therefore it is easier to see the actual change history of the device since you don't have to rev the DMR for minor changes. Do you always have revisions in your DMR? Curious about this.

 

[yodon]

it is possible to have a DMR that does not list the revisions.... Minor changes in this case would not prompt a DMR revision

There is a (not invalid) school of thought for not revision controlling the DMR. I tend to take a very conservative approach, though, so that there's no question of the version of the DMR the DHR demonstrates compliance to. I also tend to avoid the change control process for minor changes since that can be subjective. Again, I go very conservative when advising companies in my best attempt to make them bullet-proof. If your approach is (and I assume it is) defensible and can result in no confusion, then that works, too. (I try not to be a "my or the highway" kind )

 

[Tidge]

I prefer a DMR with revisions. It makes analysis and remediation much more straightforward.

 

[ga2qa23]

Hi All, I really appreciate your inputs. Things are becoming much more clear now. I'm thinking of doing the following...

• In the DHF, publish a new document called "parts list" (version controlled) that is basically identical to a BOM. It keeps track of all the parts in a neat order for assemblies, subassemblies, subcomponents, etc. All the CAD drawings/files for each part is still maintained in my traceability matrix, in my column of "Design Outputs", but now I'll also have this additional separate document "parts list" used to keep track of the same thing but much more neatly/organized.
• For the DMR, I publish a new document called "DMR Index" (version controlled) that is basically a table of contents that lists out the BOM, IFU, manufacturing work instructions, labels, etc.
• In the DMR, I publish the BOM (version controlled) as per the norm. The BOM lists out all the various document ID numbers for the CAD drawings of the parts (aka "specifications".

Does this plan align with all the advice you've provided?