Software bespoke

Category 5—Custom (Bespoke) Software These software packages are developed to meet specihc requirements of the user. A supplier audit is usually required to conhrm the software has been developed according to a documented quality system. Vahdation should ensure the software meets URS requirements. Full life cycle vahdation is needed. 

Clearly the major difference between the 1990s and earlier times is the availability of inexpensive and rehable computing and control facilities. Time is a fundamental part of laboratory automation and, in the area of computer data processing, the rapid changes that have taken place over the last 25 years are quite startling. Results from analytical measurements can now be almost instantaneous. There is a ready access to computer power, commercial interface cards and even bespoke software. 

Microelectrode arrays containing AChE were also utilised within a flow injection system [40]. A system was developed where a sample was separated and flushed simultaneously through eight cells, each containing a screen-printed electrode and fitted with a separate bespoke mini-potentiostat (Fig. 15.3). This allowed multiple measurements to be made on a single water sample using multiple electrodes, each specific for a different pesticide due to inclusions of different AChE mutants in each of the electrodes. Pattern-recognition software could then be utilised to deduce the pesticide levels in a potentially complex sample. 

Custom-built software Also known as a Bespoke System, Custom-Built Software is software produced for a customer, specifically to order, to meet a defined set of user requirements (GAMP). 

Only a small fraction of bespoke software had undergone a detailed review Poor programming practice... 

The rigor of validation for computer systems supporting these critical operational aspects of the processes should take account of their composite custom (bespoke) software, COTS software, and supporting computer network infrastructure. The risk map and supporting rationales will form the basis of Validation (Master) Plans that are discussed in more detail later in this book. 

Who developed the software (standard, conhgured, customized, bespoke) ... 

GAMP Category 5 Software Custom (Bespoke) Application Software... 

Nowadays most software and hardware is based on purchased COTS products rather than being bespoke/custom built. Pharmaceutical and healthcare companies (the COTS product users) are accountable to the regulatory authorities for ensuring that the product development methodologies used by the COTS developer are of a sufficient degree of capability maturity and adequate for the intended use of the COTS product. If the supplier can provide information about the development of its COTS product, then this can be used as the basis of user validation. 

COTS products have the same basic validation requirements as any other type of software. Typically, suppher audits are expected for critical and complex applications as discussed in Chapter 7. If an audit is conducted and progress with any significant corrective actions cannot be proven, then suitable alternative suppliers or sources of software should be sought, including bespoke/custom developments. 

Manage any bespoke programming (e.g., macros) as Category 5 software. 

Emphasis within the life cycle will change depending on whether computer hardware is bespoke or standard and also on the mix of software categories in which the application software falls. Table 5.2 and Table 5.3 outline the preferred validation approach toward different categories of software and hardware based on the risk the various categories of software pose. 

Another important aspect to take into consideration is access to proprietary source code and associated documentation. All custom (bespoke) appfication-specific software and reference doc-... 

Hardware and Software Design for bespoke code/macros. 

Audits on supplier premises are used to assess a supplier s quality management system at first hand with detailed examination of procedures and documentation relating to a product or service. As discussed earlier, such audits are primarily conducted for suppliers of bespoke (custom) software and systems. 

The Software Design partitions the Functional Specification into operational units, referred to as modules. Some modules may be suitable for implementation with COTS software packages, in which case the software packages and any configuration requirements should be defined. Other modules will require custom (bespoke) programming. 

Chapter 14 diseusses the use of standard software in more detail and how a design strategy based on exploiting COTS produets (as opposed to basing the design strategy on bespoke software) ean reduee the validation effort required by a pharmaceutical or healthcare company. 

Conlignrable and cnstomized COTS software and bespoke (cnstom) hardware shonld be snbject to an HACCP, CHAZOP, or FMEA as appropriate. It is vital that GxP processes are not compromised. The following qnestions should be rhetorically posed ... 

The system build phase is expeeted to extensively reuse existing software rather than develop new bespoke eode. Reused software must be robust and documented otherwise the benehts of the RAD process will be redueed by the need for a signihcant reengineering and revalidation exercise. 

Redundant bespoke (custom) programming is considered dead code and should be removed. The only exception is rednndant code strategically introdnced to try to protect the cotmnercial confidentiality of proprietary software, nsnally by confnsing disassemblers that might be used by unethical competitor organizations to reverse engineer the product. 

Generally, widely distributed Off-The-Shelf (OTS) software is not considered to need Source Code Review if a reputable developer has produced it under an effective system of quality assurance and the product requires no more than an application parameter configuration. In most computer systems, therefore, Source Code Reviews are limited to custom (bespoke) software and configuration within OTS software products. 

Checking bespoke and COTS software versions loaded against configuration management plan... 

Any COTS product configuration, new bespoke (custom) hardware and software... 

All custom (bespoke) software source code must be available for regulatory inspechon (e.g., OECD recommendation in the GLP Consensus Document ). Relevant COTS product reference documentahon should also be available for inspection, recognizing that proprietary COTS source code is usually only available at the supplier s premises, and access may not be available for regulatory inspechon. 

Suppliers sometimes provide this facility as part of an upgrade or replacement product. This option, if available, is a useful alternative to migrating records to entirely new computerized archive system. The integrity of the emulation facility must be verihed. Hopefully the emulator can be considered as standard software otherwise the software will have to be treated as bespoke code and validated as such. 

Standard Release Documentation The specification and testing documentation is shared among many installations so its unit cost per apphcation should be less than that for bespoke software. 

The approach to standardized software should follow a variant of the V-Model called the X-Model (see Figure 14.1). Assuming that the standardized software has been developed under a suitable quality management, the end user validation can be abridged from the full bespoke software validation life cycle. 

Bespoke Element Developments Writing extra software to complement the standardized application. These modihcations may impinge on standard software stams, but cau be compensated by overall functional (black box) testing. Bespoke code must itself be fully validated, including strucmral (white box) testing. 

Upgrade Versions Caution is needed when implementing new versions or bug fixes to standardized apphcations. Release documentation should coufirm coutiuued quality of software. If serious doubts exist over software quality, commouseuse should prevail aud the software should be treated as customized or eutirely bespoke, aud heuce require full validation. 

Bespoke Application Not applicable Not applicable Bespoke software... 

A Design Review should be conducted before testing begins. This will normally involve developing a Requirements Traceability Matrix (RTM). If no detailed design information is available then cross-references should be made between the newly prepared System Specification, available operator manuals, and user procedures. Source Code Reviews will be expected for custom (bespoke) software under the control of the pharmaceutical or healthcare company, and redundant code identified should be removed. 

Pharmaceutical and healthcare companies shonld consider working with key individnal snppliers and industry groups to help suppliers develop electronic record/signatnre-compliant COTS products. Current versions of COTS prodncts need not be specifically cnstomized for nsers to provide full electronic record/signatnre fnnctionality the development risk with bespoke development must balance with the complexity and criticality of the change. It shonld be possible to compensate for the lack of key software fnnctionality by adding nser procednral controls. 

---