< 1 min reading time
Those who have launched a medical device, how did you develop the executable software? Any experiences with purchasing software vs in house development or other methods is appreciated. source: https://www.linkedin.com/groups/78665/78665-6030128815324352513 Marked as spam
|
Meet your next client here. Join our medical devices group community.
Private answer
Nancy Knettell would be a good person to ask: https://medicaldevicesgroup.net/your-advisory-board/#nancy-knettell
Marked as spam
|
|
Private answer
Nancy Knettell, MSMgmt
Hi Justin, Because medical device software is subject to FDA rules and regulations, you have to make sure that when you develop or purchase software it is done under the auspices of a FDA 62304 compliant defined software quality system. This means 62304 compliant written Policies, Procedures, etc. in place. Parts of the software can be purchased, such as a communication stack. Parts can be outsourced. Parts can be developed in house. But, developing the software is only 25% of the process.
To ultimately ensure obtaining regulatory approval you must ensure that you develop all the documentation that goes with the software as defined by your quality process. This can be just as much or more effort than building the software so a good idea to start from the very beginning. You don't need this for prototyping/proof of concept. But once it becomes product oriented, you do. Please feel free to ask me any questions you might have about Med Device Software. Marked as spam
|
|
Private answer
Al Christie
I agree with Nancy above - either embedded software for electromedical devices, or standalone software that can be considered a medical device must be developed in compliance with IEC 62304.
This is referred to by IEC 60601-1 and is very tightly bound to the business QMS, which will include suitable design control, contactor control and risk management (ISO 14971) among many others processes. IEC 62304 itself will give you a very good understanding of what you need, regardless of in-house or off the shelf. The FDA guidance on software validation is also a good reference to help you on your way. Marked as spam
|
|
Private answer
Frances Cohen
Hi Justin,
Medical Device Software is what my company specializes in (PromenadeSoftware). We develop software under the guidelines of the FDA and CE compliance for companies that do not have software teams well versed in the regulation requirements (FYI - FDA needs different things than that of 62304), or need help, test tools, ect.... Your decisions as to make, buy, or outsource have a lot to do with what you are trying to accomplish, the class/risk of the device, and the resources you have. We often see a combination - basically doing what fits best for the budget, timeline, and expertise needed. * Frances Marked as spam
|
|
Private answer
My field of electrical engineering is digital signal processing. I work on algorithms and mathematical software. If you have signal processing or machine learning software that doesn't work, or if you need software developed accurately the first time, please contact me for consulting. My work has been deployed in critical applications such as the AT&T long distance network and the Coast Guard communication satellite.
Marked as spam
|
|
Private answer
Saeed Sokhanvar, PhD, PMP
In addition to the regulatory aspects, there are some business decisions as well. When you buy an OTS software, you need to own it. If the software is obsolete or the seller does not support it at any point of time in future, you must have a plan for it. If you do not have access to the source code, then you might be in trouble. ...
Marked as spam
|
|
Private answer
Al Christie
There are of course many considerations from an operations perspective, however OTS (or COTS) is often unavoidable. For instance, essential components or libraries used to develop specific algorithms, or the operating system itself and a mobile platform.
The medical device software standards force you to address the risks associated with use of such Software of Unknown Provenance (SOUP). Clear SOUP, where source is available such as open source, may seem lower risk than Opaque SOUP, which is essentially a black box. Nonetheless, both can be used with appropriate risk management applied.... with the product and business continuity in mind. Marked as spam
|
|
Private answer
Gottfried Griesmayr
If you intend to launch in Europe, do not miss EN 62304 in the organization developing the software!
Attention, this is not a product standard, but a system standard requiring compliant processes and documented procedures. It applies for all software products fulfilling the medical device definition, either as accessory or as MD-product on its own. FAQ's are found here: http://www.eisnersafety.com/wp-content/uploads/2013/04/FAQ_62304_Ver_1.0_5Apr2013.pdf Marked as spam
|