Clouds or Clods? SaaS in GxP Regulated Laboratories

This blog will discuss some of the regulatory risks involved in using a cloud software service provider, or Software as a Service (SaaS). If you take this route, will you be floating on a cloud or just a clod? A clod is defined as a lump of earth or a stupid person—I leave it to you to decide whether these definitions apply, after you finish reading.

The traditional approach to lab informatics is changing slowly within the conservative pharmaceutical industry: instead of purchasing and operating physical infrastructure together with purchased applications installed on premise, companies are turning to the cloud and virtual infrastructure, and leasing applications as SaaS. SaaS applications that can be used by a GxP regulated laboratory include LIMS, ELN, and even CDS.

Financial Considerations in Cloud Hosting

In most regulated organizations the IT function reports via the Finance Department to the Board. As such, expenditure on IT infrastructure and applications is open and visible to the group responsible for controlling costs. The SaaS approach has several advantages from the financial perspective:

• A move from capital to revenue spend. Revenue spend comes straight off the bottom line rather than a capital depreciation over several years.
• No hardware to install, this is managed by the hosting company or companies.
• Fewer IT staff required in-house to maintain the application; however, the technical contract and service level agreement (SLA) still need to be monitored.
• There is no need to order hardware, as a SaaS application can be designed to expand or contract to meet current needs (on-demand service), if required.

As we are discussing a cloud solution for a regulated laboratory, let us look briefly at what the regulations are for an application from an IT perspective.

GxP Regulatory Requirements

The main regulations for defining implementation, validation, and operation of lab informatics software in a GxP regulated environment are:

• EU GMP Annex 11 regulations [1]
• OECD GLP No 17 Application of GLP Principles to Computerised Systems [2]
• 21 CFR 11, Electronic Records and Electronic Signatures [3], with interpretation by the underlying predicate regulations which are 21 CFR 58 for GLP [4] and 21 CFR 211 for GMP [5]

Annex 11 provides the best overview of IT requirements for a computerized system in a regulated environment: system owner, staff training, physical and logical security, backup, user account management, change control, problem management, and disaster recovery. In addition, both Annex 11 [1] and OECD No 17 [2] permit the use of SaaS applications and provide a requirement for agreements to cover the roles and responsibilities of both parties and define the scope of the agreement.

To appreciate the business and regulatory risks that must be managed, let us look at the situation with a traditional in-house approach.

Same Old, Same Old?

Traditionally, the landscape of IT in a regulated GxP company is:

• Regulated laboratory, e.g., analytical development, bioanalysis, or quality control where the process owner resides
• IT department where the system owner is responsible for:
• Physical and virtual infrastructure and infrastructure applications
• Regulated application installation and monitoring
• Support services for the application, such as application administration and supplier liaison in addition to those listed above
• Quality oversight, which can be a single group overseeing both the business and IT or separate quality functions—one in the business, and a separate IT quality group

All of these functions are within the organization and can be controlled within that organization.

House of Cards?

When moving to a SaaS application for your LIMS or ELN solution, most of the IT operations are outsourced to at least one if not more independent entities outside the direct control of the outsourcing company. The only control that the regulated laboratory has is via a contract, technical and quality agreement, or service level agreement (SLA) that defines the roles and responsibilities of each party and the service levels provided.

But…

• Do you know all parties involved?
• Are the providers compliant with procedures and have staff been trained in GxP awareness?
• Are there records of backup, change control, etc.?
• Do you know where your data are?
• Are you sharing your server with a dating site or similar business with less stringent security needs?

Remember, all you have is a contract and SLA with the service provider.

SaaS Options in the Cloud

Is your arse hanging out of the window, putting your business at significant risk in this situation? To manage risk, you need to understand what is happening with your data. SaaS can mean one of the following options:

• Single GxP entity: a SaaS company that operates the physical infrastructure, generates and monitors your virtual infrastructure, and then installs and operates an application on your behalf; i.e., the supplier is both an Infrastructure as a Service (IaaS) and SaaS provider
• Dual GxP entity: a SaaS company installs an application on a GxP IaaS provider
• Dual partial GxP entity: a SaaS provider uses a major IaaS provider such as Amazon Web Services (AWS), Google Cloud or Microsoft Azure 

We will discuss the third option, as it carries the greatest potential risk, and focus on the IaaS provider first. It will be highly unlikely that the laboratory will be allowed to audit the data center or the organization providing IaaS. Instead, they will rely on a combination of ISO 27001 certification [6] or equivalent plus a white paper, typically written by a third party, which justifies this stance. The problem with this approach is the one major omission: there is no mention of staff GxP awareness training. 

Is this a risk? 

Yes. 

The question you have to ask is, how does the SaaS supplier manage this risk and is that management adequate? Remember the SaaS provider is now your IT department for this application and you are responsible and accountable for compliance and risks to your data.

Do You Feel Lucky?

Risk management is more than the approach advocated by Clint Eastwood’s Dirty Harry. Assessing a SaaS supplier involves more than sending a questionnaire—it requires a multi-level approach to determine the adequacy of the provider’s approach to the following considerations:

• Software life cycle development and support of the application
• IT support services, including qualification of virtual IT infrastructure and GxP awareness training of the supplier’s staff
• Qualification of the application by the supplier and how the application is configured prior to validation by the laboratory
• Software updates, revalidation (discussed below), and change management
• Risk management in dealing with the IaaS supplier
• Agreements with the supplier defining work to be performed during implementation as well as the operations listed above

We will discuss the key topic of software updates now.

Validation Treadmill?

The traditional pharmaceutical industry approach to computerized system validation (CSV) is that once the project is finished there should be no changes to the system, as validation is seen as expensive. This is wrong and this attitude must change, because control of the application is lost when moving to the cloud. Often software suppliers will use an Agile software development model, and this can result in new version releases every three to four months. This is obviously good news for CSV personnel who want a job for life, but a nightmare for companies who will be on a validation treadmill.

A solution is to only use SaaS providers that batch software releases into a single annual upgrade. The upgrade should be accompanied by release notes, to allow each laboratory to understand the changes, update and execute validation documents, and write change requests. The supplier will require you to accept those annual updates, as it is easier for them to maintain the current and a previous version rather than a multitude of versions that only gets larger over time. It is far simpler to upgrade on an annual basis, as changes are likely to be relatively small compared to the big bang when a Dear Esteemed Customer letter arrives on your desk informing you that the current on-premise application goes out of support in six months. This is when your choices get very expensive.

Freedom, or Sentence for Life?

A key aspect of hosting in the cloud is planning for what to do at the end of the contract or when you want to change to a different application and provider in the future. Can you get your data back from the cloud or do you have to keep paying support fees forever? The possibility of de-clouding is a mandatory topic in the planning process, to be discussed both internally and with the SaaS provider. Options should be included in the contract.

Cloud or Clod?

In this blog post I have outlined suggestions for handling the regulatory and business risks associated with SaaS. Prudent laboratory staff should think these through, to avoid becoming a clod.

---

Have you considered a SaaS solution for your regulated laboratory? If so, share with us below how your experience with SaaS has been.

References

1. EudraLex – Volume 4 Good Manufacturing Practice (GMP) Guidelines, Annex 11 Computerised Systems. 2011, European Commission: Brussels.
2. OECD Series on Principles of Good Laboratory Practice and Compliance Monitoring Number 17 on Good Laboratory Practice Application of GLP Principles to Computerised Systems. 2016, Organisation for Economics Co-Operation and Development: Paris.
3. 21 CFR 11 Electronic records; electronic signatures, final rule, in Title 21 1997, Food and Drug Administration: Washington, DC.
4. 21 CFR 58 Good Laboratory Practice for Non-Clinical Laboratory Studies. 1978, Food and Drug Administration: Washington, DC.
5. 21 CFR 211 Current Good Manufacturing Practice for Finished Pharmaceutical Products. 2008, Food and Drug Administration: Silver Spring, MD.
6. ISO 27001 – 2018 Information Security Management. 2018, International Standards Organisation: Geneva.