DHF, DMR, and DHR are easy to mix up when you’re just using the abbreviations – they sound a lot alike! And they are connected. But it’s important to understand the differences between them as well as how they interact with each other.
Medical Device Guru Laura Court joins the podcast today to discuss these three documents – what you need to know about them, what to do with them, and why it matters.
Listen to the episode to learn how Laura thinks about best practices, what companies get wrong, and how to improve when dealing with these three different kinds of documentation.
Watch the Video:
Listen now:
Like this episode? Subscribe today on iTunes or Spotify.
Some of the highlights of this episode include:
-
DHF vs. DMR vs. DHR
-
What’s involved with the design history file
-
Recommendations for retaining the design history file
-
The difficulties of paper files
-
What device master records are
-
Making sense out of device history records
-
What goes into the DHR per the FDA
-
How engineers can do a better job of the feedback process
-
The change control process to update the DMR
-
Laura’s additional advice about documenting early
Links:
Memorable quotes from Laura Court:
“I am on the onboarding and implementation side of our team for the gurus here, so I help get our customers started in the software.”
“Your design history file is truly the history of how your product was developed.”
“Don’t assume that you know everything. Even if you’ve been reading your DHF, you’re not going to know everything.”
“Everything should go through document control.”
Transcript:
Etienne Nichols: Welcome to the Global Medical Device Podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge direct from some of the world's leading medical device experts and companies.
Hey everyone. Welcome back. I'm excited to be talking with Laura Court today. She's one of our medical device gurus here at Greenlight Guru. Laura, how are you doing? You want to talk a little bit about what you do here at Greenlight Guru?
Laura Court: I'm doing good. So, I laugh because my position in Greenlight's one of the most unique engineering positions I've ever had.
Previously I had worked as a product development engineer. Pretty much everyone knows what a product development engineer does. You're working on design controls, you're working with quality, just all the kind of fun stuff that's pretty common.
But when you hear the job title of medical device guru, first thing people are going to ask you is, what do you actually do? Or what is the guru?
And so, my specialty within the team, we recently split about a year ago, but I am on the onboarding and implementation side of our team for the gurus here. So, I help get our customers started in the software, get them up and going, learn the ins and the outs. You have to learn what button does what.
But once you get past that, we even help specialize in how are you going to implement now this new software into your company, into your team, how are you going to get your documents in all of that kind of fun nitty gritty stuff at the very beginning of starting up a new QMS or transitioning an existing QMS and getting it up and started.
In the past, before I specialized into the onboarding side, I also did some of the strategic side as well, which was really helping our customers who needed that extra bit of support and questions.
From everything from design controls to quality to administrative side, anything along those lines, we kind of touch it all. So, I laugh in saying we're all very good at thinking on our feet, on our team, and we can pretty much help you with most things.
And if I don't know the answer, I will always find it for you. So, a guru does multiple things,
but mainly we're here to help.
Etienne Nichols: That's a great answer. And you know, I struggled to answer that question myself as well when I was working as a medical device guru. So that's, that's, that's really good.
And so, you really have a lot of wide-reaching experience. But the thing that I'd really like to talk to you about today is Maybe reaching back in your past, maybe some of the things that you, you've. You're experiencing and helping other customers or medical device professionals work through. And that is like the product development cycle of DHF versus your DHR versus your DMR.
Those are three acronyms that sound a lot alike, but I, I'd like us to break those down today. I mean, I don't. Do you have an opinion or where you want to start with that?
Laura Court: Oh, I laugh because I will tell everyone this. Whoever decided to name all three of them with such similar acronyms should just go off into the woods by themselves and just leave everyone else alone.
Because it's just a cruel joke, I swear that they're playing on everyone.
I have worked on with them for years. I spent five months at my last company just building a design history file and I still can't keep the acronym straight. So, if you struggle with it, I don't feel bad.
I keep a post it note on my desktop so that I can like quickly reference and be like, okay, wait, which one am I actually supposed to put this under?
Just as my little reference guide. But a lot of my past history was working on design history files, specifically in design controls, which ultimately then go into your DMRs. And as part of that design history file as well, you have to build documents to be a part of your DHR.
So, they all truly interrelate with each other. But again, whoever named them just leave the world alone.
Etienne Nichols: Well, let's start with the, the dh and maybe I'll start first by breaking down what the acronyms are. You kind of mentioned them already, but DHF, Design History File,
DHR Design History Record, DMR Design Master Record. But let's start with DHF, the Design history file. When you think of design history file, what goes into that?
What's involved with the design history file, when do we start building it and things like that.
Laura Court: Your design history file, you're actually going to start building that well before you even think that you are. Because your design history file is truly the history of how your product was developed.
So, when you initially start, even if you're just in the prototyping phase and you're writing down that we're trying out this material, we're trying out this material, all of that's going to feed into your official design controls that you'll go with for the official design, and all of this design controls, your user needs, design inputs through to your verifications, validations, outputs, all of those are that design history file because it's how did you develop the product?
It's going to include everything from your design plans for the actual project that you're working on, all of your drawings, manufacturing documents, templates, things like that that are going to be part of your design outputs. Ultimately, design reviews always do your design review. Don't just do one. I know the FDA says you only need $1, do multiple. That's my biggest piece of advice to everyone.
But everything that you're doing as far as how you're building that device and what you're going to need in the future for those design outputs, all of that is your design history file.
True.
Etienne Nichols: And that, that's really good advice. You know, I actually in the industry as, even as a project manager, I thought you did a design review at each stage review. You know, there's a difference between a design review and a stage review.
So, from, from a project management standpoint, I saw them as one of the same. When you finally separate yourself and look at the regulations for what they are, you, you can get, get a better understanding of that.
But you're right, there's only a requirement for one. But can you imagine design doing an entire review from nuts and bolts all the way up to the, you know, finished device at the very end?
That's, that's mildly terrifying, actually to think about.
Laura Court: I think that's the best way to cause delays in your project because if you don't get your key stakeholders, like marketing. I had to work with marketing on a product I worked with once.
I didn't know there were so many different shades of blue in my life.
And if I had gone through the entire process and had basically material on order for this specific blue that they needed to have for some reason or another, that would have set us back. But I had them in on my early stages. I had finance in on my early stages. Manufacturing.
Never assume that you know more than manufacturing or the people who's going to be making the devices, because they're going to have heavy input into the beginning of that product development.
So that's why, like you said, you typically or should, in my opinion, have a design review at every stage, just so that you get those key stakeholders and you get everyone's input and it's going to save you both time and money in the long run.
Etienne Nichols: Yeah, and so I wanted to read too, because you did mention several things about the design history file. And I want to break it down just a little bit, but what's interesting is I pulled up the FDA, the 21 Code of Federal Regulations 21 CFR Part 820.30, which is where design controls is located.
Section J, the very last part of part 820.30, design history file. And there's two sentences. It has two full sentences.
Each manufacturer shall establish and maintain a DHF for each type of device.
So, interesting thought there. Okay, whatever device you have, that's two different. There's a DHF for each device.
The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.
So that's interesting to me because there's, there's actually a lot in those sentences, but it's, there's not, there's not much there either. You know, there's not a lot of words.
So, in your, in your past working for, you know, whether it's following the, the requirements of this part or the approved design plan, do you have any recommendations or any best practices as far as that goes in maintaining that design history file document?
Laura Court: I know as much as we all hate it so as like starting off, when I was an early engineer, I hated how much I had to document everything. It truly does help you in the long run because if you start documenting early, you're just going to make it easy for yourself to assemble this design history file.
In the past, I mentioned previously that I once worked on five months on a design history file, and that was because there had been a lot of different hands who chose to document things in a variety of ways that put it nicely.
There was a lot of hands in the pot for this design history file. For this product, it was a bit of a mess. So, I took the time, and I sat down, I went through every document, every, everything that there was, and just made sure everything was in alignment with how it should be documented.
Filling in gaps, things along the signs. That's why even if you're in the product development phase or you're in that very fast prototyping phase, no, you don't need to make an official trace matrix if you're changing your design every two days until you get closer to that design freeze stage.
But if you document at least some notes for yourself as far as what you're doing, you're going to make your life so much easier as far as starting that design history file.
And you'll have most of it built by the time you even go to be like, what's a design history file? What do I need to do? You're going to have a lot of it done already.
Etienne Nichols: Yeah. And one other thing I'll bring up too because you make a good point. All of those docs, all of those, whether it's protocols or reports around how maybe you verified your.
The design of your device, those all need to go into that DHF. And there's two ways you can do that. So. And I'm curious if you have an opinion on one way or another.
So, when I was in the industry, I maintain a spreadsheet, and I referenced those reports and documents. But I've also heard of a lot of different product development engineers who, they would keep the actual protocols and reports in binders and so they would all be in that location.
Like if you wanted to know something about that device, you'd go look at the DHF and it would be located in that binder. And you know, in a paper world, you know, it's almost like picking the worst of two evils. But I don't know if you have an opinion or thought of that.
Laura Court: I swear I have like traumatic. I don't even know past from going through some of those binders.
While yes, they had their place previously, before we had electronic systems, things along those lines. Digging through those is not fun and it is very hard to find everything. I am a full fan of.
It used to be an Excel street that I worked on for.
But I'm a full fan of just having the documents referenced so that you can easily pull them if an auditor's looking at your design history file in the future.
Nobody wants paper cuts while going through a binder.
Etienne Nichols: That's the last thing you want to give an auditor is paper cuts. That's good.
Quotable quotes from Laura Cora. Okay, so, okay, so there's the DHF. The design history file serves a big purpose. You already mentioned. You gotta start early so that you can.
You're not working at the end trying to reverse engineer your device. Finding. Okay, where are the reports of protocols? What do we even use so that that all makes sense?
So, I don't know, do you have a preference? Do you want to go to DMR or DHR? Which, which one would you prefer next?
Laura Court: I would go to DMR next.
Etienne Nichols: Okay, let's talk about DMRS device Master record.
Laura Court: Yeah. So, the name just kind of in general, the fact that it's the master record leads you to the fact that it's kind of going to be that final stack of documents for this product.
It is the product design and how it was manufactured or how. Sorry, not how, how to manufacture it. So, you're looking at how to manufacture it. So, this is going to include things, things like your bill of materials, your device specifications, packaging labeling specifications, quality assurance procedures and specification installation, maintenance products, process specifications.
You'll notice though, a lot of those things that I mentioned also overlap into your design history file. So, things like that packaging and labeling specifications you already have written into your design controls in your design history file, your device specifications, that is your design history file. So, this is where I like to talk about Device Master Record next, because it is going to be a compilation of your design history file and then more on top of it.
So that's where, if you start really strong with that design history file, your device Master record's going to be easy to do because you already have so many of the things checked off the box or.
Yeah, checked off the box.
Etienne Nichols: Yeah, exactly. So, and I mean you.
This actually just popped in my head.
You're going to have to tell me if I'm right or wrong here. But the DMR, you can almost call it the Device Master Recipe because that's, that's you're building your device from this DMR.
So, the way I've looked at it in the past, the DHF, that's everything that went into the design and development of the process. And like the user needs the original.
What are we trying to do this for? What the indications for use and stuff.
You get to your design outputs, which you mentioned, user needs. Design inputs, design outputs. Then you verify and validate those. But that middle column, those ver, those design outputs, your drawings, your work instructions, all those different things, you cram that into a design Master recipe record and hand that to a manufacturing engineer. He should have everything he needs to make that device. He doesn't care who, who he's making it for, but he needs to know how to make it.
So, yeah, that's good.
Laura Court: Absolutely. One thing I do with customers who are absolutely brand new to medical devices at all, I've never done anything when it comes to the industry before, but when we first talk, start talking about design controls, I suggest making a design control matrix around a type of food that you like.
I did it with one of our internal people while trading them. We did a design control matrix around a burrito.
And so, I said, I'm like, this is a great practice. Go through and build this out, then take all of your design outputs. Can you hand this to a toddler and make a burrito?
Maybe not a toddler, but can you give it to absolutely anyone? And can they follow the process that you have as part of your outputs to make a burrito the way that you imagined it in your head.
That's gonna be a great way to break it down. It's just the way of trying to connect it back from medical devices back to something that you love. And I found it a lot easier to translate and start to understand what the purpose is.
Etienne Nichols: That's, that's really cool. Is that something we're able to share with other like customers or things like that? Or it'd be better if they just burrito project.
Laura Court: I'm not sure how built out it is, but it's a pretty good one. I know. I also suggest doing them around cake a lot because I'm a baker. I just around cake.
I'll have to see it. That might be something that I can throw in the academy. As far as some food examples, I have some real examples in there for anyone who needs a real example.
Etienne Nichols: Probably better.
Laura Court: But I like the food. I like the food aspect of it.
Etienne Nichols: And yeah, you mentioned being a cake person or a baker. If, if those of you listening, if you haven't seen Laura, I don't know how they could even find it. You need to put something on LinkedIn because it's amazing.
Your, your talents even go beyond medical devices, which is super cool.
Laura Court: Now it's just family and friends get special cakes for fun.
Etienne Nichols: Okay, well now anybody who knows, you know, hit her up on LinkedIn, see if you can get something from her.
Laura Court: But start shipping them worldwide. No.
Etienne Nichols: And so, I'm just going to go ahead and rattle off a few things from Title 21 8, 20.181, which is where you can find advice Master record. I'll also put the links in the show notes so that you, you can find this as well a little bit easier.
So, we talked about the DHF, the DMR. We've already kind of talked about it, but I'm just kind of run through the five things that Laura already mentioned. But number one on there is device specifications.
So, think drawings like, like she mentioned. Number two is work.
Well, production process specifications. But in my simple brain, I like to think work instructions, assembly instructions, then in quality assurance procedures, again, if I break that down, okay, think inspection procedures and then packaging and labeling. And then if, if there's some kind of installation or servicing requirements, that would be the fifth thing.
So yeah, we'll put links in the show notes to that as well. But really good. Did I leave anything out?
Laura Court: No, I think you hit the key ones. Like I said before, just make yourself a post it note and just leave it on your desktop. Because I can't even keep them straight after years.
So, I recommend.
Etienne Nichols: Absolutely. Okay. Our last acronym DHR device history record. How, how do we make this make sense?
Laura Court: So, device history record. Once you've gone through the design and the development, you've gone through all the fun, boring regulatory paperwork that we all know, love and hate, you've gotten your device, you're ready to go to market, or you're about to make your first batch.
There we go. That's the word I'm looking for. A batch or lot of your product.
This is when you're going to start building out a device history record.
So, your device history record is how the product was manufactured and that you followed your DMR. So, this is where it's always going to go back.
All three of these are always going to interrelate to each other. But your device history record, that is going to go specifically with each production batch or lot that you're making.
So, you're not just going to have one. You're ultimately going to have a lot of design history.
Design history records. See, I can't even say them straight. That's why you have a post it note to reference them. But this is where you're going to be recording everything for that batch along your material lots.
All of your production records. So, your dates, your labeling, unique identifiers, who was part of the manufacturing for this specific lot, all of that traceability that you're going to need to be able to track from the raw material through to the finished good, that's all going to be within this design device history record. I'm going to be very careful when I say these names.
But yeah, so this is going to be how did you make it, what did you use? And did you follow your DMR?
Etienne Nichols: So really, it's kind of in from manufacturing terms. If I reach way back into my past, I think the router, or I've heard some people call it the traveler that goes around and everybody signs off on it, you know, has all your instructions.
At the very end you have this thing, okay, we inspected it, we passed three parts, two of them failed. This is how we inspected it against. And this is the release.
These are the UDI numbers. Unique device identification from the labeling, all of that is just the file. So that, you know, in my mind I used to think, man, this is a lot of paperwork, for what reason?
And then we had a failure in the field, and we said, okay, well where's the DHR. We went and looked up the DHR and it is a wealth of information.
Okay. Second shift made it, there wasn't a supervisor on, but you can go back and look at all those different things. It really helps build up all your non-conformance and CAPAs or whatever else that you need to build up against that.
So, lots of good, good reasons for a DHR but yeah. What do you have the list in front of you as far as what specifically goes into the DHR per the FDA?
I I can I could check it out if you don't I have just.
Laura Court: My little bullet points. I don't think I have the official FDA list. I just have material lots of production records, dates, lots labeling, unique identifiers.
What else did I miss? Off the I think you got it.
Oh yeah, I think you got it.
Etienne Nichols: Yeah, there are, let's see here, 2, 4, 6 I I have part 8 20.184 pulled up again. We'll put these in the show notes. I We also have a link to an article that was written a few years ago on a similar subject so we'll include that as well.
But yeah. Dates of manufacturer quantity, manufactured quantity released for distribution acceptance records which demonstrate the device is manufactured in accordance with the DMR. As Laura said, the primary identification label and labeling used for each production unit and any UDI or universal product code, UPC code and any other device identification.
So yeah, that's so the device history record, that's just all the signatures and everything, all the numbers just goes into a filing cabinet in case, you know, for a rainy day if you have some reading you need to do.
Laura Court: Yeah, I have a love hate relationship with DHRs primarily because you have so many of them. If you have a very high quantity product you're going to have a lot of design device history records so it is easy to mess up on one of them because people get so used to filling out the same information you continuously all the time that they need to be scrutinized or they need to be paid attention to very highly.
But they're easy to kind of just throw away. Like this is my normal paperwork that I'm doing every day. You think you filled out everything. It's easy to miss a box but they are going to be your first level of action should something happen like a failure in the field that's going to be your first place you turn to and be like okay,
let's start tracking everything back. So that's why you have to be very careful with your DHRs for each of your different products.
Etienne Nichols: So, the last thing I said, because you had mentioned something that I kind of want to hit on, you said DHF obviously feeds into your DMR. DMR feeds into your DHR.
It's kind of a; it's a sequential process if you look at it that way. But you actually could think of it as a feedback loop. Because I heard someone once, I can't remember who told me one.
One good idea is to put on your router improvement section so the person who's signing it off for each subsequent step, they could fill out. You know, it would be nice if we did this to make it faster, more efficient.
Just a way to capture tribal knowledge.
Do you have any suggestions or thoughts on how engineers or even, you know, whoever it might be can do a little bit better job as far as capturing those items?
Just, just any, any kind of things as far as the whole process goes? That whole circular feedback loop.
Laura Court: Absolutely. So, I love the idea of having that improvement section. This kind of goes back to a story that I was telling ETN before this. As far as. One of the best lessons I think I ever learned as a young engineer was, I was helping out on a revalidation of part of our manufacturing plant.
I was going to be working second shift, had never met everybody that worked down there on the second shift. It was a very loud, noisy environment that I was going to be working in and there's people moving everywhere.
A very physical process, just kind of an intimidating place to almost work at times.
Especially because I looked like a child in the lab coat that was meant for like a six-foot man and I just looked like a child. So, I took the day before and I walked down, waited around till second shift, walked down there and introduced myself to everyone who was working on second shift.
It's like I've never met these people before. Like I just wanted to say hi, give an explanation as far as what I was gonna be doing. So, I'm just not this random face that shows up on a random Tuesday and says, can you do this?
Or like, will you do this for me? Like, no. I took the time, met everybody, kind of learned what different roles were, who was in charge of what areas during that shift and explained why I was going to be down there.
And it was great. Everyone was so receptive to it. Everyone was so nice. It made my job honestly a complete breeze. They gave me a lot of different suggestions while I was there of just like how to make even just the smallest minor improvements or I thought I was doing something correctly.
And they would walk up to me and be like, oh no, no, like do it this way or it's better to do it this way. And I got the feedback later on about how fantastic it was that I had gone down there and introduced myself even just a day before.
Because a lot of people go in with the assumption that I'm going to be the smartest person in the room. That is never my situation. So, I'm never going to be that person.
But I went down there and so just taking that time to get to know everybody and then listen to their feedback, it's the, you can't be the smartest person in the room because people who are working on this product or making it day after day, they're going to know way more than I'm ever going to know.
They're going to know the intricacies of it. And so, getting that introduction and making those connections ultimately helps make a better product because they were then felt comfortable giving me this feedback rather than just walking up to somebody random and saying this isn't working, please go fix it for me.
They'd be like, hey Laura, like could you look into this or maybe try doing this. Be like, yeah, let's throw it in with our next revalidation or let's see how this is going to work.
So that's where it always goes back to make the connections. And don't assume that you know everything. Even if you've been reading your DHF, you're still not going to know everything.
Etienne Nichols: That's a really good point. I mean just to the point of capturing tribal knowledge, that's one of the things that, that we forget about that human centered connection or communication sometimes.
And why would they share that knowledge if they just see you as someone who's trying to seem smarter or above them or whatever. So that's really good. I'm glad you learned that early in your career.
That's something that. It takes us a while sometimes.
Laura Court: It absolutely does. Sometimes.
Etienne Nichols: The one other thing I wanted to mention, my brain just kind of went back to DMRS for a moment and that is that those need to be prepared in accordance with the document controls per part 820.40.
So that just. I just wanted to remind people of that. Just so you have change control, if you have that recipe, it should be specifying revisions and so forth. So that if anything changes the you do go through some sort of change control process to update that DMR.
So just wanted to throw that other little tidbit out. Go ahead.
Laura Court: Let's clarify that though. All your documents should be going through your document control procedures. Even your official final sign offs on your DHRs.
Everything should go through document control. I always laugh and say hug your document control because they get a lot.
Etienne Nichols: More I think about so Kathy was my document control lady manufacturing when I was a manufacturing engineer. And yes, we should have had a hug your document control day because they go through a lot.
Laura Court: Heather was mine and God love her; she caught so many of my mistakes for me. So, hug. Yeah, Hug your document control.
Etienne Nichols: Yep. I'll never forget that. You know you're supposed to be an engineer. How come you're making this typo? Oh, still human.
Laura Court: I'm an engineer. I can't spell. So that was my mistake. I laughed and I told her, I'm like, you'll catch all my spelling mistakes.
Etienne Nichols: Any other thoughts? Piece of advice? I mean, I think we covered it pretty well Any, any of the thoughts though before we, before we end it.
Laura Court: I think we've covered the big ones. Just start documenting early. I know it seems intimidating when it comes to all this different paperwork and acronyms that are going to be thrown at just everything when it comes to medical device, but if you start documenting early on in the development process, you're going to have these three things knocked out more before you even know it. Cause you're already gonna be doing it.
Etienne Nichols: Yeah, that's. That's great. And for those of you who you know are like me, you're taking it in, but you may forget the numbers or the definitions. We'll have that in the show notes, definitely check out the links and we look forward to seeing you next time.
Thank you. Until then, have a great rest of your week. Talk to you all later.
Laura Court: Thank you.
Etienne Nichols: Thanks for tuning in to the Global Medical Device Podcast. If you found value in today's conversation, please take a moment to rate, review and subscribe on your favorite podcast platform. If you've got thoughts or questions, we'd love to hear from you.
Email us at podcast@greenlight.guru. Stay connected for more insights into the future of MedTech innovation. And if you're ready to take your product development to the next level.
Visit us at www.greenlight guru. Until next time, keep innovating and improving the quality of life.
About the Global Medical Device Podcast:
The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.
