Objective 3. Detailed design of Protocol Engine specifications, including operating requirements, data definitions, and trackable event descriptions.

In our model a protocol engine will be made up of:

Protocol Definer to help the user to properly configure protocols.
Event Monitor to determine if an event for which a protocol is defined has taken place, and, if so to send task lists to the message handler.
Message Handler to control access to information about tasks that need to carried out.
Rule Enforcer to scan data for rule violations.

The design work will focus on defining the specifications for how these modules will work, interact with each other and with external programs. More detailed descriptions of the functions of each of the elements follows.

PROTOCOL DEFINER. This module will contain the key elements that will allow users to truly customize their use of protocols. It will include the ability to define an unlimited number of care management "events". Each event will be linked to data definitions to indicate what changes in the data constitute the event, so that the system will have the information it will need to independently detect it. A protocol type will be defined by the combination of events and status descriptors that make up the critical elements for triggering it. This module will also need the facilities to allow the user to enter the rules associated with the protocol, and then convert those rules to tasks that the computer can implement. The successful or unsuccessful completion of those tasks can be treated as events in their own right, so that other protocols can be based on them.

The processes themselves will need to be defined, so that at the time it is asked to execute them, the system will have available to it all information it needs to complete the task.

EVENT MONITOR. This module will be designed to be called by external packages, and will provide primary link between the external package and the protocol engine. Before the actualization of any "event," the Event Monitor will receive information from the external package in order to see if the event and its associated data satisfies the conditions needed to trigger a specific set of tasks. If so, the Event Monitor sends to the Message Handler one or more messages that contain instructions describing each of the tasks to be accomplished in order to implement the protocol's rules. Information for each task will include the schedule for performance and the name or names of those with primary responsibility for confirming that the tasks are completed. The Event Monitor will also assist the calling program with protocol enforcement, by letting it know, if the event in progress can be allowed to go to completion.

The Event Monitor will also allow third party packages to enforce protocols on their own, by responding to a Checking for Messages Event. In that case it will build a query to the message handler, and return information to the calling program about any pending messages that it finds.

MESSAGE HANDLER. The message database will contain information describing all tasks that need to be performed to insure that standards are met for cases that are active on the system. Messages can be directed to particular users, or to the system itself. Messages will contain all of the information needed for the system to know what it has to do with the message, and the primary work in this part of the project will be to define how the message is to be formatted. The message handler will be designed to add messages to its list, retrieve them on schedule in response to Event Monitor or Rules Enforcer queries, and then delete them, once messages have been sent out and acted on.

RULES ENFORCER. This part of the protocol engine will work with any data sets for which protocols have been defined. It will run independently of any calling programs. Will use information in the PROTOCOL DEFINER to scan all data looking for conditions which do not meet rules, create messages, and then take actions which do not depend on other software packages, i.e. report of problems; messages to users. This will be set up as an open ended package, which can have a great deal of followup development for users of third party systems which are not setup to use the DLL, but whose data definitions are known. It will be possible to have it run concurrently with data entry packages, checking for the occurrence of triggering events, simply on the basis of new data that has been saved to disk.