How should I document my medical device technology?
Finding the Right Balance
As a dear mentor of mine likes to say, “there’s a ditch on both sides”.
Common Documentation Pitfalls
It’s quite common, as you might expect, to find companies failing to document their development and testing work. By the time you’re sending your device out for verification and validation testing just prior to FDA submission, the clock has moved past midnight and you’re living on borrowed time if you haven’t got your documentation up to FDA expectations.
On the other hand, believe it or not, there IS such a thing as “too much too soon” in the world of early stage medical device development documentation. This usually comes in the form of zealous quality system consultants selling “complete” “turn-key” quality systems, and unsuspecting startups not realizing that a quality system needs to be grown organically, maintained, and above all USED. The bare minimum done well is far more effective than an overblown set of documents being left to rot.
We see the former and the latter quite a bit.
Striking the Right Balance
It takes hard work and good strategy to find the right balance for documentation at each stage of the process.
What form does good documentation take?
First, it’s important to understand that regulatory auditors are going to be looking for what’s referred to as “objective evidence”. “Objective evidence” usually takes one of two forms: documents, or records.
Understanding Records
Records are just that – a record of what happened at a point in time. Maybe you tested something, or had a review meeting. The dates and signatures on those records attest that something happened at a point in time. There’s generally not a need to update records, except to correct them, as they represent a one-time event.
Understanding Documents
Documents, on the other hand, are “living”. This means that they tend to go through revisions throughout the total product lifecycle of your medical device. If you think you have 200 requirements for your product and then decide later that you have 300, revision 1 of your document is going to be different than revision 2 of your document.
Once you’ve addressed FDA’s minimum expectations for what’s in each document or record and how to store them in an appropriate document control system, there’s no one “right way” beyond that to create or store these documents. Don’t feel like you need to go out and buy the shiny, expensive document control system that will inevitably be pitched to you. If money is no object, many of these do have convenient features, but you can go all the way past clearance without them.
Key Documentation Components
Device Master Record (DMR)
The most current set of documents that tell someone how to build your medical device are referred to as the DMR, or Device Master Record. It’s like the recipe for your medical device.
Design History File (DHF)
The Design History File, on the other hand, contains not only the current revision of all documents, but all the records and revision history covering the whole development process of your medical device, including its testing and release, as well as its inputs (requirements).
Design Controls
That leads to the whole topic of design controls, when they’re required, when they’re not, but that’s for another day. Hopefully this gives you a sense of what some of the documentation looks like that needs to be generated during your medical device development process.
Final Thoughts
As always, if you have any questions about the strategy of crafting your medical device development process, just reach out!