Many new medical devices integrate connectivity and more functional capabilities. The design requirements associated with these added functions increase the complexity of the entire system, and with that comes interoperability and security risks. Laura Elan, engineering manager at UL, LLC shares some of the common and emerging issues associated with software compliance and requirements.
Laura Elan will be speaking at the Medical Device Software conference | March 21–22, 2017 | Washington, DC | Learn more
MedTech Intelligence: What current challenges do device companies face in the area of software regulatory, quality and compliance?
Laura Elan: I think there are two key areas that have been contributing to challenges for medical device manufacturers. First, software complexity continues to increase. With lines of code and functionality dramatically increasing in medical devices and Software as a Medical Device, so many products now have such a large code base. Verification coverage and execution of sizeable software code continues to be increasingly difficult. Add on top of code base size the advancing functionality—including more than just algorithms medical devices are also increasingly connected through IT networks. This results in different and often disparate parts of a system with connectivity dependencies. Last, oftentimes third-party software plays a part in the connectivity and functionality. This adds yet another layer of complexity. Can manufacturers completely characterize all of the functional aspects within a software solution of such complexity? It will be important for manufacturers to have the ability to determine an efficient way of verifying the requirements of that system completely.
Second, I think we still see a difference in regulatory approaches with software. And in some ways, we’re seeing regulators in certain parts of the world begin to adopt standards for the very first time. Thus, companies are seeing the need to demonstrate they have a lifecycle management process that produces the type of objective evidence such as risk management, architectural and design documents, and verification planning and reports. For many geographies with established requirements, now these regulatory bodies are beginning to address more complex issues with connectable medical devices. Regulators have begun to recognize and discuss potential risks with medical device interoperability, considering safety as well as security concerns.
A global company may also experience a varied and broad landscape of compliance requirements, which further adds complexity for product launch. One can certainly design a device for the most stringent requirements; however there are likely tradeoffs between product design and regional requirements. Many companies will have to carefully consider these design trade-offs decisions based on the global regions and regulatory requirements for their desired markets.
MTI: Are you seeing specific issues in product development when it involves the integration of software?
Elan: We’re seeing so many requirements that continue to emerge for software—security is a great example of that. We know that with software development there exists this notion of “How hard can it be to change? It’s just software!” Well, it really actually isn’t an easy thing. Software design and development is pretty complex. Design modularity can certainly help, however a lot of that has to start very early in the design process. Today manufacturers with products that have been in the field many years are dealing with the prospect of legacy software and how to integrate new functionality or additional requirements such as security into these software-based products. Often times it forces manufacturers to go back to the design board and start over. That’s true for not only security but also features and functionality such as adding networking or wireless connectivity. Continuing to bolt on these types of features tends to make software very brittle, and it can become very difficult for manufacturers to get products to market quickly. Again, there’s is a tradeoff between speed to market and a development cost with having new features to software in a robust manner.