Learn how to streamline workers’ compensation reporting with EDI in Origami Risk. Origami Risk’s Electronic Data Interchange (EDI) can play an essential role in helping clients with efficient, accurate, and timely reporting. During this 12-minute solution showcase, we demonstrate the significance of the workers’ compensation EDI process and showcase how it can make for seamless FROI and SROI reporting and provide useful insights through powerful dashboards in the Origami Risk platform. This solution showcase covers: Overview of Electronic Data Interchange (EDI). FROI/SROI reporting. Manual and auto-trigger EDI functionality. EDI acknowledgement. Workers’ comp compliance EDA reporting consists of several type of EDA reporting, like Frauischeui reporting, unit statistical reporting, POC reporting, medical bills, CMS, or workers’ comp paper state forms. In this session, we are going to discuss about workers’ comp EDI FROI SHOI reporting. FROI stands for first report of injury. SHOI stands for subsequent report of injury. Basically, this EDI reporting is subset of primary workers’ comp claim data. This is required by jurisdictions, rules, and regulation to fulfill their statutory re requirements and have a better data quality, timely reporting, and monitoring of the data. And this data is valuable for them to have dispute resolution. Origami offers two different type of workers’ comp EDI Frauishoi reporting solutions. One is manual EDI and another is called EDI with auto triggers. Before jumping into how EDI is done in origami, let’s understand the relationship between claim events and corresponding EDI reports Typically when a claim is initiated, you are supposed to file a FROI Original or MTC OO. If a claim is denied to start with then typically a FROI O4 is filed. Similarly once benefit starts, if claim administrator is paying those benefits then SHROI IP or initial payment is filed. If employer is paying that benefit then EP is filed. Claim is closed then FN is filed. So for every claim event there is prescribed MTC as per state or jurisdiction’s requirement. Three main elements of workers’ comp FROI SHOI reporting FROI First Report of Injury Typically it is about initial information related to injury. It can be FROI original, it can be FROI denial or if you are changing some claim information then you file first report of injury called MTC O2. Subsequent report of injury corresponds typically with initiation of benefits or payments, stopping the benefits payment, closing down the benefit or you are closing the claim. When you file a FROI or a SHOI, state returns acknowledgement. It can be TA that is accepted by state, accepted with errors and rejected by state is called TR. Now let’s jump into Origami Workers Comp EDI manual solution, how manual filing is done, and how to view EDI reports, how to review acknowledgment, how to tell if there are any EDI reports filed on a workers’ comp claim. If you look at the right hand panel and you see open task and there are no EDI reports, that means there are no EDI reports yet filed for that particular claim. On a claim where there are some EDI reports filed, on right hand panel, you will see EDI reports and the corresponding reports that are filed for that particular claim. How to do EDI in origami? On a workers’ comp claim that is for a particular jurisdiction, like, for example, this claim is for Virginia and coverage is worker compensation. In the more drop down menu, you will see create FROI or create SHROI. So this claim has no initial report filed, so we will start with create first report EDI. And in the drop down next, you will see options that the options that are provided that you can file for Virginia. We start with FROI original. When we click on create report, at this time, process is fetching all the necessary data from the claim screen to the EDI screen, And you will see certain fields are marked with asterisk. That means that data is mandatory, and this claim will not be this EDI report will not be allowed to save without this mandatory data provided. If we click on save changes, it will pop you like this information is missing, and this is a mandatory information that is needed to save this EDI report. Once we provide that information and click on save changes, it it will successfully update and save the EDI report. Once you have successfully saved the EDI report, next task is to validate EDI. At this step, once we click validate EDI, this data is dynamically being sent via API to Mitchell EDI report validation system. And if there are any validation errors found, it will pop you what the errors are, and you need to fix those error before it is allowed to be submitted to Mitchell. After receiving the validation errors, how to resolve those errors? You will see most of the errors will have hyperlink that will point you to the right data element that needs to be fixed. In this example, it is erroring on date of hire. It is saying that date of hire must be less than or equals to date of entry. In this case, you can see date of hire is in twenty seventeen, but the date of injury is showing in twenty fourteen. So that must be an typo. If you click on this, it will point you at the right data element. So to fix this error, you have to click on the edit EDI report and then fix this error by clicking on it. Once all the validation errors are fixed, the next step is to transmit this EDI report to Mitchell. By clicking transmit EDI, we are sending this data to Mitchell to be submitted to state. If Mitchell accept this without errors, you will see a t acknowledgment. That means that it is accepted by Mitchell. There are no validation errors, and this MTC will be submitted to state by Mitchell. In summary, this is the workflow we just finished. We created the EDI report in Origami, then we validated and sent it to Mitchell. If there were any validation errors, we fixed in origami and submitted to Mitchell. Goal is to get accepted by Mitchell. Once all the errors are resolved, then the acknowledgment from Mitchell is t accepted by Mitchell. Then Mitchell sent that MTC to state for timely processing. Once state process that EDA report, they will return back the acknowledgment. It can be accepted. It can be rejected. It can be accepted with errors. Whatever acknowledgment we receive, that is loaded in Mitchell’s system as well as in Origami. Here is the list of possible EDI status values that we can see coming back from Mitchell’s system. Now let’s discuss how EDI with auto trigger works and how it differs from EDI manual filing. EDI with auto trigger is a business engine which runs behind the scene and looks at the current event based on the claim data present in the origami system. It evaluates that any event based on these event scenarios is met And if that condition needs a new MTC needs to be triggered, it will trigger on its own without any manual intervention based on the rules designed by the EDI team. It can run on a historical claim. It can run on new claims. It can run on claims that are being edited on daily basis. On nightly basis, when this process runs, it evaluate the current condition of the claim data. If it needs new MTC, it will trigger that MTC. It will save it and validate against Mitchell rules if needed. And if configured, it is pretty flexible system. It can work as per client needs. If you want to have a deeper understanding of how auto trigger rules are coded and what actually these rules are doing, you can view those auto trigger rules from the EDI reports screen. If you click on more, then you will see a pop up for view EDI triggers. If you click that, it will take you to the triggers configured in system. You can sort them, arrange them based on jurisdiction you are most interested in. You can sort it based on the MTC you are looking for. Now understanding how this trigger is coded and what exactly it is doing. For example, this is Alaska Froy original trigger. So requirement for this condition to be met is it is checking there should not be any existing FROI in the system. There should not be prior AQs in the system. Claim type should be this, and it is not a denied claim because we are starting with a FROI original. If it was denied, then maybe state requires a FROI o four instead of FROI o o. So this is how you can understand what trigger is coded and what is the logic behind these triggers. If you have any questions regarding any trigger, you can reach out to the EDI team, and they are happy to help with understanding of these triggers and why what is coded and why it is coded like that. Before we conclude today’s session, there is one more important topic that I would like to cover is regarding acknowledgments. On the EDI report screen, you will see that you all the EDI reports are sorted based on the MTC date. You can filter it out based on the acknowledgment that you have received. If you filter it out by TR rejected by jurisdiction, you will see all the rejections that you have received from the state. You have to open these reports, and you have to look at the rejections that you have received from the state, and you have to fix and resubmit that EDI report. So it is based on rejection to rejection, case to case. It might differ from one EDI report to another EDI report. And this is a dummy database, so this might not be the actual rejection reason. You will see it on your EDI reports. One way to keep an eye on the EDI reports rejection is filtering your reports based on the acknowledgment status as I have shown you. Other way is to create dashboards that will give you an bird eye view of what is going on with EDI reports, what are your top rejections, which state you are receiving more rejections, what is your acceptance or rejection ratings are. You can contact your service or accounts team to get more information about this. Thanks a lot for your time. Have a good day.