In talking with a Quality Manager in a young med device company last week, I touched a nerve and set off a firestorm of frustration related to clinical quality management. Fortunately, it was not directed at me.
Cindy (not her real name as I did not ask her permission) told me that she is “sick and tired” of having to force-fit her quality processes into systems designed for managing manufacturing quality. She said she needed a system that could meet her needs to manage clinical process quality.
Perhaps it was wrong of me to poke the bear when I asked her, “But is there really that big of a difference?”
Of course, I already knew the answer, so that was just me adding some fuel to the fire. But it did set off a diatribe worth recounting.
Clinical Quality Management is Not Manufacturing Quality Management
Cindy acknowledged that the core quality processes for managing widget or drug manufacturing versus clinical operations quality share a common language and processes. For example, identified issues are often called deviations, the fixes are referred to as corrective actions, and changes are implemented under change controls. But she made it clear that a quality management system for clinical operations use has to address a completely different set of needs in a completely different context once beyond the most superficial level.
She illustrated her frustration by telling me about her current situation. Brought in to institute a quality system for clinical studies, she immediately started to review clinical quality management system (CQMS) solutions that would meet her needs. But she was stopped in her tracks by the COO.
He informed her that she is lucky because they already have a quality management software system in place. And even better, it had been around for years, and that “everyone uses it.”
hbspt.cta.load(7421631, ‘a62ba25c-c3b3-423f-9212-d9372ecb615c’, {“region”:”na1″});
I am sure Cindy groaned at least inwardly at that moment because, as she told me, she has been down that road before. Most QMS software solutions are designed for manufacturing environments, where deviations refer to a defect in a product. Every field in every form reflects that orientation. Trying to adapt that system — designed and configured for manufacturing — to clinical operations processes is (and this her language) a “frustrating exercise in idiocy that results in a terrible system for the clinops users.”
She illustrated her point by saying that the whole exercise includes language like this: “Where this form has a field for ‘Lot’ or ‘Batch’, we put the study name. And where it talks about the equipment, we use that for the specific site where the incident occurred.”
In other words, every step in the process requires translation from what the system was designed for to what she needs it to do. And that, to put it mildly, is a real turn-off for users. And you can imagine the hell it creates when it comes to reporting!
So I guess the term QMS for Quality Management System needs a little more context. As my kids would say, ya think?
A Clinical Quality App is Different
Let me try to be less sassy and identify some of the ways that a quality management application for clinical operations needs to be different from a quality management application for manufacturing:
The Language
Clinical Quality oversight has its own language. For example, protocol deviations are different from a deviation in a product with the wrong part installed. The forms for documenting the deviation need their own fields (metadata) to identify and categorize the issue.
The Steps in the Process
What happens after a product defect is found is different than when a process deviation is identified. While both may be an “investigation,” the steps and information collected are entirely different, and the system needs to reflect those steps and accommodate the data.
The Users
The users of a quality system, and even the setting where they are used, for manufacturing and a quality system used for clinical quality oversight, are completely different. Therefore, systems designed for use by one type of user will be suboptimal for the other.
The Reporting
Manufacturing deviations have a much higher frequency (at least we hope they do) than what is expected in a quality environment. After all, if you are manufacturing thousands of items, there will be more issues than we would see in a moderately sized clinical study. That means that reporting requirements will be very different, with one more focused on qualitative data and one more focused on context and narrative.
And that is just off the top of my head. I am sure there are many more differences. But I am not asking Cindy; that could put her over the edge 🙂
Manage Clinical Quality Processes, Not Widgets
At Agatha, we support both manufacturing and clinical operations quality processes with our QMS application, Agatha Quality. But the key is that our one application has two VERY different configurations, with different forms, views, fields, and reports. That means we never have to show one form, for example, but use the dreaded phrase “imagine if this form was a different form.”
By the way, if you ever hear that in a software demo, run for the exit. It is a clear signal that the system you are looking at “could” work for you if customized beyond recognition but is not designed with you or your process in mind.
By now, I am sure you get my point. If you are looking for an application to manage clinical quality processes, look for a system designed for that specific set of procedures. Don’t allow yourself to be cajoled into using a system designed for different users managing a different process. You will be happier with the result, and your blood pressure will be lower than Cindy’s was in our conversation.
And don’t forget, #ClinOpsRocks!