June 28, 2011
Cloud Computing in Life Sciences
This will be the first of what I expect to be several blogs on this topic as this is the direction technology is headed in. There’s no denying it. IT as we know it is changing. The real question for those of us in life sciences is how and when do we embrace this new technology.
There are three layers of the Cloud to be considered.
- Infrastructure as a Service (IaaS) (Amazon Web Services)
- Platform as a Service (PaaS) (Google App Engine)
- Software as a Service (SaaS) (Salesforce.com)
In life sciences, the easiest one to embrace would be IasS to outsource a company’s IT infrastructure. Who wouldn’t love to get rid of the headache of managing servers supporting an organization and the crazy technical guys and gals doing it. Cloud offers you a ‘pay as you go’ model which allows you to take advantage of significant computing resources, when you need them (not all of the time) without hosting it yourself. Cloud vendors provide you with access to these resources and maintain them in what you would need to verify to be a secure and controlled fashion. One definite benefit here is that these vendors can hire more experts to stay abreast of specific technology issues than most companies can in their own IT departments. It is definitely appears to be more efficient.
As far as Software as a Service, I have real trouble with this in life sciences. While it sounds grand to be able to get rid of all of your IT headaches, how can you outsource the business know-how associated with how your organization needs to use the applications? The efficiencies to be gained in Cloud computing is having everyone do things the same way. I remember how this wasn’t done well back in the ASP days and can’t imagine it working well now. And, no, I am not a fan of hosted solutions either. Not all organizations run their business the same way so forcing organizations down that path as it appears organizations like NetSuite do is not what I would advocate for my clients. It sounds good and seems economical but the price you pay is not just financial. You give up control.
And this is where it gets tricky for life sciences companies: qualification and control. We can’t simply toss it over the fence and let the vendor take care of the infrastructure , servers and applications. Life sciences companies need to demonstrate control over their infrastructure and systems to be able to defend the integrity of their data to the FDA and other governing bodies.
Internally, our organizations need to establish minimums in terms of policies and procedures, and if we outsource, verify the vendor has similar policies and procedures and that they do in fact adhere to them. It’s no different from outsourcing API manufacturing to a CMO. The cloud vendor becomes part of the approved supplier process and is subject to similar audits and monitoring. On site audits need to be performed prior to signing any agreements and specific service and control requirements need to be in place from a contractual perspective. I know of some organizations that have specialized agreements to be included with Cloud vendor contracts covering this very thing.
I know Cloud is the way of the future but I am not ready to advocate this for life sciences as I believe that the model has not matured to the point where we can comfortably eliminate the technical staff or business analysts within our IT departments. The market is still immature and growing so rapidly that the controls are not in place to adequately meet compliance requirements that are inherent to life sciences organizations. This isn’t to say they won’t get there; it’s just going to be a while.
June 22, 2011
Begin with the end in mind
I may not agree with everything Stephen Covey says but I have to admit it truly is critical to begin with the end in mind when developing or implementing a custom application or system in the life sciences industry. One of my clients is learning the hard way about the extra time and money associated with remediating a system to meet compliance requirements and it is turning into a truly painful process for all of us.
What could they have done differently? Planned ahead. This would have meant asking questions not just about what they wanted the system or application to do but how they expected to use the system and the data in the short and long-term. I like to imagine they would have made some different and better decisions had they spent some time up front thinking about these things.
Taking into consideration whether a system or application might be used to capture data for a submission or to support manufacturing processes is critical. If the system or application will do either, then it is critical to build controls into the system, define the electronic records in the system, define procedures to control the system, and seriously consider 21 CFR Part 11 compliance in advance of releasing it into production use. In 2011, it’s rather hard to defend a non-compliant system to the FDA or other regulatory bodies especially when it is critical to the manufacturing or quality testing process.
Remediation is expensive and risky. It’s risky in that you may not be able to get the system or application into compliance and even if you do, how can you adequately rely on the electronic records generated prior to implementing controls? Companies have received 483s for not establishing control over their systems subject to 21 CFR Part 11.
I understand that early stage companies are short on resources and money (generally) and look for ways to defer some activities until there is more money and more time (which there never is). But unless you do the work up front to define the intended use and overall requirements including compliance requirements, in addition to planned life expectancy for the system, how can you adequately assess the potential risk to your organization if you defer activities? Or, if you put in a stopgap solution, do you really thing there will be time and resources to put in another solution once it’s in place and relieving most of the pain points but not satisfying compliance requirements? As a colleague of mine states often, there is nothing as permanent as a temporary solution.
Solutions2Projects, LLC 