Translating EDI and API: What brokers should know about system integration
If you’re comparing benefits administration and HR software, you’ve probably looked into integration capabilities. Brokers are looking for software with robust integration in communicating eligibility and election information from the benefits system to the carrier system, but what does that really mean?
At its core, integration typically means two databases are talking to each other. With benefits software, it means employees’ elections on the platform are communicated to the carrier. There are two approaches used in the industry to accomplish this: electronic data interchange (EDI) and application program interface (API).
EDI is simply a standard format for exchanging data from computer to computer. If you’re familiar with file feeds, then you already know what EDIs are. This is a mechanism for pushing streams of information, or data feeds, from one database to another, automatically or on demand. While EDI is a step above manually inputting information into a carrier’s host, the process does leave room for error. The files are often difficult to interpret, and most carriers will typically only do EDI with companies that have more than 100 employees because of the error reports they generate.
In contrast, through API, the HR/benefits software is actually talking directly to the partner system, instead of through a file feed. API is what makes it possible to move data between databases in real time. It’s capable of syncing directly with carriers whenever there is a change in benefits. This is a much more robust method of integration, and more of what most brokers are typically envisioning when they ask for integration.
What brokers should know
Many platforms are capable of both EDI and API, but limitations will be based on what your carrier partners are able to accept. For example, EDI is the best integration most insurance companies can offer. API is better than EDI. But, currently, few insurers are capable of this type of integration.
Further, if you work with smaller carriers or groups, you may be communicating eligibility and election information via more manual forms of integration. Examples of this include carrier form mapping, where the platform maps information onto the carrier’s paper form or change reports that can be generated and manually input on carrier websites or facilitate sending mapped carrier forms.
The main takeaway for brokers is that integration capabilities are shaped by carrier limitations. The best scenario for you is to work with a platform that offers all of the options, so that you can do what is best for each client in each carrier situation.