| A. | Vendor Audit Check List from Validation-Online Company Overview | Done | Notes |
| A.1 | Audit details (address, audit team, supplier representatives) |
|
|
| A.2 | Company size, structure and summary of history (number of sites, staff, organizational charts, company history) |
|
|
| A.3 | Product/service history (main markets, how many sold, use in healthcare sector) |
|
|
| A.4 | Summary of product/service under audit (product literature) |
|
|
| A.5 | Product/service development plans |
|
|
| A.6 | Tour of facility (to verify housekeeping, general working environment, working conditions) |
|
|
| B. | Vendor Audit Check List from Validation-Online Organization and Quality Management |
|
|
| B.1 | Management structure (roles, responsibilities) |
|
|
| B.2 | Method of assuring quality in product/service (quality system, responsibilities for quality) |
|
|
| B.3 | Use of a documented Quality Management System (QMS) e.g., existence of a quality policy and objectives, quality manual, process definitions/procedures, standards |
|
|
| B.4 | Maturity of QMS (relevance to product/service under audit) |
|
|
| B.5 | Control of QMS documentation (reviews, approvals, distribution, updates) |
|
|
| B.6 | Maintenance of QMS documentation (regularly reviewed and updated when appropriate) |
|
|
| B.7 | QMS certified to a recognized standard (e.g., ISO9001) |
|
|
| B.8 | Method of checking compliance with QMS (internal audits, management reviews) |
|
|
| B.9 | Qualification and suitability of staff |
|
|
| B.10 | Independence of auditors, inspectors, testers, reviewers |
|
|
| B.11 | Staff training (general, QMS, product/service related, new staff, changes to QMS, regulatory issues, training records) |
|
|
| B.12 | Use of sub-contractors (individuals, companies): |
|
|
|
| Method of selection |
|
|
| Sub-contractor qualifications and training records |
|
|
| Specification of technical and quality requirements in orders placed |
|
|
| Method of accepting product delivered by sub-contractor |
|
|
| B.13 | Experience of validation process (with other customers, previous Supplier Audits, services provided by supplier, involvement in regulatory inspections) |
|
|
| B.14 | Awareness of healthcare regulatory requirements (knowledge of regulations, subscription to publications, attendance of relevant events, involvement in industry groups) |
|
|
| B.15 | Continuous improvement programme (use of metrics to evaluate and improve effectiveness of QMS) |
|
|
| C. | Vendor Audit Check List from Validation-Online Planning and Product/Project Management |
|
|
| C.1 | Use of quality and project plans (per project/product, defining activities, process definitions/procedures, responsibilities, timescales) |
|
|
| C.2 | Status of planning documentation (reviews, approvals, distribution, maintenance, and update) |
|
|
| C.3 | Documentation of user/supplier responsibilities |
|
|
| C.4 | Use of Validation Plan where supplied by user company |
|
|
| C.5 | Project management and monitoring (mechanism, tools, progress reports) |
|
|
| C.6 | Accuracy of, and conformance to, planning and management process definitions/procedures |
|
|
| C.7 | Use of formal development life cycle |
|
|
| C.8 | Evidence of formal contract reviews where applicable |
|
|
| D. | Vendor Audit Check List from Validation-Online Specifications |
|
|
| D.1 | User Requirements Specifications |
|
|
| D.2 | Functional Specifications |
|
|
| D.3 | Software Design Specifications |
|
|
| D.4 | Hardware Design Specifications |
|
|
| D.5 | Relationship between specifications (together forming a complete specification of the system which can be tested objectively) |
|
|
| D.6 | Traceability through specifications (e.g., for a given requirement) |
|
|
| D.7 | Status of specifications (reviews, approvals, distribution, maintenance and update) |
|
|
| D.8 | Accuracy of and conformance to relevant process definitions/procedures |
|
|
| D.9 | Use and control of design methodologies (CASE tools) |
|
|
| E. | Vendor Audit Check List from Validation-Online Implementation |
|
|
| E.1 | Specification of standards covering the use of programming languages (e.g., naming and coding conventions, commenting rules) |
|
|
| E.2 | Standards for software identification and traceability (e.g., for each software item: unique name/reference, version, project/product reference, module description, list of build files, change history, traceability to design document) |
|
|
| E.3 | Standards for file and directory naming |
|
|
| E.4 | Use of build files to compile and link individual software configuration items into a formal release of the software product |
|
|
| E.5 | Use and version logging of development tools (e.g., compilers, linkers, debuggers) used for each software configuration item and the formal build and release of the software product |
|
|
| E.6 | Evidence of source code reviews prior to formal testing (checking design, adherence to coding standards, logic, redundant code, identification of critical algorithms) |
|
|
| E.7 | Independence and qualifications of reviewers |
|
|
| E.8 | Source code reviews recorded, indexed, followed-up and closed off (with supporting evidence). Evidence of timely management action for reviews which remain open. |
|
|
| E.9 | Listings and other documents used during source code reviews identified, controlled, and retained with review reports |
|
|
| F. | Vendor Audit Check List from Validation-Online Testing |
|
|
| F.1 | Explanation of the test strategy employed at each level of development (e.g., module testing, integration testing, system acceptance testing or alpha/beta testing) |
|
|
| F.2 | Software Test Specifications |
|
|
| F.3 | Hardware Test Specifications |
|
|
| F.4 | Integration Test Specifications |
|
|
| F.5 | System Acceptance Test Specifications |
|
|
| F.6 | Structure and content of each test script (unique reference, unambiguous description of test, acceptance criteria/expected results, cross-reference to controlling specification) |
|
|
| F.7 | Relationship between test specifications and controlling specifications (demonstrating that the system has been thoroughly tested with traceability between specifications and tests) |
|
|
| F.8 | Evidence that test specifications cover: |
|
|
|
| Both structural and functional testing |
|
|
| All requirements |
|
|
| Each function of the system |
|
|
| Stress testing (repeat testing under different conditions) |
|
|
| Performance testing (e.g., adequacy of system performance) |
|
|
| Abnormal conditions |
|
|
| F.9 | Status of test specifications (reviews, approvals, distribution, maintenance, and update) |
|
|
| F.10 | Formal testing procedure to execute test specifications (method of recording test results, use of pass/fail, retaining raw data, reviewing test results, progressing and resolving test failures) |
|
|
| F.11 | Status of test results and associated review records (indexed, organized, maintained, followed up on failure) |
|
|
| F.12 | Involvement of QA function (as witnesses and/or reviewers) |
|
|
| F.13 | Independence and qualifications of testers and reviewers |
|
|
| F.14 | Accuracy of, and conformance to, relevant test process definitions/procedures |
|
|
| F.15 | Control of test software, test data, simulators |
|
|
| F.16 | Use of testing tools (documented, controlled, and versions recorded in the test results) |
|
|
| F.17 | Traceability of test results back to the appropriate specifications/test scripts |
|
|
| G. | Vendor Audit Check List from Validation-Online Completion and Release |
|
|
| G.1 | Documented responsibility for release of product, such as certificate of conformity, authorization to ship (including evidence that testing has been accepted with/without reservations) |
|
|
| G.2 | Handover of project material in accordance with quality plan/contract (e.g., release notes, hardware, copies of documentation/software) |
|
|
| G.3 | Provision of user documentation (user manuals, administration/technical manuals, update notice with each release) |
|
|
| G.4 | Records of releases (i.e., which customers have which version of system/software) |
|
|
| G.5 | Warranties and guarantees |
|
|
| G.6 | Archiving of release (software, build files, supporting tools, documentation) |
|
|
| G.7 | Availability of source code and documentation for regulatory inspection (e.g., use of ESCROW accounts, and which product releases are covered) |
|
|
| G.8 | Customer training (summary of courses provided by staff or third parties) |
|
|
| G.9 | Accuracy of, and conformance to, release process definitions/procedures |
|
|
| H. | Vendor Audit Check List from Validation-Online Support/Maintenance |
|
|
| H.1 | Explanation of support services (agreements, scope, procedures, support organization, responsibilities, provision locally/ internationally, use of third parties, maintenance of support agreements) |
|
|
| H.2 | Duration of guaranteed support (number of versions, minimum periods) |
|
|
| H.3 | Provision of Help Desk (levels of service, hours of operation) |
|
|
| H.4 | Fault reporting mechanism (logging, analysing, categorizing, resolving, informing, closing, documenting, distribution, notification of other customers with/without support agreement) |
|
|
| H.5 | Link between fault reporting mechanism and Change Control |
|
|
| H.6 | Method of handling of customer complaints |
|
|
| H.7 | Accuracy of, and conformance to, support process definitions/procedures |
|
|
| I. | Vendor Audit Check List from Validation-Online Supporting Processes and Activities |
|
|
| I.1 | Documentation management (covering QMS and product/project documents): |
|
|
|
| In accordance with QMS/Quality Plan |
|
|
| Following documentation standards |
|
|
| Indexed, organized |
|
|
| Reviews carried out prior to approval and issue |
|
|
| Reviews recorded, indexed, followed up and closed off (with supporting evidence) |
|
|
| Evidence of timely management action for reviews which remain open |
|
|
| Formal approvals recorded, meaning of approvals defined |
|
|
| Distribution controlled |
|
|
| Document history maintained |
|
|
| Removal of superseded/obsolete documents |
|
|
| I.2 | Software Configuration Management: |
|
|
|
| System for identifying, controlling and tracking every version of each software configuration item |
|
|
| System for recording the configuration of each release (i.e., which software configuration items and versions are used) |
|
|
| Identification of the point at which Change Control is applied to each software configuration item |
|
|
| Control of build tools and layered software products, including the introduction of new versions |
|
|
| I.3 | Change Control covering software, hardware, documentation: |
|
|
|
| All change requests formally logged, indexed and assessed |
|
|
| Rejected requests identified as such, reasons documented, signed by those responsible and the originator informed |
|
|
| Changes authorized, documented, tested and approved prior to implementation (except for emergencies) |
|
|
| Emergency process definition/procedure documented covering reviewing, testing, approving, and recording |
|
|
| Impact of each change (on other items and on requirements for re-test) assessed and documented |
|
|
| I.4 | Security process definitions/procedures (physical access, logical access to accounts/software, virus controls) |
|
|
| I.5 | Backup and recovery process definitions/procedures (secure storage and handling of media, on-site, off-site, recovery procedure exercised) |
|
|
| I.6 | Disaster recovery process definition/procedure (tried) and documented evidence of disaster recovery testing |
|
|
| I.7 | Control of purchased items bought on behalf of user (e.g., computer hardware, layered software products), including associated packaging, user documentation, warranties |
|
|
| I.8 | Accuracy of, and conformance to, relevant process definitions/procedures |
|
|
| | | | |
