The purpose of this page is to give you the best conditions for setting up and building a protocol from scratch. These insights are based on experiences working with different protocols across our customer base. Some of the tips/tricks may be more useful to you than others. So feel free to use the guide to the extent you desire.
Tip: Before starting any protocol editing work make sure you only have one tab open within the protocol editor, and that no one else is making changes in the protocol simultaneously. Failure to do so may results in lost protocol work.
You will always set-up your protocol within your home branch. This will form the basis of your protocol, and will be the starting place for all calls. You could, in theory, have your entire protocol within the home branch. However, to ensure the structure of your protocol is easy to edit and manage, the best practice is to organize all chief complaints/case types/incident types into separate branches.
Tip: A good home branch is characterized by including a high-level overview of the different call categories answered by your organization e.g. is the call a referral from 911, field staff, or did the patient call directly to your command center? To collect detailed information on the content of the call, it is recommended to use portal links that link to new branches.
Besides adding separate branches, good suggestions include;
- Using portal links to create links between branches. You can use portal links across your entire protocol to link to view notes in other branches. This makes it easier to avoid very long protocols within a single branch.
- Avoid using the same combination of view nodes across many different branches. The view nodes represent the individual Engage cards that instruct the call taker on what to ask, and offer options for actions to take, or for selecting or writing the right response to a question. Only create new branches with view nodes when the flow requires the call-taker to select between different options.
Best practices for using components
Your can save a view node as a component, if you want to use it multiple times across your protocol. Using the same components enables you to;
- Update information on the same view nodes across all protocol branches. This means the change you make in a single view node is reflected across your entire protocol (If you wish to change information in one place, while not changing all components, make sure you change the component to a normal view node).
- Reduce the workload of creating additional view nodes with the same information.
- If a user changes branches during a call, any information saved within a component block will be pre-filled, when changing to a new branch.
Remember: all the components will need to be renamed in the component library before they can be reused.
Tip: If the content of the view node is the same i.e. a multi-select option but you want the title of the view node to be different, use the same component with a different “paragraph block” for the title.