Validation and regulatory compliance of free/open source software - Open Source Software in Life Science Research - page 476

import restrictions being imposed or, in the most serious cases, US FDA
Consent Decrees [10], which have required life sciences companies to
implement expensive corrective and preventative actions and pay
penalties in the range of hundreds of millions of dollars for non-
compliance.
More importantly, the failure to appropriately validate a computerised
system may place product quality and patient safety at risk and there are
several known instances where faulty software has led to indirect or
direct harm to patients.

21.3 Who should validate open
source software?

Although the regulations do not provide details on how software should
be validated, those same regulatory expectations (and numerous
enforcement actions by various regulatory agencies) make it clear that
regulated companies (i.e. pharmaceutical, medical device, biotechnology,
biological and biomedical manufacturers, CROs, etc.) are accountable
for the appropriate validation of such software applications.
Industry guidance such as the widely referenced GAMP ® Guide [11] is
increasingly looking for ways in which regulated companies can exercise
such accountabilities while at the same time leveraging the activities and
documentation of their software vendors or professional services
providers (systems integrators, engineering companies, etc.). The
GAMP ® Guide provides pragmatic good practice for the risk-based
validation of computerised systems and is accompanied by a number of
companion Good Practice Guides. Although all of these recommended
approaches can be applied to the validation of open source software,
there is very little specifi c guidance on the specifi c validation of such
software.
Following one of the key concepts of the GAMP ® Guide - leveraging
supplier involvement, activities and documentation - presents a signifi cant
challenge for the validation of open source applications where there is
often no software vendor with which to establish a contractual
relationship and often no professional services provider who will assume
responsibility for implementing and supporting open source software.
There are examples of third-party organisations providing implementation
and support services for open source infrastructure (e.g. Linux Red Hat) or
applications. This may not, however, be the case for many new or innovative

￿ ￿ ￿ ￿ ￿