Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo Especially for content not in the forum
Such as files in the Cove "Members" Directory
Social Distancing - It's not just YOUR life - It's ALL of OUR lives!
Me <——————— 6 Feet ———————-> You

Validation of eQMS - Cloud based out of the box solution

#1
Good morning!

I have been tasked with the validation of our eQMS, which is a cloud based out of the box solution. As part of the validation, we need to create our own user requirement specifications (URS) and Process Qualification (PQ).

I have several questions that I am struggling to answer, and would greatly appreciate assistance.

1) For the PQ, should observed results be a screenshot, or is just stating the result acceptable?
2) For the URS, how would risk be assessed e.g. 'authorised reader shall be able to access and read controlled documentation within the system' - would this be high, medium or low?

I suppose the biggest issue we would have with if the system went wrong would be that we couldn't up-revision any documentation without being in breach of our work instructions. We do not rely on the system for anything directly relating to production or patient safety.

Thanks for your help
 

yodon

Staff member
Super Moderator
#2
You should always strive to have objective evidence that the test expected results were met. *Judicious* use of screenshots can help. Bear in mind that the objective evidence should demonstrate a requirement was met. You don't need to capture every screen transition. Don't write requirements around the implementation, focus on your functional needs.

Risk, at least per 13485, "pertains to safety or performance requirements of the medical device or meeting applicable regulatory requirements." If you use a scale of high / medium / low, patient death would be high. You have to consider what the effects are if the software fails. You indicate no patient harm, so the likely failure would result in regulatory NC. You have to decide where that falls on your 3-level scale.

You mention PQ. To me, using the IQ/OQ/PQ paradigm:
  • IQ demonstrates the system is installed per mfg recommendations and per any of your requirements. Do note that if you are capturing PHI as part of the system (maybe feedback or complaints) then you should consider secureity as part of IQ. I also like to look at setup: are you configuring to enable compliance (is everyone admin or are security levels defined and enforced, is audit trail enabled, etc).
  • OQ is where I verify the requirements are met
  • PQ is rarely used; however if there are performance needs (e.g. 50 people hitting the tool at the same time, database capacity, response time, etc.) that's where I use PQ
 
#3
Thank you for the reply and for clarifying a few things.
I think my main concern is the use of screenshots in the documentation. I seem to find varying information relating to how many and how often to use.
 

LUFAN

Starting to get Involved
#4
I think my main concern is the use of screenshots in the documentation. I seem to find varying information relating to how many and how often to use.
You won't anywhere. That's up to you to demonstrate the correct amount of confidence in the software. When I did an eQMS, I believe I had close to 20 binders full of test scripts and matching screenshots. For every test script instruction, I had a screenshot at least demonstrating the software matched that requirement. Whether that's too much or too little is up to you to decide.

PQ is rarely used; however if there are performance needs (e.g. 50 people hitting the tool at the same time, database capacity, response time, etc.) that's where I use PQ
This is interesting to me. I've done a PQ on an eQMS after it was configured to better suit the needs of my QMS and after the OQ was done. The eQMS company called it their Conference Room Pilot but more formally referred to it as a PQ. I can appreciate without any deltas from the OQ, a PQ wouldn't be necessary.
 
#5
Does anyone have a template for ERP system Validation ( all very low risk activities which have a paper back up) or a sample validation protocol?
Thanks
 

MakingADifference

Starting to get Involved
#7
I have performed this a couple of times and have always kept it quite simple and high-level. I have treated it in the same way I would a Medical Device, focussing on the following:
Purpose
Intended Use
Requirements
Test Cases
Traceability between requirements and Test Cases
Conclusion.

Thanks
 

Tidge

Involved In Discussions
#9
Might be 21 CFR Part 11 Part 11 Electronic Records Electronic Signatures Scope and Application is useful.
Several risks can be formulated based in 21 CFR Part 11.
I want to insert a note of caution: 21 CFR Part 11 does not introduce new requirements for non-product software systems, it merely describes the expected mechanisms for implementing a software system which provides the functionality for keeping electronic records and recording electronic signatures. Another way of saying this: Part 11 isn't introducing "new risks", any risks are coming from the regulated (or certified) element of the system that is being automated. E.g. the risk of losing (paper) records is always present, it didn't come from 21 CFR part 11.

Don't get carried away with "Part 11" when implementing ERP systems that have little or no bearing on regulatory requirements. There is value in using 21 CFR 11 as an informative source for some functional implementations/requirements, but it should never be at the beginning of a validation (where the risk analysis begins).
 

sreekiran14

Starting to get Involved
#10
Hi Lufan, I am validating Cloud based eQMS. I would like to know
1. Whose responsibility is to develop a Risk Management Plan? What a Risk Management plan contains for Cloud based systems?
2. Vendor is suggesting to utilize their IQ/OQ/PQ that they performed, is that acceptable by the FDA?

Thank you
 
Top Bottom