ASTM E2066-00(2007)
(Guide)Standard Guide for Validation of Laboratory Information Management Systems (Withdrawn 2015)
Standard Guide for Validation of Laboratory Information Management Systems (Withdrawn 2015)
SIGNIFICANCE AND USE
Validation is an important and mandatory activity for laboratories that fall under regulatory agency review. Such laboratories produce data upon which the government depends to enforce laws and make decisions in the public interest. Examples include data to support approval of new drugs, prove marketed drugs meet specifications, enforce environmental laws, and develop forensic evidence for trial. This also extends to LIMS used in environmental laboratories. In some cases these systems may need to be interoperable with CLIMS and computer-based patient records (CPR) for reporting environmental exposures and clinical laboratory testing for biologic measure of stressor exposure. The enormous financial, legal, and social impact of these decisions requires government and public confidence in laboratory data. To ensure this confidence, government agencies regularly review laboratories operating under their rules to confirm that they are producing valid data. Computer system validation is a part of this review. This guide is designed to aid users validating LIMS and incorporating the validation process into their LIMS life cycle.
Validation must provide evidence of testing, training, audit and review, management responsibility, design control, and document control, both during the development of the system and its operation life (2).
SCOPE
1.1 This guide describes an approach to the validation process for a Laboratory Information Management System (LIMS).
1.2 This guide is for validation of a commercial LIMS purchased from a vendor. The procedures may apply to other types of systems, but this guide makes no claim to address all issues for other types of systems. Further, in-house developed LIMS, that is, those developed by internal or external programmers specifically for an organization, can utilize this guide. It should be noted that there are a number of related software development issues that this guide does not address. Users who embark on developing a LIMS either internally or with external programmers also should consult the appropriate ASTM, ISO, and IEEE software development standards.
1.3 This guide is intended to educate individuals on LIMS validation, to provide standard terminology useful in discussions with independent validation consultants, and to provide guidance for development of validation plans, test plans, required standard operating procedures, and the final validation report.
WITHDRAWN RATIONALE
This guide describes an approach to the validation process for a Laboratory Information Management System (LIMS).
Formerly under the jurisdiction of Committee E13 on Molecular Spectroscopy and Separation Science, this guide was withdrawn in September 2015. This standard is being withdrawn without replacement due to its limited use by industry.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: E2066 − 00(Reapproved 2007)
Standard Guide for
Validation of Laboratory Information Management Systems
This standard is issued under the fixed designation E2066; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope E919 Specification for Software Documentation for a Com-
puterizedSystem(Discontinued2000)(Withdrawn2000)
1.1 This guide describes an approach to the validation
E1013 Terminology Relating to Computerized Systems
process for a Laboratory Information Management System
(Withdrawn 2000)
(LIMS).
E1384 Practice for Content and Structure of the Electronic
1.2 This guide is for validation of a commercial LIMS
Health Record (EHR)
purchased from a vendor. The procedures may apply to other
E1578 Guide for Laboratory Informatics
types of systems, but this guide makes no claim to address all
E1639 Guide for Functional Requirements of Clinical Labo-
issues for other types of systems. Further, in-house developed
ratory Information Management Systems (Withdrawn
LIMS,thatis,thosedevelopedbyinternalorexternalprogram-
2002)
mers specifically for an organization, can utilize this guide. It
2.2 IEEE Standards:
should be noted that there are a number of related software
100 Standard Dictionary of Electric and Electronic Terms
developmentissuesthatthisguidedoesnotaddress.Userswho
610 Standard Glossaries of Computer-Related Terminology
embarkondevelopingaLIMSeitherinternallyorwithexternal
729 Glossary of Software Engineering Terminology
programmers also should consult the appropriate ASTM, ISO,
730.1 Standard for Software Quality Assurance Plans
and IEEE software development standards.
730.2 Guide for Software Quality Assurance Plans
1.3 This guide is intended to educate individuals on LIMS
828 Standard for Software Configuration Management Plans
validation, to provide standard terminology useful in discus-
829 Standard for Software Testing Documentation
sions with independent validation consultants, and to provide
830 Guide for Software Test Documentation
guidance for development of validation plans, test plans, 1008 Standard for Software Unit Testing
requiredstandardoperatingprocedures,andthefinalvalidation
1012 StandardforSoftwareVerificationandValidationPlans
report. 1016 Recommended Practice for Software Design Descrip-
tions
2. Referenced Documents
1028 Standard for Software Reviews and Audits
2.1 ASTM Standards: 1042 Guide to Software Configuration Management
1058-1 Standard for Software Project Management Plans
E622 GuideforDevelopingComputerizedSystems(Discon-
tinued 2000) (Withdrawn 2000) 1063 Standard for Software User Documentation
1074 Standard for Developing Software Life Cycle Pro-
E623 Guide for Developing Functional Requirements for
Computerized Systems (Withdrawn 1994) cesses
1228 Standard for Software Safety Plans
E624 GuideforDevelopingImplementionDesignsforCom-
puterized Systems (Withdrawn 1994)
2.3 ISO Standards:
E627 Guide for Documenting Computerized Systems (Dis-
9000 Quality Management and QualityAssurance Standards
continued 2000) (Withdrawn 2000)
- Guidelines for Selection and Use
9000-3 Guidelines for Application of ISO 9001 to
Development, Supply, and Maintenance of Software
This guide is under the jurisdiction of ASTM Committee E13 on Molecular
9001 Quality Systems—Model for Quality Assurance in
Spectroscopy and Separation Science and is the direct responsibility of Subcom-
mittee E13.15 on Analytical Data. Design, Production, Installation, and Servicing
Current edition approved March 1, 2007. Published March 2007. Originally
9002 Quality Systems—Model for Quality Assurance in
approved in 2000. Last previous edition approved in 2000 as E2066 – 00. DOI:
Production and Installation
10.1520/E2066-00R07.
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
Standards volume information, refer to the standard’s Document Summary page on Available from Institute of Electrical and Electronics Engineers, Inc. (IEEE),
the ASTM website. 445 Hoes Ln., P.O. Box 1331, Piscataway, NJ 08854-1331, http://www.ieee.org.
3 5
The last approved version of this historical standard is referenced on Available from International Organization for Standardization (ISO), 1 rue de
www.astm.org. Varembé, Case postale 56, CH-1211, Geneva 20, Switzerland, http://www.iso.ch.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E2066 − 00 (2007)
9003 Quality Systems—Model for Quality Assurance in 3.1.6 dynamic testing, n—the actual testing of various func-
Final Inspection and Test tions and procedures using the LIMS software while in
operation.
9004 Quality Management and Quality System Elements—
Guidelines
3.1.7 installation qualification (IQ), n—documented verifi-
9004-2 Quality Management and Quality System Elements,
cationthatallkeyaspectsoftheinstallationadheretoapproved
Part 2 Guidelines for Services
design intentions as defined in system specifications and that
9004-4 Guidelines for Quality Improvements
manufacturers’ recommendations are suitably considered.
10005 Guidelines for Quality Plans
3.1.8 LIMS, n—acronym for Laboratory Information Man-
10007 Guidelines for Configuration Management
agement System that refers to computer software and hardware
10011-1 Guidelines for Auditing Quality Systems, Part 1
that can acquire, analyze, report, store, manage data, and
Auditing
process information in the laboratory.
10011-2 Guidelines for Auditing Quality Systems, Part 2
3.1.9 LIMS data loading (configuration), n—the process of
Qualification Criteria for Auditors
entering static data into appropriate data structures, such as
10011-3 Guidelines for Auditing Quality Systems, Part 3
tables or database records, to make a LIMS suitable for
Managing Audit Programs
operation in a particular laboratory. This information may
8402 Quality Vocabulary
include items like names and addresses of laboratory
2382 Data Processing Vocabulary
customers, names of laboratory personnel, descriptions of tests
performed by the laboratory, specifications, calculations,
3. Terminology
templates, or descriptions of LIMS reports, etc. In this process,
3.1 Definitions—This guide defines terminology used in the
no new functionality is added to the LIMS that was not
validation of computerized systems. The standards listed in
originally planned by the system designers. Addition of con-
Section 2 provide additional definitions that the reader may
figuration data may affect the behavior of the system.
want to review before beginning their validation process.
3.1.10 LIMS tailoring, n—see LIMS data loading (configu-
3.1.1 acceptance criteria, n—the specifications used to ac-
ration).
cept or reject a computer system, application, function, or test
3.1.11 operational qualification (OQ), n—documented veri-
action.
fication that each unit or the entire system operates as intended
3.1.2 change control, n—the process, authorities for, and
throughout its full operating range.
procedures to be used to manage changes made to a comput-
3.1.12 quality assurance unit (QAU), n—the body of indi-
erized system or a system’s data, or both. Change control is a
viduals responsible for design and interpretation of quality
vital activity of the QualityAssurance (QA) program within an
standards, such as validation procedures and processes (not
establishment and should be described clearly in the establish-
product testing).
ment’s SOPs.
3.1.13 source code, n—a computer program expressed in
3.1.3 configuration management, n—a discipline applying
human-readable form (programming language) that shall be
technical and administrative direction and surveillance to
translated into machine-readable form (object code) before it
identify and document the functional and physical character-
can be executed by the computer.
istics of a configured item, to control changes to those
characteristics, to record and report change implementation 3.1.14 static testing, n—a structured review of the source
code.
status, and to verify compliance with specified requirements.
IEEE
3.1.15 stress testing, n—the running of test protocols de-
signed to test the limits of LIMS functions.
3.1.4 customization, n—the process of adding new software
to or altering a LIMS so that it may perform functions not
3.1.16 test plan, n—see test protocol.
planned by the original system designers. This entails creating
3.1.17 test protocol, n—a written procedure describing a set
new software, compiling software modules, and linking mod-
of actions and their expected outcomes that when executed
ules to produce new executable programs. If done by the
provides documentary evidence that specific functional re-
vendor, it may be considered and validated as part of the
quirements for the LIMS work as specified.
vendor system. See related definition for “customized system”
3.1.18 validation, n—the process of establishing docu-
in Terminology E1013.
mented evidence that provides a high degree of assurance that
3.1.5 deliveredsystem,n—theLIMS,asinitiallysuppliedby
a specific process, system, or item consistently meets its
the vendor before any static configuration data have been
predetermined specifications or quality attributes.
added. In some cases, the vendor may contract with the
3.1.19 validation plan, n—the document that identifies all
laboratory to enter some configuration data on behalf of the
systems and subsystems involved in a specific validation effort
laboratory, in which case the delivered system is still consid-
andtheapproachbywhichtheywillbequalifiedandvalidated,
ered to be the default system before such customer-specific
including identification of responsibilities and expectations.
information has been added. When the vendor performs this
task, they are an agent of the laboratory, and the customer shall
3.1.20 validation team, n—the group of individuals respon-
meet the on-site validation requirements in Section 7. sible for the validation process. This team may consist of
E2066 − 00 (2007)
representatives of the laboratory, QAU, Management Informa- life cycle, and the amount of interaction with the validation
tion System (MIS) organizations, or outside consultants. team will vary during each life cycle phase.
5.1.1 Validation Team Formation Phase—This phase is
3.1.21 vendor audit, n—an independent review and exami-
typically not a separate phase in the LIMS life cycle, however,
nation of system records and activities in order to test the
adequacy and effectiveness of data security and data integrity it is a critical part of the validation process. A typical team
consists of representatives from the laboratory, MIS group, and
procedures, to ensure compliance with established policy and
operational procedures, and to recommend any necessary QAU. There may be other team members depending on the
scope of the project and resources within the organization. If
changes. ANSI
required, the identified validation team members should begin
3.1.22 vendor audit team, n—a team made up of individuals
to identify training courses on computer systems validation at
who are knowledgeable in computer system engineering,
this time. No training should take place until those who have
auditing practices, computer system quality methods, regula-
been selected for the validation team have their management’s
tory compliance, validation practices, business and legal poli-
full agreement to participate in this activity. These courses can
ciesandprocedures(applicableonlytocomputerhardwareand
be either in-house or outside-developed courses. The vendor
software procurement and related services). (1)
audit team may consist only of the validation team or it may be
3.1.23 version control, n—control of all associated software
a specific subgroup within the organization. It is recommended
and document versions. This also includes all documents
that the vendor audit team should include organizational
associated with implementation, validation, or operation of a
members from the QAU, MIS, and the laboratory (1).
LIMS.
5.2 Business Requirements Definition Phase—The business
4. Significance and Use unit, specifically the laboratory, shall contact the QAU to
determine current good manufacturing practices (cGMPs),
4.1 Validation is an important and mandatory activity for
good manufacturing practices (GMPs), good automated labo-
laboratories that fall under regulatory agency review. Such
ratory practices (GALPs), and other requirements that shall be
laboratories produce data upon which the government depends
addressed with this project. An initial selection of validation
to enforce laws and make decisions in the public interest.
team members is made at this time.
Examplesincludedatatosupportapprovalofnewdrugs,prove
marketed drugs meet specifications, enforce environmental
5.3 Project Definition Phase—Finalagreementandmanage-
laws, and develop forensic evidence for trial.This also extends
ment acceptance for all validation team members should be
to LIMS used in environmental laboratories. In some cases
obtained. Because validation is complex and can take a long
these systems may need to be interoperable with CLIMS and
time, each team member should have the full support of their
computer-based patient records (CPR) for reporting environ-
management. It is critical that management understands and
mental exposures and clinical laboratory testing for biologic
agrees to the time commitment for these individuals. Without
measure of stressor exposure. The enormous financial, legal,
agreement from each member’s management chain, the prob-
and social impact of these decisions requires government and
ability for developing and validating the LIMS successfully
publicconfidenceinlaboratorydata.Toensurethisconfidence,
will diminish. Once formed, the validation team can start to
government agencies regularly review laboratories operating
address high-level issues such as the existence of corporate
under their rules to confirm that they are producing valid data.
standard operation procedures (SOPs) needed for validation.
Computer system validation is a part of this review. This guide
Time constraints and inexperience of team members can be a
is designed to aid users validating LIMS and incorporating the
limiting factor in the validation process. This is when the team
validation process into their LIMS life cycle.
should identify outside consultants that may be needed in the
validation process and b
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.