Stedi

Alright. So today we’re talking about Stedi and how it’s being used at your company. Before we jump into that, could you give a brief overview of the organization and your role there?

Yeah, our organization is building a health plan tailored to the needs of startup technology companies. We’re doing this by leveraging best in class vendors throughout the ecosystem. And by building a digitally native solution that gives members more incentives to shop around and be active healthcare consumers and savers.

Got it. When did you purchase Stedi and how long have you been using it?

We had our first call with Stedi in December or early January. It was more of an introduction call, and their head of sales was on the line. At that time, we didn’t know much about EDI, but we knew we needed it for integrations. They spent around 30 minutes with me and my co-founder, educating us about the basics of the landscape and showing us how to use the product. We didn’t have specific partners in mind yet, but other contracting conversations were giving us EDI specs. So, it was a great opportunity to understand what an EDI processing software product would look like.

We started with the self-serve option by making an account and trying out some API calls. Stedi had a free tier, and we didn’t exceed it. The transaction-only pricing model appealed to us because it aligned with our ethos of being agile and avoiding high-commitment contracts. It felt familiar, almost like AWS, which was reassuring as there were ex-AWS people at Stedi.

In February, after experimenting with Stedi, we began building the claims system to process claims from our partners. Their team provided valuable guidance, occasionally bringing in engineers to help us. We initially used the guides product to evaluate what our partners would send us, but we discovered other useful products like Buckets and SFTP. Buckets allowed us to self-host interactions with partners, while SFTP enabled remote access to those buckets. We also utilized the Functions product to customize webhook-like interactions when items in the bucket were adjusted.

We only started paying for Stedi services in April when they introduced the Core product priced at $500 per month with a managed portal, better APIs, and preset defaults for webhook interactions. Initially unsure if we needed Core, we decided to try it out, and it turned out to be a great decision. When we hired our first back-end engineer in mid-May, she loved the Core product, and Stedi’s customer support was helpful during onboarding.

Overall, Stedi has been influential in our journey, and we appreciate the level of support they provide. Now, we pay $500 a month and don’t encounter any major issues as everything is well set up.

Could you give us an overview of Stedi and its purpose? What problem does it solve?

Absolutely. In the health plan space and healthcare in general, especially on the payer side, working with multiple partners with varying technical sophistication can be challenging. The industry relies on exchanging data through EDI files, which can be likened to structured XML but not as good as JSON. These EDI files are semi-structured, and while HIPAA regulates the need for parameters and structure, many trading partners either go beyond the requirements or miss some technical specifications.

The traditional method of exchanging this data is through an SFTP server, where you essentially drag and drop files into someone else’s folder. It’s not as efficient as synchronous API calls used in other industries. This is where Stedi comes in. It bridges the gap by allowing abstractions and tighter structures, similar to API programming, to work in the SFTP environment. Stedi handles the complexity of creating a basic file structure that meets HIPAA and guide regulations, providing example data for testing. Moreover, it enables other procedures like hosting a file bucket and granting access, which previously required more complex and intricate code, especially for achieving HIPAA compliance.

I’m curious to dive deeper into the differences between working with the regular EDI paradigm and using Stedi. Could you explain that?

Sure. In the regular EDI paradigm, both you and your partner would have a PDF guide for the specific type of EDI file you’re sending, like claims, enrollments, or payment advice. Usually, the customer with more clout determines which guide is primarily followed, but there might be some modifications based on technical requirements.

The process involves exchanging these guides and example files over email. You send example files in dot txt format to validate that the data works with the receiving party’s system. Once everything is confirmed, a production server is established, and data starts flowing over a period of days to weeks, as automation is implemented.

This whole process can take two to three months due to frequent sync-ups, vacations, and small issues that cause delays. It can be quite cumbersome. However, Stedi simplifies things significantly. They provide example guides that are helpful for comparison, and they allow you to generate example data programmatically through API connections to your local or hosted systems.

With Stedi, you can quickly adapt to new trading partners’ guides by making a few changes within the platform and generating the updated example file programmatically. This saves time and effort, as you don’t need to build all the automated workflows yourself. Stedi handles the intricacies of generating the EDI data, allowing developers to focus on the structural aspects and understand how the data should be processed without dealing with the complexities of healthcare-specific language used in EDI.

I see, Stedi seems to simplify the communication with processing partners and allows easy modification of that communication without the need for complicated code. Does that sound right?

In our current workflow, Stedi provides products that allow us to visualize incoming files processed today or files that encountered errors in the last week. It’s a comprehensive monitoring system with events that can be set on these interactions. This user-friendly interface makes it easy to monitor all incoming and outgoing data, and it also offers native connections to webhooks and other customizable behaviors. Stedi essentially streamlines the entire process and provides a one-stop solution for EDI interactions with partners.

Got it. To refine the analogy further, Stedi not only makes it easy to speak the language of EDI but also brings modern developer tools and practices to the EDI world.

Absolutely, that’s a good way to describe it.

Maybe you could chat me through, from a workflow perspective, what happens and what it is that the product is doing for you?

From a workflow perspective, we have a daily job in our custom code that sends updated enrollment information to our partners, which could be around three or four different partners. We send this enrollment data as JSON to Stedi, and in return, we receive a response from Stedi indicating whether the process was successful without errors or if there were any issues encountered.

To keep track of this process, we utilize a Slack webhook to post the response from Stedi. So, we receive a Slack notification stating whether everything went smoothly for the day or if there were errors with certain members. This helps us stay on top of the processing status and any potential issues that may arise.

Additionally, Stedi also notifies us whenever files are dropped into our SFTP servers. This feature is incredibly helpful as it immediately triggers a webhook to process and send the live JSON to our website or the next step in our processing chain. This notification allows us to be proactive in handling incoming data, such as reaching out to a partner who might be testing their integration or checking claims in our dashboard to initiate further actions. Webhooks and JSON have empowered us to work efficiently within this asynchronous, email-based healthcare environment, enabling seamless communication and data processing.

That’s a big deal. I’m curious to discuss the extent of its applicability and, as we mentioned, we’ll edit and clean up the transcript. Let’s talk about integration. Does Stedi have the concept of integration partners or other products that it works with out of the box?

Stedi is aiming to reach that point, and they have made a lot more progress in other industries. For instance, they have partnerships and a marketplace for integration guides in the shipping industry, where EDI is also used. In that context, it’s not governed by HIPAA but by X12, similar to the W3 association.

In healthcare, the challenge lies in dealing with partners who often lack technological sophistication. As far as we know, we were the first healthcare customer to use Stedi, and they were excited to have us on board. However, other healthcare partners may not fully understand or appreciate the solution, though they assume we have a robust legacy system. Despite Stedi’s ambition to become a clearinghouse for this type of work, it may take time to gain traction in healthcare due to the industry’s complexities and partnerships with companies that may not be as receptive or easy to work with as we’d hope.

How do you feel about their API endpoints and webhooks?

Stedi’s API and API documentation have been quite useful for us. Their documentation is fairly comprehensive, though we noticed that it can sometimes lag behind the rapid pace of their updates by about two weeks. Despite that, it still serves as a helpful reference to get started and understand the basics of their offerings.

One standout aspect of working with Stedi is their exceptional responsiveness. Early on, they added us to a Slack group, which was a game-changer for communication. We can reach out to them anytime, even outside regular working hours, and their CEO and team members respond promptly. It’s quite impressive to see the dedication and enthusiasm they have for assisting their customers. For instance, even on a Saturday night at 10 pm, their CEO would be there to answer questions or address issues.

Whenever we encountered any challenges or questions related to the API or webhooks, their team would spring into action. It’s like an on-call army of engineers would be summoned to tackle the situation. When we reported a possible bug or needed support for a particular feature, they’d promptly involve the appropriate experts to resolve the matter.

Moreover, Stedi provided us early access to some of their features and capabilities. This allowed us to be among the first users to test and experience certain functionalities, and they even provided tailored support to ensure we made the most of these new tools.

It sounds like Stedi has been able to move really fast with you.

Absolutely correct. Their responsiveness is unparalleled, and they have amazed us with their speed of development.

That’s incredible. Now, shifting gears a bit, what are your thoughts on the robustness of their codebase and the overall quality of their engineering and production?

Their codebase and engineering are definitely top-tier. It’s like “holy sh*t” level of quality. They essentially provide an opinionated wrapper on AWS, which means their reliability is on par with AWS. We haven’t experienced any downtime or issues with their service. They offer a BAA agreement similar to AWS, providing confidence in their security and reliability.

How has your experience been with bugs or issues when using Stedi’s platform?

Bugs have been more related to edge cases rather than major problems. The healthcare industry has many unique and peculiar edge cases, and Stedi has been responsive in addressing those specific situations. For example, we encountered cases where someone would drop an EDI file with the extension “.txt” instead of “.edi,” which is surprisingly common in healthcare. Stedi was quick to address those issues.

So, let’s talk a bit about the procurement decision itself. You mentioned the sales process earlier, but let’s dive deeper into that. How was your experience interacting with the head of sales and other salespeople? Also, did you consider any other products or explore alternative options during your evaluation?

Yeah, when we started, I was mainly focused on learning about EDI, and Stedi had the best resources for that. They offer the option to play around with a guide and read blog posts about EDI without any cost. I had heard about a couple of other products, like Availity, Change Healthcare, and maybe something from United, but none of them compared to Stedi. Stedi just felt different, and I didn’t bother looking at other options. Plus, the fact that Stedi was free to start with made a huge difference in our decision-making process.

Actually, let me backtrack a bit. Our main competitor wasn’t another tool similar to Stedi, but rather using a clearinghouse or a business process outsourcing (BPO) company to handle integrations for us. The challenge in healthcare is that once these connections are established, it becomes challenging to switch providers. As a startup, we wanted to remain incredibly flexible. Contracting with external companies can be tough, and I knew that the choices we make now, like the provider network or medical management company we use, are going to be wrong half of the time. So, I was determined to build the integration in-house to have the ability to swap out a network easily, rather than relying on a BPO company that might create dependencies and hinder our flexibility. For instance, if we want to swap provider networks, the BPO could probably do it, but it would cost us $10,000 and take 3 months, and by the time they make the change, it wouldn’t be worth changing back, and we’ve lost any negotiating leverage. We’re trying to be incredibly flexible with our tech and processes, so that we can iterate and make changes very quickly. So, Stedi made it so easy to handle the EDI layer ourselves, and gave us the control we needed to work with other partners without getting locked into rigid contracts and pricing discussions. That was the competitive decision for us: whether to let a clearinghouse or our claim system handle it, or do it all ourselves.

So it was less of a comparison or bake-off, more of a “this is the only product that works for me” type of situation?

Exactly, you nailed it. We didn’t go through a traditional head-to-head comparison of different products because Stedi’s focus on being a developer tool, its usage-based pricing, and the self-serve nature of their platform made them the obvious winner for us. The modern web-tool approach they took aligned perfectly with our needs and requirements.