Lyniate Blog

Insights and Updates From The Healthcare IT Experts

    Payer Workflows: Prior Authorization Support and Payer Coverage Decision Exchange

    Haya Husain
    Posted by Haya Husain on Aug 4, 2020 11:16:27 AM

    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:

    Contact Us

    Topics: Payers, CMS

    Blog Subscription

    Most Popular

    Post By Topic

    See all