Originally Published in Pharma Focus Asia December 17, 2019
December 17, 2019
Author:
Steve Galen
Global Head, Clinical (CRO) Division
Navitas Life Sciences
Back in August of 2011 in the Wall Street Journal, Marc Andressen, the famous venture capitalist, wrote a now classic editorial in which he predicted that software would “eat the world”, that is, many traditional businesses and industries would morph from manual enterprises to ones being run using software and delivered as online services.
Although Andressen’s statement was bold at the time, we now accept it as axiomatic.
However, Andressen also predicted that the healthcare industry, was, as he put it, “primed for tipping by great new software-centric entrepreneurs”. As explored more in depth in a recent article1, the healthcare industry, in general, and the clinical research industry, specifically, have not been transformed by software, nor software’s successor, software-enabled platforms.
There are 5 important barriers that have prevented the clinical research industry from being transformed by software and software-enabled platforms. Logically, the desired transformation could be significantly accelerated if the following barriers were removed.
1. A belief that national regulatory authorities are risk-averse and will penalize companies for undertaking (or leveraging) software-based innovation
There was a fascinating research paper published by personnel at Utrecht University, the Netherlands, in 2O15 that aimed to provide insight into why it is difficult to develop software in the pharmaceutical industry. As part of the research, domain experts developing software in the pharmaceutical industry were interviewed about 14 common problems they confronted.
One of the problems was called ‘multi-layered regulatory requirements’, referring to the complexity caused by multiple, overlapping regulatory requirements. Here is the candid observation of one of the domain experts regarding this problem:
It is not only IT, but essentially everything you do in pharma, whenever something is changed or new devices that are not related to IT are implemented… Everything has to be done according to rules and procedures. You cannot just change something in a system. There is a very specific change process that is involved. It sure puts a lot of pressure to accomplish this, which is quite different at other types of companies.
Another related problem, ‘documentative attitude’, is defined as “the comprehensive habit of documentation generation during IT projects” in the pharmaceutical industry. The authors state in this regard:
The problem is so peculiar that one expert made a picture of a stack of test documentation that the expert’s team created …The documentative culture is primarily caused by the need for compliancy to regulations and the fear for regulatory inspections. The current industry standards mainly fuel the need for overhead due to the fear of ‘missing information’.
Regarding another problem, ‘risk-oriented decision making’, the authors note that there is a pervasive “… risk avoiding mentality instead of a risk oriented mentality…”. In a poignant related comment, one of the interviewees states bluntly:
The fear reigns. So let’s not touch it and take zero risk.
And regarding this same problem, the paper’s authors state:
Balancing between incompliant but fast software development and compliant but slow and rigorous software development seems to be highly influenced by fear.
Given this pervasive attitude of fear among pharmaceutical industry software developers, it is not surprising that these software developers are reticent to change current industry practices, even when regulatory agencies themselves are openly encouraging and supporting change, as evidenced in the following recent statement by Cisco Vicenty, program manager for CDRH (Center for Devices and Radiological Health) at FDA:
The FDA supports and encourages the use of automation, information technology, and data solutions throughout the product lifecycle in the design, manufacturing, service, and support of medical devices. Automated systems provide manufacturers advantages for reducing or eliminating errors, increasing business value, optimizing resources, and reducing patient risk. These capabilities provide significant benefits in enhancing product quality and safety.
Perhaps more convincing than even public statements such as the one above would be examples of the regulatory agencies following their own guidances and leveraging software and software-based platforms to change the way they conduct critical activities.
In one powerful example of this, it is hard to imagine a population more in need of protection than infants, and the FDA has the responsibility to ensure that infant formula is safe. FDA collects, reviews and approves the composition of infant formula submitted by manufacturers using its Infant Formula Tracking System (IFTS).
Recently, FDA redesigned the IFTS using low-code Platform as a Service (PaaS). The application was designed and put into production in less than 90 days. The application itself provides end-to-end tracking of the process, full transparency of the review cycle, and enhanced collaboration between the manufacturer and the FDA review team. Paper submissions have been eliminated and approval cycle times have been reduced.
2. Lack of receptivity on the part of Clinical Operations leadership (Pharma, Biotech and CROs) to adopt software solutions that significantly alter the status quo
Clinical operations leaders are typically hyper-focused on making sure clinical trial outputs (selected sites, activated sites, screened patients, enrolled patients, inputted data, cleaned data) are delivered on time, on budget and to quality. Therefore, it makes sense that when they encounter process problems, they typically look for solutions that cause as little downtime as possible, are cheap, and won’t impact deliverable quality.
ln a mature, steady-state industry, this approach makes sense. However, if industry transformation is required or desired, this approach will stymie the required or desired changes.
I witnessed this situation when I was working at a large global CRO that was implementing a software solution built to track process steps for clinical trial data collection, data cleaning and data postprocessing. The software was built, successfully piloted and then prepared for full-scale implementation. The impacted operational leader did not actively support the full-scale implementation, as he was focused on “as is” operations. It wasn’t until a new leader was brought in who understood how the software solution would significantly improve operational visibility and resource utilization, and who was willing to exert influence to overcome organizational resistance to change, that full scale implementation was accomplished.
3. Lack of understanding on the part of clinical operations leadership (pharma, biotech and CROs) of what software can do, resulting in applying software and software-enabled platforms in sub-optimal ways
Even when clinical operations leaders are receptive to applying software or software-enabled platforms to improve operations, they frequently view these new tools as simply extensions of current state tools and exert pressure on the software development teams to build solutions that are de facto recreations of current state tools in the new environment.
I saw several examples of this lack of understanding at a large global CRO that was working with a PaaS provider whose platform had very powerful and sophisticated functionality.
Instead of viewing the situation as an opportunity to rethink and redesign operations (as the FDA did in the example mentioned above), operational leaders instructed their teams to essentially rebuild their Excel “trackers” on the platform. After witnessing this approach being taken a number of times, a colleague wryly named this the “spreadsheet in the sky” phenomenon.
4. A risk-averse approach by QA groups responsible for computer system validation assessments that results in software being assessed as GxP when it is not
ln the Utrecht University paper, one of the interviewees states:
And if you say something like; ‘okay people, we did an impact analysis and we choose to not validate it’. People will respond like; ‘wow, wait a second. We are in a pharmaceutical business here, you cannot just put that thing down and use it?’. They [QA representatives] will directly search for arguments that can have great impact.
Another interviewee comments:
If you look to the people, you can see that there are people that are carved out of oak. These validation specialists have their job to align our practices with CMP regulations. They will do anything…to make sure we do the things [rigorous validation] we should do.
I observed this misclassification numerous times when I was involved with software development activities at several large global CROs, resulting in unnecessary and lengthy delays in releasing software to end users.
A senior technical leader at a PaaS company commented to me that because of this misclassification, he has seen on many occasions clinical research companies build useful apps in less than a week that then took four or more months to validate.
5. A lack of understanding by QA groups responsible for computer system validation assessments regarding how software platforms should be validated that results in QA requiring the entire platform to be re-validated even when the changes are limited to the configuration level of the platform
As previously mentioned, FDA is leveraging PaaS to build CxP applications. PaaS has also made modest inroads into the pharmaceutical industry as well.
One roadblock to expanding the use of PaaS in the pharmaceutical industry is that traditional QA approaches view any change to the platform as requiring full re- validation of the entire platform. This onerous requirement can completely stymie the adoption of PaaS for CxP applications.
This re-validation is, in fact, not necessary. Rather, once the initial core platform is validated, only new pieces of functionality need to be validated. For QA groups that are unfamiliar with PaaS validation, there are IT consulting groups that specialize in helping pharmaceutical companies validate PaaS.
Concluding Thoughts
ln order for the clinical research industry to be transformed by software and software-enabled platforms, the unique, structural barriers discussed in this article need to be overcome.
But how?
The authors of the Utrecht University paper offer a straightforward insight that can help us understand what needs to be done:
IT often lacks detailed knowledge about the pharmaceutical industry, while the pharmaceutical industry often lacks detailed knowledge about IT.
With the above in mind, I would suggest that the clinical research industry do two things:
- Develop a talent pool, first at the functional level and then at the leadership level, that is as comfortable designing and commercializing software as it is designing and running clinical trials.
- Build clinical research companies that contain within themselves both software development and clinical operations capabilities, run by the leaders from (1).
Accomplishing (1) and (2) above will be very challenging. However, the rewards will be great for those companies that meet the challenge, as demonstrated by other major industries that have been transformed by software and software-enabled platforms.
Galen, S. (2019, December 17). Barriers preventing clinical trial software development. Retrieved February 12, 2021, from https://www.pharmafocusasia.com/clinical-trials/barriers-preventing-clinical-trial-software-development