New Health Plans Need New Operating Systems with Flume Health

TL:DR 

Flume Health has built a tech-enabled back office solution for anyone that wants to launch their own health plan - claims, payments, eligibility, etc. all powered by APIs, webhooks, and data sharing. They’re making it easier for providers and health plans to take on financial risk without the administrative hassle. They’ll likely face some obstacles along the way, including whether enough companies actually want to take on financial risk, legacy companies building their own tech, and operational complexity that comes with scale.

---

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 nikhil@outofpocket.health.

Company Name - Flume Health

Flume Health is a new Health Plan Operating System (we’ll get into what that means). They’re named after Flume, the DJ, who is himself an innovator of the EDM genre and also would probably be a fan of enabling new care delivery organizations to take on financial risk without the administrative burden. This is alluded to in his 2019 EP Quits, which is a reference to ending existing third-party administrator contracts when they don’t meet their Service Level Agreements. 

Or apparently flumes are a human made channel of water, but I have no idea how I’m supposed to turn that into a joke. 

The company was started by Cédric Kovacs-Johnson in 2017. The company recently announced a $30 million Series A raise, led by Optum Ventures. New investor Cigna Ventures and existing investors Crosslink Capital, Route 66 Ventures, Accomplice, Founder Collective, Primary Venture Partners and ERA’s Remarkable Ventures Fund also participated in the round, bringing Flume’s total raise to $40 million. 

What pain points do they solve?

You can think of health insurance carriers as three separate products. The first is a financial product which is the actual insurance - they have a pool of money you have access to if something happens. The second is a network of providers who they contract rates for different services. And the third is administrative - processing claims, wiring payments to the right people, sending bills, etc. The fourth bonus product is a neurological test used to assess your sanity that they call their customer service department. I wrote about a lot of these individual functions in the “Personalized Health Insurance and the Payer Stack” post, which was a certified banger if I do say so myself.

Historically, self-insured employers have decided they don’t need the financial product that health insurance carriers offer. They have a big enough pool of people and money that they can spread the financial risk across their own employees without needing the insurance carrier to do that for them.

However, most employers don’t want to deal with the admin and the network contracting themselves so they still outsource those functions. In one version they’ll outsource it to health insurance carriers that already have a contracted network and admin function and you just use their rails. This is called an Administrative Services Only (ASO) contract. Another version is working with a third-party administrator (TPA) that has a bit more flexibility vs. the ASO, which is largely pre-packaged. Not to make this insanely more complicated but sometimes health insurance carriers (especially smaller ones) will also outsource some internal functions to these third-parties as well. Normal specialization of roles, Adam Smith kind of stuff. 

‍

But there are some pain points with existing ASOs and TPAs.

ASOs are relatively inflexible. If you want to add a new provider or create some new arrangement with a provider group as a business (e.g. value-based care arrangement, discounts on volume, etc.) it’s a huge pain in the ass because they have to get credentialed and set up with the parent health insurance carrier that’s handling your ASO contract. 

And third-party administrators are old school - like moving paper and throwing bodies at a problem old school. Like the biggest TPAs were started at a time period where saying “groovy” was normal and “tech-enabled services” companies were defined by whether they used rotary phones. 

Once you start hitting a relatively significant volume of admin transactions, stuff just starts slowing down because the human capital can’t keep up and if you have complex rules/arrangements for payments they’ll take even longer. If you look at the Glassdoor reviews for some of the larger third-party administrators, you can see that a lot of them complain about how much they have to be aware of and how overextended they are. Without using a modern tech stack, this system starts breaking down.

These are issues that existing payers face with the current offerings. But now there’s also a new underserved entrant in the market for services to help stand up a health plan: companies that deliver care that want to take on more risk. These new care delivery companies want to take on more risk but don’t want to handle the admin functions involved with that, and the existing third-party admins were not designed for them.

Enter Flume.

What does the company do?

Flume originally started trying to help self-insured employers design better, custom health plans for their employees. Then the founders read my whitepaper about going down that route and were like, “wow Nikhil is so smart we should change our whole company direction because of his armchair analysis.” Flume took the tools they built to make a better health plan themselves, and turned that into its own white-labeled product for anyone else to use that wants to design their own health plan.

Today, Flume is a “Health Plan Operating System”, which more specifically is four separate products that allow companies to take on the financial risk while using a modern back-end to handle the administrative stuff, rethinking what third-party administrators are and building a new category of back office services. 

1. Flume Core: Payments, claims, eligibility, contract management, compliance, and reporting in one platform
2. Flume Workflow Engine: Trigger events and conditional logic dynamically affect adjudication, webhooks, and engagement in a no-code environment
3. APIs, Webhooks, and EDI: Real-time data exchange with platform customers, vendors, providers—highly flexible as a plan matures and grows 
4. Member & Client Services: White-label their portal and concierge services, or integrate in-house member app and support

Flume starts by working with health insurance carriers, brokers, or providers looking to take on risk to figure out exactly what kind of member experience they want to create. Flume helps them build out all the components of the health plan “stack” (pharmacy benefits, network, utilization management, etc.) around the partner’s specific offering. This can be partners Flume works with already or partners that the customer already works with. 

Then Flume brings in a network of stop-loss insurance providers they work with to provide insurance.

*disc scratch* remember kids - stop loss insurance is an insurance product for financial risk bearers aka. insurance for insurers. In case a few members get super sick, it won’t bankrupt the insurer.

Flume gets some discount rates on stop loss insurance because they work with companies that cut across different employers instead of working with just one, so they can better understand how companies plan to actually contain costs and mitigate patient risks in several instances. The stop loss carriers are  betting that companies which use Flume's products will tend to manage their members better. 

Implementation of Flume takes a few months in which Flume’s engineers work on the back-end integrating the different stack components with the client’s to create seamless data flows, and build novel plan design features. On the front end, Flume helps clients who are new to the health plan arena build basic necessities like Open Enrollment materials and member support flows. 

The claims processing engine they’ve built is really the core here, and the workflow engine is where the pieces come together IMO. You can think of it kind of like Zapier for any insurance-like function. Want to waive the amount a patient pays if they go to certain providers? Want to send them a text if there are plan updates specific to them based on their medication history or nudge them to a mail order pharmacy? Need to pay a provider using some reference-based pricing scheme and send bills to a patient for the remainder? Need to set triggers for manual review of a claim if the amount is super high? Conditional logic + having a claims processing engine built on a modern tech stack lets you create these more complex payment arrangements and rules.

So if you’re trying to create complex payment rules or if you expect care delivery/patient workflows to change in response to some trigger based on coverage or a financial event, then you want to do as much of this programmatically. Flume wants to be the one to (web)hook you up.

What is the business model and who is the end user?

Flume has a bunch of different case studies and end customer types on its site. 

• Incumbent healthcare (huge af) health insurance carriers - Large health insurance carriers that want to replace inefficient back-office processes or offer more flexible ASOs (with better economics) can use Flume to do that.
• Challenger plans - Masochists building new health insurance carriers can use Flume to set up logic for different coverage events or administrative functions. This means not needing to build a whole claims processor and contract management function in-house day 1, lowering the startup costs for challenger plans.

• Large insurance brokerage firms - Most brokerages help their employer clients figure out cost-containment strategies, underwrite risk, etc., but stop there. For innovative brokerages that want to offer their own branded health plan powered by Flume, they can move beyond making money from just broker fees and instead get money via risk-sharing with their clients.
• Employers that want to offer a custom plan - Some employers might want a really specific plan for the types of employees they have based on occupational hazards, types of issues employees tend to face, etc. For example, a nationwide retailer might want to offer different plans tailored to in-store workers, warehouse workers, and office workers if they have all of them. Or a tech startup might want more custom health benefits and build a network of providers that use pastel colors in their marketing, which their employees prefer. Flume gives employers customizability of plan design and handles the backend administration of the plan.
• Hospital systems - Hospital systems and providers are increasingly trying to take on more risk since they’re handling the patient’s care anyway and have more direct means of cost control. Providers that want to launch their own commercial health plans can do so by partnering with Flume.
• Celebrities that want to launch their own health insurance - After the NFT hype slowly dies down, maybe it might make sense for celebrities to move to the next equally logical area of health insurance plans. I said it before and I’ll say it again - sign me up for that Drake HMO. Flume said this isn’t a use case they’ve seen yet but I’m hoping this post inspires someone.

‍

Flume charges Per Employee Per Month enrolled in the health plan that gets built on top of FlumeOS.

Job Openings

Flume is hiring for lots of different roles, including:

Engineering

Senior Front End Engineer

Senior Software Engineer

Director of Engineering

Senior DevOps Engineer

Senior Engineer Manager

People

Senior Recruiter

Product

Senior Product Manager

Sales

Enterprise Account Executive

Marketing

Director of Marketing‍

___‍

Out-Of-Pocket Take

One of the reasons I think it’s good that more money is going into digital health is because it means new infrastructure companies can get built. Flume represents one of the new pieces of tech-first healthcare infrastructure (with open API docs!).

Here are some of the specific things I like about the company:

Programmatic design - If we believe that insurance coverage is going to get increasingly personalized, which I do, then we’re going to need to keep track of a lot of different coverage rules. This simply isn’t possible with a monolithic administrative function that throws bodies at problems - the administrative spend would skyrocket and plans would have terrible customer experience. Now that every healthcare step is generating data in some capacity (claim, encounter-level data, prescription fill, etc.), we need a health insurance backend built to ingest that data and use it to power next steps without humans in the loop unless necessary. 

Tackling new customer segments + helping them take on risk - The last decade has seen so many companies building new care models with telemedicine, remote patient monitoring, etc. and claim to have better outcomes as a result. If that’s true, companies should put their money where their mouth is and take on financial risk! But the reality is that it’s hard for companies to just become a health plan, it’s not as easy as flipping a switch.

These companies don’t want to hire people full-time who need to handle the administration part of running a health plan, they’d rather outsource it. Plus for companies that pitch themselves on superior customer experience or have a solution targeting a really niche population, that entire experience gets ruined if you’re using a claims processing engine that takes months and makes a lot of mistakes. Flume is trying to tap into this new emerging market who are looking for more flexible solutions - It’ll be difficult for incumbents to copy them since they’re not built for that kind of flexibility or this type of customer. 

Tightening the payer-provider loop - One of the issues with healthcare is that payers and providers are totally out of sync with each other, antagonistic, and interactions between them get drawn out over weeks or months. Payers struggle to actually engage their customers, and providers struggle to figure out a patient’s care within their insurance coverage. Flume lets providers become payers, which lets them better control cost and care. It also allows data between payers and providers to pass through to each other faster so that physicians can make decisions about patient care using information from the payer. 

A modern claims processor + health plan operating system could be the stepping stone to real-time payment/coverage information flowing in healthcare, which I think could have many different second-order effects. Imagine how different a doctor’s office visit might be if you knew right there what your costs for next steps in care would be, whether something was going to be covered or not, etc.

--

Here are the obstacles I think Flume will face as it grows:

Number of customers + appetite for a new admin layer - Right now, Flume is making two bets about its customer base. The first is whether or not the number of tech-first care delivery companies (who believe in their solution enough to actually want to take on risk) and new insurance carriers continues to grow. These are going to be companies that need to use a third-party for administrative functions for the first time, and Flume being a tech-enabled provider that can easily connect with their systems is a plus. But that market is currently small, though growing. The second is that legacy companies will be willing to rip and replace their current third-party administrator or in-house functions and switch over to Flume, which is always a massive undertaking for any large enterprise and a huge leap of faith to use a new entrant vs. a tried and true name.

Operational complexity - Third-party administrators offer a ton of different product lines, some that are programmatic and some that are services. To be competitive you need to be able to offer all the features a company wants to outsource, which is everything from call centers to mail operations for the benefits cards to third-party integrations and more. This becomes even more difficult the more customized and heterogeneous a company's customer base is. As Flume takes on more covered lives or turns on massive enterprises, scaling becomes very operationally complicated. However this is also theoretically Flume’s advantage. Software/tech should make scaling easier and also improve their gross margins + it’s also why it would be hard for old companies to compete with their offering. 

Competition - I think about the quote “the question is whether incumbents can build technology faster than startups can build distribution” a lot. While I think it’s improbable that incumbent third-party administrators build tech-first solutions immediately, it’s possible they acquire companies and introduce some of the functionality that Flume currently offers while starting from an already larger existing customer base. Legacy companies are slow to move especially in healthcare because every decision requires 8 zoom calls and 3 pre-meetings before the meeting. But when incumbents feel threatened things can change. Either way, it means we’ll get better infrastructure so that’s still a win societally lol.

–

It’s exciting to see companies like Flume potentially revamp the administrative infrastructure of healthcare and make it easier for companies to take on financial risk. Everyone agrees we should be aiming for a better backend for our health plans, and now it’s up to Flume to prove they can execute with this product.

Thinkboi out,

Nikhil aka. “OOP PPO coming soon, where everything is an out-of-pocket cost”

Twitter: @nikillinit

IG: @outofpockethealth

Other posts: outofpocket.health/posts

{{sub-form}}

---

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.