Select a state or province from the map above to get primary contact and web information for any
member fund.
Member Connection: A member-only forum where you can post questions and ideas.
Stat Book: A highly functional analytical tool that provides valuable comparative benchmarking results from among our members who participate.
Online Directory: Get connected with your counterparts through this comprehensive list of AASCIF members with updated phone number, email and website information.
By Matt Holbrook, Director of IT Applications, Maine Employers Mutual Insurance Company (MEMIC)
Electronic data interchange (EDI) has been a common practice across many industries, used to replace the submission of information through paper forms with a more efficient electronic transactional process. In each industry, there usually exists an EDI standard that governs the content, format, and processing of transactions, either enforced by legal authority or adopted by voluntary consensus.
In workers' compensation claim reporting, state agencies have adopted EDI to reduce their reliance on paper forms in fulfilling their legal mandates. The standard for all Claim EDI has been developed by the International Association of Industrial Accident Boards and Commissions (IAIABC). The most current version of the IAIABC standard is Release 3, which incorporates and enhances the prior releases' content while adding new data elements.
Right now, 33 states are in production with EDI based on the IAIABC standard, with EDI being mandatory in 26 of them. Another 8 states are planning or actively working on EDI implementations. And among those already in production there are some contemplating migration to the latest release of the standard. Just this year, Pennsylvania will be migrating and enhancing its EDI program, while New York will be going through a new implementation.
One can see the advantages that EDI offers to a state agency. In a time of budgetary constraint, EDI reduces the overhead required to input data coming into the agency. It also increases the accuracy of that data, while also increasing the speed in which it is processed.
There are advantages, too, for the insurance carriers who do the bulk of the reporting to these agencies. Reports are sent to the states much faster, and it is easier to keep track of what was sent when, so carriers have more flexibility meeting statutory deadlines and can more readily track their compliance.
However, there are costs for carriers. Carriers are generally still required to send paper forms to other parties involved in the transaction, such as injured workers. In addition, some states are unable to translate certain paper forms, for which there is a legal mandate, to EDI transactions. So EDI reduces somewhat, but does not eliminate, paper processing for the carriers. It also may require carriers to spend valuable IT resources to enhance their claim management solutions so that they may generate the transactional data required by EDI mandates.
Here is a brief overview of the typical EDI process. The initial step for any carrier is to become an EDI trading partner with the state agency. The IAIABC standard provides a specific set of documentation for defining the trading partner relationship. The documentation describes the types of data being sent, the means through which the data will be sent, and the entities whose data will be sent under this relationship. Generally, carriers can choose to be direct trading partners or to send their EDI transactions through an EDI reporting vendor approved by the state agency. In typical cases, there are testing requirements that need to be fulfilled before a carrier can be approved for production. These requirements confirm that the carrier's process is adhering to the EDI standard as defined by the state agency. (In some cases, the fact that an EDI vendor already has approval to submit in production rescinds the need for carriers using that vendor to go through a testing process.)
There are two types of reports in the IAIABC standard: First Reports of Injury (FROIs) and Subsequent Reports of Injury (SROIs). Within these report types are a number of transaction types called Maintenance Type Codes (MTCs), which correspond with events in the life of a claim. When a given event occurs, the insurance carrier will generate the appropriate EDI transaction and transmit the data to the state agency, whether directly or through a vendor. The state agency runs the transaction through its edits and determines whether to accept or reject the transaction. Its determination is sent back to the carrier as an Acknowledgement transaction, indicating whether the carrier's submission was accepted, and providing error message details if it was rejected.
FROI transactions are accepted by all 33 states in production, but only 20 states accept SROI transactions, with 18 having mandates. The FROI transactions are easier to implement, as they are fewer in number, represent claim-level events, and fit better with existing state forms. Implementing SROI transactions is a more complex undertaking, and some states have limited their required SROI transactions to just a very few.
Carriers that may be new to claim EDI will be considering the "Build or Buy" question. If one has a claims management system that includes a module to handle EDI reporting, the question has already been answered. But for those who must modify their systems, "Build or Buy" is not the true choice. There are vendors that provide EDI reporting services. For carriers with low exposure in states with EDI mandates, a vendor with an interactive EDI solution may suffice. But once a carrier's EDI volume reaches a certain point, greater automation is in order. The carrier could still work with a vendor, but the carrier must provide data to the vendor to drive the process, so there will always be a good deal of internal IT work. Working with a vendor adds costs to the EDI process, but it also relieves the carrier of the need to build and maintain the multiple data transfer processes required when working directly with the individual states. So the true choice is to build a completely internal solution, or a hybrid that involves a vendor.