| Class | Purpose |
| Protocol Type | This is the base protocol class from which specific protocols can inherit many of their attributes.
Data describing each element in this class will be stored in a protocol type table. 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.
A protocol type will have all of the same instance variables described for protocols. |
| Protocols | The members of this class will be every protocol which is defined and described. A protocol
definition consists of:
|
| Actions | This class provides the system with a list of all tasks that it is capable of performing, and the
information required 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. An action definition includes:
|
| Expressions | 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 abstraction 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. Each expression definition includes:
Appendix II contains a discussion about how expressions will be described and compiled. |
| Protocol Activities | 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. Each activity definition includes:
|
| Protocol Outcomes | Each outcome definition includes:
|
| Variances | This class maintains the definitions of all variances that can be used for either protocol
activities or protocol outcomes. Each variance definition includes:
|
| Protocol Activity Variances | 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. |
| Protocol Activity Tracking | 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 definition for each activity tracking
elements includes
|
| Data Tracking | The Data Tracking Class allows users 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 definition for
each data tracking element includes:
|
The following classes deal with accessing data. They act as a layer between the rules and the data to which the rules will be applied. On systems with diverse data sources, the set of data definitions used will depend on the data source. | |
| Data Fields | This is a generic list of fields to which all rule definitions will refer when they have to
refer to field information.
Each field definition will include:
|
| Data Sources | Maintains a list of all data sources available on any network. Similar information from different
locations may be coming from different local data sources maintained in table formats.
Each source definition will include:
|
| Data Groups | The data group class allows a series of related tables needed to evaluate expressions or perform
activities to be classified in a group definition. Any member of this class can then be referenced prior to
evaluating any expression or performing any action to insure that connections are in place to all data that
will be needed during the process.
Each group definition will include:
|
| Data Group Tables | Each member of this class contains the items that define tables that belong to each data group.
Each item definition contains:
|
| Data Tables | This is a list of all tables on the network on which data is stored and can be accessed.
Each definition includes:
|
| Table Field Structure | The full definition of each field or data element is contained in the members of this class.
This allows the system to enable users to build expressions based on the descriptions of the data field and table
rather than having to know the specific field names or identifiers. This list also provides the information that
the Protocol Engine will need to know how to evaluate expressions, and will allow protocols to be translated from
one vendor's system to another. Any field identifier referenced by an expression can have different entries for
each data source on the system.
|
| Home | ck_MedRules | ck_CompCare | ck_Medical | Grants | The Company | Employment | Request Info | Links |