Ideon Blog

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 sales@ideonapi.com