Preconditions

• Client must have an integration with their external notification’s application.
• Clients must have an integration with their external scheduling application.
• Users must be paired between Solo®, Notifications and Scheduling applications as mentioned above.
• Users must be scheduled in the clients scheduling application.
• A Solo® Practitioner Admin user role is required to pair users.
• Emergent, ambulatory and asynchronous service requests (consults) are supported, while Virtual Sitter service requests are not supported.

Creating an Escalation Policy

1. Navigate to Users Profile > Practice Settings > Escalation > Create Escalation Policy
2. In General Settings add:
   • The “Policy Name” of the escalation policy you are adding.
   • “Service” associated with the escalation policy.
   • Set the “Decline/Ignore Protocol”.
   • Select if you want to “Restart the escalation policy when it ends”.
   • Select if you want to “Also notify providers for incoming shifts”.
3. Customizing name of Path 1 > Pencil icon > Edit Path 1 name > Apply
4. Add “Who to notify” using the type-ahead in the dropdown.
   

   • You can create one or multiple “Who to notify” steps in an escalation path. The number of paths is limited to 5 and the number of steps is limited to 10.

   • See Integrating TigerConnect and QGenda for more information on task-syncing with QGenda

5. Add the Response Time Allowance (in minutes), which is the amount of time that elapses before the next step.

   • Clicking on the “Trash” icon will remove the “Who to notify” step.

6. Add custom messaging in “Notification Text” by adding available Tags.
   • Make sure all required field denoted by an asterisk (*) are completed prior to the next step
   • See below about adding Smart Note fields as tags to Notification Text
     
     Configured “Notification message” example:
7. Click “Create” to complete the set-up. Click “Cancel” to discontinue creating a new escalation policy and changes will not be saved.
   NOTE: You can create one or multiple escalation paths with different recipients and notification messages

Linear Escalation Policy with Decline/Ignore Protocol

Administrators can configure an escalation policy with Decline/Ignore Protocol set to “Proceed through Paths.” When this protocol is set, the following occurs:

• Instant transition to subsequent steps once a provider declines within the primary Paths.
• Accept and decline buttons maintain visibility across all Path steps in the client messaging tool.
• Parallel processing across multiple paths; a decline in a Path triggers subsequent steps in Path 1 and additionally configured concurrent paths.
• Unaffected continuity for concurrent paths if a user chooses to ignore a step within Path 1.
• Trigger of a new escalation policy step upon user’s decline button action, persisting the button in the UI for reference.
• System-generated browser notification to inform users of a service request (consult) declination.

Restarting an Escalation Policy after the Policy Ends

An admin can restart the escalation policy from the beginning after it processes the last step. This feature ensures continuous attempts to address a service request (consult) until a practitioner accepts the service request or the maximum cycle limit (10 cycles) is reached.

Escalation Policy Restart Options

Automatic Restart

Once all “Who to notify” steps in an escalation policy have been processed without a practitioner accepting the service request (consult), the policy will automatically restart from Path 1, “Who to notify” steps.

Immediate Restart

If the last step of the escalation policy is configured with zero-time allowance, the first step will begin immediately after the last step ends.

Configuring Restart Options

A configuration called “Restart the Escalation Policy when it ends” is located under General Settings. A checkbox is located under the Decline/Ignore Protocol options to enable or disable this feature.

NOTE: The default setting is OFF.

When ON, the escalation policy will continue to execute, process, and restart for up to 10 cycles.

Error Messaging for Unsynchronized Tasks between an Escalation Policy and QGenda

Admins are promptly notified within Solo® when a task synced with Qgenda is deleted or becomes unsynced, enabling swift action to maintain the integrity of escalation policies and uninterrupted notifications.

Upon deletion of a Qgenda-synced task, Solo® will display an error state below the affected step in the corresponding escalation policy.

The error message “One or more tasks have been revised in your scheduling tool. Review and resync.” Alerts administrators to the task deletion, prompting them to take corrective action in Qgenda to avoid disruptions to notifications and potential impacts on patient care.

Error message:

Adding Smart Note fields as tags to Notification Messages

Client administrators can request the Teladoc implementation team to incorporate Smart Notes fields as tags in escalation policy notification messages. This ensures that providers receive comprehensive patient information, empowering them to make informed decisions regarding service request (consult). Providers will receive notifications enriched with additional patient information, enabling them to render decisions effectively.

Note about Delayed Tag Application:

• To ensure tagged data is included in notification messages, a 5-second delay is implemented for each service request (consult) creation. This accommodates variations in data availability depending on the method of service request (consult) creation.
• If there is a change in the JSON template at the service level, then the tags will disappear from the escalation policy notification messages and will appear blank in the provider’s message.
• If a service is removed from an escalation policy, then the then the tags will disappear from the escalation policy notification messages and will appear blank in the provider’s message.

There is no error message to indicate tags will be removed from escalation policies if the JSON template is removed from the service.

To implement this feature, contact the support team. They will update the JSON templates with the required JSON configurations.

P/N PL016212.A