How Healthcare Payments Work with Candid Health
Get Out-Of-Pocket in your email
How to Build a Healthcare Call Center
Candid Health is building an API-first billing solution for digital health startups that bill insurance. They handle everything end-to-end, including claim submission, claim follow-up, payment integrity, denial management, and appeals. The key is using data to build and maintain a rules engine that draws from claim submission across its customer base to maximize the number of claims paid correctly the first time. For Candid’s customers, this means higher net collections and better data to inform business decision making. As the company grows, it'll have to figure out how to handle more complex billing types, competition, and whether digital health startups are a large enough market.
This is a sponsored post - you can read more about my rules/thoughts on sponsored posts here. If you’re interested in having a sponsored post done, email firstname.lastname@example.org.
Company Name - Candid Health
Candid Health is making the process of medical practices submitting bills to insurance + getting paid easier and more automated. I know what a lot of you are thinking, aren’t they the teeth straightening company? You’re not cool or original, everyone confuses them. Only thing they straighten is your accounts receivable, feel me?
Candid Health was started by Nick Perry and Adam Reis and has raised from First Round, 8VC, BoxGroup, Y Combinator, and…me! I’m actually an investor in the company, so I’m excited to recycle my investment memo write something completely new on what they’re up to.
What pain points do they solve?
You all keep bothering me about how payments work in healthcare. Well be careful of what you wish for cause we’re about to get into the thicc of it. Let’s go through the steps.
- Insurance eligibility - First the provider checks the patient’s insurance information. This is the part where you get a clipboard asking you to fill out your insurance information and you’re not totally sure if what you’re putting in is correct because the fields on your card have slightly different names than what the form is asking. This will let the provider know if the patient has active insurance and if they have a copay/deductible. Surprisingly, the provider usually doesn’t find out things like whether or not they’re in-network from this part of the check.
- Doctor’s visit - The physician sees you and the visit generates a bunch of clinical documentation around what happened during the visit: “Patient was agitated because the appointment started 45 minutes late”.
- Documentation to codes - The documentation from the visit needs to get turned into standardized codes that insurers can understand and know how much to pay. Medical coding is an entire profession dedicated to turning this documentation into the appropriate ICD-10, CPT, and HCPCS codes which explain what services and how many units of that service were rendered. More complex providers will have medical coders in-house or EMRs/third-parties will offer this as a service.
- Codes to claims - These codes + information about the physician, where the services were rendered, etc. go into an electronic form to be submitted to insurance. Originally these were submitted through paper forms like UB-04, CMS 1500, etc. which you can see below, but now the new electronic claims like 837P or 837I include a lot more information. If a patient is out-of-network, the doctor might create a “superbill” (aka. an invoice of services) the patient can submit to insurance themselves to get reimbursed. “Superbills” are such a cool name for what is actually a very boring thing.
- Claims to Clearinghouses - These electronic claims are submitted to clearinghouses, which essentially are the rails that allow for electronic claims submissions to virtually all of the payers. They will also check the claim for basic errors (e.g. is this a valid ICD-10 code, is the zip code in the correct state, etc). The clearinghouse will reject it if there are corrections to be made, and then eventually submit it to the payer.
- Payer Review - The payer checks the claim against the patient’s plan and the rules associated with that plan. Did the patient need prior authorization and get it? Was everything billed deemed medically necessary? How much is the provider going to be reimbursed for each of these services? How much does the patient have to pay? The payer is figuring all of this out in the “claims adjudication” process and sends their decision back to the provider on the amount they’ll be covering through an Electronic Remittance Advice (ERA). I’ve been told somewhere between 85-90% of claims are auto-adjudicated without people actually looking at it.
- Accounts Receivable + Appeals - After learning how the payer adjudicated the claim, the provider finds out whether it was adjudicated without issues or if the payer denied it/paid an incorrect amount. If the provider disagrees with the decision, they can appeal, which is a different process for each payer and can involve third-party review, submission of other documents, a trial by combat, etc.
- Payment Remittance - The payer sends the provider money and the patient a separate receipt for what was covered. But the payment to the provider probably doesn’t include the full amount thanks to things like deductibles and coinsurance so the provider needs to get money from you, the patient. This is why you get the confusing receipt of coverage called an explanation of benefits where it loudly emphasizes “THIS IS NOT A BILL” on the front and then an actual bill from the hospital later. It gets even more complicated if a third-party physician group was contracted out within the hospital and you might even get a separate bill from them.
- Reporting and data - The billers give data back to the provider on all of the above. Today this comes back in a variety of formats and level of granularity depending on the sophistication of the biller and if they understand how pivot tables in Excel work.
Some of the many issues that arise as a result of this process:
- It’s hard getting data to and from billing companies, particularly if you built your own EMR. How will you send them claims data? Nightly or weekly CSVs? How will you ingest their CSV report? Who is auditing the integration between these two systems to ensure that all claims data has been successfully processed? How much therapy are you going to give the product manager who has to oversee this?
- Third-party billers don’t give a ton of information back to providers on why their bills have issues or how much money is coming in from different sources. This is really important for accounting, forecasting, and understanding how to think about which payers to accept, whether your insurance contracts are messed up, what workflows need to change to make sure the right information is consistently captured, etc.
- Eligibility is a surprisingly unsolved problem still today. If you’re a provider, answering the question “does this patient have coverage for this service?” and “how much is covered vs. how much do I collect from the patient?” is very difficult. There are lots of technical reasons around this which aren’t worth getting into here involving EDIs and something called 270/271 transaction sets. But the result is that the information to answer these questions is unspecific and in some cases unavailable electronically, which requires providers to guess and correct later or call payers to figure out the answer. In most cases, you’ll learn the patient has active medical coverage, but won’t know granular things like if the plan covers the first 3 therapy visits.
- Knowing which payer to send a claim to isn’t always clear. For example, an insurance card might have a big Wellfleet logo on it, but the provider network is rented from Cigna so the claims actually need to be sent to them. Or the patient tells you they have medical insurance through Arizona Medicaid, but they actually have coverage through a Medicaid Managed Care Organization in Arizona (aka Medicaid coverage handled through a health plan). Understanding all of these underlying rules and relationships is key in knowing who to bill.
- This entire process takes a long time - this is why you might not see a bill about a healthcare visit for 3-5 months after until it comes out of nowhere to completely emotionally ruin your day. Part of this might be the provider not sending their bills quickly, part of it might be issues that come up on the bill formatting that need to be fixed by a human, part of it might be that this industry absolutely hates you, etc.
- The patient experience sucks. Besides how long it takes for the bill to arrive, you might actually get multiple explanations of benefits. If the billing company messes up because they missed information and the claim gets denied, the patient gets a letter making it seem like the entire claim got denied (even if the biller just needs to resubmit with the right info), followed by a corrected one several weeks or months later.
- Though some portion of automation and modern API architecture has entered this process, there are tons of manual processes in the mix and really old/gross technical messes in the backend like COBOL, X12, etc.
- Different insurance companies have different rules for what should be on the claim. There are very few standards when it comes to billing - for the same set of services each insurer has a different set of preferences for how they want something documented, which diagnoses the patient should have to deem it medically necessary, etc. A good example would be something like CPT modifiers, which are additions you’ll put to regular CPT codes if something specific happens that might change the payment. You can read some examples here, like a complication during a surgery for example. Each payer will have very specific rules around which modifiers to use when things happen and the documentation required to back it up.
- Insurance companies often change their claim submission and payment rules. Once you figure them out, you need to build the infrastructure to quickly identify when the rules change and implement fixes.
- Insurance companies can be incredibly vague when they deny claims, or they may adjudicate claims incorrectly. Traditionally, a lot of manual work is done to even identify when claims were adjudicated incorrectly, let alone fix them. It’s hard to parse out when the only reason an insurance carrier gives is “nah”.
- It’s incredibly difficult to manage ERAs (the “receipts”) that insurance companies send back to the billing company.
- It’s hard to track if the payers are paying you correctly/ according to your contracted rates. These contracts are confusing as shit! Different license types will get paid differently for the same procedures (e.g. nurse practitioners vs. MDs). Payers have really specific policies, like if you do two procedures in a day some plans will pay less for the second procedure using CPT modifiers. Or the same carrier will have different fee schedules for their EPO vs. PPO plan, so you need to know upfront what the patient has.
When you add up all of the above, digital healthcare providers looking to bill insurance are left with one of two bad options: either (1) outsource billing to a third party billing vendor many of which are pretty old-school,require significant hands-on management, and don’t provide granular data that comes back from the billing process, or (2) build a billing tech stack in-house, which means solving for all of the stuff above even if it’s not a core competency for the company.
What does the company do?
Candid improves the experience of getting paid by insurance so it feels less like stepping on a Lego. They provide modern software tools that handle the entire medical insurance payments system for digital health companies. Similar to what Stripe does for credit card payments or Twilio does for SMS, Candid wants to abstract all the weird healthcare payment stuff away for customers and automate as many traditionally labor-intensive processes as possible.
Specifically, Candid does a few different things through a modern, actually stable and well-documented API:
- Claim Creation + Submission - First, Candid helps customers get the claim to the right payer. Knowing where the claim needs to be submitted is more complicated than it seems. If you wanted to send a claim to your local Blue Cross Blue Shield, in certain states you can figure out which plan is your local one based on your zip code, while others use the first 3 digits of the patient plan #.
Then, Candid takes the codes and creates a claim to be submitted to that insurance carrier. This is not only about the process of taking documentation and converting it into CPT/ICD-10 codes; Candid also run the claims through the rules engine compiled from previous claims submitted to (1) make sure the claim complies that with the payer’s rules and (2) see if they can flag any issues before the claim goes out (e.g. this diagnosis code isn’t covered for this CPT code for this payer). And off it goes!
- Payment processing - Understanding the adjudication details that come back from the payer to understand how much of the claim was paid and the reasons certain parts weren’t paid is not as straightforward as it seems. There are things called Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs), which essentially give reasons why the amount paid might be different than the amount billed. But even though the codes are standard, each payer might actually use them for different reasons. Candid figures out the underlying reason so they can fix the issue for future claims.
- Data + Reporting - Candid gives really granular data back to its customers so they can understand if there are certain workflow issues they need to change upstream. Candid can tell you very specifically where you're fucking up eligibilty, where you don't have providers credentialed, where you have contracting issues, etc. Also, if any rules change from the payer side on how they adjudicate claims, Candid can catch this quickly from across their customers and implement changes to claim submission quickly so payment isn’t interrupted. Plus you get pretty lil’ charts which you can manipulate depending on what mood you want to feel.
- Accounts Receivable and Resubmission - If there are any issues, the claim needs to be re-submitted. Traditionally, in many cases, this requires human intervention, which is a major reason why many bills don’t get resubmitted. How many times do you return items when you got the wrong one? Exactly. Candid is building a rules engine to automate more and more of these resubmissions, in many cases without needing a human looking at it. If there isn’t an automation in-place, Candid’s team of in-house medical billers will go back and check the issue + add a new rule to the rules engine to make sure submissions are done correctly the first time going forward. If there’s an issue that the provider needs to fix, an alert and to-do is sent back to them.
If you’re interested in seeing a demo of the product you can sign up for it here.
Candid isn’t reinventing the wheel on how claims submission works, but aggregates a lot of improvements with technology and learns from their customers. Those improvements make it faster to submit a claim and get paid + new providers and digital health startups don’t need to build their own billing function in-house and can instead focus on their core competency of delivering care or convincing investors you’re actually a software business, not a services one.
Candid claims their customers get higher collections, better visibility into business vis a vis better data, and spending less time managing billing.
What is the business model and who is the end user?
The business model is pretty straightforward - pricing for Candid starts at 3% of collections if a provider doesn’t use their medical coding services, and 3% + $6 per claim if they do. There are some adjustments based on the state where service is provided, complexity and volume of claims that go through them.
Candid’s customers are looking to make their billing problem completely disappear by plugging in their API and never thinking about it again. Typically, these customers aren’t interested in building out their own internal billing team, or may have already tried and realized how hard it is. There are others that opt for a more hybrid model, and utilize their existing internal billing team to operate on top of Candid’s software in order to increase automation, reporting, and efficiency.
Candid is explicitly targeting digital health companies that are delivering care and expect to get paid by a payer. This can be early stage companies working with payers for the first time or larger companies transitioning into payer contracts or replacing their in-house billing teams. Digital health companies have different workflows than in-person providers (e.g. different patient intake processes), engineers that can send data to the Candid API, and data teams that can utilize/slice the info Candid gives back to the provider to inform different business decisions.
Plus, more digital health startups are buying a billing company for the first time vs. a practice or health system that would most likely need to rip and replace an existing provider that has their own medical coders on staff. Candid is betting the digital health provider segment grows and they can grow along with them or die trying.
Candid is hiring for engineering, product, operations, and sales. Check out Candid’s open roles on their website. Alternatively, if you’re motivated by Candid’s mission and are attracted to being part of a high-trust, low-ego, high-output team, reach out at email@example.com
Another infrastructure-as-an-API company! I have a type. One big reason I like these kinds of companies is that they’re sticky once they’re actually integrated into workflows, and if executed correctly, basically become an index on digital health companies as an entire sector.
Here are some of the other things I like about Candid.
Data network effects - Each time Candid submits a claim to an insurance company and something happens, it learns something new and creates new rules. Why did the claim end up in the wrong payer? What do the different numbers of the insurance card correspond to? What are this payer’s coding policies? Whose line is it anyway? As the company works across more digital health providers, it eventually interacts with more types of insurance arrangements, which means it learns increasingly more rules of claim submission, lowers the chance of a claim having an error, and gets providers their money faster.
API-first + automation - Being an API-first billing company has some advantages. For one, data flow can be bidirectional - digital health companies can push their data to Candid for billing purposes and Candid can push back notifications around why certain bills got rejected, which can directly be pushed into the workflows of the care team to review. On top of that, for companies in more complex payment arrangements (e.g. partial fee-for-service with some value-based care bonuses) setting up rules and automation in advance makes it much easier for practices to submit and track payments (and see which contracts they’re attributed to).
Utilizing data exhaust - I think data is still very underutilized to inform operational processes in healthcare generally, mostly because no one can get the data out of a fax machine. Tech-enabled care delivery companies are trying to better utilize data in their operations, and Candid is using the traditionally overlooked data that comes out of the billing process + a bidirectional API to enable that. For example, some customers use reporting data to find all of the claims that were processed out-of-network because the physician isn’t credentialed to then tell their credentialing team where they should be prioritizing their work. Other customers use the Candid API to estimate patient out-of-pocket expenses post-billing to figure out their product prioritization.
As an investor, the main thing you’re trying to figure out is what the startup’s existential risks are, the bets that need to work in order for the business to succeed, and your comfort with those risks. Here are the main ones I thought about with Candid Health.
Are the founders cool? No, but they love healthcare billing. (Just kidding, don't dilute me!).
Startups as a customer - Focusing on startups as a customer has its pros which we already talked about. But the downsides are that the market is currently small. Candid is betting this market is going to grow and they’ll grow alongside it. Moving into areas like traditional small practices or larger providers will be more complicated since either they’ll have to rip and replace entire billing departments or offer modular versions of their product that work with their existing medical coding teams (which might end up losing some of the efficiencies that Candid’s product brings). Plus the sales cycles are much more brutal - in this economy you'll go through two recessions before a hospital contract goes through.
As the startups get large, they’ll also have to decide whether they continue using Candid’s offering or build their own billing function. This is pretty difficult to do, even in other areas like e-commerce, companies aren’t building their own versions of Stripe or Twilio. Candid can also offer other services once they get more data and understand individual practice billing more granularly (lending, eligibility checks, outsourced prior auth management, etc.). Stripe, for example, started in payments, but was able to offer loans and fraud detection by taking advantage of the data they had across their customers.
Competition - An open question is which part of the stack is best equipped to handle billing. Should the EMR layer also just handle billing themselves? Could clearinghouses move further upstream and handle billing? There are also a lot of existing billing companies; are their service offerings good enough for customers who don't want to try a new player in the space? Candid’s bet is that billing alone is so hard and complex that it requires a singular focus on solving the problem and being extremely good at just that alone. And also that customers care about the data Candid gives back.
Complex cases - Today, Candid mostly focuses on relatively straightforward specialty areas that don’t have complex edge cases. For areas that have lots of prior authorization requirements or have a really wide variance in payment rules for a given case (e.g. oncology), the billing requirements are very different. The company can eventually build into this as the rules engine expands, but those areas might end up being better served by billing companies that specialize there.
Candid is tackling a thorny and unsexy issue in healthcare with automation and software. The team is so locked-in and obsessed with the nuances of medical billing that you can tell them what state and health plan you have and they’ll tell you some weird quirk about your health insurance card. It’s the lamest party trick I’ve ever seen, but it does help in getting your provider paid quickly and made me pull a term sheet out of a hat.
If you’re interested in seeing a demo of the product you can sign up for it here. Please I’m begging you. I need to show them I add value.
Nikhil aka. “wait did I pay for this post?”
Other posts: outofpocket.health/posts
If you’re enjoying the newsletter, do me a solid and shoot this over to a friend or healthcare slack channel and tell them to sign up. The line between unemployment and founder of a startup is traction and whether your parents believe you have a job.