Windows Provide Clearer Focus for EHR Use

For the previous post in this series, click here.

“Multi-tasking - Screwing everything up simultaneously.”
- Anonymous

Last week we explored why the decision to base a computer system on a Command Line Interpreter (CLI) can influence how an EHR behaves and what features it can make available. To review, most commands to a modern computer are processed by a CLI. Mostly it’s invisible these days unless you open a DOS window on a PC or a Terminal window on a Mac but it’s there in the background.

Back in the days of PC-DOS, you started a program from the DOS prompt and from that moment, until the program ended, the computer devoted itself exclusively to running that single task. (Purists will please forgive me for not delving into TSRs.) A computer running DOS was, by definition, a single-user, single-tasking computer - a very personal computer. Adopting these constraints kept the cost and complexity down and made the device relatively easy for novices to use, at least until they started to get impatient.

As you learned if you read last week's reference on the origins of MUMPS, some computer systems were and are, multi-user but single-tasking. Such systems apportion computing cycles to all users in an egalitarian fashion, without giving priority to any individual user. The MUMPS system provided in my clinic works like this: If I need to look at two portions of a patient's information at the same time, I have to log on a second time and hope the first session doesn't time-out while I'm in the second. The platform on which I first built a production EHR (back in 1985) was also a multi-user, single tasking system. They can be extremely useful and cost-effective but by now, users expect more and the complexity of care demands more.

From the very beginning, the Unix system was both multi-user and multi-tasking but there was a big gotcha - the computer terminal was "dumb." All it could do was display 24 or 25 lines of text. This would seem to put an end to any hope of multi-tasking - but - Unix users were (and still are for the most part) geeks. They love arcane, complex stuff and Unix obliges with two ways to multi-task.

First is the "background job." Putting an "&" at the end of a command launches the task in the background. It runs until it's done and may unceremoniously send lines of text to your screen right in the middle of whatever you were doing, especially if an error occurred and you forgot to pipe (remember pipe?) the error output to a file. The other way to multi-task is the "virtual terminal." Most terminals had function keys like your computer today. In Unix, each function key accesses a separate session; of course you still have to log in. It's like having 10 or 12 terminals lined up on your desk. Each virtual session continues even if you toggle away from it. This can get pretty confusing and it's certainly not something appropriate for ward clerks or busy doctors - it's simply too geeky.

Then someone had a bright idea*- to use a graphical display instead of character terminal. Doing so makes it possible to draw a little box into which a program can write and from which it can receive input. The box is called a window; each program is said to be running in a window. Instead of needing 12 virtual terminals, the user can start whatever programs they like. Each one has its own window. One window is said to have "focus" and that's where anything that you type will go. Switching the focus to a different window is easy.

It doesn't matter whether the windows are brought to you courtesy of Microsoft, Apple, or some Unix or Linux system. Windows (in the generic sense) provide an organizing theme (a metaphor if you like) that takes multi-tasking out of the geek realm and makes it more understandable to the general public, thereby helping them to unlock the power of the computer.

The next article in the series will begin to examine why the popular programming languages and databases are ill suited to medical data.

* Reference of the week: History of the graphical user interface, Wikipedia.

Learn more about Daniel Essin and our other contributing bloggers here.