In order to meet all of the design
requirements discussed above, we have organized the way we will
store and structure protocol information in a way that will provide
users maximum flexibility. First we will give a general overview
of the basic building blocks of the system. Then we will list
and discuss all of the separate classes, their components, and
the purposes and functions of each. Data concerning the rules
will be stored in tables which will be organized to have fields
which match all of the instance variables defined for each class.
In Appendix I we provide a detailed list of all components needed
for detailed rules definition with brief field and function descriptions
for each.
Events and Actions.
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. Usually, the definition of an action will have
elements defining who is responsible for performing the action,
the time that will be required, and what the objective of the
action is. On the computer, the differences between an event
and action are somewhat semantic, since in order to evaluate whether
an event has occurred, the computer must be performing an action.
It will also need to keep track of how often it has scanned for
particular events. But this will all be built into the system.
As far as users are concerned, events will be measured passively.
For our purposes we can say that in order to determine the occurrence
or non-occurrence of an event, a computer will be scanning data
that it is storing or has access to. An action will involve some
additional activity on the computer's part, and will require some
way to measure whether the activity was accomplished.
Expressions
An Expression is our term for abstracting
any instructions telling the computer to perform a task. What
we could also call events or status descriptors require a link
to an Expression which tells the computer how they need to be
evaluated. It is the way we will define every event, outcome,
or status descriptor in ways that the computer can act on. We
use the term Expression because for a computer an expression is
made up of a series of operators and operands. Operators are
things that compare or combine. Operands are the values that
get operated on, i.e.: compared or combined. Thus at its simplest
an expression could be a status descriptor, taking two operands
such as a patient's age, and a value of 30, doing a greater than
comparison, and returning a logical true if the patient is over
thirty, and a false otherwise. Expressions can also be far more
complex, and can include any number of operators and operands,
including previously defined expressions. In this way any triggering
event, outcome, or milestone can always refer to a single expression.
One way of handling expressions is
to link every expression to a compiled routine. Unfortunately
this would require that every time a user needs an expression
somewhat different from what is already available, someone has
to program what the new expression does. Another way is to provide
building blocks from which users can pick and choose, and into
which they can pass values, and in this way have the flexibility
of building their own expressions without reprogramming being
necessary. For example: the reason for a patient's exam is a
common criteria which determines prescribed sets of actions.
We could write a routine which will return a logical .t. if it
sees that the reason for the visit was to receive a Pre-Placement
Exam. Then we could write another routine which would check to
see if the reason for the visit was a work related injury. Obviously
after doing several of these we would want to have a single routine
that would check the reason for the visit, and then compare it
with some value which is passed as a parameter. This would allow
us to have a single expression, to which we could pass a constant,
and have it return a logical true or false. Additional discussions
of considerations for efficiently handling expressions are provided
in Appendix II. How we structure the definition, evaluation,
and execution of expressions will be one of the primary design
challenges of Phase II and beyond. It will have bearing to the
usability, usefulness, and portability of the Protocol Engine.
Protocols
Each rule or protocol is defined
by the following elements.
| Number. | Provides a unique identifier that can be used throughout the system to refer or point to the protocol. |
| Name. | Descriptive name for lookup purposes so that users will always recognize the protocol being referenced. |
| Type Definition. | Indicates the class of protocols that a specific protocol will be inheriting most of its attributes from. These classes of protocol types can also by user defined. It makes defining specific protocols a lot simpler, since most of the detailed information can be inherited from a more general definition, and then modified. Since the type definition also contains information about data files, it is used for increasing the efficiency of scanning for triggering events, since it may be possible to search for all triggering events of a specific protocol type in one pass through the data. |
| Trigger. | Definition of condition elements that must be present for the protocol to be activated. In our design the protocol trigger is actually stored in the Expression list. The protocol keeps a reference to an expression in the expression list which defines all of the details necessary to determine if a triggering event has occurred. |
| Activities. | A protocol can have any number of activities tied to it. Each protocol activity specifies an action to be performed, who will perform the 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. For each activity it will also be possible to define a list of reasons why the activity was not performed or the outcome achieved. |
| Outcomes. | Protocols can have multiple outcomes, each of which again points to a condition defined within the expression list. |
Protocol Components
We have stated that events and actions
are the basic building blocks of protocols. However, in order
to deal with many of the needs and complexities described previously,
our overall protocol engine design includes many other components.
We will describe them briefly here, and then define each component
in more detail in Appendix I.
Serve as templates from which specific
protocols can inherit many of their attributes. In this class,
protocol groups are defined in order to simplify the task of
creating specific protocols that belong to the group. Each individual
protocol will become an instance of its protocol type class and
be able to inherit the default triggering event, activity list,
outcomes, data sources, and tracking specifications defined for
the group or class. The user can then modify a few elements of
the protocol rather than having to fully define all elements of
the protocol. For example we might want to create a protocol
type for pre-placement exams that we do for any client company.
In it we could describe standard actions that would be performed
whenever someone came in for a pre-placement exam, what data would
be tracked, and in which files that data would be found. Then
whenever a user wanted to tailor a protocol to the requirements
of a specific employer, by selecting the pre-placement protocol
type, everything already defined for the class would be inherited,
and it would only be necessary to change or add specific prescribed
activities.
The elements of every protocol, including
the name, identification number, triggering event, activity list,
and outcome list are described above.
This class provides the system with
a list of all tasks that it is capable of performing, and information
it needs to know how to perform them. Every item in a list of
protocol activities will refer to an action in this list. The
action class has methods which initialize, perform, and close
actions.
An action is one of the basic building
blocks of the system. It is a task that needs to be performed
either by the computer or by an individual. When it is to be
performed by the computer, we need to provide enough information
so that the computer will be able to complete it. When it is
to performed by an individual, the computer can play a role in
scheduling the task, monitoring that it has been performed, or
checking data associated with or outcomes of the action.
Every event, milestone, outcome,
or status descriptor will be listed in the expression list. An
expression is a means of describing an event in a way that a computer
can interpret and compile for the purpose of rapid evaluation.
The conversion of events and status descriptors into an expression
list, is one of the levels of abstraction needed to make this
system portable to different data and software environments.
The protocol activity definitions
are the keys to making this system flexible enough to be used
for critical path definition, clinical practice guidelines, clinical
or treatment protocols, or standard order sets. Each protocol
activity links a protocol to a predefined action item. It also
put constraints on when that action needs to be performed, who
will perform it, if it needs to be preceded by other actions or
milestones, how often and at what frequency it needs to recur,
how it should be followed up, how to determine if it was completed
successfully, and what variances should be allowed to explain
why it was not performed or completed.
One or more variances can be defined
for any protocol activity. Because of the nature of health care
work, many prescribed protocol activities will not be performed,
often with good justification. For a rules system to be useful,
it must allow for this fact, and in order to facilitate the analysis
and tracking, make it as efficient as possible for users to acknowledge
that certain tasks weren't completed and explain why. The key
to doing this is to pre-select the most likely reasons that any
activity will not get completed, so that the majority of times
that this happens, a user will be able to select the reason from
the list that immediately pops up, if needed, add a few notes,
and then proceed with other things. It should also be possible
to indicate that if a specific protocol activity variance is selected
as the reason that the activity was not completed, this is a triggering
event that can initiate another protocol.
Whenever a protocol is triggered
an action tracking record is initialized. One of these records
is created for each activity included in the protocol. In addition
to recording the date and time that the activity was initiated,
this is where the system records when the activity was completed,
or if it was not completed, the reason or variance, along with
any additional notes.
The Data Tracking Class allows a
user to designate specific data to be gathered as part of any
single protocol activity. When a field identifier is used, the
system will attempt to get the data based on information it finds
in the Field Structure List, and any conditions specified in the
expression reference to help narrow down a specific item of information,
where there are multiples or some ambiguity. If no field or expression
identifiers are filled in, the system can prompt users for the
information.
The data access components serve
two purposes: they act as a layer between the Protocols or rules
and the data to which those rules will be applied. They provide
the descriptions which will allow the protocol engine to access
and examine data, and they provide the translations necessary
for a single set of protocols to function similarly on different
sets and types of data. Data Access Components include classes
describing data sources, data groupings, relations, tables, and
fields, and are covered in more detail in Appendix I.
| Home | ck_MedRules | ck_CompCare | ck_Medical | Grants | The Company | Employment | Request Info | Links |