search.noResults

search.searching

note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Beyond the laboratory Building a Smart Laboratory 2017


Category 2: Tis category is no longer in use


Category 3: Non-configured products l Definition: off-the-shelf solutions that either cannot be configured or that use default configuration. Run-time parameters may be entered and stored, but the soſtware cannot be configured to suit individual business processes.


l Example: firmware-based applications, COTS, instruments.


l Validation: the package itself. Record version and configurations, verify operations against user requirements. Consider auditing the vendor. Risk- based tests of application: test macros, parameters, and data integrity.


Category 4: Configured products l Definition: soſtware, oſten very complex,


that can be configured by the user to meet the specific needs of the business process. Soſtware code is not altered.


l Example: LIMS/SCADA/MES/MRP/ EDMS/clinical trials, spreadsheets and many others (See GAMP5).


l Validation: life cycle approach. Risk- 32


based approach to supplier assessment and other testing. Record version and configuration, verify operation against user requirements. Make sure SOPs are in place for maintaining compliance and fitness for intended use, as well as for managing data.


Category 5: Custom applications l Definition: soſtware, custom-designed and coded to suit the business processes.


l Example: it varies, but includes all internally/externally developed IT applications, custom firmware and spreadsheet macros. Parts of Category 4 systems may be in this category.


l Validation: the same as Category 4, plus more rigorous supplier assessment/audit, full life cycle documentation, design and source code review.


System validation


Te validation itself usually needs to be divided into more manageable pieces. One way is to use the ‘4Q method’. Tis comprises development qualification (DQ), installation


qualification (IQ), operation qualification (OQ), and performance/process qualification (PQ). What the chosen manageable pieces or phases are is up to the individual, but it must be described in the validation plan. Tis defines the phases, the input and output of the phases, and which documents will be created during the phases. Typically, this will be a phase plan including test plans, the testing itself and the test documentation, and the phase report.


DQ – development qualification Tis includes writing the user requirements specification, choosing the system, auditing the supplier if the risk assessment says that this is needed, and implementing the system.


IQ – Installation qualification Installing the system is usually just a matter of following the description from the supplier. A brief test will show that the system is up and running.


OQ – Operation qualification Tis may be defined differently in different organisations, but a common definition


www.scientific-computing.com/BASL2017


Dmitry Kalinovsky/Shutterstock.com


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44