The inspection-ready lab includes IT

Oct. 24, 2017

The majority of clinical laboratories undergo regular inspections by government and/or accrediting agencies. These inspections cover all aspects of the laboratory operations, including information technology (IT)—the laboratory information systems (LIS) and middleware that modern laboratories rely on for those operations. What does it take to make sure your laboratory IT is as ready as the rest of the lab when inspectors come to call?

Inspections are opportunities

Preparing for, anticipating, and undergoing an inspection can be stressful. The potential fallout of not doing well during an inspection—risk to patient safety, cost to respond to inspector findings, and, in extreme cases, even closure of the business—is too great to chance failure.

On the other hand, doing well on the inspections and being awarded continuing accreditation provide an opportunity to publicize the laboratory’s contributions to the organization and community. Such communications may take the form of internal memos, news releases published on the organization’s website, or coverage in local media. Such publicity will help to instill confidence in the laboratory’s stakeholders—staff, administration, care providers and patients.

Clinical laboratories may be inspected by one or more agencies including CAP, CLIA, AABB, The Joint Commission, and even, depending on the types of services offered by the lab, the U.S. Food and Drug Administration (FDA). According to CAP’s website, “the Centers for Medicare and Medicaid Services (CMS) has granted the CAP Laboratory Accreditation Program deeming authority, which allows CAP inspection in lieu of a CMS inspection. It is also recognized by The Joint Commission, and can be used to meet many state certification requirements.”

The CAP inspection is “the gold standard” for many labs, so this article will refer to the checklists that CAP provides.

Tracking compliance internally

Laboratories have different ways of tracking the CAP requirements and their own compliance. Methods range from building a spreadsheet to using sophisticated computer databases or programs. One lab that this author is familiar with uses both methods: staff extract all the CAP requirements into a spreadsheet that includes the actual requirement information and add their own notes about the related records and their location(s). Armed with this tool, the lab or IT analyst can quickly locate the documentation for the inspector if asked to produce it. The lab’s compliance tracking software program keeps detailed training and staff proficiency records, and the spreadsheet notes where to access the records related to the particular requirement.

CAP checklists for IT

Modern clinical labs are large, complex organizations with hundreds of supporting procedures covering all disciplines of the lab and many related aspects—for example, sample collection, quality management, workplace safety, and training. Even though many labs have multiple information systems in the form of an LIS and middleware, there is not an IT-specific checklist. Instead, the IT-specific requirements are a subset of the Laboratory General checklist.

The reason IT solutions have a place in the lab is that they integrate with and support the lab workflow. Thus, many non-IT specific requirements are impacted by IT. For example, CAP requirement GEN.40530 says the lab needs a way to track samples sent to it from a remote site. If the LIS has the capability to do this tracking, then the functionality provided will need to meet the stated requiremets; for example, recording the time of dispatch and receipt.

Meeting the requirements

Some requirements are out of the lab’s direct control, such as those dealing with the facility maintenance, fire equipment, network security, and power sources. For these items, the laboratory can conduct internal inspections in conjunction with its IT peers to ensure compliance prior to outside inspections.

There are some CAP requirements which could be met by the lab’s IT systems, but due to poor or lacking software design, they are not. If the LIS does not provide the compliance needed in an automated fashion, the lab will need to develop a manual process. Looking again at CAP checklist item GEN.40530 for Specimen Tracking, if the LIS does not have an adequate tracking system, the lab can design forms that are completed by hand and kept on file. In cases like this, the lab benefits from having a strong IT representative who can communicate the particulars of the requirement to the vendor and advocate for its inclusion in the vendor’s software delivery plan.

There are several requirements related to system validation. All of these requirements state the need for validation upon initial software installation and whenever a modification is made. In addition, some require periodic validation even if no system changes have been made. They are:

  • GEN.43022: LIS testing, no periodic revalidation required, records must be kept two years beyond the life of the system
  • GEN.43450: calculated patient result values; every two years
  • GEN.43875: auto verification, at least annually
  • GEN.48500: interface result integrity, at least every two years.

Validating a new or a major LIS upgrade involves hundreds of hours of testing, with potentially thousands of test steps. While the listed requirements are only a small part of the overall checklist, the amount of work and record-keeping to demonstrate compliance is disproportionately large.

Capturing “test evidence”

After developing the test plans for the validation process, the laboratory or IT analyst captures “test evidence” for the record. The test evidence may be copies of patient reports, or screen shots that show the software has performed as expected. For smaller projects, such as the two-year interface validation, it may not be an issue to print the screen shots and store them in a three-ring binder whose location is referenced in the spreadsheet mentioned above.

For a new laboratory or blood bank information system, the test evidence can easily amount to hundreds of pages of data. Labs with space constraints may choose to capture the information electronically using screen print tools or scan the printed pages so they can be stored electronically. The spreadsheet would be completed with the electronic file information necessary to find those records easily in cases where the inspector wants to review them.

More and more, labs are looking for automated tools to alleviate understaffed departments and provide efficiencies that free up time for their existing staff to focus on more complex issues. One such tool is the compliance tracking software solution mentioned above, a system that replaces manual tracking of personnel training records and employee proficiencies.

Another solution that’s being used in more laboratories is automated testing software. This software performs the actual testing, and it also captures the records necessary to demonstrate that the system performs as expected. Robust testing software can also summarize the records in a way that shows the conditions tested and includes a cross-reference to the test case or cases in which the condition was demonstrated. The reports are available electronically.

A state of readiness

A colleague who at one time was associated with a blood bank software vendor recently told this author that when the company had its first few FDA inspections, there was an aura of fear and resentment over being judged by an outsider. However, the company eventually came to the realization that the inspectors were not the enemy; they were people who wanted to help make the company better, ultimately assuring the safest possible product was available for patient care.

Similarly, laboratory inspections can be used to educate the lab on process improvements that assure their practices are consistently reliable and safe. The inspection-ready lab and its IT staff should not “get ready” for an inspection so much as maintain a constant state of readiness through consistent, organized, and disciplined processes. That is the best way to enhance quality, increase stakeholder confidence, and assure patient safety.

Jennifer Lyle is CEO and Founder of Nevada-based Software Testing Solutions, LLC. She founded the company in 1999 to create innovative solutions which automate and accelerate the in-depth testing of healthcare applications.

Photo 241571148 © BiancoBlue |
Photo 75539817 © Vladimirs Prusakovs |
Dreamstime Xxl 75539817
Image by NatalyaBurova @
Coverbackgroundv1 Forstory
Photo 14015956 © Sebastian Czapnik |
Dreamstime Xxl 14015956