Using Google Drive/Docs

[KarenA01]

Show me where it says that the "document control" software has to be validated because I don't see it, it just references the "computer software" to operate controls and equipment....You're probably reading too deep or your consultant is spacing out.

It comes from the 13485 standard:

4.1.6 The organization shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application.

That would imply software used for document control needs to be validated.
-Karen

 

[Randy]

That would imply software used for document control needs to be validated.

Yep, that's all it says "validation of the application of computer software " and not validate the software how you create and manage the documents themselves

You're reading too, too deeply and starting to make a mountain out of a mole hill

 

[KarenA01]

Yep, that's all it says "validation of the application of computer software " and not validate the software how you create and manage the documents themselves

You're reading too, too deeply and starting to make a mountain out of a mole hill

I would be VERY happy to be to wrong!!! If after you read this and you still think I am over interpreting this please let me know.

Perhaps you think I mean validating all the functionality of google workspace? No I don't mean that... I mean our use of the software.

I don't think it means means validating the software you use to create the documents (word, Acrobat etc) itself...

But I think managing ACCESS to the documents would be a use of the software for the QMS that would seem to be included in:

The organization shall document procedures for the validation of the application of computer software used in the quality management system.

Our 13485 consultant has said that 13485 auditors do expect validation of the use of software used to manage the QMS...

In my case we are using the features of google drive to allow users to display (read) our SOPs but not download or print to ensure they only have access to the current version...

I would think that clause of 13485 would require that we show it does that, no?
It's easy enough to write a script and do a validation where a user tries to download or print an SOP (the only way is screen capture!) and record the results. That seems straight forward.

We use google sheets to maintain inventory and various logs... and so that may need to be validated for that use though I am not sure how we would do that

Besides access control, we are using google drive to store QMS documents and records long term... I would think we need some way to show that the records remain unchanged and accessible over time... something else I am unsure how to do.

We don't have paper copies of our SOPS and other documents only electronic. We do scan records with wet signatures and store them on the server - I am saving the paper copies of teh records just in case, but we would rather not!)

So if you don't need think I need to do the above please let me know... again I would rather not!

- Karen

 

[DannyK]

ISO 13485:2016 clause 4.1.6 requires that you validate computer software used in QMS based on risk.
You could create a procedure to define the risk levels for QMS software.
The best practice would be to list all QMS software in use and indicate what it is being used for.
Then apply a risk level to each QMS software that will determine if you need the validate the software.
If the software is used to store documents, you can normally assign a low risk rating to the software and justify that it does not require validation.
I hope this helps.

Danny

 

[Tidge]

Yep, that's all it says "validation of the application of computer software " and not validate the software how you create and manage the documents themselves

Creating the documents falls clearly under the "typewriter rule". Managing the (lifecycle of) documents is part of a 13485 quality system, as such if a tool is used for it, the tool has to (at least) be assessed for validation.

I won't pretend that there are many peculiar paths that folks can follow along the path to using software to implement elements of a QMS. This is often the case: as soon as a computerized system is being used for documents, folks using that system will find many ways to use it that fall rather squarely into the realm of Quality System duties, such as

• Review, Approval, Distribution of documents (including removal of obsolete documents) per 21 CFR 820.40(a), 13485 4.2.4
• Maintaining records of document changes, per 21 CFR 820.40(b), 13485 4.2.4

(for now, I'm strictly limiting my bullet points to documents for the QMS, and not to any other things like DMRs, DHFs, DHRs, verification/validation executions/reports, etc.)

These would all be electronic records, and so far I'm not even considering the possibility of electronic signatures. In the US, these put us firmly in the realms of 21 CFR part 11, where again we would be obligated to assess the (possible, likely) use of the system to be implementing either/both ER and ES, and if it is doing either of those things we will have to have some assessment of how well it does those. FDA enforcement is somewhat discretionary on this point, but I wouldn't put such a slow pitch right over the plate. If the 21 CFR 11 elements are taken seriously, I can't imagine any other group (e.g. under MDSAP) taking issue with the question.

 

[DamienL]

Thanks for the response Karen.

You imply validating google Drive and sheets would fairly easy/quick.... How would one go about doing an acceptable minimal validation on Google Docs/Sheets?-Karen

I think the recent CSA guidance from the FDA provides some light touch suggestions (based on risk). Also, I’m sure you’ve considered this, but for your logs, maybe you could just use Excel sheets in write-protected folders, instead of Google Sheets?

But as you likely know Docusign sells a part 11 compliant electronic signature product... so somehow the issue must be dealt with, else they would not be in that business.-Karen

As far as I know, DocuSign/AdobeSign, etc will have the paperwork for 21CFR compliance done before they roll out the updates to their customers. Not an option for us as too expensive.

 

[DamienL]

You're reading too, too deeply and starting to make a mountain out of a mole hill

Thanks Randy. I 100% take your word when you imply FDA wouldn't expect this much detail (enforcement discretion, etc) - not disputing that for one minute. It's just that I also have to convince internal stakeholders that this Doc Control solution would be fully compliant with that line in 820.70(i) - that changes "be validated before approval and issuance". Plus we will have 13485 certification auditors to contend with, and I'd bet eyebrows will raise if we're allowing software updates to be implemented without having assessed that our doc control system remains in a "validated state" (we could do that assessment shortly afterwards, but we couldn't do it "before issuance"). At the moment, I just can't square that circle, but really want to use this as a doc control solution.

Just to clarify - the application I'm thinking of is using Google Drive for doc storage and DocuSign for eSignatures - the 2 combined plus an instructional procedure would be our Doc Control system, and per the QSR and 13485, this would need to be validated. Like Karen says, not validating the software itself, but our application of the software. I think the validation would be quite straightforward - e.g. for Drive, it would be just like you said earlier "Can you access what you need, when you need it, in the required format? YES or NO?". However, the problem lies with the continuous pushing of updates in light of the requirement that changes "be validated before approval and issuance".

 

[DamienL]

..........you can normally assign a low risk rating to the software and justify that it does not require validation.

Thanks Danny. Per the FDA's CSA guidance, I don't think you can justify no validation for low risk. You can certainly use the risk to minimise the validation activities, but it would still need to be validated. And the problem with validation is the continuous updates. So same problem for my application (Google Drive for doc storage plus DocuSign for eSignatures) as Karen's application (Google Sheets) - how to handle continuous updates while staying compliant with the 820.70(i) requirement that changes "be validated before approval and issuance".

 

[KarenA01]

Just to clarify - the application I'm thinking of is using Google Drive for doc storage and DocuSign for eSignatures - the 2 combined plus an instructional procedure would be our Doc Control system

Before we decided to go with an ERP that was exactly what I was planning to go with for 13485 registration. With the docs only available for viewing on screen and not printing or downloading... in fact that is what we are doing right now without E-Sigs (we just got 9001 last summer), saving the wet signature approvals paper.

If the ERP solution for documentation turns out to be too unwieldy we might still wind up with that in the long term, though I expect the ERP should take care of most, if not all, of what we use google sheets for.

BTW the advantage of use using google sheets over Excel spreadsheets is that you get an audit trail... And in any case with office 365 you can still have update issues.

-Karen

 

[Jen Kirley]

I agree that ISO 13485 stipulates the validation should be based on risk. I question whether Google Docs applies, based on the nature of this service. It is not an enterprise software package, nor is it a specialty like calibration or maintenance management.

That said, it has been my experience that validation could include retrieval of records, a procedure for which is required (4.2.5). When my IT group repeatedly asked Google how this is controlled (Who do you call/contact if a record vanishes or is accidentally deleted?) they received no response besides a silly flyer-type of document proclaiming they had x backups on x global server arrays... blah blah blah. Not what we wanted to know.

So, given the importance of record retention you could validate for that using a test. I do hope they in Google have figured it out since we tried it.