Biomedical Engineering Reference
In-Depth Information
■
performance testing, where there are concerns about the performance
or scalability of the software;
■
functional testing, including:
appropriate testing of all requirements, usually by the development
team (which may be an internal IT group or a third party),
user acceptance testing by the process owners (users), against their
documented requirements (may not be required where a previous
assessment has been made of a standard package that has not been
altered in any way).
The use of open source software does not infer that there is a need to test
to a lower standard. If anything, some of the additional risks arising from
using open source software means that testing by the regulated company
will be more extensive than in cases where testing from a commercial
vendor (confi rmed by a traditional supplier audit) can be relied on. All
testing should follow accepted good practices in the life sciences industry,
best covered in the GAMP
®
'Testing of GxP Systems' Good Practice
Guide. In some cases requirements cannot be verifi ed by formal testing
and other forms of verifi cation should be leveraged as appropriate (i.e.
design review, source code review, visual inspection, etc.). Supporting IT
infrastructure (servers, operating systems, patches, database, storage,
network components, etc.) should be qualifi ed in accordance with the
regulated company's usual infrastructure qualifi cation processes, and as
required by Eudralex Volume 4, Annex 11.
All of the above should be defi ned in a suitable validation plan and
reported in a corresponding validation report. Based on accepted
principles, any of the above documentation may be combined into fewer
documents for small or simple software applications, or alternative,
equivalent documentation developed according to the applicable open
source documentation conventions. Where the software is used within
the European Union or used in a facility that complies with EU regulations
- and soon to be any country that is a member of the Pharmaceutical
Inspection Cooperation Scheme (PIC/S) - the documentation should also
include a clear System Description (Eudralex Volume 4 Annex 11). The
use of the open source software as a validated application also needs to
be recorded in the regulated company's inventory of software applications
(Eudralex Volume 4, Annex 11).
In summary, the validation of open source software should follow a
scalable, risk-based approach, just as any commercial software package.
The only difference is that the inability to rely on a commercial vendor
Search WWH ::
Custom Search