Clinical Research and the Cloud…two great things that don’t go together (yet).

Cloud computing seems to have become the best thing since sliced bread for most startups. With the arrival of Amazon Web Services and Google Apps, we have seen the rise of “pay-as-you-go, on-demand basis” for all aspects of IT infrastructure, including storage, servers, and processing speed. Already several startups have bet the farm on the cloud to pay off (Heroku is one example, joined by Twitter, SmugMug, and Scribd). Bigger players have also banked on cloud computing: Apple’s MobileMe service is the most recently cited example of working with consumers in the cloud.

Earlier this month, I read a post over at GigaOM entitled “10 Reasons Enterprises Aren’t Ready to Trust the Cloud“. The article busts through a lot of the gee-whiz aspects of cloud computing and brings us back to reality. Some of the points the article makes include:

  • Security – this is the big issue. The article even goes so far as to mention HIPAA by name, since it is that important for PHI, including clinical data.
  • Lack of auditing – another big issue, especially in the clinical trials space.
  • Reliability – what happens when it goes down? More on that issue in a moment.
  • It still has to exist on a server somewhere – what are the legal complications of hosting PHI in a server farm that could be in say, Russia?
  • And oh yes, it still has to be fast – as the article says, “the need for speed still exists” in companies, and not all of the cloud can address that issue.

This piece was eerily prescient, because after I started a draft of this post, Amazon E3 went down, taking with it several Web 2.0 startups, including the aforementioned Twitter, Scribd, and SmugMug. This is the second big failure this year for them, so Amazon’s cloud computing is definitely starting to get bit by the ‘reliability bug’. It’s worth pointing out that this is not the first time we’ve been taken with technology that operates on a cloud-like principle that blew up in our faces, as one blogger points out the linkage between Amazon in 2008 and Bell Systems’ failure in 1990.

So where do we go from here? Cloud computing is definitely becoming a huge trend for the enterprise, but not ‘prime time enough’ for something as mission-critical as clinical data. As an aside, our hosting plan is entirely under our own control and nothing is given up to an external system for reasons which are now painfully obvious. However, the most recent announcement by HP, Yahoo and Intel to launch the Cloud Computing Test Bed is proof that all is not lost when you bet on the cloud.

But the clouds will keep on rolling, and we, we’ll keep on watching (underneath an umbrella).

PS – Apparently, MobileMe hasn’t been doing so well either. So, if we ever do cloud computing in the future, we’ll have lots of mistakes to learn from.

PPS – A pair of passionate posts on Cloud Computing have been written recently by Hugh of Gapingvoid fame: they are here and here: “We’re potentially talking about a multi-trillion dollar company. Possibly the largest company to have ever existed.” He certainly sparks up the idea more than I have.

Validation and Compliance with Open Source Clinical Trial Software

We are often asked, “if your clinical trial software is open source, how can it be validated”? The answer is that, like with many other things open source, you have multiple options.

If you choose, you can validate the product yourself from the ground up. This involves defining your requirements, generating and executing test cases that are traceable to those requirements, and doing all this within the framework of well-defined change control and quality management systems. Since you have access to the source code, you might include design and code reviews as part of this process, especially if you are modifying the core distribution or applying patches. If your requirements are highly specialized or your implementation has been extensively customized to integrate with home-grown and legacy solutions, this might be an attractive option. Be warned however – this approach is time consuming and requires the generation of extensive documentation.

As an alternative, we offer a Validation Support Package to our OpenClinica Enterprise customers comparable to what you would expect from a proprietary software vendor. The validation support package provides access to documentation on the Akaza quality system and the OpenClinica Enterprise solution. For example, Akaza maintains a comprehensive SDLC (Software Development Lifecycle) controlled by Standard Operating Procedures, and each release undergoes comprehensive system testing and deployment testing according to a detailed test procedure and a controlled, documented testing methodology. Quality System and testing artifacts are available for auditing and inspection by customers. Customers receive access to test scripts and system requirements specifications, and may tailor these test scripts to their own needs, making them traceable to their business requirements, and executing performance qualification of their OpenClinica systems. A document specifying how OpenClinica complies with 21 CFR Part 11 requirements is included in the package as well.

At last year’s DIA Annual Meeting I hosted a panel that included two very knowledgeable colleagues on this topic, entitled “Utilizing Open Source Software in GCP-Compliant Environments”. We’re doing an updated, slightly broader version of the session at this year’s meeting in Boston in June: Utilizing Open-source Software in Clinical Research Environments. I’ll be sure to post the slides here after the meeting, and if you’re at the event please come by.