Search This Blog

Wednesday, June 10, 2009

eClinical Vendors - Build or Merge

Over the last year, we have seen a spat of eClinical companies either swallowing up smaller players, or, merging.   The recent procurement of eTrials brought this to mind. From a capability checklist perspective, this looks good.   As a sponsor, instead of going to many companies for many systems, they can be procured from a single source. If problems occur with a system, there is only one number to call.  If the systems aren't speaking, then no finger pointing - the single vendor is responsible.

However, with today's eClinical systems demands, I believe some challenges exist particularly related to scalability and metadata management.

In former days, where Client/Server solutions were the norm, and, the cost of setup and integration was just an understood overhead of working with eClinical systems, mergers made a lot of sense.  It often took months to fully configure a platform, carry out validation and adjust the configurable settings to make it work as required.  If the system came from 2 sources versus 1, it didn't really mater as much, as it was expected that it would take considerably time and cost to make everything work anyway.

The technology landscape today is very different.  In a Software or Platform as a Service model, sponsor companies are looking for a number of capabilities that can potentially conflict with the abilities of separate products coming from different sources.

How long should it take to setup an eClinical product so that it is ready to be configured to support a clinical study?  3 months, 1 month, 1 week, 1 day?     In a capacity managed, multi-tenanted Platform as a Service environment anything more than a day is too long. Organizations are increasingly expecting instant capacity support, and immediate responsiveness.

Let us imagine a hypothetical case study. 

A company has developed a nice multi-tiered Java EE web app, with horizontal scalability - things are looking good...  the operational configuration and management of the platform has reached a point where an instant 'on' is a reality for clients. There is a single location for user and metadata management. Security is looking solid, a development plan is in place to expand and extend the core software... and then bang...

... a merger occurs...  The companies IT Hosting group are handed an entirely new platform to co-exist with the current platform... the R&D group inherit a new technology.  This one is .Net, on a different database, using a different app and web server.   Both applications are large and complex - a complete re-design is out of the question.  So, what next?

Well,the first thing that might happen is that the systems are made to appear integrated.  A common User Interface, often called a 'portal' is created that gives the impression that the independent systems are operating closely together.

Next, an interface.   Integration would be nice, but, as the two products were designed in isolation, they don't share a common architecture or platform stack, so, an interface is the only viable solution.  Both products are not standards interface based so hard-coded bi-directional feeds as put in place.

Ok, so they share an access point, and, they share data, but, do they provide an effective solution?

CDISC & Standards

CDISC may offer potential to organizations that choose to buy rather than build.   One of the key objectives of the CDISC standards are to achieve cross system interoperability.   If the disparate systems are capable of offering CDISC ODM integration - both data and metadata - then the challenge may be less steep. 

We are also seeing the emergence of Web Services, often leveraging CDISC standards, that in theory will allow the non programmed bi-directional interchange of data and metadata between supporting systems.

The question though ultimately is, will the resulting systems deliver solutions in the way the customer wants a solution, or, will the the customers end up with having to work in a convoluted way, because that is they way the systems came together, and that is the way they need to work.

I will not expand on this commentary for now as I am interested in hearing experiences from those that have faced, or are facing these integration challenges.

No comments: