As the October 1st deadline for the new US Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act) comes into force, the medical device industry is gearing up to meet all the requirements before premarket submissions to the US Food and Drug Administration (FDA).
With the FDA potentially refusing to accept submissions that fail to meet the requirements, sponsors, and developers of cyber devices must be diligent about how to comply with the act.
The PATCH Act, which has been in development for several years, defines a framework for minimal cybersecurity focus within medical devices. On December 29th, 2022, the Act was signed into US law and from March 29, 2023, a premarket application or submission of cyber devices had to contain all information required by the FDA. In this period, the FDA holds back from issuing refuse to accept (RTA) for premarket submissions of cyber devices submitted before October 1st, 2023.
In an exclusive interview with Medical Device Network, former FDA software system safety expert Paul Jones, and Ketryx founder Erez Kaminski, discuss all the concerns surrounding the enforcement of the PATCH Act.
This interview has been edited for clarity and length.
Kiays Khalil: What is the PATCH Act and how will it impact the medical device industry?
Paul Jones: The PATCH Act is a legislative document, passed by the US Congress to establish a security analysis framework for all civilian organisations in the federal government and their affiliates. This framework gives legal authority to the FDA, and within that framework, they're free to make some adjustments that are appropriate.
Erez Kaminski: It comes because of public pressure, industry pressure, and pressure from politicians, that say we need a better way to depend on our digital infrastructure, especially in medicine.
They want manufacturers to be able to produce a patch, which means they have the ability to fix your software based on an unintended consequence, in an off-cycle release. If you can release your software, let's say every month or every three months, although many manufacturers in this industry release in a much broader timeline. The government is saying you still need to have the ability to release software in a reasonable amount of time to remove any possible harm for the public in an off-cycle release.
KK: What are the complexities surrounding the PATCH Act and how can the industry prepare for it?
PJ: The complexities in the abstract are added rigour in the pre-market design control process. Significantly more rigour in the post market surveillance and monitoring process, and change control and corrective action, preventive action processes, and the magnitude of monitoring all these off the shelf, third party software products that would be enumerated in what they call the SBOM (software bill of materials).
KK: What are the benefits that could come from the PATCH Act and who are most likely to reap the rewards?
EK: Over 20% of all medical device recalls are related to software. Long term studies have shown that 80% of that results from changes to software, many of them patches. Patients benefit from having a requirement for transparency, review, and a process that's premeditated to fix obvious issues in the software. There's no software that's deployed today that would not need a patch, within the next five to 10 years, at most, if not in the next week. Codifying that, and making sure that happens, would benefit the people who rely on it the most.
PJ: It's a societal benefit, where anyone from children, up to senior citizens can expect safer products to use when they need them. And doctors who are using the equipment can expect that the device will perform as intended.
KK: How does the PATCH Act influence regulatory decisions on medical devices by the FDA?
PJ: It provides the legal authority to establish guidance, explaining to manufacturers what they want to see in submissions, and how they want them to behave in post market activities. It also allows the organisations like the FDA, to credential their guidance documents. Theoretically people aren't required to comply with them, but it allows FDA to map guidance to specific regulatory code that can be enforced through the legal system, if necessary. For example, people doing audits for the FDA, can refer to these legal codes, and take bad actors to court, and even seize their products.
KK: How will the PATCH Act address safety and security concerns?
PJ: The FDA is concerned that one of these days a device is going to get hacked, like a pacemaker and kill somebody important. To the extent that's a possibility, they're really concerned about trying to prevent that. This PATCH Act gives them the authority to be more forceful in trying to coerce industry to be more proactive and do a better job at trying to prevent situations like that long before they happen.
EK: The issue with cybersecurity, unlike certain other safety concerns around hardware devices, it has nothing to do with your device, it's out of your control. You rely on thousands of other manufacturing organisations or open-source groups that are developing software. Tomorrow, someone can find a zero-day vulnerability, and suddenly every device connected to that library is vulnerable to hacking. A lot of great manufacturers put risk controls in place to prevent hacking. I think fundamentally, if you're using software, you must be able to change from a security standpoint, because you don't control what's going on, and if someone finds an issue, it's important to be able to provide changes rapidly.
PJ: These off the shelf products that are deeply embedded in these systems were not designed for medical grade safety, they're just general-purpose use software. You must build wrappers around these off the shelf systems to address the security issues.
EK: It's just not possible to buy medical grade open-source software. You must use what you have. Most of the software was made to serve social media apps over the phone, not to serve doses for combination products for patients that have serious illnesses.
KK: Will we see more specialised software built for medical devices which will address these concerns?
EK: I think it's absolutely an area of growth. Because there’s a difference in what I expect from an app I use to play a game on my phone and between an app I use to monitor my child's health. My expectation of those two things is so vast that we really need to reconsider what we allow into the latter.
PJ: Ketryx is probably one of the few companies that's out there looking far into the future and using computation to address these complex matters. As society becomes more dependent on these off the shelf products, the demand for perfection, and reliability is going to increase to the point where – for example if something goes wrong with let’s say cloud computing, part of society crashes with it.
KK: How can the industry remain resilient on product monitoring?
EK: Product monitoring, to me is about post market surveillance monitoring, which is an area that I have quite a bit of experience with. I’ve worked with industry and helping the FDA and MDIC in their National Evaluation Centre for Health Care Technology (NEST) CC project.
There will be significant central databases that provide the identified information about the real-world activities of devices and their effects on patients. I think there's going to be a need for industry to adopt new tools and not just build their own custom tools to solve these problems. There's also going to be a big push to do active surveillance, as well as eventually a total change in how passive surveillance is thought about. Because again, it's kind of erratic the way it's done today, and I think that's going to be tied to some extent to your ability to do patches and record digital information from your devices.
PJ: The more data the FDA has, the better the picture they get of the state of the healthcare industry. They're trying to monitor the ecosystems of the healthcare industry.
KK: What are the post market vulnerabilities for devices and how can they be resolved?
EK: Post market vulnerabilities are software vulnerabilities that are discovered in your software after it's been launched into the market. I use a library developed by a team of people in Germany. If someone discovers an exploit and publishes it online, look at how you can use this library to control the device or control the application that is using it. That can happen at any point in the future, we can never know if a library has a potential exploit, you can only know once it's discovered. I can release the device today, scan it for vulnerabilities, but tomorrow or in a week, a year, someone can take full control of it.
There'll be another vulnerability in a major library that's commonly used and this time, it'll be commonly used for some action on a medical device or huge amounts of medical devices. It's not like this might happen, it'll eventually happen many times over in the rest of this decade and century.
