|Values are valid only on day of printing.|
Published: February 2009Print Record of Viewing
Dr. Hanson discusses the latest information on using middleware in the clinical laboratory. Properly defined, middleware rules can reduce the number of normal specimens that automated platforms tag for manual review. This results in improved turnaround times and fewer normal specimens requiring time-consuming manual review.
Presenter: Curtis A. Hanson, MD
Welcome to Mayo Medical Laboratories' Hot Topics. These presentations provide short discussion of current topics and may be helpful to you in your practice.
Our goals today will be: to understand the use of the CBC and differential count as the prototype for using middleware in the clinical laboratory; second, recognize the importance of modeling your laboratory practice before purchasing or implementing middleware; and, lastly, to understand how middleware can be used to enhance both the medical and management arms of the clinical hematology laboratory.
Why should we focus on the CBC and differential count? Well, the CBC is the most frequently ordered single laboratory test and it’s used in a variety of patient settings. The CBC and differential are used as a screening tool for health as it may provide clues for a whole realm of possible diseases. And it is utilized specifically to evaluate a variety of acute and chronic hematologic diseases and therapeutic responses.
I think we are all aware that there are two ways to obtain a differential count. First, the manual differential count is the traditional but labor intensive method that requires having highly skilled and experienced technologists. In addition, the manual differential count is inherently associated with a variety of potential errors. And from a management perspective, the differential count is an expensive labor intensive activity.
In contrast, the automated differential count has different issues to be recognized. It is clearly a more reproducible method than the manual differential and can be done quickly in an automated approach. But, on the down side, it is geared towards “not missing” any morphologic changes and it must recognize a wide spectrum of white cell abnormalities including those from both lymphoid and myeloid cells, acute and chronic disorders, as well as reactive and malignant processes. In addition, no single cell type in the peripheral blood perfectly represents each benign and malignant disease process. And the automated differential count cannot consistently distinguish between reactive and malignant cell types. Every instrument technology has its own inherent idiosyncrasies and, in my experience, will either over-capture or under-capture particular morphologic features. But from a management perspective, the automated differential count, since it is a technology based, is relatively inexpensive to perform. Bottomline: the laboratory must find how to maximize the use of automated differential counts while minimizing the number of manual differential counts performed.
Verification of the differential count can occur at any one of or combination of three steps. Certainly the modern hematology instrument can either trap or auto-verify results based on quantitative flags that are usually set by the laboratory and qualitative flags that are established by the manufacturer and usually based on abnormal light scatter or other qualitative aspects determined by the instrument itself. The LIS may also have the ability to apply autoverification rules. This is dependent on the particular system you have and its rule writing capabilities. Pushing the software support back to your LIS group will make it easier for the laboratory to meet regulatory requirements and it will also help provide necessary IT support and backup. In the laboratory the differential may be verified by either a technologist directly or with the use of middleware. Middleware can be acquired from either instrument manufacturers or software vendors and should be capable of incorporating data from both the instrument as well as demographic and laboratory data from the LIS into a rule based approach. It is critical when choosing and implementing a middleware solution, to bring that middleware vendor, the instrument manufacturer, and local LIS resources together to understand the necessary interfaces and more importantly, the limitations of all systems involved. Again any combination of these three steps may be involved in the verification of the differential count.
Let’s now look at the possible steps that may occur from when a differential count is done to when it is entered into the LIS or the electronic medical record. First of all, the differential may auto-verify at the instrument and thus place the results directly into the electronic medical record or it may flag or trap that particular specimen; if it does, then the technologist may scan the slide, confirm the accuracy of the autodiff, and then release that differential without doing a full 100 cell manual differential count. If not, then a full manual differential review should be done. But it is important to think about the manual differential count in perhaps a different way. A manual differential ends up in one of two separate categories: those cases with no or only minimal abnormalities versus those that have significant abnormalities with clinical implications. Thus, in the laboratory the four green boxes identify the four key decision points; will the instrument auto-verify the results? Will the technologist scan and release this specimen? Will the manual differential count show only minimal or no abnormalities? Or will there be significant abnormalities on the manual differential? This is the time when it is essential for a laboratory to model their practice so they can understand how their cases are distributed within these various categories. This will help determine the potential value or not of the middleware product and its implementation. For example, does your instrument currently auto-verify at a rate of 80% or 40%? Clearly at an 80% level there is much less opportunity for a middleware product as opposed to 40%. If the scan and release rate is a high number, like 30%, versus a very low number, it would offer more middleware auto-verification opportunities. And finally, take a hard honest look at your manual differentials and understand how many really have contributed true clinical value by having a morphologic review. Again if it’s a low percentage, middleware can clearly add value. The scan & release and the minimal or no abnormality boxes are the key areas that a laboratory needs to focus on as they will provide the most opportunities for using middleware within a clinical hematology laboratory.
I want to share with you our experience here at Mayo Clinic, again using those four major decision points. We instituted middleware in 1996 and I pulled some old data prior to that to show what we were doing. I know that sounds like eons ago, but at that point in time the instrument was auto-verifying using its internal software at a 40% rate; we were scanning and releasing without doing a manual differential in 20% of cases; and when we took a hard look at our manual differentials, 30% of all cases that we did or 3/4 of the manual differentials really had no or only minimal clinically significant abnormalities. Now, let’s look at 2008: we see an auto-verify rate at the instrument together with middleware at 82%; an 8% scan and release rate; 2% manual differentials with normal to minimal abnormalities and an 8% manual differential rate for clinically significant abnormalities. This clearly shows a significant change in the lab’s workflow after the successful implementation of middleware. And that change is coming primarily from those middle two boxes of scan and release and manual counts showing no or minimal abnormalities. What was the impact of this change? Within 3 months of implementation, we had decreased our FTEs and improved our turnaround times within the laboratory.
The rest of my talk will be focused on how middleware can be used in the hematology laboratory. Although I will be focusing on the hematology laboratory, all the points that I make can be translated and applied to other clinical laboratories. I will first focus on #1: automating rules for manual differentials.
Again, we need to look at our four key boxes and focus on these two boxes where we have our biggest chance for gain by using a middleware product.
The first step is to simply write rules for what the technologist does. If they look up results in the computer, write a rule. If they compare results to previous studies, you write a rule. If they base a decision on where the patient is or who their doctor is, if they minimize or ignore certain results or certain instrument flags, then write a rule. This very simple and obviously self evident step is the most critical part and will give you the biggest bang for the buck within the laboratory. Second, use the quantitative numbers coming off the instrument, use the instrument flags, and incorporate whatever demographic or patient information you can get out of the LIS, such as physician name, patient location, the location of a laboratory, the elapsed time in between specimen testing, and finally by defining different types of CBCs for different clinical purposes. You may find the published consensus guidelines from the International Society for Laboratory Hematology regarding verification of the CBC and differential count as a helpful place to start.
There are particular caveats for writing rules that I would like to share with you based on our 12 years of experience within the laboratory. Most important, rely on data not on individual case exceptions. Don’t reflexively change your whole rule system based on one single case. Make sure that you understand that exception and insist on sufficient data to understand what the impact would be of either changing a rule or writing a new rule. It is important to identify what flags or standard operating practices (SOPs) are driving the current review process, in other words, what’s driving the work in the laboratory? Be sure to review the data to see what happens in those cases: is there no change to that differential count coming off the instrument, only very minimal changes that will have no clinical impact, or are there significant manual differential changes that warrant keeping a particular SOP or rule in place? Be quick to ask the technologist doing the job what they think. I am sure you will not be surprised when they are the ones that know where they are wasting time on a particular activity and when they are providing high value work. It is important to never be afraid to ask why and never hesitate to ask for data. Data is your friend. Importantly, be creative; think of new ways to get things done within the laboratory.
I want to give you an example of how we went about creating change and solving one of our lab problems at Mayo. The problem in the laboratory: the physicians were calling the laboratory wanting the CBC and differential results now! The response from the laboratory: The CBC is not normal and I have to do a manual differential count. Call back later. The retort from the clinican: “I know the CBC is not normal; this patient is on chemo! It is not supposed to be normal! I don’t want a perfect CBC - I just want reasonably accurate platelet and neutrophil counts so I can make a decision NOW as to whether this patient can receive today’s chemotherapy dose.
We then went back and reviewed our CBC data from our chemotherapy unit. Our findings: 55% of the specimens were auto-verifying as compared to 80% for the rest of the practice, i.e. we were prolonging turnaround time. Interestingly, the platelet and neutrophil counts were never significantly changed. And think about it: we were replacing a likely accurate automated absolute neutrophil number based on the counting of thousands of cells with an inherently less accurate manual differential neutrophil percentage based on a one hundred cell count! We also found that the so-called value of the manual differential count was that we identified left-shifted cells, red cell changes, some white cell abnormalities, and sometimes known or persistent circulating malignant cells. Although these findings would certainly be very important in a screening CBC, in this particular setting the clinician already knew that information and just wanted to know what the platelet and neutrophil counts were. The additional information was really of no value to the clinician in how they were looking at these particular patients at this point in time.
What did we do about this? We created a new type of CBC that was available only to hematologists and oncologists called the CBC chemotherapy or CBC-C. A perfect differential count was not the concern - just “I want a reasonably accurate neutrophil and platelet count”. The most important thing was to provide for a rapid turnaround time that would allow the patient to get through the system and receive their chemotherapy on time. Now it does require the clinician to understand the differences between the CBC-C and a routine screening CBC. Indeed we send out annual reminders to emphasize the differences between the various CBCs and how best to use them. But by creating this different CBC it allowed us to create unique autoverification rules that best met the clinical need.
The second issue to discuss is the focus on patient safety issues.
Why call it patient safety? While truly primarily sentinel events are rare, any Hematology lab will generate revised reports which may contribute to subsequent unnecessary clinical steps which in turn may lead to unnecessary patient events. Thus, every lab needs to look at their revised reports and near misses; why did they happen and what went wrong with the process? Until you collect this data and actually look at it, I guarantee you will underestimate the severity of this issue in your laboratory.
When you look at revised reports and near misses in the hematology laboratory, you will find that they may be related to revised differential counts, revised platelet counts due to clotted specimens or EDTA associated clumping, or it may be because a SOP was not followed through. In other words, the memory was faulty: the tech did a scan and release instead of a manual differential, they forgot to have a second review by a senior tech or physician, etc. In addition, there may be clerical errors as data is entered into the LIS or the worst possible scenario: mixing up slides and paperwork. Think about how many sticky notes your laboratory has on the wall and how dependent we are on those as well as our individual memories. When we have these dependencies, I guarantee you that we will end up with patient safety issues.
So it is important to realize in all these situations that individual patients act like individuals, they don’t always follow the rules for the group. So let’s call our hypothetical patient “Mrs. Johnson”. Well with Mrs. Johnson, blasts may be missed on follow ups because of the particular morphology of her cells. For the same reason lymphoma cells may be missed or in general any situation where the morphologic features may be difficult to interpret. We all know that EDTA platelet clumpers can lead to errors and red cell agglutination can create trouble. Sometimes the clinician or pathologist really wants specific follow up on Mrs. Johnson or there are particular protocol or clinical trial requirements for Mrs. Johnson.
Middleware can help with all of these situations. When Mrs. Johnson’s particular problem is encountered, the laboratory can immediately create a rule to trap the next sample that comes through the lab from her. A timeline is added to the rule such that it expires in one to three months. And it doesn’t matter where in the system Mrs. Johnson walks into, you will have the same outcome. In other words, the sample will be trapped and the laboratory will do the right thing for Mrs. Johnson.
The third item we will talk about is how we can use middleware to enhance laboratory effectiveness.
Clearly one of the big advantages that middleware offers is that it allows the lab to continue to run if the LIS is down and will continue to drive the operations within the laboratory. It is also able to streamline the flow of data from the instrument to the workstation regardless of where that data was acquired. Thus, you can really minimize the number of manual steps between the instrument and where the slide review workstation is. You can use middleware to make the laboratory paperless at each workstation, using it to transmit scatterplots to any of your workstations, making all the CBC and differential data easily available, etc. You can also use middleware rules as SOP reminders for the technologists. For example, you can set it up such that new employees cannot report out particular morphologic findings such as schistocytes without a second review or all blasts >1% need an initial physician review. One can also use the middleware as related to particular disease processes and set the frequency of review after an initial diagnosis of a disease.
Next, number 4 – how can middleware be used to support management goals?
One can ask the question: is there laboratory information that cannot be garnered through routine reports that might be available through the middleware system? For example, technologist productivity, the type of cases being released by the technologist, the number and type of cases trapped by each rule thus allowing you to monitor utilization of the rules and to identify new clinical scenarios for potential new rules to be written.
Finally let’s talk about how middleware can be used to help unify multisite practices.
It is a rare laboratory these days that isn’t a part of a multisite practice. A hospital and a clinic, or multiple hospitals and clinics within an organization whether that organization be local, regional or national. You may have different instrumentation at different sites, you may have different clinical needs at each site whether it be a clinic or a hospital with different patient characteristics. Not all sites may end up doing manual differentials and all sites may not have a common electronic medical record. Thus, middleware offers you a common language through which all the laboratories can communicate together. It offers you a starting point for standardizing and integrating your medical practice.
So in conclusion, middleware is a very important tool that can be used in the clinical laboratory. But before you purchase or implement middleware, make sure that you model your laboratory practice to understand the potential benefits. Keep in mind both the value and cost benefits and how they relate to your laboratory. You must envision the coordinated roles of your instrument, LIS, and potential middlware system and it may be that your instrument and LIS are sufficient to meet your need. It is critical to work with your IT people to understand their needs and their willingness and ability to help provide you support.
Automating rules for differentials is the easy but most critical part for middleware implementation in the hematology laboratory. I must challenge your concept of the CBC and differential and urge you to think of the CBC as not a single test but as a common assay that is used in a variety of very different clinical situations and scenarios. Second, focus your middleware on patient safety issues: every laboratory needs to look at all their revised reports and near misses. Why did they happen, what went wrong in the process? And then use middleware to fill in the gaps in your patient safety processes using, as we talked about before, the Mrs. Johnson rules, and using SOP and disease specific popup reminders.
Middleware can also enhance your laboratory effectiveness by helping you create the paperless laboratory and to ensure the ideal screen presentations of data to your technologists. By minimizing steps between the analyzer and workstation, you are decreasing the chances of specimen and paper mix-up. Middleware may be able to help support management goals by providing other sources of information, and middleware may be the common language to help unify multisite practices, and it can be used as a starting point for standardization and integration of a multisite practice.
Our goals today were to see how the CBC and differential could be used as a prototype for middleware implementation in the clinical laboratory, second to recognize the importance of modeling your laboratory practice before purchasing or implementing middleware and finally to understand how middleware can enhance both the medical and management arms of the hematology laboratory. Thank you for the opportunity to speak to you today and hopefully I have been able to answer some of your basic questions regarding middleware and the clinical hematology laboratory.