At the start of the COVID-19 pandemic in the U.S., in early 2020, the federal government wanted to ensure that anyone could get tested for COVID-19, for free, regardless of whether they were insured. This was accomplished by passing the CARES Act, which included a clause that forced all insurers to cover the cost of COVID-19 testing. In addition, the government created a fund, managed by the U.S. Department of Health and Human Services (HHS), to pay for testing for any patients who were uninsured.
As one of many care providers who invested deeply in pandemic response to serve our communities, Carbon Health had to operationalize the process of collecting payment from this government fund. Here’s how it worked:
• If a patient came in and presented with COVID-19 symptoms, had been exposed, or otherwise requested a COVID-19 test, and said they were uninsured, we’d take their identifying information as normal (name, birthdate, address, and so on — the same information we’d need in order to provide care).
• Given that this was a new workflow, we’d then add all their information to a CSV file that looked like this:
• We’d upload that CSV file to the HRSA (Health Resources and Services Administration), and a few days later (usually within two days, but longer during peak COVID-19 spikes when there were lots of patients), they would respond with a list that included:
> For each patient who was actually uninsured, temporary “member” IDs we could use to submit to our insurance clearinghouse
> For each patient who had insurance, a request to contact the patient
We’d then submit claims for uninsured patients to our clearinghouse, who would submit them to the government directly for reimbursement. For insured patients, we’d reach out to the patient to collect their insurance information.
One obvious learning from this process: there’s a database somewhere that lists everyone who is insured and everyone who isn’t. HHS either owns or has access to this data, because in order to tell us a patient was uninsured, they’d need to query it.
This matters a ton for providers like Carbon Health, because one of the biggest points of friction in delivering care is collecting and verifying patient insurance. There are several friction points throughout this process.
Several issues arise when you try to collect and verify patient insurance — in part because insurance cards are non-standard in several ways. They are structured differently, with the same fields in different places depending on the insurer, and insurers format data differently from one another (for instance, some start ID numbers or group numbers with letters; others, with numbers). In addition, these differences exist in different insurance plans from the same insurer, insurers differ by state, and most insurers have multiple plans. BCBS, for example, has hundreds of plans in Northern California alone.
Carbon Health’s insurance-collection flow works like a waterfall.
The scanning process is successful only two-thirds of the time. The rest of the time, it fails — because the service couldn’t focus on the insurance card, because it could focus on the card but couldn’t extract the text in a format that made sense, or because something about the extracted insurance details couldn’t be verified (for instance, an unknown payer or an unknown plan for a given payer).
Every time insurance information is entered into our system, we call an API to verify eligibility. This does a couple of things: it verifies that the patient’s insurance is valid (the data is correct and what’s on file with the insurer) and unexpired, whether Carbon Health is in-network or out-of-network with that insurance plan, and the copay amount. This process also has several failure points. First, many insurance systems (mostly smaller ones) don’t allow eligibility to be verified electronically; you have to call them on the phone. Many systems are asynchronous — you can verify eligibility electronically, but you don’t get a real-time response. This can be problematic in cases where a patient walks into a clinic, they’re right in front of you, and you want to make sure they know that their care will be covered and they won’t have a surprise bill. In addition to this, insurers launch new plans all the time, and these new plans are not uniformly verifiable via API upon launch. API calls to verify insurance eligibility fail 30 to 50 percent of the time (unfortunately, the API responses don’t typically include underlying failure reasons).
Another factor: some patients might not know whether they have a Medicare Advantage or a Medicaid Managed Care Plan; in these cases, they might have two or three insurance cards and might not know which one to use. This means patients scanning multiple cards (or entering insurance information multiple times manually) to check whether they’re eligible for care, and then, even with valid insurance, care not being covered by that payor specifically. I suspect that these metrics are uniformly bad across the healthcare industry and end up being papered over by human intervention at the point of care.
The failure rates in insurance collection and eligibility verification increase costs in a few ways. First, almost every insurance flow has a human in the loop somewhere, just to handle the failure cases. Every provider in America pays for a team (or teams) of people to do this, and these costs are ultimately passed on to patients in the form of higher fees.
Second, it often happens that the provider sees the patient, and only after the visit learns that they can’t get paid via insurance — either because they don’t have the patient’s insurance information (and the patient is nonresponsive), or because even though they have the insurance, they’re not in-network and the payor denies the claim. This ends up as bad debt, for which the provider won’t get paid, and over time turns into higher costs passed on to uninsured patients and or insurers.
Over the course of the pandemic, we’ve worked with our clearinghouse partners and been able to manually retrieve verified insurance information for a really small number of patients. What we’re doing right now is fairly unscalable, but the development of widely available coverage-detection-as-a-service infrastructure will both help reduce costs in healthcare and increase the adoption of software-driven healthcare services.
The best analogue I can think of for this is identity verification in fintech. In financial services, all consumer-facing use cases require you to verify a customer’s identity. Today how this generally works is, you collect identity information from a customer, ping an API, and get back a response indicating that the identity is real. The identity information collected is generally fairly standard: name, address, birthdate, social security number, and an identification document (driver’s license or passport). This is spoofable at the edges, but it works at scale.
In this analogue, the insurance card and the driver’s license play similar roles; they are physical documents that are proof of identity. In fintech, driver’s licenses are often a last resort during IDV; most hyperscale IDV systems are API based: you send a name, a date of birth, a social security number, and an address, and then you receive a likelihood that the identity is real, a credit score, and so on. In healthcare however, the insurance card is a first resort; every person knows their own name, date of birth, and social security number. No one knows their insurance card number from memory. The result is that you put a super high-friction experience in front of every patient.
Routing layers like Alloy make it easy to call a single API and get connected to several identity databases at once. A routing layer for coverage detection would accomplish several parallel objectives. First, it would help reduce the cost of care by reducing the need for a human in the loop. Second, by increasing the likelihood that a provider had insurance, it would reduce patient delinquencies.
In addition, it would enable software-first care-delivery companies to scale faster by not having to rebuild insurance collection flows over and over again (which is what happens today). There’s a massive opportunity to supplement or replace the existing insurance collection flows around the industry. Here’s how this routing layer could be built:
Over the course of our response to the pandemic, we discovered that some clearinghouses provide manual, asynchronous coverage services. From what we can tell so far, each clearinghouse has only partial coverage (ours returns a patient’s insurance only 30 percent of the time given a name, birthdate, and address — this probably varies hugely depending on your region, patient mix, and so on).
So you’d build a routing layer for coverage that healthtech customers could use to access multiple sources of insurance coverage data via a single API. The API request would include a patient name, a birthdate, an address, and either a social security number or the last four digits of a social security number (adding these elements would greatly improve your precision). You’d source the data in a few ways:
• Aggregate the clearinghouses and abstract away the technical complexity (differences in clearinghouse APIs) and operational complexity (some clearinghouses use SFTPs as their processes are quite asynchronous).
• Interface directly with willing insurers to get access to their enrolled lives. As an incentive, you could pay them per successful API call. This would also give them an avenue to reduce the humans in the loop in their verification systems (currently, as a last resort, a provider can call an insurer on the phone and verify that a patient is eligible). Most insurers should have a portal where providers can go to check a patient’s eligibility already, so the underlying infrastructure already exists.
• You could retrieve this information from the government. There’s prior art for government providing private citizen data to authorized parties; the IRS enables private companies to retrieve tax data for certain reasons and uses (for instance, ModernTax and TaxBit). This vector will require a ton of lead time, but as far as I can tell, it’s the only way to actually tell whether a patient is uninsured. I am less sure about how this would work, because governments don’t reliably respond to economic or experience incentives, but it’s an approach worth exploring.
• Buy claims data: there’s already prior art for buying patient claims data from insurers and clearinghouses. Lots of companies do this. For the routing layer use case, buying claims data is a treadmill. People change their insurance frequently enough that you’d need to constantly buy claims data to stay up to date, which would make this far more expensive than the other models. If you had a just-in-time exchange for claims data, you could probably reduce the costs — but still, this would be quite lossy from both a financial and a coverage perspective.
For the service, you’d return a synchronous response to every API call. The response would do one of three things:
• Be empty but promise an asynchronous response
• Confirm that the patient was uninsured
• Return the patient’s actual insurances (plural if they have more than one) with a recent use date (the last time a claim was filed against that insurance)
For async responses, where you’re unable to detect a patient’s insurance coverage in real time, you’d post a webhook later and just have a [n] day SLA, by which time a developer could simply assume that no insurance payments are forthcoming. Alternatively, you’d enable the developer to include the appointment date in the API request, and the service could give it priority or respond prior. Additionally, you could bundle eligibility verification, so you’re not only returning the patients coverage, but also verifying that your providers can accept the patient in network, and returning the deductible, copay, and coinsurance so that you can predict the patient’s out-of -pocket costs.
In early explorations and prototyping of this, we’ve already encountered a couple of failure modes. First, clearinghouses often return vision and dental insurance payors, instead of medical. In addition, even when medical insurance coverage is returned, it’s returned with incorrect details. For example, the right plan will be returned, but attached to the wrong payor (imagine the correct Aetna plan appended to Cigna as a payer). Cleaning this up will take some creativity.
I think there would be four large categories of users. First, every full-stack healthtech company that delivers care and bills insurance — I see new startups experimenting with new care-delivery models daily. Carbon Health also falls into this category. Second, EHR providers would offer this as a value-add service to the doctor’s offices and health systems they serve. Third, companies that handle appointment scheduling and patient intake on behalf of care providers — using a service like this would enable them to more cleanly match patients to in-network providers. Finally, health marketplaces would use this to enrich their matching algorithms, and match patients to providers and specialists that are in-network.
The experience we want to create is simple: for patients to never take out an insurance card again. No more typing, no more typos, no more fumbling for your wallet, no more awkwardly scanning your insurance card over and over again when the camera doesn’t work. We can discard those awkward rituals. Just know what you’re in for, and walk in, and get care.
As always, please let us know here if you have questions or feedback.
