Clinical Trials in the Cloud (Part II)

The other day I posted an overview of the new OpenClinica Optimized Hosting offering. Since then we have received requests for more detail on how we secure the data in a customer’s OpenClinica instance against unauthorized access. This is obviously a very important topic!

The particular questions were asked in the context of HIPAA–particularly the HIPAA Security Rule–and the answer below is framed in this context. But even if HIPAA is not relevant to you (because you have no PHI in your OpenClinica instance, you’re not part of a covered entity, or you’re outside the U.S.), the safeguards described below are generally applicable best practices and can be applied in the context of most security compliance/regulatory regimes.

In general the requirements of the HIPAA Security Rule can be summed up as:

  1. Ensure the confidentiality, integrity, and availability of all e-PHI you create, receive, maintain or transmit;
  2. Identify and protect against reasonably anticipated threats to the security or integrity of the information;
  3. Protect against reasonably anticipated, impermissible uses or disclosures; and
  4. Ensure workforce compliance.

Adhering to these requirements is generally demonstrated via a risk analysis that determines reasonable and appropriate security measures for protecting ePHI, and implementing administrative and technical safeguards consistent with the risk analysis (see for more info). These safeguards may include:

Administrative Safeguards

  • Implement security measures that reduce risks and vulnerabilities to a reasonable and appropriate level.
  • Limit uses and disclosures of PHI to the “minimum necessary.”
  • Appropriate training, authorization, and supervision of workforce members who work with e-PHI
  • Regular review and evaluation

Technical Safeguards

  • Implement technical policies and procedures that allow only authorized persons to access electronic protected health information.
  • Ensure that e-PHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been improperly altered or destroyed.
  • Implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network.

So how do we do this? Many of these safeguards have long been in place as part of the SOPs and other controls we have for our staff and suppliers. The OpenClinica application itself enforces controls such as password policies, audit history, role based access control, and user access log. On top of these safeguards, what’s notable with OpenClinica Optimized Hosting are the specific controls surrounding this new hybrid/cloud-based hosting environment. Below are excerpts of our new Standard Operating Procedure associated with OpenClinica Optimized Hosting. The full SOP and supporting documentation are available as part of a compliance audit.

Excerpt from SOP-SA002 – Managing Hosted OpenClinica

7.1               Security

7.1.1                       Access to any customer instance is limited, via login credentials, to authorized customer users for the web interface only. Customers have no access to the server itself [except through defined application and programmatic interfaces].

7.1.2                       All OpenClinica employees are granted access only to computer and networking areas necessary to perform their duties.

7.1.3                       Each customer’s installation is separate, and cannot be accessed from any other customer installation.

7.1.4                       Connection to a hosted instance is encrypted by means of secure socket layer.

7.1.5                       Application server and database server are secured via firewall, hardened to remove nonessential access credentials, and strong password compliance.

7.1.6                       Hosted systems are constantly monitored for latencies and intrusion.

7.2.1     Installation qualification is performed on initial setup of the OpenClinica Optimized Hosting environment image, and documented in an IQ Report. Qualification items are checked by inspection, review of vendor documentation, or direct testing as appropriate; items are specified in the Installation Qualification Protocol.

7.2.2     Installation qualification for each customer instance is performed when configuring that instance, and is documented in an IQ Report. Qualification items are checked by inspection, or direct testing as appropriate.

We conduct qualification of our own IT practices and our data center provider to assure security, reliability, availability, performance, and data protection within our hosted services. Items reviewed include:

  • Data Center physical security procedures
  • Data center HVAC, power conditioning, and fire suppression systems
  • Disaster prevention and disaster recovery processes
  • Back-up and data retention procedures
  • Network redundancy
  • Firewalls
  • SSL certificate (encryption)
  • System and network monitoring (for latencies, intrusion, and failure prediction)
  • Load balancing

Our data center has a SAS 70 Type II security certification, a well known security certification that originated from financial industry compliance requirements and aligns well with the requirements of the clinical trials industry. We regularly audit their policies and procedures in the context of our quality system, including review of the SAS 70 Type II audit report they provide. Our data center assures secure and reliable operation in part by maintaining appropriate physical resources at the  facility. Fire suppression, conditioned power, and redundant HVAC all protect computing equipment against damage from extreme conditions, while physical access security and surveillance guard against unauthorized intrusion. The full report is available for our customers to review as part of a compliance audit.

The above are some highlights of our multi-tier strategy to ensure the highest level of security of critical clinical data while maintaining accessibility and ease-of-use. Like any good security strategy, we treat it within the company as a dynamic function, subject to regular review and assessment. We recognize our strategy must always be evolving to respond to emerging threats and new requirements. At the end of the day it is the combination of process and technology controls, and subjecting these controls to continual scrutiny, that leads to strong security.

– Cal Collins

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.

Will the New PHR Gorillas Embrace HIPAA? Taking a cue from clinical research

In April, the WSJ’s Health Blog pointed to an article that asserted that Microsoft and Google were not ‘covered entities’ under the HIPAA patient-privacy law.  Something more interesting than the article itself (from the New England Journal of Medicine), a link in the comments lead to this post, which mentions that insurance company Aetna is also getting into the PHR-management market, with its own systems.  In short, we are beginning to see large corporations grow into the health space with offers to log and store Patient Health Records (PHRs) on internal or external systems.

Great news for the shareholder, you might ask, but what’s this got to do with clinical research?  What’s this got to do with open solutions or clinical trial software?  OpenClinica was originally devised to cover all points of HIPAA, and because of that the amount of personally identifiable information is minimal, and can be removed entirely.

Without proper oversight and auditing, however, these large systems could easily turn into a headache for the end-users, which in Google’s case is the Cleveland Clinic, and in Microsoft’s case is the Mayo Clinic.  Both are large clients with a lot of important PHI.  OpenClinica, in its drive to be HIPAA compliant, also created a set of audits on its database, keeping track of who changed what parts of the clinical research data inside it. 

Microsoft’s HealthVault site has certainly received lots of accolades, and, while the Google Health announcement is not much more than a blog post itself, both pages have something in common; they both state that they are committed to the users’ privacy without ever mentioning HIPAA.  Here is hoping that they are holding themselves to a higher standard.