Rhapsody Health Solutions Team

Payer Workflows: Prior Authorization Support and Payer Coverage Decision Exchange

August 4, 2020

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


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.


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 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.


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.


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

Melanie Medina

The role of state, regional HIEs in TEFCA

Healthcare organizations should become involved with local HIEs and lean on your EHR and interoperability vendors for guidance in TEFCA participation.

Read more
Generative AI, semantic interoperability, precision medicine and other themes from HIMSS23

Evgueni Loukipoudis

Generative AI, semantic interoperability, precision medicine, and other themes from HIMSS23

Read our key takeaways from HIMSS23, including perspectives on artificial intelligence, semantic interoperability, and patient matching.

Read more

Brie Hilgers

Health equity hinges on healthy data

Access to clean, actionable data is the key to health equity initiatives. Data integration, normalization of terminology, and data enrichment enable healthcare leaders to more accurately evaluate the social, economic, and physical environments that impact a person’s health.

Read more