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

Open source software may come in many forms. At the simplest it may
be GAMP ® software category 3, with fi xed functionality with the
possibility to enter only simple parameters. It may be GAMP ® software
category 4, meaning that it is a confi gurable off-the-shelf (COTS)
application or, because of the nature of open source software it may be
customisable - GAMP ® software category 5. It may, of course, also
combine elements of GAMP ® software categories 4 and 5, meaning that
a standard confi gurable application has been functionally extended for
specifi c use by the regulated company or possibly by the wider open
source community - the ease with which functionality can be extended is,
of course, one of the benefi ts of open source software.
From a validation perspective, such project-specifi c development
should be considered as customisation (GAMP ® software category 5) or
at least as novel confi gurable software (GAMP ® software category 4).
Categorisation of open source software as GAMP ® category 4 or 5 will
signifi cantly extend the rigour of the required validation process, which
may in turn further erode the cost/benefi t argument for using open source
software. A question well worth asking is at what point does the further
development and validation of an open source software cost more in
terms of internal resource time and effort than acquiring an equivalent
commercial product?
This is specifi cally a problem with generic open source software which
is not specifi cally aimed for use in the life sciences industry. An example
might be an open source contact management application that is extended
to allow sales representatives to track samples of pharmaceutical product
left with physicians. In this case the extension to the open source software
to provide this functionality may require a signifi cant validation effort,
which could cost more than purchasing a more easily validated
commercial CRM system designed for the pharmaceutical industry and
provisioned as Software as a Service. For software that is specifi c to the
life sciences industry (e.g. an open source clinical trials data entry
package), there is always the possibility of further development being
undertaken by the wider open source community, which can be a more
cost-effective option.
There is then the question of whether the open source software can
successfully be validated. Although this usually means 'Can the software
be validated cost-effectively?', there are examples of open source software
that cannot be placed under effective control in the operational
environment (see below). This should be assessed early in the validation
planning process, so that time and money is not wasted trying to validate
an open source application that cannot be maintained in a validated

￿ ￿ ￿ ￿ ￿