A monitoring plan is a collection of rules that specify how information related to the care of the subject should be processed by the system.

Each rule within the monitoring plan contains 2 logical parts:

1. Trigger – What causes the rule to become true
2. Actions – What should happen in the event of the rule being true.

The process then of building a monitoring plan involves determining what events you want to watch for and when that event occurs, what you want the system to do. You describe the events of interest as Triggers and you specify what the system should do through the actions you associate with the trigger.

Example Monitoring Plan

Let’s learn a bit more about monitoring plans by opening up an example plan and dissecting its parts.

Below is a screen clip of a very simple minded monitoring plan. This plan has a name (COPD Monitoring Plan – Simple). The plan also has a small collection of events (about 7) that are of interest in the plan. When you display the monitoring plan then, you’ll see the plans name and the list of triggering events specified in the plan. You can also click on the “Assignments” and see for which of your subject/patients the plan is in effect

Let’s take a look at one of the events of interest… specifically, let’s look at the event whose triggering action is “Pulse Ox <= 90.000%”. I can see more information about that event by clicking on the Revise button next to the event description.

Clicking on Revise next to the event in the monitoring plan brought up a page named Plan Item Detail. This page allows us to examine in more detail exactly what is being monitored with the event and what actions should be performed when the event is detected.

At the top of the page in the Trigger section is a description of the event that would be used to trigger the actions listed below. In this case, we are assessing the arrival of a discrete measure of pulse oximetry. The trigger indicates it should fire if the value received is <= 90.

Below is a list of actions that will be performed then if a patient being watched by this monitoring plan ever submits a pulse ox value of <= 90. In this example, we see a number of actions that will be completed by the system including:

1. Notifying the care team with a high level alert message that the event has occurred
2. Sending the subject a message that will appear on their iDevice about the measure
3. Starting a task in the task system of type “Alert: Pulse Oximetry” and assigning that work to the person playing the role of Care Coordinator for the patient.
4. Adjusting the overall value of the healthcare for the patient by 100
5. Sending a message to the patient’s care givers that the value has been received and may be out of line.

Each event allows you to configure the rules about the event in the “Trigger” section and each event may have 0 to many actions that should be done by the system when the event occurs.

Triggers

Setting up a trigger involves selecting a kind of triggering event that should be assessed along with rules about how to aggregate data and compare data of the event to determine whether the triggering event has occurred.

1. The name of the triggering event being assessed
2. Data aggravation rules regarding the event data
3. Classifications of data related to the event
4. Comparison information

There are a large number of event types that can be assessed (at this writing, there are over 200 event types). As you select an event type to assess, the system will refresh the display showing just those fields that might be required for describing the event of interest. It will also present a brief description of the event type to ensure you’ve selected the correct event directly below the name of the event you choose to assess.

In our example, the triggering event was the arrival of a measurement. The actions went along with describing what to do when that measurement arrived. In our example, the actions weren’t meant to be run based on the arrival of any measurement. Rather, the actions we’ve composed are specific to handling discrete values of pulse oximetry and more specifically, those that are less than or equal to 90%. It’s within the trigger area that you define those rules.

Each event type has it’s own required fields and when you set the event type, the fields refresh to match those of the event type. For example, in the following screen clip, we are looking at an event of a diary entry arriving. The diary entry arrival event lets you specify what to look for in a diary entry to decide whether you want to take action.

Notice that different from the measurement arrival event, the diary arrival does not allow you to specify a measurement type…that wouldn’t make sense. But it does allow you to add a comparison of the diary entry containing the worlds “hard time sleeping” and taking action when those words are seen in the entry.

Notice also that the actions listed for the diary entry event are different. The actions specified with this alert are related to the diary entry. If someone says they are having a hard time sleeping, this alert will enroll them in a text bank motivation collection that will send messages throughout the day about how to prepare yourself for a good nights sleep. It also assigns a book to the user to allow them to read up more on good sleeping habits. These actions make sense based on the event… the user is indicating they have a hard time sleeping so the system gives them material to help. No action was required by the care team so no tasks were created… the system handled all actions for the care team itself.

Actions

Actions are the steps you want the system to take when an event fires that matches one of your triggers. There are a large number of actions available that you can use. A triggering event can run any number of actions you’d like the system to perform.

You add an action by tapping on the “+” button next to the word Actions. When you do so, the Add an Action display appears.

Since there are a large number of actions to select from the actions are categorized together. First you select the category of the action, then you specify the specific action to perform. In the following screen shot, you can see that the action category is Notify and within the Notify category are all of the actions that have to do with notifying someone. In the example below, we are using the action of “Tell Subject” which sends a message through the message applet to the subject.

Once we select our action, the system will prompt you for the parameters that are relevant to the action. The system also describes how to use the action and what the parameters mean in the “Options” help text displayed on the screen. In our example, we indicate that the system should send a message from the fictional character named ‘Dr. Nagenstein’ and that the message should be delivered as a regular old message and then we describe the message content.

The parameters on the action display, again, vary based on the action type, but also based on parameter settings. For example, if we decided we wanted to send an urgent message, we could change the message type to Announcement and in so doing, the system re-prompts and let’s us enter in a formatted message for display. It also allows you to set a URL that can be used as the announcement itself (including Youtube video clips). The point here though is to notice how the display changed based on the Message Type option being changed to Announcement.

There are a LOT of actions and new actions get added on a regular basis. The action categories as of 1/7/2020 are listed below. Note that if you do not know the category to choose, you can select All and then look through the longer list of all actions.

Here’s a partial list of the actions as of 1/7/2020.