Upgrading (or Updating) Your Instrument Calibration Program A Calibration Program upgrade can mean something different depending

on who you ask. It could mean that the current way you manage your calibration program has become cumbersome and inefficient. It could mean that the software program you use to manage your calibrations is outdated or no longer supported by the supplier. It could mean you dont have a calibration program in place at all. Or it could mean something else entirely. Ill try to address some of each in this article, but mostly we are talking about upgrading the Computerized Calibration Management System (CCMS) software used to manage your instrument calibrations. This article is also focusing on process calibrations. I personally consider Metrology and Process Calibration to be two different worlds. Metrology deals more with calibration of test standards and instruments calibrated in a controlled environment to better accuracies (and uses uncertainty). Process calibrations are performed in the field or the shop to calibration tolerances that are (should be) based on process requirements as opposed to manufacturer specified accuracies (and typically uncertainty is not determined for process instrumentation). The same Calibration Program principles apply, but the regulatory requirements, calibration methods, and controls may differ. That being said, the software program can be the same for both disciplines, but some different functionality, fields will be needed. Lets all get on the same page with calibration program basics. Any basic calibration program consists of an inventory of the instruments, calibration schedules, and history of calibrations (scheduled and unscheduled) / repairs performed on the instruments. The calibration program itself might also include spare parts inventory. For the scope of this article, the calibration program does not include mechanical equipment and maintenance, although many of the same principles apply. Instrument Inventory: The instrument inventory includes all the information you want to track about the specific instrument asset. At a minimum this should include a unique identifier for each instrument along with a description, location, manufacturer, model, serial number, P&ID tag number, calibration range, and calibration tolerance (limits). Other data to consider might include Instrument Type, Instrument Owner, Department, range and accuracy specified by manufacturer, Parent System, Parent Equipment, Criticality Classification, etc. When establishing a new calibration program, serious consideration should be given to the unique identifier. If the P&ID tag is used, remember that instruments will be replaced and many instruments will not have a P&ID tag. The more projects I do, the more I am convinced that the unique identifier simply should be a sequential number such as INSTXXXXX, unless you are going to consistently assign a unique identifier to everything, including lab, admin, portable, and test equipment. Calibration Schedules: The calibration schedule establishes the initial due date and the frequency at which the calibration(s) for the instrument is performed. The calibration procedure and nominal test points are typically associated with the schedule as well. Calibration History: The history for each completed calibration and repair performed on a specific instrument must be maintained. Each calibration performed must include a record of the date

completed, technician, As-Found measurement data at each test point for the test standard and instrument with the corresponding error , As-Left measurement data (if different than As-Found) and a listing of all calibration standards used with corresponding expiration date. When scheduled calibrations are completed, the next due date is updated based on the calibration schedule. OK, so now that we have some background information, lets talk about some recommendations and requirements for upgrading the software used to manage our calibration program. The absolute most important thing about doing any upgrade is to have a champion and get the commitment of everyone involved. Its going to take involvement from Management, IT, Quality, System Users, and the Supplier during implementation. Its going to take a dedicated person to champion the project through all the inevitable obstacles. I cannot over-stress the importance of obtaining agreement on responsibilities and expectations up-front to ensure project success. It is particularly important to clearly document quality expectations for documentation and testing. These costs can add significantly to your project, particularly if out-sourcing is required. The project champion for a calibration program improvement is likely to be a senior person in the calibration department (but not necessarily). The champion has either already identified the need for an upgrade or been told to start figuring out what the options are. The first steps: 1. Research: a. Determine drivers - for example, system outdated and no longer supported, quality initiative, improve efficiency/reduce operating costs b. Check with other departments should we integrate Asset Management for maintenance, validation, training needs c. Check your options what systems are available that might meet our needs, network (online discussion groups, professional organizations, professional associates) to see what other similar companies are using, what they like and dont like d. Develop a Draft User Requirement Specification (see table). Major cost differentiators a. Paperless or paper-based b. Web-based, stand-alone, network /client c. Number of concurrent users (license fees can be significant) d. Interface with process calibrators e. Same system for maintenance and calibration f. Enterprise, Site, or departmental scope g. Regulatory compliance for electronic records, electronic signatures e. Obtain quotes for software, hardware, data migration, and implementation costs. You will then need to apply some common sense to the costs and likely increase the estimate based on experience with projects at your facility. Utilize a project manager for assistance to help account for the additional costs that may occur due to schedule delays and additional quality requirements. Document the cost additions so that the financial understand what, if any, fudge factors have already been added.

My suggestion for the champion would be to get a partner in the Information technology (IT) department to help do an initial review to make sure any system selected will comply with the network infrastructure. For example are the wireless/network drops in the locations that will be needed for calibrations. Also SQL systems are a tough sell in an Oracle based IT department. Some suppliers have not kept pace with technology advances which could lead to frequent system crashes or total inoperability with your network infrastructure. It will be able to help with that determination. This is the beginning of a beautiful alliance and team building, one that will pay huge dividends during implementation. The champion should also begin to discuss quality requirements (see table for examples) to get an idea of the resources that will be needed (people and costs). The more detail here, the better. Do not overlook this very important alliance. I would also recommend getting with Maintenance Manager. For many years, I have seen companies use 2 different systems; one for equipment maintenance and one for instrument calibration, and for good reason. The CMMS that does a great job for maintenance was not good for calibrations, and vice versa. Maintenance systems need to do a real good job of spare parts management, inventory control, craft planning, meter-based and calendar-based scheduling, and incorporate preventive, predictive, and corrective maintenance strategies. Calibration systems, on the other hand, need to provide pre-defined test points and tolerances, track as-found and as-left measurement data, automatically calculate error, track test standards used, and provide reverse traceability in the event test standards are found out of tolerance. Some of the more popular systems today are doing a good job for both maintenance and calibration needs. The maintenance department typically has a much bigger budget that calibration. Given these two factors and that it just makes sense to have all your assets in one system, makes it a nobrainer that the two departments team up for any upgrades. Even if the systems have to remain separate near term, the system can be implemented for use in Calibration and then later add maintenance once the system has proven itself. Now we need to get funding for the project. Thats going to take management approval. To obtain approval, management is going to want to know whats in it for them. Unless there is a quality mandate, a Return on Investment (ROI) will be the ticket to justify the project expense. Also remember that if the money isnt already in the budget for this year, your efforts are now being spent simply to get the project in next years budget. 2. Justification a. Identify and quantify productivity improvements b. Identify and quantify quality improvements c. Identify and quantify tangible benefits d. Document current system support (if any) e. Add it all up and make your case Once the funding is approved its time to select a solution, but not so fast. 3. Product selection a. Round up the troops (stakeholders)

b. c. d. e. f.

Finalize and approve the URS Issue RFP and have vendors include Functional Requirements Specification Make a preliminary selection of the product/supplier Conduct a comprehensive Quality Audit of the Supplier (leverage results in test requirements and Risk Assessment) If Supplier is acceptable, issue Purchase Order.

Now the real work begins. We bought it, now we have to make it work for us. I have included a typical implementation sequence below and a description of the documentation/testing in the table. Your implementation may vary depending on the system complexity, quality requirements, and leveraging of other activities. Some activities can be performed in parallel and some eliminated if system are installed on multiple servers such as a Testing/Development environment and a Production environment. For example, training can be conducted on one server, while Performance Verification is occurring on the other. 4. Implementation a. Purchase and install hardware b. Develop required documentation (see table for examples) c. Installation of software d. Configuration (may be installed pre-configured, depending on system) e. Perform Installation Verification f. Test Migration #1 (if necessary) perform data migration verification and document any issues that need to be corrected for final migration. Note that an final migration will be required even if no errors occurred, to update the system with any changes made up to the source system g. Informal Use Testing (VERY IMPORTANT!) use this period to put the system through all possible use scenarios. Communicate with supplier on any additional functionality desired, even the ones that are not yet possible, and update documents with any additional requirements that will be implemented. Use this time to develop procedures and dry run testing. h. Perform Operational Verification testing i. Approve procedures/work instructions and complete training requirements typically procedures to support operation are required prior to final system testing and user training should be completed. j. Optional Data Migration #2 if there were any issues during migration #1 or additional configuration, you want to make sure final system testing is performed on the data and configuration that will be used once system Goes Live. k. Perform Performance Qualification l. Final Data Migration m. GO LIVE!! All done, right! Absolutely not! Plan for problems once system goes live. Even with all the proper planning and implementation, things will not go smoothly. Training likely didnt cover every scenario

and there is a learning curve for the users for every software implementation that anyone has ever done. Make sure your system experts and key players during configuration and testing are available for post-GO Live support. Hopefully I have shed a little light on the requirements of a calibration program, CCMS, and some helpful hints for implementation. I want to emphasize the importance of obtaining consensus with all stakeholders, including IT, Quality, Users, Supplier, and Maintenance, even before making the final purchasing decision. On every CCMS system I have implemented the IT support and ever-changing quality requirements have led to project delays and increased costs. The main problem I have seen is that we dont know what we want until we see what we have. So the key is to provide visual clarity to what the end products will be ahead of time, obtain buy-in from stakeholders and approval from management that these are the requirements that if changed will significantly delay and add cost to the project. There is a lot of detail and specific lessons learned from experience that have been left out of this article due to the variables involved. However, feel free to contact me for any additional suggestions, recommendations, or details on this topic. [Note to Susan: Table is below on next page due to landscape orientation] About the author: Mike Cable is Sr. Consultant with PCI in Raleigh, North Carolina providing instrumentation compliance solutions to the life science industry. He is author of ISAs Calibration: A Technicians Guide and contributing author to ISAs Automation Book of Knowledge. Mike resides in Graham, NC with his beautiful wife of 28 years and has three wonderful daughters.

Documentation and Test Requirements to Consider He following table lists the documentation and testing requirements that should be considered for a Calibration System Upgrade project. The titles might be different for your industry. Some documents can be combined such as URS/FRS and verification testing. Document Type User Requirements Specification (URS) Description Provides conceptual overview of system operation and specific use requirements, including required interface with any other systems. Also may include performance requirements. Detail the technical specifications required of a system to be developed/configured and represent the particular operations a system must be capable of performing in order to comply with all of the User Requirements Specifications. Details the hardware and software that will be implemented, along with specific configuration settings, customizations, file structures, etc Defines the validation strategy for implementation to include documentation requirements, sequence (schedule), constraints/dependencies, and overall system acceptance criteria. If migrating data from existing system(s), this document describes the methodology and field mapping. May also include the data migration verification testing.
Identify and assess potential malfunctions associated with the system functions, and the potential impact of those malfunctions on product quality. Maps the relationship between the requirements, design, and testing

Functional Requirements Specification (FRS)

Examples Typically includes general requirements of calibration mentioned above. May include workflows for instrument induction, calibration process, and handling OOT conditions. Have supplier provide FRS to document how their system will meet user requirements and other specific technical operational requirements. System configuration settings and report specifications Includes a matrix of the required documentation and test requirement deliverables along with a description and acceptance criteria for each deliverable Includes field map detailing what data in source database to what field in delivered database, including data type, limits, and special handling. Identify severity, probability, and detectability of potential malfunctions against each user requirement. Any unacceptable risk has documented mitigation strategies such as additional testing or controls put in place. Table that maps each URS to FRS to DDS to Testing. SOP for Use of System (Login/logout, system

Detailed Design Specification (DDS)

Validation Project Plan (VPP)

Data Migration Plan

Risk Assessment

Traceability Matrix Procedures/Work Instructions

Instructions for use, administration, and control to

support system operation.

Training Installation Verification

Training program and documentation for users on the application and SOPs
Verify proper installation of the system software and hardware Verify proper operation of the system software and hardware Verify proper performance of the system software and hardware Document that summarizes implementation, testing completed, and overall system acceptance for use.

Operational Verification Performance Verification Final Report

navigation, routine operations, error reporting, running reports, etc), System Administration (Adding users, handling errors, designing queries, deploying reports, Back-up and Recovery) Onsite Supplier training, Train-the-trainers, functional training, on-the-job training Hardware Verification, Software Verification, Physical Security, Environmental Testing, Configuration Verification, Connectivity, Backup Testing performed against system functionality. Testing performed against User Requirements and specific configured workflows. Verification Summary Report