Healthcare Customer Satisfaction: More Talk AND More Action Customer satisfaction (Voice of the customer) is a recurrent th...
Sunday, October 30, 2011
Quality and Risk revisited.
I read with interest an article in last month’s (September) edition of American Society for Quality (ASQ) Quality Progress which is about doing risk assessments throughout an organization. (See Site Seeing by L.W. Yu, E. Urkin, S. Lum, R.S. Kennett, and R. Ben-Jacob. www.quality progress.com). In it, the many (!) authors make the point that companies need to keep their eye on RISK throughout the organization and that that is best done as part of risk-based audits. Helpfully, they present a number of tools that can be used, especially an example of a probability of occurrence-severity grid which in my experience is very helpful for setting priorities. Attack the issues that have the highest (occurrence X severity) product first, and address the lesser issues later.
I agree with them. In the medical laboratory we have an ISO document ISO/TC 22367: 2008 Medical laboratories -- Reduction of error through risk management and continual improvement which gives the same message. (Actually I agree with them so much that I wrote on the subject over a year ago – see MMLQR: Medical Laboratory – Quality and Risk. September 25, 2010).
A few comments about measuring risk, especially for laboratories which do not follow or understand ISO standards, in particular ISO15189:2007.
One of the expectations of Quality Systems as iterated in 15189 (and CLIA and CLSI GP26) is that the laboratory should demonstrate that it performs preventive actions. Commonly this is an expectation that laboratorians struggle with because they don’t understand where or why they fit within the laboratory.
Risk analysis fits perfectly within the Quality Management systems as a direct approach to Preventive Action. Preventive actions are the process of looking at new equipment, new procedures, new policies, or the existing environment (think safety audits) to see if they have the potential to cause more harm than good, and then addressing the problems BEFORE they occur (ergo they are preventive).
I think that the reason that these are so difficult for laboratorians is because thinking about problems before they occur seems like a lot of “blue-skying “ and a waste of time. Well it is blue-skying, but with a safety mechanism built in. If you dream up a potential problem that is either so implausible (very low occurrence) or so inconsequential (very low severity) you don’t have to do anything about it. But on the other hand if you discover only one thing that has a real potential impact on worker safety, or patient safety, or test performance, or quality control, or finances, or liability, then the risk-preventive action process has done you a real favour.
So how often do you go through the exercise? It depends. How often do you do a safety audit? When you are setting up your safety program you probably do them frequently. Once the system has settled in, you probably do them less often; same with risk-prevention audits. The only real problem is when you slow down to the point that you have essentially stopped.
As a commitment, you can tie doing a risk-prevention audit to when you introduce a new piece of equipment, a new procedure, or a new policy, and again a few months later when it has settled in.
In addition, this can be really valuable when you have made changes because of an imposed change in regulation or budget. Not that I am a “I told you so” kind of guy, but recording and reporting potential risks in a constructive structure along with a resource strategy of how to prevent them, can be both helpful and powerful.
Risk-prevention audits don’t have to take a lot of time. Often you can work through the whole process in a few hours. But give yourself enough time to take the task seriously.
You may be very glad you did.
PS: Some folks still write and sell software that includes the term CAPA which suggests that Corrective Actions and Preventive Actions are the same thing. They are not the same thing and those software packages are a waste of electrons and machine language and money.