by the EBS team
If you have been working with technology vendors or benefits carriers, you have probably heard EDI and API pop up in conversation. But, what do these acronyms really mean, and why are they important to your business? EDIs (Electronic Data Interchanges) and APIs (Application Program Interfaces) help transfer data from one program to another. For companies that consistently onboard new employees or make benefits adjustments for current employees, the difference between these two modes of data transportation can have a significant impact on your business’ ability to operate effectively. In this blog post I will establish points of difference between the two models and provide insight as to why this talked-about transition from EDI to API isn’t just a passing phase or the talk of a few innovative software vendors, but a movement that should be promoted and encouraged.
Key points from this article:
Newer EDIs are a significant improvement over old, paper-heavy and faxing systems, but APIs are the best solution for syncing, seamlessly entering and updating benefits data real-time.
APIs allow for storing employee benefits data in the cloud, so there’s no delay caused by a file feed transfer over to a benefits carrier.
API solutions aren’t perfect: it’s a good idea to be proactive about understanding when changes are automatic and when they need to be manual.
EDIs are file exchanges that are typically sent to benefits carriers on a weekly or bi-weekly basis. The necessary information gets pulled from these file feeds and is delivered to the carrier. This process provides an automated data exchange between the HCM platform and carriers, however, it is not without some manual intervention. Once this file feed process is complete, the data may result in error reports to be reviewed and manual intervention to correct the erroneous data. This can result in weekly (or bi-weekly) work for the client. However, many HR technology leaders in our industry see this as a significant improvement over the process preceding EDIs, which was paper heavy and often entailed faxing countless documents to your benefits provider.
While we can agree this system is a vast improvement, if you’re in a company that needs benefits data updated in real-time to run effectively, EDI won’t cut the mustard. And even in a company that has implemented EDI, roadblocks that are hard to ignore still exist. For example, Blue Cross Blue Shield in MA requires at least 150 employees before accepting EDI automation. If you’re under 150 employees, you are either stuck with a manual process, or you can use their enrollment system. Are these limitations prohibiting small businesses from working more effectively? Absolutely.
Many technology vendors are pushing benefits carriers to step away from using outdated, slow EDIs and transition over to a faster, real-time solution: APIs. Unfortunately, due to the sluggish and arduous nature of innovation, particularly on the side of the benefits carriers, file feed technology is the most common integration that benefits carriers can offer. Nevertheless, some benefits organizations have made investments that allow them to do better. That’s where API steps in.
For any smartphone user, interaction with APIs happens on a daily basis. Anytime you log into a new application or program using your Facebook information or email ID means APIs are at work. These integrations essentially store the data in the cloud, allowing for real-time access from other applications that have permissions (either provided by you or mutually agreed upon between the two platforms) to seamlessly enter and update data. What does this mean in terms of your benefits solutions? Onboarding new employees and making benefits changes can happen in real-time. There is no delay caused by a file feed transfer over to a benefits carrier. For rapidly growing companies, this solution often makes the most sense.
There’s no question that web service API integration has several advantages over EDIs, but keep in mind there is no API solution that is perfect, especially in the benefits industry. Still, working with vendors who offer API integration with a variety of partners will likely play to your advantage in the long-run. Some larger benefits carriers with the bandwidth to put innovative technologies into action have started to make the move over to API integration, but barriers still exist. For example, a benefits carrier may have instant syncing for employee enrollments, but terminations require a file feed. The onus of understanding when changes are automatic and when they aren’t still lies on the client.
So, why hasn’t everyone embraced API integration? Simply answered, it takes time. We should continue to strive for API to be the way to move data in the future, and hopefully we can get there with the carriers and technology vendors alongside. For the time being, the responsibility remains on the technology vendors to move this process forward. But, it is also in the benefits carriers’ best interests to start acting like technology vendors, too. Notorious for lack of flexibility and dragging their feet, benefits carriers aren’t being held equally accountable for preventing much needed technology improvements for their clients. How can you give them a proverbial kick in the pants? Start asking about API integration when it’s time to renew, and collaborate with software vendors who you trust to encourage integration solutions. By articulating a need in the market, benefits carriers might start getting the idea.
What is your biggest challenge with transitioning to an API solution?
Tell us in the comments below and I’ll respond with my best advice.