Biomedical Engineering Reference
In-Depth Information
and Part 820 [5]), regulatory guidance (e.g. EU Eudralex Volume 4
Annex 11 [6], PIC/S PI-011 [7]) and applicable industry standards (e.g.
ISO 13485 [8]). These documents require that such systems are validated,
but do not provide detailed requirements on how this is achieved.
Computer system (or software) validation is a process whereby clear
and unambiguous user and functional requirements are defi ned and are
formally verifi ed using techniques such as design review, code review and
software testing. This should all be governed as part of a controlled
process (software development life cycle) defi ned in a validation plan,
supported by appropriate policies and procedures and summarised in a
validation report.
Although some regulatory guidance documents (i.e. FDA General
Principles of Software Validation [9], and PIC/S PI-011) do provide a
high-level overview of the process of computer system validation, industry
has generally provided detailed guidance and good practices through
bodies such as the International Society for Pharmaceutical Engineering
(ISPE) and the GAMP
®
Community of Practice.
The need to validate such software or applications is not dependent on
the nature of the software or how it is sourced - it is purely based on
what the software or application does. If an application supports or
controls a process or manipulates regulatory signifi cant data that is
within the scope of regulations (e.g. clinical trial data, product
specifi cations, manufacturing and quality records, adverse events
reporting data) or provides functionality with the potential to impact
patient safety or product quality, there is usually a requirement to validate
the software.
This also includes an expectation to ensure that the application or
software fulfi ls the users stated requirements, which should, of course,
include requirements to ensure compliance with regulations. Validating
the software or application therefore provides a reasonably high degree
of assurance that:
■
the software will operate in accordance with regulatory requirements;
■
the software fulfi ls such requirements in a reliable, robust and
repeatable manner.
Not all open source software has regulatory signifi cance, but where this
is the case failure to validate such software can have serious consequences,
which includes regulatory enforcement action. There have been cases
where a serious failure to appropriately validate a computerised system
has directly led to or has partly contributed to enforcement actions
including failure to issue product licences, forced recall of products,
Search WWH ::
Custom Search