Validation of VCS software for document control? Small medical start-up

[SterileField]

I'm working with a small medical start-up to assist them in implementing a 13485 and 21 CFR 820 compliant QMS. As is usual, timelines are compressed and budgets are tight.

Because of the latter we're looking at "open source" version control software and, at the moment, SubVersion in particular for document control. Trac is also being looked at for the software-development side of things. It is likely that the repository holding the documents would also be the repository holding records as well and that SubVersion would thus be used for both documents and records.

My question(s) centres around the validation requirements of the FDA (21 CFR 11) and ISO 13485 (if any) for such software. How does this work? What's needed for such validation to show efficacy? Has anyone used SubVersion with or without Trac (or Trac with any other open-source VCS) and obtained approval from the FDA after demonstrating validation results?

Any assistance to nudge/shove me along the right direction would be greatly appreciated.



Mike

 

[Marc]

Any medical device experts that can help with this?

 

[Gert Sorensen]

Depending on whether you intend to use Electronic Signatures the requirements are a bit different. So, please tell us that.

In general, when validating software it is IMHO not that different to validating other processes. You need to:
Define your User Requirements up front
Create a validation plan
Test that the software meets your User Requirements - IQ, OQ and PQ (combine them if the validation is simple).
For your own benefit make a matrix of where the requirements are documented in your protocols.
Create a validation report that sums it up.

Make sure that you take into consideration the requirements in part 11 - they include things like: Access control, backup, audit trail etc. The tricky part is the need for a access log, and the requirements regarding E-signatures. But, they can be handled in most - or some - cases.

STAY AWAY from any thing that is not of the shelf software. That makes it so much more difficult to handle.

ISO 13485 adresses the need to perform software validation in 7.5.2.1

 

[SterileField]

STAY AWAY from any thing that is not of the shelf software. That makes it so much more difficult to handle.

Thanks for the considered reply. With respect to the above, can I assume that you do not recommend, say, Subversion for this use due to validation concerns? If so, can you offer any recommendations with cost-sensitivity in mind?

 

[Gert Sorensen]

Depending on the size of your company and the number of users that you intend to be using the system then you may actually find that the cost of using well reputed systems for document control is not all that expensive. Most of the accepted systems have a validation package that is optional which will be of value when performing validation to Part 11. The validation package is not a "fail safe" thing, you need to evaluate the software according to your requirements, but even so you may save a lot of time and the documentation will be a lot better than what most of us is able to conjure on our own.
When you talk about cost effectiveness of systems like these don't just look at initial cost. Look at the entire life cycle of the system, and look at the time that you save on your operations - that's also a cost.

 

[yodon]

I would not completely agree that you should avoid open source software. Our clients have used CVS for SW CM and various other open source tools for other aspects without any regulatory issues arising. (Unfortunately, none have used Subversion, though.) Often times, open source tools are more stable than commercially-available tools. You do have to be aware of what you're getting into. If you have a problem, for example, you likely have nowhere to turn for quick resolution. There are some service companies that can provide such support, but then it's more like going the COTS route.

I do agree that, if you're using such tools, validation is the right approach. As Gert pointed out, you'll need to define your requirements in order to validate. Remember that you're not validating the entire tool, only as it relates to your requirements. You should also do a risk analysis. You can extend the scope of your efforts and should be able to wrap up any Part 11 questions / concerns in the same analysis & validation.

I believe that if you have a good CM process, can show that Subversion is meeting your needs (requirements), and any risks are sufficiently identified and mitigated, that you would have a strong enough story for the FDA.

 

[mafjensen - 2011]

For software development you should consider Rational Team Concert (www.jazz.net). This is free if you have a team of up to 3 software developers, and after that the it is very expensive. But it is a pretty solid software (IBM) and you should be able to define a development process that will fullfill the requirements of IEC 62304.

For the rest of the documents, and the final release of software, a paper-system could be considered.

 

[curryassassin]

Check out Q Pulse. Although we have no experience of using this software, we had a demo and were extremely impressed with its capabilities for all types of document control, including audits, CAPAs, deviations. We could not fault it. It is marketed and used widely at the small to medium life sciences companies. It was also relatively inexpensive.

 

[icare2much]

I have also looked at SubVersion for document control but it falls short meeting the electronic signature requirements for 21 CFR 11.

From 21 CFR 11:
Sec. 11.200 Electronic signature components and controls. (a) Electronic signatures that are not based upon biometrics shall:
(1) Employ at least two distinct identification components such as an identification code and password.
(i) When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.


The issue is that SubVersion remembers your identity when you check-in or check-out a document. So subsequent check-ins do not prompt you for your password again.

I have heard of people "unchecking" the "remember me" option and making this action part of their SOP to get around this issue, but I can't see how that passes muster as it leaves no audit trail whether it was checked or unchecked.

Perhaps someone else has experience here in the Cove with it...

 

[Jerome]

We are a small (40 empl.) company (in the Netherlands) which also makes some medical devices.
For our document control I am also looking into Subversion as our software dept. is piloting with that as a replacement of Visual Source Safe.
For the software part it looks promissing and we'll be implementing it soon.
For the documentation of our entire QMS and product/project documentation I'll be investigating this tool in particular (don't want to many different systems which can do the same). Next week I'll get a crash course on the what-how-and-where of this tool.
I want to use it to move from our (explosively growing) paper archive to a digital one.
We want to use the digital signing capebilleties of Adobe Acrobat 9 Pro to do the signing of the documents.
Only a few key persons can then prep a document with acrobat for digital signing and all involved can then sign using acrobat reader (with user specific ID certificate) to sign of on the documents.
These will go into the Subversion to keep track of the documents and their history trail.

This way we only need a few Acrobat licences (Subversion is free) and can loose a bunch of archive cabinets
We think this is the right way for our situation.
For validation purposes we'll use a stable version of Subversion, validate our User requirements and freeze this version.
For the digital signiture in Acrobat, there is a bunch of documentation on the net and at Adobe. I'll need to verify it's integrity but as it is used in a 'closed system' I don't foresee many problems there.
I try to keep u posted on the outcome.

Just my :50cent:

Feel free to share on this matter