Blog

Rhapsody Health Solutions Team

Payer Workflows: Prior Authorization Support and Payer Coverage Decision Exchange

Payer_Coverage_Decision_Exchange2
The finalization of the Interoperability and Patient Access final rule from the CMS has brought a new sense of urgency to data interoperability in healthcare, especially for payers participating in Medicare.

While the original deadline to comply with the rule was January 2021, CMS extended the deadline by six months because of the COVID-19 pandemic. The extension is helpful because it gives health leaders a little more time to ensure their organizations are technologically capable of delivering data where it needs to go via the HHS-specified standard, FHIR®.

If you’re not familiar with FHIR, we invite you to read some of our FHIR resources, including:

Meeting the requirements of the CMS rule will require more robust interoperability solutions that can accommodate FHIR APIs, bulk data transfers, message formatting and parsing, and other data-exchange needs. Yet as we work with our payer and health plan customers, we find that some are somewhat boxed in by their current technical capabilities and need tools to make these integrations easier.

In this blog post, we’ll explore how to make payer data exchange more efficient, and how an integration engine can improve data exchange between payers and providers, as well as between payers and other payers. We’ll cover two use cases that have been defined by the DaVinci Project: Prior Authorization Support and Payer Coverage Decision Exchange. (The DaVinci Project is a private-sector initiative aimed at helping payers and providers to positively impact clinical, quality, cost and care management outcomes.)

This blog post is based on our recent webinar, FHIR: 3 Real-World Scenarios.

Prior Authorization Support and the Role of an Integration Engine

John_Dough

Our example features John Dough, a 68-year-old male who works at a library. After many years of carting heavy books around, he has some back trouble. His insurance provider has authorized physical therapy for his condition. He also has cataracts, and his ophthalmologist has recommended surgery. Now he’ll need to seek authorization from his insurance company for cataracts surgery.

An interoperability layer, however, can automate the process and take the burden off of the patient.

prior_auth_support

In this workflow, John’s provider sends his data to his insurance company and requests authorization to perform cataract surgery. Assuming the provider has a FHIR repository, John’s data is bundled and sent to an integration engine where the message is translated to X12. The payer receives the X12 message and determines if the requested procedure is covered.

The process also works in reverse, allowing the payer to send the notification of authorization to John’s provider.

The benefits of Prior Authorization Support, a use-case defined by the DaVinci Project, include:

  • Improved accuracy – Less room for human error because the provider and payer exchange information directly
  • Improved efficiency – Neither John nor any provider or payer staff need to waste time on the phone or exchanging emails

Payer Coverage Decision Exchange and the Role of an Integration Engine

Payer Coverage Decision Exchange is another use case defined by the DaVinci Project, and it involves exchanging FHIR data between payers.

John_Dough_New_Job

John Dough changes jobs. He now works at a bakery and has new insurance. He’s worried that this change will cause a lapse in his physical therapy treatments and cataract surgery, both of which were already approved by his previous insurance company.

John may have to gather documentation to prove that he needs medical care. And he may have to pay out of pocket for treatments that his previous insurance company had approved.

Payer_Coverage_Decision_Exchange1

In this scenario, using FHIR, John’s new insurance company sends a query to his old insurance company, and requests information about John’s current treatments, conditions and diagnoses related to those treatments, supporting documentation, and any prior authorizations.

What happens if one payer has a FHIR repository, but the other one doesn’t? In these cases, an integration engine can be used for message filtering, conversions, customization, monitoring, and logging. Having an engine can streamline this process among multiple payers.

Payer_Coverage_Decision_Exchange2

This post covers only two among many use cases for an integration engine in a payer’s IT infrastructure. Have a use case you’d like to discuss with us? Just click the Contact Us button below, fill out the form, and we’ll be in touch soon.

For further reading:

Related Blogs

Rhapsody Health Solutions Team

ONC regulation is here: What you need to know

AI is driving new regulation from the ONC. Learn more about how the HTI-1 rule impacts healthcare technology development.

Read more

Rhapsody Health Solutions Team

How Michigan DHHS supports high quality data exchange with FHIR

Discover how Michigan's Department of Health and Human Services optimizes modern data exchange with Rhapsody

Read more

Shelley Wehmeyer

Manage versions and workflows with improved visibility and usability in Rhapsody Semantic 15.3

Learn about the latest enhancements of Rhapsody Semantic including namespace versioning and FHIR code system version support.

Read more