Oops, I hit reply rather than reply to all
---------- Forwarded message ----------
From: Stephen Connolly <stephen.alan.connolly_at_gmail.com>
Date: 2009/7/30
Subject: Re: [FDA] approval
To: "Bolstridge, Andrew" <andy.bolstridge_at_intergraph.com>
First off, IANAL
As somebody who used to do computer systems validation for the pharma
industry... (before I went back to pure software development)
The requirements of the FDA are basically:
*'...computer systems used to create, modify, and maintain electronic
records and to manage electronic signatures are also subject to the
validation requirements. (See 21 CFR �11.10(a).) Such computer systems must
be validated to ensure accuracy, reliability, consistent intended
performance, and the ability to discern invalid or altered records.'
*So, what I always interpreted this to mean w.r.t. a source control system
is that:
- You must validate that your SCM is accurate & reliable... this requires
you to define what you mean by accurate... I would think something like,
commits are atomic, partially committed transactions will not be committed
and that the SCM is always in a consistent state... So take your SCM, create
a test repo, commit a big chunk of files, change some of them, commit the
changes and interrupt the commit while in progress (try a couple of ways,
e.g. ^C, yank network cable, pull power cord of client, pull power cord of
server). If following the SOPs you write (for system recovery, or what to
do when your workspace is corrupted, e.g. svn cleanup) and the system as you
have configured it (e.g. if you configured HA/drbd) you meet *your
definition of accurate*, then the SCM system you have chosen passes this
test.
- You must validate that your SCM has consistent intended performance..
again you need to define this... if your intended performance is that
checkout of a workspace containing no more than 1000 files each of which is
no more than 20kb will take less than 5 minutes, and committing changes to
10% of these files will take less than 5 minutes, then test that and confirm
you met what you defined your requirements to be.
- You must validate that your SCM has the ability to discern invalid or
altered records... OK, first off define what invalid records are... in the
case of an SCM, you would probably define these as corrupted records, a SOP
or cron job running svnadmin verify could probably meet the requirements you
define for discerning invalid records. Second problem is altered records...
well we can put hook scripts in place to prevent revprop changes, that
should stop people changing the past from a remote svn client... now we have
to worry about a single person who has admin access going in and modifying a
record... the rule the FDA seemed to follow was that if one person on their
own can effect the change... you fail... but if it takes two people actively
cooperating... you pass... so you probably just want a post-commit hook that
sends the transaction to a second server... if the second server has a
different admin from the primary and is configured to be write once, and you
have a SOP or cronjob for scheduled comparisons of the two repos... that
should cover that problem
The smart person will note that none of these concerns are unique to
Subversion.... in fact throughout I have just referred to a SCM... and none
of these refer to how the SCM is developed or sourced... in fact they all
relate to:
- What you say, up front, you want your SCM system to be able to do.
- How you configured your SCM system servers.
- What SOPs you put in place for managing your SCM.
- What validation you performed on the SCM system you chose and deployed,
and the SOPs you put in place for managing that SCM.
IMHO, do not worry about where you source your SCM. whatever SCM system you
use, you will have the *exact same* set of hoops to jump through... I
suspect that Subversion would be the easiest to jump through the hoops with,
but I could be wrong.
-Stephen
2009/7/30 Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
I found this from Google, it might help you with other aspects:
>
> http://linuxmednews.com/1018893577/index_html
>
>
>
> It appears that the use of OSS is orientated towards software used directly
> in medical devices, not used to develop that software.
>
>
>
>
>
>
>
> *From:* Eric Keller [mailto:keller.eric_at_gmail.com]
> *Sent:* Thursday, July 30, 2009 7:50 AM
> *To:* users_at_subversion.tigris.org
> *Subject:* [FDA] approval
>
>
>
> Hi everyone,
>
> I would like to introduce Subversion in our company processes... We are in
> the medical business and to sell our devices on the US market, we need the
> FDA approval. For getting this approval, we need to certify the software we
> are using. As subversion could be part of them I have to convince our BU
> that FDA clearance will not be delayed because of using an open source
> project!
> Anyway, I would be more than happy if someone in this mailing list also use
> subversion and gets its product through FDA inspection successfully.
> Feedback appreciated!
>
> Best Regards
> --
> Eric Keller
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2377001
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-30 17:08:58 CEST