Mastering Electronic Data Interchange Payments
Explore the world of Electronic Data Interchange (EDI) with expert trainers Gordon Davis and Paul Fortier. Learn the fundamentals of EDI reporting, its role in claims handling, and dive into real-world case studies to enhance your understanding. Additional insights from WCB staff Kimberlee Barriere, Deb Morton, and Carrie Pelletier make this course essential for anyone looking to streamline payment processes.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Electronic Data Interchange Payments
Trainers: Gordon Davis Paul Fortier Additional WCB Staff: Kimberlee Barriere, Deb Morton, Carrie Pelletier 2
Introduction to EDI Fundamentals of EDI Reporting EDI and Claims Handling EDI Review and Case Study 3
At the conclusion of this training session, you should be able to: Name the three basic steps in EDI reporting Recognize common EDI acronyms and define common EDI terms List the transaction processing documents 1. 2. 3. 4
At the conclusion of this training session, you should be able to: Provide examples of legal/business requirements vs EDI reporting requirements Explain the fundamentals of transaction editing and the AKC report 4. 5. 5
Electronic Data Interchange or EDI is an electronic communication system that provides standards for exchanging data via any electronic means. Reduces, or in some cases, eliminates paper reporting. Allows jurisdictions to collect more data to satisfy statutory and regulatory obligations. 7
The goal for EDI in workers compensation is the seamless processing of information from its initial reporting source to a jurisdiction. IAIABC EDI standards cover the transmission of Claims, Proof of Coverage, and Medical Bill Payment information through electronic reporting. 8
The standards are developed and maintained through a consensus process that brings together volunteers from jurisdictions, claim administrators, vendors, and others interested in participating. IAIABC EDI Claims Release 3 is the latest national standard for reporting claims information to jurisdictions. 9
While the IAIABC has developed a national standard for use by each of the jurisdictions, jurisdictional requirements vary widely. You must be familiar with the jurisdictional requirements for each of the states that you handle claims for. 10
152. AUTHORITY OF BOARD; ADMINISTRATION 2-A. Electronic filing rulemaking. The board shall adopt rules requiring the electronic filing of information required by this Act and by board rule. Consensus-based rulemaking. Standards and procedures for implementation. Specific forms required to be filed. Testing required before adoption. 11
Board Rules and Regulations Chapter 3 contains vital information regarding data element definitions, formats, values, and processing rules that may differ from those of IAIABC due to statutory or regulatory requirements. The rules also outline the distribution requirements for forms filed via paper and EDI. 12
Legal - John Rohde John.Rhode@maine.gov Technical Paul Fortier Paul.Fortier@maine.gov and/or Brad Howard Brad.Howard@maine.gov Audit Gordon Davis Gordon.Davis@maine.gov Claims - Deb Morton Debbie.Morton@maine.gov 13
Step 1: Trading partner relationship established Claim administrator completes and submits Trading Partner Documents to the jurisdiction System test is performed between the CA and the Jurisdiction CA is approved for Production environment 14
Step 2: Claim administrator sends a report to the jurisdiction Defined by the jurisdiction and the EDI standard via the Event Table and Element Requirement Table Based on a claims-handling activity (e.g. decision to pay or deny) 15
Step 3: Jurisdiction acknowledges success or failure of the report Based on the Edit Matrix Table TA = transaction accepted TR = transaction rejected It is critical that adjusters know whether a transaction has been accepted. For instance, if a denial transaction is rejected, there exists the potential for a 14-day violation 16
Trading Partner: An entity that has entered into an agreement with another entity to exchange data electronically. Trading Partner Agreement: A set of expectations and responses between two entities exchanging data electronically. These expectations include, but are not limited to, what transactions to send, what format to use, what data elements to include, when and where data elements are to be sent, and testing to be performed. 18
Data Element: A single piece of information, e.g., Date of Injury, Date of Birth, etc. Data elements are: Defined Assigned a Data Element Number or DN Assigned values or codes, if applicable Assigned valid applicable edits Assigned a data format Record: A group of related Data Elements to form a transaction. 19
Transaction: Can consist of 1 or more records to communicate a claim event. Each Transaction Type is contained in a batch, which is preceded by a Header Record and concluded with a Trailer Record. Transmission: Consists of one or more batches sent or received during a communication session. 20
The FROI is a record sent to the jurisdiction to comply with the jurisdiction s First Report of Injury requirements. The SROI is a record sent to the jurisdiction to comply with the jurisdiction s Subsequent Report of Injury requirements. 21
The FROI record is identified by the Transaction Set ID 148 (fixed length record). This record must be paired with its companion record R21(variable length record) to complete the FROI transaction. The SROI record is identified by the Transaction Set ID A49 (variable length record). This record must be paired with its companion record R22 (variable length record) to complete the SROI transaction. . 22
A Periodic report is a type of SROI transaction that must be filed at regular intervals (monthly, quarterly, sub- annual, annual, etc.). The State of Maine only requires one periodic report (MTC SA). This report is required every 180 days until a FN is filed (think WCB-11 Statement of Compensation Paid). 23
The Maintenance Type Code or MTC is a code defining the specific purpose of individual records within the transaction being transmitted. In other words, the MTC is the type of FROI or SROI transaction being transmitted, e.g. Original FROI, Initial Payment, Partial Denial, etc. 24
The Benefit Type Code or BTC is a code identifying the payment being made. The Other Benefit Type Code or OBT is a code identifying miscellaneous benefits not otherwise specifically defined with a Benefit Type Code. 25
The Acknowledgement Record or AKC is a transaction returned by the jurisdiction as a result of a report sent. It contains enough data elements to identify the original transaction and any technical and business issues found with it. 26
Data Element Single piece of information 1 Record Group of related data elements 2 Transaction Group of records 3 27
Batch Each transaction type is a batch 4 Transmission One or more batches 5 Acknowledgement Report Each transaction TA or TR 6 28
Standard Elements: IA Implementation Guide ME Implementation Guide Trading Partner Tables 29
The IAIABC EDI Implementation Guide For Claims includes information regarding the following: Jurisdiction EDI Preparation Technical Documentation and Acknowledgment Scenarios Business/Technical Process Rules Business Scenarios Data Dictionary 30
The MWCB EDI Implementation Guide For Claims includes information specific to processing Maine workers compensation claims including: Closure requirements Paper filing requirements Consent Between Employer and Employee 21 Day Notice Requirements Lump Sum Settlements Permanent Impairment 31
The Data Dictionary is Section 6 of the IA Implementation Guide. It contains the IAIABC data element definitions, formats, values, and processing rules. Note: some definitions are dependent on jurisdictional requirements (see the MWCB EDI Implementation Guide For Claims . Example - Initial Date Disability Began DN0056: Per Board rules, when an employee is paid 1/2 day or more wages on the date of injury, the date of injury will not be considered a day of incapacity. 32
Standard Tables: When to report = Event Table What to report = Element Requirement Table How jurisdiction validates the data = Edit Matrix (actually consists of 5 separate tables) 33
The Event Table provides the information necessary for the claim administrator to understand the jurisdiction s EDI reporting requirements. It relates EDI information to claim events and under what circumstances and when the claim administrator must report those events. 34
Report Triggers these are events in the life of a claim that cause a particular report to be filed with the jurisdiction (payments, denials, changes, suspensions, reinstatements, closure, etc.) Each report trigger has a corresponding maintenance type code (MTC) which is a code defining the specific purpose of individual records within the transaction being submitted. 35
Basically the old paper forms are replaced by EDI reports that are identified by MTC. You will need to learn the MTC codes the same way you learned the paper form numbers. The Event Table provides a form to MTC crosswalk. 36
Non-payments: 04 CD PD Suspensions: S1 S2 S4 S5 S6 S7 S8 S9 SD Initial Payments: AP EP IP One-time Payments: PY 37
Changes to Benefits: CA CB Periodic Reports: SA Resumption of Benefits: ER RB Claim Closure: FN 38
Refer to your Event Table: Which MTC(s) correspond to the following event triggers: Denial of a claim (full v. partial) Initial payment of a claim Suspension of benefits (EE RTW) Lump sum settlement 39
The Element Requirement Table is designed to let claim administrators know the jurisdiction s business data element requirements. Lists the data elements for each electronic report (i.e. each MTC) as required by statute, rule, or current version of EDI and includes the condition that triggers a conditional data element be sent to the Board. 40
Every piece of data is numbered and represented by a DN. The Data Dictionary contains all the data elements along with their definitions, formats, values, and processing rules. The Quick Code Reference List identifies the valid code values for each data element. 41
In Maine, the requirement codes generally fall into one of the following: Fatal (F) or Fatal Conditional (FC) Mandatory (M) or Mandatory Conditional (MC) If available (IA) Not applicable (NA) Exclude (X) These data requirement codes also tell you how critical each data requirement is for each report type/MTC. 42
Variable Segments: Permanent Impairments Death Dependent/Payee Relationships Benefits Payments Other Benefits Benefit ACR Recoveries Reduced Earnings Concurrent Employers Full Denial Reason Codes Denial Reason Narratives Suspension Narratives 43
Refer to your Element Requirement Table: Which data element on the A49 record is required on an IP transaction, if available on an AP transaction, and excluded from an EP transaction? What condition triggers the requirement for the Employee Tax Filing Status Code (DN 158)? 44
Report indemnity benefits: Currently being paid ( Event ) Have been paid ( Sweep ) 45
Event Benefit Segment MTCs: 02, AP, CA, CB, EP, ER, IP, PY (Benefit Type Codes other than 5XX), RB, S1-S9, SD Sweep Benefit Segment MTCs:02 (if benefit segment data is not changing), 04, CD, PD, FN, PY (Benefit Type Codes 5XX), SA 46
When a benefit type is being affected (i.e. starting, changing from/to, or suspending) or when reporting a lump sum payment with a Benefit Type Code other than 5XX, the MTC is sent in the benefit segment of the affected benefits. 47
If the claim administrator has paid any indemnity benefits, every SROI transaction must contain a Sweep Benefit Segment for every benefit type paid. Previously reported benefits must be reported on each subsequent SROI transaction unless explained via certain codes. 48
A Sweep Benefit Segment is sent with any Event Benefit Segment if a different Benefit Type Code has previously been paid and is not part of the Event that is currently being reported. The segment is a snapshot of benefits that have been paid on the claim at the time of the report. 49
Segment includes: Benefit Type Code, Benefit Period Start Date, Benefit Period Through Date, Benefit Type Claim Weeks, Benefit Type Claim Days, Benefit Type Amount Paid Segment does not include: MTC (that would imply an Event ), Gross Weekly Amount, Gross Weekly Amount Effective Date, Net Weekly Amount, Net Weekly Amount Effective Date, Benefit Payment Issue Date 50
