When your company is developing software for a medical device, regulatory standards can hinder your ability to launch more timely updates unless you plan carefully.
This is especially true for software that is considered part of your device by FDA standards (for example, software that is necessary to complete a procedure). This type of software is subject to more stringent regulations than secondary software that handles post-procedural data.
As we all know, any software you develop is going to need to be updated periodically to maintain functionality, add new features, etc. But when your software has to undergo more rigorous regulatory review, how do you avoid getting slowed down by that process?
In Episode 3 of The Health Connective Show, we discussed how software architecture can help solve these issues with Bold Type‘s Jose Bohorquez, Mohamad Foustok, and Andres Echeverry. Here are some of the takeaways.
Using Software Architecture to Streamline the Regulatory Process
If you aren’t careful in defining medical and non-medical boundaries for your device early on, it can add time to your regulatory review process and increase your costs. In the long run, it can also make it more difficult to roll out updates to your software on a more frequent basis.
When medtech companies don’t clearly define those boundaries on what does and does not need FDA approval, what often ends up happening is they submit everything as part of the medical device for review when they might not have needed to. This not only slows down the initial review, but also each subsequent update that you might need to make. Instead of making frequent updates, you might have to go a lot longer between new releases, which can really disrupt business goals.
You also must consider what platforms you are using to display information. In the podcast, Mohamad mentioned the current trend of developing a smartphone app to use as a display for medical devices rather than a separate, dedicated display screen for the device. The potential pitfall with that is that if the smartphone is used as a display during the procedure, it is now considered part of the medical device and subject to regulatory review. So, you have to weigh whether or not those choices are worth it in the grand scheme of things.
Reducing the Scope of Your Project
For startups in the initial phases of product development, clearly defining and tightening up those boundaries can mean that the scope of your project is much smaller, and your FDA review process may be easier.
As Mohamad mentioned in the podcast, the larger your submission may be, the greater the chance that FDA reviewers may find something that they don’t like. You then, in turn, have to go back and change things. When you keep your medical device submission as tight as possible, there is a greater chance of getting it right the first time.
Additionally, it takes a lot of extra work and testing to get medical device software ready for regulatory review. When you are doing this for parts of your software that don’t need to be considered part of the medical device, you are increasing the scope of your project needlessly.
Allowing for More Frequent Updates
When you can partition out those features that must be reviewed as a medical device, it also makes it much easier to release updates to the parts of the software that are not considered medical in nature.
There are several things that you might want to add to an app that have no direct impact on the procedural function of the medical device. But, if you haven’t planned out your software architecture to strategically separate those elements from the medical device aspect, you may be forced to submit those updates for regulatory review. If the initial plan was, say, to update the software monthly, it might not be possible to meet those goals if you have to do regression analysis, verification, validation, etc. for every new release.
It may be tempting to create two distinct systems to solve this problem–one for all of the features that must be reviewed as part of the medical device, and another for those secondary features. However, forcing your users to switch between two separate systems for one device isn’t a great experience. Skilled software architecture allows you to set a clear boundary internally, while still creating a single experience for the end user. Then, when you need to update that secondary part of your software, you can do so without having to submit it for regulatory review.
Planning Ahead to Avoid Future Slowdowns
It’s more than worth it to take the time to really nail down your software architecture before jumping into a project. Doing so could save you time during the initial review process, and make it much easier to roll out updates that do not impact the use of the actual device in an efficient manner.
Health Connective’s Development Essentials
These different components are the foundation of any solid development project in our minds. Check out our 7 essentials, and see if you agree.
Justin Bantuelle balances the responsibilities of both the Chief Operating Officer and the Web Technology Director after having worked with Health Connective for more than a dozen years. Justin regularly leads the cross-disciplinary teams in building out and updating applications for Fortune 500 companies.
Justin keeps his technical abilities sharp by contributing to an eclectic mix of open-source and personal projects on Github.
As the marketing manager, Ashley ensures that our clients’ marketing strategies are put into action. This includes content writing, SEO, online advertising, analytics, and interfacing with the tools, systems, and team members needed to help our clients accomplish their marketing goals.
