Don’t Make Your Engineers Pull Their Hair Out 🔗
If your software engineers have not previously built a medical device, they will require guidance from a regulatory expert to navigate the process.
There’s a lot to learn: Design inputs, software risk management, SBOMs, post-market vulnerability monitoring, electronic interfaces, system-and-software-architecture diagrams, IEC 62304...
The regulatory expert guiding your engineers can have varying levels of experience:
- Suboptimal: Most experience is with hardware devices
- Good: Experience with software devices
- Best: Are software engineers themselves
If the regulatory expert lacks software experience, your engineers will want to pull their hair out by the end of it. Or worse—quit! (We’ve seen it happen more than once.)
Engineers Hate Pointless Documentation 🔗
Medical device documentation can be placed in one of these categories:
- Documentation that helps make the device safer
- Documentation needed to satisfy the FDA
- Documentation produced merely to follow your company’s quality procedures
Often engineers like the first type because it gives them breathing room to think about the bigger picture software architecture or cybersecurity.
When they get to the second and third types, they’ll often say: “Do we really need to document ALL of this? Really!?” Engineers ask me this question all the time. Next comes frustration at the bureaucracy, then resignation. 🤨😡😞
We understand. Code is more fun to write than documentation, even when it’s useful documentation, but when the documentation feels pointless it’s even worse. (Doesn’t the Agile Manifesto say “Working software over comprehensive documentation”?)
Good regulatory consultants will minimize the time spent on the second two types of documentation, while saving you time and letting you focus on the first type.
Regulatory Consultants Who Know Software Will Get You To Market Faster 🔗
If you’re working on Software as a Medical Device (SaMD), or a device that contains software (SiMD), regulatory consultants who know about software will save your time:
- They can translate regulatory language into something the engineers understand, reducing pushback from the engineering team.
- They can assist in drafting documentation (see our guaranteed 510(k) software docs in 3 months) or provide concrete examples to guide the team.
- They can help adapt your existing automated software development processes to meet regulatory requirements more naturally, resulting in a more efficient process that will pay dividends well into the future.
- They know which documentation tasks are time-consuming and can help the team achieve the right balance between over-documentation and under-documentation.
Find the Right Documentation Balance 🔗
The amount of documentation you need for a submission isn’t black-and-white. Each device is different. The FDA is as specific as they can be, but guidance will often say things like:
- “the above considerations are intended to serve as a guide and may not apply in every case”
- “leverage industry best practices within and outside the medical device industry”
- “should be commensurate with the safety risk associated with the system, device, or process”.
The amount of documentation needed is often not clear cut. If you write too much documentation, you waste time. If you don’t write enough, the FDA will ask a lot of questions or even reject your submission.
Good regulatory consultants help you find the right balance, thus saving you time and getting your device in the hands of patients faster.
Large companies tend to be conservative and create more documentation. Smaller companies can’t afford to be so conservative—they’ll go bankrupt, and their device won’t get on the market and won’t ever help any patients.
A Case Study in Over Documentation: OTS Overload 🔗
At the risk of getting into the weeds, I’m going to go into a specific example showing how regulatory consultants who know software can save your team time. The example involves the documentation of “OTS Software” as described in the 2019 FDA Guidance titled, “Off-The-Shelf Software Use in Medical Devices.”
What is OTS software? 🔗
The FDA defines Off-The-Shelf (OTS) Software as “a generally available software component, used by a medical device manufacturer for which the manufacturer cannot claim complete software life cycle control.”
The FDA Guidance lists operating systems (like Windows and Linux), device drivers, and utilities (like virus scanners) as examples.
What do you need to document for OTS software? 🔗
There’s a significant amount of information that the FDA guidance suggests is documented for each piece of OTS software. It includes basic things like the name and version, but it also includes a lot of other details:
- Why is this OTS Software appropriate for this medical device?
- What are the expected design limitations of the OTS Software?
- What OTS Software documentation will be provided to the end user?
- What aspects of the OTS Software and system can (and/or must) be installed/configured?
- What measures have been designed into the medical device to prevent the operation of any non-specified OTS Software, e.g., word processors, games?
- What is the OTS Software intended to do? The sponsor’s design documentation should specify exactly which OTS components will be included in the design of the medical device and to what extent OTS Software is involved in error control and messaging in device error control.
- What are the links with other software including software outside the medical device (not reviewed as part of this or another application)? The links to outside software should be completely defined for each medical device/module. The design documentation should include a complete description of the linkage between the medical device software and any outside software (e.g., networks).
- Describe testing, verification, and validation of the OTS Software and ensure it is appropriate for the device hazards associated with the OTS Software. FDA recommends that software test, verification, and validation plans identify the exact OTS Software (title and version) that is to be used. When the software is tested it should be integrated and tested using the specific OTS Software that will be delivered to the user.
- What measures have been designed into the medical device to prevent the introduction of incorrect versions? On startup, ideally, the medical device should check to verify that all software is the correct title, version level, and configuration. If the correct software is not loaded, the medical device should warn the operator and shut down to a safe state.
- How will you ensure proper maintenance and life cycle support for the OTS Software?
- How can OTS software failure result in patient harm, what is the estimated severity of this harm, etc.
And this list is just the basic documentation you need for low risk OTS software (although this is the level you’ll need for most OTS software in SaMD).
SaMD Often Contains 100’s of OTS Software Components! 🔗
Modern software is often developed with hundreds, or even thousands, of open-source packages. This is especially true for software that is built by engineers new to the medical device field—they don’t know better. These packages almost always qualify as OTS software.
If your regulatory consultants don’t know software, they’ll likely give your engineers an excel template and ask them to fill in all of the information for each of the 100s of libraries. We call this “OTS Overload.”
Your engineers will say: “Do we really need to document ALL of this? Really!?” 🤨😡😞
If your regulatory consultants don’t know better, they may just say “yes, you do!” In actual fact, there are several ways you can avoid OTS Overload! I’ll talk through them briefly, but we’ve seen engineers waste weeks on this.
But first, I’m going to explain why, in most cases, the OTS documentation falls squarely into category (2): Documentation we write just to satisfy the FDA.
Why the OTS Guidance Doesn’t Make Sense 🔗
The OTS Guidance was originally written in 1999. Back then, software was simpler and often didn’t incorporate as many third-party dependencies. When they did, they were often not incorporated directly into the device software. This is why so many of the questions the FDA asks about don’t make sense any more, e.g., when considering third-party packages like numpy (a widely used numerical library used in most AI/ML or image-processing applications written with Python):
FDA: What OTS Software documentation will be provided to the end user?
Software Engineer: I don’t think we would give them the numpy docs… so I guess none.
FDA: What aspects of the OTS Software and system can be installed or configured?
Software Engineer: It’s incorporated into our Docker image. So none.
FDA: What measures have been designed into the medical device to prevent the operation of any non-specified OTS Software, e.g., word processors, games?
Software Engineer: Games?! Our software runs on a server in the cloud that only we control.
FDA: What measures have been designed into the medical device to prevent the introduction of incorrect versions?
Software Engineer: We pin the version in our requirements.txt file. Does that count?
Modern software packages, like numpy, are often low-level utilities that function well below the system requirements, software requirements, or even detailed software requirements. They tend to be widely used and battle tested. In many cases, their functionality will be effectively verified by the system-level verification.
So why does the FDA still ask for all of this information? To be fair, the FDA has a hard job. It’s difficult to write regulations for a fast-changing technology landscape. Furthermore, their questions still do make sense for some types of software running on machines the users control, or for packages that are critical for the device or fulfill the system-level requirements.
Strategies to Reduce the OTS Overload 🔗
First of all, we think that any OTS that could fail in a way that would harm patients should be documented according to the FDA guidance. A hazard analysis will help you identify these OTS software components. Regulatory consultants who are experts with medical-device software can help.
For many of the low-level utilities, there are a couple of strategies to save time on the documentation:
One strategy is to provide documentation for the most important OTS and note that the remaining OTS components are listed in your Software Bill of Materials (SBOM).
Another strategy is to lump your granular dependencies into “buckets” of related OTS Software and treat them together. For example, we may lump all of our image-processing Python dependencies into one bucket and answer all of the questions for them together. Many of the questions will have similar answers.
Another strategy that can work in some cases, is to isolate the dependencies used in the core software function from the dependencies used for “Other Functions” (See Multiple Device Functions Impact on FDA Submissions for more details about this.)
You can read a lot more about documentation OTS Software in our popular resource: Off-The-Shelf Software: Best Practices, FAQs, and Examples.
How to Hire Regulatory Consultants for SaMD 🔗
If you’re looking for regulatory consultants to guide your engineering team through as they develop SaMD, we suggest asking a these questions:
- How many SaMD devices have you cleared before?
- How will you support our engineers in the documentation effort?
- What are some areas where you’ve seen software engineering teams struggle in past submissions?
We hope this article was interesting and will help you find regulatory help that will get your SaMD on the market as quickly as possible.
We Can Help! 🔗
All our regulatory consultants have software expertise, and some of them are even practicing engineers.
If you’re just venturing out on your medical-device journey and need a partner to help define an optimal path to market, we can help develop a regulatory strategy and can help you develop the software.
If you have a clear regulatory strategy and an engineering team, and your engineers need guidance, we can help. Perhaps you have regulatory experience with hardware but are breaking into SaMD or AI/ML for the first time.
If you have nearly finished software, but need help with your 510(k), we can help draft the documents needed in as little as 3-months, guaranteed. Click here to learn more.
