Put Yourself in the FDA’s Shoes 🔗
Can a glossary speed up your FDA review?
Imagine you are an FDA reviewer. You face a barrage of submissions, and each is filled with lingo:
- Software Terms such as JWT, NPM Package, and GraphQL Client
- Clinical Terms such as DHQ, PPTA aDHQ, Qualified Donor, and Cementoenamel Junction
- Device-Specific Terms such as MIP Pipeline, DICOM Validation Module, Inputs Sensor Barcode, or Cardiac Input Dataset
- Metrics such as Major Error or Reference Time
🍀 If you’re lucky, there’s a glossary. If you’re really lucky, all of the abbreviations and terms are defined.
🐈⬛ Unfortunately, you’re not lucky.
If there is a glossary, its incomplete. Some terms are duplicated or, worse, conflict. There are unused leftover terms.
You you read DOC-0143 Device Description (written by James, the young libertarian product lead with a disdain for regulation). It uses one set of terms.
Next you read the DOC-0158 Software Description (written by Jennifer the Software Lead who desperately wants to get back to coding) and it uses a different set of terms.
Why Does this Happen? 🔗
Getting a team to use and maintain a consistent glossary is hard.
- Debating definitions can feel abstract or pointless.
- It's not always obvious what you need to define. I'm often half-way through writing a document when I'll realize, "Wait, I should define a term for this!"
- Keeping the team up to date with the terms that are added is difficult. You add term to the shared glossary. So does George, but neither of you notice the other's term.
- Engineers may use terms differently than the FDA expects (e.g., with AI/ML devices, the FDA prefers "Test Dataset" to the more broadly used "Validation Dataset")
- It often isn't clear where a definition came from (did Tes make it up, or did it come from a FDA guidance). As a result, someone changes the term when they shouldn't.
Possible Solutions 🔗
I haven't found a perfect solution to these problems, but here are some ideas I've tried:
- Create buy-in for using the shared glossary early in the 510(k). With engineers, I emphasize the many parallels between writing good code and good documentation (DRY, KISS, refactoring, etc.)
- Set up a specific Slack channel for "Glossary Discussions" and have everyone list their new terms here before adding them. (Our Medtech OS documentation platform automates this for us, and posts.)
- Hold a meeting and try to get the team to agree on terminology (i.e., to "come to terms"). During this meeting, I explain FDA terms that affect the project (e.g., "Quantitative Imaging Function" for radiology AI/ML projects)
- To help ensure people don’t modify regulatory terms, we link our terms back to the references where the terms come from.
- 🤖 I’d like to add an LLM-powered agent that flags documentation for missing definitions, duplicate terms, and more.
Medtech OS Example 🔗
Here’s a screenshot of how this works in Medtech OS:
A well-maintained glossary not only aids the FDA reviewer but also streamlines your documentation process, potentially speeding up your submission.
Seen any other glossary pitfalls or have other tips? I’d love to hear them! Please connect with me on LinkedIn and send me a note.
