Software for Quality Management Systems can roughly be divided into two categories. You can either purchase specialized regulatory software which has specific features for whatever regulated industry you’re in, or you can choose a generic software and attempt to re-purpose it as your regulatory software.
This is very similar to dogs: If you need someone to do your laundry, you could either bring in a specialized laundry dog who has been well-trained in doing laundry-specific tasks, or you could attempt to teach your existing dog how to do laundry. The latter option has the risk of your dog making mistakes and it will certainly be a time-intensive process. On the other hand, laundry dogs are often quite expensive.
So this analogy definitely works. Let’s see how it applies to QMS software:
Specialized regulatory software is purpose-built software with the exact set of features your regulated industry (e.g. medical devices) requires. So, for example, if one requirement is that you archive old documents for at least 10 years, specialized regulatory software will automatically keep your documents around for 10 years. However, one of many drawbacks is that specialized regulatory software unfortunately is often not sold in a transparent way (ours is different) - rather in an enterprise sales process which includes you filling out a contact form on their website, resulting in a very trustworthy sales representative reaching out some time later for a friendly sales call in which many vague promises will be made (“does the software also do my laundry?” - “sure, I’ll have our enterprise laundry integration team reach out to you to set that up. Just sign the contract now and we’ll get started”).
Now, generic software is very different for obvious reasons, just like your dog is probably very different from the specialized laundry dog I described earlier. What would an example be (of regulatory software, not of a laundry dog)? I’ve seen many startups use Google Drive as their QMS software. Staying with the example above of keeping documents around for 10 years, that would mean that you’d have to configure Google Drive to somehow store your documents for 10 years. This would probably be easy as you could just make sure that you don’t delete them (duh). Maybe also export them and save them somewhere else. But there are other requirements which are harder to implement.
Okay! So with those boring terminology things out of the way, let’s focus on how you can use Google Drive as your QMS software. And after that we should discuss whether that’s a good idea at all.
Google Drive as QMS Software: What Do We Need?
As with all QMS software systems, everyone makes a huge fuss about them while no one actually states which features they contain. Simplifying this for you (you’re welcome), the two main features you need are:
- You need to be able to review and electronically sign documents.
- You need to keep old versions of documents around.
That’s it. There’s nothing more to QMS software than those two things. Crazy, right? All those vendors out
there present their snake oil software like it’s the eighth world wonder, and in the end it only handles a
few documents.
(Okay, okay, there’s also requirements management software which is harder to develop and a completely separate topic. But let’s not get into that today. By the way, Formwork does that, too, and it’s really good at it.)
So how would you implement those document features in Google Drive?
QMS Document Signing in Google Drive
Easy. The reviewing and signing part would be solved by adding a table at the bottom of each of your documents. It would look like this:
| Action | Role | Person | Date | Initials |
|---|---|---|---|---|
| Creation | Software Developer | Dr. Oliver Eidel | 2022-11-16 | OE |
| Review | Software Development Lead | |||
| Approval | CEO |
Okay, so there’s a lot going on here. In this example, your document and record control process contains three activities: Creation, review and approval of a document. Each step must be signed (you can actually come up with your own steps - you could e.g. reduce these 3 steps to 2 in a smaller company). The creator of the document enters their role and name into the first row and then “signs” it by entering the current date and their initials.
Wait, what? That’s how a document in Google Drive is signed? By just typing your initials? No DocuSign or any other third-party, clunky, expensive software involved? Yep - at least for EU MDR compliance (this is not FDA compliant). The main requirement here is that you must be able to unique identify the actual person who did the signing. And that’s trivially possible by looking into the change history of a Google Doc, i.e. the person who typed those initials was actually the person who should have been signing the document there. Cool.
If you’re now slapping yourself because you’ve already built a super-clunky signing workflow in your Google Drive with some third-party tool, don’t worry. That’s okay. We all make mistakes. Maybe you can make things right in your next life decision, like when hiring a laundry dog to do your laundry instead of training your own. And if you now think I’m just making fun of you, I’m not - laundry dogs exist.
Alright, let’s move forward with the signing. In this case, the creator of the document (that’s me) would select the next signer, enter their name into the table and tag them in a comment in this Google Drive Document:
| Action | Role | Person | Date | Initials |
|---|---|---|---|---|
| Creation | Software Developer | Dr. Oliver Eidel | 2022-11-16 | OE |
| Review | Software Development Lead | Steve Wozniak | ||
| Approval | CEO |
(Imagine a comment hovering over “Steve Wozniak” in which Oliver Eidel has tagged Steve Wozniak and written “yo Woz, please sign this once you’ve finished designing the Apple I”)
Same for the last (third) signature. And so on, and so on. In the end, the document is signed and released.
Okay, so we’re done? Cool! End of post.
Not so fast, unfortunately. We still have a few problems to solve because Google Drive unfortunately isn’t a specialized QMS tool. The first one is that we somehow have to separate released (or rather, signed) documents from drafts. This is not trivial.
QMS Document Control in Google Drive
The problem is this: You draft a document, add a signing table at the bottom and everyone signs. The document is released, everyone is happy and people celebrate a document-signing party. But the next morning you wake up and a distressing thought pops into your mind: How do I edit this newly-released document if I want to make changes to it? Good thinking - those are also the thoughts I have when I wake up every morning.
So how do we solve this? The main requirement here is that you keep a copy of the released document around. So the infamous Google Drive Document Copying Situation begins: You have to create a folder called “Released Documents” (or so) and move your document there. Next, you create a folder called “Drafts” and you copy your released document into that. That’s where you’ll be making your changes.
Again, in other words: If you want to make changes to a released document, you have to copy it and make your (draft) changes to that copy. This will lead to you keeping your released documents separate from your drafts. Makes sense. This will also lead to a lot of copying.
Now, what do you need to do before making changes to your newly-copied draft document? The first thing is that you should probably remove the entries in your signing table below - because it no longer is a released document, right? If this sounds manual and painful, I’m with you! Welcome to setting up your QMS in a generic tool. That being said, Google Drive is not all that bad, as we’ll discuss in the end.
So you remove the signing table entries. And then you make all your changes and then the signing process starts all over again.
Cool. But now you have two signed documents: The old released one in your “Released Documents” folder, and the newly-released one in the current “Drafts” folder. Ugh! What to do?
“Easy”: You archive the old-released one by moving it into another subfolder and rename it to ensure that it’s no longer identified as the current-released version. How might this subfolder be named? You could create one subfolder per document which would contain the archived versions of that document.
As an example, if your document is called “SOP Laundry Instructions v1”, you’d create the folder “SOP Laundry Instructions” inside the “Released Documents” folder and move it there. This sounds clunky, maybe there are better solutions to this.
And, of course, you finally move the newly-released document (“SOP Laundry Instructions v2”) into the “Released Documents” folder. Cool, all done!
One thing to add maybe: You might want to add a table to the bottom of the document to describe the changes you’ve made in each release. Like this:
| Document Version | Date | Changes |
|---|---|---|
| 1 | 1970-01-01 | Initial release. |
| 2 | 1970-01-02 | Add more detailed definition of “laundry”. |
You might wonder: “Doesn’t Google Drive already track all of those changes?” - and you’d be right, it does! But there are three arguments against relying on Google Drive’s change history:
- The Google Doc change history gets cluttered with many changes.
- You might lose the change history when copying a Google Doc.
- Some auditors are dinosaurs and expect to see change tables. They get very confused if they don’t see one.
Taking these points together, I think it’s reasonable (albeit painful) to add a change table to each of your documents.
Okay, so we’ve talked about how to handle text-based documents in Google Drive, and that seems to work. What do we do it we need to store data in a more structured way? For example our software requirements list (check out our template to get an idea of how it looks) - a spreadsheet would probably make more sense there, right?
Entering Linked / Structured Data in Google Drive
A lot of your regulatory documentation ends up being lists. So this is not only limited to your software requirements, but also includes things like software tests, problem reports, CAPAs, and so on.
Creating spreadsheets for those makes a lot of sense. So you’d use Google Sheets for that instead of Google Docs. It’s all in Google Drive anyway, so it hardly makes a difference. The signing process there is similar to the one above: Create a signing table and have people write their initials into it. Also, all the other stuff applies: Archive old versions and include a change table.
That aside, is using spreadsheets a good idea for this sort of data? It depends. But all in all, it’s a viable solution. There are many more worse things on this planet right now - like global warming and Jira tickets.
The good thing about spreadsheets is that anyone and their dog / laundry dog is able to edit them. They’re also easy to export and customize.
That bad thing about spreadsheets is that they are terrible at linking data. And, in your technical documentation, you’ll end up having a lot of linked data. An example:
| ID | Description | Tested in Software Test IDs |
|---|---|---|
| SR-1 | Users can log in | 1, 2, 3 |
| SR-2 | Users can see their medical data | 2, 3 |
In this example, you have two software requirements and each of those are tested by multiple software tests. Software requirement 1 is tested by tests 1, 2 and 3, while software requirement 2 is tested by tests 2 and 3. I hope you see where this is going - you’re manually maintaining two tables (one of software requirements, one of software tests) and you manually have to maintain links between them.
This in itself is already bad because you have no way to automatically detect broken links. Like, if you change the ID of test 2 to test 99, how will you able to find all references to it and change those from 2 to 99? There’s no trivial way.
It gets worse when you want to create traceability matrices (auditors love them). They look like this:
| Software Test ID (rows) Software Requirement ID (columns) | SR-1 | SR-2 |
|---|---|---|
| ST-1 | x | |
| ST-2 | x | x |
| ST-3 | x | x |
This is just another way of displaying the relations of software requirements to software tests. An “x” in a table cell means that a software requirement is tested by the relevant software test in the row.
Now the huge problem of course is that your spreadsheet won’t be able to auto-generate these sort of traceability matrices. So you’ll have to create them manually. If you think I’m joking, think again! I’ve seen regulatory people in companies create these manually. Crazy.
Google Drive as QMS Software: Pros and Cons
Alright! Let’s sum this up, shall we? Even though my last point was a bit negative, Google Drive also has quite a few positive aspects.
Google Drive Is Cheap / Free
Most startups are already using Google Workspace (good choice), so using Google Drive as your QMS software ends up being free. That’s a huge plus for startups without any revenue or funding.
Everyone Can Use It
Contrary to setting up a QMS in GitHub or GitLab in which all users have to learn how to write markdown documents and use git (pain), Google Drive is very accessible. Even non-technical people can edit documents. This also applies to spreadsheets. In most other tools, customizing your “structured data storage” is tricky, like changing your Jira (ugh) ticket fields. Imagine a non-technical person doing that - it seems unlikely. But anyone can edit columns in a spreadsheet. That’s cool.
Comments and Suggesting Stuff In Documents Is Great
Google Docs is probably the best tool I know for collaboratively working on documents. In fact, I even recommend it to our Formwork customers if they’re still in the early stages of drafting their documentation and need many people to provide comments and suggestions per document. No tool comes close!
Signing Is Not-Too-Bad
If your goal is EU MDR compliance, signing documents is fairly straightforward by typing your initials (see above). If you’re going for FDA compliance however, you’ll likely need a clunky third-party solution.
All in all, this signing workflow is not too bad. There are certainly better ones (like ours), especially for batch-signing many documents in a short amount of time, but the GDrive signing workflow is still reasonable. Things of course get much worse when you want FDA compliance - you’ll have to manually send out sign requests with a third-party tool, mark the relevant areas in which people should sign, etc., etc., this will be a huge pain. In that case you could use Formwork because we have FDA-compliant e-signing. Or any other specialized tool really which is not shady. Here’s a list of non-shady tools besides Formwork: (end of list).
Linking Stuff Sucks
For table-based, structured data in your spreadsheets, linking that data between multiple tables sucks. Maintaining it becomes a Herculean task which includes manually generating traceability matrices. So much pain.
If you think this is a minor issue, think again. This problem, in my opinion, is huge and grows exponentially with the size of your technical documentation. Example: You have 20 software requirements. No big deal. Link them manually in your spreadsheets and everyone goes home at 5pm. But soon you suddenly have 100 software requirements. No one understands any longer whether all those links are correct and there’s chaos. People sleep at the office, like at Twitter after the Musk takeover, and edit spreadsheets.
This is the main reason for which I would advise against Google Drive (see conclusion below).
Archiving Stuff and Signing New Versions Becomes a Full-Time Job
Archiving documents is painful. If you think this only includes moving old document versions to a certain folder, that’s unfortunately not all. Imagine this scenario: You’ve updated five documents and want to sent them out for signing. For each document, you have to do the following steps:
- Edit change table at the bottom and describe changes.
- Remove signed initials in signing table.
- Enter new reviewers who should sign.
- Comment-tag them and tell them to sign (like I did for The Woz above).
- Get ready to move the old released version to the archive folder, and get ready to move this one to the released folder.
- Wade through your Gmail inbox which by now has been flooded by comment notifications to see which documents have been partially signed by people.
How long might this take for one document if you’re fast? 5 minutes? Now, with 5 documents, we’re already looking at almost half an hour of unproductive work, shuffling things around. That’s already bad. But if it just takes you 5 minutes longer per document, you’re already looking at an hour. And how about sending out 20 documents instead of 20? This is the Google Drive Document Copying Situation. Not cool.
This is the second-biggest reason I advise against Google Drive.
But let’s sum up first!
Summary: Google Drive as a QMS Software
Just as in our other QMS software posts, let’s sum up the relevant points here so that you can review this summary later if you’re looking into what tool to choose.
How to Sign Documents?
Write your initials into Google Doc / Sheet. EU MDR compliant, but not FDA compliant. FDA compliance will need a separate tool. This will slow down your signing workflow significantly.
How to Review Documents?
Create signing table. Comment-tag people so that they type their initials into that signing table.
Benefits of Google Drive as a QMS Software
- Cheap or even free.
- Everyone knows how to use it.
- Manufacturer is (mostly) not evil, especially in contrast to enterprise QMS software vendors.
- Collaboration features are awesome: Commenting and suggesting in documents is unmatched by any other tool.
- Signing is mostly easy if you’re going for EU MDR compliance.
- Data can easily be exported in an auditor-friendly format (pdf, docx, xlsx).
Drawbacks of Google Drive as a QMS Software
- Entering structured data and linking stuff between tables sucks and becomes very painful.
- The archiving and signing workflow can quickly become very cumbersome and labor-intensive once you want to send out multiple documents at once (the Google Drive Document Copying Situation).
Would I choose it?
The million-dollar question. Would I choose Google Drive for my QMS?
As a matter of fact, our company actually has a QMS - we also act as a medical device manufacturer if our clients don’t want to deal with regulation and want us to bring their product to market. And, in the early days of OpenRegulatory, our QMS actually ran on Google Drive! So yes, I at least chose it once in the past. We also used it for many of our consulting clients at the time. It worked reasonably well.
However, all the pain points of Google Drive caused us to develop our own QMS software, Formwork. And that’s what we’re using now.
But before you now get the impression “the dude is biased and this is simply an ad for Formwork”, I caution you to read on, because while I truly am biased, this should not be an ad for Formwork. There are reasonable scenarios in which Google Drive is the right choice. Let’s look at those.
If I would be an early-stage startup with no revenue or funding, going for MDR Class I compliance while not even being sure whether we’d want to bring a medical device to market at all, I would maybe choose Google Drive. Why? For class I, you don’t need a prior audit by a notified body, so many of Formwork’s features, e.g. its structured audit export, might not be immediately useful to you. Also, you don’t need a hyper-compliant document review and archiving workflow for class I audits. It’s mainly important that the actual content of your documentation is compliant.
If Formwork is not for you and you’re considering other enterprise QMS software vendors, I have a strong opinion on that: I would choose Google Drive over any other enterprise QMS software vendor. That’s because your data can easily be exported from Google Drive, so there’s no lock-in. All the other vendors (except us) have crazy lock-ins. The features they provide aren’t worth this risk, in my opinion.
If you’re still in the early stages of iterating on documents, like drafting your intended use with many people involved, I would use Google Drive. It’s too early to set up a full-blown QMS at this stage anyway.
In all other cases, I’d choose Formwork.
Meanwhile, we’ve introduced a free version of Formwork, so it may become a suitable choice in some of the scenarios above, e.g. when being a MDR Class I manufacturer with no revenue or funding - it’s free, after all :)