In life sciences, we have systems subject to 21 CFR Part 11 and therefore subject to computer validation in compliance with FDA regulations. Computer validation isn’t just about checking boxes and creating a lot of documentation to meet compliance requirements. Computer validation forces good business practices in terms of defining what you need in a system, configuring or developing against those specific requirements, testing to ensure the requirements are adequately met, training users to use as intended, and then maintaining control over the system to make sure that you can rely on the data in the system (data integrity). And, all of this is documented because as we all know, to the FDA, if it isn’t documented, it didn’t happen.
Modern Approach to System Selection (Part 2 of 2)
Once the internal activities of system selection are complete, it’s time to move on to the external activities covered here. These include:
· Identifying potential vendors/solutions
· Preparing the RPF and facilitating the RFP selection process (if the team decided it was necessary and desirable)
· Conducting tailored demos
· Performing references checks
· Planning the project
· Negotiating and signing the contracts and agreements
Modern Approach to System Selection (Part 1 of 2)
This is the first post in a two-part series on system selection. The first part of any system selection focuses internally on what the business needs and how it wants to approach selecting a solution to satisfy those needs. This post focuses on these foundational elements:
· Defining business need
· Creating the selection team
· Performing the criticality and risk assessment
· Determining the system selection process and assessment criteria
· Defining the business requirements
Adopting Best Practices with Enterprise Systems
When cars replaced the horse and buggy, the functions that were inherent to having a horse as the “engine” were not brought over when people switched to driving cars. Without a horse, you don’t need blinders, a horse whip, or apples to feed the horse — although thoughtful automobile drivers might consider the apples for hungry passengers.
The same concept holds true when implementing an enterprise system. Manual or paper-based processes or activities that were in place (even using something like Excel) are no longer necessary, nor do they fit well into a technological solution.
Project Management: Lessons Learned (Part 1: Bringing in a Professional Project Manager Before Signing Agreements)
Bringing a project manager in after the agreements are signed is akin to bringing in a general contractor after the agreements with the subcontractors have already been signed. The general contractor, or project manager in my case, has expertise in negotiating those contracts and has experience around the best practices around the work. After the agreements are signed, not only have we lost all leverage but it leaves me as the project manager somewhat handicapped in doing my job and creates additional and unnecessary work (that the customer ends up paying me to do to clean up).
Project Management: Begin with the End in Mind
I prepared a one hour webinar for a select group of interested project management professionals and wanted to share the presentation and info here. I’ve spent the last 20 years managing IT related projects and have learned a thing or two and would love to help others to succeed and avoid some common mistakes. I also recorded a podcast on the subject which takes you through the slides and the process.
Effectively Using an RFP as Part of Your IT System Selection Process
With the rapid adoption of SaaS solutions, a lot of the life sciences companies have opted to simply sign the SaaS user agreements without thinking about the their business requirements, the change in their business processes, and even ownership of their own data. They don’t take into account the intended use and validation requirements. I know that a lot of vendors really hate RFPs. They see them as a waste of time since they are generally sent out to check internal procedure boxes and not provide value to either the customer or the vendor. I had an implementation partner routinely challenge me on my processes. He thought that I should just recommend the best solution based on my experience and shortcut the process. What he didn’t appreciate was that I saw value in the process. It wasn’t just about selecting the solution. There is value associated with a good process for selecting a new system and that selecting the right system is only one aspect of the selection process.
Validating a SaaS Solution
We need to start with a base assumption and that is: the life sciences company is responsible for validating a software solution for its own intended use regardless of where it is deployed.
There seems to be some confusion around this when it comes to SaaS systems and the vendors are contributing to this in order to sell more software. Somewhere along the way, one vendor said their solution was ‘validated’ (hiding the reality in the fine print of a Part 11 white paper) and customers flocked to the solution to avoid doing any validation work themselves. And then the rest of the SaaS vendors felt the need to say the same thing to be competitive.
The reality is that a vendor cannot validate for a customer’s intended use without doing additional work for the customer after the purchase. And this costs both time and money and the customer has to be a part of the process. Vendors don’t generally offer these services, although they may provide deliverables (for a fee) that are generally not tied to a customer’s business processes or intended use.
Well, then, what should this look like to meet compliance requirements and be defendable during an FDA inspection? I am so glad you asked.
Assuming we are talking about a medium to high risk system like CTMS, RIMS, Quality, Electronic Document Management, NCMR/CAPA, Complaints, Manufacturing/Inventory, SAE, etc. the first step is a validation master plan (VMP).
The VMP documents the scope of the system, the risk assessment and justification that drives the validation effort, and the validation effort itself. Validation begins with requirements and ends at system retirement…it is not simply testing. (I will document what is in a VMP in more detail in a separate blog post)
With that being said, the following are the primary (and critical elements) that should be considered with a risk based approach to computer validation(Note: this is for configurable-off-the-shelf without any custom code and assumes that the vendor meets your company requirements and industry best practices):
Vendor audit: if you are going to rely on your vendor for to develop the software and maintain the system (as software as a service) you can’t simply ‘throw it over the fence’ and leave it to the vendor. You have a responsibility to make sure that the vendor is meeting your company’s requirements and industry standards. The vendor audit may result in findings that drive the requirement for additional processes and controls to mitigate risk. I generally recommend that this is done before signing any contracts to make sure the vendor can actually meet the requirements.
Functional requirements: these drive configuration and business processes and are ultimately verified in the Performance Qualification (PQ) testing. This is critical…this is the foundation for all verification activity.
Functional requirement risk assessment: this is an assessment of each requirement that drives level of testing (I generally combine this into the functional requirements specification for ease of maintenance after Go Live).
IT SOPs: standard operating procedures to establish YOUR company’s minimum requirements for validated and business critical systems.
Work instructions and operational SOPs: in order to ensure that there is consistent use of the system to generate reliable data, you need to make sure people are using it in a consistent manner.
Performance Qualification (PQ) protocol: these are the business scenarios with specific tests that verify intended use and functional requirements. The protocol is approved by the validation team prior to execution and executed in a controlled manner by trained users (actual, intended users of the system).
Traceability matrix: this traces the requirements to configuration elements to verification tests (PQ tests) to provide documented evidence that the requirements have been effectively satisfied.
PQ final report: this is a summary of the execution of the PQ protocol and summarizes the results and findings.
Data migration plan: this defines the the way in which data will be migrated into the system whether from paper or electronic records. To rely on the migrated data, there should be a plan, verification, and summary of activities.
Configuration document: this is to establish the baseline for all future change control. I wrote a blog post on the importance of this as memories are short and it is really helpful to remember why decisions were made and what the decisions were.
VMP final report: this is a summary of the validation activities and how they aligned with the original plan. If the FDA comes in for an inspection, and they want to take a look at the validated state of your system (yes, it is yours even if it is offsite), they will start with the VMP final report.
I always leave my clients with an impact assessment template for to be used to simplify and streamline the process when there are updates to the SaaS solution (this happens two to three times a year). Once the system is live, it needs to be maintained and operated in a validated state and that responsibility does not just lie with the vendor. The vendor will introduce changes that could impact your requirements and processes.
The good news for our clients is that we can provide you with assistance with all of this. We have been developing and refining the templates and processes to make it easier for your company to comply with validation requirements as defined in the FDA regulations and GAMP5.
Feel free to reach out if you have any questions on this or if you want to sanity check what your vendor is telling you. Terri.Mead@Solutions2Projects.com or go to our website at Solutions2Projects.com.
Keep in mind that it is generally not in your vendor’s best interest to fully inform you of the true level of effort to validate a SaaS solution in the life sciences space. The vendors are incentivized to minimize the effort to get you to sign on the dotted line. It’s not really their problem but yours: they are not going to be the ones demonstrating data integrity and data reliability for electronic records and signatures subject to 21 CFR Part 11 or used in a regulatory submission; you are. It’s a bit of gamble, and yes, up to each company’s own risk assessment and tolerance. Then again I have to wonder: do you feel lucky, punk?
Failed IT Implementations are Expensive: Here’s How to Avoid Them
Between 30% and 60% of IT related system projects fail. This doesn’t consider partial successes or disappointments associated with system implementations. Most IT related system projects don’t have clear criteria for success so the definition of failure is subjective. The costs of these failures could be in the millions of dollars and result in significant litigation in the billions of dollars. within Life Sciences companies, they can range from ERP system implementations to Quality systems to clinical trial management systems (CTMS), to lab systems. The cost of the failures isn’t just the cash outlay to vendors but includes internal resource and opportunity costs and can be in the hundreds of thousands to millions of dollars. Here are some examples of what can go wrong with IT system projects and then some suggestions on how to improve your chances for success.
SaaS Adoption Will Lead to Compliance Issues for Life Sciences Companies
SaaS (software as a service) systems appear to be the panacea for organizations wishing to reduce their overall IT costs and the burden of managing IT departments. Making IT someone else’s problem seems ideal when one’s core business is anything but IT: SaaS solutions allow companies to outsource the technology and get access to new functionality through frequent software updates. SaaS vendors position themselves in such a way to make it appear that with the ‘click of a button’, functional area managers can begin to use systems that used to take months to implement. However with systems subject to 21 CFR Part 11 compliance and validation in the life sciences space the companies must validate for intended use. The vendor cannot meet this requirement without some level of validation effort on the part of the life sciences company.