Computer System Validation Policy on Software-as-a-Service (SaaS)

In a recent LinkedIn Group discussion (Computerized Systems Validation Group: Discussion "Validation of Cloud), the topic of Software-as-a-Service (SaaS) was widely discussed and the need to identify appropriate controls in Computer System Validation (CSV) policies was discussed.

The reality is that relatively few compliant, validated SaaS solutions are out there, and relatively few Life Sciences companies have CSV policies that address this. 

However, there are a few CSV policies that I’ve worked on that address this and although client confidentiality means that I can’t share the documents, I did volunteer to publish some content on what could be included in a CSV policy to address SaaS.

Based on the assumption that any CSV policy leveraging a risk-based approach needs to provide a flexible framework which is instantiated on a project specific basis in the Validation (Master) Plan, I've provided some notes below (in italics) which may be useful in providing policy guidance. These would need to be incorporated in a CSV Policy using appropriate language (some Regulated Company's CSV Policy's are more prescriptive that others and the language should reflect this).

"When the use of Software-as-a-Service (SaaS) is considered, additional risks should be identified and accounted for in the risk assessment and in the development of the Validation Plan computer system validation approach. These are in addition to the issues that need to be considered with any third party service provider (e.g. general hosting and managed services). These include:

• How much control the Regulated Company has over the configuration of the application, to meet their specific regulatory or business needs (by definition, SaaS applications provide the Regulated Company (Consumer) with little or no control over the application configuration)

o   How does the Provider communicate application changes to the Regulated Company, where the Regulated Company has no direct control of the application?

o   What if Provider controlled changes mean that the application no longer complies with regulatory requirements?

• The ability/willingness (or otherwise) of the Provider to support compliance audits

• As part of the validation process, whether or not the Regulated Company can effectively test or otherwise verify that their regulatory requirements have been fulfilled

o   Does the Provider provide a separate Test/QA/Validation Instance?

o   Whether it is practical to test in the Production instance prior to Production use (can such test records be clearly differentiated from production records, by time or unique identification)

o   Can the functioning of the SaaS application be verified against User Requirements as part of the vendor/package selection process? (prior to contract - applicable to higher risk applications)

o   Can the functioning of the SaaS application be verified against User Requirements once in production use? (after the control - may be acceptable for lower risk applications)

• Whether or not the Provider applies applications changes directly to the Production instance, or whether they are tested in a separate Test/QA Instance

• Security and data integrity risks associated with the use of a multi-tenanted SaaS application (i.e. one that is also used by other users of the system), including

o   Whether or not different companies data is contained in the same database, or the same database tables

o   The security controls that are implemented within the SaaS application and/or database, to ensure that companies cannot read/write delete other companies data

• Where appropriate, whether or not copies of only the Regulated Companies data can be provided to regulatory authorities, in accordance with regulatory requirements (e.g. 21CFR Part 11)

• Where appropriate, whether or not the Regulated Companies data can be archived

• If it is likely that the SaaS application is de-clouded (brought in-house or moved to another Provider)

o   Can the Regulated Companies data be extracted from the SaaS application?

o   Can the Regulated Companies data be deleted in the original SaaS application?

If these issues cannot be adequately addressed (and risks mitigated), alternative options may be considered. These may include:

• Acquiring similar software from an acceptable SaaS Provider,
• Provisioning the same software as a Private Cloud, single tenancy application (if allowed by the Provider)
• Managing a similar application (under the direct control of the Regulated Company), deployed on a Platform-as-a-Service (PaaS)"

Hopefully these ideas will help people to develop their approach to SaaS, but CSV Policies should also address the use of PaaS and IaaS within the broader context of outsourcing.

Successful and Compliant ERP Projects

Unfortunately we ran out of time in yesterday's webcast “Secrets to Success - Plan and Implement Compliant ERP Projects”.

That was partly my fault because I was late dialing in. (Apparently, Microsoft Exchange/Outlook still doesn't automatically recognize that the US and Europe change to daylight savings on different weekends - doesn't anybody validate this software?). My apologies for that, and for the fact that we ran out of time to answer all of your questions as fully as we would have liked.

During the webcast we discussed how small to medium-sized life sciences companies can plan for the successful implementation of their ERP systems. We looked at how to align project planning and validation planning activities, we reviewed the typical project activities that are the responsibility of the regulated company and we looked at the importance of assigning the right people to the project. Below are the questions we didn't have time to answer fully and our answers - we hope that you find them useful.

Q. How does implementing ERP in pharmaceuticals vary from other industries?

A. The main differences are that in many cases the system requirements represent mandatory regulatory requirements which have to be fulfilled. There is no option to defer these to a later release and so many of the software vendor's ‘accelerated’ implementations using out-of-the-box software configurations cannot be used. There is also the fact that requirements, design specifications and testing all need to be formally documented and there may also be the issue of electronic records and electronic signatures to consider.

Although it is possible to implement an ERP system in a small to medium business within 8-12 weeks, the above factors make this virtually impossible in the life sciences industry. The fastest that we have ever been able to implement an ERP system in life sciences has been 16 weeks and for small to medium business 6 to 8 months is more typical.

Q. Does the increased focus on formal project management have any benefits?

A. The focus on formal project management controls means that time and cost overruns are usually better controlled. The focus on the formal definition and documentation of requirements also means that systems are much more likely to meet the real requirements of the real users. While the time and cost of implementing in life sciences is greater than some other industries, the fact that the system more completely fulfills the user requirements generally provides a better return on investment.

As an industry we must do a better job in demonstrating return on investment in order to justify the increased time and cost when compared to other industries. Where case studies are available they clearly show that a formally defined project management process, documented requirements specifications and tests and the need to demonstrably confirm that user requirements have been fulfilled delivers an ERP system that is fit for purpose, better meet the needs of users and provides better return on investment over the life of the system.

Q. How realistic are regulated companies in their expectations when looking to implement ERP or CRM?

A. Clients can certainly be very demanding and their expectations can be difficult to manage, especially when those expectations are informed by software vendors and system integrators who don’t really understand the life sciences industry.

As a company constantly engaged in implementing ERP and CRM systems but also competing to win such projects we often see small to medium life sciences companies with unrealistic expectations with respect to the real project budget, how long it will take to implement the system and the level of commitment their people will need to devote to the project. This is natural where the procurement process doesn't really understand the need for regulatory compliance, under values the benefits of formal validation and focuses mainly on comparing costs and implementation timescales.

On the validation side of business we have worked with a number of system integrators who are inexperienced in the life sciences industry and as a result we’ve had to help a lot of regulated companies bridge the gap between their initial expectations and what is really required for a successful and compliant project.

The reality is that it takes a minimum amount of time and effort to successfully implement a compliant ERP or CRM system. Small to medium life sciences companies would be better served by starting projects with realistic expectations and thereby avoiding having to go back to stakeholders to ask for additional funding and to explain why the project is “late”.

Q. Where do most ERP implementations fail?

A. Failure is a relative term. Most projects go live and deliver acceptable return on investment but are often seen as challenging projects or having failed because of initial unrealistic expectations with respect to the level of effort required of the regulated company. As discussed during the webcast, it is important that regulated companies really understand the activities that they will be responsible for and the deliverables that they will have to produce.

These need to be resourced appropriately; funding needs to be available and realistic timescales need to be set. If realistic timescales were put in front of stakeholders at the beginning of a project far fewer projects would be considered to have ‘failed’. Key to this is involving experienced resources in the concept phase of the system life cycle and during the early stages of the project planning.

Such resources need to have experience of implementing and validating ERP (or CRM) systems in the life sciences industry and the experience and knowledge that they bring to the table is invaluable.

As ever, if anybody has any follow-up questions from the webcast they can comment on the blog will get in touch through a usual e-mail address life.sciences@businessdecision.com. If you missed the webcast and would still like to view it the recording is available here.