The Continuing Evolution of Quality Management Software
Ongoing improvements protect data integrity
Michelle Dotzert is the creative services manager for our partner brand, Lab Manager. She holds a PhD in kinesiology (specializing in exercise biochemistry) from the University of Western Ontario. Her research examined the effects of exercise training on skeletal muscle lipid metabolism and insulin resistance in a rodent model of Type 1 Diabetes. She has experience with a variety of molecular and biochemistry techniques, as well as HPLC-MS.
ViewFull ProfileLearn about ourEditorial Policies.
George Thanasides, senior partner at SoftTech Health since 2011.
Q: When you speak of the evolution of quality management (QM) software, what do you mean?
A: The evolution of QM software, like that of all software, has been marked by developments in technology that made it possible to replace less efficient manual processes. At first, software was a simple digital alternative to pen and paper or typewritten processes. We used keyboards to enter data and maintain records. For example: instead of writing in a temperature chart clipped to the side of a blood bank refrigerator, we typed in the exact same pieces of information into a computer.
Software developers then began to take advantage of the fact that the software “knows” who is entering the information at an exact date and time. So, secure sign-ins and automated date stamps, among other processes unique to software, relieved end users of additional manual record keeping and took care of recording that information. This new process offered clear and measurable efficiencies not only in terms of time, accuracy, and cost, but also, and more importantly, data integrity—data could be validated as “unimpeachable.”
Q: What is the connection between the evolution of software and data integrity?
A: Accurate and timely information is the basis for the development of a solution to any problem. On a fundamental level, the right building blocks need to be in place for things like vaccine development and test development to take place. The information provided by software needs to be accurate and precise.
In addition, risk mitigation should be an ever-present concern for lab management. For example, when an end user manually enters the name of a person who approved a new SOP, or manually enters the date that it was approved, it opens the lab up to the same risks we saw with old-fashioned pen and paper, which is the possibility of making inadvertent mistakes.
What if an incident occurs on November 21, 2021, (11/21/21) and the correct SOP was actually in place on that date, but the end user made a typo and it looks like the SOP was retroactively put in place on December 11, 2021, (12/11/21)? That typo opens the lab up to unnecessary questioning because of human error in data entry.
Or, a user might enter a “guesstimated date” with the best intentions of later correcting the entries, but with so many other demands on their time, they simply don’t get to it. With the added pressure on time caused by COVID-19, this is becoming more and more of a possibility.
Q: Is the evolution of regulatory standards also interrelated with QM?
A: Regulatory standards—as enforced by laboratory accreditation—have evolved to become more comprehensive and rigorous over time. Evidence-based practice and root cause analysis, along with systems-based thinking around quality in many industries, not just the lab, means that ISO 15189 and other standards are now even better at addressing and assessing systemic causes of errors in the lab. It’s important to remember the intent and spirit of the standards: it’s not to create more “administrivia,” it’s to help laboratories mitigate risk and keep patients safe. Most QM software is designed to support that intent; it’s not meant to help the lab simply show compliance but to actually be compliant.
Q: Do you have any concerns as you survey this evolving QM landscape?
A: Actually, I do. We’ve been saying this for years, but it bears repeating: QM software should not slip backward to the old days of manual entry of key quality data points. It’s important to remember the intent and spirit of QM regulations, and to facilitate true compliance.
For example, accreditation agencies want to know whether a subject matter expert actually reviewed the SOP and vetted its quality before it was distributed to the lab. This requirement is grounded in the intent of making sure that laboratorians are following guidance that was written by someone who is properly trained and certified. For example, if an SOP requires approval by the director, they should be the only person who can document that it is approved. If it is possible for other laboratory staff to effectively impersonate the director and document that the SOP was approved—even if it was—then the integrity of all the data is called into question.
Q: Despite these concerns, do you see any positive trends for the future of QM?
Yes, I do. There seems to be growing awareness by all parties—software developers, regulatory bodies, and certainly labs themselves—that there is a right way and wrong way to go about making and using software to aid QM processes. People understand: we can use software as a tool, not just to replace a pen or pencil, but to reduce human errors in data entry, and to reduce the attendant risk. More and more folks in the lab space, including the accreditation agencies, are understanding that and demanding that QM software meets the same standards of accountability. The tools we software developers provide should have the same integrity as the users we support.