EQMS Validation

[SallyOV]

Hi,

I need to validate an eQMS solution. As I am new to this area, I would greatly appreciate your input. My current plan is to leverage the validation documentation provided by the eQMS supplier. Specifically, my general strategy is as follows:

1. Define the intended use and requirements of the eQMS solution.
2. Document a Master Validation Plan, including a justification of the required level of validation using a risk-based approach.
3. Execute test cases as part of the validation process.

Could you please confirm if I am on the right track?

Additionally, regarding the risk-based approach, could you provide any suggestions or examples of what a risk-based rationale might look like for an eQMS solution?
In general, is software used for QMS considered high-risk, or is the risk profile more closely tied to the level of confidence in the software?

Many thanks in advance for your assistance!

 

[William55401]

GAMP 5 approach suggested. Google and search functions on this site are your friends.

 

[Hi_Its_Matt]

I highly recommend reviewing and really reflecting on FDA’s (draft) guidance document Computer Software Assurance for Production and Quality System Software. Depending on the level of customization in your eQMS, you may have a smaller level of effort required than many people/companies have traditionally thought. There are also some great webinars on this guidance document.

 

[LUFAN]

Hi,

I need to validate an eQMS solution. As I am new to this area, I would greatly appreciate your input. My current plan is to leverage the validation documentation provided by the eQMS supplier. Specifically, my general strategy is as follows:

I'd use a combination of ISO 80002 to structure your document and CSA @Hi_Its_Matt linked you to execute your strategy.

 

[yodon]

I'll second the recommendation made by @Hi_Its_Matt . IMO, GAMP 5 is too heavy and is one reason (I think) that companies have shied away from software validation. It also doesn't fit all that well with cloud-based applications. (Of course, you can tailor it, I know.)

One thing I do recommend is to do an assessment of, in particular, how you have permissions. Document that you have established the principle of least privilege. You can set these things up with everyone being an Admin and that would defeat many of the built-in controls.

 

[Tidge]

I also concur, GAMP 5 is "too heavy" for something like an eQMS system.... the "scaling" of GAMP 5 is not a good fit for commercial software solutions not used in manufacturing.

 

[QuinnM]

Check out the IMDRF documents: Personalized Medical Devices – Production Verification and Validation

 

[srkn14]

I'll second the recommendation made by @Hi_Its_Matt . IMO, GAMP 5 is too heavy and is one reason (I think) that companies have shied away from software validation. It also doesn't fit all that well with cloud-based applications. (Of course, you can tailor it, I know.)

One thing I do recommend is to do an assessment of, in particular, how you have permissions. Document that you have established the principle of least privilege. You can set these things up with everyone being an Admin and that would defeat many of the built-in controls.

I'll second the recommendation made by @Hi_Its_Matt . IMO, GAMP 5 is too heavy and is one reason (I think) that companies have shied away from software validation. It also doesn't fit all that well with cloud-based applications. (Of course, you can tailor it, I know.)

One thing I do recommend is to do an assessment of, in particular, how you have permissions. Document that you have established the principle of least privilege. You can set these things up with everyone being an Admin and that would defeat many of the built-in controLC.

Curious to know what the other options are if we want to update our validation procedure to remove GAMP Methodology, appreciate input on the other best options we can implement as we arenot a manufacturing company.

Thank you for your time in advance.

 

[Tidge]

IMO most for most commercial software used by medical device companies, it is as simple as Plan-Do-Check-Act:

1. Define the intended use, and intended users
2. Recognize the (high-level) requirements and use scenarios
3. Detail the solution and its environment
4. Test the solution (in its environment) for its scenarios of use, as well as scenarios of misuse.
5. Once the software is determined to be suitable for use: Establish a life-cycle plan (for updates, bug-fixes, retirement)

There are a lot of potential subtleties, for example there may be particular requirements for identity, "electronic signatures", audit trails that could require more robust testing than other requirements. The "risk-based thinking" is really about the testing; requirements should only be as detailed as necessary to support the testing (for OTS software solutions that aren't built from scratch).

GAMP 5 pretty much has all these, but it has a peculiar (somewhat understandable) focus on categorization to drive specific deliverables with a level of detail that IMO clouds the intent of knowing that the business system is doing what you need it to do.

 

[srkn14]

So, if I understood correct its like one size fits all method of validating.

On the contrary, I was thinking for an option to change the extent of validation is based on the Rick levels "low, medium and high" which is like categorization based again.

Any feedback would be appreciated.

Thank you