When electronic data interchange (EDI) was growing adoption in the 1970s, the world was a different place. Customers and businesses didn’t expect instantaneous, real-time data exchange, and EDI files worked well to standardize business processes. Today, EDI is still the most commonly used technology in the health insurance industry for electronically managing enrollment and eligibility data.

Despite broad adoption, EDI has many limitations that stem from its pre-internet design principles. As a file-based protocol, it can only facilitate one-way communication, and it carries high integration and operations costs.

Over the past few decades, advancements in cloud computing have led to new standards for data exchange, specifically application program interfaces (APIs). APIs offer a standardized way for many different applications to exchange information in near real-time. This makes it easier for developers to build interoperability between software systems, perform complex data operations, and receive instant feedback when a record is changed or a request is fulfilled.

We'll closely compare the two systems of data exchange, EDI vs API, paying close attention to the costs, efficiency, security, and reliability of both solutions.

A One-Way Snapshot vs. Bidirectional, Real-time Data

EDI works, in short, by storing and then transmitting files from one party to another over a secure pathway like SFTP. Information can only be sent from the sender to the receiver, and as a result, the received file is simply a snapshot of the data at a previous point. Because both parties do not share the same level of visibility, it is difficult to monitor changes and to find and resolve errors. Discrepancy and error reports for EDI files can take days to produce and even longer to address, which too often results in coverage delays. In many cases, these reports aren’t provided at all, requiring administrators to manually review files with hundreds of employee records.

APIs, on the other hand, enable two applications to instantly and bidirectionally exchange information in a standardized way, typically over HTTPS, the protocol that underlies the internet. This means that data can essentially be synced between health insurance carriers and benefits administrators, allowing transactions to be reflected in both systems in near real-time.

Because communication is bidirectional, APIs allow instant feedback, so, for example, a benadmin platform can access the live status of every transaction during open enrollment or receive automatic updates to confirm that a request was successfully implemented in the carrier’s system.

Where EDI provides a snapshot of a file, APIs are like the building blocks that make up a real-time model. You can use the blocks themselves to perform data operations, validate data, and retrieve information about the state of the data itself. Here’s an example of how Noyo’s APIs power fast, accurate data exchange when managing enrollments and member maintenance.

Manual Data QA vs. Automatic Operations

Constructing and maintaining EDI files is a tedious, time-consuming task that requires a lot of personnel. This results in unavoidable data quality issues, and, by extension, poor consumer experiences.

Because EDI is sent in batched transactions, a small error like a missing digit can invalidate an entire EDI file, which means that changes within the file can’t be fulfilled until the one error is corrected. APIs, on the other hand, can execute transactions individually, so a conflict with one transaction doesn’t disrupt other requests being processed.

Another issue that heavily impacts the reliability of insurance coverage is the high error rate among EDI files. As an example, it was reported that the jaw-dropping 25 percent error rate of 834 EDI transactions in the ACA market was reduced to 10 percent, which is still shocking. A recent report from Guardian found that while EDI was the most common solution for trading enrollment/eligibility data, data quality was the most common concern.

According to the report, 25 percent of all employers surveyed and 40 percent of larger firms (1,000 employees or more) see EDI errors as a common problem. Similarly, 30 percent of all employers and 50 percent of larger firms would switch carriers for real-time data connectivity.

Noyo Co-founder and COO Dennis Lee captured the sentiment well in a recent article, “No matter how robust the quality assurance process, if data exchanges multiple hands and relies heavily on human interpretation, the system will break down.” 

The core features of APIs—bidirectional communication, real-time data exchange, and individual requests—allow software systems to automate manual, error-prone processes, as well as embed programmatic ways to protect data accuracy.

For example, a carrier can build in business logic so that a request to enroll an employee in a specific plan can only be fulfilled if the employee meets the plan’s criteria. Before a request is confirmed, the API validates that the necessary information is present and in the correct format. This is very powerful when you consider that one of the most common issues benefits administration platforms face is incorrect or out-of-sync plan configurations.

Other tasks like error identification can be increasingly automated, so instead of a human reviewing a report and then manually correcting errors, a benefits administrator could access a real-time dashboard of all transactions. Ops personnel could receive instant notifications when a record in their system doesn’t match the carrier’s system, along with information about how to resolve the issue. This level of transparency and efficiency is what Noyo's API solutions enable today with unprecedented features like round-trip confirmation, proactive audits, and modern reconciliation tools.

APIs don't just make processes like installation, maintenance, and renewal more automated, they allow deeper insights at each stage of a policy. When data is locked away in EDI files, it can’t be used for analysis, reporting, or product development.

One-to-one vs. One-to-many

The major benefit of EDI is the standardization it provides, however, it isn’t one-size fits all. EDIs are challenging to tailor to different company sizes. On one end, most carriers won’t accept EDI files for groups under 50 individuals, and on the other, EDI files become increasingly difficult to work with as they grow—structuring an EDI file for a company of 1,500-2,000 employees can take weeks.

EDI integrations are also expensive to build, requiring a custom EDI pathway for each connected partner, and a custom file for each group. Engineering teams may spend 8-14 weeks on an integration with each new partner having a unique configuration process and file requirements. That means high, recurring integrations costs that are compounded by the high operations costs we outlined above. It also means valuable engineering resources are locked into lengthy build timelines that only grow in complexity as you move upmarket.

Comparatively, developers can set up connections with APIs in mere days. This is because you don’t need to build a custom pathway or file for each connection. Installing a group, updating coverage, or verifying coverage can be as simple as submitting a request to an API endpoint—it’s a much more scalable system. Instead of building custom infrastructure for each connection, APIs provide a streamlined protocol that any partner can access over the web.

Minimum Security vs. Granular Control

While any data infrastructure is vulnerable to attack, EDI and APIs offer different levels of security by design.

Noyo VP of Engineering Peter Nagel explains, “Within health insurance infrastructure, by far the most common alternative to an API solution is a file-based exchange over SFTP. While APIs served over HTTPS and SFTP offer similar encryption to EDI via SSL/TLS and SSH respectively, APIs offer additional benefits that result in an even more secure solution.”

With EDI, you are able to restrict who can access a folder and what operations they can perform (e.g., read vs. write). APIs allow these same protections, but with more granular permissions. For example, you can control access for specific endpoints and HTTP methods, the fields that are returned from a particular endpoint, the resources that are accessible in a given endpoint, the attributes that can be modified, and which actions can be taken on a resource itself.

When it comes to guarding against attacks from bad actors, the most common way to protect an SFTP server is to allow-list specific IP addresses from known partners. This particular protection is also available for APIs, but additionally there are well-tested API solutions to protect servers from other attacks like DDOS using rate limiting and web application firewalls.

It’s easy to assume that encryption and basic user permissions are enough to protect PHI, but when you consider how many people are needed to access and manipulate EDI files, the risks increase. The more automated a system can be and the more control it allows, the more secure it is.

The age of connected insurance

In a world where an online purchase can be delivered to your door same-day, it shouldn’t take a month to receive health coverage. Despite the many advantages of APIs over EDI connections, insurance companies need to upgrade legacy infrastructure to modern standards for broad connectivity to exist.

We know a major challenge companies face is figuring out how to grow with legacy systems today while investing in technology for the future. We also know most insurance companies want to focus on insurance, not technical infrastructure.

Noyo offers a complete API solution across every step of policy administration. We partner with leading companies across the industry to streamline data connections and enable seamless benefits experiences.

See what benefits software platforms and insurance carriers can do with powerful APIs and clean, trusted data.

__________________

EDI vs API - Frequently Asked Questions

What is EDI?

Electronic Data Interchange (EDI) is a file-based method of electronically sharing information between two systems of record, typically via the SFTP protocol. With EDI, data is stored and transmitted in batch files that are transferred between each system at regular intervals. EDI can only facilitate one-way, asynchronous communication between sender and receiver, whereas modern alternatives like APIs enable real-time connectivity between multiple systems using web-based protocols like HTTP/S.

Is EDI outdated?

EDI was created in the 1940s and saw broad adoption for standardizing business processes in the 1960s and 1970s. However, in today’s world of real-time data exchange, EDI is being replaced with more efficient and scalable cloud-based technologies like Application Program Interfaces (APIs). Due to its limitations and pre-internet design principles, EDI is largely considered an outdated, legacy technology.

What is an API?

Application Program Interfaces (APIs) are simply a standardized way for two applications to instantly exchange information. This is typically done over a web-based protocol like HTTP/S. Using APIs, data can be exchanged bi-directionally and synchronously with granular control over how data is accessed. Any system capable of HTTP requests can exchange data with an API making it easy for developers to build real-time data connections between many different applications.

How are APIs used for health insurance and benefits administration?

APIs are used to facilitate real-time data exchange between benefits administration software and insurance carriers. Insurance enrollment and eligibility data can be synced between many different systems enabling new benefits experiences like fully digital group applications, one-click policy activation, instant insurance coverage verification, and automated open enrollment processes. Instead of building expensive, one-off EDI connections, APIs offer a one-to-many solution, which is more efficient and scalable.