Tales from the data entry trenches

When a family member underwent a series of minor medical procedures recently, I got a telling glimpse of the hospital’s data-entry systems. As I’m sure is true elsewhere, it isn’t a pretty picture.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

The ordeal begins at the registration desk, where, no matter how many visits you’ve made -- sometimes even on the same day -- you are required to “verify your information.” Listening to someone read from a screen such facts as date of birth, address, employer, and insurer has always bugged me. But when this procedure is immediately repeated at the surgical registration desk, it becomes a flagrant HIPAA violation. Anyone within earshot is made privy to information the hospital must, by law, safeguard.

After you have been admitted, each exam room and lab requires its own consent form. They’re all identical, so you wind up scribbling the same information, which you only just painstakingly verified, onto one piece of paper after another.

It’s easy to mock this kind of bureaucracy, and I don’t pretend that if I were king, I could bring order out of the chaos. But I do think putting people in charge of their own data entry would help.

For one thing, I’d trust an SSL channel to the hospital’s database more than a spoken interview with a bored clerk. And I could take care of filling out the forms the night before, in the peace and comfort of my own home. Not everyone could exercise this option. But growing numbers of people would, and everyone registering electronically subtracts from the queue at the registration desk.

Offering Internet registration isn’t a slam dunk, of course. The medical data-entry systems I’ve seen are nowhere near ready for self-service. They really do require clerks who know how to navigate the software and obey the business rules that govern it.

Watching over their shoulders, I could see some of the reasons why the navigation is harder than it need be. For example, several of the Windows-based programs I saw exhibited the “dancing tabs” syndrome -- one of the classic errors described in Jeff Johnson’s book GUI Bloopers. Here, dialog boxes present rows of tabs, then disconcertingly shuffle the ordering of the rows as you move among them. It’s a problem for me whenever I try to manage settings in a Microsoft Office application, and it was also clearly a problem for the clerks I observed.

I’ll bet the vendors of these applications and the customers who bought them would describe the software as easy to use. If pressed to explain why, they’d cite its graphical user interface. But a GUI alone is no guarantee of usability. Neither, I hasten to add, is a browser-based UI.

Data entry is just plain hard to get right. For all the XML wizardry under its hood, the highest achievement of Microsoft’s InfoPath may be its smooth and supple user interface. According to MS XML architect Jean Paoli, InfoPath’s interaction model took several years to discover and refine.

I’ve griped before about Microsoft’s weird reluctance to saturate the market with copies of InfoPath. Alternatively, I’ve suggested that a competitor might leverage open source (Mozilla) and open standards (XForms) to create a ubiquitous next-generation platform for data collection. One way or another, something’s got to give. Requiring human proxies to mediate interactions between customers and database records is neither cheap, nor reliable, nor secure.