Just the other day a question of how to alert physicians of laboratory reflex rules came up. After all, everyone's rules are slightly different.

Examples: if the dipstick is positive for blood or leukocyte esterase, perform a microscopic examination of urine sediment; if the triglycerides are elevated, perform a direct LDL cholesterol measurement; if a screen for unexpected antibodies is positive, perform an antibody identification. These "if-then" rules are simple enough.

But many are more complex. A culture reflex based on a microscopic is subjective and variable if based on the number of white cells seen. There may be rejection criteria based on the number of squamous epithelial cells. While this may meet a physician's general expectation to "Culture if indicated," it's a broad net that will capture a lot of contamination and miss a few true positives.

Physician expectations and laboratory rules may collide. Catheterized specimens are often thought better – are they? An indwelling catheter can result in treating the catheter, and a straight catheter scoops up everything in its path. OB/GYN docs may order cultures on asymptomatic patients, resulting in "more" contamination.

Our rules, which are designed for symptomatic patients with a florid response who are able to collect a clean catch specimen, often don't fit. Instead of focusing on exceptional presentations – a hallmark of other healthcare professions – we try to standardize collection with expensive kits, complex instructions, and harder to read signs. What many patients hear, often enough, is "Pee in a cup."

If all patients are different, why should a "one fits all" approach to reflexive testing work? Perhaps, diagnostic algorithms that take into account the total testing process, including patient presentation and symptoms preceding the order, is the answer. Rules would account for age, gender, symptoms, medications, comorbidities, etc. This information could also guide the workup. It might even reduce unnecessary testing.

All of which still needs to be told to the physicians, somehow, to get "medical necessity." Don't get me started on billing.

Don Watson says in his introduction to Watson's Dictionary of Weasel Words, Contemporary Cliches, Cant, & Management Jargon that weasel words are bringing about the death of language. "The real disease," he writes, "is in the system: in the new models of business organisation, in the triumph of economics. It is there in the cant of competitive advantage and human resources management, transparency, accountability: in the clichés, consumer, client, key, core, going forwards, at the end of the day, outcomes-based. "

Weasel words – a pejorative term – apparently convey deep meaning, but which say nothing. Their use can range from obtuse to oppressive. Here are a few:

• Line staff – as in "the line staff will be recruited" like fruit flies for genetic experiments.
• Empower – as in "this will empower line staff," who are otherwise unable to self-actualize without the magnanimous gift of whatever-it-is.
• Change – as in "change is inevitable," and as my kids say, "Duh."
• Buy-In – as in "we need line staff buy-in," as though the only way to change anything is by seduction rather than mutual understanding.

When weasel words are used enough, two things happen. One, they become the culture and asking what they mean is de facto counter-productive. Two, they lose their promise of meaning, and perfectly good words such as communication are enlisted. "Line staff needs communication to be empowered to facilitate buy-in regarding this change." I know managers who talk like this every day. I can't help but wonder what their dinner conversation is like.

All this would be funny, except for not knowing what people are really saying. And if you don't know what people are saying, it's impossible to know what they think they intend for you to hear what they mean to say. I think.

A height of absurdity was recently scaled when it was announced that patient falls (as in patients falling out of bed onto the floor) are now called unplanned descents. Maybe, Watson's right. This kind of language takes all the fun out of talking.

The other week I watched a show on the Discovery channel in disbelief. Called Pig Bomb, it described hoards of feral pigs roaming the Southeast. Locals may have cross-bred the American boar with its ill-tempered cousin, the Eurasian wild boar, for hunting. A six hundred pound, sixty mile per hour beast with tusks would be hard to shoot, never mind it panicking unarmed civilians. But I wonder if it's all as bad as it looks.

And so I ponder swine flu.

A threat of unknown impact is always unsettling, and certainly with H1N1 there is real concern. Hospitals strained to capacity will find it difficult to handle a sudden influx of patients with influenza-like illness while coping with their own staff getting ill.

Just the same, planning is smart, even if we don't know what this particular "pig bomb" will do. You should know your laboratory's plan, which may also include:

• Stockpiling – your hospital pandemic plan may include rapid influenza testing but also point of care testing to screen for other causes of influenza-like illness (ILI). Include backup suppliers in your plan as well as procedures in the event you have to change kit manufacturers.
• Staffing – if staff members become ill and need to stay home for a week or more, you need to have a plan to limit or reroute testing. This may include, for instance, formatting your test menu as reference lab tests in your information system ahead of time.
• Traffic – your hospital may have a plan or may have already started to reroute patient traffic, depending on symptoms. Many will come to your laboratory, and you'll want to be aware of parking and waiting room issues to make it easy as possible for your patients.

Not just planning but weekly planning meetings can help your laboratory adjust as events change. If you plan, you can avoid the panic.

MS-DOS (Microsoft Disk Operating System) debuted 28 years ago, quickly finding its way into labs on PCs in offices or attached to instruments. Programs such as BASIC promised much. We just knew, deep down, that computers meant less paper, effortless statistics, and (ha, ha) fewer telephone calls.

Nearly three decades should be enough time for a technology that doubles in capacity every two years (Moore's law) to accomplish all this. But modern information systems generate more paper, telephone calls, and steps than our old paper system ever did. We fill a dozen recycle bins a day, generate dozens of corrected and amended reports, worry about intermittent network failures, and spend hours on the telephone arguing with "support" that something doesn't work. We tolerate a standard that is sometimes unresponsive, often inadequate, and frequently burdensome.

Don't get me wrong – it's great to get statistics, retrieve results, or send reports instantly. But let's be real. Do we really know results are stored correctly in history? Do we really know reports are sent to the correct doctor? Do we really know calculations are done correctly? All software is buggy.

Somewhere along the way we started working for these machines, which, for all their speed and memory, are painfully slow. More and more time is spent waiting for a computer to retrieve, process, or print. Patients are compared to barcodes, stickers, and wristbands. Quality control is driven by point-at-a-time rule decisions, inviting techs to repeat until in. The days of multitasking, holding a requisition in hand, and glancing at a dozen plots on a wall are gone, replaced by efficiency designed by people who are, for the most part, not laboratory professionals. I wonder when this "efficiency" will happen.

Any application needs a simple test: does it suggest a better way of doing what we do now? We don't buy potential, after all, but performance. Each laboratory needs to define what "better" means, and managers should listen to their techs. The bookends are still the doctor and the patient, and computers need to shorten the distance between the two.

I once read an article about a BASIC program used to temperature-correct arterial blood gas results. This was in the day when a program could be "keyed in" from a magazine. BASIC, which stands for Beginner's All-purpose Symbolic Instruction Code, was quick, versatile, and loaded on nearly all computers. You may remember this:

10 CLS
20 PRINT "Hello World!"

BASIC is an interpreted language, meaning that instructions are read and executed on the fly. It is thus limited by its interpreter, which usually requires that programs be written in a way that makes them nearly unreadable. BASIC programs contain sequential line numbers (the 10 and 20 above), limitations on variable names, obscure GOTO and GOSUB statements, and other quirks. BASIC programs, often "spaghetti code," were devilishly difficult to debug.

But in the day, it was cool stuff. All laboratory statistics and even graph generators could be programmed in BASIC, and its decision branching made it possible to create interpreted, customized reports. It didn't take a great programmer to code in BASIC. Even artificial intelligence seemed around the corner. At a time when many labs were still hand-writing results on carbon-copy slips, this showed promise.

Was this promise a fairy tale?

Information systems are now ubiquitous in laboratories as integrated systems, instrument data managers, and middleware. Many include some capability to program calculations limited by software design. CPSI, for instance, does not include "If-then" statements, which makes conditional calculations cumbersome to program. But some onboard data managers make limited decisions i.e. automated microbiology systems. I don't remember seeing a side-by-side comparison, but it would interest me as a programmer. It should be considered when purchasing a system.

There is tremendous potential to develop expert systems that translate all by rote decisions, from true autoverification to antibody identification, but I wonder how close we are and how well what we have works. Once upon a time, it all seemed so BASIC.

Much was made of the President's "beer summit" last July, a meeting between a black professor and the white policeman who arrested him, something the Wall Street Journal labeled a "teachable moment." Aside from wondering what kind of beer goes best with conflict resolution, I'd never heard the term.

A teachable moment is that rare and special event in the classroom when a teacher has the ideal opportunity to offer insight and students are most receptive. Teachers are aware of and seize these opportunities. Holidays and important current events are two obvious examples.

The laboratory, too, has teachable moments. The difference is that a professional is both a student and a teacher. Recent examples I've encountered:

• A gram stain on a blood culture, positive in one of four bottles, showed small gram positive coccobacilli, but these organisms weren't viable when subcultured. According to the physician, the patient had been given antibiotics for bronchitis and presented in a week with status asthmaticus. Our reference lab consultant suggested a weakened Arcanobacterium.
• A nurse asked me the other day, "Is our C. diff kit not accurate? We are repeating many tests." Currently, we perform a toxin assay not considered to be a good test for cure. The test is run on multiple samples to increase sensitivity, but a positive test may not specifically indicate active infection. I explained that we are changing our algorithm to test for antigen first.

These events, while generating interest and enthusiasm, aren't just academic exercises. They are chances to improve patient care by increasing knowledge and tweaking or changing what we are doing. Like a teacher in a classroom, we need to watch for and seize these events.

Even creating collection kits with highlighted instructions when a question such as How do we collect a specimen for swine flu? is asked – can be a teachable moment. As professionals, we support and inform. Other professionals – doctors, nurses, ancillary departments – reciprocate. It's a "win-win." The beer will wait until we get home.

It wouldn't surprise me if most laboratories have more written procedures than all other departments of the hospital combined -- shelves of them in worn, bursting binders. Printed or scanned, that's a lot of writing. And I'll bet the procedures are all comprehensive, detailed, and referenced.

CLIA (Clinical Laboratory Improvement Amendments) Sec. 493.1251 describes what procedures contain, beginning with they "must be available to, and followed by, laboratory personnel." It may not be Hemingway, but it needs to be well-written enough to answer common questions under pressure. It needs to be detailed at a glance, readable for content alone. Faced with a spinal fluid at 3 AM, that's pure gold.

Remarkably, many procedures (in my experience) are written by bench techs. Guided by a package insert or manual, techs write down what they do. They write for each other in a common language. It is a unique and important kind of technical writing, often done by people who are not writers.

And it's surprisingly hard to do well, given how well a tech knows the job. (Think of writing a procedure to tie your shoes!) Here's a few tips:

• Use a spare style. Simple sentences and precise words lack personality. That's OK. Content is king.
• Use your own words. Your audience is you and your coworkers. There is no one else to impress.
• Use direct voice. Instead of writing Two drops of control are added write Add two drops of control.
• Use present tense. Instead of writing Results will be called write Results are called.
• Use pictures. Copy and paste diagrams and photographs into a word processor document to save the trouble of describing something visual.
• Use examples. Especially with logical algorithms and calculations, examples are a "dry run" when a tech is working with live data.

If you volunteer, are assigned a project, or become a supervisor you may suddenly be a technical writer of procedures. It's an important skill to learn that benefits coworkers and patients. And who knows? You may even enjoy it.

When a round robin of "What's New" got to me at a recent department head meeting I said, "We're working on a new C. diff algorithm that screens for toxin-producing antigen and not just the toxin." Amid blank stares one manager laughed, "English please!"

Such befuddlement is a good-natured acknowledgement that the lab is a technical, even obtuse, department. And while this example is somewhat artificial – I had only a moment to explain what was new – it has a point. If success depends on peer acceptance, cooperation, and support, then it's crucial that what we do is perceived as valuable work. In other words, our work has to reflect values shared by other departments.

Values are guiding principles that answer the question, "Why did you do that?" As one website puts it, "A values statement reflects the core ideology of an organization, the deeply held values that do not change over time." The more people share values, the more decisions make sense. Ideally, values make choices clear for all employees; likewise, values are inferred from decisions.

Let's suppose, for instance, your hospital has a core value of putting patients and family members first. The above could be told as a story. "A recent patient with C. diff disease spent much of her time here in isolation, making it difficult for friends and family to visit. We're working on fixing that by making sure we can confirm the disease in-house. Some patients may be taken off precautions sooner. This way, the patients and family members will know we are putting them first."

There isn't anything wrong with the first way of stating the news, if quality is a core value. But the second puts it in personal terms that everyone relates to. You're likely to get nods around the room, cooperation of nursing, and support when someone asks about the change. Stories are powerful tools to drive values home. Making it personal makes it everyone's story.

Check out "Meet the Bloggers" for our personal stories. And please share your own.

According to CLIA (Clinical Laboratory Improvement Amendments) Sec. 493.1413(b)(8), the technical consultant is responsible for "evaluating the competency of testing personnel." There are a number of ways to do this: direct observation, review of records, analyzing previously tested samples, and so on. These have to be written procedures (493.1235). But what does this mean?

At first glance, more work! It means retesting samples, extra documentation, and being watched. This insults professionals otherwise trusted to perform lab work. Why do I have to prove I'm able to do the work I'm already doing? I understand and agree with these feelings.

But there is another way to view "competency." If you think of your laboratory as a quality system that defines how test results are produced, many competency checks are already built in. They have to be; it's the way that good bench techs feel confident to report results. Some examples:

• Commercial quality control
• Reflex criteria to repeat testing / perform confirmatory testing
• Calibration verification
• Blind samples i.e. proficiency testing

For example, the question How do you know this glucose result is accurate? is really answerable in most labs. Most lab tests are backed up by hard data. It's how good systems enable quality. Therefore, we can think of quality as rephrasing How do we prove our competence to How do we know these patient results are accurate?

This is a litmus test that each reportable result needs to pass. Ideally, the system should be designed to ensure results are accurate, including some way of knowing they are done correctly. In other words, "competency" should be built into our procedures. That way, assessing competency isn't busy work but an ongoing proof that patients are getting the best care.

The challenge is to check your lab menu for tests that don't have proficiency testing, quality control, a way to review how the test was performed, and so on. You might have a few. And while we may be able to spot-check a tech annually, we need to know that patient results reported throughout the year are accurate.

I've written about bullies in contexts of relational aggression and most recently in terms of what it means to you. Let's consider several examples.

• The Coworker Bully – this individual goes to breaks and lunches before you, volunteers early for the sweet schedule spots, and leaves the hard bench work for you.
• The Nurse Bully – this individual has been at your hospital for many years. Her manner is scornful and offhanded to the laboratory, and the few times you've talked to her she's infuriated you by dismissing a concern, making an unrealistic demand, or hanging up.
• The Doctor Bully – this individual has yelled at you in front of patients. He once was overheard complaining about laboratory quality at a nurse's station.

While the above are not real, they are composites of real observations. What they have in common is an apparent desire to provoke negative reactions in others. Their specific behavior seeks to limit your responses into either a defensive stance, one in which you're forced to take responsibility for their work, or both. These bullies react indifferently to your aggravation and leave you wondering what they say about you and your work when you aren't around.

You may not be special. Remember, bullies have been bullies for years. They get hired and even promoted because their behavior works for them. And when confronted, they can be excellent victims. You're correct to be concerned that others tip-toe around these monsters. In my last blog I offered a few suggestions to help cope, but what can be done about these people?

Well, if a bully is a bully forever, not much. But you can change to break a cycle of abuse. Try this with the coworker above: "I see that you repeatedly take an early break before me, even when I have an earlier shift. From now on, let's work together to decide what time to go to break." By stating the truth, offering a solution, and following up the next morning, you've refused to let the bully control your behavior. It's a first step in changing his.

When I was a kid, every grade seemed to have a bully, often a large boy with thick fists who didn't do well in school. Small for my age, I saw many of them up close. I was told to stand up to bullies -- essentially cowards -- or suck it up. (I got larger friends.)

Schoolyard bullies, it seems, eventually get jobs. According to a recent story, almost 50% of American workers have been bullied or witnessed a coworker being bullied. The Workplace Bullying Institute defines the behavior as:

• Verbal abuse
• Offensive conduct/behaviors (including nonverbal) which are threatening, humiliating or intimidating
• Work interference – sabotage – which prevents work from getting done

That's a broad brush. But the problem is real. Health effects include obsessing about work, skyrocketing blood pressure, "mental health" days off, days off spent listless and exhausted, and feelings of guilt and anxiety. A recent article in the journal Sleep links bullying to insomnia, even for observers. And if you think the recent economic crisis is an excuse for employers to fire their bullies, guess again, according to a recent survey.

So, it seems my parents and teachers were correct: bullies are everywhere. Chances are, you have a few at work. And while you may have been told to suck it up as a kid, you're an adult. Here's a few suggestions:

• If possible, confront the bully in a professional manner. Stay calm and do not threaten. A bully will want you to lose control.
• Do your job and do it well. Remember, a bully wants you to fail.
• Make sure your superiors are aware of your work.
• Don't try to win others to your side. Your actions will speak louder.
• Don't allow the bully to isolate you from workplace friends.

Easy to say. It's one thing to read "don't be intimidated" and quite another to face subtle torture day in and day out. Be honest about what is happening and don't allow the bully to control your actions. When all else fails, consult your Human Resources department.

Along with "Aha!" moments – those insights that punctuate hard work – you've probably heard the idea to "think outside the box." It means to think from an unconventional or different perspective, assumed to be essential in creativity. It's a cliché these days.

I'll tell a story. Twenty years ago I worked in a laboratory facing a budget crunch. Our manager held an emergency meeting and explained our situation in grim terms. Unspoken was the elephant that payroll is easiest to cut. Instead of rallying morale with a creative vision, he told us to save money. Over the next few weeks many of us tried to invent ways to reduce costs and became frustrated. Eventually, the budget crisis passed.

This story has two lessons. One, although we knew that we needed to "think outside the box," it was impossible. We came up with lame ideas like cutting applicator sticks in half. Two, our manager simply wanted us to do more with less; we needed a tangible goal. Both inhibited creativity.

If you're on the bench in a similar bind, try this:

• Be positive. It sounds corny, but positive thinking is a great morale boost. This doesn't mean you need to like everything, but seeing a negative situation as an opportunity ("what can we do that's new?") can help.
• Be supportive. Management is not alone. If a manager asks for help, take it seriously and ask questions to make sure you understand what's needed ("what do we want to gain?").
• Be bold. If there's one thing "the box" is, it's constrictive. Once you make sure you know the issues, don't be afraid to make suggestions ("what if we tried this?"). One idea leads to another, and another.

If you think of "the box" as where you are now, "outside" is where you want to be. This may be more efficiency, happier customers, or a greater market share. To think "outside," you have to know where that is and what it looks like. After all, it's where you want to do your thinking from now on.

One of the catch-phrases at seminars is The take home message is…

Giving your audience a pithy "take home" message is good public speaking. It can be a memorable way to summarize an idea, merge ideas with action, or put a complex idea in terms everyone remembers after the seminar. The take home message is the punctuation at the end of the speaker's communication. Example: no magic bullet.

But does it change thinking?

The "Aha!" moment does that. This happens when material is presented in a way that suddenly makes a new idea obvious. Recently, for example, I attended an all-day customer service training session that in part reviewed survey data. Two answers to a question about recommending the hospital to family and friends were Probably Yes and Definitely Yes. Suddenly, I understood those answers in personal terms: Would I go back to see Doctor X? is quite different than Would I send my child to see Doctor X? My standards for loved ones are much higher.

Aha! As service providers we want the answer to be Definitely Yes, because then our service meets that higher standard. For me, that was the valuable message of the day, my "Aha!" moment.

An article in The New York Times suggests that "Aha!" moments are not sudden bursts of light in our consciousness but "a slow process of accretion." We often focus on the magic bullet of insight without realizing it was made possible by hard work over time. And so I realized the above thanks to all the recent training in customer service.

This doesn't only happen at seminars. It happens on the bench, too, when years of work and study "suddenly" lets you connect the dots in performing tests and you understand how to relate results to each other, what the doctor is looking for, or how it impacts the patient. "Aha!" moments may be rare, but they are the real take home message.

Most of us aren't mathematicians. Well, I'm not. I've known people who are just better at "seeing" math than myself. I've always struggled to add a column of figures in my head, forget solving Fermat's Last Theorem.

Which has been solved already. Just as well.

Even so, some formulas are burned into my layman's brain from repetition. Creatinine clearance, expressed as mL/min cleared and often corrected for body surface area, compares the level of creatinine in the urine with the level in the blood to estimate the filtration rate of the kidneys. Many years ago I memorized:

U*V
P

Where U is the urine creatinine, V is the volume divided by the number of minutes in the collection period (usually a day or 1440), and P is the plasma (serum) creatinine. "UV over P" was doubtless memorized by most if not all techs of my generation.

I wonder if this is still true. These days, chemistry analyzers and information systems perform this standby calculation, including a variety of ways to estimate the patient's body surface area. Easy access to this technology – even on handheld devices – makes "UV over P" less essential, even problematic.

Creatinine clearance depends on an accurate 24-hour (or other timed) collection, something which the laboratory has no way of verifying. Like so many laboratory tests, the preanalytical variables can be significant, and patient compliance is a big one. Your laboratory may have decided to report an estimated GFR calculation based on the serum creatinine as suggested by the National Kidney Disease Education Program.

If you look at these equations, they are not "UV over P" and are unlikely to be memorized. Indeed, they are impossible to report routinely in your laboratory without the help of an information system. And as I wrote in ADVANCE, it can be done.

Most of us aren't programmers, either. I suppose I should be happy that computers are memorizing these new equations instead of me.

In writing a procedure, I strive to make it the reference on the bench. Yet no matter how good a written procedure is, the package insert is always invaluable.

There are two reasons for this. One, the package insert is the main reference for any procedure and should be consulted to resolve questions. This can be useful if information changes, for example. Two, there are details in the package insert that may not be included in a stepwise procedure meant to standardize performance on the bench.

I'll use a urine pregnancy test package insert as an example. A common question is, "How soon after conception is the test positive?" Unless explicitly stated in a procedure, the package insert becomes the reference. Under "Limitations" there are the following statements:

• Very low levels of hCG (less than 50 mIU/mL) are present in urine specimen shortly after implantation…
• A number of conditions other than pregnancy… cause elevated levels of hCG…
• The test provides a presumptive diagnosis for pregnancy.

"Sensitivity and Specificity" claims the test will detect as little as 25 mIU/mL in urine, but "Expected Values" reminds us that the amount of hCG will vary with gestational age and between individuals.

Other details include storage and stability of the specimen, collection technique, presence of particulate matter, the condition of the reagents, and cross reactivity of substances or chemicals in the urine. What seems like a simple question quickly becomes complicated. The real question is, is there an answer?

While package inserts are invaluable for details, they may not answer simple questions well. This is where a stepwise procedure can help. A statement such as "Repeat in 48 hours on a first morning void to confirm equivocal or weak positive tests" can help. Package inserts often remind us that a single laboratory test result is only one piece of the puzzle.