BRMs and Healthcare AI-Partnering for Success

Too often, healthcare professionals and healthcare IT divisions find themselves in conflict despite having nearly identical goals of improving patient care, reducing burden on providers, and providing care to patients at lower costs.

This is particularly evident in attempts to use artificial intelligence to provide better patient care and reduce burden on caregivers – but why? What makes AI different?

The cultural narrative around artificial intelligence in healthcare has created a terrifying dichotomy in which AI simultaneously will replace medical professionals by providing more care than humans, but also harm innumerable patients by providing worse care than humans and creating artificial barriers to care. Neither, of course, is strictly true, but these fears loom large in many discussions about AI implementation in healthcare. Additionally, the AI regulatory environment significantly lags the technology, leaving hospital systems to create governance criteria for themselves.

The technology’s capabilities and clinical needs are not always well matched, and the hype and cultural conversation around AI’s capabilities are often overblown. In this article, we will discuss some common challenges to implementing AI in healthcare and illustrate how the role of the Business Relationship Manager, or BRM, can smooth this path to implementation, through a hypothetical project idea and evaluation process.

But first, what IS the role of the Business Relationship Manager? Philosophically, the business relationship manager role is any role that leverages positive relationships to increase value in their organization. This role, often filled by a certified BRM, maintains relationships with key leaders on both the clinical and IT sides. One of the BRM’s main functionalities is to connect IT-related project ideas (and those that have them) with processes for evaluation and implementation resources. A good BRM will be a trusted advisor/strategic partner to their clinical leadership, and a respected voice for the clinical “customer” within IT.

The BRM role brings special expertise to these conversations since they are familiar with both the clinical workflows and the technical requirements of the IT division. They can speak fluidly with both providers and technical teams and help navigate implementation processes. A good BRM will advocate for responsible innovation, hold teams accountable to adhering to process, and ensure that the value proposed by new technology is realized.

The BRM has brought their clinical workflow knowledge to bear on the problem described, understanding that inbox messaging flows from providers as well as the patient, and clearly documenting the increase in pajama time as an issue for providers.

The BRM has also used their technical knowledge to remove the vendor’s promise that implementation will take 30 minutes and substituted instead several reality-based criteria for evaluation. Finally, the BRM has identified an additional governance group that will need to weigh in as this project is evaluated. With the assistance of the BRM, this healthcare AI project has avoided early common complications of poorly scoped problem, poorly defined value and early rejection by IT groups.

When the BRM communicates their efforts back to the requesting provider, the conversation shifts quickly to frustration with the process. “Why do we have to have all this extra information? I already gave you the solution,” says the provider. The BRM explains the intake and evaluation process and illustrates the value of a thorough evaluation prior to implementation.

Luckily, the BRM has contacts at another institution that has just paused their pilot of an AI message bot due to its inaccurate message suggestions. This anecdote helps underline the importance of the evaluation process to the provider. They’re not happy about it, but they understand. Although frustrations with process are not unique to AI projects, the novelty of artificial intelligence can complicate routine evaluations, as we’ll see in the next few steps of our hypothetical project evaluation.

Now that the project has a more detailed scope and proposed solution, the next step is to bring the proposed project to IT for evaluation. In this example, IT has regular evaluation meetings where all IT teams can ask questions, detail the work their team would need to perform to complete the project, give estimates of the time it would take, and approve moving the project forward. Getting this project on the schedule is no problem, and when this project comes up on the agenda, several of the teams have follow up questions and comments.

Some of these questions are routine for any technology implementation within a healthcare IT environment. However, some of these questions highlight ethical and philosophical concerns unique to AI. Questions about unintended consequences of large language models – “what if patients hate the messages and we actually spend MORE time messaging” can be recast as metrics for evaluating pilots. Questions about strategy, such as “should we pilot AI in such a patient-facing space or in a more internal area” are worthy of further discussion outside the format of the project evaluation process.

The IT division agrees to defer a decision about whether to proceed with a pilot until the BRM brings back some additional information. The BRM will not be able to generate all this information on their own. Gathering this information requires assistance from technical teams, the clinician, the vendor, and an assist from a business analyst or project manager with standardizing documentation. This takes time, and during this information gathering process the BRM is keeping the requesting clinician informed about progress as well as providing regular updates to the IT division.

When the requesting clinician reaches out to the BRM to voice impatience with the process, the BRM knows that part of the delay is that the AI Governance Board is still being spun up and is not yet formally meeting. The regulatory environment for healthcare AI is still forming, leaving hospitals to create their own governance structures and criteria. Our hypothetical hospital is doing well – they’ve seen the need for a governance board, and identified a few people to be on it, but the governance process is not yet formalized, another common problem in healthcare AI.

The BRM brings the clinician directly to the proposed members of the AI Governance Board to advocate directly for their project. The clinician and BRM co-present a few slides clearly describing the problem and the proposed solution. The clinician’s emotional description of the time spent responding to messages, paired with the BRM’s neatly-written documentation of the proposed pilots to evaluate an AI tool to help providers avoid burn out, resonates well with the Board.

They decide to approve the project and ask that the clinician come back to present interim results from the pilots once the Board is formally meeting. The BRM is asked to provide a list of evaluation criteria for the pilots so that any similar cases that come before the Board can be measured by standard metrics. In this case, the BRM has used their relationship skills to avoid a long delay while a governance board is formalized and helped create standard evaluation criteria.

After this discussion, and the additional information provided by the BRM, the IT division approves moving forward with the pilots. Contracts are drafted, success metrics set, and the pilots begin. The BRM and requesting clinician stay involved throughout the process, ensuring that standard metrics are used for each pilot, and that the clinician’s desired result – less time spent composing messages – remains the goal. When the pilots end, the BRM brings the requestor and IT division back together to jointly give opinions on which pilots should continue, terminate, or expand. Finally, reporting metrics are handed off to the appropriate support team, and the BRM continues to confirm that the implemented solution is performing as expected.

Without a trusted partner to bridge gaps in IT processes and advocate for incoming ideas, projects and innovations can stall, especially innovations involving novel new technology such as artificial intelligence.

AI can overpromise results and is often seen as a universal solution for problems in healthcare IT. Those problems must be carefully defined if real value is to come from implementing a new technology. A new AI solution for healthcare should undergo scoping and requirements documentation so that it can be evaluated and prioritized by both IT and the clinical area.

The BRM role brings essential knowledge and relationships to this documentation, evaluation, and prioritization process. A good BRM will possess strong clinical workflow knowledge – including strong enough relationships to facilitate shadowing clinical workflows by IT team members and to generate powerful narratives to advocate for innovation. They will also have basic technical knowledge, including relationships with other institutions that have implemented similar technology.

A BRM role will bring an ability to bridge communication gaps and hold both sides accountable to the evaluation processes, including governance evaluation, success metrics, follow ups, and post go live evaluations. With a good BRM, the road to innovative, safe AI in healthcare is much smoother.