Skip to main content

Escalation Process and Execution

Updated

Preconditions

  • A new patient record and service request (consult) were added.
  • User(s) were paired across applications (Solo®, QGenda and TigerConnect).
  • User(s) were scheduled.
  • User(s) received an “Alert” notification in their Messenger.

How it works

Once the user accepts the new service request (consult) in their “Alerts”, a new message will be sent to their “Inbox”, with the Solo® Consult Link. Users can click on the Solo® Consult Link to launch them directly to the service request (consult) in the Queue, Encounter or Service pages.

  • Accepting a service request (consult) stops the configured escalation policies.
  • Declining a service request (consult) immediately notifies the next configured user(s).
  • Ignoring a service request (consult) immediately notifies the next configured user(s).

In General Settings, if a user configures the “Decline/Ignore Protocol” to “Stop Escalations and Contact Decline Recipients”, and a user “Declines” a service request (consult), then the primary paths and steps are stopped, a Decline Path commences (if configured), and recipient(s) are notified.

If the primary user(s) in a configured step “Ignores” the service request (consult), then the secondary user(s) in a configured step are notified.

  • If primary and secondary user(s) in configured steps “Ignores” the service request (consult), then confirm the tertiary user(s) in a configured step are notified
  • If primary, secondary and tertiary user(s) in configured steps “Ignores” the service request (consult), then the user(s) in the next configured step are notified.

New Service Request Follow up Message to Provider in TigerConnect

Providers who accept a new service request (consult) in TigerConnect Messenger will automatically receive a follow-up message in their inbox containing a Solo® Visit URL along with relevant patient information.

After a provider user accepts a service request (consult) in their TigerConnect Messenger “Alert Box”, they will receive a second message in their “Inbox” (not Alert). The follow-up message will include the same notification text and a URL link to the Solo® service request (consult). Tagged data from the notification message will be included under the URL. The message will be labeled “Solo® Consult Link.”

NOTE: Admins do not need to configure the URL in the notification text. The system will automatically include it in the follow-up message.

Follow-up message example:

Unassigning Provider(s) from a Service Request

When a provider or another user “unassigns” a previously assigned service request (consult), the service request becomes available to notify other providers in the practice. This ensures service requests (consults) are efficiently managed and reassigned according to the configured escalation policies.

If unassigned, the configured escalation policy will resume, notifying recipient(s) in the next configured step of the Path according to the policy.

Once all configured steps of the policy are processed, or if there are no other steps configured, the policy will stop after the last step of the path unless the client configures the path to restart.

Note

An escalation policy can be configured to be executed from Path 1 to a Decline Path1.

P/N PL016213.A