Biomedical Engineering Reference
In-Depth Information
usual to conduct a detailed functional risk assessment at this stage,
examining each function (business process, use-case, etc.) to determine:
■
whether or not the function requires formal validation, that is does it
support regulatory signifi cant requirements?
■
the risk severity of the specifi c function - usually assessed of a relative
basis, but potentially using qualitative or quantitative risk assessment
for software with a higher overall risk severity (see ICH Q9).
For functions that are determined to be regulatory signifi cant and
requiring validation, specifi cations will also need to be developed in order
to document the setup (confi guration) of the open source software by the
specifi c regulated company. For COTS software this will include a record
of the actual confi guration settings (package confi guration specifi cation
or application setup document). Where custom development is required
this should also be documented in appropriate functional and technical
design specifi cations.
It is worth noting here that where specifi c functions are developed by
the open source community to meet the needs of a specifi c project, and
where the community does not provide functional and technical design
specifi cations, it is recommended that the regulated company's
involvement in the development includes the production of these
documents. Not only will these provide the basis for better support and
fault fi nding in the future, but they will also be of use to other life sciences
companies wishing to use the same functional enhancements.
The nature of the open source movement implies a moral responsibility
to share such developments with the wider community and it is common
practice for developers in the open source community to 'post' copies of
their software enhancements online for use by other users. While it is
possible for life sciences companies to develop enhancements to open
source software for their own sole benefi t, this goes against the ethos of
the movement and in some cases the open source licence agreement may
require that such developments are made more widely available.
Where such functional enhancements require validation, the associated
documentation (validation plans, requirements, specifi cations, test cases,
etc.) is almost as useful as the software. Sharing such validation
documentation (devoid of any company confi dential or commercial
details) fi ts well with the ethos of the open source movement and such
documentation may be shared via open source forums or online
repositories. Most open source software sites have a location where
documentation can be shared and this practice is to be encouraged in line
with the GAMP
®
key concept of leveraging 'supplier' documentation.
Search WWH ::
Custom Search