May 2023: Emergent use cases for transparency-in-coverage data
Utilizing Transparency in coverage data for consumers and providers
I previously wrote about the transparency in coverage data.
Consumer use cases
I think there’s 4 distinct categories of use cases that will emerge on top of this data: I’ll focus mostly on the consumer and provider tools for now, and do the rest in the future. In addition to consumers and providers, I believe it unlocks tools for employers and payors.
Use Case 1: Price Transparency for simple procedures
The most obvious use case (and I think the intent of the regulation) was to make prices legible to consumers. You might think this doesnt matter if you’re insured, but more and more consumers are on high deductible plans, so knowing that the provider they’re visiting is lower cost, ultimately means they pay less directly out of their pocket. In addition, one of the largest sources of phone calls we get at Carbon Health is patients calling in to verify with us, whether we’re in network with their health plan (they’re calling us, not checking their payor directory). For simple services where quality exists within a narrow bound (such as flu shots, simple diagnostics like STD tests etc), you really do want to be able to price compare. We’ve built some tools for this at Carbon, but these data will enable a much better experience for patients.
Enabling price transparency will manifest in several ways:
Tell me which providers are in network with my plan, for a specific service. This alone can reduce costs in healthcare by reducing the odds that a patient ends up somewhere that is not in-network with their plan.
Tell me how this provider ranks vs. others on price generally (regardless of my insurance plan) or in my plan (based on other similar providers in network): you can imagine creating a price index that a user can use when searching for a specific service. Ultimately this can enable a patient to find the cheapest place to go for a specific service, which is literally impossible today
For families who have primary and secondary insurances, this can help you really figure out where to go to get the most bang for your buck: families sometimes have multiple plans they’re insured under. Being able to find providers who are in-network on both plans reduces your likely out of pocket spend for that specific service.
If this works as intended, providers who are generally lower cost will win more patients over time (at the standardized end) and (on applicable services) more and more providers will need to systematically reduce their prices in order to attract patients. We previously already built a way to price compare for flu shots if you’re paying out of pocket. The transparency in coverage data will enable the same thing, but for a patient’s specific insurance plan:
Use Case 2: Specialist Access
Very often when you need a specialist, you don’t know if that specialist is in network with your plan until they have your insurance and have run an eligibility check. This is super inconvenient because very often, your provider refers you to a specialist who clinically might be great, but is completely inaccessible to you unless you’re willing to pay a high out of pocket cost. This results in the provider making a referral, the patient discovering days later that the provider is out of network, and then the patient going back to the provider to ask for a new referral, and this pattern repeating itself and often resulting in either wasted days, or just the patient never getting connected to the specialty care they need.
Because these data are at plan level, you could theoretically create a tool which shows a patient a) who are all the specialist providers in-network for that patient’s plan for that specialty, and b) what their relative costs are. Historically your PCP would at best know which specialists are contracted with your insurer, but your insurer likely has thousands of plans. Now your PCP can know exactly which specialists are in network with your exact plan, and what they cost for the procedure you’ll likely need. Cascade Health has built tools for this, and will expand over time.
Use Case 3: Plan fit
This use case was inspired by the recent propublica article (https://www.propublica.org/article/unitedhealth-healthcare-insurance-denial-ulcerative-colitis) . Here’s how it would work
We pull your claims for the last year
We find all payors who are in network with your providers, procedures and prescriptions that you did over the last year
We calculate the plan that if you had been a member, would have yielded the lowest overall cost for the exact same set of services you consumed in the last year, and filter for
Exchange plans
In your state
Nearby employers
And we give you a menu of plans to pick from
This use case could also be extended to people considering switching jobs
You’d pick the new employer
We pull your claims for the last year for your entire family
We tell you, for all the plans that employer has,
Which has all your providers in network
what last year would have cost in terms of total bills for each plan
Provider Use Cases
Use Case 4: Am I In Network with that plan?
New plans emerge all the time, and while you might be in network with (for example) United PPO, you might not be in network with the United HMO. This can result in a patient having to seek care elsewhere, or seeing a patient and having their claim denied, only to foist a large bill on a patient who might have done the same procedures elsewhere for a much lower out of pocket cost. The compound effect of dealing with the denial, patient dissatisfaction, and ultimately not getting paid, drives a ton of administrative cost in healthcare, which ultimately drives costs higher. Early on at Carbon I thought it might be possible to extract in-network status from the real-time-eligibility response (which providers like us use to just verify the patient’s insurance), but it’s simply not there.
Use Case 5: Are my doctors credentialed with that plan?
A sub-part of the in-network use case is credentialing - it’s often the case that even though a clinic is in network with a particular payor and plan, a new doctor in that clinic is not yet credentialed with that plan. This means a patient coming to the same clinic might previously have received care in-network, but could have their claims denied this time around because they’re seeing a different doctor.
Fast growing healthcare providers that are hiring new clinicians very often will have a period of time when a clinician is seeing patients, but they are not yet in-network with that insurer. We’ve experienced this at Carbon. In this case, if you submit a claim, the payor’s very likely to deny the claim (because as a “practice” you’re in network, but the provider is not, and this screws you and saves them money). In addition, payors use manual/async processes to notify provider groups that specific clinicians are in or out of network. As a result, you’re stuck either
Submitting claims that have a high likelihood of being declined
Holding claims till you’re aware that the provider is in network (which lags)
(the time between applying for a provider to be in-network, and that being approved and the provider group being notified can be up to 3 months)
All of these inject waste in the system; the 3 month lag time increases the working capital burn of the provider group, as does the process of working denials and tracking in-network providers).
Knowing which providers are in network (and falling out of network) in an automated way can help reduce the administrative burden, currently mostly carried by humans. Services exist to facilitate this already, such as Verity, but all rely on an incredible amount of manual overhead.
Lastly, the in-network use case can help a provider understand how many plans they are in-network with in their region, which can drive the decision on which new plans or payors to focus on.
Use Case 6: Contract Streaming - programmatically create payor fee schedules
One obvious use case is using the public data to discern exact contract rates in near real-time (updated monthly). Many key parts of a revenue cycle management platform require the platform to be aware of the provider’s contract rates with every plan you’re in network with. Having this data enables providers to
Understand if they are being underpaid or overpaid for a specific service or appointment by comparing the actual payment for that service, to the contracted rates for that service
Forecast revenue for services already provided with much greater precision
Provide price transparency to patients and enable them to know, prior to the visit, exactly how much they will owe inclusive of their copay, deductible and coinsurance
Today, this workflow involves breaking down contracts manually (usually handled by humans doing data entry, either in house, or outsourced to a low cost geo) and transcribing their contents into tabular format, and uploading it into a contract module. By utilizing the transparency in coverage data, you could stream contract rates directly into a provider’s contract module with minimal human intervention. Done right, it’s simultaneously faster than being done by humans, higher precision, lower cost, and enables you to tell when something weird is happening. One way to implement this would be as an app for large RCM providers like AthenaHealth - you could automatically create fee schedules for providers and stream them right into the Create Fee Schedule endpoint.
These are just a few emergent use cases I see coming down the pike off the transparency in coverage data being published. I expect to see more and more use cases emerge as tools get built to help patients, providers, employers and payors get their arms around these data.