Objective 4. Development of a Windows prototype which will work either as an independent application or as an add- on product, and will demonstrate the definition and implementation of the highest priority protocol types.

Once the design phase of the work is nearing completion, we will begin the development of the prototype using either Visual Basic Professional Development system, Computer Associates Visual Objects, or Visual C++.

We will create a complete implementation for one or two of the protocol types deemed most critical for implementing in desk top health care software, using data from a single source.

We will take an appropriate section of the windows version of our medical package, ck_Medical, and set it up to make calls to the protocol engine Event Monitor, to see if protocol triggering events have taken place, and to get and act upon task lists, when they have.

The major programming effort will come in creating the following data entry screens or functions (since some of the terminology may be a little vague, we have included brief examples):

PROTOCOL DEFINER: We will create tables, scrollable lists, and entry screens to define and manage the following information:

Events. An event can be anything that we can define as a change in data, or status. Time since last visit, change in work status, new diagnosis, and purpose of visit can all be categorized as events. Each event will need to be given a data definition listing all data which is necessary to indicate its occurrence, the tables or files in which the data is located, the fields that must be added, deleted, or changed to specify the event, and any relations between fields of data stored in different tables.

Processes. A process is a task definition in terms that a computer can act on. This screen will accept descriptions and definitions of all software tasks listed in a protocol, and of the format of information that will have to be passed to the message handler when the Event Monitor sends it information regarding a set of tasks that are called for by a protocol

The following examples illustrate some of the differences that need to be dealt with in converting rules to tasks which a computer will implement. A simple rule such as:

• Administer 2 Tylenols to patient

may need to be transformed into the following series of instructions:

• Flash message: "Administer 2 Tylenols to patient" on Visit Clinical Information Screen.
• Add same message to Treatment Notes section of the encounter form, then print the encounter form.
• Add 2 Tylenols to list of medications administered.
• Before saving visit information, have operator confirm that 2 Tylenols were administered.

In other words, the software must be designed in a way that will help the user laying out the protocols to break up the task into all of the components that will actually need to be performed by the computer. As was the case with the protocol triggering events, each task described needs to have the capacity to include one or more data definitions and event descriptions.

The following list shows the types of processes into which protocol rules will need to be translated for computer implementation.

• Display or flash message or instructions on the computer screen at an appropriate time.
• Add instructions or message to a form.
• Prompt the user to enter specific information.
• Prompt user to execute and complete a task on the computer.
• Print a form, letter or document.
• Scan specific parts of the database to ensure that required criteria are met.
• Create an electronic message that either will be scheduled to appear in a staff member's E-mail at an appropriate time or will prompt the system itself to perform some other task automatically at the appropriate time.
• Transfer information to or from another system.

Data Access. These definitions will give the protocol engine the information it needs to use data from other software systems. Information will include lists of all tables in which data is stored, the format in which the data is stored, field identifiers for all data in each table, relations between tables and the key fields which can facilitate data searching.

Protocol Types. The prototype will be set up for one or two protocol types or categories. Diagnostic related protocols, visit purpose protocols, examination result protocols, are examples of three protocol types. Others will be added in future development. Each protocol type definition will include a list of events that need to be checked to see if conditions to trigger a protocol have been met. A visit purpose protocol type may be set up to examine the following events and/or conditions for triggering conditions: new visit has been added or purpose of visit has been changed, check patient's employer, check patient's insurer.

Protocols. A Protocol type may have many protocols that are associated with it. Each protocol has a specific set of conditions that trigger it, and a set of tasks that should be implemented as a result. For each protocol in a visit purpose protocol type, here we would specify that when the purpose of the visit was for a preplacement examination for company XYZ, we would want the following tasks carried out. For the same type of exam, when the insurer is ABC, we might require a different set of tasks. When there is a different reason for the visit, we would specify other tasks.

EVENT MONITOR. Write functions which will receive a message that an event has taken place, or is about to take place, then scan protocol types, to see if this event may trigger a protocol, and specific protocols, to see if all required conditions have been met. Other functions will create message for message handler, using event, process, and data access definitions.

MESSAGE HANDLER. Write functions to add, retrieve and delete messages as described in Objective 3.

RULES ENFORCER. Write functions to 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, as described in Objective 3.