Qualio is a web-based, multi-tenant system that runs identically for all customers. It would therefore be redundant and potentially a waste of your time to repeat the functional tests already performed and documented by Qualio with tools like CircleCI and GitHub.
The only additional required / recommended testing comes from the specific system configurations you build into Qualio, and how they might impact your business processes and, by extension, the safety of your products and patients. Regulators like the FDA encourage a critical-thinking and risk-based approach to testing so it’s appropriate to the business-specific risks you identify, and isn’t overly excessive or burdensome.

An eQMS is an example of low-risk, non-product software with no direct impact on patient safety, product quality, or the integrity of the data underpinning these areas.
Your auditors will expect your assurance activity to be focused proportionately based on the systems you’re using, and an eQMS naturally demands less rigorous assurance than a high-risk system for these reasons.

No. Any modern software vendor providing IQ, OQ and PQ documentation as standard is simply sticking de rigeur to 20-year-old outdated validation practice. Both FDA CSA and ISPE GAMP guidance have now diverged from this approach, understanding that ‘linear’ documentation like IQs, OQs and PQs doesn’t reflect the non-linear, agile nature of modern software development.
Simply put: a vendor pushing this approach is only interested in appeasing customers worried about ticking old boxes – and not interested in offering a modern, streamlined and least burdensome approach for their customers.

The foundation of modern CSA is demonstrating that the system meets your requirements for intended use with a minimum of burden and effort. With that as the basis, you’re proving that the system meets the requirements defined during its inception and in subsequent updates.
If we map the traceability of requirements to functions to testing (which is what we used to do with IQs/OQs/PQs), we have proven our system is suitable for use leveraging our software development lifecycle process.
From there, you then configure the system to meet your needs and manage the configuration. Our partnership as your eQMS vendor ensures we are managing the system for you as the experts in QMS software.
Ditching time-heavy documents like IQs, OQs and PQs saves you time and lets you start extracting value from Qualio more quickly.

Qualio provides test scripts and documentation on requirements for the system, and you can format them as your company and your policies require.

Not only is the Qualio team highly experienced in modern quality and compliance, we aren’t afraid of listening to industry experts and third parties to keep our approach aligned with the latest trends and expectations.

We asked Sion Wyn, editor of GAMP 5, FDA advisor and a leading expert on computerized system compliance, to interrogate our software assurance approach and advise us on the direction of current updates from the FDA and ISPE.

You can hear Sion’s thoughts on our assurance approach here.

And you can read our breakdown guide of all the threads of modern computerized system compliance, and why we do what we do, here.

You still have a validated instance of Qualio, but with the recent product updates in October 2022 we recommend you review the product updates and evaluate for impact to your organization. New feature evaluation will be ongoing throughout our partnership.

Correct. Customers do not need to additionally test software functionality that we have already tested.

We have reviewed that guidance, yes. We have chosen to align with GAMP, and there is no conflict with that standard and GAMP.

Yes, we have always had a part 11 assessment in the pack and we have updated that to improve the traceability into the actual system requirements.

Yes, that is correct. But this is driven in practice in how you manage your configuration and business processes. Repeating the functional testing for the software does not mitigate process risks, only controlling the processes appropriately does that.

Thanks for this feedback, it is very helpful. We do release a "version" with every deploy, and that version provides traceability on our side all the way back to the released piece of code.

There is zero value in a "PQ", unless you have determined that the process you're using Qualio to support can somehow cause a patient injury or product quality problem. To better align your assessment process with ours, I would recommend that you include in your re-val SOP, that bug fixes are not changes, they only return the software to currently expected behavior, and the vendor (Qualio) has tested the fix. Since your use of the system is focused on your configuration in your instance, changes that do not affect that configuration do not require any additional action on your part (or maybe just an internal SOP update).

Our validation has gone through many audits since our shift to the CSA approach and has been accepted by all types of auditors.

Yes, some are still in the works but for the most part, those materials have been released and can be accessed from the Help Center.

EU and ISO 13485 only require that you validate the system; they do no specify how that gets done. GAMP is a globally recognized approach to validation.

Qualio provides test scripts and documentation on requirements for the system, and you can format them as your company or your policies require.

The Qualio Feature Validation document will always point to the overarching Features Validation folder in Qualio’s Dropbox. The most current release version will be at the top of the list. Because your Validation Summary Report will be the only validation document that may be updated with new releases, compare the Effective date of this document with the most recent release train.

With the move to cloud computing, the idea of multi-tenancy was born. Multi-tenancy means there is only one application running, and all customers are using it. Customer data, however, is segregated logically in the software instead of physically with hardware; customers can, and should, continue to expect privacy of their data, though it does not physically reside under their control.
Multi-tenancy is how cloud software can be updated quickly and easily without requiring customers to upgrade hardware and mess with software updates. That means users get new features and bugs get fixed quickly, which leads to better product adoption and user satisfaction.
It also means that Qualio performs validation tests prior to releasing new features and any update, lifting the burden from our customers.

All customer instances, whether “production” or “sandbox” are using the same application and database. The actual data is segregated in software, so they are not “connected” to each other, just like any other customer account. Your sandbox can be validated the exact same way as your “production” instance, and other than any test data you create, the functionality will be exactly the same. This is most useful in developing new templates or workflows, as you can “experiment” in a sandbox without creating any data in your “production” account. You will have to recreate anything you want to use in production, as the instances are not connected.
Having a sandbox gives us the ability to leverage feature flags to turn on new features to test out and also for you to decide how you want to implement new features in your business, and update internal SOPs.
For updates to existing functionality, we will eventually “turn it on” for everyone, and the changes will be available in your “production” instance. Because of the nature of multi-tenancy and SaaS in general, there is not an option to not accept updates to functionality in most cases. Some features are permanently “feature flagged” however, so you can choose not to use those.

The API changes how data comes into our application, but not the behavior of the application itself. You should document the configuration of the API and any set up of the system on your side that you’ve tied to the API. The responsibility for risk assessment and validation of the API resides with you, the customer. The API artifacts are covered on our side in our automated testing routines.

We use a SaaS standard approach called “feature flagging” (or an “on/off toggle” for a specific product feature). This means that some updates can happen to areas of the software that you may not use. There is no regulatory expectation that you validate areas of the application that you’re not using, or cannot even see because they’re behind a “flag”. This is important to understand, because you will see new “versions” happening in the product releases tab of our application, but this does not mean you’re no longer in a “validated state”. We make clear the “version” every time we do bug fixes. There is just one “version” of Qualio, and the releases and such you see there are minor in nature (unless we notify you otherwise).

Yes; the User Management feature Test Plan details testing of each role.

The version number is available in-app, located in the product changes section. The number in the version is the date it was released. In the example below, it was released on December 22, 2021.

We follow Agile development methodology, use design control principles in development, and GAMP guidance for validation.

No, the system risks are all mitigated. As the customer, you will incorporate your business risks as you manage the content and user access for your instance.

Yes, we have updated the supplier qualification record, as well as made copies of our ISO certs available through the Help Center links.

Sounds like you have it covered. Those tools (such as CAD) should be included in your supplier management program, with the risk assessment of the use of said tools driving the level of control. I have always treated those tools as "Class 2" - or indirect impact to my product - tools, then done a short, documented assessment of their capabilities based on our intended use. If they have direct impact, then I'd qualify more deeply, to include a full process FMEA supporting their use in my manufacturing processes.

You can always find the link to the root Dropbox folder from the Validation Resources article in the Help Center. But here is the link for your convenience.

Validation speed depends on your review of the documentation along with resources available to review the documentation. Your validation documents will be available in your account to review within a day or two of your kickoff call.

You'll notice that the Validation Plan in the validation pack ask for references to specific SOPs. If these SOPs do not yet exist - no need to worry! You can remove the specific document ID callout in the validation pack documents. For example, in the Validation Plan, you could say "The definitions from the Risk Management SOP are used to categorize the process failure risk."

These procedures do not need to be in place prior to completing the validation and can be developed later.

Ultimately, you should be using Qualio to manage your document stack, including Validation records. These documents should be saved in Qualio and routed through the review/approval workflow to become an effective document. Then Smartlink to this document from the Validation Summary Report. These documents, combined with your audit trail, will serve as your proof of QMS validation. The Executing Qualio Validation article contains more details.

Qualio employees should not act as reviewers or approvers on any of your documentation in your QMS. Qualio employees do not fall under your business processes and are here to provide guidance only. Any changes made to any validation documentation should be reviewed and approved by your internal stakeholders only.

For 21 CFR Part 11 Compliance 11.100(c), persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures. The certification shall be submitted in paper form and signed with a traditional handwritten signature, to the FDA at the:
​
Office of Regional Operations (HFC-100)
5600 Fishers Lane
Rockville, MD 20857
​
​This link includes two sample letter formats that can be provided to the FDA. This letter is NOT the same notification for signing up on the Electronic Signature Gateway (ESG), but just an informed consent that is established to equivocate the electronic signatures used in Qualio to traditional wet ink signatures of a paper-based system.

Dropbox is an approved supplier for Qualio. Dropbox allows Qualio to add new folders for new version releases without needing to update all customer documentation for each change. Because Qualio cannot invite all our customers into our internal systems we are leveraging Dropbox as an easy way to share these records with our customers. Supplier qualification documentation is available upon request.

We recommend keeping the configuration document current. But this is ultimately a customer’s responsibility and they can determine what triggers an update. A good way to maintain this document would be to utilize the periodic review functionality that’s built into Qualio documents.

Onboarding customers can leverage their COM to create this document and document a baseline configuration if they plan to implement Suppliers or Design Controls. Within the Support Documentation folder in Dropbox, Qualio provides a template for this Configuration document that can be utilized by you at any time. This template can be used post-onboarding if features such as Suppliers or Design Controls are implemented later.

We recommend marking the section as N/A in order to preserve the details for potential future implementation of that feature.

Suppliers and Design Controls, with their integration abilities and policies that can be built into the system based on end user needs, would be considered configurable features. Nothing in the platform “backend” can be customized for individual customers by the customer or Qualio engineers. Documents, User Management, Training and Events features have been included on the configuration document for customer convenience as some customers have demonstrated an interest in documenting settings and templates.