But now that CMS has said

“Our ED physicians “Assign” themselves to patients using the tracking board function of EHR. Does documentation of the date/time “assigned” qualify as Provider Contact Date/Time? Otherwise, the earliest documentation of contact with the patient would typically be the first order or the first LIP progress note. Are those acceptable forms of documentation for these data elements?”

“No, this would not be sufficient documentation of provider contact. You would need to use documentation that supports the time of the first direct, personal exchange between an ambulatory patient and a physician or institutionally credentialed provider to initiate the medical screening examination.”

–Quality Insights of Pennsylvania

I predict three things:

(1) ED directors will try to persuade docs to only put their name on the patient at the instant they actually see the patient,

(2) this will be a miserable failure that fails to generate accurate data and causes much friction, and that

(3) passive tracking (using RFID smart badges that track when you enter a room) will suddenly be of great interest to many EDs. May be a good time to invest in these products.

Back in 1988, Ray Kurzweil came out with speech-recognition software, including something called VoiceEM. It was an emergency medicine physician charting application; there was also VoiceRAD for radiology. These were DOS programs that ran with that typical DOS 80 character x 25 character text screen. In addition to having a medical-specific vocabulary, VoiceEM had another advantage over the retail shrink-wrap Kurzweil Voice: you could access your voice profile (what the program learned about your particular voice, and the new words you had taught it) from any PC on the network. And, as it learned more about your voice, and as you taught it more words, these were saved back to the server, so you could access this updated “profile” from the network when you started up at the beginning of the next shift. VoiceEM alsom allowed electronic signature, saving your charts on the server and sending them through an interface to an electronic medical record (EMR) system.

VoiceEM employed a speech recognition engine developed by Kurzweil and his engineers. It was advanced for the time but crude by today’s standards. It only recognized

one

word

at

a

time.

The recognizer wasn’t all that good, but if you gave it a choice of just a few words, it could figure out pretty easily what you said. It was even quite good at discriminating between fifty or a hundred words.

To leverage this, Kurzweil added Applied Intelligence. (Applied Intelligence is Artificial Intelligence, only with more engineering and less hype.) They analyzed ED charts, and created templates for the most common presentations.

Let’s take, example, a “chest pain” template. (I’m grossly oversimplifying so it has only a passing acquaintance with the real template, which appears in the screenshot of VoiceEM’s successor Clinical Reporter, but bear with me, it’ll work for an illustration.)

The template looked like a regular ED note on screen, only with fill-ins (blanks) that could be filled in by voice. When you tabbed to a fill-in, a list of potential choices appropriate to that fill-in would appear along the right side of the screen.

The patient presents with a chief complaint of chest pain. The pain is [ ]. The chest pain started [ ] ago. The location is [ ]. Associated symptoms include [ ]. The pain [ ].

When a fillin was highlighted, you could use your voice to pick from choices, for example

“severe” or “moderate” or “mild”;
“pressure-like” and/or “sharp” and/or “burning” and/or “pleuritic”;
“one” or “two” or “three” etc., and “hours” or “days” or “weeks”;
“left” or “right” or “substernal”;
“shortness of breath” and/or “diaphoresis” and/or “palpitations”;
“radiates to right arm” or “radiates to left arm” or “does not radiate.”

(for some of the fillins, you could only pick one choice, and then the cursor would move to the next fillin; for others, you could pick multiple choices)

Given charting chest pain was pretty simple and standardized, you could just say the following, tabbing to the next “fill-in” (blank with an associated short list of possible answers):

“chest pain” TAB
“severe” TAB
“pressure-like” TAB
“two” “hours” TAB
“left-sided” TAB
“shortness of breath” “diaphoresis” “palpitations” TAB
“does not radiate” TAB

and the like. This then would then generate a chart that looks like this:

The patient presents with a chief complaint of chest pain. The pain is severe. The pain is pressure-like. The chest pain started two hours ago. The location is left-sided. Associated symptoms include shortness of breath, diaphoresis, palpitations. The pain does not radiate.

“Free-Text-Mode” and Continuous Speech Recognition

With Kurzweil VoiceEM, you could even go to “free-text-mode” and dictate

word

by

word.

This “free-text-mode” had the dual disadvantages that it was painfully slow, and, since the recognizer had to choose from a very much larger vocabulary than in the fillins, it was much more prone to misunderstanding you. But for some complex charts, you had to use it. Or type. I think we all typed faster than this original “free-text-mode” so that’s what we did. One of our docs used the Dvorak keyboard layout, and I installed a macro program to switch the keys for him; this way he could type a lot faster.

Even today, working as an ER doc requires typing proficiency. I think that all applicants for our group should have to take a typing proficiency test, and they have to do better than 35 words per minute to be considered. I type about 90 WPM. I credit my mother with this. When in high school, she made me take a typing class. I was outraged, until I realized the advantages of being the only male in the class.

Overall, VoiceEM worked pretty well for simple, straightforward charts. Even for those charts, it was slower than handwriting. But much more legible! I remember when one of my partners was handed one of his own handwritten charts for a QI (quality improvement) review: “What? You expect me to be able to read this?”

Continuous Speech

Later, Kurzweil started working on continuous-speech recognition. About the same time, a group of grad students at Carnegie-Mellon University were working on continuous-speech. Living close to CMU, I got to attend some seminars of the working group. The CMU project got spun off as an independent business, something called Dragon Dictate. Typical grad-student name, don’t you think? Later it became a commercial product.

Both the Kurzweil and Dragon continuous-speech recognition programs were built on a trigram model: each word is evaluated in the context of the word before and the word after. This improved recognition massively compared with Kurzweil’s original word-by-word recognizer. Having a vocabulary based on actual emergency medicine reports allowed fine-tuning of both the vocabulary as well as improving trigram recognition, as Clinical Reporter was preferentially listening for the most commonly-used emergency medicine phrases. There were problems with this model, however; the vocabulary was computer-created from analyzing many, many ED reports without much human oversight. This resulted in a “dirty” vocabulary, with some occasional proper names and misspellings creeping in.

Kurzweil’s technology and business got bought out by a Belgian company called Lernout & Hauspie. So there was an upgrade of VoiceEM called Clinical Reporter. It still had all the templates – in fact, even better templates, and more of them, and they were customizable. It switched from being a DOS program to a Windows program, but otherwise was much the same.

Two words = $$$$$

Customizable templates were important to us. For example, we realized that we were very poor at billing for critical care, which pays better than “regular” care. ER docs do all sorts of things that are billible as critical care (like taking care of bad asthma patients) that are easy for us. It’s billable as critical care, but the care is so routine for us that we forget to chart the language about critical care.

At the bottom of our standard ED provider charting template, we added a reminder:

[Critical Care?<>]

This was a non-printing prompt. If you ignored it, it would disappear when you signed and closed the report. But if you highlighted it and said “Critical Care” then this would appear:

CRITICAL CARE: The aggregate critical care time was [<30>] minutes of direct attention while the patient was in the ED, under my care, addressing the stabilization of multiple systems. My care included the history and physical examination, patient management, patient reassessment, interpretation of diagnostic tests, coordination of care, discussions with family, and decisions regarding patient treatment and disposition.

The month after we added this to our standard template, our critical care billing went up by 13%. Pretty impressive change for adding two words and a question mark! This illustrates one powerful feature of templated charting systems: reminders. (There are disadvantages of templated systems, too; we will review them in a subsequent post.)

Many of my partners complained about the slowness of charting with Clinical Reporter, but the complaints were quite muted (for a few months, at least) after our billing went up so sharply. You could also add in reminders about things like aspirin and nitrates and beta blockers for chest pain/myocardial infarction, which helps with charting compliance. Also, occasionally, with improved patient care as well; you’re charting and suddenly realize you’ve forgotten something and ask the nurse “would you put half an inch of nitropaste on the patient?”

About the same time (late 1990s), several competitors to Kurzweil appeared, and we demo’d a few of them. Many of them had innovative features.  We were looking at them as a potential replacement for Clinical Reporter, because:

Of Mergers and Acquisitions and Criminals

In 2000, Lernout & Hauspie went on a shopping spree. They bought Kurzweil. They bought Dictaphone (who had just bought Articulate Systems and their continuous speech recognition, one of those competitors we were looking at). They bought Dragon, with their successful retail speech recognition product. L&H brought out a highly-effective continuous-speech recognition product, VoiceExpress.  I used this at home; it wasn’t bad. Their stock soared. Any competition (that they hadn’t already bought) withered on the vine.

But the next year, it all fell apart. The principals were sentenced to jail over fictitious sales figures from Korea. The stock tanked. The company went bankrupt. The EDs using Clinical Reporter all followed the news with a kind of horrid fascination.

Nuance Takes Over

Scansoft, the makers of the leading Optical Character Recognition (OCR) program, Omnipage, acquired Lernout & Hauspie’s speech-recognition technologies, and changed their name to Nuance (what a bad name) along the way. They continued to market both retail and medical versions of Dragon. The medical version of Dragon was basically the standard retail package but with a medical vocabulary added and the price multiplied by a factor of 10. They even offered specialty-specific vocabularies, including emergency medicine. However, the Dragon product, unlike VoiceEM and Clinical Reporter, wouldn’t save your voice profiles to the server and allow you to load it from different PCs, nor would it send reports through an interface to your EMR system. (Years later, Nuance finally did start offering a medical version of Dragon with some network management capabilities.)

Nuance killed Clinical Reporter. They abandoned all the Applied Intelligence (templates) that Kurzweil and then the Clinical Reporter team had developed.

Too bad. Many of those templates were quite finely tuned and had a lot of smarts in them. They also abandoned Kurzweil’s work on a real-time program to analyze any text chart and code it for billing, giving advice if the report was close to but not quite up to a coding level. I used a beta version and it worked quite well. The code for this was developed based on a NIST (National Institute for Standards and Technology) grant, so I suppose the code is still available somewhere in the public domain for any enterprising individual to take and develop further.

Nuance took technology acquired from Dictaphone and started marketing a program called PowerScribe.

This inherited nothing from Kurzweil or Clinical Reporter, it was a brand-new and totally different program. PowerScribe had a simple template system (much cruder than the Clinical Reporter templates), but  no predefined templates.  Later, they collected templates from existing users and started providing new users with a few basic templates, but nothing like what Clinical Reporter had. There was no way to tie a particular list of words to a fillin; each fillin was listening using the full vocabulary, and without a list of preferred words, and with the standard trigram model of continuous speech recognition, uttering a single word in a fillin results in frequent misrecognitions. However, Dictaphone, being part of Nuance, got to use the latest and best versions of the Dragon speech-recognition engine (recognizer). However, over the past few years, they’ve been slack in rolling out upgraded recognizers for Powerscribe and then its successor, Enterprise WorkStation (EWS).

I’d worked with one of the Kurzweil/L&H engineers testing different microphone designs, including custom designs with separate microphones on the back of the microphone, trying to get good recognition despite:

• one male nurse with a booming voice that could be heard throughout the ED even when he was speaking softly,
• trauma patients and trauma surgeons each trying to outshout the other,
• people with kidney stones loudly retching, and
• demented nursing home residents screaming “HelpMeHelpMeHelpMeHelpMe!”

We found one, a customized Philips Speechmike, that worked pretty well. We also traced some of the problems down to poor design of many sound cards, which introduced noise into the mike input.

Powerscribe had many disadvantages compared with Clinical Reporter, but one great advantage: the Dictaphone USB microphone. This microphone, combined with a good sound chip on the motherboard (almost all sound chips are good now, designs have improved) had truly superior noise rejection, and provided excellent recognition. We use this mike in the ED to this day.

As with VoiceEM and Clinical Reporter, Powerscribe saved voice profiles on the server. It also offered an interface to the registration system (so you could pick a patient from a list) and to the EMR system (so completed reports flowed seamlessly into the EMR).

However, Nuance abandoned Powerscribe for emergency medicine, though it’s still supported for radiology. Instead, they offered a program called Enterprise Workstation, or EWS. EWS is designed not just for the ED but for use throughout the hospital or clinic. As with its predecessors, it offers management of voice profiles of the server, and interfaces to registration and EMR. To the end-user (us) it looks, and acts, just about the same as Powerscribe.

Dictaphone Enterprise Workstation

EWS is a front end for all Nuance/Dictaphone speech-to-text. There are three primary modes for converting speech to text and correcting errors.

1. The speech may be self-corrected on the screen, which is what I’ve always done in the ED. Reports are then immediately available on the EMR, which is important for admitted patients and even those discharged from the ED who show up at an outside doctor’s office the next day, or return to the ED the next day. It also allows visible templates as reminders.
2. The speech may be created onscreen using templates, and then sent electronically to a correctionist who cleans up the dictated text. There are no “transcriptionists” any more; essentially all speech-to-text, whether you dictated into a microphone on a computer or into a telephone, is processed first by speech-recognition software.
3. Or, you may simply dictate a complete note without looking at the screen and rely on the correctionist to clean it up.

Options 2+3 entail more expense and delay. The shorter the delay, the higher the cost: transcription (correction) companies charge more for rapid turnaround.

In September 2010, Nuance introduced the Dragon Medical Enterprise Network Edition vSync (what a mouthful) which allows dictation directly into many common enterprise EMR systems, working over Citrix, as well as providing centralized updates and profile management. I have not seen this in action, and am not privy to much in the way of details, though there are rumors that a healthcare system where I work is investigating it as a replacement for EWS in the next year or two. As near as I can tell, this will offer profile management, but no chart management, as the underlying EMR provides that; it will also offer no templates, again depending on the underlying EMR for that. That means integration of templates with speech recognition is likely to be poor, unless the institution and the EMR vendor both work hard on this, with careful attention to user interaction design. Based on past experience, this seems unlikely. But I will keep hoping to be pleasantly surprised.

Quite a few vendors have “integrated” Dragon into their point-and-click EMR systems. But rather than a tight and user-focused integration, it usually has all the disadvantages of both point-and-click and of speech-recognition charting. It doesn’t leverage speech-recognition in an intelligent way, as pioneered by Ray Kurzweil in his original VoiceEM and subsequently Clinical Reporter.

Thus far, I have written only about the Kurzweil > L&H > Nuance/Dictaphone lineage of medical speech transcription. That’s because there is no real competition. IBM had something called ViaVoice, but sold it to Nuance in 2003. Philips used to have its own speech recognition engine but now their speech-recognition products use the Dragon engine. All those other products that we were looking at in the late 1990s? They’re long-gone.

Which is too bad, because Dictaphone could do with some competition. Competition makes product managers focus on the user experience and user interaction design improvements. They neglect these when there is little competition.

Why Speech Recognition is Inferior to Other Charting Methods

As with any charting system, there are disadvantages to speech-recognition. For some people, recognition is poor, though this tends to be with those for whom English is a second language. It’s not a matter of accents; the current Dragon engine compensates well for accents. The problem is with grammar. German-speakers seem to have the worst of it: if you reverse your sentence order from the standard English order (“She threw the ball”) to be like the German order (“She the ball threw.”) then the recognizer gets confused.

A bigger problem is proofreading. Professional correctionists are good at proofreading. Doctors, especially frequently-interrupted emergency physicians, are not nearly as good. And, the recognizer definitely has a dirty mind.

I remember one time that I was reviewing a note sent to me by one of our senior residents, who was a bit on the stoic and hard-bitten side; he’d worked as an big-city police officer before medical school. He had dictated a note on an obese woman who had a rash under her big, protuberant abdomen. He had dictated “The abdominal exam was notable for a large pannus.” Later, he came out of a room to see me in front of my PC, with three or four  residents looking over my shoulder, all of us laughing. He saw the misrecognition (I told you the recognizer has a dirty mind) and turned bright red. I think it’s the only time I saw him embarrassed during his residency.

I have seen many implementations where speech-recognition is grafted onto a point-and-click charting application. Some of these work, but none of them seem to me to work all that well. These seem to have many of the disadvantages of both point-and-click and speech recognition. We know that switching modes slows you down, both physically and mentally. There are opportunities here for entrepreneurs interested in smoothing this user interaction and making a successful blend of speech recognition and templates.

Why Speech Recognition is Superior to Other Charting Methods

Immediate Availability

Unlike with speaking into a telephone, where it takes hours or days for the chart to be available, speech-recognition/self-edit charts are available on the EMR system as soon as you close them. This is big. Think of:

• admitted patients,
• those returning quickly to the ED,
• those following up with their doctors the next day, and
• those calling back with a question right after you’ve left for the end of your shift.

Readability

The problem with most point-and-click templated charting is that it reads like point-and-click templated charting. You can tell. With DocuTAP charting, the support personnel in triage enter the chief complaint, past medical and social history, medications and allergies, and there is no need for me to do anything more than review this by clicking on it. Speeds things up quite a bit. But, it’s a template system. So I find, for example, that the chief complaint is

Patient complains of a Swelling.

With speech recognition, you can dictate a whole paragraph of HPI, or a whole paragraph of medical decision-making, easily. And if you’ve read many ED charts, you realize that these are the only parts that people really read. A good, succinct paragraph summarizing things makes a medical chart much better as a work product. The PCP, the admiting physician, or your partner who deals with the patient right after you leave, will appreciate such.

Yes, you need to use a little peer review and peer pressure to get people to really proofread their own charts, though with Version 11 and above of the Dragon engine, recognition is really quite good. And, yes, the vendor needs to do some user interface modification to promote proofreading. It’s hard to remember where you stopped proofreading when you’ve been interrupted, and that interruption was interrupted by something more urgent, and even that interruption was interrupted. If the vendor were to do something like highlighting all text we’ve dictated, and allow us to run a finger or mouse across the lines as we proofread, un-highlighting them, this might help.

Speed of “Clicking”

One particular fact I mentioned above – that speech recognition can easily distinguish between fifty or a hundred words – is a key advantage of speech recognition templated charting over point-and-click templated charting. That’s because point-and-click charting is limited by the number of words you can see on the screen. And you have to use your foveal vision to scan the screen to find the word you want. It’s slow and limited.

But with speech recognition, you probably already know all the likely words for the fill-in, which means that accessing one of those words is simply a matter of thinking of it and speaking it. This is much faster than having to visually scan a list of words and then use your hand-eye coordination to click on one of those words. And with speech recognition, the word list can be much longer than a list you can see on the screen.

This fact has been too long overlooked as a way to leverage speech-recognition.

If you could find a way to attach a list of words to a fillin of a template, to recognize that they are the most  likely words to recognize, you could improve recognition and usability greatly. Unfortunately, no current products do this: the template systems are quite crude, compared with what Ray Kurzweil pioneered.

Speed

I have found a very effective way to use Dictaphone EWS. I have a standard template – just a slight personal modification of the standard template we all use – shown here:

***************************************************************************
***************************************************************************

ATTENDING EMERGENCY MEDICINE NOTE:

Registration clerk chief complaint reviewed. [<Agree>]

Triage note reviewed. [<Agree>]

[<I performed a history and physical examination of the patient with the resident. I reviewed the resident's note and agree with the documented findings and plan of care (although I have not manually corrected all typographical/recognition errors) unless otherwise noted.

>]CHIEF COMPLAINT: [<>]

History of Present Illness: [<>]

REVIEW OF SYSTEMS: [<All systems listed below were reviewed and are negative unless otherwise noted in the report.
General
EYES
ENT
Cardiac
Respiratory
Gastrointestinal
Genitourinary
Musculoskeletal
Dermatologic
Neurological
Endocrine
Hematology/Lymph
Psychiatric
Allergic/Immunologic>]

PAST MEDICAL HISTORY: [<As above>]

MEDICATIONS: [<Reviewed and agree with Nursing Notes>]

ALLERGIES: [<Reviewed and agree with Nursing Notes>]

SOCIAL HISTORY: [<As above>]

PHYSICAL EXAM: Vital Signs: [<reviewed nurses' note>]

PATENT STATUS: [<alert, cooperative, no visible distress, not ill appearing, well-hydrated>] [<>]

[<>][<>][<>]

MEDICAL DECISION MAKING/DIFFERENTIAL DIAGNOSIS: [<Old records reviewed.>] [<>]

DIAGNOSIS: [<>]

DISPOSITION: [<Patient discharged in stable condition. Computer-generated discharge instructions provided.>]

Though the ideal for many is bedside charting, and I’ve done bedside charting with T-sheets, and have seen some hybrid systems that allow some part of the chart to be done via dictation at the bedside, this system is used at a sit-down PC. I’m still a fan of scribbling a few notes on a 6.5×5″ bit of card stock, folded in half, and stuck in my pocket. Even when we had what is arguably the best ED tracking system, Wellsoft, I still used the card in my pocket as a “peripheral brain.”

My usual charting strategy is to primarily dictate a long HPI, which includes a bit of social history, and pertinent positives from my review of systems (ROS). I can usually do this paragraph in one continuous utterance. It’s quick. Then, my template says “as above” for both social history and ROS, so I don’t usually need to modify them. I can then dictate a physical exam as follows, using the proword “Dictatphone” to tell the program that each of these is a “shortcut” (macro to programmers). Each of these is a standard “shortcut” that I have personalized to reflect my usual normal exams.

Dictaphone Normal Eyes
Dictaphone Normal Throat
Dictaphone Normal Neck
Dictaphone Normal Back
Dictaphone Normal Chest
Dictaphone Normal Lungs Heart Abdomen
Dictaphone Normal Skin
Dictaphone Normal Extremities
Dictaphone Limited Neurological

I can take a deep breath, and dictate this without stopping. It takes just a few seconds.

One problem with any templated charting system: it’s easy to chart things you really didn’t do. So I dictate a “normal” only for those things I actually examined. As these shortcuts (macros) are expanded, you see something like this on the screen:

THROAT: [<No injection. >] [<No exudate. >] [<No tonsillar hypertrophy. >] [<Airway widely patent. >] [<Uvula is midline. >] [<No tonsillar bulging, retropharyngeal soft tissues appear normal. >]

I then go back, use the mouse to highlight over anything that’s actually abnormal, and dictate the abnormal to replace it, thus:

ABDOMEN: Soft, nontender, normal bowel sounds, no guarding or rebound, no hepatosplenomegaly or mass, no bruit.

ABDOMEN: Soft, mild right upper quadrant tenderness, no Murphy sign, normal bowel sounds, no guarding or rebound, no hepatosplenomegaly or mass, no bruit.

Incremental Chart Completion

One of the great advantages of speech recognition charting, compared to talking into a telephone, is that you can break this process in half. You can start a chart, spend a few seconds dictating just the HPI, and save and close the chart. That way you’ve at least got the history down, and visible to you when you re-edit the chart. This is a great service to those of us who sometimes get back to our charts at the end of a shift and have a hard time remembering: “Was that the first old lady with abdominal pain? Or maybe the third?” Indeed, this ability to suspend charting in the middle is perhaps the most popular feature of speech-recognition charting with our residents. They rotate between our hospital, where we use speech recognition, and another hospital, where they dictate into a telephone. An informal survey reveals that 2/3-3/4 of the residents prefer the speech-recognition charting system, mostly for this reason.

* * *

Overall, in terms of efficiency, usability, functionality, and quality of work product, I know of nothing that works as well for ED provider charting as Enterprise WorkStation. It’s frustrating, though, as the company has done little to improve the product’s user interaction design, and is slow in upgrading the recognizer to the current shrink-wrap retail version. It could be so much better.

I look forward to reviewing the competition, and upgrades to Dictaphone’s charting software, when it appears.

"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.