ClinOps Digital Transformation: Tips For Getting It Right The First Time
By L. Allen Kindman, MD
“The only constant is change.” — paraphrased from Heraclitus, 500 BCE
Clinical trial operations are complex and continue to become even more so with each passing year. Trial designs and the regulatory environment are getting more complex. Consequently, operations are increasingly complex. To navigate the labyrinth of the modern clinical trial, virtually all trial operations are now completed with digital tools. These systems have evolved and will continue to do so as they become more seamlessly integrated with site electronic medical records, local or central IRB, lab, sponsor, and other vendor systems.
All of this means continual change, especially now that AI is being more widely adopted in clinical trial operations. Sadly, despite the digital “revolution” being more than 70 years old and continuing to accelerate, digital transformation continues to be challenging. The same mistakes continue to be made. That does not need to be the case. Here, I outline some of the problems I have seen over several decades of digital transformations involving small and large companies in different sectors of healthcare and have heard about from colleagues across pharma and clinical medicine. My goal is to encourage organizations seeking to transform their operations to ask the right questions. Although many of these points may seem self-evident, operations teams commonly overlook them.
What’s the return on investment (ROI)? Priorities need to be aligned and to do so it’s necessary to determine the potential ROI. Seek help from corporate finance to be sure the institutional pain points are being addressed. But also consider how a new platform could improve the quality of work produced (better data quality, more granular insights, greater confidence in choices made, faster time to insight, and others) and try to put a realistic value to these. Also, consider simply assessing whether each of the current activities the new platform will replace must be completed in the first place. This is an instant win on the current workload and potentially reduces the requirements for the new platform.
Carefully consider whether an off-the-shelf solution exists. Even though your company’s approach to a specific issue may differ from commercially available solutions, it’s worth examining closely whether your company’s current approach is so much better that it’s worth building from scratch, rather than switching to a commercially available, validated solution with technical support that may be customizable and provides ongoing system updates. Consider whether external solutions can be readily integrated into your company’s work and data streams. Often, the answer to this is “yes.” Consider the needs not only of the direct users but of the upstream and downstream employees who will interface with the team benefiting most from the new technology. Will the new application also improve their work, or would it create unnecessary work or increased complexity for other parts of your organization?
Decide whether to keep development in-house or to outsource it. This will depend on your company’s size and business strategy. For example, building a sophisticated AI-powered application or highly tuned large language model (LLM) requires a degree of expertise that most companies not devoted to AI product development do not have readily available in-house. If your company does not already have the internal expertise, then an external solution is more appropriate. If a new team has already been hired with the goal of reimagining the company using AI, plan to become their “best friend” but realize that they will likely already have high-priority corporate commitments.
Prepare for a learning curve. If a product is in-licensed, understand that it won’t look the same as your current internal applications. Invest time to determine what it will and won’t do well. Decide if those trade-offs are worth the change and if the vendor is sufficiently resourced to provide customizations that are essential for operational efficiency. However, if the application does not allow you to deploy what you believe is your “magic sauce,” think long and hard about committing.
Your new solution might also become a product. If you build an application, always consider the possibility that the software you create could turn into a marketable product. This is especially true if your company already sells software in your industry. There are examples across biopharma where competitors buy applications from others, particularly if their mutual clients also use it. Of course, guardrails could be put in place to protect both sides. If it’s a successful product, it becomes a profit center of its own.
Better, but not always cheaper. Choose or design software with the idea of doing your work more efficiently, not necessarily with the idea of reducing costs. Quality will improve and workers are happier when they can focus on what they do best and are rewarded for it — and productivity will increase. There are faster, easier ways to reduce costs if that’s the only interest. Resist decreasing headcount until your new software is actually in use and demonstrating productivity increases (again, never over-promise!). These types of programs should not be expected to grow profits but rather should be viewed as investments in quality and long-term operational efficiency. Consider, however, that with improved efficiency and quality, it may be possible to create offerings that previously would not have fit within a team’s core mission.
Keep all users involved. Make sure the user community is intimately involved in designing the new product. Regular product showcases where new developments are revealed to users and publicly updated timelines are very helpful. Feedback from the community should be sought and integrated into the program, wherever feasible. This should be the case whether software is built internally or if a vendor is custom-building a product.
Hold the software architects and project managers accountable. Find development metrics that are measurable and meaningful to all stakeholders; avoid sandbagging and recurrent target misses. If your engineers are suddenly pulled into another (unrelated) project, protest loudly.
Likewise, hold your end users accountable. Engineering project managers should hold end users accountable for prompt and useful feedback and guidance. There are two reasons for this: First, engineers and project managers should expect that the end users’ ideas will evolve as application development progresses (but at some point, further evolution will need to wait for the next version of the software). The second reason is that coders who work in complete isolation from their end users may lose touch with the end users’ needs. As a result, the end user may get what they are asking for, but it may not be what they really need. Thus, the best way to minimize this risk is through a close relationship between the end users and the development team, coupled with using an agile software development approach.
End users should not settle for a replica of their prior technology. Don’t replace a macro-enabled Excel spreadsheet with a system that does exactly the same thing — only in the guise of an app. You will lose the near-infinite flexibility of Excel. And you won’t gain the ability to take advantage of AI. Make the new system or application do more, connect more, and think more. That’s how real value will be created.
Not just new, but better. Nothing should be put into production unless tasks completed on the new product do not take more time than spent using the existing methodology. This is a sure way to alienate users. A few future users should volunteer (or be “voluntold”) to work in parallel with new tools. This is the best way to determine whether the new application can accommodate a wide range of scenarios.
Performance is everything. Most bottlenecks are due to poorly considered user interfaces, software bugs, or unanticipated hardware and software conflicts. The interface should be “consumer grade” so that everyone loves to use it. If you wait for the results of user acceptance testing to find this out, it’s too late. Also, users need to remember that they don’t need to understand all the nuances of how the software works, especially when it comes to AI. Like the GPS on their smartphone, they just need to know that it will work for them and be reliable.
Tech is never “one and done.” Software rapidly becomes obsolete if not continually updated. Needs will change and new ideas will emerge both in information technology and in your company’s priorities. Technology debt will build up if the architectural underpinnings are not continually updated to meet new business needs including contemporaneous hardware, application programming interfaces (APIs), and operating system needs. If there is no planned budget for continued evolution, think twice before proceeding. Some of the most unpleasant conversations I have had involved an IT leader, a business user leader, and the realization that no budget was available for needed improvements to the product.
Finally, and probably most importantly, avoid the clinical versus technical schism. Pharma companies that hire a new group of software engineers and technologists to accomplish a digital transformation — but don’t properly integrate this new team with their incumbent clinical and cross-over workers — lose a golden opportunity for synergy. The same is true for tech companies that dive into pharma by hiring a team of clinical experts without integrating them with their engineers. The software engineering and operations cultures and languages are very different. The path to success of a software development project always goes through tight integration and partnering and usually takes 12 to 18 months. But with top-down example-setting, this can happen much sooner. Start by assuming good intentions. Senior leaders of both teams should communicate regularly and present together regularly to combined meetings of both teams. Cross-shadowing and “buddying” helps both groups develop relationships they can quickly tap into when questions arise or advice is needed. Budget time to allow this.
These are a few of the issues you can expect when digital transformation is essential to a company’s future. Software engineers do not need to become operations experts and operations experts do not need to become software engineers. Don’t be afraid to ask questions and insist on your seat at the table. AI may be the latest wave of transformation that is already overwhelming us with change. It won’t be the last.
About The Author:
L. Allen Kindman, MD is a cardiologist and real-world data analytics expert. He consults with emerging biopharma and device companies on clinical trial design and operations and is developing generative AI/large language model based-tools to make clinical trial design and medical writing more efficient. He was a vice president in the Applied Data Science Center of IQVIA, where he led a global team using real-world data and machine learning to plan clinical trials. He has led or contributed to digital transformation programs in clinical and hospital practice and biopharma/pharmaceutical R&D.