SBAR: A Useful Tool in Healthcare IT

Healthcare IT and pharmacy informatics can include many different aspects of issue resolution and follow-up. There are many tools that can be used in pharmacy informatics to help make these processes more approachable and understandable. One such useful tool in informatics is the SBAR, which most often used by nursing but can also be applicable in the healthcare IT space.

The SBAR is a communication tool that stands for Situation, Background, Assessment, and Recommendation. There are potential benefits in using this tool in informatics because it allows you to jump right into analyzing the issue focusing on solving the problem rather than going through a possibly convoluted discussion on where to start.

S: Situation

The situation should be a concise statement that refers to the problem at hand.

B: Background

This section provides all the information that is related to the current situation at hand. It includes any problems or scenarios that was leading up to the discovery of the situation, and it can also include current-state information and how it is problematic.

A: Assessment

In the assessment section, this is where the situation is being analyzed and the different options have been reviewed. The goal of this section is to provide a succinct rationale for what is believed to be a viable option to move forward.

R: Recommendation

The recommendation section provides a clear suggestion on what the next steps are. This is where you provide your recommendation based on what has been reviewed and analyzed, considering the different advantages and disadvantages of each of the options.

Other Considerations

One thing to note is that SBAR implies that you need to follow the acronym in order, but that isn’t always necessary. You can still utilize this tool out-of-order, especially for the assessment and recommendation phases. If a recommendation is made that is found to be insufficient for the needs of the organization, you need to iterate back to the assessment phase for a new recommendation. The fluidity of the SBAR is what makes it useful.

Incidents vs. Requests

Within information systems, there are two major types of tickets that would come through: incidents and requests. For incidents, these are usually in the form of something that is broken and it needs to be fixed. For requests, these are usually enhancements or new functionality that is requested to be implemented. Using an SBAR is useful for both of these types of tickets. Here are some examples for SBARs on incidents and requests.

SBAR Relating to an Incident

Situation: The provider is unable to place an order for Duoneb.

Background: Duoneb was approved on hospital formulary last month. Patients have been being admitted with active orders of Duoneb, and they are expected to continue their Duoneb in the hospital. It’s been found that the providers were unable to perform a medication reconciliation to continue Duoneb in the hospital despite Duoneb being approved to be on formulary. Patients were forced to switch their respiratory medication or they had to use their own home medications in the hospital.

Assessment: Duoneb was built in the electronic medical record and the pharmacy system, however the visibility of Duoneb was not completely configured. In addition, formulary restricts Duoneb to be used in only patients who are already on it from home meds.

Recommendation: Configure Duoneb to be visible for CPOE but create required fields that will make it necessary for providers to identify that patients have already been on Duoneb for home meds before providers can proceed to order the medication.

SBAR Relating to a New Request

Situation: Some reports are coming in that providers are manually calculating weight-based dosing incorrectly and leading to incorrect doses dispensed for the patient.

Background: Providers can place mg/kg orders, but since the EHR did not have system calculations enabled, providers needed to manually calculate and enter the absolute dose into the EHR. As a result, several reports came in to the Medication Safety Committee noting incorrect calculations for weight-based dosing leading to underdosing or overdosing the patient.

Assessment: The EHR has the ability to automatically calculate the weight-based dosing. Benefits are that this would be more systems-reliant and less provider-reliant, allowing the system to remove a potentially erroneous step for the provider. The drawback is the change in workflow and the reliance on the weight in the system being continually updated and accurate.

Recommendation: Enable the weight-based autocalculation in the test domain and have key providers test the functionality. If deemed appropriate, have the rest of the hospital trained to ensure weights are accurate in the system at all times when the preference is turned on in the live domain.

For more information about SBAR, check out the following resources:

Check out more blog posts from our contributors here.