The Origins of EHRs - Commanding the Computer

For the previous post in this series, click here.
"We face the same issues even if we speak different languages."
- Jaime Contreras
…but…
“Language shapes the way we think, and determines what we can think about.”
- Benjamin Lee Whorf

This week continues the discussion of how a computer’s basic design can influence how an EHR behaves.

When the original Apple computer booted up, it presented the user with a blank screen, a prompt character and a blinking square. At that prompt you could type things like:
10 PRINT CHR$(4)"PR#3" : PRINT CHR$(0); : POKE 49246,0 : GR
This text is a simple computer program.

The prompt is generated by a program that functions as a language interpreter. It is stored in the computer’s read only memory (ROM) and launched when the computer is switched on. Its purpose is to understand and execute program code. To perform a function, such as copying from one disk to another, requires a program that will read data from the source and write it to the destination.

Various specialty systems have been based on language interpreters, especially those used in artificial intelligence, but the most common one that you never knew about is MUMPS, the language behind many of the large EHRs such as Epic or the VA. A simple tally of all the computer systems in use today will reveal that the language interpreter did not win the evolutionary battle for dominance. The winner was the Command Line Interpreter (CLI.)

MS-DOS, Unix, and Macintosh, among others, provide a CLI, sometimes called a shell - in DOS it was command.com. That's where the "Bad command or file name" message came from. The CLI takes what is typed (e.g. "xxx") and attempts to match it to its internal commands such as DIR. If there is no match, it looks in the current directory for xxx.bat, xxx.com and xxx.exe. If that fails, it does the same search in every directory listed in the PATH variable. If that fails, the dreaded message is displayed.

Now comes the powerful part. A bunch of commands can be placed in a text file (e.g. xxx.bat) and the CLI will perform them all in sequence as if reading a script. Additional instructions allow programming scripts such as by testing for failed execution or verifying that a file exists before running a program on which it depends. This is called shell programming and it is a vital part of setting up large computer systems that will support multiple users. Today, a language-interpreter-based scheme such as MUMPS is almost always run on a Unix platform and would not be viable without the CLI and shell programming.

Consider the possibilities if each program could accept input from a stream or pipeline instead of a person typing and send output to a stream instead of the screen. The CLI makes it possible to string a series of small, single-purpose programs together to produce an overall result. A program could find all the files with EHR in the filename, "pipe" those names to a program that searched inside each file for a specific text string, replacing it with a new one and then pipe them to a printer.

The vital side effect of the CLI and piping is standardization. Everyone proposing to use the features must agree to and adopt the same standards and conventions for what a data stream will look like and how the programs will be built. The existence of these conventions allows programs and data to be distributed and used by others.

The next article will continue the discussion of command and language interpreters.

Reference of the week: Language, Thought and Reality: Selected writings of Benjamin Lee Whorf, John B. Carroll ed., MIT Press, 1956.