pronounced: “eye-dee-ahn”

Arguing API vs EDI is Missing the Point

By Dan Langevin, Ideon co-founder and CTO

The evidence is in: APIs are the future. Across industries—in travel, healthcare, retail, marketing, hospitality, etc.—Application Programming Interfaces are the superior technology for real-time data exchange in complex digital ecosystems.  

That’s no less the case in health insurance and employee benefits, industries for which it is essential that carriers, brokers, employers, and InsurTech companies be able to exchange accurate and up-to-date information that provides members (not to mention those brokers and employers) with the seamless digital experiences they’ve come to expect.

In fact, carrier executives today recognize that they must develop and deploy APIs for enrollment and eligibility or risk being left behind. 

But if APIs are the future, the present is still dominated by EDI—Electronic Data Interchange—and migrating to the former from the latter will take many years and untold millions of dollars. Recognizing this, some carriers are trying to bolt an API onto their existing legacy technology. But this process can also take several years and cost millions of dollars—and still may not provide InsurTech platforms what they need most: real-time access to carrier systems with dependable data quality.

Missing in too many calculations around this issue is the fact that there’s a way to achieve API-like, near real-time synchrony and high data quality today, through EDI: Ideon’s infrastructure solution, which puts an API “wrapper” around EDI. This hybrid approach allows carriers to save money and deliver higher quality service to brokers, employers and plan participants now—and build APIs when they are ready.

To understand why a hybrid approach that incorporates EDI and APIs is best, for now, it helps to recall the evolution of the technologies that carriers deployed to manage members.

In the 1990s, the industry began to adopt an electronic method for brokers and employers to submit enrollment data through BenAdmins to carriers: EDI. But if EDI is a fine format for eligibility and demographic information, it is limited. In particular, EDI is asynchronous—i.e., a one-way transfer of information—so errors aren’t detected until after the file is submitted and an exception report is returned to the sender. 

Moreover, the way the industry implemented EDI created as many problems as it solved. Each carrier developed its own EDI variant, requiring extra work from any broker, employer or technology company that needs to communicate with multiple carriers. Each carrier also has its own internal system for associating participants with plans, rates, networks and other details. These labels often don’t correspond to the way employers name plan options and describe them to workers, so the carriers needed another army, analysts, to clean up the data.

This resulted in two nettlesome consequences. First, because it takes time to review these EDI files, carriers limited how frequently they would accept them (generally, no more often than weekly). This gave rise to a two-week (or more) round trip, which contributed to poor experiences for employers, employees and brokers. For example, while an employee could use an HR app to, say, add a newborn dependent, they’d still have to wait two weeks for confirmation that the change was made correctly.

The second unfortunate consequence was that many carriers chose not to use EDI for small groups because they didn’t want costly analysts working on less significant accounts. So, for smaller groups, carriers asked brokers to enter enrollment data through broker portals. But if this sometimes reduced operating costs, it was—and is still—prone to errors.

Small wonder, then, that modern InsurTechs would prefer carriers to adopt APIs, which are, after all, how computer systems built this century communicate: Their developers know how to use APIs, and have myriad tools to speed their deployment and maintain security. For the BenAdmins, two aspects of APIs are critical:

  1. Bidirectional, transactional connections. That is, real-time conversations vs. the one-way lagged transfers of information of EDI. This  means that when an employee inputs a new baby through an InsurTech app, the API will transmit the name, birthdate and other information and receive near-immediate confirmation that the dependent has been added to the policy.
  2. Higher data quality. The real-time data exchange of APIs enables errors to be identified and addressed quickly. For example, if the new parent mistypes a social security number, the carrier API will flag the error immediately, allowing the employee to correct the information. 

So, of course, carriers should move from EDI to APIs … when they are ready. 

The problem is that they cannot do it as quickly or effectively as some in our business would imagine. A new API, by itself, won’t speed up the rest of the carriers’ electronic workflow. Their core systems still rely on mainframe technology that updates overnight and can’t support real-time changes. And there is a lot of hard work to do to automate the cleanup of enrollment data and the assigning of accurate product codes.

What’s more, APIs typically take years to develop at costs rising into the millions … and the carriers have to do all this with IT budgets already stretched just keeping up with ever-increasing regulatory demands. It’s why we’re in this situation: There has always been a more pressing issue than building eligibility APIs or replacing core systems. 

Still, brokers, employers and members expect fast, accurate and convenient access to all their coverage information. Which means that carriers disappoint them at their own peril. So what’s the industry to do? 

Embrace middleware, which solves all of the above problems and gives carriers the time they need to transition to APIs fully and most advantageously. At Ideon, we start with the premise that not only can we work with the EDI systems that carriers have, now and as they evolve, but elevate those systems to the benefit of both InsurTechs and carriers. By doing so, we give BenAdmin and other InsurTech companies the APIs they yearn for, and the carriers the clean data they need. Importantly, these APIs are consistent across carriers and lines of coverage for the functions we enable. This imparts significant leverage to these technology companies.  

How do we elevate EDI?  We build into these APIs each carrier’s business rules and validations. That enables synchronous responses to errors that may exist in their submission; errors that would have otherwise been transmitted to the carrier and taken a week to come back to them through a traditional EDI connection. These validations ensure that the EDI files we send to the carrier have fewer errors. As they spend less money to clean up EDI data, carriers become willing to accept EDI files more frequently (sometimes daily) and from smaller groups.

We also facilitate the exchange of data back from non-API carriers. For example, we ingest group structures and censuses from carriers regardless of how they are able to deliver these data (e.g., files, email, API, etc). Then we normalize this data, structuring and delivering it through an API to our InsurTech partners. Such data is used for group installation and reconciliation. This functionality eliminates what has historically been another set of manual tasks.

Taken together, our hybrid approach delivers 80% of what a true end-to-end API-to-API solution would. Again, we are not arguing against carriers building APIs. Quite the opposite. In fact, we are often asked to be thought partners as to the sequencing and structure of those APIs, and happily so. But we are saying that middleware is a solution that works very well today, leveraging EDI while addressing most of its shortcomings, thus allowing carriers room to develop APIs when they are ready.

And for those who doubt that middleware that incorporates legacy EDI technology can support modern BenAdmin systems, we offer this quick review:

  • Connected, virtually real-time experiences: ✅
  • Data quality: ✅ 
  • Leveraging existing technology and infrastructure: ✅

Over the coming months we will talk more about  a number of the areas touched on above. In the meantime, if you’re interested in our approach to simplifying the exchange of health insurance and employee benefits data, reach out to

Lightening up the year-end blackout period for employee benefits

Ideon ends the hassle of changing current-year plan details during open enrollment.

By Dan Langevin, co-founder and chief technology officer of Ideon

Towards the end of every fall, as 1/1 renewal dates loom, insurance carriers, brokers and members work diligently to ensure that upcoming plan elections go off without a hitch. Meanwhile, life goes on in the current plan year, and life events that affect enrollment need to be addressed. Simultaneously managing the current plan year changes and the upcoming elections is often a tricky ordeal.

The fact is, most carrier systems struggle to manage coverage across plan years—regardless of the carrier’s backend data ingestion system (EDI 834, API or a custom format). When you consider that enrollment elections for the next plan year begin at least a month before the effective date and that changes can continue to be made retroactively for 60 days, cross-plan-year changes can actually be a problem for three months a year.

To this point, the “state of the art” solution has been manual one-off processes. Carriers require specialized, custom formats (different from their regular EDI 834, API requests or flat files) or specially timed delivery of changes for the prior plan year that differs from the regular file delivery day. In practice, most brokers and operations teams at BenAdmin platforms handle these changes manually, by contacting the carrier or by entering the data into the carrier’s portal. This isn’t exactly ideal. Nor is it ideal for the carriers, as their cost-saving automation is bogged down by so many extra manual touches.

This is a major systemic shortcoming. How can we realize full digital connectivity if for 25% of the year we require a separate manual process to handle basic changes?

Eventually, the underlying limitation will be resolved. Carriers will upgrade their internal systems, data models and processes to seamlessly handle cross-plan-year changes. But, as with many things technology-related at large national carriers, the investment required to accomplish that will be large and the timeline long. The market wants a solution today.

Enter Ideon’s Blackout Period Change Management. We have worked diligently with our carrier partners to develop cross-plan-year, change-management processes that eliminate the need for one-off manual changes. The result: the effective elimination of Blackout Periods.

From the BenTech platform or broker’s perspective, data is sent to Ideon’s APIs per standard operating procedure. Our data model has the concept of different plan years baked in. The differences between how transactions are handled with each carrier are entirely transparent. It “just works.”

From the carrier’s perspective, cross-plan-year changes remain less than ideal. Most carriers need to do some level of system acrobatics to process them. That can mean tasks as manual as employees processing a custom Excel doc with every requested change. That said, knowing that they are getting clean data in a consistent format from multiple BenTech platforms gives them back some of the leverage they reap from automation the other nine months of the year. Further, as the carrier upgrades the efficiency of their internal systems (to standard file feeds or, ultimately, to APIs), it will have a partner who understands the idiosyncrasies of cross-plan-year changes and can help to develop a technical integration and business process.

This fall, we piloted our Blackout Period Change Management process with a large customer that covered tens of thousands of lives across hundreds of groups and four carrier partners. The feedback from all sides was extremely positive. That success has made us that much more excited for a broad rollout across all of our carrier and BenTech partners.

Ideon’s mission is to make insurance and employee-benefit data flow freely between member-facing tech platforms and insurance companies. We know that APIs will be a big part of that solution. In the short term, though, we will also provide innovative, tech-enabled business processes that bridge the gap between where we think we should be and the realities of what exists in the ecosystem today. 

Contact us to learn more!

Data Distribution – Use Cases for API vs Flat Files

**Ideon is the company formerly known as Vericred. Vericred began operating as Ideon on May 18, 2022.**

For the past 10-15 years, APIs have been considered the “modern” way for two software systems to interact. But an API isn’t the solution to every problem.

At Vericred, we provide large volumes of health and benefit data to partners for integration into their platform or their product, and when we were developing our integration points, we were faced with a decision: do we go API-only or do we support other methods of data transfer?  Ultimately, we landed on a hybrid approach where we provide product feature-level access to our data via API, and platform integration via a set of flat files.  This approach has proved to be flexible for us, and has allowed us to develop deep integrations with minimal friction and start-up costs for our customers while minimizing bloat within our codebase.

Is this the right approach for you? Below I offer four considerations to keep in mind when deciding how you’ll integrate your data.

1. Usage of the Data (Platform vs. Product Feature)

Is the data going to be used to build a product feature or to power a platform?  This speaks to the flexibility that our customers will need when using the data.  For example, our provider-network search data answers a few simple but commonly asked questions.  The primary questions is “is Dr. X in-network for this plan?”  This lends itself nicely to an API endpoint (and, in fact, we only offer this data via API).  We would consider this a product feature: it solves a very specific need. While it’s an important part of the user experience, its functionality doesn’t bleed over into too many other user journeys in our customers’ apps.

Conversely, for many customers, our health plan data is core to their platform.  It’s displayed in multiple user journeys throughout their apps. This lends itself well to a bulk data transfer process.  Our customers would rather have this data in their own database.

2. Volume and Frequency of Update

How frequently is this data updated?  The cost, in terms of development and operations time, of pulling a large data set into their database is considerable for our customers.  If the data set is updated extremely frequently (and if the number of updates is very large), these issues are magnified.

In the previous example, our provider-network data has hundreds of millions of records and changes very frequently.  We see churn as high as 8% per month in certain networks.  The volume of the dataset is an indicator that a flat file might not be an optimal solution.

Conversely, plan data is updated once a year and rate data is updated once per year in the individual market and once per quarter in the small group market.  While in practice the data changes quite a bit more than that due to corrections, new data becoming available, and other factors, the volume and frequency of updates are far lower than provider-network data.  This makes it a candidate for the flat file approach.

3. Relationships Between Entities in the Data

One of the key design principles of a REST API is that it is entity-based.  While this has the advantage of a predictable location for each entity (e.g., Plan 123 always lives at /plans/123), it has the disadvantage of making it a bit more difficult to string together many related entities.

In the above example, if Plan 123 happens to cost $X in zip code 12345 and $Y in zip code 23456, and it also happens to be available in 12345 and 23456, but not in 34567, the customer would need to make additional API requests to determine all of that information.  When the object graph is fairly large and the customer needs to access the entire object graph to persist it to their database, flat files tend to be a better choice than API-only.

4. Format Requirements

Many of Vericred’s customers have vastly different schemata, and in order to reduce friction and increase adoption of our data platform, we made the decision to offer customized formats to those customers.  An API is, ideally, a single consistent representation of a set of resources.  Maintaining multiple formats or schemata in a single API is complex, and will often accrue technical debt within a codebase.

We made the decision to push this complexity out of the API and further down the chain.  The “standard” set of flat files we offer is generated from our API directly, but any customizations are post-processes that operate on our standard set of files.  This allows us to build out features in our core API while still meeting the needs of customers who have specific format requirements.

As a data services company, we’ve learned through working with customers over the course of the past 2 ½ years that there isn’t a one-size-fits-all solution to data transfer.  APIs are a great solution for many use-cases, but they are not the only solution.  There are several cases where transfer via flat files has proven very useful and has allowed us to separate out the general and client-specific pieces of our architecture to provide us substantial flexibility in working with our customers.