Using Google Drive/Docs

Randy

Super Moderator
validation

ISO 9000:2015
3.8.13

validation
confirmation, through the provision of objective evidence (3.8.3), that the requirements (3.6.4) for a specific intended use or application have been fulfilled
Note 1 to entry: The objective evidence needed for a validation is the result of a test (3.11.8) or other form of determination (3.11.1) such as performing alternative calculations or reviewing documents (3.8.5).
Note 2 to entry: The word “validated” is used to designate the corresponding status.
Note 3 to entry: The use conditions for validation can be real or simulated.


Does it work the way it's supposed to? YES - NO

Does it store your doc's? YES - NO
Can you retrieve your doc's? YES - NO
Does it allow you to update your doc's? YES - NO
Does it allow you to track updates? YES - NO
Can you block access to out of date doc's? YES - NO

I'm an auditor, answer those and I could be happy ....And you don't have to make me or any other auditor happy, you've just got to meet ACTUAL requirements. Just show me the "beef"
 

DamienL

Involved In Discussions
Thanks everybody for your input. I had a quick call with one of the (very helpful) authors of the CSA draft guidance and he basically echoed Randy's comments (but it was still reassuring to hear it directly from the FDA). The main concern I raised was around the 'must be validated before issuance' bit in 820.70(i) in light of rolling updates from cloud service providers. We discussed the option of employing regular (but after-the-fact) assessment/testing as a way to ensure that the overall system maintains a validated state. He didn't consider this approach to conflict with 820.70(i) provided it was part of a pre-defined risk-based validation strategy for the system. Obviously, if the potential for product/user risk exists, then this approach wouldn't be acceptable, but there was nothing in the application as described to him to suggest that level of concern.

So for the application I'm thinking of (Google Drive or similar for Doc Storage + DocuSign or similar for eSignatures + accompanying work instruction) a validation approach might look something like the following. And Karen, I don't believe your application of Google Docs for maintaining logs would be much different:
  1. A once-off documented Validation plan justifying the risk associated with the application and outlining the validation strategy through its lifetime. This would include risk-based justification as to why periodic review/testing is sufficient in lieu of conducting a prospective validation at each update.
  2. Full validation initially. Because this isn't a high risk application, I think a User Requirements document, a protocol with specified test scripts (per Randy's suggestions above), and a final report would suffice.
  3. Periodic review (e.g. monthly) to ensure changes pushed out by the service provider haven't broken the system. Ideally this could be done via an automated test script to minimise the effort involved (my next problem to figure out, hopefully it doesn't scupper the whole approach). And in line with the CSA guidance, no detailed reporting, just a simple record of the review would be filed.
  4. Full revalidation annually or when aware of major updates.
So if you're thinking of doing something similar, I hope this is of some help. And please let me know if you'd recommend anything different in the approach?
 
Last edited:

SteveJ

Registered
ISO 9000:2015
Does it work the way it's supposed to? YES - NO
Does it store your doc's? YES - NO
Can you retrieve your doc's? YES - NO
Does it allow you to update your doc's? YES - NO
Does it allow you to track updates? YES - NO
Can you block access to out of date doc's? YES - NO

I'm an auditor, answer those and I could be happy ....And you don't have to make me or any other auditor happy, you've just got to meet ACTUAL requirements. Just show me the "beef"

I think Randy has the best response for this situation. The way you validate the software is up to you. Having a little scorecard with these Yes/No works very well, as long as your Yes/No's meet the standard. You can go further if you want, but that's up to you. As long as whatever you do validates the software you're utilizing. The language does not have to match, but as long as the fit, form and function are identical, it doesn't matter. We call incoming material that is out of spec nonconforming material whereas the standard a nonconforming material is coming from our production line. It doesn't matter as long as your definitions are clear. You can go further if you want, but that's up to you. As long as whatever you do validates the software you're utilizing.

The thing that we did while going through our ISO certification was we made sure that our ISO Systems matched what we are currently doing. We didn't wanted to add 100 new processes over something that we're currently doing and would meet the standard. We did add a couple, but they are minimal. Look at what you're currently doing and ask yourself if it meets the standard as it is right now and then capture that in your processes. You'll worry a heck of a lot less if you're ISO system is matching exactly what you're doing now. Less change, people will have an easy time during audits, etc. Don't reinvent the wheel, just add a few new features.

My two cents, I hope they help.
 
Top Bottom