In order to illustrate, test, and deal with initial problems involved with setting up connectivity between a local application and a simple Rules Evaluator residing on a Web Server, we developed a Phase I Protocol Engine Demo. The demo illustrates the way a local application running on a PC can interact with a web browser running concurrently on the same system.

The demo must be run on systems with Windows 95 or Windows 3.1 and requires that a TCP-IP connection be established, and that a web browser such as Netscape Navigator or Microsoft Internet Explorer be present on the system. The demo will be posted on our web page http://www.cksoftware.com. The local client can be easily downloaded, installed, and uninstalled by any person interested in reviewing the status of our work. As changes are made to the demo we will keep updating them onto the web page.

The demo has four components: (1) a data entry application, (2) a rules definer, (3) an event checker, and (4) an enforcement agent. The data entry application and the rule creating agent are written in Delphi and run on PC's running Windows. The event checker resides on a Unix web server where it performs as the rule archiver, the processor which compares events to rule triggers, and the information delivery agent. The web browser which runs on the same PC as the Delphi apps, acts as the information display and enforcement agent.

1. Data Entry Application:

This is a simplified mockup of a medical data entry package, in which users select various patient demographic categories and visit elements from predefined check off lists. It has been written in Delphi 1.0 and will run on systems with the Windows 3.1 or Windows 95 operating systems. There are pull down lists for guarantor and insurance information, and check off dialogue boxes for the reason for the visit, patient diagnosis, visit procedures and treatments. Once the data has been entered, and the protocol button is pressed, the data will be sent to the web server to see if there is a match between what the user has entered, and a triggering event that has already been defined in the rules table.

Each check-box in the data entry application, is also present in the Rules Definer. This gives the check-boxes an independence from the data that they are meant to represent. Within an organization, as long as the labels on the check-boxes are consistent on all data entry applications and rules definers, we can use a unique three character code to represent the fact that a specific check-box has been marked. The check-box is thus tied to whatever is expressed by its label, not to any underlying data.

We have experimented with different screen sizes for the data entry application, and currently have it appearing as a fairly small screen, with buttons that either drop down lists, or pop-up dialogue boxes from which criteria can be checked off. The reasons for the small screen are (1) all messages that appear in the web browser will be completely visible, (2) we wish to emphasize the concept of even being able to run this in environments where we have virtually no access to data, as an independent add on which will have minimal impact on the data entry load, but which users could use to quickly check off critical criteria, and get immediate feed back on rules and requirements.

2. Rules Definer.

The rules definer is functionally very similar to the Data Entry Application, except we are not entering information from a specific patient encounter, but instead are indicating the combination of criteria for which we want to define a rule. The status descriptors or other criteria that we check off, basically define the triggering "event" that will initiate the activities described in the rule actions. The demo allows one action to be defined for each rule in the form of a message that can be displayed on the user's screen, printed, or sent to anyone with an e-mail address. The rule is defined locally, and then after it is saved it can be uploaded to the server, where it will immediately be added to the rules database by the web server application.

In the Rules Definer all choices that users are able to make from each category are uniquely encoded. Again, as long as labels are consistent within an organization, the codes that are used, need not have any relation to the data described on the labels. The codes from all choices that are checked off are combined with each code being separated from the other codes by a single character delimiter. This string of codes which represents all choices that a user has checked off is then what gets sent from the local application to the web server. This minimizes network traffic, and increases security. The demo only deals with one type of logical relation between the different items that are checked. All are treated as exclusive (logical "AND"). In Phase II we will deal with the problems of embedding more complex logic and adding data to the messages that are sent to the server. The Rules Definer is also written in Delphi 1.0 and also requires a computer running Windows 3.1 or Windows 95.

When a rule is saved and then uploaded to the web server, the string of encoded elements that have been checked off as being what defines the rule, are used to generate a unique file name which contains the message that the rule is supposed to deliver to a user whenever it is triggered. For example a label in the Visit Reason check off box might say Well Child Exam, but be encoded as a unique three character code: bdd, with b representing the Visit Reason category box, uniquely identifying this specific check off. In UNIX namespace there are 62 possible characters that can be used in each of the 3 spaces, so there are for this one 3 character code, 238328 possible strings, like the Well Child String, that can be represented. It is possible to have a total of 62 chunks of 3 character codes in a token, this is a very large number of unique combinations. It is the challenge in phase 2 to embed logic in this scheme so that AND, OR, NOT, WITH and DATA can become a part of the web servers vocabulary. In this way a token could have DATA associated with it. This data could be the upper and lower boundary of a lab result, or a patient's insurance policy number for example.

In this prototype we are able to abstract data to a small unique code that is essentially independent of underlying data because both the rule maker and the rule querying come from programs that are very similar and kept synchronized. They look somewhat different, but refer to the same code to check off either triggering events or visit criteria.

3. Event Checker.

This is a web server application which receives data, determines if a triggering event has occurred, and if so sends appropriate HTML files to the Web Browser on the computer that the local data entry application resides on.

When the Protocol button is pressed after entering visit information on the Data Entry Application, the character string that contains the encoded set of visit and patient demographic categories is transmitted from the Delphi Application to the web browser in Dynamic Data Exchange (DDE) format. This is a format developed to allow tasks in different windows that are running concurrently on the same computer to exchange information between each other. The encoded event string is passed as part of a command string which tells the web browser running concurrently which URL to contact, and the full message to send to the web server once contact is established. The string that is passed to the web server initiates a CGI script on the server which is what examines and determines if the encoded "event", which is passed to it as a parameter, matches any of the rule triggers in the rules database.

Our means of communicating between the local application and the web server relies on DDE to get the application to initiate an action in the browser running in another concurrent window. The local windows application itself is not communicating directly to the Web Server over the TCP-IP link. Instead using DDE it embeds an FTP, REXEC or SQL query command that the browser transmits to the server. For example when a new record is added to the Rules Definer, it is first saved in a local temporary file. When an update to the rules database is executed, that temporary file is sent to the server using FTP (file transfer protocol), and then the REXEC process starts a script or batch file which adds the records in the temporary file that was just transferred to the main rules database.

The data entry application communicates through the web browser in a similar manner. Visit criteria are passed as an encoded event string. A header on the event string, initiates a CGI script which checks to see if an exact match between the encoded visit criteria and a file name in the response file directory is found. If so, that means that visit criteria exactly match all of the criteria set up to define a triggering event for a specific rule, and this initiates the action that is supposed to follow a triggering event. If the rule requires that email be sent to anyone, mail with the rule's alert and message are sent. Then the text contents of the rule file back to the web browser. Since the text of the rule file is saved in HTML format, the file may include one or more embedded links to other web sites which contain appropriate technical, medical, or instructional information.

If no exact match is found for the encoded visit criteria, the CGI script running on the web server gathers a list of all rules, which have triggering event descriptions which are non conflicting subsets of the elements that make up the current visit criteria. By non conflicting subsets we mean that all of the criteria that make up the triggering event are included in the current visit's criteria, but there are some criteria checked off for the current visit that are not mentioned in the trigger. For example we could have a rule defined which is triggered when a patient comes in with Travellers' Insurance and the reason for the visit is a work related injury. When a patient with a Travellers Insurance policy comes in for a work related injury, and we fill out the check off boxes for the visit criteria, we will most likely fill out additional diagnosis or procedure information. Thus the server will not find an exact match between the visit criteria, and the rule triggering event. In that case it will do a second search, collecting a list of all rules with triggers which are non conflicting subsets of the criteria entered for the visit. The user can click on any item on the list to activate it, and display the message associated with that rule.

A Simple and Workable Approach to Data Independence

While we know that this demo greatly oversimplifies the inherent complexities of health care rules, we justify what we have done for two reasons. (1) This was a first phase demo, designed primarily to test and illustrate interaction techniques between a local application, a web server, and a web browser. (2) Simple approaches often hold the key to addressing the most important problems in a timely and efficient manner. A simple tool bar, such as is illustrated by our rules definer, takes up very little room on a typical screen. Minimal effort would be needed for an organization or health care alliance to set up check off boxes that could be filled in with minimal additional effort by users. No underlying relationship between the check off boxes and the data that is being entered into the local application would be required. Obviously, the disadvantage is that if there is no underlying relationship to the data, a certain amount of double entry will be required. Users would have to enter data in their local application, then check off selections from a rules checking tool bar or vice versa. However by the use of pull down lists and check off boxes, the amount of duplicate entry could be minimized. The advantage of this approach is that it is immediately workable and can be deployed on all of an organization's participating systems without delay.

Optimization for Speed.

We experimented with various methods of storing and querying rules, and producing the HTML files that were associated with the action messages that the server needed to send out whenever an action was triggered. To store the rules on the Web Server we were using an inexpensive SQL shareware database. This database was very limited and extremely slow by modern standards. It's primary weakness is that it can not do more than one thing at a time. It processes requests serially, where modern more robust SQL databases do so concurrently. As a result we were forced to deal with methods to optimize speed. We limited our use of the database to retrieving the rules to edit them, and as such it acts primarily as a holding device. In a real setting, concurrent processing would be an absolute must if the data was to be used in more traditional SQL ways. However because of the rate at which new tools for web database management are becoming available we might find that a product like WebLogic, which with its action classes will more efficiently provide a better mechanism for storage and categorization of rules than formally setting up a rules database.

Rather than doing a traditional SQL query, and creating an HTML file with the text of the message that had to be sent in response to a triggering event, we used a naming convention that allowed us to pre-build HTML files, and select them without having to query the database to see if a particular encoded event string triggered a rule. Because UNIX file names can be very long, we put the encoded event string into the file name. This is a good idea for a completely data independent application. In our Phase II work we will put some serious thought into whether it holds potential for being a workable solution in real world situations.

Growth and Development Path

We understand that what we built in our Phase I demo is not yet ready to work as a commercial solution. Possibly it is merely a learning step to test and illustrate multi-platform connectivity and communication. However what it has done very well is illustrate the power and immediate applicability of a simple, data independent concept. It has little of the sophistication and complexity described in the previous Prototype Design Specifications section. Setting up that kind of prototype was beyond the scope or resources of this phase of the project.

On the other hand, by adding a few incremental changes and improvements to the demo, we feel we would have a simple, but very powerful tool that organizations with far flung and disparate data sets could put to use immediately, to set up a means of monitoring and enforcing critical organizational guidelines at all sites throughout their system. These features are:

1. Provide organizations with the ability to define their own check box categories and labels, and list elements.
2. Improve rule definition by adding other logical operators so that triggering events can be defined with more complexity and sophistication.
3. Allow multiple action sequences to be defined.
4. Merge context sensitive information into email messages that are sent as part of the rule action sequence.
5. Improve algorithms for determining if a triggering event has occurred. The system needs to make more intelligent choices about when criteria describing the visit or other event are close enough to a trigger, to initiate rule actions without requiring additional user intervention.

Again, while we realize that many of the essential features described in the Prototype Design Specifications section would still be missing, an application with the improvements listed above would be very useful to many large organization and alliances, and the immediate help that it could provide would more than make up for its limitations. Therefore we are planning to proceed with these improvements to the demo so that we have a product that can be put in place while we deal with some of the much more complex elements of the design specifications.

User interface. The demo has illustrated the importance of having a very simple user interface. We have found that once we explained the basic principals of how the demo worked, most users had no problem setting up a few rules and entering some data to see if it worked. On seeing alerts pop up at the right times, they came away favorably impressed. However our attempts to setup prototypes of screens that would be needed to define rules in the more complex ways described under Prototype Design Specifications were much more confusing to some users, who had problems understanding such things as how data links needed to be defined, what an expression consisted of, and the difference between data to be examined and data to be collected once it was determined that a triggering event had occurred. It became clear that it would be necessary to develop a multilevel user interface. The simplest level would need to be suitable for non technical users, who would need to be able to easily set up straightforward rules without a lot of technical help. Simple rules may be the ones that are most important for an organization. A presentation of simple choices, grouped in a manner similar to those outlined in the current demo would work very effectively for this purpose. A more complex user interface would need to be made available for situations in which data links, supplemental data entry screens, rule variances, or complex and conditional activities need to be defined.

Messaging System. By completing work on a set of specifications for a simple messaging system which will allow third party applications to communicate with the Protocol Engine, we will alleviate much of the primary problem of using a simple data independent interface. If a message from a third party application can provide the same information to the web server that it now gets from the data entry component of the demo application, it would not be necessary for users to reenter the patient's name or check off items which may already be entered in the primary local application. Rule checking and notification could all continue to be handled as described in the incremental changes previously discussed.

Development platforms. For success in the medical world, parts of our application may have to be written in two separate versions: one in Java, and one in a Windows language in order to encourage transitional use of the product in environments unable to support the Java virtual machine. Thus we will probably need functionally equivalent rules definers, one written in Java to run on any browser, and one written to run on a PC. This should not be difficult to do because both the Java and Windows applications will be the thinnest of thin clients that only check data integrity and transfer the data or data tokens to another place. In this way an institution with mixed age computers can immediately use the rule/trigger software. Alternately depending on environments, we could have clients which make use of functions in both a normal windows application and a web browser in separate windows, but working together to perform each of these functions ( in a manner analogous to but more sophisticated than the way the browser and the Delphi app work together in the demo). The browser does not really need to be the one sending the query to the server, however if there is a response received from the server, allowing the browser to handle it allows for a much greater level of platform independence.

Either platform independence, or multiple versions of the same product will be needed for the web server and the rule processing software that the web server depends on to know what action to take. In real environments one can expect NT Servers, and servers running UNIX in the slightly different versions offered by different vendors, such as Data General, HP, and Digital Equipment. We are currently studying a product called WebLogic which works in a Java environment with methods to access all of the most common SQL databases.

Security. We have not yet dealt with security issues, but those will be critical as soon as we have a product that organizations will be looking at seriously. Much more flexible, elaborate and robust rules making and initiation process, with much greater data security than the simple encoding process that we used. We realize that to be workable in real and demanding situations, we must either develop or acquire a library of configurable action methods which meet the design criteria described previously. What is needed is a single, fast, firewall friendly communication protocol. Native HTTP support which Java provides and which is now available for windows languages such as Delphi is critical for this. Firewalls are security barriers that will be becoming more and more widespread as organizations attempt to setup secure networks which make use of established internet providers and lines. Firewall friendly communication protocols basically are packaging schemes that allow servers to immediately identify what group a specific packet of information belongs to and whether any specific packet can access information or utilities that reside on the server, or can only be transferred to other places. Similarly, as organizations begin establishing their own private intranets, there will be the necessity for users without direct access to the intranet lines to access the information. Again all sources of outside access to these networks will be protected with security that will allow rapid access to only properly packaged packets.

Notification Techniques. In Phase II we have proposed to use server-push, client-pull as a way to more economically connect the triggering event with the server's protocol reply. To accomplish this task the web server and "thin" client need to communicate with the HTTP network protocol. Server Push deals with issues of having the server initiate communications with a client. The normal means of contact between web browsers and servers is client push, where the Browser / Client initiates all contacts. With server push, the server attempts to see if a client is out there, by pinging, and if it gets a response it sends information without prompting by the client. This requires that there be processes running on the server which are either constantly running, or can initiate themselves at particular times, by maintaining a kernel which is constantly running. Working with this new technology is essential to the success of Phase II work.

Data Access. Ultimately it will be critical to have tools which can access outside data sources. More work will need to be done with incorporating outside data sources into the client's software control. New products, such as the Java based WebLogic software for monitoring all of the most common SQL databases, may tremendously cut down the effort required to do this work, and make our goal of being able to independently access third party data sources much more achievable. Integrating this access will be a critical part of the Phase II work.