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:
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:
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.
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:
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.
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.
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 retraining
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.
Home | ck_MedRules | ck_CompCare | ck_Medical | Grants | The Company | Employment | Request Info | Links |