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.

Aggregate Spend/Sunshine Act: Change is Inevitable….are you ready?

The Comment Period for the Physician Payments Sunshine Act closed last week.  Now everyone is waiting to see how it will play out and what will be included in the final legislation.  We, at Business & Decision Life Sciences are no exception.

In addition to the “nuts and bolts” of the changes i.e. what payments are now to be accumulated, payments made to which parties, how reporting will change, etc., I think it is relevant to consider the impact of change on the organization and the people who are required to incorporate the changes into their routines.  I think sometimes, the focus on the technical elements of change overshadows consideration of the impact of the changes on the people.  If the impact of how the change impacts the people is not considered, success of the change can be limited. 

Change experts often refer to the need to assess where the organization is in terms of readiness to make changes.  I found a great tool that assesses change readiness in the form of a brief questionnaire called The Change Readiness Audit (found in The Change Management Pocket Guide which can be purchased from the authors at http://www.changeguidesllc.com/). It can be used formally as a questionnaire completed by employees or informally as a discussion tool at the management level (don’t forget that input from employees can be very different than management’s perceptions!).

This Change Readiness Audit includes questions that cover a range of sub-areas including:

·         The Vision or Business Case for the change

·         Engagement of resources

·         Leadership involvement and commitment

·         How effective will the implementation of the change be

·         Sustainability of the change

As with many tools, this one can be tailored to fit a particular situation.  Regardless of how it is tailored, once completed, the assessment can help to pinpoint areas that need attention in preparation for the anticipated change, including, but not limited to, those related to the Sunshine Act.

Risk-Based Validation - How Are We Doing?

Yesterday, I posted a poll on LinkedIn asking the question

"How is Life Sciences industry embracing risk-based computer systems validation? Do we have the balance between risk assessment and risk mitigation right? Are we just rushing to reduce costs...?" 

People's responses are starting to come in and we're already starting to get some interesting comments on the question. If you're interesting in the poll and want to take part you can find it here (once you've answered the question you'll be able to see how everybody else has been voting).

Since I asked the question I guess it's only reasonable that I try and answer it and provide my own opinion. There is of course no single answer and even within a single Regulated Company there are different individuals and departments taking different approaches to risk-based validation. In many cases you have the business, and IT tried to reduce costs against a background of life sciences companies struggling to maintain profitability. At the other extreme you have the quality unit who are used to doing things the old-fashioned way and like to see every 'i' dotted and 't' crossed.

Hopefully, somewhere in the middle, you'll find some pragmatic validation practitioners genuinely trying to do their best to take a risk-based approach to validation and apply the appropriate resources to the highest areas of risk to patient safety, product quality and data integrity.

However, this is often thwarted by two obstacles:

1. The pragmatic practitioners in the middle are seldom the people with control of the budgets or with the power to effect real change. This often means that they'll pull from pole to pole at the behest of the business owners, the IT group and the quality unit who have different perceptions of how things should be done. In many cases these practical practitioners of the validation art are not recognised as true subject matter experts and they guidance, advice - and even wisdom - is ignored, often for the sake of point scoring and political expediency in large organisations.

2. Where practical and experienced practitioners are not available (often in small to medium sized organisations but also in organisations in emerging economies where computerised systems validation is a relatively new discipline) there is a genuine lack of understanding of how to take a practical approach to risk-based validation. in these cases and inability to invest in training and education is an obstacle to adopting risk-based validation.

I think therefore the what we will see is an industry which continues to adopt risk-based validation at a relatively slow pace. While some companies are using risk-based validation as an excuse to do less (and in some cases, too little) I think the majority of companies want to do the right thing but are hampered because of their own organisational structures or lack of experience, training and education.


From my experience as a consultant, and with my experience working with the small number of companies who are doing a good job with risk-based validation I genuinely do believe that taking a risk-based approach to validation has advantages both in terms of cost effectiveness but also in mitigating risk to patients. Regrettably, it's one of those things that most regulated companies will have to see for themselves before they believe, and they were set for themselves until they have gained the necessary experience.


As an industry I believe that we need to do a better job in publishing case studies demonstrating the effectiveness of risk-based validation, that we need to recognise the value of our internal and external subject matter expertsand he must be prepared to invest in training and education.

Cost Effective Validation of ERP and CRM - Your Questions Asnwered

In yesterday's webcast "Dissecting ERP and CRM Vendors for Cost Effective Validation" we discussed what regulated companies should be looking for when selecting ERP or CRM software and system integrators in the Life Sciences industry.

Specifically, we looked at how the choice of software vendor and system integrator affects the validation of the system, in terms of:

• Cost effective and efficient validation,
• Level of compliance achieved, both in terms of compliant business processes and compliant validation,
• The quality of the final solution delivered.

We also reviewed what regulated companies can do to ensure that projects obtain the right balance between project cost, timescales and quality.

Unfortunately we ran out of time to answers all of the questions submitted during the webcast and our apologies to the person whose question we didn't have time to get around to. As promised, here is our answers to your question.

Q. How current is your data on cost, time, and quality?

A. In the webcast we showed a slide that inferred that time and cost considerations are usually completely divorced from quality/validation, where of course they should be balanced. Our experience is that a small number of Life Sciences companies (mainly larger pharmaceuticals) have invested significantly in adopting GAMP 5 risk-based validation and have developed flexible SDLCs which can accommodate ERP/CRM implementation in a cost effective and efficient manner.

However, this is still a small minority and as the later vote showed, most companies are still struggling to achieve the proper balance between time, cost and quality.

We also mentioned that it is possible to reduce the cost of validation to around 2-3% of the overall project budget, but most projects are still around 10-15%. The 2-3% figure assumes a well-defined SDLC that is specific to the ERP/CRM system being validated and also a great deal of process repeatability. In the case of Business & Decision, we can achieve those figures because (a) with due modesty, we are experts in implementing ERP/CRM and are also experts in risk-based validation and (b) we have done this dozens and dozens of times before in Life Sciences.

Some large pharmaceutical companies are also quoting similar single digit figures for the cost of validation, but the reality is that they are being selective in the figures they are quoting i.e. they represent mature processes for validating the roll-out of new phases of an existing system, using a system specific, mature and well-understood SDLC.

For most companies implementing ERP or CRM for the first time, 10-15% is more realistic. 5-10% can be achieved if you engage a specialist who really knows ERP and CRM validation and you engage them early in the project planning. 10-15% is more likely if your own validation staff work it out with a less experienced system integrator.

These figure are based on experience over the last 3-5 years, since the publication of GAMP 5.

You can view the webcast and hear all the other questions - and answers - by viewing the recording of the webcast. We hope that people found the webcast useful and that you’ll be able to join us for the remaining webcasts in the ERP/CRM series – details of which can be found in the ‘webcasts’ page on the Business & Decision Life Sciences website.

Integrated ERP and CRM in Life Sciences

As many of you all know, over the last few weeks we've organized a couple of webcasts looking at the integration of ERP and CRM systems ("Leverage Your ERP & CRM Data to Make Faster, Smarter Decisions" and "How To Integrate Product, Customer and Patient Data"). This is as part of a series of five webcasts we are running related to enterprise systems.

The last two webcasts have looked not only at the advantages of integrating ERP and CRM systems, but also the use of master data management, business process orchestration and business intelligence tools.

There are some good questions the came out of yesterday's webcast session and unfortunately we didn't have time to answer them all during the live webcast. 

As we promised we've reproduce the unanswered questions and our answers here our blog.

Q. Can you say more about why some life sciences companies are keen to get into healthcare management and what they are doing?

A. We talked about this quite extensively in one about earlier webcasts () but basically were seeing a number of life sciences companies move more into healthcare as they see their traditional profit margins being increasingly squeezed. Moving into healthcare has several advantages such as:

• Opening sources of new revenue
• Ensuring better health outcomes for patients

In the case of this latter benefit this means that patients are more likely to continue using the regulated companies drugs or devices, thereby ensuring an on-going revenue stream. At a time when many payers (whether these are insurers or governments) are increasingly looking to pay based upon results it makes sense for life sciences companies to ensure that patients are complying with their medication regimes and treatment is successful.

In the case of yesterday's webcast were seeing a number of life sciences companies increasingly extend the use of their CRM systems to incorporate the use of patient and healthcare management.

Q. Can aggregate spend reporting be built into CRM systems?

A. It is certainly possible to build aggregate spend reporting based upon information that is held in CRM systems. For small to medium life sciences companies with only a single CRM system, these systems may indeed contain all of the information required to produce accurate aggregate spend reports. However, where there are multiple CRM systems data usually needs to be aggregated across the systems and as we saw yesterday's webcast there are also advantages in terms of integrating information from the ERP system such as cost information and expense data.

For those of you specifically interested in this topic we'll be talking more about aggregate spend in a webcast in the New Year

Q. With such a focus on external patient facing activities, easy ERP system becoming less important?

A. The traditional reasons for implementing ERP systems have never gone away. Those of us remember the days of early MRP and MRPII implementations understand the significant benefits that such functionality brings. For small to medium life sciences companies who do not currently leveraging ERP system there is considerable return on investment from implementing core ERP functionality. This should really be the primary reason for acquiring and implementing a new ERP system.

However, we are seeing ERP systems become increasingly integrated across the enterprise and not just in areas such as manufacturing and operations. While ERP systems are just as important as ever, they are becoming more and more integrated into the enterprise applications landscape.

For a company that has no ERP system implementation of a new ERP system is properly one of the most important things the company can do in terms of investment in IT. However once the basic ERP functionality has been implemented there are a number of additional end to end business processes that can be facilitated by integration of the ERP system and it is perhaps true to say that additional manufacturing functionality may not be the most important extension of functionality.

If you have any remaining questions please do get in touch and for those of you who missed the webcasts the recordings are still available on the Business and Decision Life Sciences website (see Past Events). We do hope you'll be available for the rest of the webcasts where we were looking at some interesting topics such as

• How to leveraged software and system integration activities for cost effective validation
• How to integrate good record-keeping and document management with your ERP and CRM systems
• How to plan for successful ERP and CRM systems as a regulated company

Software as a Service - Questions Answered

As we expected, last week's webcast on Software as a Service (Compliant Cloud Computing - Applications and SaaS) garnered a good deal of interest with some great questions and some interesting votes.


Unfortunately we ran out of time before we could answer all of your questions. We did manage to get around to answering the following questions (see webcast for answers)

• Would you agree that we may have to really escrow applications with third parties in order to be able to retrieve data throughout data retention periods?
• How is security managed with a SaaS provider? Do they have to have Admin access, which allows them access to our data?
• How do you recommend the Change Management (control) of the SaaS software be managed?
• How can we use Cloud but still have real control over our applications?
• What should we do if procurement and IT have already outsourced to a Saas provider, but we haven't done an audit?

As promised, we have answered the two remaining questions we didn't get time to address below.

 

Cloud computing is, not surprisingly, the big topic of interest in the IT industry and much of business in general. Cloud will change the IT and business models in many companies and Life Sciences is no different in that respect.

 

We've have covered this extensively during the last few months, leveraging heavily on the draft NIST Definition of Cloud Computing which is starting to be the de-facto standard for talking about the Cloud - regardless of Cloud Service Providers constantly inventing their own terminology and services!

If you missed any of the previous webcasts they were
- Qualifying the Cloud: Fact or Fiction?
- Leveraging Infrastructure as a Service
- Leveraging Platform as a Service


There are of course specific issues that we need to address in Life Sciences and our work as part of the Stevens Institute of Technology Cloud Computing Consortium is helping to define good governance models for Cloud Computing. These can be leveraged by Regulated Companies in the Life Sciences industry, but it is still important to address the questions and issues covered in our Cloud webcasts.

As we described in our last session, Software as a Service isn't for everyone and although it is the model that many would like to adopt, there are very few SaaS solutions that allow Regulated Companies to maintain compliance of their GxP applications 'out-of-the-box'. This is starting to change, but for now we're putting our money (literally - investment on our qualified data center) into Platform as a Service, which be believe offers the best solution for companies looking to leverage the advantage of Cloud Computing with the necessary control over their GxP applications.

But on to those SaaS questions we didn't get around to last week:

Q. Are you aware of any compliant ERP solutions available as SaaS?

A. We're not. We work with a number of major ERP vendors who are developing Cloud solutions, but their applications aren't yet truly multi-tenanted (see SaaS webcast for issues). Other Providers do offer true multi-tenanted ERP solutions but they are not aimed specifically for Life Sciences. We're currently working with Regulated Company clients and their SaaS Cloud Service Providers to address a number of issues around infrastructure qualification, training of staff, testing of software releases etc, . Things are getting better for a number of Providers, but we're not aware of anyone who yet meets the regulatory needs of Life Sciences as a standard part of the service.

The issue is that this would add costs and this isn't the model that most SaaS vendors are looking for. It's an increasingly competitive market and it's cost sensitive. This is why we believe that niche Life Sciences vendors (e.g. LIMS, EDMS vendors) will get their first, when they combine their existing knowledge of Life Sciences with true multi-tenanted versions of their applications (and of course, deliver the Essential Characteristics of Cloud Computing - see webcasts)

Q. You clearly don't think that SaaS is yet applicable for high risk applications? What about low risk applications?

 

A. Risk severity of the application is one dimension of the risk calculation. The other is risk likelihood where you are so dependent on your Cloud Services Provider. If you select a good Provider with good general controls (a well designed SaaS application, good physical and logical security, mature support and maintenance process) then it should be possible to balance the risks and look at SaaS, certainly for lower risk applications.

 

It still doesn't mean that as a Regulated Company you won't have additional costs to add to the costs of the service. You need to align processes and provide on-going oversight and you should expect that this will add to the cost and slow down the provisioning. However, it should be possible to move lower risk applications into the Cloud as SaaS, assuming that you go in with your eyes open and realistic expectations of what is required and what is available.

 

Q. What strategy should we adopt to the Cloud, as a small-medium Life Sciences company?

 

A. This is something we're helping companies with and although every organization is different, our approach is generally

• Brief everyone on the advantages of Cloud, what the regulatory expectations are and what to expect. 'Everyone' means IT, Procurement, Finance, the business (Process Owners) and of course Quality.
• Use your system inventory to identify potential applications for Clouding (you do have one, don't you?). Look at which services and applications are suitable for Clouding (using the IaaS, PaaS and SaaS, Private/Public/Community models) and decide how far you want to go. For some organizations IaaS/PaaS is enough to start with, but for other organizations there will be a desire to move to SaaS. Don't forget to think about new services and applications that may be coming along in foreseeable timescales.
• If you are looking at SaaS, start with lower risk applications, get your toe in the water and gradually move higher risk applications into the Cloud as your experience (and confidence) grows - this could take years and remember that experience with one SaaS Provider does not automatically transfer to another Provider.
• Look to leverage one or two Providers for IaaS and PaaS - the economies of scale are useful, but it's good to share the work/risk.
• Carefully assess all Providers (our webcasts will show you what to look for) and don't be tempted to cut audits short. It is time well worth investing and provides significant ROI.
• Only sign contracts when important compliance issues have been addressed, or are included as part of the contractual requirements. That way there won't be any cost surprises later on.
• Remember to consider un-Clouding. We've talked about this in our webcasts but one day you may want to switch Provider of move some services or applications out of the Cloud.

The Cloud is coming - in fact, it's already here. As usual, were not always the earliest adopters in Life Sciences, but you need to be prepared to move and take advantage. We hope that our webcasts have helped - please do let us know if you have any questions.

E-mail us at life.sciences@businessdecision.com