Medical Devices and the FDA, a History of Change

As you probably know, devices of all types continue to get more complex, more interconnected, and in the world of medical devices, more and more specialized to provide new benefits to patients, medical staff, and hospitals that improve all our lives. This goes together with evolving ways in which governmental regulators look at these devices; perhaps half a step behind the industry but looking to define what it means to be safe and secure in a rapidly changing world. In the United States, this responsibility mainly falls upon the Food and Drug Administration (FDA) who places requirements on the device manufacturers that they ultimately must fulfil to be allowed to market their devices. Other countries and regions have regulatory agencies like the FDA, but we’ll focus on the FDA in this blog. It makes sense to understand how we got here, and what that might mean for the future.

While precursors to the FDA date back to the Civil War (the FDA traces their history to 1862), it first appears in something like its current form in 1927, after several laws had been passed regulating several aspects of food and drugs, mainly focusing on standards for labeling of these products. In 1935 there was a scandal in the drug “Elixir of Sulfanilamide”, which contained a poisonous solvent that killed 107 people, mainly children. In response, in 1938 congress passed the Federal Food, Drug and Cosmetic Act which contained several provisions that continue to guide the FDA today, among them:

1. It gave the FDA regulatory oversight of therapeutic devices
2. It installed a requirement that new drugs be shown to be safe before they could be marketed to the public
3. It gave the FDA and the courts authority to implement and enforce these, and other food, drug and medical device requirements.

In 1949, the FDA published its first guidance to industry (about how to determine the toxicity of food additives), which is a format in which the FDA continues to use to this day, including on how safety and security needs to be measured and documented in medical devices. However, it wasn’t until the 1970s that congress required device manufacturers to follow quality control procedures and register them with the FDA, and that certain devices must have pre-market approval by the FDA, which led to the system manufacturers use to this day to show the FDA that their devices are safe. This was augmented after 9/11 to expand the FDA’s authority over the safety and efficacy of medical devices to cover the security of those devices.

Through all this history, we see congress has given the FDA wide responsibility over the safety and security of medical devices, and wide authority to determine what manufacturers must do to satisfy these responsibilities. Further, even in today’s divided political landscape, congress has shown no sign of backing off the responsibilities they’ve given the agency and has shown willingness to expand that responsibility as circumstances warrant.

So, what does this mean for the future of the requirements placed on medical device manufacturers, especially as far as software is concerned? The first thing to consider is that the FDA is aware of the emphasis that manufacturers are placing on software; both for standalone devices and for apps that might run on a phone or smart-watch, and they are aware that some of the foundational pieces such as Open-Source Software (OSS), may not be developed to software safety standards such as IEC 62304 (Medical device software – Software lifecycle processes). Another consideration is that the FDA is aware of the evolving landscape of security; what the state of the art is for secure development, what the threats are, and that the amount of data that needs to be protected is constantly increasing. Further, we know that when something goes horribly wrong (such as a 2012 epidemic of fungal meningitis that was tracked down to contamination of a legal drug), that congress will extend the FDA’s responsibility and authority to make sure a similar breakdown doesn’t happen the same way in the future.

So, keeping all this in mind, here’s what I see for the future of FDA expectations from device manufacturers:

• An increasing emphasis on security in these devices, and increased testing to make sure devices are secure when released. While this has been required since 2002, the recent creation of standards such as ANSI/CAN/UL 2900 will be an increasing emphasis in the reviews of pre/post-market submissions.
• In-hand with this expectation, the FDA will expect increasing sophistication on preventing attacks based on known vulnerabilities, such as those listed as Common Vulnerabilies and Exposures (CVEs), including methods to securely update vulnerable devices when new CVEs are discovered.
• The FDA will continue to keep an eye on the open-source communities
  • For safety, they will monitor efforts led by OSS comunities to improve the quality of open source to make this an easier and better solution for device designers and manufacturers. The ELISA project (focusing on the safety of the Linux® kernel), and safety activities around both the Zephyr real-time operating system and Xen hypervisor will become more vital as time goes on; these efforts are sponsored by the Linux Foundation, and are worth monitoring if you are thinking about using open-source software as part of your device
  • For security, they will emphasize the best security add-ons available in the open-source community, such as OpenSSL.

There will be other directives and improvements, but they will be driven by the forces mentioned above. Hopefully this background gives you better knowledge of how the FDA’s responsibilities have come to be, and how they refine their requirements to better satisfy those requirements and serve their role of ensuring device safety and security for the public, and how these might expand in the future.

Learn more about Embedded Software for Medical Devices https://www.plm.automation.siemens.com/global/en/industries/medical-devices-pharmaceuticals/medical-instruments-equipment/embedded-software.html