eClinical 2020-2040 versus 2000-2020

eClinical 2020-2040 versus 2000-2020

As a consumer of software products that accelerate the execution of clinical trials, we frequently need to navigate the minefield of vendors able to meet varying demands that clinical research presents. KCR are an organically growing CRO that specialise in tackling clinical trials that we feel we can perform well. This philosophy also applies to the software products we use when executing clinical trials. Leading edge, but not bleeding edge.

One of the difficulties that all clinical trial software consumers face is to be able to differentiate between the good and the bad solutions. No clinical trial manager wishes to start a study that may run for many years, only to discover mid way through the trial that either the product stops functioning correctly, or, worse that the company behind the software ceases to exist.

This is further amplified by the scale of work that is involved in configuring, optimizing and embedding a cloud Software-as-a-Service clinical research application within an organization. No organization wishes to invest the time and effort into a solution over potentially many years only to discover it must be scrapped and the organization begin from scratch.

The critical nature of this has been further amplified in recent years with the increased use of patient facing technologies such as ePRO or Decentralized Clinical Trial systems. A failure with these type of systems most likely result in a study cancellation due to the direct impact on the integrity of the trial.

Traditional Solutions (2000 --> 2020)

Over the last 20 or so years, we have seen 3 key aspects that determine the success of a software product.

1). The Software

2). The Services and Support for the software

3). The Sales & Marketing

[ Note- I could also add Quality Management, but will keep this simple for illustrative purposes. ]

Software solutions typically have a lifespan where they exist ( the x axis) against the revenue they generate (y-axis). This is often presented in a bell curve for most business software. A balance of the 3 major elements above influence the products longevity and revenue generation potential. Unlike other business areas, in the lifescience clinical research software space, the impact of the sales/marketing and service/support have a considerably greater proportionate impact than the softwares abilities.

No alt text provided for this image

A described in the above chart, a relatively good traditional eClinical software product might reach its revenue generating potential after 5 years unless supported by an appropriate services / support organization combined with sales & marketing. The Y axis represents the relative spend against revenue.

The above profile was demonstrated by Medidata with the core product (Rave 5) being developed from around 2002 until 2007. The services and partner infrastructure began functioning well from around 2006. The Marketing also took off and expanded from 2008. The chart shows cumulative returns.

The model above explains the large number of vendors on the market today. The software solutions are developed in a relatively short space of time, and then are serviced and marketed in order to create a sufficient revenue and extend their potential lifespan, with minimal further development. Traditionally we have seen success based on sales, marketing, service and support rather than good quality software.

Cloud Platform solutions - 2020 --> 2040

Although the model for legacy solution provides some indication of the future, we have different factors at play that adjust the influence and longevity of solutions going forward.

With legacy systems, jumping from a version 1 to a version 2 of a product was a complex painful exercise that was often best avoiding, especially in the context of a running clinical trial. Changes to a software product may impact the status of validation, require new study builds and might even involve significant re-training of staff and users.

Single instance, continuously updated cloud platforms do not tend to follow the same 'big bang' major version number release cycle and as a result avoid some of the bell curve lifespan waves.

The formerly typical big up front software development costs are typically spread over a longer period of time. The continuous, competitive evolution of the product determines the long term success as a cloud platform.

No alt text provided for this image

With this second model, the impact of the strength and functionality of the platform has greater influence, but takes longer to achieve in comparison to legacy solutions - it takes over 10 years for the platform to achieve maturity and correspondingly maximum revenue. Services and Support are less critical as the solutions generally operate as Software or Platform as a Service solutions - the demands are for Knowledge Transfer and Support rather than large scale inhouse service organizational support.

Marketing remains important, but less relatively so over the software platform. This is partially due to the built in sales and marketing elements of the platform itself. Configurable platforms by their nature are 'sticky' meaning they are difficult to leave.

The value of the solution to a consumer grows over time as the knowledge and meta information are built up. Ordering a new study on the platform is as simple as pressing a few buttons. Preparing a study is a matter of leveraging the knowledge and meta information developed since implementation.

In Summary

Successful next generation cloud based eClinical platforms will take longer to emerge but they will exist for extended periods of time. Unlike the more traditional bell curve approach, they will be continuously updated and improved therefore extending their lifespan. Their combined integrated capabilities together with continuously improving feature set will steadily erode the best of breed solutions that have persisted for many years.

Postscript

I would like to point out that a good proportion of platform vendors will fail to meet this 10 year inflection point. This is most typically due to either architectural failures or strategic failures during the development phase. Architectural failures occur when it is determined that the underlying platform is unable to service the functional needs of the solution. Separate systems are built and integrated, or, investment funding is used to acquire other technologies. This results in a sub-optimal hybrid - best-of-breed + platform. This may be countered in part by extending the sales and marketing spend but ultimately, these compromise solutions will lose out in favour of true cloud platform systems.

Great article, Doug. Thank you for sharing your thoughts. I agree that eClinical platforms will not only improve over time, but they will be easier to improve over time.

Really insightful read. It hits on a part of the business side that we don't necessarily talk about often. Do you think that the rise of more educated and savvy buyers in the eClinical market will have an impact? Eg. as buyers become more savvy, due to experience (read: their careers have always included this kind of tech, so they are better at buying it) + access to more openly-shared user-generated information about what they'd actually be getting in to if they purchased XYZ tech (read: forums communities, etc.), it will collectively create pressure to create better products.

回复
Will Crocombe

Research IS/IG strategy and delivery

2 年

My experience is that the software products that do well (for users as well as vendor) are those that engage with users in a meaningful way, and continually invest in improvement. There are several cases I can think of where the initial good product just withers on the vine as the years go by - the vendor makes money and then runs out of steam. Products are also bought and sold, and sometimes replaced. As a user of software, this reliable longevity is important. An EDC system is like a dog: not just for Xmas.

Mark Maclean

Associate Director Data & Informatics at NHMRC Clinical Trials Centre

2 年

Interesting article. I agree with the gist of your argument, and have a few questions / comments: - Are you defining the ‘success’ of a software product mostly on vendor revenue? Also other measures such as vendor ROI, market share, customer perception of value, quality measures, customer ROI, sponsor ROI, …? - Are your models based on data, and if so what? - I agree that platform products take longer to reach maturity. (I’m living that journey as a customer…) Would be interesting to measure and model the changes in ‘success’ over time as functionality grows, particularly from customer perspective.

回复
Ross Jackson

Literally The Man Who Wrote the Book(s) on Patient Recruitment

2 年

Interesting stuff, Doug - there's a definite shift towards cloud platform solutions becoming the norm. Hopefully - as you suggest - leading to the quality of the system being the primary driver of take-up and longevity, rather than success being based on the quality of the sales and marketing efforts.

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了