- Overview
- Resources
- Transcript
Speakers
Ryan Stastny
Product Manager, MuleSoft
Description
In this demo, learn how payers can leverage MuleSoft Accelerator for Healthcare to develop FHIR-based APIs and streamline the prior authorization process. This video follows the scenario of a fictious patient awaiting authorization for a medical device. It explains how healthcare payers can use this release to authorize similar claims in a fraction of the time.
| Ryan Stastny (00:07): Hello, and welcome to a demonstration of the MuleSoft Accelerator for Healthcare prior authorization use case. Ryan Stastny (00:15): Before we walk through the demonstration of MuleSoft's capabilities, we wanted to first share some of the challenges of the prior authorization process that we've heard from our customers. First, the process tends to be very manual and requires a lot of back and forth between the administrative teams on both the provider and the payer sides. You'll see a representative example in today's demo where there are a number of steps that could be streamlined through a modern approach. Second, the technology used to support this process is quite dated with the interactions happening between the different parties via phone or fax while the technical integrations are based on the legacy X12 standard, which has limitations of its own when it comes to supporting modern experiences. These challenges lead to delays in care delivery. And in some cases, patients may forego treatment altogether due to the excessive amount of time this process can take. With this backdrop, let's dive into the demonstration and learn more about how MuleSoft can help transform this process for the better by improving both patient experience and provider-payer relations. Ryan Stastny (01:22): For this demo, we'll be discussing a fictitious patient, Vlad, and a recent encounter he experienced. Vlad is a male in his mid-60s and has recently been diagnosed with diabetes. After receiving his diagnosis, doing some research online, and consulting with friends and family, he's determined he would like to request a home blood glucose monitor in order to track his blood glucose levels from home. During his most recent visit with his physician, Vlad requested this device. His doctor explained that before Vlad can receive the device, his doctor will need to submit a prior authorization claim with Vlad's insurer to determine how much of this will be covered by his plan versus out of Vlad's own pocket. Ryan Stastny (02:06): Now let's look more closely at a representative workflow depicting the steps associated with this process today. As mentioned earlier, Vlad meets with his doctor and requests the home blood glucose monitor. From there, his doctor calls his insurer and shares the information he has collected. After reviewing the claim further, his insurer realizes there is some required information that was not captured in the original call, so the insurer calls back and leaves a voicemail. When his physician is finally able to review his voicemails, he faxes the necessary documentation. And once the documentation is properly received and routed, the insurer is able to approve the claim and Vlad is finally able to receive his device. Ryan Stastny (02:57): As you can see, there are many manual steps involved in this process which can lead to unnecessary time delays in a patient receiving care. To alleviate the administrative burden on providers and to improve patient access to their health information, CMS is mandating new rules requiring payers to build APIs to support data exchange for prior authorization. Let's now look at a future state workflow powered by MuleSoft to automate and enhance this process as organizations prepare to adhere to the upcoming regulations. The workflow starts the same where Vlad requests a home blood glucose monitor. From there, his doctor is able to submit this request directly within his EHR and is prompted in real-time for all the necessary documentation. Ryan Stastny (03:44): This experience and integration are powered by the MuleSoft APIs that are provided via the MuleSoft Accelerator. The insurer then receives the request and is able to approve much more promptly. And lastly, Vlad receives his device in a fraction of the time. Some of the benefits of this solution and approach include that it is automated by nature, removing unnecessary iterations. The time to approval and delivery of service is minimized. And lastly, it enables the use of both existing and modern technologies. Now that I've walked you through the use case at a high level, I'm excited to show you these APIs in action. To begin, I'll exit presentation mode and head to a mock EHR interface that is a reference implementation provided by the Da Vinci Project where Vlad's physician will submit his prior authorization request and order this device. Ryan Stastny (04:43): First, acting as Vlad's physician, I will select Vlad as the patient. From there, I will select the home blood glucose monitor as the device that will be requested with this prior authorization request. Next, I'm ready to submit the prior authorization request. And immediately you can see that authorization is in fact required. As Vlad's physician, I then would check the documentation requirements associated with this device, which includes background, common reasons for denial, and best practices to avoid having my request being denied on Vlad's behalf. If I return to the EHR view, I'm now ready to submit the order form to Vlad's insurer. The order form launches a secure smart app that automatically populates key information about Vlad, his diagnosis, as well as the device that is being ordered through this prior authorization request. Ryan Stastny (05:56): After his physician confirms and validates the information, he's able to click next, which brings us to the final view where you're able to see the FHIR request that has been constructed based on the information filled in by the provider and is ready to submit to the API being hosted by Vlad's insurer to handle this request. When the provider clicks submit, he's able to see immediately that has been successfully submitted and await further response and approval from the insurer. Isn't it great how fast and easy this process was compared to the original back and forth associated with the current prior authorization process? Now that we've reviewed this experience from the provider standpoint, let's go to Exchange to see what resources are available to enable this workflow. Ryan Stastny (06:51): Anypoint Exchange is the marketplace for accelerators, connectors, templates, examples, and APIs. To access the assets provided by MuleSoft to power the experience we just walked through, click the MuleSoft Accelerator for Healthcare tile in the provided by MuleSoft view and exchange. As you can see, the Accelerator for Healthcare provides assets to help our customers accelerate their interoperability efforts. We have a number of use cases ranging from Patient360, appointment scheduling, as well as the focus of our discussion today, prior authorization. After opening this tab, you're able to review the documentation associated with this use case, including an overview, diagrams, and details associated with the use case. And most importantly, links to the assets themselves, including both API specifications and implementation templates. Ryan Stastny (07:50): Thank you for your time and interest in our capabilities and head to Exchange to check out these assets and try them for yourselves. Thank you. |
