State of Minnesota

Department of Labor and Industry
Workers’ Compensation Division

Electronic Data Interchange

Implementation Guide

March 1, 2005

Table of Contents
1 INTRODUCTION
1.1 EDI Concepts 1.2 Advantages of EDI

1
1 2

2 EDI IN MINNESOTA
2.1 IAIABC 2.2 EDI Communications 2.3 EDI Transactions 2.4 Future Capabilities

4
5 6 9 11

3 EDI – IAIABC RELEASE 1
3.1 Transaction Types 3.2 Record Formats 3.3 Validation Rules

12
12 13 18

4 EDI – IAIABC RELEASE 3
4.1 Transaction Types 4.2 Record Formats 4.3 Validation Rules

22
22 24 31

5 EDI TRADING PARTNER QUALIFICATION 6 EDI FREQUENTLY ASKED QUESTIONS (FAQ)

40 44

Minnesota Department of Labor and Industry EDI Implementation Guide 1 Introduction
The Minnesota Department of Labor and Industry (DLI), Workers’ Compensation Division, started its Electronic Data Interchange (EDI) program with one trading partner in 1993. Since that time, the EDI program has evolved and there are now many companies that trade EDI information with the department. The rate of EDI submissions is expected to have steady growth in the future as the department encourages the business community to operate in an increasingly paperless environment. The EDI program at DLI has streamlined the submission of First Report of Injury (FROI) data from our many trading partners and eliminated the handling of paper FROI forms whenever possible. Recent statistics show an ever increasing percentage of the initial FROI submissions are received via EDI processing. This percentage is expected to grow substantially as additional insurance companies, self-insured employers and third-party administrators embrace the benefits of EDI.

1.1 EDI Concepts Electronic Data Interchange makes it feasible for computer systems that store data in disparate proprietary data formats to effectively communicate with one another in an efficient manner. EDI enables a commonly understood and standardized format of the relevant data to be transmitted from one computer system to another with minimal human intervention. EDI transactions are structured for highly automated processing. EDI is widely used in industry to transmit traditional “documents,” such as invoices or purchase orders, between companies. The standardized transaction set has been refined, expanded and developed so that there are now hundreds of different “documents” that can be electronically exchanged between multiple trading partners. The electronic transmission of these transactions is an efficient means of conducting business. The Internet has enabled EDI transactions to be transmitted between trading partners in an even more efficient manner. The Internet provides business and government agencies with an environment that is open, fast, cost effective, and widely accepted and used. The Minnesota Department of Labor and Industry offers several communications methods with which trading partners can exchange EDI transactions with the department. The concept of a value-added network (VAN) is a mechanism that facilitates the transfer of electronic data between trading partners. A VAN can be thought of as a post office that allows an entity to send EDI formatted data to one of their trading partners at any time. The VAN will hold the file of transmitted transactions until the trading partner to whom it is addressed retrieves it at a later time. The Advantis VAN is widely used within the insurance industry to trade information between insurance companies, employers, third-party administrators and state jurisdictions.

Introduction

1

Minnesota Department of Labor and Industry EDI Implementation Guide
1.2 Advantages of EDI The electronic submission of workers’ compensation claim information has many advantages compared with the submission of paper claims. The benefits and advantages are shared by both the trading partner submitting EDI information, as well as the Minnesota Department of Labor and Industry. • • • • • Improved Reporting Performance Time Savings Cost Savings Improved Accuracy Enhanced Flexibility

Improved Reporting Performance Electronic submissions are a much more efficient way to transmit the legally required information related to workers’ compensation claims. Claim administrators can electronically send the required claim information without generating a paper copy that would need to be sent through the traditional mail system. Typically the electronically submitted EDI data will be received, processed and acknowledged within hours of when it was submitted, rather than the multiple days it would take through the postal system. The timely submission of claim information is of primary importance to both the Workers’ Compensation Division and the claim administrators. EDI allows the departments’ trading partners to meet their reporting deadlines in a timely manner. Time Savings EDI claim submission provides an efficient means of getting the correct information to the department as quickly as possible. EDI saves time by eliminating the overhead of the paper handling that is required and is otherwise necessary for both the trading partner and the department. The use of EDI for claim submission also streamlines the process of error reporting by eliminating the phone calls that might otherwise be necessary to ensure that accurate information is being reported. Cost Savings Although there are initial costs involved with designing, developing and implementing a new EDI system, these costs can be recouped and the system can pay for itself many times over by the efficiencies garnered by the use of EDI. The cost of mailing and handling paper documents is completely avoided when the documents are sent electronically.

Introduction

2

Minnesota Department of Labor and Industry EDI Implementation Guide
Personnel at both ends of the electronic transaction that would otherwise be involved in the handling of paper generated claim information can be redeployed to other tasks. There are fewer people required to monitor and administer the EDI system than is necessary to process paper documents. Improved Accuracy EDI reduces the number of times the same data needs to be redundantly entered into multiple computer systems. There is also the inherent efficiency and improved accuracy from the electronic acknowledgment process that allows for the senders’ transactions to be verified and validated immediately upon receipt. The acknowledgment process allows the trading partner to submit more timely and accurate information while at the same time reducing the amount of time that it takes to correct invalid or inaccurate claim information. Enhanced Flexibility Electronic data can be sent any time, day or night, to ensure that the most accurate and timely information is delivered in an efficient manner. The EDI submission of first report transactions can be scheduled to run when the computing resources are at a lower demand (i.e. during non-peak utilization periods).

The Minnesota Department of Labor and Industry, Workers’ Compensation Division, invites you to explore the possibility of participating in our EDI program and enjoying the many benefits available. The advantage of electronic submission allows for superior communications between the department and our trading partners which in turn leads to increased accuracy, improved timeliness and reduced costs.

Introduction

3

Minnesota Department of Labor and Industry EDI Implementation Guide 2 EDI in Minnesota
The EDI environment at the Minnesota Department of Labor and Industry is designed to accept transactions from known trading partners throughout the world. The department is a member organization of the International Association of Industrial Accident Boards and Commissions (IAIABC). The IAIABC creates, maintains and publishes EDI standards that are specific for workers’ compensation insurance claims. There are several alternative communications mechanisms available to facilitate the exchange of EDI data between the department and our trading partners, which are typically insurers, self-insured employers and third-party administrators.

EDI Connection

Trading Partner 1

Trading Partner 2

Trading Partner 3

Trading Partner 4

New Trading Partners...

EDI Transactions processed and acknowledgments returned to trading partners

State of Minnesota Department of Labor and Industry

EDI in Minnesota

4

Minnesota Department of Labor and Industry EDI Implementation Guide
2.1 IAIABC The International Association of Industrial Accident Boards and Commissions (IAIABC) is an association of administrators from various state workers’ compensation agencies. The objective of the IAIABC is to recommend, create, develop and maintain standards for improving and strengthening workers’ compensation laws and their administration. Among the member organizations with representation to the IAIABC are the state administrative agencies, insurance carriers, the National Council on Compensation Insurance (NCCI), the National Association of Insurance Commissioners (NAIC), selfinsured employers and other vendor organizations. The IAIABC has developed standards that can be used by the state jurisdictions and the various claim administrators that are required by law to report information about workers’ compensation claims. The IAIABC published Release 1 (R1) of the IAIABC standards in 1995. Release 2 (R2) of the IAIABC standards was published in 1997 and is primarily used by Iowa. The IAIABC Release 3 (R3) standard, also known as the Combined Claim Product (CCP), was published in 2004. The IAIABC Release 3 standard is upward compatible from Release 1 and was designed to resolve outstanding issues with both Release 1 and Release 2. There are approximately 30 state jurisdictions that currently participate in or are planning to use EDI communications with their trading partners, using the various IAIABC release standards. Many of the states mandate the use of EDI communications with the claim administrators and other companies that are required to report in their jurisdiction. The EDI program remains voluntary at the Minnesota Department of Labor and Industry, however the filing of EDI claims may be mandated at some point in the future. The Minnesota Department of Labor and Industry has supported and used the IAIABC Release 1 standard in all EDI communications with our trading partners since the inception of the EDI program. The department started accepting EDI communications based on the IAIABC Release 3 standard in 2005. The department will continue to support and use the IAIABC Release 1 standard with existing trading partners for the foreseeable future. However new trading partners, and existing trading partners wishing to upgrade, are encouraged to start using the IAIABC Release 3 standard for EDI communications. Claim administrators interested in participating in the department’s EDI program should reference the IAIABC website and acquire the appropriate IAIABC EDI Implementation Guide. IAIABC Contact Information Phone Fax Website (608) 663-6355 (608) 663-1546 http://www.iaiabc.org

EDI in Minnesota

5

Minnesota Department of Labor and Industry EDI Implementation Guide
2.2 EDI Communications Trading partners with the department typically batch up their EDI transactions, currently new and updated First Report of Injury (FROI) transactions, and transmit the transactions as EDI data files at a scheduled time during their business day. The EDI transactions from each trading partner are subsequently processed and acknowledgment files are transmitted back to each trading partner. The acknowledgment process provides an indicator to the success or failure of each transmitted EDI transaction. The Minnesota Department of Labor and Industry currently processes EDI transmissions twice each business day. The EDI data files are picked up from the various EDI communications interfaces and processed at 7:00am and 4:30pm. EDI acknowledgment files are delivered back through the same communications interfaces as the EDI data files were received. The Minnesota Department of Labor and Industry offers several ways to communicate with the department via EDI. • • • • • Direct Connect (DLI FTP Server) Advantis VAN Red Oak E-Commerce Solutions (Workcomp.NET) Bridium (ClaimPortTM Transmitter) HealthTech

Prospective trading partners are required to indicate on their EDI Trading Partner Profile documentation which EDI communications environment that they plan to use.

Direct Connect
The department allows trading partners to directly connect to the DLI FTP server using secure FTP using SSL/TLS encryption. This will typically be the most cost effective EDI communications solution as it avoids all value-added network (VAN) charges. Trading partners are permitted to send and receive EDI transmissions at any time. The trading partners who wish to communicate with the department using the direct connect interfaces will be required to have an FTP/SSL client, which must be configured with a specific IP address and port number. The trading partner will be given a user name and password that will provide access to the trading partners’ mailboxes on the DLI FTP server. Each trading partner will be required to generate an SSL certificate signing request (CSR), which must be signed and returned via secure e-mail by the EDI Coordinator at DLI. The SSL certificate signing request can be generated using the FTP/SSL client.

EDI in Minnesota

6

Minnesota Department of Labor and Industry EDI Implementation Guide
There are several options for FTP/SSL clients including Kermit v8.0 on Linux and WS FTP Pro v8.03 on Windows platforms. A list of FTP/SSL clients that are available on a variety of platforms can be found by using a World Wide Web (www) search engine with the keywords “FTP/SSL clients.”

Advantis
A value-added network (VAN) acts as an intermediary between trading partners, allowing them to send and receive EDI transmissions independently of one another. A VAN is similar to the post office for traditional mail, allowing the sender to deposit the EDI data files until they are subsequently retrieved by the intended recipients. A common VAN that is widely accepted and used within the insurance industry is the Advantis VAN. The Advantis VAN is used by many of the departments’ trading partners to send and receive EDI data. The Advantis network defines each trading partner by a unique account and user ID, collectively known as the mailbox. The Minnesota Department of Labor and Industry has two Advantis mailboxes, one for testing with our new trading partners and another for production processing. The naming convention for an Advantis mailbox is to name both the account and user ID (i.e. MLI7.MLI7889 and MLI7.MLI7887). • • MLI7.MLI7889 (Test) MLI7.MLI7887 (Production)

Trading partners interested in using the Advantis VAN for EDI communications with the department should make arrangements to set up an account and user ID on the Advantis VAN. Advantis VAN Contact Information G-International Website 877-326-6426 (formally IBM e-Commerce Services) http://edi.services.ibm.com

Workcomp.NET (a Red Oak E-Commerce Solutions, Inc. (ROES) company)
Red Oak E-Commerce Solutions, Inc. offers a full range of products and services to provide EDI and E-Commerce capabilities in the workers’ compensation industry. Their products and services are available to claim administrators, insurance companies, selfinsured employers and state agencies. Red Oak E-Commerce Solutions offers the Workcomp.NET product, which is an internet based product that allows their customers to comply with the states’ EDI reporting requirements.

EDI in Minnesota

7

Minnesota Department of Labor and Industry EDI Implementation Guide
Trading partners interested in using Workcomp.NET for EDI communications with the department should make arrangements with Red Oak E-Commerce Solutions to acquire the necessary software and communications capabilities. Red Oak E-Commerce Contact Information Toll Free Phone Fax Website 866-363-4297 512-363-4297 512-363-4298 http://www.roesinc.com

Bridium (ClaimPortTM Transmitter)
Bridium offers a product called ClaimPortTM Transmitter, a Windows based transceiver that can be engaged by the user to send and receive reports and acknowledgments simultaneously. This product is designed for facilitating the extraction of FROI, SROI, POC, and Medical reports from an existing insurance management system. It also is the version that is installed at the state jurisdictions. Trading partners interested in using the ClaimPortTM Transmitter for EDI communications with the department should make arrangements with Bridium to acquire the necessary software and communications capabilities. Bridium Contact Information Phone Fax Website 866-448-1776 256-882-1810 http://www.bridium.com

HealthTech
HealthTech offers several products that differ depending on the volume of transactions to be sent. The Reporter product can be used for internet-based claim entry on the HealthTech server. The Exchange product allows claims to be entered in a claim management system and then sent to the HealthTech Internet server for review and entry of missing data. The Manager product provides an integrated EDI claim management solution that interacts with a claim management system with real-time communications, thus eliminating the need for duplicate data entry. Trading partners interested in using the HealthTech products for EDI communications with the department should make arrangements with HealthTech to acquire the necessary software and communications capabilities.

EDI in Minnesota

8

Minnesota Department of Labor and Industry EDI Implementation Guide
HealthTech Contact Information Phone Fax Websites 913-764-9347 913-764-0572 http://www.health-tech.net http://www.htedi.com

2.3 EDI Transactions There are several types of EDI products that have been defined by the IAIABC to facilitate the exchange of workers’ compensation information between the state jurisdictions and the claim administrators that are required to report. These EDI products are designed to transfer different types of data between trading partners. The primary EDI products that are available are Claims (various releases), Proof of Coverage (POC), and Medical reporting. The Minnesota Department of Labor and Industry uses the IAIABC Claims product to provide the standards for the exchange of information related to workers’ compensation accident/injury/illness claims. The Claims product is used primarily to report First Report of Injury (FROI) and Subsequent Report of Injury (SROI) transactions. The First Report of Injury (FROI) transaction is used to transmit new and updated claim information. The Subsequent Report of Injury (SROI) transaction is used to transmit payment and medical information related to previously submitted claims. The Minnesota Department of Labor and Industry currently accepts only the First Report of Injury (FROI) transaction. A planned phase of the EDI project at the department is slated to accept the Subsequent Report of Injury (SROI) transaction at some point in the future. The Claims product has been modified throughout the years and there are several releases of the standards that are defined and available. The department currently accepts, administers and supports two of the IAIABC release standards; Release 1 and Release 3. The various IAIABC release standards define the different types of transactions that are available for processing. Each of the transactions is associated with one or more record types that are comprised of various fields. The fields within the transactions are known by specific data element numbers that are used to identify the type of data they contain. For example DN0001 is the data element number for the “Transaction Set ID” field. Certain fields in the EDI record are validated to enforce database integrity rules and to inform the departments’ trading partners (senders) whether the data is accepted, accepted with errors or rejected in its entirety. The validation of the EDI data is closely related to the acknowledgment process for the EDI data that is returned to the trading partner. As the transaction and the individual data elements are validated for consistency and

EDI in Minnesota

9

Minnesota Department of Labor and Industry EDI Implementation Guide
accuracy, acknowledgment transactions are built for the eventual transmittal back to each trading partner. There are circumstances where the transaction may be determined to be rejected based upon the contents of the transaction data elements that were sent. In the case of a rejected transaction (e.g. a missing value for a mandatory field), the acknowledgment record will be created and all further processing of the FROI transaction will not take place (i.e. nothing is written to the database). Transaction Acknowledgments The fields in the transaction data set are identified with a specific data element number, so both the sender and receiver can quickly and easily identify data fields during the validation and acknowledgment procedures. Each data element is validated according to specific rules and can potentially generate an error condition for the transaction. The acknowledgment record that is generated and eventually sent back to the trading partner informs them whether the EDI data was accepted or if there were errors that may require a secondary transmission (i.e. correction transaction - CO MTC). As each data element is validated, the acknowledgment for the submitted EDI data row is generated. The acknowledgment transaction is a variable length record that indicates the status of the overall FROI transaction and informs the trading partner about the individual data elements that had validation problems. If there were any data elements in a transaction that did not pass validation, the data element number and a corresponding error number that indicates the reason for the validation failure is generated in the acknowledgment record. The Application Acknowledgment Codes [DN0111] that can be returned with the acknowledgment record are as follows: Status Code Comments Batch rejected in its entirety. HD Transaction accepted (default if no other validation issues). TA Transaction accepted with errors (certain fields did not pass validation but TE the information was accepted and stored in the database). Transaction rejected (certain fields did not pass validation which forces TR the rejection of the EDI transaction). All acknowledgment records for a particular data set from a specific trading partner are written to a unique file that corresponds to the transmitted EDI data file that was sent. The acknowledgment transmission file also has a header and trailer record written as the first and last records, respectively.

EDI in Minnesota

10

Minnesota Department of Labor and Industry EDI Implementation Guide
2.4 Future Capabilities The EDI environment at the Minnesota Department of Labor and Industry is continually maintained and enhanced as business conditions warrant. The EDI project’s goal is to steadily increase the EDI capabilities of the department, with the anticipation of increasing the percentage of electronically received transactions. Potential future phases of the EDI project include: • • Acceptance of IAIABC Release 3 “Subsequent Report of Injury” (SROI) transactions. The possible expansion of additional communications capabilities as conditions warrant.

EDI in Minnesota

11

Minnesota Department of Labor and Industry EDI Implementation Guide 3 EDI – IAIABC Release 1
The IAIABC Release 1 standard defines multiple transaction types that can be used to transmit EDI transactions between trading partners. Of these, there are two transaction types that are defined to transmit specific information related to workers’ compensation claims: the “First Report of Injury” (148 – FROI) and the “Subsequent Report of Injury” (A49 – SROI). The other transaction types defined in the IAIABC Release 1 standard are primarily for administrative purposes and are used in union with the 148 and A49 transaction types. 3.1 Transaction Types The following transaction types are defined for the IAIABC Release 1 standard. Transaction Comments The HD1 header transaction is used to precede a batch of specific HD1 transactions (i.e. 148). There are fields within the HD1 transaction that identify the sender and inform the recipient about the transactions that follow. The use of an HD1 transaction in each transmission is required. The TR1 trailer transaction is used as the final record in a batch of EDI TR1 transactions. It is used to indicate that there are no more records to process. The use of a TR1 transaction in each transmission is required. The 148 (FROI) transaction is used to transmit new and updated First 148 Report of Injury information. There are department specific rules that are used to validate the various data elements contained in the 148 transaction. The A49 (SROI) transaction is used to transmit payment and medical A49 information related to First Reports of Injury that were previously submitted. The department does not currently accept A49 transactions. The AK1 acknowledgment transaction is used to inform the trading AK1 partner of the status of the submitted information. There is a corresponding AK1 transaction generated for each 148 transaction that is sent and processed. The IAIABC Release 1 148 transaction type has a defined set of maintenance type codes (MTC) that determine what the trading partner is attempting to do with the transmitted data. Each MTC requires slightly different processing and validation rules. Refer to the record formats (Section 3.2) for the record layout definitions for the various transactions. There are also validation rules (Section 3.3) that denote the required, mandatory, conditional and optional data elements that are dependent upon which MTC is specified in the 148 transaction. The following MTCs are defined for the 148 transaction in the IAIABC Release 1 standard. EDI – Release 1 12

Minnesota Department of Labor and Industry EDI Implementation Guide
MTC 00 01 02 Comments New First Report of Injury (FROI). The 00 MTC is fully supported in the DLI EDI environment. Cancel transaction. The 01 MTC is not supported in the DLI EDI environment. Update first report information transaction. The 02 MTC is fully supported in the DLI EDI environment. Note that there must be a claim on file, based upon the SSN and date of injury that is specified, for the transaction. Update transactions that are intended to update the value of the SSN and/or date of injury must specify both the agency claim number that is returned with the AK1 transaction for new and updated claims, and the claim administrator claim number for the claim. Denial transaction. The 04 MTC is supported in the DLI EDI environment and is processed as a new FROI (MTC 00) transaction, not a denial. A paper NL01 (NOPLD) form must still be filed to deny the claim. Correction transaction for first report information. The CO MTC is fully supported in the DLI EDI environment. This transaction is only due when in response to an acknowledgment (AK1) that indicated that there were errors. The CO MTC is treated in a manner similar to the update (MTC 02) transaction. Acquired claim transaction. The AU MTC is supported in the DLI EDI environment. A claim must be on file with the department (similar to update and correction transactions). The AU MTC is validated less rigorously than other MTC’s like the 00.

04

CO

AU

3.2 Record Formats There are different record types that are required in a batch of EDI transactions that are included in the EDI transmission file. The records must be formatted with appropriate data in the necessary fields and the records must be in the correct order in the EDI data file. A description of each record is included in this section for convenience. The record definitions can also be found in Section 4 – Transaction Standards – Flat File Formats section of the IAIABC EDI Implementation Guide – Release 1 document. This document can be found at http://www.iaiabc.org/EDI/implementation_guide_index.htm. The records in the EDI file must be ordered in the proper sequence. Each batch must have a header record (HD1) as the first record in the file. A FROI transaction consists of a single fixed-length 148 record. There can be any number of FROI transactions included in a batch. The last record in the batch must be the trailer record (TR1), which contains the counts for the entire batch.

EDI – Release 1

13

Minnesota Department of Labor and Industry EDI Implementation Guide
HD1 148 … 148 TR1 3.2.1 Header Record (HD1) The header record must be the first record in the batch. There are certain fields that must be populated with specific information so that it is known to be a Release 1 EDI file. The “Interchange Version ID” field [DN0105] in the header record made up of the “Batch Type Code” and “Release Number” data elements. The “Release Number” should specify “01” to designate that the transaction file is a Release 1 formatted EDI file. The expected “Interchange Version ID” is “14801”. There are other validation rules for a number of different fields in the header record. If there are problems with the validation of any of the fields in the header record, it may cause the entire batch to be rejected. Therefore it is important to populate all of the fields in the header record with valid information. One of the more important fields is the “Test/Production Indicator” field [DN0104]. This field must be populated with a “T” when sending test transactions or a “P” when sending production transactions.
DN HD1 Data Elements 0001 Transaction Set ID 0098 Sender ID Sender FEIN Filler Sender Postal Code 0099 Receiver ID Receiver FEIN Filler Receiver Postal Code 0100 Date Transmission Sent 0101 Time Transmission Sent 0102 Original Transmission Date 0103 Original Transmission Time 0104 Test/Production Indicator 0105 Interchange Version ID Batch Type Code Release Number Format Length A/N 3 A/N 25 A/N 9 A/N 7 A/N 9 A/N 25 A/N 9 A/N 7 A/N 9 DATE 8 TIME 6 DATE 8 TIME 6 A/N 1 A/N 5 A/N 3 A/N 2 Beg 1 4 End 3 28

29

53

54 62 68 76 82 83

61 67 75 81 82 87

EDI – Release 1

14

Minnesota Department of Labor and Industry EDI Implementation Guide
3.2.2 Trailer Record (TR1) The last record in a batch is the trailer record (TR1). The Release 1 TR1 record will specify the counts for the number of records contained within the batch (the total number of 148 records). The trailer record is also validated to ensure that it corresponds to the batch that has been received. If there are problems with the validation of the trailer record, it may cause the entire batch to be rejected.
DN TR1 Data Elements 0001 Transaction Set ID 0106 Detail Record Count Format Length A/N 3 N 9 Beg 1 4 End 3 12

3.2.3 FROI Records (148) A Release 1 FROI transaction is defined as the 148 record, which is a fixed length record. The data elements in the 148 record collectively provide the information necessary to create a First Report of Injury claim at the department. Refer to the validation rules (see Section 3.3) that describe which data elements are required or mandatory and how they are validated.
DN 0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020 0021 0022 0023 148 Data Elements Transaction Set ID Maintenance Type Code Maintenance Type Code Date Jurisdiction Agency Claim Number Insurer FEIN Insurer Name Third Party Administrator FEIN Third Party Administrator Name Claim Admin Address Line 1 Claim Admin Address Line 2 Claim Admin City Claim Admin State Claim Admin Postal Code Claim Admin Claim Number Employer FEIN Insured Name Employer Name Employer Address Line 1 Employer Address Line 2 Employer City Employer State Employer Postal Code Format Length A/N 3 A/N 2 DATE 8 A/N 2 A/N 25 A/N 9 A/N 30 A/N 9 A/N 30 A/N 30 A/N 30 A/N 15 A/N 2 A/N 9 A/N 25 A/N 9 A/N 30 A/N 30 A/N 30 A/N 30 A/N 15 A/N 2 A/N 9 Beg 1 4 6 14 16 41 50 80 89 119 149 179 194 196 205 230 239 269 299 329 359 374 376 End 3 5 13 15 40 49 79 88 118 148 178 193 195 204 229 238 268 298 328 358 373 375 384

EDI – Release 1

15

Minnesota Department of Labor and Industry EDI Implementation Guide
DN 0024 0025 0026 0027 0028 0029 0030 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 0041 0042 0043 0044 0045 0046 0047 0048 0049 0050 0051 0052 0053 0054 0055 0056 0057 0058 0059 0060 0061 0062 0063 0064 148 Data Elements Self Insured Indicator Industry Code Insured Report Number Insured Location Number Policy Number Filler Policy Effective Date Policy Expiration Date Date of Injury Time of Injury Postal Code of Injury Site Employers Premises Indicator Nature of Injury Code Part of Body Injured Code Cause of Injury Code Accident Description/Cause Initial Treatment Date Reported to Employer Date Reported to Claim Admin Social Security Number Employee Last Name Employee First Name Employee Middle Initial Employee Address Line 1 Employee Address Line 2 Employee City Employee State Employee Postal Code Employee Phone Employee Date of Birth Gender Code Marital Status Code Number of Dependents Date Disability Began Employee Date of Death Employment Status Code Class Code Occupation Description Date of Hire Wage Wage Period Code Number Days Worked Format Length A/N 1 A/N 6 A/N 10 A/N 15 A/N 18 A/N 12 DATE 8 DATE 8 DATE 8 HHMM 4 A/N 9 A/N 1 A/N 2 A/N 2 A/N 2 A/N 150 A/N 2 DATE 8 DATE 8 A/N 9 A/N 30 A/N 15 A/N 1 A/N 30 A/N 30 A/N 15 A/N 2 A/N 9 A/N 10 DATE 8 A/N 1 A/N 1 N 2 DATE 8 DATE 8 A/N 2 A/N 4 A/N 30 DATE 8 $9.2 11 A/N 2 N 1 Beg 385 386 392 402 417 435 447 455 463 471 475 484 485 487 489 491 641 643 651 659 668 698 713 714 744 774 789 791 800 810 818 819 820 822 830 838 840 844 874 882 893 895 End 385 391 401 416 434 446 454 462 470 474 483 484 486 488 490 640 642 650 658 667 697 712 713 743 773 788 790 799 809 817 818 819 821 829 837 839 843 873 881 892 894 895

EDI – Release 1

16

Minnesota Department of Labor and Industry EDI Implementation Guide
DN 0065 0066 0067 0068 148 Data Elements Date Last Day Worked Full Wages Paid for DOI Indicator Salary Continued Indicator Date of Return to Work Format Length DATE 8 A/N 1 A/N 1 DATE 8 Beg 896 904 905 906 End 903 904 905 913

3.2.4 Acknowledgment Record (AK1) A Release 1 acknowledgment transaction is defined as the AK1 record. The AK1 record is a variable length record, which contains fixed length information and a variable number of error segments depending upon the number of errors in the FROI (148) transaction that is being acknowledged. An acknowledgement batch consists of a header record as the first record, an AK1 record that corresponds to each FROI (148) transaction, and a trailer record as the last record, all in an acknowledgment transmission file that is returned to the original sender. The first 208 bytes of the AK1 record are fixed length. There is a counter in the AK1 record, (“Number of Errors [DN0114]), that indicates the number of variable error segments that are contained within the record. The data elements that exist in each variable segment will be specified the number of times that are indicated by the DN0114 error counter.
DN AK1 Data Elements Format Length Beg 0001 Transaction Set ID A/N 3 1 0107 Record Sequence Number N 9 4 0108 Date Processed DATE 8 13 0109 Time Processed TIME 6 21 0006 Insurer FEIN A/N 9 27 0014 Claim Admin Postal Code A/N 9 36 0008 Third Party Administrator FEIN A/N 9 45 0110 Acknowledgment Trans Set ID A/N 3 54 0111 Application Acknowledgment Code A/N 2 57 0026 Insured Report Number A/N 25 59 0015 Claim Admin Claim Number A/N 25 84 0005 Agency Claim Number A/N 25 109 0002 Maintenance Type Code A/N 2 134 0003 Maintenance Type Date DATE 8 136 0112 Request Code (Purpose) A/N 3 144 0113 Free Form Text A/N 60 147 0114 Number of Errors N 2 207 Variable Segments Error Info occurs up to 99 times (DN0114) 0115 Element Number N 4 1 0116 Element Error Number N 3 5 0117 Variable Segment Number N 2 8 End 3 12 20 26 35 44 53 56 58 83 108 133 135 143 146 206 208 4 7 9

EDI – Release 1

17

Minnesota Department of Labor and Industry EDI Implementation Guide
3.3 Validation Rules The data elements in the 148 record are validated for appropriate values. Some data elements are considered mandatory and will cause the FROI (148) transaction to be rejected (TR) if they are not specified or are invalid. Other data elements are mandatory and expected in each transaction and may cause the transaction to be accepted with errors (TE) if they are invalid. Still other columns are considered conditional or optional and will only be validated under certain conditions. The following requirement/edit codes are used to indicate the reporting requirements for each data element. Code
R M C O

Explanation Mandatory/Reject – transaction will be rejected (TR) without the data element. Mandatory/Error – transaction should not be sent without data element or will get TE error. Conditional – see conditional requirements for the specified data element. Optional – data should be sent if data is available, but is not required.
DN 148 Data Elements 0001 Transaction Set Id 0002 Maintenance Type Code 0003 Maintenance Type Code Date Req R (5) R (5) R Minnesota Validation Rules TR (Must be 148,HD1,TR1) TR (Must be 00,02,04,CO,AU) TR (Must be a valid date) TR (Must be <= today’s date) TR (Must be >= date of injury) TR (Must be MN) TE (Must exist for MTC 02 & CO) TR (Must exist) TE (Must be a valid IR FEIN) TR (Must exist) TE (If exists–must be valid TPA FEIN) TE (Must exist if TPA FEIN specified) TE (Must exist) TE (Must exist) TE (Must exist) TE (Must exist) TE (Must exist) TE (Must exist) TE (Must exist) TR (Must exist) TR (Must exist – UNKNOWN is invalid) TE (Must exist) TE (Must exist)

Group Trans

State Insurer

0004 Jurisdiction 0005 Jurisdiction Claim Number 0006 Insurer FEIN 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020 0021 0022 Insurer Name Third Party Admin FEIN Third Party Admin Name Claim Admin Address Line 1 Claim Admin Address Line 2 Claim Admin City Claim Admin State Claim Admin Postal Code Claim Admin Claim Number Employer FEIN Insured Name Employer Name Employer Address Line 1 Employer Address Line 2 Employer City Employer State

R (5) C (4) R R C (1) C (1) M O M M M M M M R R O M M

Employer

EDI – Release 1

18

Minnesota Department of Labor and Industry EDI Implementation Guide
Group DN 148 Data Elements 0023 Employer Postal Code 0024 0025 0026 0027 0028 0029 0030 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 Self Insured Indicator SIC Code / NAICS Code Insured Report Number Insured Location Number Policy Number Policy Effective Date Policy Expiration Date Date of Injury Time of Injury Postal Code of Injury Site Employers Premises Indicator Nature of Injury Code Part of Body Injured Code Cause of Injury Code Accident Description/Cause Initial Treatment Date Reported to Employer Req R M M O O O O O R M M M M M M M O M Minnesota Validation Rules TR (Must exist >00001 &< 99999) TE (Must be a valid ZIP code) TE (Must be ‘Y’es or ‘N’o) TE (Must be 4-byte SIC/6-byte NAICS)

Policy

Accident

TE (If exists–must be valid date) TE (If exists–must be valid date) TR (Must be a valid date) TE (Must be <= today’s date) TE (Must be valid time 0000-2400) TE (Must be a valid ZIP code) TE (Must be ‘Y’es or ‘N’o) TE (Must exist) TE (Must exist) TE (Must exist) TE (Must exist) TE (Must be a valid date) TE (Must be <= today’s date) TE (Must be >= date of injury) TE (Must be a valid date) TE (Must be <= today’s date) TE (Must be >= date of injury) TR (Must exist – valid numeric) TR (Must exist) TR (Must exist) TR (Must exist – UNKNOWN is invalid)

0041 Date Reported to Claim Admin

M

Employee

0042 0043 0044 0045 0046 0047 0048 0049 0050

Social Security Number Employee Last Name Employee First Name Employee Middle Initial Employee Address Line 1 Employee Address Line 2 Employee City Employee State Employee Postal Code

R R R O R O M M R

0051 Employee Phone 0052 Employee Date of Birth

0053 0054 0055 0056

Gender Code Marital Status Code Number of Dependents Date Disability Began

TE (Must exist) TE (Must exist) TR (Must exist >00001 & <99999) TE (Must be a valid zip code) M TE (Must exist – valid numeric) M TE (Must be a valid date) TE (Must be <= today’s date) TE (Must be <= date of injury) M (5) TE (Must be ‘M’ale or ‘F’emale) M (5) TE (Must be U,M,S) C (2) C (3) TE (If exists–must be valid date) TE (If exists–must be <= today’s date) TE (If exists–must be >= date of injury)

EDI – Release 1

19

Minnesota Department of Labor and Industry EDI Implementation Guide
Group DN 148 Data Elements 0057 Employee Date of Death Minnesota Validation Rules TE (If exists–must be valid date) TE (If exists–must be <= today’s date) TE (If exists–must be >= date of injury) M (5) TE (Must be 1,2, 8,A,B,C,9 [FLAT] or FT,PT,SL,AD,AP,PW,VO [ANSI]) O M TE (Must exist) M TE (Must be a valid date) TE (Must be <= today’s date) TE (Must be <= date of injury) M (5) TE (Must exist–AWW > $10 if not VO) M TE (Must be 1,2,4,6) O O TE (If exists–must be valid date) C (5) TE (If exists–must be ‘Y’es or ‘N’o) O TE (If exists–must be ‘Y’es or ‘N’o) O TE (If exists–must be valid date) TE (If exists–must be <= today’s date) TE (If exists–must be >= date of injury) TE (If exists–must be >= disability date) Req C (2)

Employ

0058 Employment Status Code 0059 Class Code 0060 Occupation Description 0061 Date of Hire

0062 0063 0064 0065 0066 0067 0068

Wage Wage Period Number of Days Worked Date Last Day Worked Full Wages Paid for DOI Ind Salary Continued Indicator Date of Return to Work

Special Conditions (1) Mandatory when claim handled by Third Party Administrator (2) Mandatory for fatalities (3) Mandatory for lost-time cases (4) Mandatory for MTCs 02 and CO Special Edits (5) Additional Minnesota edits: • Transaction Set ID - rejected (TR), if not 148, HD1 or TR1 • Maintenance Type Code - 01 not valid and will be rejected (TR); 04 processed only as 00, not as denial; 02, CO and AU rejected (TR) if no prior FROI found (resend as 00 as needed); AU will be processed using more limited edits • Jurisdiction - rejected (TR) if not MN • Gender Code - U not an accepted code • Marital Status Code - K not an accepted code and S treated the same as M • Employment Status Code – 3,4,5,6,7 [FLAT] or NE,RT,OS,DS,UK,ZZ [ANSI] are not accepted codes • Wage - must be greater than $10 a week unless employment status is VO • Full Wages Paid for DOI Indicator – must be a Y or N if the employee had lost time on the date of injury – otherwise this should be blank

EDI – Release 1

20

Minnesota Department of Labor and Industry EDI Implementation Guide
Accident Description/Cause Each injury description must contain enough detail for the department to code the claim using each category below; and comprehend what the claimed injury is and how it happened, to enforce compliance with the workers' compensation statutes and rules as required by M.S. 176.251. • • • • • Part of body (arm, leg, wrist, back, etc.) This must include descriptors such as right, left, both, upper, lower, etc. Nature of injury (burn, fracture, sprain, strain, cut, etc.) Source of injury (the item that was directly involved in the injury, such as tools, office machines, boxes, the ground, etc.) Type of accident (struck by, fall, overexertion, etc.) Associated objects (if another item was involved in the injury such as falling off of a ladder onto the ground)

Examples for coding purposes: • • • Left knee strain. Employee reports he was climbing in and out of the truck, when his left knee made a popping sound and has hurt since. Taking plugs off of fire hydrants using a wrench. Strained right hand and lump formed in the palm. (The type of accident is overexertion.) Fell in a manhole. Pain in the right knee and strain in the lower back.

EDI – Release 1

21

Minnesota Department of Labor and Industry EDI Implementation Guide 4 EDI – IAIABC Release 3
The IAIABC Release 3 standard defines several transaction types that can be used to transmit EDI transactions between trading partners. There are two transaction types that are defined to transmit specific information related to workers’ compensation claims: the “First Report of Injury” (FROI – 148/R21) and the “Subsequent Report of Injury” (SROI – A49/R22). The other transaction types defined in Release 3 standard are primarily for administrative purposes and are used in union with the FROI and SROI transactions. The Minnesota Department of Labor and Industry currently only accepts EDI transmissions with batches of FROI transactions. A future phase of the EDI project is planned to accept some forms of subsequent report (SROI) information. 4.1 Transaction Types The following record types are defined for transactions in the Release 3 standard. Transaction Comments The HD1 header transaction is used to precede a batch of specific HD1 transactions (i.e. 148). There are fields within the HD1 transaction that identify the sender and inform the recipient about the transactions that follow. The use of an HD1 transaction in each batch is mandatory. The TR2 trailer transaction is used as the final record in a batch of EDI TR2 transactions. It is used to indicate that there are no more records to process and to verify the number of records and transactions that were sent with the batch. The use of a TR2 transaction in each batch is mandatory. The 148 (FROI) record is a fixed length record that is used to transmit 148 new and updated First Report of Injury (FROI) information. There are department specific rules for the data elements included in the 148 record. The R21 (FROI) record is a variable length record that is a companion R21 record to the 148 (FROI) record. Each FROI transaction is comprised of a pair of 148 and R21 records. There are department specific rules for the data elements included in the R21 record. The A49 (SROI) record is used to transmit payment, medical, and other A49 subsequent reporting information related to a previously submitted claim. The department does not currently accept SROI transactions. The R22 (SROI) record is a variable length record that is a companion R22 record to the A49 (SROI) record. Each SROI transaction is comprised of a pair of A49 and R22 records. The department does not currently accept SROI transactions. The AKC acknowledgment record is used to inform the trading partner of AKC the status of the submitted transaction. There is a corresponding AKC transaction generated and returned to the trading partner for each FROI or SROI transaction that is sent and processed. EDI – Release 3 22

Minnesota Department of Labor and Industry EDI Implementation Guide
The Release 3 FROI transaction is made up of a pair of 148 and R21 records that must physically follow one another in the transmitted EDI batch. The FROI transaction has a defined set of maintenance type codes (MTC [DN0002]) that determine what the trading partner is attempting to do with the transmitted data. Each MTC requires slightly different processing and validation rules. Refer to Section 4.3 for the 148 transaction layout that denotes the mandatory, expected, conditional and optional data elements that are dependent upon which MTC is specified in the 148 transaction. The following MTCs are defined for the FROI transaction in the Release 3 standard. MTC 00 01 02 Comments New First Report of Injury (FROI). The 00 MTC is fully supported in the DLI EDI environment. Cancel transaction. The 01 MTC is not supported in the DLI EDI environment. Update first report information transaction. The 02 MTC is fully supported in the DLI EDI environment. Note that there must be a claim on file, based upon the SSN and date of injury that is specified, for the transaction. Update transactions that are intended to update the value of the SSN and/or date of injury (DOI) must specify both the jurisdiction claim number that is returned with the AKC transaction for new and updated claims, and the claim administrator claim number for the claim. Denial transaction. The 04 MTC is supported in the DLI EDI environment and is processed as a new FROI (00 MTC) transaction, not a denial. A paper NL01 (NOPLD) form must still be filed to deny the claim. Correction transaction for first report information. The CO MTC is fully supported in the DLI EDI environment. This transaction is only due when in response to an acknowledgment (AKC) that indicated that there were errors. The CO MTC is treated in a manner similar to the update (02 MTC) transaction. Upon request transaction. The UR MTC is supported in the DLI EDI environment and is processed as a new FROI (00 MTC) transaction. The jurisdiction (MN) would initiate a request for a UR MTC transaction. Under investigation transaction. The UI MTC is not supported in the DLI EDI environment. Acquired claim transaction. The AQ MTC is supported in the DLI EDI environment. A claim must be on file with the department (similar to update and correction transactions). The AQ MTC is validated less rigorously than other MTC’s like the 00. Acquired unallocated claim transaction. The AU MTC is supported in the DLI EDI environment. A claim must not be on file with the department (similar to a new transaction – MTC 00).

04

CO

UR

UI AQ

AU

EDI – Release 3

23

Minnesota Department of Labor and Industry EDI Implementation Guide
4.2 Record Formats There are several different records that are required in a batch of EDI transactions that are included in the EDI transmission file. The records must be formatted with appropriate data in the necessary fields and the records must be in the correct order in the transmission file. A description of each record is included in this section for convenience. The record definitions can also be found in Section 2 – Technical Standards of the IAIABC EDI Implementation Guide – Release 3 document. This document can be found at http://www.iaiabc.org/EDI/implementation_guide_index.htm. It is required that the records in the transmission file be received in the proper sequence. A Release 3 transmission file can include one or more batches of transactions, however it is more common to have one batch per EDI transmission file. Each batch must have a header record (HD1) as the first record in the file. Each FROI transaction is comprised of a pair of records, the first being the 148 FROI record and the second being the R21 FROI companion record. There can be any number of FROI transactions (pairs of 148/R21 records) included in a batch. The last record in the batch must be the trailer record (TR2), which contains the counts for the entire batch and transaction/record set. HD1 148 R21 … 148 R21 TR2 4.2.1 Header Record (HD1) The header record (HD1) defined in the Release 3 standards is identical in format to the header defined in the Release 1 specifications. The header record must be the first record in the batch. There are certain fields that must be populated with specific information so that it is known to be a Release 3 transmission file. The “Interchange Version ID” field [DN0105] in the header record made up of the “Batch Type Code”, “Release Number” and “Version Number”. The “Release Number” and “Version Number” should specify “30” to designate that the transaction file is a Release 3 formatted transmission file. The expected “Interchange Version ID” is “14830”. There are other validation rules for a number of different fields in the header record. If there are problems with the validation of any of the fields in the header record, it may cause the entire batch to be rejected. Therefore it is important to populate all of the fields in the header record with valid information. One of the more important fields is the

EDI – Release 3

24

Minnesota Department of Labor and Industry EDI Implementation Guide
“Test/Production Code” field [DN0104]. This field must be populated with a “T” when sending test transactions or a “P” when sending production transactions.
DN HD1 Data Elements 0001 Transaction Set ID 0098 Sender ID Sender FEIN Filler - Future Defined Usage Sender Postal Code 0099 Receiver ID Receiver FEIN Filler - Future Defined Usage Receiver Postal Code 0100 Date Transmission Sent 0101 Time Transmission Sent 0102 Original Transmission Date 0103 Original Transmission Time 0104 Test/Production Code 0105 Interchange Version ID Batch Type Code Release Number Version Number Format Length A/N 3 A/N 25 A/N 9 A/N 7 A/N 9 A/N 25 A/N 9 A/N 7 A/N 9 DATE 8 TIME 6 DATE 8 TIME 6 A/N 1 A/N 5 A/N 3 A/N 1 A/N 1 Beg 1 4 End 3 28

29

53

54 62 68 76 82 83

61 67 75 81 82 87

4.2.2 Trailer Record (TR2) The last record in a batch is the trailer record (TR2). The Release 3 TR2 record will specify the counts for the number of records contained within the batch (the total number of 148 and R21 records) in the Detail Record Count [DN0106], and the number of transactions contained within the batch (the total number of 148 and R21 pairs that make up FROI transactions) in the Transaction Count [DN0191]. The Detail Record Count should always be twice (double) the number contained in the Transaction Count for correctly assembled batches.
DN 0001 0106 0191 TR2 Data Elements Transaction Set ID Detail Record Count Transaction Count Format Length A/N 3 N 9 N 9 Beg 1 4 13 End 3 12 21

4.2.3 FROI Records (148/R21) A Release 3 FROI transaction is comprised of two records that exist in the transaction file, one directly after the other. The first record in a transaction must be the 148 record. The Release 3 148 record is similar to the Release 1 148 record, with most data elements being the same size and location in the record, and having the same meaning. However

EDI – Release 3

25

Minnesota Department of Labor and Industry EDI Implementation Guide
several data elements have been expanded from their original size (from Release 1). The expanded data elements have been made “Filler” in the Release 3 148 record and were moved to the R21 companion record. The 148 record is a fixed length record.
DN 0001 0002 0003 0004 0005 0006 0012 0013 0014 0015 0016 0021 0022 0023 0025 0027 0028 0029 0030 0031 0032 0033 0035 0036 0037 0039 0040 0041 0044 0048 148 Data Elements Transaction Set ID Maintenance Type Code Maintenance Type Code Date Jurisdiction Code Jurisdiction Claim Number Insurer FEIN Filler (Not for Use) Claim Admin Mailing City Claim Admin Mailing State Code Claim Admin Mailing Postal Code Claim Admin Claim Number Employer FEIN Filler (Not for Use) Employer Physical City Employer Physical State Code Employer Physical Postal Code Filler (Not for Use) Employer Industry Code Filler (Not for Use) Insured Location Identifier Policy Number Filler (Not for Use) Policy Effective Date Policy Expiration Date Date of Injury Time of Injury Accident Site Postal Code Filler (Not for Use) Nature of Injury Code Part of Body Injured Code Cause of Injury Code Filler (Not for Use) Initial Treatment Code Date ER Know of Injury Date Claim Admin Know of Injury Filler (Not for Use) Employee First Name Filler (Not for Use) Employee Mailing City Format Length A/N 3 A/N 2 DATE 8 A/N 2 A/N 25 A/N 9 A/N 129 A/N 15 A/N 2 A/N 9 A/N 25 A/N 9 A/N 120 A/N 15 A/N 2 A/N 9 A/N 1 A/N 6 A/N 10 A/N 15 A/N 18 A/N 12 DATE 8 DATE 8 DATE 8 TIME 4 A/N 9 A/N 1 A/N 2 A/N 2 A/N 2 A/N 150 A/N 2 DATE 8 DATE 8 A/N 39 A/N 15 A/N 61 A/N 15 Beg 1 4 6 14 16 41 50 179 194 196 205 230 239 359 374 376 385 386 392 402 417 435 447 455 463 471 475 484 485 487 489 491 641 643 651 659 698 713 774 End 3 5 13 15 40 49 178 193 195 204 229 238 358 373 375 384 385 391 401 416 434 446 454 462 470 474 483 484 486 488 490 640 642 650 658 697 712 773 788

EDI – Release 3

26

Minnesota Department of Labor and Industry EDI Implementation Guide
DN 148 Data Elements Format Length 0049 Employee Mailing State Code A/N 2 0050 Employee Mailing Postal Code A/N 9 Filler (Not for Use) A/N 10 0052 Employee Date of Birth DATE 8 0053 Employee Gender Code A/N 1 0054 Employee Marital Status Code A/N 1 0055 Employee Number of Dependents N 2 0056 Initial Date Disability Began DATE 8 0057 Employee Date of Death DATE 8 0058 Employment Status Code A/N 2 0059 Manual Classification Code A/N 4 Filler (Not for Use) A/N 30 0061 Employee Date of Hire DATE 8 0062 Wage $9.2 11 0063 Wage Period Code A/N 2 0064 Number of Days Worked Per Week N 1 0065 Initial Date Last Day Worked DATE 8 0066 Full Wages Paid for DOI Indicator A/N 1 Filler (Not for Use) A/N 1 0068 Initial Return to Work Date DATE 8 Beg 789 791 800 810 818 819 820 822 830 838 840 844 874 882 893 895 896 904 905 906 End 790 799 809 817 818 819 821 829 837 839 843 873 881 892 894 895 903 904 905 913

The second record in a FROI transaction set is the R21 record. The R21 record is the FROI companion record that must be immediately preceded by a 148 record for the same transaction. The 148/R21 pair must be for the same claim (SSN/DOI) as indicated by the “Claim Admin Claim Number”, which is data element DN0015 that exists in both the 148 and R21 record. This is necessary to ensure that the 148 record and the corresponding R21 record are for the same transaction. The R21 record is a variable length record, meaning that there are several expandable segments. The first 1600 bytes of the R21 record are fixed length. There are counters in the R21 record that indicate the number of variable segments that are contained within the record. The data elements that are indicated in the variable segments are expected for the number of times that are specified by the associated counter.
DN 0001 0295 0296 0186 0015 0187 0188 R21 Data Elements Transaction Set ID MTC Correction Code MTC Correction Code Date Filler - Future Defined Usage Jurisdiction Branch Office Code Claim Admin Claim Number Claim Admin FEIN Claim Admin Name Format Length A/N 3 A/N 2 DATE 8 A/N 8 A/N 2 A/N 25 A/N 9 A/N 40 Beg 1 4 6 14 22 24 49 58 End 3 5 13 21 23 48 57 97

EDI – Release 3

27

Minnesota Department of Labor and Industry EDI Implementation Guide
DN 0135 0010 0011 0136 0270 * 0255 0150 0157 0043 0045 0046 0047 0155 0051 0146 0290 0228 0189 0224 0314 0017 0184 0026 0007 0185 0292 0249 0118 0119 0120 0121 0122 0123 0280 0281 0018 0329 0019 0020 R21 Data Elements Format Length Claim Admin Mail Info/Attn Line A/N 50 Claim Admin Mail Primary Address A/N 40 Claim Admin Mail Second Address A/N 40 Claim Admin Mail Country Code A/N 3 Employee ID Type Qualifier A/N 1 Employee ID (DN0042/DN0154) A/N 15 Employee Last Name Suffix A/N 4 Employee Auth Release Med Recs A/N 1 Employee SSN Release Indicator A/N 1 Employee Last Name A/N 40 Employee Middle Name-Initial A/N 15 Employee Mailing Primary Address A/N 40 Employee Mailing Second Address A/N 40 Employee Mailing Country Code A/N 3 Employee Phone Number A/N 15 Death Result of Injury Code A/N 1 Type of Loss Code A/N 2 Return To Work With Same ER Ind A/N 1 Return To Work Type Code A/N 1 Physical Restrictions Indicator A/N 1 Insured FEIN A/N 9 Insured Name A/N 40 Insured Type Code A/N 1 Insured Report Number A/N 25 Filler - Future Defined Usage A/N 9 Insurer Name A/N 40 Insurer Type Code A/N 1 Insolvent Insurer FEIN A/N 9 Filler - Future Defined Usage A/N 32 Accident Premises Code A/N 1 Accident Site County-Parish A/N 20 Accident Site Location Narrative A/N 50 Accident Site Organization Name A/N 50 Accident Site City A/N 15 Accident Site Street A/N 40 Accident Site State Code A/N 2 Accident Site Country Code A/N 3 Date ER Know of Initial Disability DATE 8 Filler - Future Defined Usage A/N 1 Employer Name A/N 40 Employer UI Number A/N 15 Employer Physical Primary Address A/N 40 Employer Physical Second Address A/N 40 Beg 98 148 188 228 231 232 247 251 252 253 293 308 348 388 391 406 407 409 410 411 412 421 461 462 487 496 536 537 546 578 579 599 649 699 714 754 756 759 767 768 808 823 863 End 147 187 227 230 231 246 250 251 252 292 307 347 387 390 405 406 408 409 410 411 420 460 461 486 495 535 536 545 577 578 598 648 698 713 753 755 758 766 767 807 822 862 902

EDI – Release 3

28

Minnesota Department of Labor and Industry EDI Implementation Guide
R21 Data Elements Format Length Beg Employer Physical Country Code A/N 3 903 Employer Contact Business Phone A/N 15 906 Employer Contact Name A/N 40 921 Filler - Future Defined Usage A/N 90 961 0163 Employer Mailing Info/Attention Line A/N 50 1051 0165 Employer Mailing City A/N 15 1101 0166 Employer Mailing Country Code A/N 3 1116 0167 Employer Mailing Postal Code A/N 9 1119 0168 Employer Mailing Primary Address A/N 40 1128 0169 Employer Mailing Second Address A/N 40 1168 0170 Employer Mailing State Code A/N 2 1208 Filler - Future Defined Usage A/N 50 1210 0060 Occupation Description A/N 50 1260 0199 Full Denial Effective Date DATE 8 1310 Filler - Future Defined Usage A/N 149 1318 0522 ICD-9 CM Diagnosis Code A/N 6 1467 Filler - Future Defined Usage A/N 8 1473 0073 Claim Status Code A/N 1 1481 0074 Claim Type Code A/N 1 1482 0077 Late Reason Code A/N 2 1483 0273 ER Paid Salary in Lieu of Comp Ind A/N 1 1485 Filler - Future Defined Usage A/N 105 1486 Variable Segment Counters 0274 # Accident/Injury Desc Narratives N 2 1591 0277 # Full Denial Reason Codes N 2 1593 0276 # Full Denial Reason Narratives N 2 1595 0278 # Managed Care Organizations N 2 1597 0279 # Witnesses N 2 1599 Accident/Injury Description Narrative occurs up to 10 times (DN0274) 0038 Accident/Injury Description Narrative A/N 50 1 Full Denial Reason Code occurs up to 5 times (DN0277) 0198 Full Denial Reason Code A/N 2 1 Full Denial Reason Narrative occurs up to 3 times (DN0276) 0197 Full Denial Reason Narrative A/N 50 1 Managed Care Organizations occurs up to 2 times (DN0278) 0207 Managed Care Organization Code A/N 2 1 0209 Managed Care Organization Name A/N 40 3 0208 Managed Care Organization ID Num A/N 9 43 Filler - Future Defined Usage A/N 20 52 Witness Info occurs up to 5 times (DN0279) 0238 Witness Name A/N 40 1 0237 Witness Business Phone Number A/N 15 41 Filler - Future Defined Usage A/N 20 56 DN 0164 0159 0160 End 905 920 960 1050 1100 1115 1118 1127 1167 1207 1209 1259 1309 1317 1466 1472 1480 1481 1482 1484 1485 1590 1592 1594 1596 1598 1600 50 2 50 2 42 51 71 40 55 75

EDI – Release 3

29

Minnesota Department of Labor and Industry EDI Implementation Guide
The value of the “Employee ID Type Qualifier” data element [DN0270] is used to specify the type of “Employee ID” data element that is being provided in the transaction. The department will only accept a nine (9) digit SSN or the equivalent employee ID (department generated SSN) for the “Employee ID” data element. Therefore data element DN0270 must be either an ‘S’ or an ‘A’ and the corresponding data element for the employee ID must be provided (DN0042 or DN0154). All other employee ID type qualifiers contained in DN0270, or other employee ID data elements (DN0156, DN0152 or DN0153) will cause the transaction to be rejected.
DN0270 Value S P E G A

DN 0042 0156 0152 0153 0154

Employee ID (*) Employee SSN Employee Passport Number (TR) Employee Employment Visa (TR) Employee Green Card (TR) Employee ID Assigned by Jurisdiction

4.2.4 Acknowledgment Files (AKC) A Release 3 acknowledgment transaction is defined as the AKC record. The AKC record is a variable length record, which contains fixed length information and a variable number of error segments depending upon the number of errors in the FROI (148/R21) transaction that is being acknowledged. An acknowledgment batch consists of a header record as the first record, an AKC record that corresponds to each FROI (148/R21) transaction, and a trailer record as the last record, all in an acknowledgment transmission file that is returned to the original sender. The first 248 bytes of the AKC record are fixed length. There is a counter in the AKC record, (“Number of Errors [DN0114]), that indicates the number of variable error segments that are contained within the record. The data elements that exist in each variable segment will be specified the number of times that are indicated by the DN0114 error counter.
DN 0001 0107 0108 0109 0006 0014 0187 0110 0111 AKC Data Elements Format Length Transaction Set ID A/N 3 Record Sequence Number N 9 Date Processed DATE 8 Time Processed TIME 6 Insurer FEIN A/N 9 Claim Admin Mailing Postal Code A/N 9 Claim Admin FEIN A/N 9 Acknowledgment Trans Set ID A/N 3 Application Acknowledgment Code A/N 2 Beg 1 4 13 21 27 36 45 54 57 End 3 12 20 26 35 44 53 56 58

EDI – Release 3

30

Minnesota Department of Labor and Industry EDI Implementation Guide
DN AKC Data Elements Format Length Beg 0026 Insured Report Number A/N 25 59 0015 Claim Admin Claim Number A/N 25 84 0005 Jurisdiction Claim Number A/N 25 109 0002 MTC (From Original Trans) A/N 2 134 0003 MTC Date (From Original Trans) DATE 8 136 0112 Request Code A/N 3 144 0113 Free Form Text A/N 60 147 0114 Number of Errors N 2 207 0295 MTC Correction Code A/N 2 209 0296 MTC Correction Code Date DATE 8 211 0186 Jurisdiction Branch Office Code A/N 2 219 n/a Filler - Future Defined Usage A/N 28 221 Variable Segments Error Info occurs up to 99 times (DN0114) 0115 Element Number A/N 4 1 0116 Element Error Number A/N 3 5 0117 Variable Segment Number N 2 8 0291 Element Error Text A/N 50 10 End 83 108 133 135 143 146 206 208 210 218 220 248 4 7 9 59

4.3 Validation Rules The data elements included in the various Release 3 transactions are validated for appropriate values. The IAIABC has published worksheets for Release 3 that can be used by the trading partners to understand the reporting requirements of the jurisdiction. Several of these worksheets are pertinent to the validation of the data elements that are specified in the transactions of a Release 3 transmission file. The following IAIABC worksheets for Release 3 are available in a spreadsheet format on the Minnesota Department of Labor and Industry website http://www.doli.state.mn.us/edi.html. • • • • FROI Element Requirement Table FROI Conditional Requirements Edit Matrix Jurisdiction Data Element Valid Values

Some data elements are considered “mandatory” or “fatal” and will cause the FROI (148/R21) transaction to be rejected (TR) if they are not specified or are invalid. Other data elements are “expected” in each transaction and may cause the transaction to be accepted with errors (TE) if they are invalid. Still other columns are considered “mandatory/conditional”, “expected/conditional”, or optional (“if available” or “not applicable”) and will only be validated under certain conditions.

EDI – Release 3

31

Minnesota Department of Labor and Industry EDI Implementation Guide
The following requirement/edit codes are used to indicate the reporting requirements for each data element. Code
F M

Explanation Fatal Technical. Data elements that are essential for a transmission/transaction to be accepted Mandatory. The data element must be present and must be a valid format or the transaction may be rejected. MC Mandatory/Conditional. The data element becomes mandatory under certain conditions. If the defined condition exists, the data element is validated which may cause the transaction to be rejected. E Expected. The data element is expected on the MTC but the transaction will be accepted with errors if any validation rules fail. EC Expected/Conditional. The data element becomes expected under certain conditions. If the defined condition exists, the data element is validated which may cause the transaction to be accepted with errors if any validation rules fail. IA If Available. Data may or may not be populated. If present, the data element may be validated which may cause the transaction to be accepted with errors if any validation rules fail. NA Not Applicable. The data element is not applicable to the jurisdiction’s requirements for the MTC and may or may not be sent. X Exclude -- The data element is not applicable to the jurisdiction and may or may not be sent.
Req Minnesota Validation Rules F TR (Must be HD1,148,R21,TR1) F TR (Must be 00,02,04,CO,AQ,AU,UR) F TR (Must be a valid date) TR (Must be <= today’s date) TR (Must be >= date of injury) Jurisdiction Code F TR (Must be MN) Jurisdiction Claim Number MC TE (Must exist for MTC 02 & CO) Insurer FEIN M TR (Must exist – valid numeric) TE (Must be valid IR FEIN) Insurer Name M TR (Must exist) Claim Admin Mailing Primary Address E TE (Must exist) Claim Admin Mailing Secondary Address IA Claim Admin Mailing City E TE (Must exist) Claim Admin Mailing State Code E TE (Must exist) Claim Admin Mailing Postal Code M TR (Must be valid zip code) Claim Admin Claim Number F TE (Must exist) TR (Key match between 148 & R21) Employer FEIN E TE (Must exist) Insured Name E TE (Must exist) Employer Name M TR (Must exist) Employer Physical Primary Address EC TE (Must exist if different than mailing) Employer Physical Secondary Address IA Employer Physical City EC TE (Must exist if different than mailing)

Rec DN Data Elements ALL 0001 Transaction Set ID 148 0002 Maintenance Type Code 148 0003 Maintenance Type Code Date

148 0004 148 0005 148 0006 R21 R21 R21 148 148 148 148 R21 148 R21 R21 R21 R21 148 0007 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020 0021

EDI – Release 3

32

Minnesota Department of Labor and Industry EDI Implementation Guide
Rec DN Data Elements 148 0022 Employer Physical State Code 148 0023 Employer Physical Postal Code 148 R21 148 148 148 148 148 0025 0026 0027 0028 0029 0030 0031 Employer Industry Code Insured Report Number Insured Location Identifier Policy Number Policy Effective Date Policy Expiration Date Date of Injury Req Minnesota Validation Rules EC TE (Must exist if different than mailing) EC TE (Must exist if different than mailing) TE (Must be valid zip code if exists) E TE (Must be valid SIC or NAICS code) IA MC TR (Must be valid agency if DOER) IA IA TE (Must be valid date if exists) IA TE (Must be valid date if exists) M TR (Must be valid date) TE (Must be <= today’s date) TE (Must be <= MTC date) TE (Must be <= EE DOD if exists) TE (Must be <= disability date if exists) TE (Must be >= hire date if exists) E TE (Must be valid time 0000-2359) EC TE (Must be valid zip code if accident site location [DN0119] not specified) E TE (Must exist) E TE (Must exist) E TE (Must exist) E TE (Must exist) IA TE (Must be valid value 0-5 if exists) E TE (Must be valid date) TE (Must be <= today’s date) TE (Must be <= MTC date) TE (Must be >= date of injury) E TE (Must be valid date) TE (Must be <= today’s date) TE (Must be <= MTC date) TE (Must be >= date of injury) MC TR (Must exist – valid numeric) M TR (Must exist) M TR (Must exist) IA M TR (Must exist – UNKNOWN is invalid) IA E TE (Must exist) E TE (Must exist) M TR (Must exist) TE (Must be a valid zip code) E TE (Must exist – valid numeric)

148 0032 Time of Injury 148 0033 Accident Site Postal Code 148 148 148 R21 148 148 0035 0036 0037 0038 0039 0040 Nature of Injury Code Part of Body Injured Code Cause of Injury Code Accident/Injury Description Narrative Initial Treatment Code Date ER Had Knowledge of the Injury

148 0041 Date CA Had Knowledge of the Injury

R21 R21 148 R21 R21 R21 148 148 148

0042 0043 0044 0045 0046 0047 0048 0049 0050

Employee SSN Employee Last Name Employee First Name Employee Middle Name/Initial Employee Mailing Primary Address Employee Mailing Secondary Address Employee Mailing City Employee Mailing State Code Employee Mailing Postal Code

R21 0051 Employee Phone Number

EDI – Release 3

33

Minnesota Department of Labor and Industry EDI Implementation Guide
Rec DN Data Elements 148 0052 Employee Date of Birth Req Minnesota Validation Rules E TE (Must be valid date) TE (Must be <= today’s date) TE (Must be <= MTC date) TE (Must be <= date of injury) TE (Must be <= disability date if exists) TE (Must be <= hire date if exists) E TE (Must be M or F) E TE (Must be U, M, or S) EC TE (Must be numeric if exists) TE (Must exist if death by injury DN0146) EC TE (Must be valid date if exists) TE (Must be <= today’s date) TE (Must be <= MTC date) TE (Must be >= date of injury) TE (Must be <= death date if exists) TE (Must be >= last work date if exists) EC TE (Must be valid date if exists) TE (Must be <= today’s date) TE (Must be <= MTC date) TE (Must be >= date of injury) TE (Must exist if death by injury) E TE (Must be C,9,8,A,B,1,2) IA E Te (Must exist) E TE (Must be valid date) TE (Must be <= today’s date) TE (Must be <= date of injury) EC TE (Must exist – AWW>$10 unless vol) TE (Must exist – valid numeric) EC TE (Must be 01,02,04,06,07 unless vol) IA TE (Must be 0-7 if exists) IA TE (Must be valid date if exists) TE (Must be <= today’s date) TE (Must be <= MTC date) TE (Must be >= date of injury) EC TE (Must be Y,N if exists) EC TE (Must exist if RTW type = A) TE (Must be valid date if exists) TE (Must be <= today’s date) TE (Must be >= date of injury) TE (Must be >= disability date) IA TE (Must be O,C,R,X if exists) IA TE (Must be M,I,N,B,L,T if exists) IA TE (Must be L1,L2,L3,L4,L5,L6,L7,L8,L9, LA,C1,D1,D2,D3,D4,D5,D6, E1,E2,E3,E4,E5,E6 if exists)

148 0053 Employee Gender Code 148 0054 Employee Marital Status Code 148 0055 Employee Number of Dependents 148 0056 Initial Date Disability Began

148 0057 Employee Date of Death

148 148 R21 148

0058 0059 0060 0061

Employment Status Code Manual Classification Code Occupation Description Employee Date of Hire

148 0062 Wage 148 0063 Wage Period Code 148 0064 Number of Days Worked Per Week 148 0065 Initial Date Last Day Worked

148 0066 Full Wages Paid for DOI Indicator 148 0068 Initial Return to Work Date

R21 0073 Claims Status Code R21 0074 Claim Type Code R21 0077 Late Reason Code

EDI – Release 3

34

Minnesota Department of Labor and Industry EDI Implementation Guide
Rec HD1 HD1 HD1 Req Minnesota Validation Rules F HD (Must exist – reject batch) F HD (Must exist – reject batch) F HD (Must be valid date – reject batch) HD (Must be <= today’s date) HD1 0101 Time Transmission Sent F HD (Must be valid time 000000-235959) HD1 0102 Original Transmission Date IA HD1 0103 Original Transmission Time IA HD1 0104 Test/Production Code F HD (Must be P,T – reject batch) HD1 0105 Interchange Version ID F HD (Must be 14830 – reject batch) TR2 0106 Detail Record Count F HD (Must exist – valid numeric) HD (Must match batch – reject batch) R21 0118 Accident Site County/Parish IA R21 0119 Accident Site Location Narrative EC TE (Must exist if accident site postal code [DN0033] not specified) R21 0120 Accident Site Organization Name EC TE (Must exist if accident site location [DN0119] not specified) R21 0121 Accident Site City IA R21 0122 Accident Site Street IA R21 0123 Accident Site State Code IA R21 0135 Claim Admin Mail Info/Attn Line IA R21 0136 Claim Admin Mailing Country Code NA R21 0146 Death Result of Injury Code EC TE (Must be Y,N,U if exists) R21 0150 EE Auth to Release Medical Records Ind NA TE (Must be Y,N if exists) R21 0152 Employee Employment Visa X TR (Not accepted as employee ID) R21 0153 Employee Green Card X TR (Not accepted as employee ID) R21 0154 Employee ID Assigned by Jurisdiction MC TR (Must exist – valid numeric) R21 0155 Employee Mailing Country Code IA R21 0156 Employee Passport Number X TR (Not accepted as employee ID) R21 0157 EE Social Security Number Release Ind NA TE (Must be Y,N if exists) R21 0159 Employer Contact Business Phone IA TE (Must be valid numeric if exists) R21 0160 Employer Contact Name IA R21 0163 Employer Mailing Info/Attn Line IA R21 0164 Employer Physical Country Code IA R21 0165 Employer Mailing City E TE (Must exist) R21 0166 Employer Mailing Country Code IA R21 0167 Employer Mailing Postal Code M TR (Must exist) TE (Must be a valid zip code) R21 0168 Employer Mailing Primary Address M TR (Must exist – UNKNOWN is invalid) R21 0169 Employer Mailing Secondary Address IA R21 0170 Employer Mailing State Code E TE (Must exist) R21 0184 Insured Type Code EC TE (Must be I,S) R21 0185 Insurer Type Code EC TE (Must be I,S,G) R21 0186 Jurisdiction Branch Office Code NA DN Data Elements 0098 Sender ID 0099 Receiver ID 0100 Date Transmission Sent

EDI – Release 3

35

Minnesota Department of Labor and Industry EDI Implementation Guide
Rec DN Data Elements R21 0187 Claim Administrator FEIN R21 0188 R21 0189 TR2 0191 R21 0197 R21 0198 R21 0199 Req Minnesota Validation Rules M TR (Must exist – valid numeric) TE (Must be valid CA FEIN) Claim Administrator Name M TR (Must exist) Return to Work Type Code EC TE (Must be R,A if exists) Transaction Count F HD (Must exist – valid numeric) HD (Must match batch – reject batch) Full Denial Reason Narrative X Full Denial Reason Code X Full Denial Effective Date X TE (Must be valid date if exists) TE (Must be <= today’s date) TE (Must be >= date of injury) Managed Care Organization Code IA TE (Must be 00,01,02,03,04,05 if exists) Managed Care Organization ID Number IA Managed Care Organization Name IA TE (Must be valid if exists) Physical Restrictions Indicator NA TE (Must be Y,N if exists) Return to Work With Same ER Ind IA TE (Must be Y,N if exists) Witness Business Phone Number IA TE (Must be valid numeric if exists) Witness Name IA TE (Must be valid if exists) Accident Premises Code E TE (Must be E,L,X if exists) Employee Last Name Suffix IA Employee ID Type Qualifier M TR (Must be S,A) ER Paid Salary in Lieu of Comp Ind IA TE (Must be Y,N if exists) # of Accident/Injury Desc Narratives F TR (Must be valid numeric 00-10) # of Full Denial Reason Narratives F TR (Must be valid numeric 00-03) # of Full Denial Reason Codes F TR (Must be valid numeric 00-05) # of Managed Care Organizations F TR (Must be valid numeric 00-02) # of Witnesses F TR (Must be valid numeric 00-05) Accident Site Country Code IA Date ER Knew of Initial Disability EC TE (Must be valid date if disability date) TE (Must be <= today’s date) TE (Must be >= date of injury) Type of Loss Code IA TE (Must be 01,02,03 if exists) Insolvent Insurer FEIN EC TE (Must be valid numeric if exists) TE (Must exist if insurer type is G [DN0185]) Maintenance Type Correction Code X Maintenance Type Correction Code Date X Insured FEIN IA TE (Must be valid numeric if exists) Employer UI Number IA TE (Must be valid numeric if exists) ICD-9 CM Diagnosis Code IA

R21 R21 R21 R21 R21 R21 R21 R21 R21 R21 R21 R21 R21 R21 R21 R21 R21 R21

0207 0208 0209 0224 0228 0237 0238 0249 0255 0270 0273 0274 0276 0277 0278 0279 0280 0281

R21 0290 R21 0292

R21 R21 R21 R21 R21

0295 0296 0314 0329 0522

EDI – Release 3

36

Minnesota Department of Labor and Industry EDI Implementation Guide
Conditional Requirements Certain data elements are either “mandatory/conditional” or “expected/conditional” depending upon certain conditions in the transaction or the contents of other data elements. The data elements in the table that are indicated by the “F”, “MC” or “EC” requirement/edit codes will have additional special conditions or conditional edits applied. The IAIABC worksheets for Release 3, including the FROI Element Requirement Table and FROI Conditional Requirements, can also be referenced for information on the conditional relationships between certain data elements. The Jurisdiction Data Element Valid Values worksheet should be reviewed to determine the set of valid values for a particular data element. Note that some valid values proposed by the IAIABC are not accepted on transactions in Minnesota. The Edit Matrix worksheet contains information on the possible error message numbers that may be generated if a transaction is rejected (TR) or accepted with errors (TE) on a specific data element.

Rec DN Data Elements ALL 0001 Transaction Set ID

148 0002 Maintenance Type Code

148 0004 Jurisdiction Code 148 005 Jurisdiction Claim Number 148 0015 Claim Admin Claim Number R21 R21 0019 Employer Physical Primary Address 148 0021 Employer Physical City 148 0022 Employer Physical State Code 148 0023 Employer Physical Postal Code

Special Conditions/Conditional Edits The transaction will be rejected for any transaction set ID indicated other than (HD1, 148, R21, TR2). The SROI transactions (A49, R22) are not currently accepted. The transaction will be rejected for any MTC other than (00, 02, 04, AQ, AU, UR, CO). The MTC 01 and UI are not accepted. • 04 processed as 00 not as denial • 02,CO and AQ require an already existing FROI (resend as 00/AU as necessary) • AU and AQ processed with limited edit checking The transaction will be rejected for any jurisdiction code other than MN. The jurisdiction claim number should be sent for MTC 02 and CO. Must be a key match to claim administrator claim number between the 148 and R21 records. The employer’s physical mail address must be sent if it is different than the mailing address. The employer’s physical mail address must be sent if it is different than the mailing address. The employer’s physical mail address must be sent if it is different than the mailing address. The employer’s physical mail address must be sent if it is different than the mailing address.

EDI – Release 3

37

Minnesota Department of Labor and Industry EDI Implementation Guide
Rec DN Data Elements 148 0027 Insured Location Identifier Special Conditions/Conditional Edits The Minnesota Department of Employee Relations (DOER) is required to send the agency identifier. DN0027 is optional for all other trading partners. Accident Site Postal Code Expected if the Accident Site Location Narrative [DN0119] is not specified. Employee SSN Either the 9 digit Employee SSN [DN0042] or the Employee ID Assigned by Jurisdiction [DN0154] must be sent. Values for the Employee Employment Visa [DN0152], Employee Green Card [DN0153], and Employee Passport Number [DN0156] are not accepted as an employee ID. Employee Gender Code Expected values are M or F. The value U is not accepted. Employee Marital Status Code Expected values are U,M or S. The value K is not accepted. The value S is treated the same as M. Employee Number of Dependents Expected for fatalities indicated by the Death Result of Injury Code [DN0146]. Initial Date Disability Began Expected for lost time cases. Employee Date of Death Expected for fatalities indicated by the Death Result of Injury Code [DN0146]. Employment Status Code Expected values are C,9,8,A,B,1,2. The values 3,6,4,5,7 are not accepted. Wage Expected value greater than $10/week unless Employment Status Code [DN0058] is volunteer (9). Wage Period Code Expected value must be 01,02,04,06,07 unless Employment Status Code [DN0058] is volunteer (9). Full Wages Paid for DOI Indicator Expected values are Y,N if there was lost time on the date of injury – otherwise this should be blank. Initial Return to Work Date Expected if the Return to Work Type Code [DN0189] is 'A' (Actual). Accident Site Location Narrative Expected if the Accident Site Organization Name [DN0120] or Accident Site Postal Code [DN0033] are not specified. Accident Site Organization Name Expected if the Accident Site Location Narrative [DN0119] is not specified. Death Result of Injury Code Expected for fatalities. Employee ID Assigned by Jurisdiction Either the 9 digit Employee SSN [DN0042] or the Employee ID Assigned by Jurisdiction [DN0154] must be sent. Values for the Employee Employment Visa [DN0152], Employee Green Card [DN0153], and Employee Passport Number [DN0156] are not accepted as an employee ID. Insured Type Code Expected values are I or S. The value U is not accepted.

148 0033 148 0042

148 0053 148 0054 148 0055 148 0056 148 0057 148 0058 148 0062

148 0063

148 0066 148 0068 R21 0119

R21 0120 R21 0146 R21 0154

R21 0184

EDI – Release 3

38

Minnesota Department of Labor and Industry EDI Implementation Guide
Rec DN Data Elements R21 0185 Insurer Type Code Special Conditions/Conditional Edits Expected to indicate “guarantee fund” (G) if the Insolvent Insurer FEIN [DN0292] is specified. Also used to indicate self-insured (S). Expected values are I,S or G. Expected if the Initial Return to Work Date [DN0068] is populated. Expected values are R or A. Expected values are S or A. The values E,G and P are not accepted. Expected if the Initial Date Disability Began date [DN0056] is populated. Expected if the Insurer Type Code [DN0185] is “guarantee fund” (G).

R21 0189 Return to Work Type Code

R21 0270 Employee ID Type Qualifier R21 0281 Date ER Knew of Initial Disability R21 0292 Insolvent Insurer FEIN

Accident/Injury Description Narrative [DN0038] Each injury description must contain enough detail for the department to code the claim using each category below; and comprehend what the claimed injury is and how it happened, to enforce compliance with the workers' compensation statutes and rules as required by M.S. 176.251. • • • • • Part of body (arm, leg, wrist, back, etc.) This must include descriptors such as right, left, both, upper, lower, etc. Nature of injury (burn, fracture, sprain, strain, cut, etc.) Source of injury (the item that was directly involved in the injury, such as tools, office machines, boxes, the ground, etc.) Type of accident (struck by, fall, overexertion, etc.) Associated objects (if another item was involved in the injury such as falling off of a ladder onto the ground) Examples for coding purposes: • • • Left knee strain. Employee reports he was climbing in and out of the truck, when his left knee made a popping sound and has hurt since. Taking plugs off of fire hydrants using a wrench. Strained right hand and lump formed in the palm. (The type of accident is overexertion.) Fell in a manhole. Pain in the right knee and strain in the lower back.

EDI – Release 3

39

Minnesota Department of Labor and Industry EDI Implementation Guide 5 EDI Trading Partner Qualification
The Minnesota Department of Labor and Industry encourages all claim administrators, including insurers, self-insured employers and third-party administrators, required to submit workers’ compensation claim information to the department, to explore the possibility of submitting the information electronically. While the department does not currently have a mandatory requirement for electronic filing, this requirement may exist in the future. There are several steps that must be undertaken prior to submitting production EDI information to the Minnesota Department of Labor and Industry. The following procedures should be accomplished in order to become a trading partner with the department. 1) Contact the Minnesota Department of Labor and Industry Contact the DLI EDI coordinator at dli.edi@state.mn.us or visit the department’s website at http://www.doli.state.mn.us/edi.html to acquire a copy of the EDI Implementation Guide. The guide contains the necessary information and details regarding the requirements, guidelines, rules and limitations of the EDI environment at the department. The EDI Implementation Guide also contains pertinent information about the EDI transaction data sets that are accepted by the department, with specific information on the required, mandatory, conditional and optional fields. The department’s EDI coordinator is available to answer questions and assist with the necessary setup required to trade EDI data with the department. Additionally, the DLI EDI coordinator can provide contact information for the IAIABC, information on the various communications options, and the vendors that can provide software and VAN support for EDI communications. 2) Contact the IAIABC The next step for claim administrators to take, when considering electronic submissions to the department, is to acquire the IAIABC standards documentation for the appropriate release level. It is not necessary to be a member of the IAIABC organization in order to become a trading partner with the department. The IAIABC standards documentation contains information that is necessary to identify the processes and procedures, the transaction data set formats that are understood and supported, error codes and other supporting information. The easiest way to acquire the IAIABC documentation is from their website at http://www.iaiabc.org or they can be contacted by phone at (608) 663-6355 for additional information.

EDI Trading Partner Qualification

40

Minnesota Department of Labor and Industry EDI Implementation Guide
3) Make arrangements for EDI communications The department has several options for receiving and transmitting EDI transmissions from our trading partners. The most straight forward and cost-effective is the directconnection to the department’s EDI FTP server. This requires the trading partner to transmit their EDI data using secure FTP SSL/TLS encryption. Many of the DLI’s current trading partners use the Advantis VAN for receiving and sending their EDI transmissions. Prospective trading partners interested in using the Advantis VAN are required to have an Advantis account and mailbox to communicate with the department. The Advantis account and mailbox can be setup with GInternational (formally IBM e-Commerce Services). Information about the Advantis VAN and details about setting up an Advantis account can be found through their website at http://edi.services.ibm.com or by phone at 1-877-ECOM-IBM (1-877-326-6426). Other vendors have products, services and years of experience working with claim administrators dealing with workers’ compensation claims. Prospective trading partners are expected to use a reliable communications infrastructure to facilitate the transmission and receipt of EDI communications with the department. Refer to Section 2.2. 4) Determine which IAIABC release to use (Release 3 or Release 1) The department currently accepts the First Report of Injury (FROI) transactions using both the Release 3 and Release 1 standards. Many of the departments’ current trading partners have used the Release 1 standard for several years, and the department will continue to support and administer claims that are received using the Release 1 standards for the foreseeable future. The Release 3 standard provides for additional reporting capabilities and new trading partners are encouraged to use Release 3. Future phases of the EDI project at the department are planned to allow the acceptance of Subsequent Report of Injury (SROI) forms. This future functionality is currently planned only for the trading partners that use the Release 3 standards. 5) Plan, research, design and develop the EDI system Once the necessary documentation has been acquired and decisions have been made on which release to use, the mechanisms necessary to transmit claim information electronically can be planned, designed and developed. It is expected that this step could potentially take some time, particularly if the claim administrator has not worked with an EDI environment in the past. There are many vendors that specialize in EDI for the insurance industry, including the vendors that offer various communications capabilities to the department, that have products and services that address a claim administrator’s needs. The packaged software

EDI Trading Partner Qualification

41

Minnesota Department of Labor and Industry EDI Implementation Guide
products can potentially be integrated with existing applications to enable the EDI environment for each site. 6) Contact the DLI EDI coordinator to setup for testing After the application design and development has been completed, or the software packages have been put in place to transmit EDI data to the department, the new trading partner should contact the EDI coordinator to set up an account for testing with the department. An EDI Trading Partner Profile document should be acquired from the EDI coordinator and completed prior to testing so that the department has a full understanding of the prospective trading partner’s EDI environment. The EDI coordinator will require the EDI Trading Partner Profile to determine which communications procedures that the trading partner will be using for EDI transmissions. All prospective trading partners are expected to know and understand the reporting requirements for the mandatory, expected and conditional fields that are documented for each release standard. Each trading partner is expected to have the ability to accept and process the acknowledgment file that is produced and transmitted back to the trading partner upon the receipt of an EDI transmission. 7) Test the EDI transaction submission process All header records (Transaction Set ID “HD1” [DN0001]) should specify a “T” in the Test/Production (TP) code field [DN0104]. Trading partners who are setup to use the Advantis VAN should use the department’s test Advantis mailbox (MLI7.MLI7889). EDI transmissions that are from an unexpected trading partner (unknown account) or that do not follow the guidelines for testing will generate an acknowledgment file for a rejected batch. The test EDI transmissions will be validated for accuracy and consistency. Any problems or issues with the test EDI transmissions will be communicated back to the sending trading partner so they can be rectified before any further testing takes place. The test EDI transmissions must be successful before EDI transmissions will be enabled to the department’s production EDI environment. 8) Test the EDI acknowledgment process Each EDI transaction submitted to the department’s test EDI environment will have an acknowledgment record (Transaction Set ID “AKC” or “AK1” [DN0001] depending upon the release) returned. The trading partner should verify and validate the acknowledgment files that are returned to ensure that they are in the expected format and relay meaningful information related to the originally transmitted FROI transactions. Each transaction will return an Application Acknowledgment Code [DN0111] in the acknowledgment record that indicates either an accepted status (TA), an accepted with

EDI Trading Partner Qualification

42

Minnesota Department of Labor and Industry EDI Implementation Guide
errors status (TE) or rejected status (TR). The overriding objective of sending acknowledgments is to improve the quality of the data being submitted. Therefore it is expected that the trading partner will correct any deficiencies identified in the acknowledgment and send a correction transaction (MTC CO) or an update transaction (MTC 02) to address the issue(s). Note that transactions that are rejected (TR) are not stored in the department’s database and may potentially be considered untimely if they are not corrected and resent in the required timeframe. 9) Review EDI statistics between the department and potential trading partner During the testing phase of the EDI qualification with the trading partner, statistics will be gathered about the quality of the data being transmitted. The EDI statistics will be reviewed and analyzed by the EDI coordinator to determine whether they meet the acceptable criteria necessary to allow the trading partner to transmit EDI data to the department’s production EDI environment. Once the decision is made to move forward with EDI submissions to the department’s production environment, the EDI coordinator will enable the trading partner’s account in the production EDI environment. After the trading partner’s account has been enabled, the EDI coordinator will contact the trading partner’s EDI representative to inform them they are able to submit their EDI claims electronically into the DLI production environment during the parallel processing phase. 10) Parallel processing of claims in production (electronic and paper submissions) When the DLI EDI coordinator has enabled the trading partner’s account for production processing, the EDI transmissions should be directed to the department’s production EDI environment. The header records in the EDI batch (Transaction Set ID “HD1” [DN0001]) should specify a “P” in the Test/Production (TP) code field [DN0104]. Trading partners who are setup to use the Advantis VAN should switch their procedures to transmit to the department’s production Advantis mailbox (MLI7.MLI7887). The trading partner will be expected to submit both paper and electronic claims for a period of time to ensure that the EDI processes and communications are working correctly. The parallel processing phase can typically be expected to last from a few days to several weeks as any problems are identified and alleviated. 11) Full production implementation of EDI submissions The DLI EDI coordinator will inform the trading partner when the parallel processing phase is complete and when full production implementation can take place. All new and updated claim information accepted by the department should then be sent electronically. The submission of paper First Report of Injury (FROI) forms can be eliminated at this point.

EDI Trading Partner Qualification

43

Minnesota Department of Labor and Industry EDI Implementation Guide 6 EDI Frequently Asked Questions (FAQ)
1. Are electronic submissions (EDI) of “First Report of Injury” claims mandated in the State of Minnesota? No. However mandatory electronic filing of “First Report of Injury” (FROI) claims may be a requirement in the future. What steps are required to become a trading partner with the Minnesota Department of Labor and Industry? There is a progression of steps trading partners that are interested in the electronic submission of claim information to the department should follow: • Acquire the Minnesota Department of Labor and Industry Workers’ Compensation Division EDI Implementation Guide by contacting the EDI coordinator at dli.edi@state.mn.us or by visiting links from the department’s website at http://www.doli.state.mn.us/edi.html. • Acquire the IAIABC EDI Implementation Guide for the appropriate release standards at http://www.iaiabc.org or by calling (608) 663-6355. • Determine the communications interface that will be used to transmit and receive EDI data with the department. • Plan, research, design and develop your EDI system. • Contact the department’s EDI coordinator to initiate the testing phase and the subsequent parallel processing phase. • Prepare for full EDI production implementation (paperless). Which IAIABC release standards does Minnesota accept and support? Minnesota DLI currently accepts and supports both the IAIABC Release 3 standards and the IAIABC Release 1 standards. The department will continue to support and administer Release 1 with existing trading partners for the foreseeable future. New trading partners are encouraged to design their EDI applications and environment using the latest Release 3 standard. What EDI transactions does Minnesota accept? Minnesota DLI currently only accepts the “Claims” transactions using the IAIABC Release 3 and Release 1 standards. The “Proof of Coverage” (POC) and Medical transactions are not accepted. Within the “Claims” transactions, only the First Report of Injury (FROI) transaction is accepted.

A:

2.

A:

3. A:

4. A:

EDI – Frequently Asked Questions (FAQ)

44

Minnesota Department of Labor and Industry EDI Implementation Guide
5. Does Minnesota accept the “Subsequent Report of Injury” (SROI) transactions? No. The department currently does not accept any subsequent reporting (SROI) transactions; however, these transactions may be accepted and supported in the future based upon the IAIABC Release 3 standards. What format of EDI submissions does Minnesota accept? The department currently only accepts the flat-file format of the transactions as identified in the IAIABC Release 1 standards. The ANSI X12 format available for Release 1 is not accepted. The IAIABC Release 3 standards only allow for the flat-file format of the transactions; therefore this is the format that is accepted. What transaction record types (Transaction Set ID’s [DN0001]) should be sent with the EDI transmission? It depends on the IAIABC release that is being used. Trading partners are expected to send their EDI transmissions as batches of transactions. Each batch requires a header record as the first record in the batch, followed by at least one or more First Report of Injury (FROI) transactions, and a trailer record as the last record in the batch. EDI batches that do not follow these standards will be rejected. Release 1 HD1 (header record) 148 (1 or more FROI transactions) … TR1 (trailer record) Release 3 HD1 (header record) 148 (1 or more FROI transactions R21 comprised of both a 148 & R21) … TR2 (trailer record)

A:

6. A:

7.

A:

8. A:

Are header and trailer records required in the EDI transmission file? Yes. An EDI batch is defined by a header record as the first record in the EDI transmission file, followed by one or more FROI transactions, and a trailer record as the last record in the EDI transmission file. Batches without header or trailer records will be rejected. Can multiple batches be sent in a single EDI transmission file? Yes, however this is also dependent on the IAIABC release that is being used. Release 1 does not support multiple batches in a single EDI transmission file. Multiple batches can be sent in a single EDI transmission file when trading partners are using the Release 3 standard. The acknowledgments for each batch

9. A:

EDI – Frequently Asked Questions (FAQ)

45

Minnesota Department of Labor and Industry EDI Implementation Guide
will also be returned to the trading partner in a single acknowledgment transmission file when multiple batches are processed. 10. Which maintenance type codes (MTC’s) are accepted for FROI transactions? It depends on the IAIABC release that is being used. The maintenance type codes (MTC) that are accepted and supported for the FROI transaction are: Release 1 00 New claim 02 Update claim 04 Denial of claim CO Correction of claim AU Acquired claim Release 3 00 New claim 02 Update claim 04 Denial of claim CO Correction of claim AU Acquired/Unallocated claim AQ Acquired claim UR Upon Request

A:

11.

How should electronic submissions (EDI transactions) be transmitted to the Minnesota Department of Labor and Industry? The department accepts EDI transmissions through several different communication interfaces. A direct connection to the department’s EDI FTP server is available to trading partners who wish to use secure FTP using FTP/TLS encryption. The Advantis VAN, the Red Oak E-Commerce Solutions, Inc., Bridium and HealthTech products are communication options used by many of the departments’ current trading partners. Does Minnesota always send EDI acknowledgments? Yes. An acknowledgment transaction (either a AK1 or AKC depending upon the release being used) is generated for each FROI transaction that is received. The acknowledgment file will contain a header transaction (HD1) as the first record and a trailer transaction (either a TR1 or TR2 depending upon the release being used) as the last record in the file. Is each trading partner required to accept acknowledgment files? The department requires the acceptance and processing of acknowledgment files to obtain sufficient data quality standards. It is expected the trading partner will send correction (MTC CO) or update (MTC 02) transactions to correct any errors identified in the originally transmitted transaction. In the case of rejected transactions (TR), the trading partner must send the original transaction (MTC 00) with corrected information.

A:

12. A:

13. A:

EDI – Frequently Asked Questions (FAQ)

46

Minnesota Department of Labor and Industry EDI Implementation Guide
14. A: How often should EDI data be transmitted? This is generally dictated by the statutory reporting requirements. Each trading partner can schedule their EDI data files to be transmitted daily, multiple times during the day or at less frequent intervals throughout the week as necessary. The department currently accesses and processes EDI transmissions twice per business day, at 7:00am and 4:30pm. Does the trading partner need to continue filing paper claims? The trading partner will be required to continue filing paper claims while testing the EDI procedures with the department. The parallel processing phase of an EDI implementation requires both electronic and paper claims be submitted to the department. After full EDI production implementation occurs, the submission of paper claims can be eliminated. Does Minnesota require the use of the jurisdiction (agency) claim number? No. The jurisdiction (agency) claim number is returned in the acknowledgment file for each successful new and updated FROI transaction processed. The EDI processes do not rely on the jurisdiction claim number for additional processing of updates or corrections; the social security number (SSN) and date of injury (DOI) are used instead. However, the jurisdiction claim number can be used if the trading partner is attempting to update the SSN or date of injury on a transaction. What happens when updates are necessary for key fields (i.e. SSN or date of injury)? If the jurisdiction (agency) claim number is submitted with the FROI MTC 02 or FROI MTC CO transactions, the SSN and date of injury can be updated. If the jurisdiction claim number is not available, a paper copy of the updated First Report of Injury form or a phone call will be required to make the necessary update. When do First Report of Injury (FROI) claims need to be filed with the State of Minnesota? FROIs need to be filed with Minnesota on all claims where there is claimed lost time beyond the waiting period, which is three (3) calendar days; or where indemnity benefits have been paid, whichever comes first.

15. A:

16. A:

17.

A:

18.

A:

EDI – Frequently Asked Questions (FAQ)

47