Cybersecurity Among Biggest Challenges For Pharma Firms Incorporating Digital Health Technologies
This is the second of two articles focusing on the issues that pharma companies face when moving into the digital health space. In the first installment, the development process, agency guidance, and the type of quality oversight needed for software incorporated into medical device and combination products were explored. This part focuses on the importance of cybersecurity and software maintenance, how time scales and methods of execution differ from those in traditional pharma, how agile software development works, and how to avoid potential pitfalls.
At the Xavier Health Combination Products Summit, Suttons Creek managing partner Steven Badelt provided a review of the evolving digital health regulatory landscape. Badelt has 20 years’ experience in neuroscience, systems engineering, and medical device design and manufacturing, and has consulted with numerous pharma companies as they moved into the medical device and combination product spaces, especially with products containing digital health components.
Cybersecurity Is Forever
Badelt stressed the importance of having a cybersecurity plan for software components in medical devices and combination products, including maintenance of the security over time.
“Once you put something out, cybersecurity is forever,” Badelt explained. “It is not something you build in the first day. You can look at some of the devices from Medtronic in their diabetes division. The early communication systems they had were easily hackable 15 years later. There always has to be a maintenance plan for cybersecurity, and that applies to these systems.”
Cybersecurity is a constant battle to outwit the other side. In order to stay ahead of people who are actively looking to do harm, you need to enable the speed to address it and work in a more transparent and collaborative manner.
Time Scales And Methods Of Execution Differ
The time it takes to get a product on the market – perhaps 10 years for a drug or a few years for a fairly simple medical device – is much longer than it is for software. “On the software side, looking at it from the perspective of maybe not getting it fully approved, but getting the software as a medical device app written, that may only take three months. Even in a regulated environment, that can be done,” Badelt said.
Contrary to popular belief, other industries do not follow a slow, heavy development process that burdens the development team. Certain aerospace companies only allot 15 minutes for a design review and an engineering change approval. That is what you are going to find in the software space as well. It is using agile development practices in ways that are quite different from common practices pharmaceutical companies follow.
Badelt noted that for drug CMC changes — for example, a formulation change — a number of tests may be required, and they can take a significant amount of time. For a medical device, something simple like a design change to an auto-injector can happen in days.
Although the design change may happen in days, there will be additional time needed for validation and documentation. However, “the scale of executing changes in a device is fairly small. For software, I can make a design change and recompile the software and have it in a test unit, run automated tests, and have a new version that is fully tested the next day. I could potentially, if I got through all of my paperwork, have that out and on the market in the app store the following day,” he said.
He recognized that those timelines might not be practical “in this particular market,” but emphasized that the capability exists. “That is where pharma is already recognizing that there are some massive changes in time scales from what pharma can do in the CMC cycle, what it looks like in the medical device cycle on the hardware side for injectors, and now what is possible for software. You cannot tie software development down to a CMC timeline. No one wants to wait 10 years for a software release. Your iPhone will not even exist at that point.”
Agile Development Is An Iterative Process
One of the main reasons that software development can take place rapidly is that it does not follow a waterfall process. Instead, many aspects of the process run in parallel and are iterative.
In the software world, a commonly followed design philosophy is agile software development. Agile development begins with an initial concept, requirements, and architecture, followed by multiple design loops. It is an iterative approach under which requirements and solutions evolve through the collaborative effort of cross-functional teams and their end users (see figure below).
The developers “work on one feature one day and get it proven out,” Badelt explained. “Then they might work on another feature the next day. These are called ‘user stories.’ You work through the stories and you constantly recompile. Every morning, you have a 15-minute meeting. You get together and decide what needs to change, what needs to be done differently, how to do it, and then roll out the next version the next day and test it. These can be tested all day long using automated systems. You just keep cranking out revisions.” These aspects of the software development process can create a clash of cultures in a pharmaceutical company.
“Most of the vendors you hire will be using agile development practices,” Badelt said. “So, it is critical to understand how to align their development practices with yours. When they have their small meetings in the morning and they do software updates, define a plan that you can use to demonstrate to yourself as well as to the regulators that you were in control of the development process. It is important for pharma to understand how these quality systems align.”
Badelt explained that coders sit around a table some days as part of a review meeting and read the code together, or they have independent reviews and come back together and audit the code they have written. That is not something that pharma quality people are used to. Pharma will need to hire software quality individuals to make sure those processes are monitored and maintained appropriately and that practices are developed around doing so.
Badelt likened the code development process to writing macros in Microsoft Excel. “If you write one macro, you can check to make sure that one works. Then you write another macro, and you see if that one works. Then you do integration testing to see if they work together.”
At the system level, he said, “we make sure that the software can run on a phone. That is what we might call ‘software validation.’ Software validation in this case is not what you might be considering as validation, which, at least in the pharmaceutical space, is often considered your human factors summative. There are differences in terminology to be careful with.”
How To Avoid Potential Pitfalls
Badelt provided advice and caveats for companies venturing into the medical device and combination products software areas based on his experience working with a number of companies.
“I would highly recommend you start with a staged approach,” he said. “We have seen a number of companies hire a whole bunch of developers and then fire them all and go in a different direction.” He recommended that companies begin with clinical testing and monitoring, which is not as heavily regulated.
Marketing is an area that is likely unfamiliar with device software regulations. In one instance, a regional sales and marketing group decided to set up a website that included a dosage calculator. In October 2017, the company, Chicago-based Opternative, received an FDA warning letter for its On-Line Opternative Eye Examination Mobile Medical App Device, which the agency determined to be a medical device. The solution had been published without an approved application for premarket approval, resulting in the warning letter.
Receiving a warning letter “becomes a broader risk if you are a pharma company,” Badelt cautioned. If a warning letter implicates quality systems relative to software, regulators may decide to look more closely at other systems within the company.
He recommended auditing the entire company and ensuring that everyone understands the implications of creating medical device software. “It is easy for marketing to hire software developers and create cool-looking things. You need to make sure they are not putting in any medical device functionality.”
Companies developing on-body injectors or pens that have firmware in them — for example, functionality that has a display, or a simple device that turns a motor on and off and makes an LED blink — need to understand that all software and firmware in devices are regulated. “You do not want to create a system in which you have created everything around software as a medical device but have not considered the broader implications,” Badelt said.
Another potential area of concern regarding the development of medical device software is the existing IT group within a company. “Prior to this, IT was the primary group within your organization writing software. In a number of cases, IT, because they have been doing software, charges in and starts doing the medical device software development for the organization but does not have any of the medical device processes in place.”
Badelt cautioned that “there are also political considerations. They are going to want to own it because it was their space, and now it is not only their space.”
Post-Market Activities Need Attention Early On
Post-market activities that need to be in place and part of the regulatory filing include maintenance plans for cybersecurity and how the firm plans to handle software bug fixes.
“Are you going to be monitoring the app store for people who rate it only one star?” Badelt asked. “Are you looking for someone to call in to report issues with the app? How are you processing all of that? Just to be clear, software can create more data than you can keep up with if you are not careful.”
You should also have a plan in place for software updates. When iOS or Android releases a new version, you could very easily have software that no longer works. “It could be a screen scaling bug in which the code has changed and the button on the screen does not show up, or only half of it does. Those are things to be considering moving forward,” he said. Because it is not possible to anticipate or test for all users or use scenarios in software development, the company needs to be able to quickly detect issues, address them, and adjust for the way customers are interacting.
Badelt referenced a recent conversation with FDA colleagues in which they highlighted what they considered software regulatory risks. The top two were the ability to keep up with changes and cybersecurity.
About The Author:
Jerry Chapman is a GMP consultant with nearly 40 years of experience in the pharmaceutical industry. His experience includes numerous positions in development, manufacturing, and quality at the plant, site, and corporate levels. He designed and implemented a comprehensive “GMP Intelligence” process at Eli Lilly and again as a consultant at a top-five animal health firm. Chapman served as senior editor at International Pharmaceutical Quality for six years and now consults on GMP intelligence and quality knowledge management and is a freelance writer. You can contact him via email, visit his website, or connect with him on LinkedIn.