A.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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 |
|
|
Views:
Vendor: ………………………………………………………
Address: ………………………………………………………
Auditor: ………………………………………………………
Persons Present: ………………………………………………………
………………………………………………………
……………………………………………………….
………………………………………………………..
………………………………………………………..
.gif)
0 Comments