June 2024: How to fix patient eligibility & registration

Healthcare needs mag stripes. Probably.

Many healthcare problems, both financial and otherwise, stem from the private payer model in the US. There are thousands of payers, mostly regulated at the state level, each with up to tens of thousands of plans. Each plan comes with it’s own policies about how claims are handled and disputed, contracted rates and contracted providers and rules about what they’ll cover and when. This model enables enormous customization, which is it’s main advantage. But the main disadvantage is it creates complexity that typically just results in providers not getting compensated for care they provide. It also makes it hard to tell patients what they’ll owe prior to an appointment, and even harder for patients to price compare. Both the dynamic where providers don’t get compensated, and the difficulty of comparing prices help drive up the cost of care. One way that complexity manifests is in the process colloquially called “eligibility verification” (what we call it at Carbon), “registration”, or “authorization”.[1] 

For the purposes of this essay, eligibility verification is the process of a) ensuring that a patient’s insurance is valid and current and b) confirming that the services the patient is about to receive are covered by the patient’s benefit. In the fullness of time, I think this can only be fixed by policy (because payors benefit from the current broken state, so have no incentive to fix it as functional eligibility will decimate their margins). In the short to medium term, if you’re a provider group or a care delivery organization optimizing your eligibility process, here’s some detail on the types of issues you might face, and how we approached them.

From what I can tell, there are 2 core problems with eligibility verification today:

1. Fundamentally payors do not want to pay providers. We can say a lot of words about regulating consumption, reducing cost, aligning incentives, narrow networks etc, but this single insight explains 90% of what happens in healthcare revenue cycle (and the rest of this essay.)

Source

2. In order to achieve #1, payors are heavily incentivized for the eligibility verification process (and many other things downstream in revenue cycle) to remain broken.

My point in #1 is not that payors are malicious. It’s that results reflect incentives, and payors’ ultimately are incentivized to be profitable, and a key way to increase profits is to reduce cost-of-goods-sold (COGS). To a payor, providers are (unfortunately) COGS. Without any inside information, I assume a payor is perfectly happy for a member to receive care from a provider, and for that provider to not get paid. The member is simultaneously healthier, the payor got the data, the service was cheap ($0), and the provider didn’t realize the service wasn’t covered until they didn’t get paid, and thus couldn’t direct the patient elsewhere.

I once interviewed someone who said that she ”was tired of working for startups trying to solve problems that only policy can solve”. In that spirit, the actual solution to eligibility verification (and a lot of the downstream problems) is to completely centralize it, or for all payors to be public (government owned). Both paths could solve coordination. But neither is happening soon. Given that, this essay outlines a bunch of the problems in the eligibility process today, a few ways to solve them based on some of the work we’ve done at Carbon and the unique data that's produced, and some insights our results have generated.

The Problems:

Today, eligibility verification (as treated by most providers and as sold by most clearinghouses) is a repackaging of EDI files provided by payors, into a combination of APIs, EDI files, & human readable web portals. For example if you went to check my eligibility for an Urgent Care visit in Waystar you would find:

It’s a human readable view of my covered benefits and cost-share details, organized roughly by the types of care I might receive. An easy way to visualize the start of the problem is to compare what my eligibility information looks like in Waystar (which we use as a clearinghouse) vs. Availity (which is also a clearinghouse, but in this context is used as the portal for Anthem CA).

The entirety of my Urgent Care benefit in Waystar:

And the same thing in Availity:

Remember, this is the same patient, just viewed through different web apps. The difference between the 2 is material; different copays and deductible levels depending on the place of service (and this difference isn’t visible at all in Waystar, and would only be human readable if the person doing registration bothered to log into Availity). 

In our case (for an urgent care/outpatient visit) the stakes are relatively low - average visit cost is in the hundreds not thousands of dollars. But imagine the compounding nature of this opaque behavior as the stakes get higher; either because you’re undergoing inpatient care or you have a chronic disease that requires many encounters.

The Plan

My basic insight is that most providers are actually trying to solve 3 or 4 separate problems when registering a patient and checking their eligibility [2]. The current EDI centered model is insufficient to cover a provider’s needs, the current toolset only partially addresses them, and to date they’ve been ruinously expensive to solve relative to the benefit providers would get. The problems are:

1. Is this patient a member of this plan on this date of service, is the service the provider is about to provide a covered service for the plan, and has the patient exhausted any specific plan limitations for that service (e.g., the plan only covers X number of PT visits in a year). EDI transactions only cover membership [3]

2. Assuming #1 is true, am I (as a provider) contracted with that payer directly, or am I otherwise “in network” (i.e. does the payor consider me to be a provider that they have a list of services and prices they are committed to pay for those services with)

3. Assuming #2 is true, are the services & procedures I’m going to provide to patient covered by their plan? Assuming #2 is false, are the services I’m going to provide covered under that patients out-of-network benefit (or in some other way eg with their employer)

4. Assuming #3 is true, what are the actual contracted rates for those services, what is the patient's financial responsibility, and what can I reasonably expect to get paid by the payor and the patient?

Most eligibility tools today solve #1. Fewer solve #2 (because it requires knowledge of the provider’s contracts). None solve #3 and #4, which is the reason why you walk out of most healthcare visits not knowing how much it costs overall and how much you specifically owe for that visit. Today, a human can manually solve all 4 problems (and you see this happen more often in outpatient specialty care like dermatology) but it’s fairly time consuming and sufficiently imprecise that no one’s really built a service around it. Even large companies like RevSpring and Phreesia don’t do all 4. 

A few things have happened over the last couple of years that can expand the definition of eligibility verification in healthcare to more closely match what patients think it means; that they can walk into a clinic and know they are in network, know the cost of the services to be provided, and know how much they’ll owe. Here’s how:

1. Utilize eligibility from 270/271 files (Everyone does this)

2. Determine if provider is in network with private or public contract data (Carbon doing this with private data)

3. Determine what CPT codes are covered with private or public contract data (Carbon doing this with private data)

4. Calculate patient out of pocket cost and estimate patient responsibility upfront (Carbon doing this, again with private data)

5. Standardize insurance card design and data exchange 

1. Combine EDI & RPA to enrich eligibility & benefit verification

EDI-based eligibility verification already happens today and is quite widespread with a going rate between $0.05c and $0.20c per electronic eligibility call. You can pretty much buy this off the shelf from Waystar, Change Healthcare, Availity, Trizetto, Stedi, Phreesia and many others. In addition, there are a few cases where EDI based eligibility is not sufficient by itself. For instance (using data going back to early 2022):

30% of real-time-eligibility (RTE) attempts fail. 

This number isn’t really all that useful, as it includes input errors as well. However RTE calls fail for all sorts of reasons that are not related to whether or not you have the real patient in front of you who genuinely needs care. RTE failures typically fall into 3 buckets:

• Identification Failures; eg incorrectly identifying the subscriber as the dependent, or vice versa, entering the wrong gender, or a typo in the address, name, date of birth, or member id

• Destination Failures: Sending the RTE to the wrong payor

• Downtime: Clearinghouse or payor failing to respond

We already have the technology to solve these problems, because credit and debit cards exist. Identification failures are solved by the mag stripe or chip; they encode information about the owner of the instrument and the instrument itself. Destination failures are solved by the network; you can pretty much put any payment card into any terminal at this point and be sure that the credentials will be checked at the right place (this isn’t 100% true but it is true enough that most people who have cards don’t worry about it). Downtime will always exist in some way. 

In our workflow, when an RTE call fails, the person entering the patient’s insurance has to re-enter the insurance twice before they can proceed. So 30% of the time, the front desk is re-entering data. This is wasted human effort that we’re all paying for, just for a patient to get seen.

After all the re-entries, that 30% number becomes 10% (basically for 10% of patients who use insurance, we’re unable to get eligibility electronically verified on the date of service, after multiple retries):

This is counting actual finished appointments where the responsible party was insurance, not just verification attempts. Going deeper in, it gets more interesting. On Sundays the failure rate is 20%.

Anecdotally, this appears to be driven by the Blues frequently being down (unresponsive to RTEs) on Sundays (RTE success rates for blues drop by 20% on Sundays, from ~89% to 66%).

Certain carriers are more reliable than others in terms of responding to RTEs:

All this is a long way of saying there’s a meanul amount of cases where RTE just does not work. Today, providers mostly solve this by having their front desk and registration teams log into clearinghouses  or payor portals to get access to patient eligibility data, and interpret what they see, or checking in a couple of days later. However, this degrades your system of record, because the human has to do data entry to make sure what they see in the portal on that day is recorded in the EHR/checkin system. On top of that, clearinghouses and payor portals are often lacking data:

• For some plans, the response is basically empty (as in the provider is told there’s a patient, but there’s no information about the patient’s benefit):

• For certain payors, the response is completely empty, and just says to call them or log into their portal to learn more. So now after logging into your clearinghouse, you ALSO have to log into the payor portal, just to verify the patient’s eligibility. All this time the patient is standing in front of you . . .

• For certain payors the response is fairly rich, but does not include sufficient cost-share information to enable the patient or provider to estimate the patient’s responsibility (we find this happens for about 22% of insurance visits)

All this is a long way of saying, as you design your workflow, some proportion of visits will require manual steps. For these cases, there are a few vendors that enable you to utilize Robotic Process Automation (RPA) to log into payor portals or call on behalf of the provider, retrieve detailed cost share & benefit information, and deploy them into your workflow. These include Opkit, Thoughtful Automation, Luminai, Substrate [4] and many others. This step isn’t critical for every single patient, but without it it’s pretty hard to have a complete view and serve all patients in the same high quality way. This whole process is really lossy; as you can imagine, in lots of cases this step doesn’t happen at all, leading to the provider either spending lots to get paid, or not getting paid at all. 

2. Determine if provider group, or a specific provider, is in network

This problem has a strange shape which is why it’s rarely discussed. Typically, physical world healthcare providers don’t grow that fast, and when they grow, they typically increase density in a single region or grow region by region (this drives the chatter about regional or super-regional monopolies). The result of this is that contracts can be known to a healthcare provider via tribal knowledge (ie the front desk can kind of know whether a particular Cigna plan is in network or not, just because they see a lot of Cigna patients). In addition, many front desks will have a literal physical binder that includes contracts the provider has, what the insurance cards look like, and if there are any plans that are known to be out-of-network. For smaller providers who’ve been around for a long time and are in a single region only, contracts can be decades old since last negotiated, meaning many plans launched since the contract was signed won’t be visible to the practice anywhere, even if they are in network (ie, the provider will only know they are in network because claims sent to that payor are paid rather than denied). 

For a fast growing provider group, or a provider group new to a region, there aren’t really any off-the-shelf solutions for determining explicitly if a patient is in-network. This is a problem because, since the provider group is growing fast they are negotiating a) lots of new contracts with b) lots of new payors in c) lots of new regions and potentially specialties. There are two ways to determine if a provider is contracted with a payor; using the provider’s contracts, or using public payor data released as part of the transparency in coverage regulation. At Carbon, we ingest & structure our contracts with payors to figure out if we’re contracted with a patient’s insurance, and can treat the patient as in-network. 

We do this with a lot of sweat and tribal knowledge decomposing the contracts into a contract administration module (in Carbon’s case we built it into our Billing Hub, but this can also live in the EHR or practice management system) which allows us, whenever a patient’s insurance is entered, to check whether we have a contract with the payor, what services are covered by the payor and what those services cost. Lots of EHRs & RCM systems have a contract administration module that enables clean forecasting (ours does as well). What’s new is using that contract data to estimate patient responsibility. The downside is that this process requires a human in the loop to break contracts down the first time and then to keep contracts up to date as they change (this is one reason I’m excited about the contract automation + claims reconciliation work Recon Health is doing)

The alternative way to determine if a provider is in network is using the transparency in coverage data. Payors are supposed to report this data monthly for every single contract they have in force with every single provider group in the country. It should include a) exactly which providers are contracted, and the negotiated rates for those services. This is initially what I thought we’d do (I even built some tooling to help break down the large files here). I believe in the coming years someone will productize these data to automatically flow into contract modules, and free humans from doing the work (this is an emergent use case of the transparency in coverage data that has yet to take off). The primary caveat (and main reason we haven’t gone this route); payors are required to publish this data or they face significant penalties. However, there’s nothing forcing them to make the contract rates accurate, and as a result I’ve yet to meet a provider or provider group that has been able to reconcile the TIC data to their own internal contracts, and I have multiple proof points that they’re simply inaccurate. Verifying accuracy is ruinously expensive, and my intuition is payors simply don’t care, because they’ll never be held accountable for correcting them (again, this isn't meant as a dig - in a world of limited resources one must prioritize and organizations fairly consistently put compliance actions towards the bottom of their priority list). 

3. Determine rates for covered services in that provider <> payer contract

This is an optional step, dependent on the service being provided. For instance, if a patient is going to an imaging center for a mammogram, it's important to know exactly the contracted rate for the mammogram CPT codes. Knowing this rate will enable the center to calculate how much that patient might owe out of pocket, and bill them for it on the date of service. In contrast, if you’re an urgent care provider, it might be sufficient to only know the office visit code range (as this will likely make up the bulk of the visit reimbursement). 

There’s 2 ways to determine these rates; first using private data, and second using public data.

Determining contract rates using private data

This involves utilizing a contract module to ingest, and create structure from a payor contract. At Carbon Health, this is the approach we’ve taken. It requires a human to retrieve required fields from the contract, and then for the list of CPT codes we care about, enter those codes, the eligible plans, the rates applied and which regions and TINs are applicable, into our system. Recon Health automates some of this process.

Determining contract rates using public data

I previously covered 3 provider use cases for the transparency in coverage data; #4 was checking if a provider is in network, and #6 was extracting negotiated rates for specific services. I still firmly believe someone will build this, and free us all from the tyranny of manually extracting rate data from contracts. Until then, using the contracts you have in house is sufficient.  [5]

4. Calculate patient responsibility up front

When all the patient owes is a copay, this is easy to do. At Carbon, we simply surface the copay amount retrieved from the patient benefit during check-in or utilize the copay amounts on their insurance card. There’s some nuance here as a patient might have multiple different copay amounts indicated depending on the type of service or whether their the covered individual or a dependent:

In our data set (outpatient urgent care and primary care) we’re able to identify a copay benefit for around ~55% of patients. When we encounter multiple different copay amounts, we pick the lower one:

I can imagine a ton of reasons why this rate might differ for different fee-for-service contexts, but the growth of high deductible health plans means that, for non-copay visits, the vast majority of healthcare providers in the US today are unable to tell a patient exactly what they’ll owe at the start of the visit. Because of this, they’re also not able to collect on it. The downstream implication is; very often if a patient has any residual balance after a claim has been adjudicated, the provider won’t have a valid card on file and will have to chase the patient down to get the patient responsibility paid.

The out of pocket calculator

On 2 recent occasions, I’ve noticed specialist providers manually doing this calculation. They’re taking the plan benefit details (co-insurance, deductible, out of pocket max, etc), the service being performed and calculating what they believe the patient will owe, and billing the patient on the date of service. Patients are happy to do this because they know they’ll owe something and they appreciate the transparency. For the provider it solves a few problems: accelerates cash flow, reduces working capital, reduces patient bad debt, and reduces A/R. For the patient they kinda know what they’re in for when they walk out the door, and don’t have the anxiety of getting a random paper bill months later. In the couple of occasions where I’ve seen this, whenever the provider overbilled (for instance when the payor covered more than expected), the provider simply sent the patient a check for the difference. 

At Carbon we built what we call the “Out-Of-Pocket Calculator” to replicate this behavior;  we’ve started estimating patient responsibility on the date of service wherever sufficient benefit details are available (deductible, out of pocket max, co-insurance etc).

1. We combine our contract rates with the accumulated patient benefit data (ie, using the amount of their deductible that is remaining/outstanding, rather than using their total possible deductible) to estimate patient responsibility. For this reason we run RTE checks every single time we’re checking in a patient so we have the most up to date benefit information.

2. During check-in, the front desk will run the RTE to get current benefit data (including their co-insurance, how much of the deductible is remaining, etc), talk through it with the patient, and then walk through the estimate. For certain scenarios (eg if the patient has multiple insurances) we just skip any future steps as it genuinely gets super complicated to determine what the patient responsibility will be after the claim’s been sent to 2 separate insurances.

3. We always assume the most simple thing (an office visit only with no procedures) when figuring out which contracted rate to use. This rate is combined with the patient cost share details to come up with the estimate.  We bill the patient for the estimated amount up front

4. After the claim is adjudicated, the patient responsibility might differ from the estimate for a lot of reasons. 

   1. If the patient's responsibility was less than the initial estimate, the system automatically refunds the patient to the card on file.

   2. If the patient's responsibility exceeds the estimate, the system automatically bills the patient for the balance.

As you can imagine, we try pretty hard not to overbill patients, so we’re extremely conservative in our estimates of what the patient owes. [6] Since shipping this in December 2023, we’ve only had to refund 5% of patients who receive an out of pocket estimate. 

Price transparency is one of the most useful tools for both patients and providers, yet is insanely difficult to execute well. If you’re going this route, ping me as I have ideas. Here are some of the inconsistencies you’ll have to work through when utilizing this data:

• Incomplete cost share information in a single service type (eg deductible and co insurance in urgent care the urgent care service type, but no stop loss )

• Nonsensical cost share details (eg a deductible that’s greater than the out of pocket max, or the remaining deductible in the total deductible field)

• Copay or coinsurance rates in the eligibility response/271 that don’t match the adjudicated amounts in the 835 files

• No cost share details on the insurance card or the 271, but cost share details present in the 835

• Differing cost shares for individual vs. family benefits

Our approach overall has been to use the most conservative cost share details possible to estimate the patient’s responsibility. I think this is why our refund rates are so low. But it would be far easier if the eligibility responses were just accurate + clear. 

Operational Considerations

To do this well, you’ll need to a) measure what is working vs. not, b) get those metrics into the hands of operators and clinical leadership who will c) design mechanisms to hold folks accountable up and down the chain. We’ve somewhat been spoiled because we have control of our technology stack; for most care delivery organizations, different pieces of functionality live across different systems so it falls to the front line staff to stitch things together and maintain context. I think the main items to design are

1. Metrics & Reporting: for every item you want to collect, how often is it being collected, and when it’s not being collected, where, by whom, and why? In our world, we require collection of; consent forms, payment cards, patient responsibilities, insurance cards, driver’s licenses (or other id). When someone skips collecting one of these items, they’re required to select a “Skip Reason”. Skip reasons are also tabulated and all these metrics are rolled up into reports that clinic managers and operational leaders review daily, and use to manage performance and guide coaching conversations

   

2. Scripting: ensuring that the front desk staff has simple, standardized language to talk to patients about their benefit and responsibility. This will differ between contexts (for example outpatient urgent care vs. an ER check in are probably 2 wildly different conversations)

3. Process: making sure these reports are directly embedded in the routine workflow for P&L owners. Insurance capture and patient collection are key to any RCM function, and the P&L owners simply cannot be best in class without managing this process pretty tightly

5. Standardize insurance card design and data exchange 

Eren tweeted a long time ago about putting a QR code on insurance cards:

Source

I think a QR code is a fine solution, BUT it masks a deeper problem which is that the insurance card is the primary authorization instrument for managing healthcare reimbursement in the United States, and every single health insurer in the country designs it differently. Many health insurers have different designs for different plans! For example, here are 8 insurance cards for Aetna plans alone (this is not exhaustive):

There’s no reason the front desk should be an expert in what field to read from the card and manually input where.

A standardized mechanism for exchange (for example, if every single insurance card had a magnetic stripe that could be swiped) would remove so much dead weight loss in the US healthcare industry. Imagine if every merchant had to manually enter your card number into the terminal before changing you? Thats what happens today in healthcare - every provider you go into is scanning + typing in your insurance details. An electronic method of exchanging payor credentials like a magnetic stripe, would reduce typos and registration errors, and ensure claims aren’t rejected for registration or eligibility issues. You could treat dependents like an authorized user of a credit card.

Consider this: you can walk into any merchant in the US, swipe your Visa or MasterCard credit or debit card, and the merchant knows exactly where to check to see if your card is valid , and knows before you walk out that you can pay (including tips!). In contrast, you can walk into a hospital, provide an insurance card, and at multiple steps along the way, the hospital can lose the ability to know where to send your claim. In fact, one core reason many hospitals require a patient’s Social Security Number is to make it possible for them to locate the patient post visit, if for some reason the front desk fat fingers your member ID, or your benefit comes up empty, or it turns out you have a primary payer that you didn't inform the hospital about. 

The lack of a standardized mechanism of exchange is literally costing every US citizen money. There are entire companies built around cleaning up the exchange process. And truly, they should not exist.

People complain about the cost of Visa and MasterCard as middlemen in the financial system. In contrast, the fully loaded cost of an actual transaction in healthcare is 5 to 10 times higher. Here’s a sample of what might be included

1. All-in cost of a Clearinghouse: 0.5% of collections (it’s priced much more granularly, but this is what it comes out to)

2. Interchange for card transactions: ~2% of collections

3. Bank Fees, Lockbox & Claims Reconciliation: 0.5% of collections 

4. Human cost: 3 - 5% of collections

This is why the going rate for using an outsourced billing provider like AthenaHealth or R1 RCM can be anywhere from 5% - 10% of revenue. Compared to this, Visa is cheap (in fairness this isn’t a perfect analogue - a meaningful amount of the cost of RCM solutions is to handle the human led adjudication process based on the codes in the visit, and these often cannot be known prior to the visit). 

Bonus

Coverage Discovery

During the pandemic, when COVID related tests, treatment and vaccines were mandated to be covered, patients had a perception that the government would pay. In practice the way it worked is, your insurance carrier was required to pay, unless you were uninsured. 

How this played out a lot of the time was:

1. Patient comes in, asks for something COVID related (ie a test, vaccine, paxlovid etc)

2. The patient doesn’t provide insurance, and the provider performs the service(s)

3. The provider submits that claim to the HRSA

4. The HRSA rejects the claim with a note that the patient already has valid insurance, and the provider should bill the patient’s insurance directly 

I remember at the time experiencing this and being absolutely surprised + certain that a service for discovering patient’s insurances exists, and we were idiots for not using it (beyond COVID, providers would use these to look up a patient’s insurance if they forgot it, or if a patient has multiple insurances the provider could verify the coordination of benefits so the claim goes to the right place, or for patients who are in an IPA, verifying which procedures could be billed to which payor). In going down the rabbit hole it turns out that there are a handful of services that payors use to do this, but the best, most canonical services that payors use, are not available for providers to use. I’ll leave you to draw your own conclusions.

As a provider group, you can use services like Zoll and TevixMD to fill this gap and do the patient lookup. Currently exploring these - will report back.

HSA + FSA Lookup

Patient cost share (copays, deductible amounts etc) are eligible medical expenses under section 213(d). For a variety of reasons, however, patients rarely pay using HSA/FSA/HRA accounts. Anecdotally from observing patient check ins, this is mostly driven by reflex - most patients at a clinic dont really want to be there, and are nervous/just trying to get their problem solved, and so reflexively reach for their top of wallet card (which logistically just cannot be an HSA/FSA card). 

This could be solved by building a lookup service on top of the main administrators of HSA/FSA cards. Using the lookup, a provider (or their registration service) would 

1. query with patient details to see if the patient has an HSA/FSA balance available, 

2. and if so, retrieve the balance,

3.  surface it to the patient, and ask patient consent to charge the balance.

4. Charge the balance for the patient’s responsibility up front, and true up after the claim has been adjudicated

This is literally better for everyone except maybe FSA providers; patients pay for care using pre-tax funds, providers get paid, it “feels” like found money to everyone involved, and HSA providers get interchange on the transaction. From what I understand FSA providers monetize more heavily on yield on patient balances and so aren’t as stoked about driving spend, but this is purely anecdotal. 

Trying to solve policy problems with technology

When we started exploring this area I mostly believed that there were good ways to solve these problems, and we simply weren’t aware of them. Now we’re in the middle of it and it's pretty clear that doing this well will require a ton of human sweat and effort that few providers can afford to expend. This applies both to finding the right technology to use, and changing staff behavior to drive consistent outcomes. 

As long as payors are incentivized to not pay for services, some version of this problem will exist (and a very similar problem extends to the rest of the RCM lifecycle, into claim rejections, denials, claims posting, and overpayment requests etc). Dealing with thousands of payers creates unavoidable administrative cost and headaches for providers. But payers do not directly bear this cost, and actually benefit from it in some ways, so they have more incentive to extend the status quo than to change it. In addition, no single payer alone can actually fix the problem, because the problem is a result of payer heterogeneity, not the actions of any one payer. 

 The “right” answer systemically is for policy changes to modify the incentive structure (in a weird way, I think the emergence of “payviders” and value based care actually helps here as the same entity is often responsible for both the services and payment). But no individual provider has the ability to change the incentive structure either. 

The fast answer is to build tools to make this work smoothly as an individual provider. That’s what we’re trying to do at Carbon, and we have a lot more work. 

Thanks to Brendan Keeler, Alejandro Novoa, Margaret Goldberg, Sherwood Callaway & Sophie Pinkard for reading this in draft..

[1] At scale, eligibility is continuous, while registration is a one time event. A patient registers at the start of their relationship with a provider, but if their care is carried out over time, their eligibility might change based on changes in their insurance, benefits, the relationship between their plan and the provider, etc. For care over time, eligibility is often re-run prior to each interaction, to ensure the services are covered and no one is surprised. 

[2] This insight, and most of the essay, applies primarily to outpatient care. For inpatient use cases or chronic care I actually don’t have a good model for what the provider is optimizing for (for example, if you show up at a hospital for an ER visit, your out of pocket cost might be thousands of dollars - I just don’t know if hospitals want to have that conversation with a patient, or if patients are ready, or should, etc)

[3] The other massive headache for providers is COB (coordination of benefits). For patients with multiple insurances, it is super hard to know what’s covered under each plan, which plan is primary and should be billed first, and what the ultimate patient responsibility will be. In these cases, actual price transparency is basically impossible. 

[4] For disclosure, I’m an investor in Substrate

[5] Some providers solve this by negotiating case rates: flat rates paid by the payor regardless of what services are done during the visit, or the complexity of the visit. This dramatically simplifies the contract side of the equation, and providers can then focus on getting the correct cost-share/benefit information as inputs into the estimate.

[6] Even getting a clean eligibility response is sometimes enough. Many payers will give members on individual plans a multi-month grace period to pay premiums, but if the member hasn't paid for some period of time, the plan will go back and retroactively terminate the member's eligibility from the first month of non-payment. I.e., the provider can check the patient's eligibility on May 1, receive a response that the patient is eligible, and receive payment from the payer, but then the payer can backdate the member's termination to March 30 and claw back the payment they already made to the provider (and direct the provider to go collect it directly from the patient)