A search of literature discussing protocols, practice guidelines, standard orders, and critical paths was conducted to compile elements critical to the design and successful functioning and implementation of both manual and automated protocol systems.

Research and surveys confirmed that timeliness, flexibility and analysis of variance were critical factors for success. Rules, guidelines, or care plans had to be available to the provider at the time decisions were being made. Plans had to be adaptable to complicating circumstances, such as multiple problems, each with its own critical path, in a way that was helpful rather than burdensome to staff members. Their output needed to become the basis of charting, rather than an added record keeping burden. Variances from critical paths needed to be monitored, analyzed, and used as the basis for future modifications. Where the system was not flexible enough to be used in most cases for which it was intended, it became a headache and failed.

On the basis of our research, we have defined protocols in as flexible a manner as possible. Each protocol can be defined by the following components:

1. Trigger. This is a combination of one or more circumstances which indicate if a particular protocol is applicable. Among these are the reason for visit, clinical diagnosis, clinical procedures, the patient's age, sex, employment, medical history, test results, functional capacities, outcomes, and the completion of actions specified by other protocols.
2. Actions. Activities specified by a protocol, which may have prescribed sequences, starting times, durations, required precedents, specified providers or technicians, allowable variances, and their anticipated causes.
3. Events. Status descriptions, milestones, outcomes, or examination results. Protocol may anticipate meeting these at specific times, and key actions off of the success or failure to do so.
4. Forms. Routing slips, orders and care instructions, educational materials, letters to employers.
5. Data Tables. Set of predefined formatted records which are created each time a protocol is triggered in order to facilitate tracking and analysis of outcomes. The data that needs to be recorded in these tables must be specified as part of the protocol definition.
6. Reports. Feedback and analysis of protocol effectiveness and outcomes.

We have defined data tables with the fields needed for describing all protocol components. Development of data entry screens for setting up and defining protocols and their components are nearing completion. These screens are being developed using the Delphi application development language.

In the prototype each time a triggering event occurs, a set of data to track all prescribed actions, relevant events, outcomes, and variances is initialized. This set of records may include patient demographic information, and historical data. It is set up to simplify the tracking, and facilitate comparison and analysis of outcomes in other instances when protocol was triggered. It also allows the system to function in situations where the information on how or where to find all needed data is not available.

Every field definition in a data table can optionally contain information on the location, file name, file format, file key, and query condition of data that can be used to automatically fill in the appropriate information. This is the basis of the means of linking specific data elements to data from software that is already in place at any particular site. Protocols themselves can have data gathering scripts, which can run several queries and automatically fill in much of the information needed for tracking. Data Links through scripts or definitions will greatly improve the efficiency with which protocols are triggered and monitored, but they are optional, and can differ from site to site.

During the term of the Phase I grant a major shift in information technology occurred. This shift was driven by the acceptance and possibilities present by the popularity of the World Wide Web. The Web Browser has become the focal point of the desktop due to its power to integrate voice, e-mail, sound, images, and data into a single window in a platform independent application. This greatly changed the way in which information could be handled. Add to this the trend toward managed care and HMO's and virtually overnight the ability to use TCP/IP based solutions, i.e.: Web browsers and servers, to fill the need to share information in the medical community between hospitals, doctors and with remote offices blossomed over night.

Our Phase I proposal was based on a platform and operating system dependent paradigm, restricted to local area networks or dedicated high speed wide area networks. Obviously the emerging platform independent, operating system independent, completely flexible wide area network paradigm of the Internet presented us with an approach that would be a far more viable solution and cost effective solution for all medical groups. Therefore we applied the goals of the grant to pursue a far more up-to-date and infinitely more viable solution.

We split our prototype protocol engine into separate components. We developed the protocol definer as a Windows application. With this protocols can be setup and defined from any PC. The other components of the protocol engine, the event monitor, rules enforcer and message handler were written and compiled to run as background processes on a Unix based Web Server. We also converted our DOS based medical package, ck_Medical to a Unix based package. This means that we can use our product and our Phase I prototype over any TCP/IP link. We can serve the emerging managed care networks and HMO that are built from a collection of practices and doctors anywhere in the community or the world. Managed care groups in one part of the state, or in separate states, could easily build a virtual organization with consolidated billing and protocol control.

As part of our survey of medical software developers we found an innovative company, MedRecall, with a patient record Web Browser, Web Server based solution to data sharing. This system creates its own SQL database of information from a variety of differing networked sources. Lab data is gathered through a connection with hospital mainframes, clinical notes are captured from word processing files transmitted by transcriptionist, patient demographic data, and limited billing data from regularly scheduled office billing package reports. All of this data is accessible via the Netscape Web Browser to physicians, staff and administrators from any location and computer with complete platform independence. Already the doctors have used this system to better manage patient plans as new drug reports indicated either potential problems or benefits as well as to find candidates for certain medical drug trials. The next steps for MedRecall were to find ways of more formally allowing users to define sets of rules, guidelines and watch-points, and achieving real time and full data integration with a medical billing package so that the full power of their approach could be achieved. For our protocol development work, having access to a system that automatically collected and compiled lab results, and which would allow us to easily e-mail chart notes to referring physicians, gave us a platform on which actions which were dependent on particular lab results or which required transmission of latest notes could be handled automatically without user intervention. Such a platform could provide a very persuasive demonstration of the full power of our concepts. Working together offered tremendous advantages for both parties.

Each protocol occurrence will instantiate another copy of the object complete with all data related to the trigger, activities, milestones, and dependencies that make up the protocol. Though it seems redundant, concept is critical to portability. Every protocol monitored event maintains its own data set. That way, whatever it doesn't get by automatic means it asks for. Just because it can't automatically get specific data in a certain environment, it will still be workable.

The Event Monitor has been set up as an application which runs on the same system on which the Web Server is located. Whenever visit information is entered into the medical package, that package outputs a copy of the data being put in an encrypted format to a file with a specific name and location. The event monitor sits scanning a particular area of the computer looking for files with this type of name, as soon as it sees one, it reads it, determines if a triggering event has taken place, by comparing information sent in the file, with the list of triggers defined by the protocol definer. If nothing that needs monitoring has happened, the event monitor will simply delete the file. If a triggering event has occurred, a data structure for recording and monitoring all data associated with the triggers and prescribed activities is created. Data from the temporary file that served as the notification is copied into the new structure, and then the notification file is deleted. Every action or event described by the protocol that has just been triggered will be treated as an object, and so each one will have an associated data set created describing the task to be performed, when it should be performed, who should do it, when it should be initiated, any dependencies on other tasks being completed or initiated, etc.

The Rules Enforcer is another component of the engine. It reviews all actions that are in the queue, where they are sorted by starting time. Development on the prototype is currently underway to enable it to automatically implement very simple versions of the following tasks to help carry out actions defined by protocols.

1. Take control of a particular PC or terminal and display a simple informational message. Using the same techniques of getting control under Phase II we will expand functionality to display a hypertext document with links to provide more reference information, or display a data entry screen which will request that the user fill in additional information that the system needs to gather about this patient or his treatment. This allows us to execute actions that provide users with context sensitive and immediate reminders, and display appropriate reference information. Users can also be asked to fill out forms in which they provide additional information about the patient, confirm that particular actions or events required by the protocol have been performed, and if not indicate the reason for the variance, by choosing one or more entries from a predefined list, and optionally adding their own notes.
2. Look for appearance of a particular document with specific information, most commonly a lab result. Based on location and name or extension of file, and information that can be found within it at a certain position. Alternately look for the appearance of a certain kind of data on the Web server.
3. Automatically send e-mail to other providers, case managers, or staff members, to which documents such as lab results or chart notes can optionally be attached.
4. Print formatted forms such as routing slips, with instructions as specified by the protocol definer. Also automatically print certain reports for specific users.

Our Phase I work has laid a solid foundation that should be continued with Phase II funding. We have defined all critical elements of a system that will enable both large and small organizations to standardize and improve their quality of service while monitoring patient outcomes and costs. The protocol engine is being developed for a rapidly expanding and technologically exciting environment where it can be implemented easily and flexibly throughout an organization, immediately have an impact on improving the quality of service, and play a major role in the industry's effort to increase its efficiency.