"Invisible Idiot" Climbing Route

“Out of sight, out of mind.”

Ever heard the one about the early translation program that converted this aphorism into Chinese and then back? It came out as “invisible idiot.” Regardless, “out of sight, out of mind” is a good general psychological principle. In any nuclear power plant control station, air traffic control center, AWACS plane, aircraft cockpit, or any busy and confusing medical setting whether inpatient, outpatient or ED , people need to know what’s going on. It’s called situational awareness, and it is key to avoiding human error. And we need to keep unimportant stuff out of sight, and out of mind, so people can concentrate on what’s important.

But to keep nuclear reactor coolant pumps, aircraft, or patients in people’s minds, we put something in front of them. Even if it’s just a tiny blinking light, a text summary. or an icon of an airplane. That is why there are tracking systems, to which many of the essays on this site are devoted.

However, the principle applies in other settings, including medical charting.

I dictate many of my charts using a system from Nuance/Dictaphone called Enterprise Workstation. Indeed,  in the ED, all of our physician charts, even those of rotating interns, have been done on this system for several years. (We’ve actually used speech recognition for all our charts for over ten years, using some predecessor systems.) It has been fairly succesful by many measures.

There are a few problems with it, including a klunky interface and the total lack of user interface upgrades for years, but one problem in particular stands out: chart completion. We have to have people tracking our charts. They are always emailing us about charts that we have

1. forgotten to do, or
2. left in self-edit mode (not yet signed), or
3. there is an unsigned resident note (sometimes an attending physician will tell a resident not to dictate a chart as the attending has done a complete chart, but the resident goes ahead and dictates a note and the attending doesn’t know it exists).

We could save $$$ and lots of people’s time if only chart status was apparent to our docs and midlevels. The system should make charts visible, so we may form a mental model of our chart status:

• Do I have charts left over from previous shifts to complete?
• Which patients belong to me this shift?
• Which charts have been completed by a resident?
• Which charts have been completed by me?

Any charting system needs a tracking system, not for patients, but for tracking charts. Such a tracking system might look like this:

EWS Interface Suggestion

Here is the explanation, which I sent to Dictaphone in June 2009:

Please look at the attached picture (just a rough sketch in Adobe Illustrator, sorry if it’s a bit crude). 

For charts you’ve “claimed” the triangles turn to squares.

This is from an attending’s view, things would look different for a resident, CRNP or PA.

The intern has started a note on Abel Baker but is not currently editing it.  

The intern has finished a note on Charlie Delta and the R3 has started work on it.  

The intern AND the R3 have finished their work on Ecco Fox’s note, and you’ve claimed it and have started editing (adding your attending note).- in fact, you only see this for a second after you’ve double- clicked on the line before the actual note pops up in front of you.  

Some other attending has started a note on Greg Hoatl.

A midlevel of some sort (CRNP, R2 or R3 – I grouped them for simplicity) has finished a note on Juliet India, but no attending has claimed it yet.

You’ve started a note on Lee Keel but are not editing it right now.

The intern is editing Mike Novimbur’s note right now.

You and the intern are both seeing Oscar Pah; you’ve edited your attending note a bit, and the intern is currently editing.  

You can click on any of the icons to edit a chart. If the chart is already open, you will be presented with an option to Cancel or to create a new chart. (If there are two charts for a particular patient, that line will double and it will have two rows of icons to indicate the two charts.)

The essential part of this is to make the relevant aspects of your list of charts visible, with nothing else cluttering the screen: “invisible idiot”.

Invisible Idiot

Trying to find my way from the entrance of my 12 year old daughter’s bedroom to the bed to kiss her goodnight, especially if barefoot, is considerably more dangerous than most of the search and rescue and disaster operations I’ve been on.

Navigating the screens of medical software often seems like walking in my daughter’s room with the lights out, blindfolded, backwards. I’m sure you can find examples in many medical software applications, and there are many causes for such problems.

But one of the most important is consistency, or rather lack of it.

I know of one EMR application, DocuTAP, where clicking on things is inconsistent. Sometimes you have to click on something that looks like a button. Sometimes you have to click on a word (and, inconsistent with the standard for web pages, it is neither blue nor underlined, even when you hover the mouse over it). Sometimes you have to click on a checkbox.

Sometimes, clicking on a word does nothing, because you have to click the checkbox next to it.

Sometimes, in a configuration screen, you can click on a checkbox, and a checkmark appears, but this has absolutely no effect on anything.

Sometimes, you have to click on a line of text in a listbox and then click on a button below the listbox.

Sometimes, clicking on a word initiates some action.

Sometimes, clicking on a word selects it.

Sometimes, left-clicking on a word results in a popup box, with the word “remove” which when clicked removes the word from a list.

Sometimes, you have to right-click to get a context menu to pop up.

Sometimes, you have to click on a word or sentence to select it, then look around and click on the red X at the upper right corner to remove the item. The red X is not a button. It is not blue. It is not underlined. There is nothing that tells you it’s clickable. It has no affordance. Once you’ve figured out to click the red X, it’s easy to remember, so it’s memorable, but it’s certainly not easily learnable.

Once, I was totally stymied on how to sign the PA’s electronic charts; I had clicked on the chart’s listings in a listbox and reviewed each. But how to “sign?” Looking around the list of charts, I saw nothing. Someone finally pointed out to me that, at the very bottom of the screen, far, far away from the couple of charts at the top of the listbox, was a button that said “Sign.” Duh.

But I’m not the only one who had this self-same problem. Many others did.  Placing a button far away from the foveal vision range of the items on which it is to operate is not, apparently, a good idea.  This seems like a good candidate for being detected during discount usability testing, which makes me think that no usability testing, discount or retail, was aimed at this particular screen.

Let me also pick on another medical product that I use: Cerner FirstNet. When doing discharge instructions, and you want to remove something you’ve added, sometimes you right-click and from the context menu select “remove”, other times you have to highlight the entry and then click a big red X (which, again, doesn’t have any clickability or “affordance” to indicate it’s clickable). Seems as though (1) big red Xs are trendy, and (2) most medical software designers don’t know from “affordance”.

In Mental Models, Input Modes and Cognitive Friction, I wrote about how distracting and slowing it is when you have to change input modes, for instance, changing from using the mouse to using the keyboard and back to the mouse. The same applies for “mental input modes”: left-clicking, right-clicking, clicking on a button, clicking on a big red X, or clicking on a checkbox. Changing from one mental input mode to another distracts us from the mental task at hand, slows us down, and makes us more likely to make an error.

If you coded a program, leaving the interface like a messy room might be OK for you: you know where everything is. If you know every little corner of the code and where everything is, that’s fine, but it doesn’t mean that users of your code should have to know each idiosyncratic corner where you’ve hidden things.

Want usability? Clean up your room.

In a one-conceptual-layer app, you click on a word to instantiate it. For example, if charting about someone’s tonsils, and you click on the word

Tonsillar Exudate

then that means that there is exudate on the tonsils. Conceptually, it’s a one-step process; there is only one layer of cognition needed to check items on the page. You click on the word to validate it. If you click on Tonsillar Exudate, there are tonsillar exudates.

In a two-conceptual layer app, you might have to click on a checkbox next to the word. For example, you might see:

 A   N
[ ] [ ] Tonsillar Exudate

You have to check the box for A (Abnormal) or the box for N (Normal). This requires a two-step, or two-layer, mental process. First, you have to find the term Tonsillar Exudate. Then you have to think” “What does ‘Normal’ mean in the context of Tonsillar Exudate? That means no Tonsillar Exudate. So I need to check ‘A’ for Abnormal since there is Tonsillar Exudate.”

I suppose you can argue that this is more than two steps, and likely you’re right. But for the purposes of simplifying the argument, I picked “one-layer” and “two-layer” even if the “two-layer” strategy may actually require several layers of cognition.

From an ease of use perspective, from an efficiency perspective, and from an error-prevention perspective, a one-layer charting system is quite superior to a two-layer charting system.

An example of a highly-successful mostly one-layer process is the T-system, available in both paper and electronic versions. The T-system offers two options for each item. First, on paper, if you circle Tonsillar Exudate or, on the computer, left-click  Tonsillar Exudate, that means it’s true. So, check next to, circle or click on Tonsillar Exudate, and this means that the patient does have tonsillar exudates. Second, if you draw a backslash through Tonsillar Exudate that means there is no tonsillar exudate.

An example of a successful two-layer process is DocuTAP.

If you’re looking at point-and-click charting applications, you may want to look carefully at whether charting is a one-layer or two-layer process. All other things being equal (and they’re usually not!) a one-layer process will be more efficient for your practitioners, cause less error, and make them happier.

And if you are a charting vendor with a two-step process, you should consider a revision to make it a one-step process. Even if your charting system is good, making it a one-layer system would likely improve it.

For point-and-click medical charting systems, simpler is better, at least in terms of the number of cognitive processing layers.

CHECK VITAL SIGNS
DISCONTINUE IV THERAPY
EKG
ORTHOSTATIC BP, PULSE
SET UP FOR PELVIC EXAM
AEROSOL TREATMENT, ADDITIONAL

WERE (whoops, sorry, need to hit the CapsLock key) were in Mixed Case, it would have been much easier to find.

As a standard part of netiquette, one is NOT SUPPOSED TO SHOUT. So simply from a viewpoint of politeness, this list should be in mixed case. Coders: don’t make your computer program SHOUT AT THE USERS ALL THE TIME. And, we have known since 1914 that ALL CAPS is harder to read than Mixed Case.

There are rules of typography, most succinctly and eruditely expressed in Bringhurst’s The Elements of Typographic Style.

Most of these rules are designed to make type easier and more pleasurable to read.

Modern typography sometimes uses

A L L   C A P S 

for certain artistic purposes, particularly in headings. But it’s usually used with extra letter-spacing, and extra white space above and below, to allow readability. This is most emphatically not the case in the DocuTAP list.  Lest I seem to be singling out DocuTAP (which also violates other rules of typography by sometimes having three different sans-serif typefaces on a single page), let me say that many medical programs have  typography that is even worse.

The book The Ten Commandments of Typography/Type Heresy says about allcaps that “THE TEXT MAY MAKE MORE OF A DEMAND ON THE READER BUT WHAT THE HELL IS WRONG WITH THAT?”

This is OK if you’re creating something that is designed to make demands on the reader, like a website or poster for the Holocaust museum.

It is most emphatically not OK if you’re coding a program that I have to use over and over again, when I’m very busy, and often distracted by lots of interruptions.

Want to make an improvement in usability without altering a line of actual code? Change your ALLCAPS to MixedCase.

Knowledge is knowing the rules.

Understanding is knowing how to break the rules.

Wisdom is knowing WHEN (and when not) to break the rules.

What’s in a word? That which we call a rose
By any other name would smell as sweet.
Romeo and Juliet (II, ii, 1-2)

OK, I cheated. I changed “name” to “word.” It sounded better for the purposes of this essay, which is about the need to choose words carefully. Yes, I changed a word of The Bard’s, and for the worse. So sue me. It makes the point.

This blog is about the usability of medical software. So I am going to offer a real-life example where the choice of a single word can have a major effect on usability.

I have discussed this idea that “one word changes everything” before. If you have read the series on Medical Computing, you will remember that the second essay was on Tognazinni’s Paradox, where usability testing showed that changing a single word on the screen made a massive difference in the usability of Apple’s introduction to the Apple II computer.

User Mental Models vs. Implementation Models

I have also discussed the idea that usable programs present a simple and coherent mental model that match the users’ expectations. Poorly-usable programs often have an interface based on an implementation model that reflects the underlying code. Instead of an interface that reflects the underlying modules of code, coders need to overlay their module structure (and likely spaghetti-like code) with the illusion of a simple, easy-to-understand machine. This is not a trivial task.

Here is an example, from a medical charting program I use. It illustrates both of these points.

I was using DocuTAP, a system for urgent care charting. I had been using it parttime for almost a year, so was fairly familiar with it. When first trained on it (an hour or so of overview), I was told that you could draw diagrams, but it looked so klunky I never tried it. But yesterday, I saw a patient with a very broad (though superficial) corneal abrasion, and thought I would try to diagram it on the chart.

Of course I had no clue about how to do this; I’m not even sure I would have remembered a week after that one-hour training. So I started inspecting the main DocuTAP screen. It’s pretty crowded.

Aha! I saw the word “Images” near the top. I see “Images” and I think Google Image Search, Picasa, or maybe sketch diagrams of an eye on which I can draw.

I clicked on “Images.” Wrong, wrong, wrong. It wasn’t the diagram-charting module, it was something else. OK, what else can I click on that looks as though it would let me draw a diagram of a corneal abrasion?

I spent maybe five minutes looking and finally gave up. I asked one of the PAs. She immediately pointed to an icon of a pushpin. I said “That’s how I chart a diagram? What has a pushpin got to do with drawing a diagram?” I finally figured out that it maybe means that you draw a diagram and then use a pushpin to attach it to the chart. Well, if this is by analogy to what we used to do with paper charts, I guess it should be a staple or a paper clip, but still, I’m not sure if I would figure that out without help. Maybe it’s just me being stupid. But I think many others would be just as “stupid.”

Sometimes people (usually quite-intelligent people) say they are having problems with a computer program because they simply aren’t “computer literate.” I tell them it’s because the coder didn’t make the program “human-literate.”

But let me go back to the main point: that word I clicked on before: “Images.” It showed me images of scanned documents that had been attached to the chart. I’d been wondering for months how to find those! I actually had thought that ”Images” was to take a picture with a digital camera and upload it to the chart. (Not a bad idea, that.)

To a coder, scanned documents are images. The might be bloated TIFF files, they might be PNG files, but most likely they’re JPG files embedded in an Adobe Acrobat PDF file. But they’re images.

But to someone working on a medical chart, they’re not “images.” To medical charting users, scanned documents are just that, documents. When I’m thinking about medical charting as a coder, those scanned documents are images. But when I’m thinking about medical charting as a user, I don’t think of them as images, I think of them as “Scans” or maybe “Scanned Documents” or maybe “Attachments.” (Though that last is getting a bit coder-ish.)

I think DocuTAP could make their program a lot more user-friendly by just changing that one word “Images.” It would be interesting to do some discount usability testing and figure out how many people can find the attached scanned document images when the link is “Images” and how many can find it when the link is “Scanned Documents.”

(Let me say that I’m picking on DocuTAP only as an example because I have used it regularly. While it could do with a usability makeover, it’s actually better than many of its competitors.)

Bruce Tognazinni was right. Changing one word can make a world of difference.

I know you’ve been waiting for it. OK. Here’s the quote with the right word:

What’s in a name? That which we call a rose
By any other name would smell as sweet.

I’m talking about active cognitive ignoring.

This occurred to me as I’ve been using an electronic medical record system called DocuTAP. It has many very, very busy screens, each with a hundred or so items from which to choose.

But I and other have learned to use it relatively quickly and efficiently. It’s hard, and it takes a lot of concentration and time, but we’ve done it.

Quoting from the website: “The DocuTAP system is extremely user-friendly and easy to learn. We can typically teach a new staff member how to use the system in less than two hours.” –Greg Troyer Owner. Yes, but how long does it take to learn to use it efficiently and effectively? I probably shouldn’t be picking on DocuTAP, as it’s no worse than many other point-and-click charting solutions, and at least you can learn to use it fairly efficiently, which is not true of a fair number of its competitors, so I’d rate it better-than-average.

How did we learn to use it “fairly efficiently?”

We learned to ignore. We ignore most of what’s on the page, the vast majority of which we never use. We focus our attention, our foveal vision, and even our mouse cursors on the place where we have learned to focus, to the exclusion of everything else on the page.  Our eyes and mousing hands (and brains) have learned where the commonly-used items are. In fact – due to slow performance – I often find my mouse cursor hovering over a particular place on a blank screen, waiting for the screen to refresh and allow me to click the link that should be right here.

There is a lesson in this. Learning to ignore things is hard work. Cognitive work. The more we have to ignore, the higher the cognitive friction. The more choices on a screen, the more we have to learn to ignore.

DocuTAP

So, cutting down on the number of choices on a screen improves learnability and memorability.This seems obvious, but if it really is obvious, why do the screens of most medical software have such a bewilderingly-massive number of choices on each screen?

If you have a single listbox with many choices, for example, the standard x-rays you may order, that’s not too bad, as long as they’re organized in a quickly-comprehensible way. It’s when you have five or six different boxes on the page, each containing a different type of option, and each with a long list of items, that things get really confusing, and the friction slows cognition to a crawl.

The infrequently-used choices on the screen should be grouped and then hidden behind a single item. A simple way to do this is to offer a few of the most common choices and then a link or button with More…

The concepts of information hiding and encapsulation are well-established in computer programming, but somehow many programmers have difficulty applying it to their user interfaces.

The lesson in this essay and other essays here applies whether you’re designing medical software; or, critiquing it, perhaps with an eye to buying it. This is another way to actually quantify (or at least qualify) user-friendly.

The bottom line? Ignoring is hard work. Ignore this at your peril.

Combine this with Alan Cooper’s dictum, from the first edition of About Face: The Essentials of User Interface Design: “A dialog box is another room. Have a good reason to go there.”

We get another heuristic (rule of thumb) for usability: “The more pages or dialog boxes a user has to traverse to accomplish a task, the less likely they are to remember what they were thinking at the beginning.”

In settings where distractions are rife, this effect is more likely to result in error, as you don’t have the cueing of the original screen to remind you where you were. The high degree of interruptions in the Emergency Department is a classic example.

Therefore, for applications for such environments should use techniques such as breadcrumb trails.

Again, duh. But the point is that the transition from page to page, or page to dialog box, is the transition where most of the forgetting occurs.

It’s not just you.

And  if all those corporate executives who are responsible for our medical software were to get one particular concept into their brains, all of us in the medical field would find our lives a lot easier and error-free.

Cognitive friction is that term, coined by Alan Cooper in The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity.

It’s quite simple. If you make a process cognitively easy, we do it rapidly and without error. If you make it cognitively hard, it takes us longer and we make mistakes.

And we know how to make things cognitively easier – how to lubricate software to reduce cognitive friction. At least, the information is out there, no matter that most medical software vendors are blissfully unaware of it.

There are many, many things that contribute to cognitive friction. In the essay on Color, we learned how color can be used to guide us through a series of computer screens by directing us to the most likely thing that we should click.

In Mental Models, Input Modes and Cognitive Friction we learned about central (foveal) vision, which subtends only a six-degree field of view. We learned that our subjective impression that we can see an entire computer screen is a total illusion, and that we have to (unconsciously) scan computer screens to find things on them.

Preattentive Attributes from Few

Unless, that is, the things on the computer screen are tagged with characteristics that are preattentively recognized – characteristics such as shown in the first and second diagrams in Performance, Data Pixels, Location, and Preattentive Attributes.

We learned that switching modes – moving from mouse to keyboard – increases cognitive friction.

We also learned that computer response time is important – if the computer makes you wait for more than a second, at any time, then your attention wanders, which of course is not just cognitive friction, it’s more of a cognitive full-stop.

More Preattentive Attributes from Few

But here, I wish to concentrate on the big-menu effect. When you’re going out for dinner, it’s easier and faster to make a choice from a one-page menu than from a six-page menu. Unless you’ve been there many times before, and know exactly what you want and where to find it on the menu - which is the same way we finally manage to work around poorly-usable medical computer systems with experience and regular practice.

Too much information – too many choices – can paralyze. Trying to find the right choice from fifty alternatives is more than ten times more difficult than choosing from three alternatives. This is true whether it’s on a menu, in medical decision-making, as reported in Donald Redelmeier and Eldar Shafr’s 1995 study, or a cluttered computer screen.

finding the numbers can be hard

My favorite example of this is from one of the books my daughter had when she was just a bit beyond being a toddler, which was chock-full of visual puzzles. If you’re developing your cognitive abilities as a toddler, such a page can focus your attention and provide an engaging exercise for an hour or so. However, the many medical computer screen pages that mimic this puzzle page are less suitable for rapid, effective use by busy, distracted, and sleep-deprived medical professionals.

So what is the solution? Follow the advice of Strunk and White: “Avoid needless words.” And follow that up, for the computer screen, following the precepts of Edward Tufte and Neilsen and Tahir, with “Avoid needless pixels.”

This is easy to say, but if you’re a computer coder or designer, not that easy to do. The main requirements for low cognitive friction are to design the program, ideally using the persona approach, looking at the work process of the most common users (doctors, nurses, secretaries, respirator therapists, x-ray technician, and the like) and designing screens to closely map their work processes. And, for each of these users, the program must allow users to create a mental model of what the software does; users must never be “lost” in the program.

Here is my summary on how to grease computer screens to minimize cognitive friction.

Triadic Colors

1. Limit the Choices:If a screen has 50 different clickable links or buttons to choose from, redesign to hide most of them behind a top-level choice.
2. No Corporate Logos: If you have to put a corporate logo on a computer screen or you will get fired, do your best to (1) make it smaller, and (2) make it low-contrast and use dull, unsaturated colors. If you have a choice, put it at the bottom right, where it is less likely to attract attention. As far as the user is concerned, these are totally useless pixels, about as helpful as one of those new LED billboards right across from your bedroom window.
3. Group Related Items: if there are bits of information on a screen that need to be seen together to make sense, make sure that they are within the 6-degree view of foveal vision. A classic example is the main elements of a complete blood count: white blood cell count, hemoglobin, hematocrit, and platelet count. These items, plus the patient name and date and time should all be within foveal vision range.
4. Guide with Color: Color can guide users through screens, just like hospitals used to have colored lines on the floor that led to different parts of the hospital (Why did they get rid of those? They were a brilliant idea, just like the London Underground Map but in real life!) Complementary color highlighting of the most commonly clicked items on a page help users mentally automate common processes. If you have to have different types of users using the same screen but frequently choosing different options, consider a triadic color scheme, with a background color and then two other colors, one for each type of user. (A tetradic color scheme, with background and three colors, is stretching it a bit.)
5. Keep User Attention From Wandering:Keep response rates well under a second. Any common computer task that has any delay more than 3/4 of a second anywhere in the process is simply unacceptable and will lead to error. Hardware is cheap, throw enough hardware at the system to keep it responsive.

   

   Tetradic Color

6. Use Preattentive Features: We all hate flashing website ads, because flashing is a preattentive attribute we simply cannot ignore (if it gets through AdBlock, I hold my hand over the offending area of the screen). Use flashing only to indicated something truly catastrophic, perhaps your “incoming missile alert.” But subtle highlighting with less-obvious preattentive attributes, especially on information-dense tracking displays, can improve the usability of these displays by many magnitudes. For example, with rare exceptions, every clickable item needs to be in blue and underlined, or look like a button.

There are other rules for good design – some of which are covered in other posts on this website – but the six rules above are the major ones apparent to me, at least at this particular instant. If you’d vote for another principle to be given such high-level status, please post a comment.

This isn’t feasible for most real-life physician medical charting. We do have to use our charts for billing, and for protection against lawsuits. (“If you didn’t chart it, it wasn’t done.”)

We also are sometimes faced with the demand for charting so that, instead of a narrative string of ASCII text, our charts are a small database of discrete, labeled elements (e.g., Chief Complaint: chest pain. Duration: 1 day.) This latter is known as structured charting, and is eagerly promoted by researchers, who want structured data, and billing companies, who enjoy the resulting ease of assuring compliance with billing and coding rules.

Some template systems are easy and fast for physicians to use, such as the famed and very-profitable paper T-sheets from T-system (there are also many reputable competitors). They are also great for billing, but hard to defend in court. They are easy enough to use that, if you’re using them, you really don’t need scribes. There are electronic versions of the T-sheets and competitors, and on a tablet such as an iPad, they are very attractive – but still not as easy as paper templates.

T-sheets and the like are, in a sense, structured charting, but the data elements are hard to capture from a scanned chart, so researchers and those involved in QI activities aren’t as enamored of them. They want electronic structured data. So the rest of this post will be devoted to electronic structured charting.

If you’re dictating into a phone, dictating takes quite a while, and I know places that use such dictation who are thinking about scribes. But instead of having the scribes dictate into a phone, the scribes would use an electronic structured charting application to complete the chart. There also are places that use speech-recognition for charting – in fact I’ve been doing ED charting via speech-recognition for over ten years – which has advantages over dictating into a telephone. For example, you can dictate the History of Present Illness (HPI) on each patient right after you see them, even if you’re pretty busy. Later, when you have a chance to complete the chart, you can see that HPI that you dictated, which really helps you remember the patient and do a more accurate chart.  However, this produces a string of ASCII text rather than electronic structured data.

I’ve tried using point-and-click charting, with speech-recognition to fill in the HPI and medical decision-making sections. Switching modes from point-and-click back and forth to dictation is awkward and slowed me down. It seemed a lot slower than simply using speech-recognition to do the whole chart.

There are other advantages to electronic structured charting; it’s easy to put in reminders to chart important things (e.g., neck and fontanelle exams for kids with fever). Electronic charting systems may also be integrated with computer-based practitioner order entry (CPOE) and other systems, allowing interaction checking between existing medications and prescribed or ordered medications (which has its own set of pros and cons to discuss), and providing easy look-up of appropriate reference information. Electronic structured charting (at least if you do a good job of haggling with the vendor before signing the contract) is a lot cheaper than traditional dictation-into-a-telephone. Which, by the way, uses speech-recognition as a front-end; rather than true transcriptionists, the people who review the output of the first-stage speech-recognition are better termed correctionists.

But, as many emergency physician informatics doyens such as Todd Taylor and Rick Bukata maintain, using a highly-paid physician to to a data-entry clerk’s job just doesn’t make economic sense. Except that electronic structured charting  (Unless you’re a hospital administrator and you don’t care about the impact on the pay and satisfaction of your emergency physicians to cut your bottom line for transcription costs.) But the pressure from researchers, coders and administrators is hard to resist.

Thus, scribes.

Scribes are now well-established in many community EDs, and used in a few academic settings. Community EDs tend to contract with a company that trains, vets and provides scribes, whereas academic EDs, which tend to be in college towns, generally set up their own program to train and vet scribes.

The Emergency Medicine Practice Committee of the American College of Emergency Physicians has prepared a detailed white paper on the subject of scribes that provides much more information about scribe programs. But I hope that the above adds somewhat, though perhaps a bit opinionated, to what the white paper provides.

There are a variety of suggestions for why this is so, and what to do about it.

With the system I use, it seems to me that there are two main sources of the error. Orders are usually entered by right-clicking the patient on the spreadsheet-metaphor tracking system, and then entering orders. However, even though you think you’re right-clicking the patient, in the split-second after your brain sends the message to your finger to right-click, a new patient is entered or deleted by someone else, and you actually click on the patient above or below your intended patient.

For the second cause of wrong-patient order entry, I have to explain the tracking system we use. There is the main spreadsheet window, which is usually maximized onscreen. Then there is a large popup window with other information; a great variety of chunks of information populate this popup window, including old records, a list of orders that have been entered, and even the order-entry screen. It’s possible to have one patient selected on the spreadsheet, and a different patient in the popup window. That is the second major cause of wrong-patient entry.

Regardless of the source of error, however, using the Swiss cheese error-prevention analogy (see the post on Color) we need a method to catch such errors (a second piece of Swiss cheese).

There are many suggestions for how to prevent such errors in the informatics literature. One suggestion is that we put a picture of the patient on the screen when one is ordering. This is used, for example, by the CPOE system used by the US Veteran’s Administration. However, for someone who has just met the patient for the first time, this may not be particularly useful. Actually, those in the ED tend to identify patients more by location and chief complaint: “the chest pain in room 5″ and perhaps having these two things prominently shown would work better for ED systems.

It’s also true that we can only see a narrow field of “foveal vision” as described in the post on Mental Models, Input Modes and Cognitive Friction. So whatever we put on a screen as an error-prevention label (picture, “chest pain/Rm 5″ or whatever) is within that six-degree field of view. Even if it’s within the realm of foveal vision, it may still be ignored, as was the gorilla that strolled through the ball-players in a famous psychology experiment: when we are tightly-focused on a task, we can ignore almost anything. In such experiments, some people even looked right at the gorilla (as seen by eye-movement tracking) but didn’t “see” it as they were so narrowly focused. There was one experiment reported at the Informatics Section meeting where placing the patient name in bold helped prevent the “wrong patient” errors, I would suspect that having the name (or “chest pain/rm5,” or a picture) closer to the task at hand would help.

I look forward to the results of more research into this issue, and will post new information here when I receive it.