Advanced Technical Concepts 2008 IAIABC All Committee Conference April 7-12, 2008 Austin, TX

Assistant Director WC Network Products, ISO Your Trainers: Robbie Tanner email: rtanner@iso.com Assistant Director WC Network Products, ISO IAIABC Participation: EDI Systems EDI XML Work Group Leader EDI Claims EDI Proof Of Coverage EDI Medical EDI Trainer IAIABC Training Team EDI

IT Business Analysis Consultant – Ingenix/ROES Your Trainers: Lori Raby email: lraby@roesinc.com IT Business Analysis Consultant – Ingenix/ROES IAIABC Participation: EDI Systems Committee Vice Chair EDI Claims EDI XML EDI Proof Of Coverage (POC) EDI Medical EDI Triage EDI Trainer IAIABC Training Team EDI

EDI Coordinator – Peak Performance Your Trainers: Sharon Marion email: smarion@peakpsi.com EDI Coordinator – Peak Performance IAIABC Participation: EDI Systems Committee Chair EDI XML EDI Medical EDI Claims EDI Trainer IAIABC Training Team EDI

Transactions/ Records (Fixed and Variable Length) EDI 301 Transactions/ Records (Fixed and Variable Length)

Transaction A Transaction consists of 1 or more ‘records’ to communicate an event such as a claim event or policy event.

Record A record is a group of ‘related data elements’ (which is a single piece of information) that form a transaction. Some records are fixed length and some are variable length.

Fixed Length Records A fixed length record is consistently the same number of data positions each time the record is assembled. Based on the individual record layout, the data within the record is always in the same position.

Variable Length Record A variable length record may vary each time the record is assembled. The variable length record has a minimum record length and based on the occurrence of the data being reported, a maximum record length.

Technically identified by DN0001-Transaction Set ID IAIABC Release 1 Records Technically identified by DN0001-Transaction Set ID Release 1 records are either fixed or Variable length.

IAIABC Release 3 Records Technically identified by DN0001-Transaction Set ID Release 3 records are either fixed or Variable length.

Batches/ Transmissions EDI 301 Batches/ Transmissions

Batch Each Transaction Type (transaction) is contained in a batch which is preceded by a Header Record and concluded with a Trailer Record. Header Transactions Trailer

The Header Record (HD1) precedes each batch of data. It is the first record in every batch uniquely identifies information about the batch and the data within the batch Batch along with the Trailer Record forms an “envelope” that surrounds a batch of transactions

Transactions A Transaction can consist of 1 or more ‘Records’ to report a claim event.

Release 1 uses 1 Record per Transaction to report a claim event. 148 148 = FROI A49 A49 = SROI

Release 3 requires 2 records per transaction to report a claim event. 148 + R21 = FROI 148 R21 A49 A49 + R22 = SROI R22

Release 3 records DN0015 - Claim Administrator Claim Number is populated in all Release 3 FROI and SROI records. 148 R21 A49 This “links” the companion record to its related 148 or A49 record. R22

Acknowledgment Transactions Both Release 1 and Release 3 Acknowledgment transactions use 1 record to communicate an event.

The Trailer Record designates the end of a batch of transactions provides a count of records/transactions within a batch is used to ensure that the entire batch is complete and valid along with the Header record completes the “envelope” that surrounds a batch of transactions

Header B A T FROI C Transactions H Trailer Batch example of R1 FROI transactions 8 records = 8 transactions Header 148 Record 1 148 Record 2 B A T C H 148 Record 3 FROI Transactions 148 Record 4 148 Record 5 148 Record 6 148 Record 7 148 Record 8 Trailer

Header B A T SROI C Transactions H Trailer Batch example of R1 SROI transactions 8 records = 8 transactions Header A49 Record 1 A49 Record 2 B A T C H SROI Transactions A49 Record 3 A49 Record 4 A49 Record 5 A49 Record 6 A49 Record 7 A49 Record 8 Trailer

Header B A FROI T Transactions C H Trailer Batch example of R3 FROI transactions 8 records = 4 transactions Header 148 Record 1 R21 Record 2 B A T C H FROI Transactions 148 Record 3 R21 Record 4 148 Record 5 R21 Record 6 148 Record 7 R21 Record 8 Trailer

Header B A SROI T Transactions C H Trailer Batch example of R3 SROI transactions 8 records = 4 transactions Header A49 Record 1 R22 Record 2 B A T C H SROI Transactions A49 Record 3 R22 Record 4 A49 Record 5 R22 Record 6 A49 Record 7 R22 Record 8 Trailer

Components of a Transmission FROI B A T C H FROI Transactions Header Trailer BATCH: Consists of 1 Header record, one or more Transactions and 1 Trailer record. SROI Transactions Header Trailer B A T C H SROI

Components of a Transmission FROI B A T C H FROI Transactions Header Trailer TRANSMISSION: Consists of 1 or more batches sent or received during a communication session. TRANSMISSION SROI Transactions Header Trailer B A T C H SROI SROI SROI SROI SROI SROI

Questions?

EDI 301 Data Element Formats

Data Element Data Element: A single piece of information. The Data Dictionary in the Implementation Guide provides the definitions, format, valid values and population rules for each data element.

Data Dictionary Example Specific Data Element Information

Data Element Formats Example: Dates: Type = DATE (CCYYMMDD): Data elements that are assigned the format of DATE should be populated with only a valid date. Example: December 1, 2001 should be populated with 20011201.

Data Element Formats Dates: Type = DATE: CCYYMMDD All zeros in a date field are considered to be invalid data. = invalid data ‘00000000’   Spaces indicate absence of data.

Data Element Formats Time: Type = TIME: Data elements that are assigned the format of TIME should be populated with only a valid 24-hour military time. 11:54 pm

Data Element Formats Time: Type = TIME: The valid values for military time are 000000 (midnight) through 235959 (11:59:59 p.m.). Example: HHMMSS: 142903 = 2:29:03 P.M. Spaces indicate absence of data.

Data Element Formats Numeric: Type = N: Data elements that are assigned the format of N should be populated with only a valid numeric character.

Data Element Formats Numeric: Type = N: Valid values consist of 0 - 9 and are right justified zero filled to the left. Example: 3 numeric ‘123’ in 6 byte field = 000123 000 123 Spaces indicate absence of data.

Data Element Formats Monetary Amounts: Type = $9.2: Data elements that are assigned the format of $9.2 should be populated with only a valid monetary amount.

Data Element Formats $ 0000000 50 00 Monetary Amounts: Type = $9.2: Valid entries consist of eleven numeric digits with the dollar sign assumed and the decimal point between the ninth and tenth position assumed. Example: 00000005000 = $50.00 $ 0000000 50 00 ^ Spaces indicate absence of data.

Data Element Formats Percentage: Type = 3.2: Data elements that are assigned the format of 3.2 should be populated with only a valid percentage. 125%

Data Element Formats Example: 50.00% = 05000 Percentage: Type = 3.2: Valid entries consist of 0 - 9 and are right justified zero filled to the left. Example: 50.00% = 05000 ^ The decimal point is assumed between the third and fourth position. Spaces indicate absence of data.

Data Element Formats Alphanumeric: Type = A/N: Data elements that are defined the format of A/N consist of a sequence of any characters from common character code schemes (EBCDIC, ASCII, and CCITT International Alphabet 5).

Data Element Formats SMITH Alphanumeric: Type = A/N: When using an alphanumeric field, the significant characters are always left justified in the field with any remaining space in the field padded with spaces. SMITH (spaces)

Data Element Formats Alphanumeric: Type = A/N: Alphanumeric character set includes those selected from the uppercase letters, lower case letters, numeric digits, space character, and special characters. See System Rules of the R3 Implementation Guide. Spaces indicate absence of data.

Release 1 Transactions/Records EDI 301 Release 1 Transactions/Records

HD1 – Release 1 Header Record There are 9 data elements and the record is 87 bytes fixed length

HD1 – Release 1 Header Record uniquely identifies the sender, the receiver, the date and time batch was prepared

HD1 – Release 1 Header Record whether the batch contains test or production data and the Transaction type

148 - Release 1 FROI Record 913 Byte Fixed Length Record

TR1 – Release 1 Trailer Record 12 Byte Fixed Length Record

148 – Release 1 FROI Batch/Transmission Example Transmission Sample Containing 1 Batch (Shown partial for display): HD1666777888 888777666999999999 23423424220010327074530 P14801 1480020010327PR 666777888ABC INSURER 818181818TPA TR1000000001 Header Record=HD1 FROI Transaction=148 Trailer Record=TR1 Transmission Sample Containing 2 Batches (Shown partial for display): HD1666777888 888777666999999999 23423424220010327074545 P14801 1480020010327PR 666777888ABC INSURER 818181818TPA TR1000000002 HD1666777888 888777666999999999 23423424220010327074630 P14801 TR1000000001 Header Record=HD1 FROI Transaction=148 Trailer Record=TR1

A49 - Release 1 SROI record Variable Length Record Variable segment Counters determine actual record length

Release 1 A49 Variable Segments Partial display of SROI A49 record Counters determine the overall record length One Perm Impair Two Pmt/Adj Three PTD/RE/REC Fixed length = 208 Perm Impair = 8 bytes Pmt/Adj = 46 bytes x 2 PTD/RE/REC = 14 bytes x 3 The A49 record ends at position 350

A49 – Release 1 SROI Record Batch/Transmission Examples Transmission Sample Containing 1 Batch (Shown partial for display): HD1666777888 888777666999999999 23423424220010327074916 PA491A A49IP20010314PR66677788881818181834236 29038412302N20010301 TR1000000001 Header Record=HD1 SROI Transaction=A49 Trailer Record=TR1 Transmission Sample Containing 2 Batches (Shown partial for display): HD1666777888 888777666999999999 23423424220010327074920 PA491A A49IP20010314PR66677788881818181834236 29038412302N20010301 TR1000000001 HD1666777888 888777666999999999 23423424220010327074940 PA491A A49IP20010314PR66677788881818181834236 29038412302N20010301 A49IP20010314PR66677788881818181834222 29045412302N20013045 TR1000000002 Header Record=HD1 SROI Transaction=A49 Trailer Record=TR1

A49 – Release 1 SROI Data Batch Breakdown Example HEADER RECORD: HD1810461738 599012126810302402 59604801120010914124949 PA491A A49 RECORD BASE DATA- POSITIONS 1 - 198: A49SA20010914MT81017053081046173859901 51660098300N1992021319931102119931103 VARIABLE SEGMENT COUNTERS – POSITIONS 199 - 208: 0102000300 PERMANENT IMPAIRMENT DATA WHERE COUNTER = 01 – POSITIONS 209-216: 99 00800 PAYMENT ADJUSTMENT DATA WHERE COUNTER =02 – POSITIONS 217-308: 0500000009120000000033600200202132003110200025 0400000047040000000016800200401012004072200280 PAID TO DATE/REDUCED EARNINGS/RECOVERIES DATA WHERE COUNTER = 03 – POSITIONS 309-336: 35000000020389 36000000067491 37000000167126 TRAILER RECORD: TR1000000001

Release 3 Transactions/Records EDI 301 Release 3 Transactions/Records

IAIABC Claims Release 3 Transaction Design FROI SROI Basic 148 Basic A49 R1 Fixed length Fixed length Permanent Impairments Payment Adjustments Different Adjustments Different Paid to Dates/Reduced Earnings/Recoveries Different Death Dependent Payee Anything New or Different from R1 or R2 Witness Accident/Injury Description Companion (R21) Fixed length Managed Care Org Denial Reason Codes Denial Reason Narratives Suspension Narratives Companion (R22) Benefit Reduced Earnings Adjustments, Credits, Redistributions Concurrent Employer Fixed length Recoveries Other Benefits Payments Denial Reason Codes Denial Reason Narratives R3

Release 1 data elements that differ in: Functionality definition Format become Filler in the R3 record layout.

Positions in the 148 and A49 records are preserved for R1 usage.

Modified data elements were moved to the companion record in Release 3 (R21 or R22).

Modified data elements were moved to the companion record in Release 3 (R21 or R22).

HD1 – Release 3 Header Record 87 byte Fixed Length record (Same as Release 1)

HD1 – Release 3 Header Record uniquely identifies the sender, the receiver, the date and time batch was prepared

HD1 – Release 3 Header Record whether the batch contains test or production data and the Transaction type

Release 3 FROI record 148 – 913 Byte Fixed Length Record

Release 3 FROI Companion record R21– Variable Length Record Variable segment counters determine actual record length

Release 3 SROI record A49– Variable Length Record Variable segment counters determine actual record length.

Release 3 SROI Companion record R22– Variable Length Record Variable segment counters determine actual record length.

Release 3 Variable Segments Counters determine the overall record length The transaction includes one Benefits segment Fixed length = 650 Benefits segment = 103 bytes. The R22 record ends at position 753 Partial display of SROI R22 record

Release 3 Variable Segments Counters determine the overall record length The transaction includes one Benefits segment and one Suspension Narrative Fixed length = 650 Benefits segment = 103 bytes; Suspension Narrative = 50 bytes. The R22 record ends at position 803 Partial display of SROI R22 record

TR2 – Release 3 Trailer Record designates the end of a batch of transactions provides a count of records and transactions within a batch is used to ensure that the entire batch is complete and valid

Release 3 148/R21 – First Report of Injury Batch/Transmission Example Transmission Sample Containing 1 Batch (Shown partial for display): HEADER RECORD (HD1): HD1666777888 888777666999999999 23423424220010327074530 P14830 FIRST REPORT (148 ) (Shown partial for display) : 1480020010327PR 666777888ABC INSURER 818181818TPA FIRST REPORT COMPANION RECORD (R21) (Shown partial for display) : R21000000133 21023CLMADMCLNUM 666777888ABC INSURER TRAILER RECORD (TR2): TR2000000002000000001 Interchange Version ID value for HD1: 14830 FROI Companion Record New field added to Release 3 Trailer record: Transaction Count (DN0191)

Release 3 A49/R22 – Subsequent Report of Injury Batch/Transmission Example Transmission Sample Containing 1 Batch: HEADER RECORD (HD1): HD1666777888 888777666999999999 23423424220010327074916 PA4930 SUBSEQUENT REPORT (A49 ) (Shown partial for display) : A49IP20010314PR66677788881818181834236 29038412302N20010301 SUBSEQUENT REPORT COMPANION RECORD (R22 ) (Shown partial for display): R2200000014500000013321023CLMADMCLNUM 666777888ABC INSURER TRAILER RECORD (TR2): TR2000000002000000001 Interchange Version ID value for HD1: A4930 SROI Companion Record New field added to Release 3 Trailer record: Transaction Count (DN0191)

Questions?

Break Time!

Acknowledgment Overview Electronic Report Acknowledgment Electronic Report Acknowledgment Overview

What is an Acknowledgment? A transaction returned by the jurisdiction as a result of a report sent. Claim Administrator Electronic Report Jurisdiction Acknowledgment

What is an Acknowledgment? It contains enough information to identify the original transaction and any technical and business issues.

How does the acknowledgment communicate the status of the transaction? Using the Application Acknowledgment Code (DN0111), located in each acknowledgment record.

How does the acknowledgment communicate the status of the transaction? The Application Acknowledgment Code is a code used to identify the accepted/rejected status of the transaction(s) being acknowledged.

What are the Application Acknowledgment Code Values?

Transaction Accepted (TA) The transaction was accepted by the jurisdiction No errors were found on the transaction No further reporting is required on the specific transaction

Transaction Accepted with Error (TE) An error was found on an Expected, Expected Conditional or If Applicable/Available data element An MTC CO (Correction) should be submitted to resolve the error(s)

Transaction Rejected (TR) An error was found on a mandatory or mandatory conditional data element TR The transaction was not accepted or added to the jurisdiction’s system as a reported claim

Transaction Rejected (TR) A review of the error should take place to determine what action should be taken to resolve the issue

Transaction Rejected (TR) An MTC CO (Correction) is not used to respond to a TR acknowledgment If an error of duplicate transaction, invalid event sequence, etc. then resubmission may not be required

Batch Rejected (HD) The Batch is rejected in its entirety When a Batch Reject Occurs, only one AKC record may be returned in the acknowledgment batch

Batch Reject Reasons Invalid Sender ID (In most cases, no acknowledgment batch will be returned. Sender is unknown) Invalid data in Header Record Duplicate Batch Invalid data in Trailer Record Transaction not present in the batch

An EDI Service Provider: Rejected by Service Provider (TN) An EDI Service Provider: Performs a service for their client to evaluate data prior to submission to a Jurisdiction Determines that the data fails the Jurisdiction mandatory requirements Reports errors to their client resulting in resubmission of the report to the jurisdiction

Acknowledgments: Release 1 vs. Release 3

Acknowledgement Record Layout Comparison Release 1 (AK1) Fixed When Number of Errors > 0

Acknowledgement Record Layout Comparison Release 3 (AKC) New elements and filler New Error Text

Release 1 Transaction Acknowledgment Claim Administrator sends: Jurisdiction returns: Header Header (HD1) 148 Record 1 AK1 TA Record 1 148 Record 2 AK1 TA Record 2 FROI Transactions 148 Record 3 AK1 TE Record 3 148 Record 4 AK1 TR Record 4 Trailer (TR1) Trailer

Release 3 Transaction Acknowledgment Claim Administrator sends: Jurisdiction returns: Header (HD1) 148 Record 1 AKC TA Record 1 Header Trailer FROI Transactions R21 Record 2 148 Record 3 AKC TA Record 3 R21 Record 4 148 Record 5 AKC TE Record 5 R21 Record 6 148 Record 7 AKC TR Record 7 R21 Record 8 Trailer (TR2)

Release 1 vs. Release 3 Requirement Code Result of Failed Element Requirement Requirement Code Result of Failed Element Requirement Edit M (Mandatory) TR (Transaction Rejected) C (Conditional) ** TR (Transaction Rejected) O (Optional) ** TE (Transaction Accepted with Errors) MC (Mandatory/Conditional)* TR (Transaction Rejected) E (Expected) * TE (Transaction Accepted with Errors) EC (Expected/Conditional) * TE (Transaction Accepted with Errors) IA (If Applicable/Available) * TA (Transaction Accepted) OR TE (Transaction Accepted with Errors) N/A (Not Applicable) * No requirement edits may be applied R (Restricted) * TR (Transaction Rejected) F (Fatal) * TR (Transaction Rejected) X (Exclude) * No requirement edits may be applied ** Release 1 only * Release 3 only

Acknowledgment Transmission/Batch Examples EDI 301 Acknowledgment Transmission/Batch Examples

AK1 – Release 1 Transmission/Batch Example Transmission Sample Containing 1 Batch (Shown partial for display): HD1999999999 234234242666777888 8887776662001032708134020010327074916PAK101 AK10000000012001032708164466677788834236 818181818A49TAINSRPTNUM AK10000000012001032708164466655788834236 818181818A49TEINSRPTNUM TR1000000002 Transmission Sample Containing 2 Batches (Shown partial for display): HD1999999999 234234242666777888 8887776662001032708134020010327074933PAK101 AK10000000012001032708164466677788834236 818181818148TAINSRPTNUM TR1000000001 HD1999999999 234234242666777888 8887776662001032708134020010327074944PAK101 AK10000000012001032708164466677788834236 818181818A49TAINSRPTNUM AK10000000012001032708164466655788834236 818181818A49TEINSRPTNUM TR1000000002 Header Record=HD1 Acknowledgment Transaction=AK1 Trailer Record=TR1

AKC Release 3 Transmission/Batch Example Header AKC AKC Trailer

AKC Release 3 Transmission/Batch Example Header AKC AKC Trailer Header AKC AKC AKC AKC Trailer

Release 3 - Matching original batch to AKC batch using the Header Record FROI Example HEADER RECORD (HD1) for FROI HD1666777888 888777666999999999 23423424220010327074530 P14830 1 |2 | 3 |4 |5 |6 |7 |8|9 | HD1999999999 234234242666777888 8887776662001032808134020010327074530PAKC30 HEADER RECORD (HD1) for AKC 1=Transaction Set ID (DN0001) 2=Sender ID (DN0098) to 3=Receiver ID (DN0099) 3=Receiver ID (DN0099) to 2=Sender ID (DN0098) 4=Date Transmission Sent (DN0100) to 6=Original Transmission Date (DN0102) 5=Time Transmission Sent (DN0101 to 7=Original Transmission Time (DN0103) 8=Test Production Code (DN0104) to 8=Test Production Code (DN0104) 9=Interchange Version ID (DN0105) DIFFERENT

The count should be the same. Release 3 - Matching original batch to AKC batch using Trailer Record FROI Example TRAILER RECORD (TR2) for FROI TR2000000002000000001 TR2000000001000000001 TRAILER RECORD (TR2) for AKC The count should be the same. Transaction Count (DN0191) is the total number of transactions sent as part of the batch. The FROI or SROI Transaction Count should be matched to the AKC Transaction Count.

Interpreting Acknowledgments EDI 301 Interpreting Acknowledgments

Interpreting Release 3 Acknowledgment AKC acknowledges Release 3 transactions. Jurisdiction assigned Claim Number is acknowledged.

Interpreting Release 3 Acknowledgment Date and time the transaction was processed by receiving Jurisdiction Jurisdiction returns value from original transaction, when available

Interpreting Release 3 Acknowledgment Jurisdiction calculates and returns the position of the transaction within the batch. 000000023 Acknowledged transaction is identified. MTC and MTC Date from original transaction

Interpreting Release 3 Acknowledgment Result of jurisdiction’s applied edits; Number of encountered errors.

Interpreting Release 3 Acknowledgment Number of Errors determine the overall record length AKC Fixed length = 248 The AKC includes two Error segments

Interpreting Release 3 Acknowledgment Element Error segment: 59 bytes x 2 = 118. The AKC record ends at position 366.

Interpreting Release 3 Acknowledgment The first error occurred on DN0134 Calculated Weekly Compensation Amount.

Interpreting Release 3 Acknowledgment The amount reported was less than required by the jurisdiction. Optional Element Error Text assists senders with error resolution.

Interpreting Release 3 Acknowledgment The second error occurred on DN0192 Benefit Payment Issue Date. An invalid date was reported in the second Benefits segment of the SROI transaction.

Interpreting Release 3 Acknowledgment Error Message 029 clearly describes the error; Element Error Text is optional.

Release 3 Error Correction EDI 301 Release 3 Error Correction

Error Correction Process New elements and Release 3 Correction Process provides a direct link to transactions being corrected. Maintenance Type Correction Code (MTCC): Maintenance Type Code from the transaction that is being corrected. Maintenance Type Correction Code Date (MTCC Date): Maintenance Type Code Date from the transaction that is being corrected. “Correction” DNs are in the FROI R21, SROI R22 and the acknowledgment AKC and ARC records.

Error Correction Process When a Release 3 transaction is acknowledged with a TE (Transaction Accepted with error)

Error Correction Process The CO (Correction) transaction corrects the errors. The MTCC and Date are populated with the values from the transaction that had the error.

Error Correction Process After successfully correcting the errors, the original 00 transaction is accepted. Refer to Error Correction Process in Release 3 Claims Implementation Guide for additional information.

Questions?

Establishing the EDI Partnership

STANDARD USAGE FOR ALL PRODUCTS http://www.iaiabc.org/EDI/default.asp

Partnering Agreement Jurisdiction EDI Reporter  

Trading Partner Profile     EDI Reporter 999999999 12345 6789

Receiver’s Specifications Jurisdiction mm/dd/yyyy  999999999 12345 6789 Claims 3.0 AKC EDI  2300 EST 

Sender’s Response mm/dd/yyyy Jurisdiction EDI Reporter     999999999 12345 6789 Claims 3.0 150  

Claim Administrator ID List EDI Reporter 999999999 12345 6789 mm/dd/yyyy 111111111 Best TPA 222222222 Insurance company 333333333 Self-Insured Employer

Maintaining Senders’ Authorization EDI 301 Maintaining Senders’ Authorization

Trading Partner Validation Table In order to validate Senders’ authorization to submit EDI reporting, the jurisdiction maintains a Validation Table.

Trading Partner Validation Table Example shows “keys” only Jurisdiction may store additional details such as address, EDI technical and business Contact information from the Trading Partner Agreement in addition to the “keys”.

Trading Partner Validation Table A = Approved R = Revoked In this example, authorization “status” of both the Sender and Claim Administrator/ Insurer/Self-Insured is maintained.

Authorized Sender details from the Trading Partner Profile are loaded into the jurisdiction’s Validation Table.  999999999 EDI Reporter 12345 6789 999999999 123456789 A (Approved)

Authorized Insurer/Claim Administrator IDs are loaded into the jurisdiction’s Validation Table. EDI Reporter 999999999 12345 6789 111111111 Best TPA 222222222 Insurance company 333333333 Self-Insured Employer mm/dd/yyyy 999999999 123456789 A (Approved) 111111111 A (Approved) 222222222 A (Approved) 333333333 A (Approved)

Validating Sender Authorization for the Batch EDI 301 Validating Sender Authorization for the Batch

If Sender exists with Approved status, the batch is processed. 888888888 A (Approved) 987654321 Approved 999999999 123456789 111111111 222222222 333333333 R (Revoked) During Batch Level editing, the Sender FEIN and Postal Code from the Header record are checked against the Validation Table. If Sender exists with Approved status, the batch is processed.

888888888 A (Approved) 987654321 Approved 999999999 123456789 111111111 222222222 333333333 R (Revoked) If Sender ID does not exist in the Validation Table or authorization is revoked, jurisdiction will reject the entire batch.

Validating Sender Authorization for the Claim Administrator EDI 301 Validating Sender Authorization for the Claim Administrator

888888888 A (Approved) 987654321 Approved 999999999 123456789 111111111 222222222 333333333 R (Revoked) During Transaction Level editing, the Claim Administrator FEIN from the FROI or SROI record are checked against the jurisdiction’s Validation Table.

888888888 A (Approved) 987654321 Approved 999999999 123456789 111111111 222222222 333333333 R (Revoked) If the Claim Administrator FEIN exists with Approved status the transaction is processed.

888888888 A (Approved) 987654321 Approved 999999999 123456789 111111111 222222222 333333333 R (Revoked) If Claim Administrator ID does not exist in the Validation Table or authorization is revoked, jurisdiction will reject the transaction.

Trading Partner Tables EDI 301 Trading Partner Tables Event Table Element Requirement Table Edit Matrix

EDI 301 Event Table

Event Table The Event Table is used by the Jurisdiction to convey the level of EDI reporting currently accepted. It is intended to help senders understand the jurisdictions’ EDI reporting requirements.

Event Table Describes conditions that “trigger” electronic reports Provide timeframes for sending the information Describes Report due dates based on jurisdictions’ legislative mandates and/or voluntary reporting requirements

Claims Release 1 Event Table

Interpreting Release 1 Event Table EDI 301 Interpreting Release 1 Event Table

Release 1 Event Table Jurisdiction's reporting requirements: A Report (Maintenance Type Code) is due in Production environment when FROM/THRU Dates meet the Report Trigger Criteria and value. (partially presented)

Release 1 Event Table When the Event Rule Thru date is blank, reporting requirements apply until further notice. (partially presented)

Interpreting Release 3 Event Table EDI 301 Interpreting Release 3 Event Table

Release 3 Event Table Jurisdiction's reporting requirements: A report (Maintenance Type Code) is due when the Event Rule Criteria is within Event Rule Date range (From/Thru), Partial Table presented

Release 3 Event Table with the conditions described in the Trigger Criteria and Value. Report due date is based on Report Due Value, Type and From) Partial Table presented

Release 3 Event Table When the Event Rule Thru date is blank, reporting requirements apply until further notice. Partial Table presented

Release 3 Event Table When a Paper Form is indicated, this form must be sent to the Receiver indicated in addition to the electronic report. Partial Table presented

Questions?

Element Requirement Table EDI 301 Element Requirement Table

Element Requirement Table The Element Requirement Table describes the data elements that are required for each FROI/SROI report indicated on the jurisdiction’s Event Table.

Element Requirement Table Requirement Codes were developed to express the severity of the jurisdiction's requirement for each data element and report type (FROI, SROI).

Element Requirement Table Requirement Code Values: RELEASE 1 AND RELEASE 3 M (Mandatory) RELEASE 1 ONLY RELEASE 3 ONLY C (Conditional) E (Expected) O (Optional) EC (Expected/Conditional) IA (If Applicable/Available) N/A (Not Applicable) MC (Mandatory/Conditional) F (Fatal) X (Exclude) R (Restricted)

Element Requirement Table Requirement Code Values: Systems/Processing Requirement Code: F = Fatal Technical. Data elements that are essential for a transaction to be accepted into a jurisdictions workers compensation administration database or acknowledgment back to the claim administrator. Release 3 only.

Element Requirement Table Requirement Code Values: Systems/Processing Requirement Code: X = Exclude. The data element is not applicable to the MTC. Release 3 only. Example: DN# 0005 – Jurisdiction Claim Number for an MTC-00 Original – the data provider would not yet have the data.

Element Requirement Table Requirement Code Values: M = Mandatory. The data element must be present and must be a valid format or the transaction will be rejected. Release 1 and Release 3. Release 3 Note: When an M is marked on an MTC 02, the element is required; changes to the value are not allowed.

Element Requirement Table Requirement Code Values: MC = Mandatory/Conditional. The data element becomes mandatory under conditions established by the receiver and mandatory rules apply (the data element must be present and must be a valid format or the transaction will be rejected). Release 3 only. Example: if the Benefit Type Code indicates death benefits, then the Date of Death becomes mandatory.

Element Requirement Table Requirement Code Values: C = Conditional: The data element is normally optional, but becomes mandatory under conditions established by the Jurisdiction. Release 1 only. The jurisdiction should describe the specific circumstance which causes the element to become mandatory.

Element Requirement Table Requirement Code Values: O = Optional: The data element is not required to be sent. Release 1 only. If it is sent, edits are applied to it, but unsuccessful edits will not cause a transaction rejection (TR).

Element Requirement Table Requirement Code Values: E = Expected. The data element is expected on the MTC, yet the transaction will be accepted with errors should it fail any edit. Release 3 only. If an “E” is designated, the transaction will not be rejected if it is the only edit failure.

Element Requirement Table Requirement Code Values: EC =Expected/Conditional. The data element becomes expected under conditions established by the receiver. Release 3 only. The jurisdiction should describe the specific circumstance which causes the element to become expected. The transaction will be accepted with errors should it fail any edit.

Element Requirement Table Requirement Code Values: IA = If Applicable/Available. Data should be sent if available. The data may or may not be populated. If present, may be edited for valid value and/or format. Release 3 only. Jurisdiction may or may not return an error on validity edits.

Element Requirement Table Requirement Code Values: NA = Not Applicable. The data element is not applicable to the jurisdiction’s requirements for the MTC and may or may not be sent; edits must not be applied. Release 3 only.

Element Requirement Table Requirement Code Values: Requirement Code limited to elements in the Benefits segment. Release 3 only: R = Restricted. The value of the data element will be accepted if a stated condition exists, as defined by the jurisdiction. For example, the jurisdiction does not accept Benefit Type Code 080 prior to a specified date of accident

Element Requirement Table Requirement Code Values: Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only. Whenever a data element that has been marked as FY, Y, or YC on the Element Requirement table under MTC 02 has changed, the claim administrator must trigger an 02 change transaction unless another MTC applies. Refer to 02 Change Processing Rules in the Release 3 Implementation guide.

Element Requirement Table Requirement Code Values: Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only. FY = Fatal Yes Change. An 02 Change transaction should be triggered when the value of this Fatal/Technical data element has changed when the jurisdiction’s Element Requirement Table indicates an “FY” requirement code.

Element Requirement Table Requirement Code Values: Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only. Y = Yes Change. The data element must be sent on an 02 Change transaction if the value has changed. This DN should be populated if it has ever been reported on the claim. Spaces imply intentional removal of previously reported data.

Element Requirement Table Requirement Code Values: Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only. YC = Yes Change/Conditional. Send an 02 Change transaction if the data element changes under these predefined conditions: Benefit Type Claim Weeks, Benefit Type Claim Days and Benefit Type Amount Paid were reported in error on a Benefit Type Code that was ended.

Release 1 Element Requirement Table EDI 301 Release 1 Element Requirement Table

Release 1 FROI Element Requirement Table (Partially presented) Requirement codes limited to: M (Mandatory) - reject if absent/invalid C (Conditional) - reject if absent/invalid with defined conditions O (Optional) - not required

Release 3 Element Requirement Table EDI 301 Release 3 Element Requirement Table

Release 3 FROI Element Requirement Table (Partially presented) Standard Technical limitations are applied: F (Fatal Technical) X (Exclude)

Release 3 FROI Element Requirement Table (Partially presented) Release 3 provides more options to describe requirement severity: E (Expected) EC (Expected/Conditional) M (Mandatory) MC (Mandatory/Conditional) NA (Not Applicable) IA (If Applicable/Available)

Release 3 FROI Element Requirement Table (Partially presented) A “Conditional Requirements” table is provided for jurisdictions to describe the condition(s) that cause the data element to be Mandatory or Expected: MC (Mandatory Conditional) or EC (Expected Conditional)

Release 3 FROI Element Requirement Table (Partially presented) MTCC and MTCC Date are Fatal on CO (Correction) transactions

Release 3 FROI Element Requirement Table (Partially presented) These data elements notify the jurisdiction which transaction is being corrected (which requirements apply)

Release 3 FROI Element Requirement Table (Partially presented) Standard requirement code for CO (Correction) MTC: $ Same requirements as the MTC being corrected

Release 3 FROI Element Requirement Table (Partially presented) When MTC 00 is being corrected, those requirements apply

Release 3 FROI Element Requirement Table (Partially presented) For example, assume the 00 (Original) was missing the Number of Days Worked Per Week.

Release 3 FROI Element Requirement Table (Partially presented) The jurisdiction returns a TE (Transaction accepted with Errors) acknowledgment.

Release 3 FROI Element Requirement Table (Partially presented) When submitting the Correction to the error(s) on the 00 (Original)

Release 3 FROI Element Requirement Table (Partially presented) M M E EC MC the $ becomes the requirement code from the 00 (Original).

Questions?

EDI 301 Edit Matrix

Edit Matrix The Edit Matrix presents standard application of edits to Claims data elements.

Edit Matrix Jurisdiction indicates edits that are applied to each data element on the Edit Matrix to assist the sender in understanding the edits that will be applied and the data quality expected by the jurisdiction.

EDI 301 Release 1 Edit Matrix

Applied edits are indicated with an “X” at the intersection of the DN# and Error Message #. Release 1 Edit Matrix (Partially presented)

Failure of applied edits may result in rejection of the transaction. Release 1 Edit Matrix (Partially presented)

EDI 301 Release 3 Edit Matrix

Release 3 Edit Matrix The Matrix consists of 5 components: DN-Error Message contains “standard” editing developed for Release 3 data elements. Value Table expresses the jurisdiction’s acceptable code values. Match Data describes the data elements that will be used to determine if the report will create a new claim or find an existing claim or transaction in the jurisdiction’s database. Population Restrictions contains the jurisdiction’s restrictions applied to the data element(s). Sequencing illustrates logical transaction sequencing for application of edit 063.

1. DN-Error Message table

1. DN-Error Message table Table is populated with standard default edits

1. DN-Error Message table F = Fatal Technical edits must be applied - data is essential for the transaction to be processed

1. DN-Error Message table L = logical standard edit for the data element

1. DN-Error Message table Jurisdiction will apply edits? N = Jurisdiction will not apply any of the standard edit(s) N

1. DN-Error Message table Jurisdiction will apply edits? Y = Jurisdiction will apply standard edits that are not “grayed out” Y

1. DN-Error Message table Edits that are “grayed out” will not be applied by the jurisdiction. Y L

1. DN-Error Message table Population Restrictions Jurisdiction will indicate whether restrictions will be applied to reported values.

1. DN-Error Message table Population Restrictions Y alerts senders to review the restrictions imposed by the jurisdiction. Y

2. Value table

Value Table conveys code values that are expected to be reported to the jurisdiction, invalid values and values that may be suppressed (Partial Table presented)

Y = data element is collected by the jurisdiction Value Table Y = data element is collected by the jurisdiction N = data element is not collected Y N (Partial Table presented)

Code values that are not valid are “grayed-out” by the jurisdiction Value Table Code values that are not valid are “grayed-out” by the jurisdiction Code values that are not grayed-out are expected to be reported H K Y A E G P N (Partial Table presented)

Value Table Code values that are grayed-out in Section 2 are not collected by the jurisdiction. These code values may be suppressed by senders. H K Y N H K (Partial Table presented)

3. Match Data table

3. Match Data  Match Data elements are used by jurisdictions to: Identify new Claims Find existing Claims, transactions or previously reported values

Match Data table describes the data elements that will be used as Match Data by the jurisdiction.

Match Data P = Primary Match data element S = Secondary Match data element P P S P S

3. Match Data Jurisdiction One use of Match Data is to determine whether the transaction should create a new Claim Claims New Claim: Match Employee ID Primary Date of Injury Primary For instance, a Jurisdiction may define Match Data elements for new claims as:

3. Match Data Jurisdiction The jurisdiction uses these  Match Data elements to evaluate whether the claim in the incoming FROI transaction exists on their data base. Claims Claim New Claim: Match Employee ID Primary Date of Injury Primary

3. Match Data Jurisdiction If the  Match Data keys do not exist, the jurisdiction will establish a new claim from the incoming transaction. Claims New Claim New Claim: Match Employee ID Primary Date of Injury Primary

3. Match Data If the  Match Data keys do exist on the jurisdiction’s data base, this FROI transaction may be rejected as a duplicate. Jurisdiction Claims Claim New Claim: Match Employee ID Primary Date of Injury Primary X

3. Match Data Once a claim has been established on the jurisdiction’s data base,  Match Data keys may be compared to previously reported data. Jurisdiction Claims Existing Claim: Match Jurisdiction Claim Number Primary Employee ID Secondary Date of Injury Secondary Existing claim

3. Match Data When a match is found with the Primary key(s), the Secondary keys are used to validate data integrity. Jurisdiction Claims Existing Claim: Match Jurisdiction Claim Number Primary Employee ID Secondary Date of Injury Secondary Existing claim

4. Population Restrictions

Population Restrictions Elaborates on data elements’ specific data population limitations or accepted values for standard error messages Returned on acknowledgment for reconciliation by senders 0002 Maintenance Type Code 042 FROI UI not accepted Not statutorily valid MTC’s not accepted: FROI UI 0063 Wage Period Code 042 Must be 01 (Weekly) Not statutorily valid Code 2, 4, 6 and 7 are invalid

5. Sequencing

5. Sequencing The Sequencing table in the Edit Matrix is a model of the standard Sequencing outline from Section 4 of the Release 3 implementation guide. It illustrates the sequence in which business events (MTCs) typically occur during the life of a claim.

5. Sequencing Application of Jurisdiction’s transaction sequence edits are defined on the Sequencing table. Partial table presented

5. Sequencing N = the sequencing edit will not be applied to the SROI report N Partial table presented

5. Sequencing Y = edit will be applied. Error text indicates why the report was rejected: 1b = 00 Original 1c = 04 Denial (FROI) Y Event 1b or 1c not accepted by jurisdiction Y Event 1b or 1c not accepted by jurisdiction

Questions?

Implementing EDI with Trading Partners Obtain the IAIABC Implementation Guide Obtain the Jurisdiction Implementation/Requirements Guide Prepare your System to send and receive the applicable data Submit the required Profiles and Agreements to the Jurisdiction Begin the EDI Process

Thank you for attending EDI 301!