Purpose and Scope of Project

Protocols, critical pathways, and clinical guidelines are sets of conditions, actions and rules that set guidelines for the delivery of health care. When presented at the time of treatment, protocols can greatly improve the quality and cost effectiveness of health care. Current protocol software is not flexible enough to be used in diverse health care settings and does not work effectively with existing medical software.

CK Software, Inc. (CKSI) is designing a prototype of protocol software with the features and flexibility to meet the rapidly changing needs of the health care industry. An innovator in the solution of health care software design problems, CKSI received a Phase I SBIR grant to research the needs of the industry and the design requirements for protocol software to function as an effective tool for physicians, staff, managers, and payors. CKSI's "Protocol Engine" design has the following features:

• Allows users to define and customize protocols to meet the specific needs of the organization.
• Scans data constantly for conditions that indicate that a triggering event has occurred, then alerts users and initiates the actions defined by the protocol.
• Accesses data from other medical software packages.

Under a Phase II SBIR grant CKSI is proceeding with the development of a prototype protocol engine to be set up in one or more clinics and integrated with a wide range of data sources.

Changes in technology since the project began, specifically the rapid growth of the Internet and Web technologies, have opened up a new, viable, and exciting platform for the protocol engine. On a web environment the application can be accessed by virtually any type of computer system that is running a Web browser such as the Netscape Navigator. Hardware, location, and access to a high speed network connection are no longer limiting factors. In this environment our package will:

• Empower health networks and managed care organizations to set uniform standards of care and have them monitored and applied at all offices in their group.
• Decrease liability by providing access to all patient records, regardless of the location where they are physically filed.
• Be cost effective by working with data and software already in place.

This implementation will demonstrate the viability of our products as a commercial application that will be a valuable tool for health care clinics, insurance groups and other health software vendors.

Definitions of Terms

We use the term protocols to refer to all attempts to use computers to help apply structures, rules, or guidelines to the delivery of health care. Critical Paths concentrate primarily on making activities more efficient. Clinical Practice Guidelines concentrate on the appropriateness of medical decisions. Clinical Protocols are concerned with which are the best methods to use. Standard Order Sets which combine some elements of all in a way which still maximizes flexibility. In a computer implementation, these forms of rule making have many common elements. All have specific events or situations in which they become appropriate. We use the term protocol trigger, or triggering event to refer to these situations. All attempt to either propose or require sets of actions. All stress the importance of regular feedback and analysis of variance from the rules in order to refine and improve them.

Critical Design Elements

Timeliness, flexibility and analysis of variance are critical factors in the successful implementation of Protocols. Rules, guidelines, or care plans have to be available to the provider at the time decisions are being made. Plans have 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 needs to become the basis of charting, rather than an added record keeping burden. Variances from critical paths need to be monitored, analyzed, and used as the basis for future modifications.

• Protocols cannot succeed if their use substantially increases staff burdens, workloads or documentation requirements. To insure staff acceptance, protocols need to reduce documentation requirements.
• Activities are the most complex part of protocols. In order for a system to meet the likely needs of a wide variety of users, users must be given the ability to describe a wide range of activities.
• Variances, their description, follow-up and analysis play a critical role in the ultimate effectiveness of protocol implementation. Their documentation cannot be too much of a burden for users, must be an integral part of care documentation (charting by exception), and must be used to refine protocols.

In order to meet the critical design requirements, we have organized the way we will store and structure protocol information in a way that will provide users maximum flexibility.

Every protocol has a triggering event, a predefined set of actions, and (optionally) a set of outcomes which can be measured.

Events and Actions are the basic building blocks of the Protocol Engine. An event defines a condition that we can measure or evaluate by scanning data or reviewing information sent in a message. An action is a task that needs to be performed and involves activity on the computer's part to complete the action, to monitor or to measure whether the activity was accomplished. The methods that we are developing to handle events and actions will give our system tremendous flexibility and power.

In order to allow users to define their own events in ways that the computer can easily interpret and act on in an environment with multiple data sources, we have defined the Expression Class. Our methods to evaluate user defined expressions, which will work with diverse data sources and allow users to define and pass their own parameters, will be critical to the usability, usefulness, and portability of the Protocol Engine.

To allow users to define actions with a great deal of specificity we have designed the Protocol Activity Class. A protocol can designate many activities, who will perform each action, when it will be performed, how many times it will need to be repeated, what the anticipated outcome will be, and how it can be measured. In order to streamline documentation and follow up, it will also be possible to define a list of likely reasons for why any activity was not performed or an expected outcome achieved.

To make rule definitions, we will allow grouping protocols so that a standard definition can be inherited from a particular protocol type and then easily modified.

Our design also includes specifications for components which handle:

• Variances and the ability to branch to new protocols if certain activities are not completed;
• Tracking of all occurrences of triggering events, and the actual outcomes of all protocol defined activities;
• Data Gathering for warehousing or centralization;
• Data Access to multiple data sources with differing formats.

Internet Demo

In order to illustrate, test, and deal with the 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 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 update it on the web page.

The demo has four components: a data entry application, a rules definer, an event checker, and an enforcement agent.

The data entry application and rules definer present a very similar interface to the user, which 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. 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. We use a small screen for the data entry application, with buttons that either present drop-down lists, or open pop-up dialogue boxes from which criteria can be selected. This allows messages that appear in the web browser to be completely visible, and emphasizes the concept of even being able to run this in environments where we have virtually no access to databases. A "Protocol Tool Bar" will have minimal impact on the data entry load, but can be used to quickly check off critical criteria, and get immediate feed back on rules, have correct forms printed, or send email notifications to specific individuals.

The event checker is a web server application which receives data, determines whether a triggering event has occurred, and if so sends back messages to the computer on which the local data entry application resides. Since the text of the rule file is saved in Hypertext Markup Language (HTML) format, the file may include one or more embedded links to other web sites which contain appropriate technical, medical, or instructional information.

If the server does not find an exact match between the visit criteria and the rule triggering event, it collects a list of all rules that have criteria which partly match, and do not conflict with 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 but workable approach to data independence

This first phase demo was designed primarily to test and illustrate interaction techniques between a local application, a web server, and a web browser and, as such, has simplified many of the design criteria we have identified as being critical for our ultimate application. However, 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. Once we modify this application so that any organization or health care alliance can setup their own categories and check off items, we will have a working application that can be filled in with minimal additional effort by users. With this approach we will have a product which is immediately available, and that any organization can immediately deploy at all of its sites, after setting up a single web server.

Growth and Development Path

While the demo does not have the sophistication and complexity described under Prototype Design Specifications, what it has done very well is illustrate the power and immediate applicability of a simple, data independent concept. By adding the following improvements to the demo, we will have an easy to use 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.

• Provide organizations with the ability to define their own check box categories and labels, and list elements.
• Improve rule definition by adding other logical operators so that triggering events can be defined with more complexity and sophistication.
• Allow multiple action sequences to be defined.
• Merge context sensitive information into email messages that are sent as part of the rule action sequence.
• 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.

A Protocol Tool Bar with the improvements listed above would be very useful to many large organizations and alliances, and the immediate help that it could provide would more than make up for its limitations. We will proceed with these improvements to the tool bar so that we have a product that can be put in place while we deal with some of the more complex elements of the design specifications.

Our development path will then proceed to tasks required for the full featured engine, which will also add functionality and utility to the tool bar.

• Background Data Access. New products for monitoring all of the most common SQL databases make our goal of being able to independently access third party data sources much more achievable.
• Messaging System for third party applications to send data directly to the protocol engine, so that responses will be immediate, and not even require entry in a drop down tool bar.
• User interface. The demo has illustrated the importance of having a simple user interface. Most users had no problem setting up a few rules. On seeing alerts that they had set pop up at the right times, they came away favorably impressed. For the full featured protocol engine where rules definition will be much more complex, we need to develop a multi-level interface, where all but the most technical users would be able to set up rules without needing technical assistance. A presentation of simple predefined 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 trained or technical users.
• Security. The demo begins to deal with security issues, but a more sophisticated system will be critical as soon as we have a product that organizations will be looking at seriously.
• Server / Browser Notification Techniques. We will need to work with options other than the normal means of contact between servers and browsers where the client initiates all contact.

Conclusion

We now have in place a two track development path with exciting possibilities. Our Protocol Tool Bar can rapidly be improved into an easy to use but very useful and marketable application that will be an immediate, low cost solution for many rapidly growing healthcare alliances. As we proceed with the development of the full featured and sophisticated Protocol Engine, we will be able to add value and functionality to the Protocol Tool Bar, and test the efficiency and effectiveness of our work in active and working environments.

Our proposed solution will allow a virtual network of medical data users and providers to function as one contiguous entity. Our methods will insure the fastest access to information and a way to insure that the correct protocols reach the user. Our methods will allow tightly controlled access to the data as well as a means with which to gather, process, and display information in a timely fashion using existing hardware with the barest minimum of personnel training or support.

Our method maximizes cost effectiveness by using well known and familiar software like the Netscape Browser, and Netscape's integrated POP3 e-mail client. Connection costs are reduced by the use of standard telephone lines and all information is distributed from a web server having a look and function with which users will already be familiar, dramatically cutting re­training costs.

The combination of features and benefits thus achieved should be of interest to a large proportion of the health care industry, thereby achieving our goal of overall increases of efficiency and reductions in costs and liability claims.