selecting implementing and maintaining cloud systems for the life sciences industry

Selecting, Implementing and Maintaining Cloud Systems for the Life Sciences Industry

www.usdm.com A White Paper Published by USDM Life Sciences 1

Selecting, Implementing and Maintaining Cloud Systems for the Life Sciences Industry How to utilize your Cloud Supplier’s expertise, quality management systems and processes in the real world – to add value to your implementation project and live system usage.

A White Paper by: David Blewitt, Vice President of Cloud Compliance, USDM Life Sciences December, 2015



Table of Contents

Selecting the Right Cloud Provider… ....................................... 4 Identifying Your Own Inefficiencies ......................................... 7 Traditional Problem Areas ........................................................................................... 7 Why Do We See These Issues? .................................................................................... 8 What's Worked Elsewhere (And What Hasn't) ............................................................ 9 By Way of Risk and Cost Reduction- What's Appropriate, What Isn't, and How Do I Determine the Difference? ......................................................................................... 10 Utilizing This Information ......................................................................................... 12

Critical, Key, and Desirable Supplier Elements ..................... 12 Critical Supplier Elements ......................................................................................... 13 Key Supplier Elements............................................................................................... 13 Desirable Supplier Elements ...................................................................................... 13 GxP Functionality With Cloud Solutions? - Why it Makes Sense Now .................... 13 The Benefits of Cloud Computing ............................................................................. 14 Overview of Cloud Architecture, Security, and Infrastructure .................................. 15 Public, Private, or Hybrid? ......................................................................................... 15 Cloud Architecture: Single vs. Multi-Tenant ............................................................. 16 The Power of the Cloud ............................................................................................. 18

Maintaining the System and The Supplier Relationship ....... 22



Copyright © 2015 USDM Life Sciences All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owners. Simplify, Unify and Optimize™ and USDM™ are trademarks of USDM in the United States and other countries. All other trademarks are the property of their respective owners. All other brand, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners. Document Title: Validation Considerations for Mobile Devices in Life Sciences Applications Published by USDM Life Sciences, November, 2013

Any comments relating to the material contained in this document may be submitted to:

USDM Life Sciences, LLC 535 Chapala Street Santa Barbara, CA 93101

or by email to: [email protected]



The intent herein is to give an overview of how to actively utilize your Cloud Supplier’s expertise, quality management systems and processes in the real world as a true value add to your implementation project and live system usage.

Executive Summary In the past, it has been difficult for some organizations to adopt a real, useable approach to leveraging supplier documentation and activities to reduce their communication, qualification and ongoing maintenance burdens. Time and again suppliers are selected merely on the basis of initial cost and time, without true considerations given to risk based factors that could truly reduce short and long term risks and financial burdens, as well as project and live system efficiency. The intent herein is to give an overview of how to actively utilize your Cloud Supplier’s expertise, quality management systems and processes in the real world as a true value add to your implementation project and live system usage. Furthermore – The answer to a very common question that often comes up – “How can I ensure my cloud system is implemented in a compliant manner, and is maintained during the constant state of flux seen within the cloud?”. Leveraging supplier’s activities is not just about reducing testing burden on you as a customer. There are many other aspects – explained herein, that should also be considered to gain true value. Finally, one of the main goals here is to help you identify the types of questions you should be asking yourselves as an organization when identifying your suppliers.



As most readers of this publication will know, for the past few years, and certainly since the latest version of the GAMP® guide – GAMP® 5, it has been recommended practice for Life Sciences companies to include leveraging supplier’s activities in their quality practices and project methodologies. Time and again suppliers are selected merely on the basis of initial cost and time, without true consideration given to risk based factors that could truly reduce short and long term risks, financial burdens, as well as project and live system efficiency.

Selecting the Right Cloud Provider… As most readers of this publication will know, for the past few years, and certainly since the latest version of the GAMP® guide – GAMP® 5, it has been recommended practice for Life Sciences companies to include leveraging supplier’s activities in their quality practices and project methodologies. As can be seen below, it is in fact one of the key concepts of the guidance.

This has never been truer than with the recent uptake in the numbers of companies choosing to utilize cloud systems and vendors to accomplish their business processes. So why has it often been difficult for some organizations to adopt a real, useable approach to leveraging supplier documentation and activities to reduce their communication, qualification and ongoing maintenance burdens? Time and again suppliers are selected merely on the basis of initial cost and time, without true considerations given to risk based factors that could truly reduce short and long term risks and financial burdens, as well as project and live system efficiency.



“How can I ensure my cloud system is implemented in a compliant manner, and is maintained during the constant state of flux seen within the cloud?”.

The intent herein is to give an overview of how to actively utilize your Cloud Supplier’s expertise, quality management systems and processes in the real world as a true value add to your implementation project and live system usage. For example to help you understand how companies ensure they select a supplier which will not only provide a quality product and customer experience initially, but will be in a good place to ensure that that product can be maintained in a qualified state throughout its lifetime. Furthermore – I am to answer a question that often comes up – “How can I ensure my cloud system is implemented in a compliant manner, and is maintained during the constant state of flux seen within the cloud?”. It should be noted of course that leveraging suppliers activities is not just about reducing testing burden on you as a customer. There are many other aspects that should also be considered to gain true value. These are explained below, along with real world methods for achieving that value.



In order to derive these internal questions, you need to first ask yourselves how and why you are going to use this information to reduce risk and costs internally.

Most issues do not arise until the equipment is actually delivered and installation begins (and sometimes even earlier with delivery deadline issues) and the discussions arise over increasing costs and slipping schedules.

Identifying Your Own Inefficiencies In order to derive these internal questions, you need to first ask yourselves how and why you are going to use this information to reduce risk and costs internally.

Some real world answers to these questions have been provided below, but what should be clear is that once you’ve identified these answers, you can use the results to derive your internal set of requirements when identifying cloud potential suppliers, as well as to drive the communications process with those suppliers.

Traditional Problem Areas One of the most common problems with trying to leverage your suppliers own activities, is that you don’t know what you don’t know. This is certainly the case for companies that are not as mature when it comes to their System Development Life Cycle (SDLC), but in all companies the precise problems they are likely to encounter aren’t really available in a manner that’s easy to grasp. Most issues do not arise until the equipment is actually delivered and installation begins (and sometimes even earlier with delivery deadline issues) and the discussions arise over increasing costs and slipping schedules. The majority of the example issues shown below relate to the implementation and development of the system rather than logistical problems – such as delivery issues – although these types of issues will also be reduced by



following the guidance given herein. Typically seen issues during system implementations/rollouts or upgrades are;

• System delivered cannot be customized readily or is not a simple out of the box system that meets your needs as is

• The documentation provided around certifications and verification activities does not fit with your quality plan and testing strategies – examples include;

o Lack of up to date installation instructions – may relate to older versions or versions that are not complete or easy to follow

o Lack of (or incomplete) testing scenarios and scripts (and therefore not useable in your risk based testing strategy to reduce time and costs).The supplier is either unable to provide useable verification documentation (for installation and functional testing phases), or is in fact unwilling to provide it as it is not contracted for.

o Certification evidence (e.g. 510k) relating to the latest and greatest version of the system you are purchasing

• Supplier is unable or unwilling under current contracts to provide assistance with requirements gathering, risk assessments, the creation of functional and other specifications, system configuration and installation and testing as needed.

• Support and maintenance processes are not established as part of a Quality Management System and therefore cannot be assured

• Some documentation, standard technical and configuration specifications for example, may also be seen by the supplier as proprietary - and they may be unwilling to provide it. This type of documentation can be used to help build up the full system picture, document the system configuration (which you as the system owner are responsible for), enable test activities and configuration management as well as enhancing the change control process.

Why Do We See These Issues?

• Supplier audit procedures are either not established (as part of your own QMS) at all, or are not sufficient to cover the types of issues described above

• Insufficient consideration given to the suppliers own QMS – how mature is it, is it available for review, do they have any quality certifications, are they willing to provide examples upon request, are the communication, change control, upgrade and issue resolution processes understandable and in line with your own expectations and requirements?

• Requirements management processes not effectively designed leading



Establishing a supplier assessment and management process following recognized guidance (e.g. GAMP5 section 7 and Appendix M2) prior to the instigation of new system selection, implementation or upgrade projects has shown repeatedly to significantly reduce costs, time and issues.

to incorrectly or incompletely defined system requirements given to the supplier for items including;

o System Installation instructions (and IOQ Plans/Templates) o Incorrect system specifications around system size, response

times, processing power o Interface considerations – how readily will the new system

sync with your current infrastructure, how standard are the interfaces required, how do I get my legacy data from my old systems into my new system?

• Minimal/no requirements defined for the precise types of documentation available relating to verification activities already undertaken by the supplier, including;

o Full set of test evidence as well as templates for all standard configuration items

o Example use cases/Business Process Flows for standard processes, to be utilized when developing user/functional and technical specifications as well as verification scenarios.

• Contract negotiations did not include the purchasing of configuration and technical documentation, with appropriate non-disclosure clauses

What’s Worked Elsewhere (and What Hasn’t)? Establishing a supplier assessment and management process following recognized guidance (e.g. GAMP5 section 7 and Appendix M2) prior to the instigation of new system selection, implementation or upgrade projects has shown repeatedly to significantly reduce costs, time and issues. Of course this process should be part of your own Quality Management System. It is no good ensuring your supplier has everything in order if your own processes are not in place (including your own requirements management process). You should also know the types of system interfaces you will require, what data needs will pre-exist and whether you intend to host your own system or utilize the cloud or a third party host (or at least have these as considerations). The process should call for clarification (in the form of documentary evidence) from the supplier that they can meet your specific needs as a customer. This evidence should include;

• Mature Quality Management System processes – established according to a recognized practice – (e.g. ISO9000) – including support, change control, communication and maintenance procedures

• Other system user references and testimonials (to enable comparisons of the suppliers, as well as gauging the system’s ease of customizability).



The provided documentation should be assessed for suitability, accuracy and completeness. There should of course be flexibility regarding acceptable format, structure and documentation practices.

• Current certifications – including the qualification dates, relating to the system version you are considering

• Installation instructions and IOQ’s – relating to the correct version of the system under consideration

• Functional and requirements specification examples • Training records for appropriate support staff • Testing Scenarios/Scripts – executed, reviewed and approved by the

suppliers quality organization, showing the testing of standard configuration has been completed successfully

• Establishment of precedents showing willingness and ability to participate in risk management activities

• Ability and willingness to provide (standard – i.e. as delivered) configuration documentation for all areas of the system

The provided documentation should be assessed for suitability, accuracy and completeness. There should of course be flexibility regarding acceptable format, structure and documentation practices. Satisfactory answers and documentary evidence can be used to justify using the suppler documentation as a means to reduce your qualification efforts on your side (utilizing a risk based approach to implementation and qualification), as well as ensuring that you know the system can be maintained per your needs in the future.

By Way of Risk and Cost Reduction - What's Appropriate, What Isn't, and How Do I Determine the Difference? Unnecessary costs can often be avoided if the correct questions are broached at initial sales and project meetings with the supplier’s representative. It is accepted that regulated companies seek to maximize supplier involvement throughout the system life cycle in order to leverage knowledge, experience and documentation, subject to a satisfactory supplier assessment As an example of regulatory bodies acceptance of this approach, released in 2011, Annex 11 on Computerized Systems states that ‘the competence and reliability of a supplier are key factors when selecting a product or service provider’; and of course ‘Leveraging Supplier Involvement’ is also one of the 5 key concepts of the GAMP®5 guidance. The FDA’s current Good Manufacturing Practices (cGMP’s) for the 21st Century Initiative and associated guidance is also promoting science based risk management. The precise amount of “leveraging” that’s acceptable depends on risk. Risk ultimately posed to patient safety as well as to your company (in the form of time and money as well as reputation).



Non Configurable systems are “off the shelf”, out of the box systems that are simpler and require only moderate installation qualifications.

.

System categorizations (as shown in GAMP5) range from Non-Configurable Products (category 3), thru Configurable Products (category 4) to Customized Applications (category 5), and each poses a different level of risk. Category 3 – Non Configurable systems are “off the shelf”, out of the box systems that are simpler and require only moderate installation qualifications. If pre-existing IOQ’s are available, it is acceptable to simply re-enact these on your own infrastructure. And of course, if the supplier can provide evidence of the verification activities performed on these non-configurable systems (performed under a QMS) then these should simply be referenced by your final validation report and stored with the system installation files as evidence of satisfactory compliance with your needs. No further system verification activities should be necessary where these factors are in place. Your own change control processes and those of the supplier should be used from that point, and it is important to ensure that these (and other issue resolution and communication processes) are compatible when assessing the supplier. Category 4 – For Configurable systems, while it is not recommended to remove qualification and verification activities to the extent as shown for category 3 systems, it is possible to leverage the activities of the supplier to significantly reduce them. The IOQ’s can be leveraged and amended as needed and re-executed, the configuration and functional specifications can be followed verbatim, and the provided test scenarios can be (edited if needed and) re-executed on your systems once configured. Of course any elements that come “pre-configured” can be identified via risk assessments involving the supplier, and the verification of those elements can simply reference the supplier activities and documentation. The same considerations should be given to change control, issue resolution and communication processes. Category 5 – Where significant customizations to the system – be it for system hardware configurations, or to the system software, a greater level of risk is prevalent and the qualification and verification activities should be commensurate to this level. It is more likely that the supplier will have no useable documentation for elements specific to your use of the system. So it follows that you will need to produce much of the documentation from scratch yourselves. Any standard and configured elements can of course be identified by risk assessments. The time and costs associated with a customized system therefore rise not only according to the amount of custom development, but also to the amount of documentation and verification activities you must perform and produce – because the risk posed is greater and less leveraging of information is possible. It is also even more critical that mature QMS processes including change control, communications and issue management



The time and costs associated with a customized system therefore rise not only according to the amount of custom development, but also to the amount of documentation and verification activities you must perform and produce – because the risk posed is greater and less leveraging of information is possible.

are in place. (E.g. any patches should be effectively managed using these processes as they will have an unknown effect on customized elements).

Utilizing this information Shown below is a summary of how to utilize the information from the preceding sections to drive the creation of the requirements you have as a customer when selecting a supplier; Firstly – ensure your own house is in order – your QMS should be created or updated to maximize the benefits from your suppliers. Utilizing industry guidance and best practices (e.g. GAMP 5), it is critical to establish your internal supplier management and selection processes. Identify your system requirements in as much detail as possible – including the data and interface requirements, and where possible whether the system you need should be a category 3, 4 or 5 system – as this will drive the decision making process. (This may not be know at the early stages but should be a consideration when looking at time, costs and complications). Determine your hosting needs – in house (Do you have qualified infrastructure? This is an important consideration and one that is often overlooked), cloud or external hosted. The supplier should also have as many of the following as possible;

• A Mature QMS (including established change control, issue management and communications processes)

• All relevant and required (and current) certifications • Installation instructions and IOQ’s • Requirements examples • Training records • Example and templates for Testing • Willingness to participate in risk management activities • Configuration documentation for all areas of the system

Critical, Key and Desirable Supplier Elements There are a number of elements that have been discussed herein. Some of these elements are more critical than others. Some are absolute showstoppers and should be considered as must haves. Others are key to success and some are desirables – the so-called “nice to haves”.



A desirable supplier element is willingness to participate in risk management activities.

Critical Supplier Elements

• Up to date certifications (e.g. 510k) related to the system version under consideration

• Mature QMS • SLA - including critical elements such as change control,

configuration and functional specifications, issue management and communications.

Key Supplier Elements

• Installation instructions and IOQ’s • Requirements examples • Training records • Examples and templates for Testing • Configuration documentation for all areas of the system

Desirable Supplier Elements

• Willingness to participate in risk management activities • Hosting considerations (ability to host, cloud availability, ease of

installation and cost of infrastructure and equipment)

Implementing Cloud Systems

• GxP Functionality with Cloud Solutions – why now? • Cloud System benefits • Overview of Cloud Systems security and Infrastructure Qualification • The Power of the Cloud • Overcoming the challenges of Cloud Compliance – How to implement

in a compliant yet efficient and cost effective manner • Lower cost to implement and maintain • Higher rate of innovation • Security • Reliability • Accessibility

GxP Functionality With Cloud Solutions? - Why it Makes Sense Now… The usage of Cloud Platform technologies within Life Sciences companies is not a new concept. However, historically – adaptation even within Life Science companies has typically been limited to using “Non GxP” functionality – such as Sales Call scheduling and financial services. Times are changing - with numerous medium to large Life Sciences



With only minor adaptation, best practice validation methodologies that have been tried and tested for many years are now being used at more and more Life Sciences companies to qualify, validate, and maintain Cloud Platforms and accompanying GxP applications.

companies paving the way to showing that the huge potential and power of the Cloud can be used to perform a multitude of GxP processes, all intertwined and all Qualified, Validated and Regulatory Compliant. With only minor adaptation, best practice validation methodologies (e.g. GAMP 5 – A Risk Based Approach to Compliant GxP Systems) that have been tried and tested for many years are now being used at more and more Life Sciences companies to qualify, validate and maintain Cloud Platforms and accompanying GxP applications. The shift of some of the compliance effort to your suppliers is already an accepted approach where relevant and performed according to regulatory expectations. Both Legacy cloud platforms and those being considered for New or Upgraded implementations at Life Sciences companies can now be taken the extra step to take advantage of their huge power and configurability and can be shown to be compliant with the FDA regulatory expectations (e.g. 21 CFR Part 11). The FDA themselves have seen the light – and are now embracing the power and usefulness of the Cloud, utilizing and leveraging cloud power for their “Big Data” initiatives to enable eSubmissions, storage, analysis, and sharing of enormous data sets. They are embarking on a progressive process to upgrade their technology platforms in line with current and future requirements. Only with the Cloud are these initiatives possible.

The Benefits of Cloud Computing



Public clouds are available to everyone but provide little visibility and no control over the location of a customer’s data. Public cloud customers share the same infrastructure pool, which provides economies of scale with costs being spread across many users.

Overview of Cloud Architecture, Security and Infrastructure

Public, Private, or Hybrid? Most cloud applications today are using a “public cloud” infrastructure but other options are available. Here’s a list of different cloud infrastructure types and how they’re different: Public Cloud - Public clouds are available to everyone but provide little visibility and no control over the location of a customer’s data. Public cloud customers share the same infrastructure pool, which provides economies of scale with costs being spread across many users. Use a public cloud when:

- You want scalability at a relatively low cost - You want to utilize a pre-built cloud platform for applications such as

CRM, customer service, accounting, HR, etc. - You desire less infrastructure administrative controls - which can be

seen as a benefit, allowing resources to spend time on other business-value tasks

Private Cloud – A private cloud is a cloud infrastructure dedicated to a single organization. Private clouds can be hosted internally or by a third party cloud provider. Private clouds allows businesses to host applications in the cloud while addressing data security and control concerns. A private cloud is for you when: - You need your data independent from anyone elses but want the

efficiencies that cloud provides - Security and control are tantamount to the success of the application

regardless of cost - Willingness to have a higher level of engagement in the administration

and development of a virtualized environment Hybrid Cloud – Hybrid clouds are a combination of private and public clouds and offer the benefits of both deployment models. A hybrid cloud should be considered when: - A pubic cloud can be used for customers while a private cloud is needed

for internal IT - Customer interaction is in the public cloud while data is stored in private - Managing multiple cloud environments is acceptable for your

organization



This architecture can provide consistency and control but is also security vulnerability. Infrastructure and data security should be near the top of the list of concerns when considering a move to the cloud.

Cloud Architecture: Single vs Multi-Tenant Another thing to consider, beyond the type of cloud, is the architecture of the cloud environment. One aspect of this architecture can be described as tenancy – single vs multi. Single tenancy is where each customer has their own dedicated hardware to serve up their application. This architecture can provide consistency and control but is also security vulnerability. Single tenancy represents a single point of entry that poses a greater risk to data theft and loss. Multi-tenancy is where many users share the same hardware yet have exclusive access to their particular data. This model does not present a less secure architecture since a customer’s data is spread over many servers so that a breech of one does not give access to full data set. Infrastructure and data security should be near the top of the list of concerns when considering a move to the cloud. Today, cloud vendors realize that in order to play in the same ballpark as the on premise vendors and establish trust with customers, they need to maintain world-class data centers and security as defined below: Facility Security:

• 24x365 on site security • Biometric readers, man traps • Anonymous Exterior • Silent Alarms • CCTV • Motion detection

Network Security:

• Fault tolerance External Firewall • Intrusion Detection Systems • Best Practices secure systems mgt • 3rd party vulnerability assessments

Architecture and Application Security:

• TLS data encryption • Rigorous password security policies • SOC1, 2 and 3 and SysTrust Certifications



Vendors have begun to establish comprehensive IQ documentation to demonstrate that qualification of their infrastructure, and the establishment of maintenance processes to ensure it remains compliant on an ongoing basis.

• ISO 27001 Certification • HIPAA compliance • Secure architecture options such as private or public clouds • Multi-tenant architecture for data security

Infrastructure Qualification (IQ) Vendors wanting to provide SaaS to the Life Sciences world have also realized that it is not simply desirable to have a well-managed, well documented and well controlled infrastructure, it is in fact a pre-requisite for almost all end customers who view the compliance world from a risk based perspective. For this reason, Vendors have begun to establish comprehensive IQ documentation to demonstrate the qualification of their infrastructure, and the establishment of maintenance processes to ensure it remains compliant on an ongoing basis. Companies should be looking to Cloud Vendors to be able to provide, at a minimum, the following elements:

• Quality Manual • Security Procedures • Communications and Release Management Procedures • Change Control Procedure • Infrastructure and Installation Qualification evidence for all Data

Centers (including ancillary support structures and Disaster Recovery back-up facilities), all hardware, and all software.

• Training Procedures and evidence of employee training. • Full access to their facilities to Client Auditors.

Highly desirable elements from a vendor perspective would be:

• Standard – Core Platform System Requirements • Verification Scripts based on SR • Additional documentation associated with the Validation Lifecycle

that can be leveraged by Clients to reduce their burden and increase their ROI

xThe Power of the Cloud The partners shown below (not exhaustive) have developed solutions to numerous Life Sciences compliance and regulatory requirements. With the possibilities that Cloud Computing brings to the table, and with these types of hugely powerful applications available, the possibilities are endless.



Salesforce.com provides a hugely powerful and configurable suite of applications including but not limited to Patient Case Management, Compliant Management, and Sample Management. Cloud based FDA regulated IT systems must be established and maintained at compliance levels equal to internally hosted systems- and this has already been done and proven successful during multiple audits of various cloud vendors.

• Provides a hugely powerful and configurable suite of applications including but not limited to Patient Case Management, Complaint Management, Sample Management

• Provides Regulated presentation management for mobile clients with Compliance tools for Chatter collaboration

• provides services for Sunshine Act reporting

• provides a great solution for customers to enhance workflows by adding in Electronic Signature and Digital Signature capabilities – including Part 11 compliant e-signature solutions that bolt onto a myriad of other GxP applications

• enables Part 11 compliance solutions on Force.com – with Cloud-based solutions designed specifically for the needs of the life science industry

• provides Field Service Management relating to Work Orders, Warranty Entitlements, Inventory & Parts Logistics, Advanced Scheduling & Workforce Optimization, and Mobile

• provides Validation accelerators, automation tools, and full Governance consulting services specific to the Life Sciences Industry for all of these tools, and have in fact worked directly with a number of them to enhance or even develop the solutions alongside the Vendors

Overcoming the Challenges of Cloud Compliance – How to Implement in a Compliant Yet Efficient and Cost Effective Manner The establishment of a Robust, meaningful and useable SLA will enable you to ensure that your cloud supplier has in place all the necessary processes, people and technology to deliver and maintain a compliant system.



For each well selected/audited and “complaint ready” vendor, the Core System configuration and baseline for each cloud system release can be qualified and validated utilizing the creation of a client and release specific Validation Plan.

You should therefore be looking to see fully documented infrastructure qualification evidence, system administration, backup and recovery processes, system redundancies, security policies, encryption policies, communications processes and schedules. All of this enable you to utilize and “leverage” the vendor’s own established documentation when implementing for GxP functionality within your own organization. Remember that the compliance requirements for IT suppliers (including cloud systems providers) is derived from several regulations and requirements:

o For Example - 21 CFR Part 820 QSR, Section 820.22 prescribes supplier quality audits be conducted

o 21 CFR Part 820 QSR, Section 820.50 prescribes evaluation, control and monitoring of all suppliers providing purchased material or services to a regulated facility, with evaluation of suppliers against written specifications using defined procedures with documented results

o GAMP 5 Appendix S5, defines specific steps to be taken to control and monitor outsourced IT hardware and services

So to sum all that up, Cloud based FDA regulated IT systems must be established and maintained at compliance levels equal to internally hosted systems – and this has already been done and proven successful during multiple audits of various cloud vendors. Qualifying the Core Establishing a solid foundation is key for any regulated system. With the Cloud, that’s no different. In fact, it is actually an unseen benefit of cloud systems usage. Since every end user sees the same initial core platform – albeit with some minor configurations specific to their internal policies, then the validation of that core platform can be “pre-packaged” and delivered very expediently. Leveraging the activities already discussed and establishing a robust SLA backed up by Vendor Audits is the first part of that foundation. The standard “Platform” qualification is the next step. For each well selected/audited and “complaint ready” vendor, the Core System configuration and baseline for each cloud system release can be qualified and validated utilizing the creation of a client and release specific Validation Plan. The plan refers to the use of the Vendor’s Change Control, Administration



and Maintenance SOP’s. System Requirements for the release are established and added to any previous requirements version and release notes (Release notes are produced upon successful completion of vendor’s internal testing) – to inform customers of the impending release functional additions and modifications. Baseline configuration is performed. All existing and new requirements from the release notes are subjected to a formal risk assessment – both at a high level to establish GxP and Business Risk criticality, and at a detailed level to determine the level of control and verification activities required IQ and OQ protocols are established according to their inherent risk and executed based on the core requirements. All requirements verification controls for the release are applied and any relevant regression tests for previous releases are performed to ensure no adverse effect is seen from the introduction of the new functionality. Core Platform

This diagram identifies the relationship between the efforts that a cloud vendor undertakes to produce the Release Notes, and the activities that you as customers will be ensuring have been established when performing vendor audits and creating SLA’s. The resultant release notes form part of your customer validation package.



Customer Specific User and Functional requirements are established and added to any previous requirement versions and the release notes.

Customer Specific System Elements

The Customer Specific Validation plan refers to the establishment of the SLA and Vendor audits, and details what is being leveraged from the Cloud Vendor. It also details the plan to establish a compliant state for the customers own specific configuration of the system to meet their needs – including the addition of GxP applicable applications and functionality. Customer Specific Configuration Management and Change Control processes are established to manage changes for each release and any unscheduled changes. Customer Specific User and Functional requirements are established and added to any previous requirement versions and the release notes. As before, risk assessments are carried out on the requirements and release notes to drive the level of testing rigor and regression testing needs. Customer specific configuration is performed. Verification activities – IQ is performed to simply verify customer required configurations on top of the standard cloud configuration (Infrastructure Qualification and Hardware/Software installation qualifications are leveraged from the vendor). OQ and PQ are performed utilizing established protocols and executed based on both the customer specific requirements – and the release notes per



Third party compliance service vendors, like USDM, can be engaged to provide these services, including scripts for all scheduled releases, patches and emergency changes Risk is therefore extremely low for the end user.

inherent risk, along with any regression testing identified as potentially necessary. Traceability is maintained throughout and summary reports are used to release the system. Maintaining the System and the Supplier Relationship

• Release Management, • Regression testing your systems – how much is too much/not enough • The nature of the changes – i.e. no effect seen on client configuration,

mostly new functions of base updates • Change control process • Communications • Enhancing your existing supplier relationships

Release Management Maintaining Compliance is a key and critical element to using Cloud systems for GxP functionality. Establishing and Maintaining Compliance are two sides of the same coin. Due to its very nature – the cloud is updated on a regularly scheduled basis – with various upgrade cadences established depending on the vendor. These can be once a year or 4 times per year, and with monthly service packs on top of that – establishing a workable and efficient process is key. For each of the releases and service packs – a set of release notes is produced as discussed. These notes are always issued ahead of production release, to allow customers to analyze them, and produce any change control steps they may feel necessary – such as PQ scripts for the released functionality itself, or regression tests for the potentially affected areas of their own configuration. Vendors also automatically execute risk mitigation regression tests (numbering in the hundreds of thousands) for all scheduled releases and patches For patches/bug fixes – it is important to follow the procedures established during your initial validation – perform assessments on the changes and regression test any potentially effected functionality accordingly. Even patches/bug fixes are released to system QA environments prior to production release, so establishing a good communications procedure as part of your SLA is critical to enable enough lead time to assess and test any patches. Third party compliance service vendors, like USDM, can be engaged to provide these services, including scripts for all scheduled releases, patches



In the majority of cases for release notes analysis it will be a simple process to identify whether a change will affect your configuration, or is meant to address a specific issue with a function that your business process does not use.

and emergency changes. Risk is therefore extremely low for the end user. Regression Testing Your Systems – How Much Is Too Much/Not Enough When determining an applicable level of Regression testing, it is possible to utilize a number of different methods, depending on your own internal system complexity and utilization of automated testing tools. Where these tools are in effect – running a suite of standard tests is possible very easily and any issues relating to cloud updates arising from them are very quickly apparent. Remember of course that your supplier should also be performing thousands of lines of code testing as a matter of course for all updates – so these tests – even automated, should be focused upon your own configuration and usage, not carte blanche across the entire platform. Where automated testing tools are not utilized, processes and tools like Configuration Management Matrices can be utilized to identify potentially affected areas, or in simple core cloud systems, performing a review of risk assessments relating to the new/updated requirements may be sufficient to attain the level of testing information required. The Nature of the Changes – i.e. No Effect Seen On Client Configuration, Mostly New Functions of Base Updates Almost all changes from a Cloud vendor will fall into two categories -

1 New Functionality 2 Base Configuration patches/bug fixes

Due to the nature of how cloud systems are designed, it is extremely rare for the periodic releases/patches pushed out by Cloud vendors to have any effect whatsoever upon a customer’s own specific configurations. Of course, in instances where a customer has a specific issue and is in communication with the Vendor to address it, this is not the case, and should be analyzed accordingly. In the majority of cases for release notes analysis it will be a simple process to identify whether a change will affect your configuration, or is meant to address a specific issue with a function that your business process does not use. New functionality changes should be analyzed to determine if they fall into the GxP arena, or a business critical change, that your business needs to perform some form of risk mitigation on. If they are GxP or Business critical, new requirements should be drawn up or existing ones amended. Then they should be subjected to the same risk analysis and testing processes the initial



Don’t be afraid of the cloud, utilization, platform qualification and functional validation are not new concepts to the industry. It is merely a slightly modified approach - necessary to address different challenges posed by cloud usage.

requirement were. For base configuration changes – i.e. patches and bug fixes relating to a specific issue, it may be sufficient to run existing related regression tests in your testing environments to ensure these processes - as they pertain to your usage, are now or are still operating as you need them to. It may however be necessary to update existing test documentation to reflect updated elements (typically new tests are not required, merely updates to existing ones). Change Control Process For all changes to the Cloud System that require a response/action by the end user, there should be a documented change control that explains and rationalizes the response as appropriate, and is approved at a congruent level. The release notes and communications from Cloud Vendors, as well as the assessment and related response activities by the end user form the back bone of the change control record and should be referenced within it. Once change control record per release/service pack is sufficient if these activities are in place, and reduces the need for multiple pre and post approvals for minor elements. Enhancing Your Existing Supplier Relationships Having a good working relationship with your Cloud System supplier is clearly a critical success factor in dealing with the challenges and advantages that the cloud uncovers. Some Cloud Vendors actively seek out key end users to participate in Beta testing groups, as well as requirements gathering sessions to identify where the next improvements and new functions should come from. If your organization can become one of these key users, then you have access not only to early functionality changes to analyze and mitigate, but also to drive the direction of the system to enable you to become even more efficient in your own business area. Conclusion As already discussed, the trend for Cloud Systems adoption in Life Sciences is very strong, and continues to strengthen all the time. Don’t be afraid of the cloud, utilization, platform qualification and functional validation are not new concepts to the industry. It is merely a slightly modified approach - necessary to address different challenges posed by cloud usage. The bottom line is that if you ensure the Quality Management Systems and processes of the supplier meet your and regulatory expectations – and you in turn provide internal due diligence to maintain the compliant state once



established, then you are in a position that enables you to leverage the activities with a documented rationale for less risk. References • ICH - The International Council on Harmonization of Technical

Requirements for Registration of Pharmaceuticals for Human Use

• GAMP 5® - ISPE Glossary of Pharmaceutical and Biotechnology Terminology - Good Automated Manufacturing Practice (GAMP) A Risk-Based Approach to Compliant GxP Computerized Systems



About the Author David Blewitt is the Vice President of Cloud Compliance at USDM Life Sciences. David is an accomplished Life Sciences Regulatory and IS Compliance Professional with extensive hands-on and leadership experience in the Pharmaceutical, Medical Device, Biotech and Blood Management Industries, specifically in the fields of; Computer Systems Validation, Risk Management, Issue Investigation – Root Cause Analysis and Remediation, Quality Assurance, Software Development Lifecycle, Lean IS Compliance Enhancement Initiatives, Business Analysis, Product Lifecycle Management and Systems/Process analysis with Compliance Roadmap development. He is an acknowledged expert on a wide range of regulatory predicate rules and guidance including: • 21 CFR Parts: 11, 203, 210, 211, 801, 803, 820 and 821. • ICH • GAMP 5 Recently, David’s engagements have been increasingly aligned with the validation of Cloud Systems and Applications, including both standard and custom solutions for Patient Case Management, Sample Management and Tracking, Adverse Event Case Assignment Systems and MHRA Dispositioning systems coming under 21CFR Parts 203 (PMDA) and Part 11. About USDM Life Sciences USDM Life Sciences is a leading global regulatory consulting firm providing compliance, validation, qualification, quality, auditing, and information technology services to our clients in the Medical Device, Biotechnology, Biologics, Diagnostics and Pharmaceutical industries. USDM has more than 10 years of experience supplying our clients in the life science industry with compliance services during each phase of their drug and product development cycle. USDM Partners with best of breed organizations to help companies simplify, unify and optimize their business and compliance objectives.

selecting implementing and maintaining cloud systems for the life sciences industry

Documents