A guide to designing protocols in Corti: Using logic to control the flow of Triaging

In essence, a logic expression is a statement written using variables and operators, following a precise syntax. The statement will then return either a true or false value. A true value will continue the flow, while a false value will not. When creating your logic gates you have some choices in both what input you use and how complex you make the expressions. Here are a few things you should keep in mind when creating logic for your graph.

When to use and not use true in logic gates

If you use true in a logic gate it will force a true state for that gate. This means that the user will continue down the protocol path regardless of what action they took in the node - even if they took no action at all. This can be both very helpful or very problematic depending on what you are trying to accomplish.

When to use a true expression:

• If you just want to present information to the user.
• If you want them to proceed down a certain path regardless of a selected option.
• If you want to make sure the user is always able to continue on the path chosen.
• If you want the user to be able to skip the view node when triaging.

When to not use a true expression:

• If you want the user to select an option before continuing down a protocol path.
• If you don’t want the user to be able to skip the view node when triaging.
• If you want the selected option to affect the protocol navigation.

The order you write your logic gates in matter

Logic gates are evaluated from top to bottom. In the below example since true is the second from the top the bottom two logic gates will never be evaluated. You NEVER want a true gate to appear before other logic gates.

You can also make a logic gate on a select block that allows multi-select. Keep in mind that the order you arrange the gates will affect the flow.

In the below example we’ve accidentally put a logic gate for a low priority symptom before a high priority symptom. This means that if the patient is both bleeding to death and light headed, they’ll only be treated like they are light headed.

We can fix this by re-ordering the logic gates or combining them with [light headed || bleeding to death]

Using complicated logic with “$”

You can make very complicated logic gates that will make graph navigation much smarter. Be aware that building such logic expressions is time intensive and prone to human error - so only do so when it offers a significant improvement for the end users and is unlikely to require much maintenance.

Examples of when to use complicated logic

• When the option selected should result in a split within the protocol flow.
• If a certain combination of selected options should trigger a specific view node to appear. This can both be options that include; [x and y] or [x or y].
• If the lack of a selected option should trigger a specific view node to appear.

When possible, cluster your most complex logic in as few nodes as possible so that the logic doesn’t need to be maintained in multiple locations.