Software quality is a broad topic and often not well understood by clinical diagnostic laboratories, which is why we thought it might be helpful to offer a quick primer. Commonly, the “quality” of software refers only to its ability to meet a set of requirements. But meeting requirements is just one of many metrics for measuring quality and if you do a quick internet search, you won’t find much agreement about which metrics are the most important.
However, as software developers and consultants, what we can say with certainty is that quality should never be compromised. This is particularly true in regulated industries, especially the clinical lab, where every system revolves around the delivery of patient-centered healthcare. So, let’s take a step back and look at some quality concepts, beginning with validation.
What is validation?
Validation is the process of establishing evidence that the laboratory method or software does what it’s intended to do. That sounds simple enough, but it can get confusing when it’s used in different contexts.
Laboratory method or clinical validation
Most lab staff will be familiar with lab method or clinical validation. Within every non-research laboratory, there is likely some type of assay or method validation being performed. That’s because it’s required by Current Good Manufacturing Practices (CGMP), CLIA, and CAP regulations.
Validating laboratory methods ensures that the data and results are consistent, accurate, and precise. In a clinical setting, validation is also used to prove that a test can effectively diagnose or predict health risks.
Regulatory bodies typically provide guides (such as this one for Bioanalytical Method Validation) on how to carry out and document method validation, as well as appropriate acceptance criteria.
Software validation
Within software engineering, validation and verification are two concepts that are often discussed hand-in-hand. Both are methods of ensuring quality. One way to distinguish the two is with these two simple definitions:
- Verification is building the system right. This means confirming that the specifications are correctly implemented.
- Validation, on the other hand, is building the right system. This goes back to confirming that the software meets user needs and requirements. You might have a piece of software that’s bug-free, but if it’s not solving the problems that you need it to, it’s essentially worthless to you. It’s not valid.
The FDA defines software validation as: “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.”
Steve Easterbrook, a professor of computer science at the University of Toronto, offers this diagram below to show the distinctions and overlap between software validation and verification:
The Institute of Electrical and Electronics Engineers (IEEE) has developed numerous technical standards, including software verification and validation standards. However, it should be noted that the organization is not a regulatory body, so usage of its standards is voluntary.
Does all software have to be validated?
The short answer is no. Not all software has to be validated according to set standards. But there are two specific cases (in the United States) where it must be.
- According to the FDA, software validation is required when the software is used in the production of a medical device or forms part or whole of the medical device.
- It is also required for computer systems that create, modify, and maintain electronic records and signatures (21 CFR Part 11). You must prove that your electronic records or signatures are equivalent to paper or ink records or signatures. This requirement applies to any entity that maintains records or submits information to the FDA as part of an FDA regulation.
We always recommend software be validated
Even if your industry isn’t regulated by the FDA, validating software is a good practice to ensure quality. Remember, whether or not your lab’s software fits into either of the two cases listed above, software is a critical part of modern laboratory testing, and therefore plays an important role in overall assay validation. Furthermore, as we mentioned in a previous post, CAP and CLIA regulations focus heavily on traceability and change documentation, so you’ll want to strongly consider validating your software if your lab adheres to these regulations.
At Semaphore, we build our software to be of the highest quality possible. We develop and carry out validation plans for all our work to ensure our customers have the documentation they need to complete their laboratory test method validations. For any software we produce, whether it’s a custom application or a LIMS workflow, we create software validation documents that focus on the requirements that the software was built to. Our customers often use these documents to fulfill certification or accreditation requirements.
