Tag Archives: regulatory compliance

When should you own or rent your own cloud (vs. simply sharing one with others)?

We all use cloud computing on one scale or another (from marketing via Twitter to owning our own corporate server clusters). This posting outlines a decision model to help you decide whether you should own, rent or share a cloud to host each of your computing services.

Wait a Minute: I don’t use Cloud Computing

Cloud Computing is simply the process in which one group provides computing services to a group of users in a “turnkey” manner, i.e., in a manner where the end user does not have to worry about how the services are managed, provided and maintained and can get them “on-demand.” In its most basic form, any time you are repeatedly using computing services (i.e., using them without requiring a supporting IT project) that are not hosted on your workstation, you are effectively accessing a cloud of services (vs. twenty years ago when I had to host most of the applications I was using on my own workstation.)


Even when we use a basic email service provided by the guys down-stairs we are using a local cloud of our very own. When we use more universal services like Twitter, we are using a truly global cloud we share with many others. In essence, today everyone is using one form of a cloud or another. The real decisions are–

  1. Who provides the cloud? and
  2. Do I pay for this?

Three ways to obtain Cloud Computing services

There are three basic ways you can obtain Cloud Computing services for your enterprise:

  • Own Your Own Cloud. Your enterprise owns the hardware and the software hosted on it. You manage it yourself, either with staff or direct contractors. You control what is installed in this cloud, when it is installed and how it is managed. Example: your corporate Microsoft Exchange Server
  • Rent a Cloud. Your enterprise licenses services from a Software-as-a-Service (SaaS) provider. This SaaS provider manages these services on your behalf but provides a level of dedication through a managed Service Level Agreement (SLA). Examples: Sales force workflow management from Salesforce.com and Web Analytics from Omniture
  • Share Your Cloud with Others. You sit on an open, freeware service with the rest of the world. You have no dedicated support or SLAs other than what everyone else gets. Examples: IdeaScale for crowd-sourcing or WordPress for blogging (when it is provided for free via your hosting provider)

Deciding how to obtain Cloud Computing services for your enterprise

This is not an “all or nothing” decision, i.e., it is unlikely you will use one model to obtain Cloud Computing for everything you need. Instead, you will need to examine each of the computing services you need and determine whether to own, rent or share each. I recommend looking at three attributes of each service to make this decision:

  1. Importance of this service to your enterprise
  2. Level of Annual Investment you have budgeted for this service
  3. Target of Opportunity the service poses to attack by hackers or competitors

1. Assessing the IMPORTANCE of each service

Not all services are equal. Some are critically important; others are “nice to have.” I have found it useful to organize your services into three priority-based buckets using a simple litmus test for each:


Note: You will find this litmus test dovetails well with compliance with regulations such as SOX (Section 404) and SAS-70.

2. Determining your LEVEL OF ANNUAL INVESTMENT for each

Cloud Computing operates of the Law of Large Numbers, essentially obtaining operational efficiencies of scale through size and passing these along to customers. As such, the size of your enterprise’s information technology and services (ITS) budget for each service (not the raw size of your enterprise) is critical to determining what type of cloud you use. If you have a small ITS budget you may gain more value from renting or sharing a cloud than building and managing it yourself. On the other hand, if you are huge enterprise it may cost- and risk-prohibitive to ask an external party to scale to support your needs. I organize Level of Investment into four categories based on the combined total budget (capital and expense for technology, services and staff) for each service:

  1. Utility (>$10m USD per year). The service is treated as a utility with its own teams, hardware, etc. You are making it core to your business
  2. Infrastructure ($1m to $10m USD per year). The service represents a major infrastructure item for your enterprise. Its investment is likely made up of multiple line items (for hardware, software, consulting and staff) in your annual budget
  3. Budget Line Item ($100k to $1m USD per year). The service has its own line item in your budget (an likely has performance targets to justify the inclusion). However, you are not spending enough to build and maintain a full infrastructure with its own support team.
  4. Expense Item (<$100k USD per year). The service does not likely reach the threshold for capital planning purposes. You do not have (or cannot afford) full-time staff dedicated to managing the service. This could be a service used by a SOHO or for a trial, experiment or campaign)

3. Assessing the TARGET OF OPPORTUNITY to hackers and competitors

Simply knowing the importance and size of your service is not enough to make your cloud decision. You also need to consider the visibility of this service as a target of opportunity. This is important, because visibility directly correlates to risk of attack from hackers. You may have a small IT budget but be a household name who attracts hackers like flies to honey. Here is my simply litmus test to determine you Visibility Risk Level:

  1. Are there competitors (if you are a public sector agency read this as “other governments”) ACTIVELY trying to obtain the information managed by this service? If so, it is a High Visibility Target
  2. If Service is not a High Visibility Target, would a 14-year-old get “bragging rights” if he or she hacked this service? (I recommend asking your children, nephews or nieces the answer to this question.) If so, it is a Moderate Visibility Target
  3. Everything else is a Low Visibility Target

Now we have enough data for a recommendation

Sit down and list all the services you have that require computing support. For each, specify the following

  1. What is its priority: Mission Critical, Operational or Non-Essential?
  2. What is your Annual Level of Investment
  3. What is thee Visibility Threat Level: High, Moderate or Low?

Then look up each on the table below for a recommendation as to how to source your cloud:


General notes, observations and disclaimers:

  • These recommendations skew towards not owning anything for which you are not willing to make a major (i.e., utility-scale) investment. The rationale is two-fold. First, if IT and computing are not your core business, you should not tie up investment capital here (save that for the true reason for your existence.) Second, if you are making small investments you cannot benefit from the law of large numbers (as such, it will be very costly to maintain 24×7, high-availability operations).
  • These recommendations steer you away from using shareware for mission-critical services (with the exceptions of campaigns, trials or small operations). The rationale is simple: you get what you pay for. (Do you really want to place the reliance for the core of large business operations on a freeware application with no SLA?)
  • These recommendations encourage use of shareware for trials, campaigns and experiences–regardless of service importance. Why? This makes trial and error inexpensive. Once you find something that works, you will likely turn up the investment, causing you to upgrade to Rented or Owned services.

Finally, treat this matrix as set of guidelines only. When in doubt, apply common sense and business analysis.

Health 2.0 Challenge: Managing UGC in the regulated environment

Update: I originally posted this in May 3, 2009. I updated this post on July 26, 2009 to add advice in response to calls to action for Health 2.0 — the use of Web 2.0, Gov 2.0 and Enterprise 2.0 technologies to help improve medicine and health care. Its focus now outlines the major HHS and FDA regulations any Health 2.0 service provider will have to navigate to deliver a regulatory-compliant solution

Why this focuses on the management of UGC

Open Collaboration intrinsically involves the collection, moderation and management user generated content (UGC). In general, moderation of UGC is not a simple prospect. Moderation of UGC in a regulated space is even tougher – especially in the very highly regulated biotech, pharmaceutical and health care industries where UGC can now include disclosure of personal health history or inadvertent reporting of adverse events. Based on the sensitivity of any discussion of regulatory compliance, it is worth diverting a little of your attention to some disclaimers and background information:

  • I am not currently affiliated with any biotech, pharmaceutical or health care company. Nor am I affiliated with and PAC or PR firm supporting those industries. I am a Chief Information Officer for an enterprise social networking company, Neighborhood America.
  • Prior to this, I worked at Amgen (the world’s largest biotech.) Most of my tenure here was in their Regulatory Affairs & Safety Operations organization leading a program to scale closeout of clinical trial data and submission of Biologic and Drug Licensing Applications to the FDA (and its global counterparts)–a highly-regulated process–through combined use of process re-design and Enterprise 2.0 technologies
  • Before this, I worked at AOL where I owned many systems subject to compliance with numerous financial regulations (especially Regulations E and FD, and Section 404 of the Sarbanes-Oxley Act)
  • Prior to AOL, I spent nearly seven years Booz Allen Hamilton, Lockheed Martin and the US National Laboratory System where I learned strict adherence to control of information of various classification levels.

I state this so you will understand that, while I am someone deeply experienced in managing compliance of information management, I am not a doctor, FDA or EMEA official or similar certified compliance professional.

What regulations do I need to consider?

The range and depth of biotech, pharma and health care regulations are vast. They cover a wide range of areas spanning how you manage clinical trials to manufacturing to sales and control of patient information. For this reason, it is absolutely critical to ensure you separate the social networking components of your Health 2.0 infrastructure from your other enterprise systems. This directly contradicts what some analysts are calling for in the evolution of enterprise social networking. However, it your do not do this, you will subject your social networking infrastructure to so many regulations that it will be impossible to manage it as an effective network AND maintain regulatory compliance. (My preferred method of this separation is the publish/subscribe model—however, that is a subject of another blog post.)

With this understanding in mind, I am assuming—

  • You are using your social network to manage outreach to bring interested parties into the fold to inform them of where to get information, gather their ideas, priorities and interests, and connect them with other professionals with related interests and expertise and…
  • You are not using your social network to manage clinical trial subject data; drug, biologic or medical device manufacturing data; or safety data

If these are true you have two bodies of regulation to watch in particular:

  1. Title 21 CFR Part 11
  2. HIPAA Title II

In addition, you will need to ensure your social networking infrastructure enables mining and export of UGC to support of your organizations’ pharmacovigilance practices.

Another Disclaimer: Of course, you may have many other regulations to consider based on your unique company and its pipeline and products. I do not need to point out the need to engage your Compliance and Regulated Information Technology teams for a full and complete assessment of your risks and needs.

The impact of Title 21 CFR Part 11 on your social network

Title 21, Part 11 of the Code of Federal Regulations (CFR) deals with the FDA guidelines on electronic records and electronic signatures. In the social networking area this means you must do three things:

  1. Never delete: In general it is bad practice, to delete data. It is much better practice to turn the status of data to “Inactive” or “Archived” so you can find it later (if needed a part of a legal or similar investigation.) To assure Part 11 compliance, you will need to ensure your system does not delete data (and your back office systems administration processes ensure data are archived prior any removal as part of hardware tuning or decommissioning)
  2. Use secure, electronic signatures: Here is where user attribution of UGC is so very important. You cannot let unauthenticated users provide content. You must register and authenticate them first. They you register them, you must confirm their identity (e.g., confirm provided email addresses) and authenticate them with encrypted, strong passwords. You then must attribute all UGC to each authenticated user. (It would also not hurt to get SAFE to review your registration and authentication approach.)
  3. Document that you do this: You will need to demonstrate that you have designed, built and tested a system that does the above. This includes documenting requirements, design, test cases and successful completion of those test cases. It also includes demonstration that your configuration management processes ensure that the code you have in production has completed full documentation of the above before going to production. (For software, this is known as Validation; for infrastructure, this is known as Qualification.)

The impact of HIPAA Title II on your social network

In general, the Health Insurance Portability and Accountability Act (HIPAA) protects the ability for workers and their families to gain access to health care when the switch employers or jurisdictions (i.e., when they move). Title II of HIPPA contains something called The Privacy Rule that governs the use and disclosure of Protected Health Information (PHI). This is where social network—even when they are not used to manage medical information—cross into HIPPA regulation.

Imagine you have a social networking site where patients are discussing places to go for cancer recovery support. On this site, a person starts to discuss their medical history. They list enough of their identity that anyone accessing the site can see that they (or a family member) has certain health conditions. This leads to an insurance company declining coverage to them or a family member when they move jobs due to “pre-existing conditions.” Now you potentially have Privacy Rule compliance risk.

However, you can easily guard against this, if you build the following elements into your enterprise social network:

  1. Make it a closed network. Your network needs to be more like facebook (where you need to be member to see UGC) then Twitter (where everything is open). In addition, you need to apply White List / Black List Rules to enforce who can join the network (e.g., pre-filtered list of doctors or patients and/or blocking of users from specific domains such as insurance companies).
  2. Strictly manage profile information. You need to help your members protect themselves by limiting profiling information. Do not capture any PHI data fields. Strongly encourage Display Names to not include names or other identifiers (this includes either prohibiting Avatars or only allowing members to pick from a list generic Avatar icons). Finally, encrypt all profile information (and – to assure Part 11 compliance – never delete past profile information.)
  3. Moderate all UGC prior to publication. Yes, this slows down the dynamics of your network. However, it protects you and your patients. By moderating all UGC before publishing it, you can protect members from disclosing information that would make maintaining their privacy difficult or impossible to anyone reading their content.

Additional support for pharmacovigilance

The WHO defines pharmacovigilance as “the pharmacological science relating to the detection, assessment, understanding and prevention of adverse effects, particularly long term and short term side effects of medicines.”

From a social networking perspective, this means you need to make provisions to handle situations where someone (inadvertantly) reports an adverse effect (AE) via UGC. This could be real-life AE or a fake AE provided by a malicious member. (Adhering to the six 21 CFR Part 11 and Title II HIPAA recommendations above significantly reduces the risk of malicious AE reporting.)

You should implement the following two items to ensure your social networking supports strong pharmacovigilance:

  1. Moderate all UGC prior to publication. If you are following the HIPAA recommendation above, you are already doing this. However, not only are you protecting patient privacy, you are also monitoring for reported AEs. This lets you both prevent inadvertent publication of malicious reports and detect and direct AE data to you Safety Reporting Systems
  2. House all UGC in a true enterprise data warehouse. Pharmacovigilance does not simply span the processing of AE reports; it also includes the mining of information sources to detect safety signals. By pulling social networking UGC into a enterprise data warehouse and providing your safety monitoring team access to this, you are providing them a new channel to mine and monitor safety information.
While these to recommendations can “sound scary,” following them will let you exploit the social networking medium to create a stronger, timelier pharmacovigilance function and capability.

Should I take the dive into social networking?

I can only imagine how many people are saying, “Social Networking in Biotech, Pharma and Health Care = Unwarranted Risks.” This is a natural reaction to the many challenges imposed by this new and dynamically expanding medium of interaction.

However, social networking is here to stay – not as the “next great technology” but as an expected medium to interact with others. When taking these recommendations in mind, companies, associations, and research organizations can tap this new medium to:

  • Foster greater collaboration on new products
  • Improve internal processes
  • Increase the effectiveness and efficiency managing regulatory compliance
  • Enable doctors and patients to more easily access needed information
  • Increasing the efficiency in the delivery of health care through innovation and collaboration
  • Strengthen post-marketing pharmacovigilance their products

Of course, given the push for Health 2.0 and the agenda of the Obama Administration, you have heard all these arguments. You only need to search “#Health20” on Twitter to find the latest.