Microsoft Azure in Life Sciences: Qualifying the Cloud (IAAS / PAAS)

Moving to the Cloud in Life Sciences

As life sciences companies, especially biotech companies, become more and more virtual, they are shifting (or have shifted) to the cloud for applications and infrastructure. It’s the right thing to do, especially since most don’t appreciate the value of technology in optimizing business performance and getting to market faster (separate rant).

Simply throwing the responsibility over the fence to the vendors does not relieve a life sciences company of its obligations around ensuring data quality and integrity.

Savvy life sciences companies know this and qualify their underlying cloud infrastructure, whether on AWS, Google Cloud Platform (GCP), or Microsoft Azure.

The qualification process is more than a compliance activity; it can provide value to the business in demonstrating system and process controls, and ensure data integrity. It’s all about the data, after all.

In this blog post, I share my recommendations for qualifying Microsoft Azure. I will cover the same for GCP in a separate post.

IaaS, PaaS, SaaS

For the purposes of this post, I am focusing on IaaS and PaaS, and not SaaS. For validating a SaaS solution, check out this post from 2018 and this post from 2019.

Some Basics and Assumptions

Qualification versus Validation

In this post I will use the terms synonymously but generally speaking, you qualify infrastructure and you validate applications for a company’s intended use.

ISPE GAMP5

I am a GAMP girl so my qualification approach is based on the International Society of Professional Engineer’s guidance documents as detailed in GAMP5 and the associated guidance documents.

CSV versus CSA

FDA released its draft guidance on Computer Software Assurance for Manufacturing, Operations, and Quality System Software and while it was expected to be finalized in 2020, it is now on the docket for fiscal year 2021 per FDA’s Center for Devices and Radiological Health (CDRH).

The guidance document is intended to shift validation approaches from CSV (computer system validation) to CSA (computer software assurance). If you’ve been following a risk-based approach (as defined in GAMP5) and have been using your noggin to focus on intended use and the value add to the business, there’s not much of a shift.

Risky Business

Two years ago I qualified GCP for a client (blog post to come) and followed a similar approach for Azure for another client this past year.

It may appear to be largely a documentation effort but it’s more than that. It’s all about defining what is needed for the business, executing against those requirements, documenting the baseline, and maintaining the platform in a controlled fashion.

With IaaS and PaaS (and SaaS), there is a lot of reliance on the vendor, and therefore the customer (the life sciences company) needs to oversee the vendor and the platform to ensure an acceptable level of control based on the company’s risk assessment and risk tolerance. To not do so is a risky business and compliance proposition.

Risk-Based Approach

A risk-based approach was the best thing to happen to computer systems and software when GAMP5 was released. It meant that we could prioritize what we focused on, company by company, system by system, process by process.

This also meant that those folks who liked to apply a cookie-cutter approach to computer validation had to start applying critical thinking to their validation / qualification efforts. It’s not easy if you just want to check boxes and follow checklists.

A risk-based approach offers up flexibility for companies leveraging software and technology. It is not a one-size fits all approach.

Azure Qualification Approach

This isn’t rocket science but if you have not been through a qualification or validation effort, this will be challenging as there’s a steep learning curve. I have yet to figure out how to get my clients to understand this process until after they’ve gone through it. Expect some discomfort as you go through it for the very first time.

What is Microsoft Azure?

Microsoft Azure is cloud computing services (IaaS, PaaS, SaaS) deployed through Microsoft managed data centers. The companies I work with rely on it as the virtual backbone for virtual machines and other Azure assets to support business applications, databases, and web deployment.

It’s essential a virtual data center in the cloud.

Above and Below the Line

I draw the line at the virtual machines. Anything above that line is at the application level and should be covered under those application validation plans and activities. Below the line is in scope for the Azure platform.

If we think in terms of a bare metal data center, IT historically commissioned the servers and prepared for application and database installation.

This typically included installing things like the operating system, anti-malware software/tools, monitoring tools, backup software or agents, and other baseline tools used by IT. This is all below the line and what I consider in-scope for the qualification of the Azure platform.

Then it’s handed over to the folks managing the application project. What they do, even with the help of IT, is above the line.

Deliverables

Remember, if it’s not documented, it didn’t happen. I highly recommend that all of the validation deliverables be approved and stored in the company’s validated document management system (eDMS).

— GxP assessment for the Azure platform based on its intended use and what is expected to reside on the platform

— Risk assessment for the Azure platform and determination as to whether to audit Microsoft for Azure

— Vendor qualification asessment and possible (paper) audit

— Validation plan for the Azure platform

— Functional requirement specification (combined FRS/FRA/TMX document)

— Functional risk assessment (combined FRS/FRA/TMX document) for the Azure platform

— Technical specification documents for the platform and the virtual machines and other Azure assets on the platform; these provide baseline documentation for operation and control and are created after the migration or the platform / virtual machines / other assets are configured or installed.

— Migration plan or protocol including verification activities

— Executed migration and supporting documentation

— Migration plan summary report

— Testing summary to document any verification activities performed whether automated or manual

— Traceability matrix (combined FRS/FRA/TMX document)

— Procedures (SOPs) and work instructions (WIs) to operate and maintain the Azure platform in a controlled fashion

— Trained administrators on the platform and SOPs/WIs

— Trained personnel on the SOPs/WIs

— Validation plan final report

What is not on the list?

— Installation Qualfication (IQ): there’s nothing to install and therefore nothing to verify

— Operational Qualification (OQ): if you are focusing on qualifying for intended use, performing an OQ provides no added value

— Performance Qualification (PQ): we can debate whether this is necessary or not. My clients have decided not to do any verification testing on the platforms (Azure / GCP) and have left the verification testing to the application layer. Or they have performed automated and manual testing and have summarized in a document that they approve and store with the validation deliverables.

Procedures and Work Instructions

Assuming the SOPs are in place to support validated systems (computer validation, SDLC, change management, backup/restoration, deviation management, training, security/passwords, monitoring, etc.), the following should be considered at a minimum:

— MS Azure Platform operation and maintenance procedure including monitoring

— Work instructions to support the platform administration including administration of virtual machines and other Azure assets, backup and restoration, user and security administration, etc.

Timeline

The timeline of the activities will depend on where/what you are migrating from (assuming you are), what is being migrated, the impact to the business, and the available resources to work on the configuration, migration, and qualification project.

So, it depends.

Recommendations

Some words of wisdom based on my experience with these qualification and migration projects:

— Work with an experienced and well-referenced Azure vendor (assuming you are working with a vendor) who understands CSV/CSA

— Work with an Azure vendor who will detail their activities and assumptions in their statement of work before you start the project. Trust me on this one.

— Create the timeline of activities and include the qualification tasks in a single project / project plan. The vendor will only care about their portion but there’s a lot more to it than the technical activities.

— Train the team on what to expect with the qualification activities and the post-migration activities. It won’t make 100% sense at first but it will at the end.

— Have the SOPs/WIs in place prior to the migration and the production cutover.

— Be flexibile. Things will not go 100% to plan. Apply critical thinking to address issues as they arise and continue to focus on the goal(s) of the qualification effort.

One Final Note

Qualification and validation do not end after the project is over. It starts at the beginning with a kernel of an idea and goes through to retirement.

Don’t forget to operate and maintain in a controlled fashion your beautifully qualified Azure platform.

Still Have Questions or Need Some Help?

Feel free to reach out to me with any questions you might have via email at terri.mead@solutions2projects.com or through my website SolutionsProjects, LLC. I’d be happy to have an initial call, free of charge, to discuss your qualification project.

Related article: Solutions2Projects, LLC