Breaking Down Electronic Data Interchange, X12, and Stedi

TL;DR 

Stedi converts industry-standard data formats like X12 EDI into easy-to-use APIs for developers who need to send information to different parties in healthcare (e.g. sending claims to insurance, checking eligibility, checking claim status, benefits enrollments, etc.). They have an API that lets you send these transactions to payers using multiple clearinghouses and direct payer  integrations. 

We talk about what X12 and Electronic Data Interchange (EDI) are because they’re core to understanding how healthcare transactions work. If all this sounds like gibberish, don’t stress because we’ll explain step-by-step what all of this means. 

Stedi is doing the nasty work of turning really old standards like X12 EDI into JSON-based APIs that can be used in the tech stack of a digital health company. They’re making the bet that developers will want to use a self-serve API vs. wanting to outsource the whole process to a legacy provider. As they grow, it’ll be interesting to see whether they can capture more value vs. just being a nice API and how they’ll compete with other more healthcare-specific data standard companies.

You can look around their API documentation here, it’s pretty nice. You can also schedule a demo and contact them here.

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 - Stedi

Stedi provides developer-friendly APIs for X12 EDI + connections to payers to transmit data across the healthcare ecosystem. 

Stedi is obviously a combination of Steady and EDI. I imagine they went through a whole process of figuring out EDI puns.

• Redi
  • Company slogan: Set, go.
• Jedi
  • Company slogan: The force is with us
• ManiPEDI
  • Company slogan: Polished APIs
• Fedi
  • Company slogan: Wap

Alright you get the joke. Zack Kanter founded the company, and they’ve raised $71M from Stripe, Union Square Ventures, Addition, and other investors. Zack is also prolific on Twitter, a phrase that people say about me too and I don’t know if it’s a compliment or insult.

Electronic Data Interchange In Healthcare

Ever since I’ve been in healthcare, I’ve heard the engineering teams talk in passing about “EDI,” “X12,” and “wait how does our company make money?” But for a long time, I simply ignored this topic because I thought knowing something about this niche might actually lower my chances of finding love.

However, the Change Healthcare hack put a spotlight on all of this, and I knew it was finally time to learn. And so I’ve been diving into the world of really disgusting PDFs and YouTube videos with <2000 views to learn about what EDI and X12 are and why they’re important in healthcare.

At a high level, Electronic Data Interchange (EDI) is a way for businesses to create a common language so they can transact with each other. In a world without EDI, each business would create its own format for how to exchange information. So to transact, you’d have to figure out how each business structures its format. Some companies might call something a “purchase,” while others call it a “checkout,” and each transaction would have different fields included. EDI sets a standard so that everyone uses the same language when they talk about these things.

EDI is used in all sorts of industries (trucking, retail, banking, etc.), and one of the most common forms of EDI is called X12, which is maintained by a consortium. When HIPAA was passed, part of the law was trying to set a common language in which payers and providers could speak to each other. They ended up landing on X12 HIPAA, which is basically a format for how financial, administrative, and clinical information is transmitted between payers, providers, employers, and every other healthcare stakeholder.

Each time a payer or provider wants to get information from the other, they use a different type of X12 transaction (or, in pharmacy, NCPDP), each of which is formatted in a way that both parties can understand.

Some of the common X12 requests you’ll see in that standard:

• 270 Eligibility Benefit Inquiry: When your doctor takes your insurance information, they want to know if the insurance is actually active. So they’ll take your demographic information and insurance plan information and send it through a 270 request that asks, “Hey is this member’s coverage active?” 

• 271 Eligibility Benefit Response: In response to a 270 inquiry, the payer sends back a 271 that says whether the insurance is active and some other information like the co-pay, what’s generally covered, dates the coverage is valid, etc.
• 278 Prior Auth: This is when a provider asks a payer for approval for a specific service to be covered, also known as a prior authorization request.
• 837 Claim: Providers use this to send claims to payers with the services they rendered to the patient.
• 835 ERA: This is used for payers to tell providers how much they’re actually covering of that claim.
• 276 Claim Status Request: This is a provider asking a payer, “Yo what happened to that claim I sent you?”
• 277 Claim Status Response: A payer would respond with the status of the claim, if adjustments were made, etc.
• 834 Enrollment: This is information sent to payers to tell them all the people that need to be enrolled in their plan including dependents, which plan, etc.

Several of these transaction types have federally mandated requirements that are very specific in what they need to send through the message, which you can see here. They include 270/271 (eligibility), 276/277 (claims status), and 835 (how much payers are covering). 

However, others don’t have those same requirements like 278 for prior authorizations. So the payers have either ignored it or done it differently and poorly. That’s also why now there’s upcoming regulation to mandate 278 standardization and streamline prior auths.

Another caveat. Even though everyone now has a common language for messages (X12), payers often issue their own “companion guide” (if you’re lucky) that gives more specifications around exactly how you should format the contents of those X12 messages using a subset of the X12 HIPAA standard. If you’re unlucky, they just expect you to figure it out without any documentation. 

Here’s an example guide from Anthem. How they describe the patient name is pretty standard, but the guide tells you exactly what parts of the member ID to include, whether they need your social security number, date formats, etc. Some of these companion guides might also include process-oriented requirements, like whether you should send all of the messages as a batch together or one at a time.

So to send any message, you need to: 

1. Use the X12 HIPAA standard which is documented in dozens of PDFs totaling tens of thousands of pages to understand how messages are generally formatted.
2. Cross reference it with the payer-specific companion PDF of how the message is actually structured for them.
3. Make adjustments based on extensive trial and error to figure out undocumented behavior that isn’t in those guides. It’s a PDF, you think they’re regularly updating that?

What Pain Point Does Stedi Solve?

So what’s the problem? I mean, did you hear anything I just said? Just look at the message, it’s fucking disgusting lol. You need to traverse reams of PDFs between every payer and the X12 guide. Also, the X12 standards cost money to actually see the specification (despite it being mandated! What?!).

This standard became the norm in the 90s, and it’s like it trapped the whole damn thing in amber. It’s hard to decipher what’s happening in these messages, it uses very strange and inflexible ways of organizing the data, etc. It also uses a “loop system” that I can’t even figure out myself, but looks like it was designed by M.C. Escher (#cultured). 

Some of these issues stem from the fact that when X12 came out, data was extremely expensive to transmit, so it tried to convey as much information as possible in a tight space. Then each entity receiving the data created their own ways of interpreting the message, which just added more complexity.

There are also limitations in what data can be transmitted via each X12 transaction. For example, the 278 prior authorization request can make the request itself but can’t transmit clinical documentation to explain why the service should be covered. So physicians need to contact the insurance company or send the documentation via 275 attachments which allow supporting documentation. 

A lot of providers use practice management systems that built support for the ancient ways of X12 long ago or hardcode certain rules based on things they can parse from an EDI message, like the one we see above. The more modern systems interface with a clearinghouse that makes a more usable and modern application programming interface (API) out of the X12 standard for you to plug into. 

But then let’s say that clearinghouse were to go down…hypothetically…you would now have to switch everything to a different company's API, which is probably designed differently. So now you need to map all of your data flows to the right place in the new API, and then map all of the responses back to account for all of the different ways that payers can respond. And the reality also is that a lot of these clearinghouses just have pretty bad APIs and documentation.

What Does Stedi Do?

Stedi turns the dank X12 nonsense above and the disparate companion PDFs into APIs that use a more modern data format called JSON (no derulo). You can make eligibility checks, check your claim status, send in claims, receive electronic remittances, and more. 

Stedi puts the hideous X12 standard behind a curtain you don’t need to see unless you want to, and instead has very easy-to-read documentation and an API that’s simple for developers to use. Below, you can see a sample 271 eligibility response. Above is the X12 version, and below that is the human-readable and much easier to work with JSON version.

Their documentation also has some other neat little things you can read about. For example:

• Avoid hitting the same payer with requests from the doctor/provider ID more than 1-2 times every 15 seconds. Payers expect to receive requests at a “human scale” and will flag this behavior.
• Some payers require you to enroll before you can ask them if a patient’s plan is eligible. Stedi actually has a form to help you enroll with those payers.
• If you do an eligibility check a payer has issues with, they’ll issue back a response that starts with AAA and then the reason for rejection. The reason is because when you get it you’ll be all like “AAA F****C*CCKCKK!!!”  (which also looks like an X12 response)

Under the hood, Stedi handles all of the various formats and payer routing for you from the base standards and payer-specific companion guides. You write code to their API, and they transform it into whatever X12 and payer companion nonsense is needed + route it to the right clearinghouse or payer to get a response back. If a clearinghouse goes down, they automatically route through the other clearinghouses or their own direct payers as needed. 

Stedi’s APIs use the same format as Change Healthcare, so if you previously used Change Healthcare’s API, you can keep your same code and switch to Stedi. Stedi has a drop-in replacement that lets you migrate without changing 😏 anything. Apparently, they got this up and running in six days after Change went down, which was less time than it took for me to figure out what Change even does.

You can see the full list of payers Stedi works with here, which by the way is like nearly 7,000 lol. Stedi works with the entirety of X12 HIPAA, and you can see the specs here. 

Plus, if you want to actually see how this works, you can schedule a demo. They have a nifty manual eligibility check tool, where you can put your own insurance details in, and it’ll show you in real-time what your insurance says about your plan.

What Is The Business Model And Who Is The End User?

Stedi charges a mix of subscription fees and usage-based rates for things like eligibility checks, claim status, claim submission, and electronics remittance (ERAs).

Stedi’s customer is any tech-forward (aka. can use an API) company that sends information to payers in some capacity. This can be small third-party administrators, employers, providers, health tech applications that do analytics for payers, etc. Some example customers:

1. Electronic Health Records (EHRs) and Practice Management Systems like Populate that help manage office appointments and turn documentation into bills
2. Revenue cycle management companies like Adonis that file claims to payers on behalf of physicians
3. Digital health and telemedicine companies like Progyny that need to check the eligibility of patients’ insurance before a visit and submit the claim after

Stedi targets developers at these companies, so the expectation is the company has engineering resources to dedicate to working with their APIs. 

Job Openings

Stedi is hiring for several jobs:

• Technical Product Manager
• Senior Visual Designer
• Senior Backend Engineer
• Legal & Compliance Operations Manager

You can see all the Stedi roles here. Stedi is also hiring opportunistically, so you should reach out to the team at careers@stedi.com if there’s a role that’s not there that you think you’d be a good fit for.

Out-Of-Pocket Take

There are a few things I like about Stedi.

Bringing X12 Into The Future - There’s been a lot of excitement about new data standards in healthcare (like FHIR) that don’t have the limitations of X12. However, the reality is that X12 isn’t going away anytime soon because it’s so pervasive and it’s basically written into HIPAA. So like everyone tells my fiance, we need to up our standards.

Since we’re going to have to deal with it, finding ways to bridge X12 into the new age will be important. Stedi has been building a deep understanding of the intricacies of X12 both inside and outside of healthcare, and they’re using that expertise and base to quickly spin up new, modern APIs that are more usable.

It’s a smart wedge, and in the future Stedi might use the trust it’s built with developers in X12 and incorporate it into other standards like FHIR. In the big vision, maybe enough people use Stedi that they can create their own standard that replaces X12 for billing to get around the current limitations.

Customer Network Effects - One of the nice things about a business like this is that whatever they do for one customer will work across their customers. Someone wants to do a direct integration with a payer partner? Stedi can set that up and then every other customer can do it, too. 

But also, as more customers use it, issues found by one customer will get fixed for everyone else. For example, if one customer starts seeing a lot of rejections/issues from a payer, they might discover that the payer changed how they accept 270/271 requests. The fix for that can then be applied to every other customer.

Good Documentation And Developer Support - As I was going through the Stedi onboarding process, they do two things that I think are very useful for customers that other companies should think about. 

One is that they immediately put you in a dedicated Slack channel to answer any questions you have about X12, getting set up, an integration not working, etc. The second is that their documentation has a version of GPT that they seem to have trained specifically to X12/Stedi docs and can answer questions pretty well on how things work. 

I think this embodies their strong opinion about building this tool to be developer-friendly and understandable to humans. Stedi has done the hard work for developers so they don’t have to deal with X12 specifics but also assumes that developers have a certain amount of customization they still want to do on their side by mixing and matching tools Stedi provides.

—

As with any healthcare company, there are things they might struggle with as they grow:

‍Managed Services Vs. Self-Serve - Stedi deliberately chose to be a tool for developers who can use and configure the different elements they have in whatever way they want. This is in contrast to a managed services option, where Stedi would essentially be an outsourced X12 development shop and handle customizations, maintenance of the data pipelines, etc. While the latter can command larger contracts and offer customers to “do it all,” it’s also harder to scale, and things break more often because of the customizability. 

Stedi is betting that the self-serve option of developers using their different EDI building blocks will be more scalable. However, it requires their customers to have developers willing to dive into their documentation and learn how it works. That means there’s “some assembly required” vs. just having it usable out of the box. It also constrains the market size since not every company is going to have the technical resources to be able to dedicate to building EDI pipes. 

‍Economic Constraints - Today, Stedi is an easy-to-use on ramp for developers and lives on top of the clearinghouses to make life easier. However, being an on-ramp is tough because most of the dollars accrue at the clearinghouse level. 

This means Stedi has two options to become a large business. One is to provide more valuable features to their customers, which they can charge more for. Stedi has to build more features and functionality for this.

The second is to convert payers into customers (right now, they’re focused on the provider side of the equation) by becoming their exclusive clearinghouse partner, which is the more lucrative and difficult-to-crack side of the market. Current clearinghouses are both quite old like your mom and an amalgamation of many acquisitions, so building a totally new one from the ground up could be simpler and much easier to use.

However, Stedi needs a critical mass of customers to give it enough leverage for this route.

Generalist Vs. Healthcare-Focused - Stedi doesn’t just operate in healthcare. They work on X12 and EDI standards that are also used in areas like e-commerce, shipping, etc. Must be nice. The positives are that the market size they’re attacking is bigger than just healthcare and they also build expertise in parsing X12/EDI by seeing how it gets implemented in other sectors.

The open question becomes whether a company focusing exclusively on healthcare instead of EDI manages to get an edge on Stedi. This is especially relevant when considering other standards like FHIR, which are included in new regulations like the 21st Century Cures Act, the new prior authorization rules, etc. Will companies with FHIR expertise as their wedge focused on healthcare applications be able to add X12 expertise to their repertoire? Then they can combine clinical/financial data together and create new made-up words from one of my hellscapes.

I think the reality is that it will be more efficient for companies to partner with someone like Stedi for their X12/EDI expertise vs. directly competing with them. But you never know!

Conclusion And Parting Thoughts

This isn’t really “analysis,” but one thing that was very impressive about Stedi is how quickly they executed in healthcare. When Change Healthcare went down, they learned quickly what customers wanted and have just been cranking. It’s been a case of “right time, right place” for them.

I talked to a few of their customers and it’s clear people really enjoy working with them. There haven’t been many engineering-focused cultures dedicated to X12 in healthcare, and that might be all the differentiation they need. But I don’t think they’d pay me to write this post if that was my entire analysis lol.

Thinkboi out,

Nikhil aka. “Ed, Edd, and EDI” aka. “X12 gon’ give it to ya”

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.