Question
We’re currently using GitHub for our code repositories. Now we’ve heard that this sort of software needs to be “validated”. What does that mean? Do we have to write tests for it? Do we need to self-host everything, i.e., move to GitLab? What about self-developed software like an internal project management tool - we’ve heard that we have to create a ton of documentation around that so it may not be feasible. Help!
Short Answer
Don’t panic :)
Yes, you have to validate software and it feels like overhead, but it’s manageable and not a huge effort. Write down your intended use for each tool with your requirements, risks and some tests and you’re done.
Long Answer
Validation of computer software is specified in section 4.1.6 of ISO 13485:2016. The main messages there are:
- Validate software which is used in the quality management system prior to use and after changes.
- Activities should be proportionate to risk.
So which software does this include? Software used in the quality management system is kind of a vague definition. More appropriately, you should understand this as “software which is used in developing your product”.
This includes software like GitHub, your IDE, your QMS software if you have any and maybe communication tools like Slack, if you mention those in any of your SOPs.
Why Software Validation?
Now the obvious question is: Why would anyone do this? Can’t we just use our software and get back to work?
I agree with you. As an auditor put it: “Software validation is where the 13485 went over board and became unreasonable.”. Well, thanks for that. Let’s see what we can do about it.
The goal of software validation is to ensure that crappy, broken or unnecessary software doesn’t get used in your company. Now you may think: If your employees select crappy software, haven’t you hired the wrong people in the first place? I wholeheartedly agree with you. No software validation procedure on this planet will save you when you’ve hired the wrong people.
Now I will stop ranting and tell you what you need to do to comply with ISO 13485:2016.
Software Validation Procedure
You need three documents:
- A list of computer software in which you keep track of all software you’re using at your company. You’ll only have one list.
- A template for a validation plan which you’ll need to fill out for every software on that list. So you’ll have many of these, one per software.
- A template for a validation report which you’ll also fill out for every software on that list, unless you determine that you don’t need to test it. More on that later.
Let’s see what those include.
Computer Software List
Your computer software list will look somewhat like this, I added a new entry for GitHub:
| ID | Name | Manufacturer | Bug tracker URL | Needs validation? | Last validation | Decommissioning |
|---|---|---|---|---|---|---|
| 1 | GitHub | GitHub, Inc. | yes | 2020-05-17 |
GitHub doesn’t have a public bug tracker of known issues list, so we just leave that out. And as it’s still in use, we don’t enter a date in the “Decommissioning” column.
We’ve just assumed that it needs validation and that we’ve validated it already on “last validation” date. Of course that’s not true, yet. I’m just skipping ahead, it’ll make sense when you’ll see what we need to enter in the validation plan:
Computer Software Validation Plan
Your plan should cover the following information:
- Software Identification: Name of the software, version (probably not available for GitHub), manufacturer, bug tracker URL.
- Intended Use: Describe how the software will be used in the context of your company.
- QM Relevance: Assess whether it’s relevant to your product or QMS. If not, you’re done here and don’t have to continue.
- Criticality Rating: The idea here is to get a feeling of how critical this software is for your company. The less critical it is, the less your validation efforts can be. I suggest to define a few categories (low, medium, high) and also use the GAMP-5 categories.
- Risk Analysis: List potential risks of this software and how you plan to mitigate them.
- Requirements: List your requirements for the software, basically an expanded version of the Intended Use.
- Validation Procedure: Your decision on how to validate the software. For high-risk and/or self-developed software, you’d want to test the requirements and document that. For low-risk software, you could just state that you “validate it during usage”.
Computer Software Validation Report
If you’ve decided to test the software, you just copy-paste the requirements here, add test procedures and acceptance criteria and go through the tests. For each test, document whether it was a Pass or Fail. Add screenshots if appropriate.
Done! That was easy. I’ll try to add a template with GitHub as an example in the future.