Steve,
You raise a rather large issue when you mention submitting distributions
for "FDA certification". Here I give some more insight on the subject. Note
that I'm grossly simplifying the FDA regulations for readability. This is a
complex subject.
Let's assume the software in question is of the type that must be
submitted for FDA clearance (even though not all medical software falls in
this case). Well, the company marketing and selling that software must, by
law, comply with the FDA QSRs (Quality System Regulations), as well as the
MDR (Medical Device Reporting) act by which a vendor must make a report to
the FDA when they learn about an event that did or could cause a medical
error.
This compliance is fairly extensive when it comes to in-house (non-OSS)
developed software, since it mandates "design controls", which among other
things involve documented verification and validation steps at each stage
of the development (Requirements, Design, Implementation and so on).
The OSS case is different: the vendor doesn't write the software but
simply wants to package it and perhaps add a few external enhancements to
maximize suitability and ease of integration into a particular market.
The vendor cannot audit the OSS development process. The only thing they
have is the code itself. (In the QSRs, this matter probably falls under
"Receiving Acceptance activities" and "Purchasing Controls". These require
evaluating the supplier of the software to make sure they have good,
documented development procedures, and auditing this supplier to make sure
they actually follow their procedures).
So, the vendor has only one option: compensate for the lack of "control"
(in the QSR sense) with inversely proportional quantities of analysis,
verification, validation of all aspects of the software.
To my knowledge, the FDA has no set precedent-setting way to deal with
this issue. I think the OSS paradigm puts a very large burden on the
vendor, and this may result in a very conservative attitude by the vendor
towards incorporating enhancements into their distribution and/or otherwise
letting it evolve.
Anyone else's experience/thought on OSS and FDA are welcome.
-JF
At 08:02 AM 8/6/99 -0700, Steve Doubleday wrote:
>Andrew,
>
>I was very interested to read your article on liability for open source
>medical software.
>
>http://www.salonmagazine.com/tech/feature/1999/08/05/anesthesia/index.html
>
>I agree that if individual programmers could be found liable for
>failures in software they wrote, that it would have a chilling effect on
>the development of open source medical software.
>
>[...]
>The other deployment model follows the example of Red Hat Software
>(www.redhat.com). Red Hat packages a distribution of Linux and sells it
>for a nominal fee. They add value in several ways. By testing all
>components of the operating system at selected levels, they assure that
>the distribution is stable. They provide some technical support as part
>of the package. The bulk of their revenue comes from the sale of
>additional technical support and services.
>
>This model separates the development of software from its implementation
>and support. I believe it will prove practical in the medical arena.
>The medical version of Red Hat would provide extensively tested software
>distributions and support services. In addition, it would submit its
>distributions for FDA certification as appropriate and would assume
>liability for the quality of the distributions. It would charge
>accordingly for these additional services. As you point out, the degree
>of liability to be assumed by any software company for its products is
>still being determined; this model merely suggests that it will possible
>to play by the same rules for open source software in the medical arena
>as for open- or closed-source software in any other arena.
>
>Any company that markets software is dependent on the quality of the
>development effort to produce software that has a minimal number of
>flaws and to respond quickly to problems. The paradox of open source
>development is that results can be better when the company does not
>directly control the development effort than when it does. All other
>things being equal, a company that re-markets open source software and
>services may therefore have a lower liability exposure than one that
>markets closed software.
>
>The strength of the open source development model begins at the
>technical level, and rests on improved quality, reliability, and lower
>cost. I believe that successful companies will be built that take
>advantage of these technical strengths while meeting the needs of the
>commercial market for medical software.
>
>Steve Doubleday
>[EMAIL PROTECTED]
>Kaiser Permanente Information Technology
>"My opinions are not necessarily those of my employer"
>
>
--
JF Lancelot, CliniComp, Intl. - mailto:[EMAIL PROTECTED]
_______________________________________________________
USA Tel: +1 (858)546-8202 Fax: +1 (858)546 0154
France Tel: +33 (1) 5543 0216 Fax: +33 (1) 4217 0260
