Communicating with Your EHR - Can You Hear Me Now?

For the previous post in this series, click here.

How an EHR behaves is highly dependent on design and other technical properties of the underlying hardware and software. These basic properties are essentially unalterable and can have lasting, and often negative, effects on what a product can do today and whether physicians will find it easy to understand and pleasant to use. An understanding of these underlying factors makes it possible to predict the strengths and weakness that a product will exhibit. The story begins at the beginning: How to communicate with the equipment.

Remember the days of DOS and CP/M? If you do, you probably remember typing something at the prompt and being rewarded with "Bad command or file name." Opening a command window on Windows you get the similar but slightly more informative message "'xxx' is not recognized as an internal or external command, operable program or batch file." Of course, both of these messages mean the same thing - you were attempting to "command" the computer to do something and the computer did not "understand" what you meant.

What does "understand" mean in this context? It means that the computer followed a set of internal rules for interpreting what you typed. If any of the rules is satisfied, what you typed IS a command and gets invoked. Otherwise you get a raspberry.

Since the dawn of computer time, only a small number of ways have been devised to effect command and control of computers. Computer applications are affected by which command and control model was adopted by those who built the computer.

The earliest method of launching an application is what I call "Load and Go." Programmers would hand-code each machine instruction and load them into sequential memory locations using a bank of toggle switches starting at a pre-determined address. Once loaded, the programmer would press the "Go" button and the computer would begin loading and executing the instructions. Execution would continue until the program came to a normal end-point or the operator pressed the "Halt" button. Later, the instructions were punched into a paper tape and the operator would execute a small program (perhaps built-in) that would start up the paper tape reader and fill the memory with instructions. When done loading, control would be transferred to the starting address of the newly loaded code. (Old-timers will recognize that I've not mentioned another Load and Go variant - punch cards and JCL on the mainframe.)

Imagine that instead of toggling switched or punching paper tape, the instructions were recorded on/in some sort of electronic medium such as magnetic tape, disk or a memory chip (read-only memory known as ROM, or nonvolatile random access memory known as NVRAM or flash memory.) Here the story of Load and Go branches; magnetic storage raises issues that are different from memory storage.

Memory-stored launch is familiar to everyone. It's what makes your microwave, TV, car, and cell phone operate. Systems built like this are called embedded systems; all the instructions and data needed to operate the device are contained within the device. You turn it on and it goes. Even the portion of your home computer that controls initial boot up, the BIOS (basic input/output system,) is an embedded system.

Launching a program from tape or disk is a bit more complicated. Tapes and disks are complex, but low-level devices. The information they store is not laid out neatly as a sequence of well-formed data words that the computer can digest directly (like an elemental or hydrolyzed protein formula). Instead the individual bits are stored in a linear stream. Something has to control where reading will begin, the packaging of the stream into computer bytes and words, the transfer of those data words into the computer's short-term random access memory (RAM) and, last but not least, when to stop reading. In other words, the process of reading data from a magnetic medium (and writing to it) is complicated and requires a specialized computer program, either a tape operating system (TOS) or a disk operating system (DOS.)

Once the TOS or DOS is loaded, what next? Well, it just sits there unless there is a way to command it to do something. The next section will start by exploring the alternative ways that an instruction could be given to the operating system.

Reference of the Week: Frédéric Bastiat, The Law [1850], Online Library of Liberty hosted by Liberty Fund, Inc.