By Kevin C. O'Kane, and Elizabeth E. McColligan

Summarized by Chris Bonnici

In the distributed environment of the World Wide Web, the ability to run a program written in the language on any combination of target operating system and hardware is of critical importance. The paper describes the development of a virtual machine environment that can support decentralized M based medical record.

Many of the medically based Web systems recently proposed rely on the PERL or REXX scripting languages that, in turn, depend upon commercial data warehousing systems for data base services. More recently commercial systems have become available, generally only on large computers, in which the data base system itself is the web server. Both are examples of server-side computing with the browser running on the user workstation generally functioning as little more than a sophisticated graphical terminal utilizing HTML as the server-client language. HTML is being used iinput data from and display results to the client.

Problems with the model presented above are that these normally require powerful servers. With a moderate amount of users (by web standards) the amount of processing at the server can be enormous. On top of this one must add the computing cycles taken up by the script processor. The authors also point out that script processors such as PERL and REXX are not particularly well suited for medical record applications given the free form and inconsistent nature of medical data. Also different departments may need to view different (or differently arranged information about a patient) and this makes the area of medical informatics quite unique. Since script processors normally exist for relatively modern database applications, on old computer platforms running legacy systems one must port these and on many occasions, a varying proportion of the system would have to be re-written.

A number of database vendors (including some M vendors) have incorporated web servers directly into their products. This bypasses the need to for PERL or REXX scripting tools one generally locks the user into a large system, single language environment with little flexibility to access graphical, sound and video content that are today an integral part of the web. It also limits the range of possible other programs that can be run concurrently for various needs. A general purpose web server with no restrictions on the hardware and types of applications that can be developed is most desirable. (The Network Compute—NC—is being viewed by some as the next generation of computer. It will be physically small, cheap and not very powerful. The underlying CPU can also vary from one brand of NC to another - CB).

"This paper presents a Mumps virtual machine environment that is transportable to most popular desktop operating systems and has the following features:

• it is derived from M and provides a full range of string handling routines and built-in functions;
• it provides a B-tree based hierarchical and relational data base facility;
• it is small, efficient, quickly loaded and executed, and it co-exists with other server based applications;
• it is fully transportable to Unix, OS/2, Win95 and Win/NT environments;
• it provides full and easy access to user entered HTML form data;
• it has several extensions that aid in return of HTML document code to the server and client;
• it permits access to operating system facilities including other script processors and data base management systems;
• it is scalable from PC's to mainframes;
• it can access all system facilities such as SQL, DB2 and Oracle;
• it permits legacy Mumps based software to run directly on the Internet;
• it can both execute software sent from clients and it can download software applets for client execution;
• and it can be run in standalone mode with or without a Web browser."

The system described above is based on a M shell processor written in C++ making it system independent. A M program consists of an ASCII file containing Mumps source code. When invoked by a web server, the interpreter then looks for any GET mode data passed by the CGI interface in the system environment variable QUERY_STRING. If any data is present in the environment variable QUERY_STRING, it is scanned, decoded, and decomposed into varname=value tokens that are then used to instantiate and initialize Mumps local variables. The varnames are derived from the NAME field of the HTML FORM tag and the values are derived from either the VALUE field or actual user entered text. The interpreter then executes the script and any standard output generated is captured by the web server for return to the originating browser. The interpreter may also be invoked in standalone mode operation without the CGI interface.

A user at a browser sends input to a program operating in the Web server cgi-bin interface through the HTML forms facility. In this mode of operation, the server begins the dialogue by sending to the Web browser an HTML encoded command stream that includes one or more instances of the <FORM> command. The <FORM> command causes the browser to display data input fields on the user's screen. These appear as data entry fields, check boxes, list boxes or radio buttons. When the user, through his browser, has completed entry of the data item or items or selection of one or more of the other multiple choice options, the Web browser encodes and sends the results to the Web server for processing. The web server stores the parameters from the browser in the environment variable QUERY_STRING and invokes the Mumps processor. The Mumps processor executes the appropriate Mumps program (the identity of which was one of the parameters) and returns a stream of text to the web server for transmission to the originating browser. The originating browser, receiving the results, displays them to the user.

Web servers do not preserve information pertaining to the user state from one transaction to the next. This means that data from the previous transaction will not be available. As happens frequently in Web applications, the MUMPS Virtual Machine resubmits to the user all data that will be subsequently needed to deepen a query. Whether the data is made visible to the user or not is totally at the discretion of the program that generates the output. For example, after entering a patient reference and obtaining the static details of the patient, the patient reference will be transmitted to the user. When the user clicks on one of the options on the latest screen the patient reference is retransmitted together with the new data.

Information between the originator and the receiver can travel through a host of servers and such sensitive data can be either examined and worst still tampered with. Presently there are a number of robust security features including data encryption, with other under development. Also data must be made available to only those who should have access to it. Most servers support a password based user authentication and access control. Other forms of tokens can be used if necessary. These issues are not implemented directly into the MUMPS Virtual Machine but are available through their own specialized markets.

Another feature of the Mumps language processor is that it can send and receive messages directly from/to other Web servers and browsers. For example, a central server may instruct a remote server to execute programs with the results returned to the central server. This type of distributed processing allows load sharing and can be used to make the overall operation much more efficient. Also, a central server can update data at remote workstations dynamically by passing update data to the workstations and invoking the appropriate update routines.