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

EDI301

Advanced Technical Advanced Technical ConceptsConcepts

2008 IAIABC All Committee Conference

April 7-12, 2008 Austin, TX

Robbie Robbie TannerTanner

email: rtanner@iso.comemail: rtanner@iso.com

Assistant Director WC Network Products, ISOAssistant Director WC Network Products, ISO

IAIABC Participation:IAIABC Participation: EDI SystemsEDI Systems EDI XML Work Group LeaderEDI XML Work Group Leader EDI ClaimsEDI Claims EDI Proof Of CoverageEDI Proof Of Coverage EDI MedicalEDI Medical EDI TrainerEDI Trainer

Your Trainers:Your Trainers:

Lori RabyLori Rabyemail: lraby@roesinc.comemail: lraby@roesinc.com

IT Business Analysis Consultant – IT Business Analysis Consultant – Ingenix/ROESIngenix/ROES

IAIABC Participation:IAIABC Participation: EDI Systems Committee Vice ChairEDI Systems Committee Vice Chair EDI ClaimsEDI Claims EDI XML EDI XML EDI Proof Of Coverage (POC)EDI Proof Of Coverage (POC) EDI MedicalEDI Medical EDI TriageEDI Triage EDI TrainerEDI Trainer

Sharon Sharon MarionMarion

email: smarion@peakpsi.comemail: smarion@peakpsi.com

EDI Coordinator – Peak PerformanceEDI Coordinator – Peak Performance

IAIABC Participation:IAIABC Participation: EDI Systems Committee ChairEDI Systems Committee Chair EDI XML EDI XML EDI MedicalEDI Medical EDI ClaimsEDI Claims EDI TrainerEDI Trainer

Transactions/Transactions/Records Records

(Fixed and Variable (Fixed and Variable Length)Length)

EDI301

TransactionTransaction

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

RecordRecord

• 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

Release 1 records are either fixedfixedor Variable Variable length.

IAIABC Release 1 Records

IAIABC Release 3 RecordsTechnically identified by DN0001-Transaction Set ID Release 3 records are either fixedfixedor Variable Variable length.

Batches/Batches/TransmissionsTransmissions

EDI301

BatchBatch

Header

Transactions

Trailer

Each Transaction Type (transaction)is contained in a batch

which is preceded by a Header Recordand concluded with a Trailer Record.

01 • uniquely identifiesuniquely identifies

information about the batch and the data within the batch

• along with the Trailer Record forms an “envelope”“envelope” that surrounds a batch of transactions

• precedesprecedes each batch of data. It is the first record in every batch

The Header Record The Header Record (HD1)(HD1)

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

TransactionsTransactions

Release 1 uses 1 Record per Transaction to report a claim event.

148 148= FROI

A49= SROI

Release 3 requires 2 records per transaction to report a claim event.

148 + R21 = FROI

A49 + R22 = SROI

DN0015 - Claim Administrator Claim Number is populated in all Release 3 FROI and SROI records.

This “links” the companion record to its related 148 or A49 record.

Release 3 records

Acknowledgment Transactions

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

The Trailer Record

•designates the endthe end of a batch of transactions

•provides a counta count of records/transactions within a batch

• is used to ensure that the entire batch is complete and complete and validvalid

•along with the Header record completes the “envelope”“envelope” that surrounds a batch of transactions

Batch example of R1 FROI transactions 8 records = 8 transactions

148 Record 1

148 Record 2

148 Record 3

148 Record 4

148 Record 5

148 Record 6

148 Record 7

148 Record 8

Header

Trailer

FROITransactions

SROITransactions

Batch example of R1 SROI transactions 8 records = 8 transactions

A49 Record 1

A49 Record 2

A49 Record 3

A49 Record 4

A49 Record 5

A49 Record 6

A49 Record 7

A49 Record 8

Header

Trailer

Batch example of R3 FROI transactions 8 records = 4 transactions

148 Record 1

R21 Record 2

148 Record 3

R21 Record 4

148 Record 5

R21 Record 6

148 Record 7

R21 Record 8

Header

Trailer

FROITransactions

SROITransactions

Batch example of R3 SROI transactions 8 records = 4 transactions

A49 Record 1

R22 Record 2

A49 Record 3

R22 Record 4

A49 Record 5R22 Record 6

A49 Record 7

R22 Record 8

Header

Trailer

Components of a Transmission

SROITransactions

Header

Trailer

FROITransactions

Header

Trailer

BATCH:BATCH: Consists of 1 Header record, one or more Transactions and 1 Trailer record.

Components of a TransmissionTRANSMISSIOTRANSMISSION:N: Consists of 1 or more batches sent or received during a communication session.

SROITransactions

Header

Trailer

FROITransactions

Header

Trailer

Questions?

Data Data ElementElementFormatsFormats

EDI301

Data ElementData ElementData 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 ExampleData Dictionary Example

Specific Data Element Specific Data Element InformationInformation

Data Element FormatsData Element FormatsDates: 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 FormatsData Element Formats

All zeros in a date field are considered to be invalid data.

CCYYMMDDDates: Type = DATE:

Spaces indicate absence of data.

‘‘0000000000000000’ ’ = = invalid datainvalid data

Data Element FormatsData Element FormatsTime: 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 Data Element FormatsFormatsTime: 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 FormatsData 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 FormatsData Element FormatsNumeric: Type = N:

Example: 3 numeric ‘123’ in 6 byte field = 000123

123000

Valid values consist of 0 - 9 and are right justified zero filled to the left.

Data Element FormatsData Element FormatsMonetary 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 FormatsData Element FormatsMonetary 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.00500000000

Data Data ElementElement Formats FormatsPercentage: Type = 3.2: Data elements that are assigned the format of 3.2 should be populated with only a valid percentage.

Data Data ElementElement Formats FormatsPercentage: 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.

Data Element FormatsData Element FormatsAlphanumeric: 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 FormatsData Element FormatsAlphanumeric: Type = A/N:

When using an alphanumeric field, the significant characters are always left justifiedleft justified in the field with any remaining space in the field padded with spaces. SMITH (spaces)

Alphanumeric character set includes those selected from the uppercase letters, lower case letters, numeric digits, space character, and special characters.

Data Element FormatsData Element FormatsAlphanumeric: Type = A/N:

See System Rules of the R3 Implementation Guide.

Release 1Release 1Transactions/RecorTransactions/Recor

EDI301

HD1 – Release 1 Header HD1 – Release 1 Header RecordRecordThere are 9 data elements

and the record is 87 bytes fixed length

HD1 – Release 1 Header HD1 – Release 1 Header RecordRecorduniquely identifiesuniquely identifies the sender,

the receiver,the date and time batch was prepared

HD1 – Release 1 Header HD1 – Release 1 Header RecordRecordwhether the batch contains test or production dataand the Transaction type

148 - Release 1 FROI Record148 - Release 1 FROI Record 913 Byte Fixed Length Record

TR1 – Release 1 Trailer TR1 – Release 1 Trailer RecordRecord12 Byte Fixed Length Record

148 – Release 1 FROI148 – Release 1 FROI Batch/Transmission ExampleBatch/Transmission Example

Transmission Sample Containing 1 Batch (Shown partial for display):

HD1666777888 888777666999999999 23423424220010327074530 P148011480020010327PR 666777888ABC INSURER 818181818TPA TR1000000001

Transmission Sample Containing 2 Batches (Shown partial for display):

HD1666777888 888777666999999999 23423424220010327074545 P14801

1480020010327PR 666777888ABC INSURER 818181818TPA

TR1000000002

HD1666777888 888777666999999999 23423424220010327074630 P14801

1480020010327PR 666777888ABC INSURER 818181818TPA

TR1000000001

Header Record=HD1 FROI Transaction=148 Trailer Record=TR1

A49 - Release 1 SROI recordA49 - Release 1 SROI recordVariable Length RecordVariable segment Counters determine actual record length

Release 1 A49 Variable SegmentsPartial display of SROI A49 record

Counters determine the overall record length

• One Perm Impair• Two Pmt/Adj• Three

PTD/RE/REC

Perm Impair = 8 bytesPmt/Adj = 46 bytes x 2PTD/RE/REC = 14 bytes x 3The A49 record ends at position 350

• Fixed length = 208

Data Description Beg End

Variable Segment Counters

0078 Number of Permanent Impairments 01 199 2000079 Number of Payments/Adjustments 02 201 2020080 Number of Benefit Adjustments 00 203 2040081 Number of Paid to Date/Reduced Earnings/Recoveries 03 205 2060082 Number of Death Dependent/Payee Relationships 00 207 208

Permanent Impairements

0083 Permanent Impairment Body Part Code 99 whole body 209 2110084 Permanent Impairment Percentage 00800 8% 212 216

Payment/Adjustments

0085 Payment/Adjustment Code 050 Temp Total 217 2190086 Payment/Adjustment Paid to Date 00000091200 $912.00 220 2300087 Payment/Adjustment Weekly Amount 00000033600 $336.00 231 2410088 Payment/Adjustment Start Date 20020213 Feb 13, 2002 242 2490089 Payment/Adjustment End Date 20031102 Nov 2, 2003 250 2570090 Payment/Adjustment Weeks Paid 0002 258 2610091 Payment/Adjustment Days Paid 5 262 2620085 Payment/Adjustment Code 040 Perm Partial

Unscheduled263 265

0086 Payment/Adjustment Paid to Date 00000470400 $4,704.00 266 2760087 Payment/Adjustment Weekly Amount 00000016800 $168.00 277 2870088 Payment/Adjustment Start Date 20040101 Jan 1, 2004 288 2950089 Payment/Adjustment End Date 20040722 Jul 22, 2004 296 3030090 Payment/Adjustment Weeks Paid 0028 304 3070091 Payment/Adjustment Days Paid 0 308 308

Paid to Date/Reduced Earnings/Recoveries

0095 Paid To Date/Reduced Earnings/Recoveries Code 350 Physicians PTD 309 3110096 Paid To Date/Reduced Earnings/Recoveries Amount 00000020389 $203.89 312 3220095 Paid To Date/Reduced Earnings/Recoveries Code 360 Hospital PTD 323 3250096 Paid To Date/Reduced Earnings/Recoveries Amount 00000067491 $674.91 326 3360095 Paid To Date/Reduced Earnings/Recoveries Code 370 Oth Medical PTD 337 3390096 Paid To Date/Reduced Earnings/Recoveries Amount 00000167126 $1,671.26 340 350

A49 – Release 1 SROI A49 – Release 1 SROI RecordRecordBatch/Transmission ExamplesTransmission Sample Containing 1 Batch (Shown partial for display):

HD1666777888 888777666999999999 23423424220010327074916 PA491AA49IP20010314PR66677788881818181834236 29038412302N20010301 TR1000000001

Transmission Sample Containing 2 Batches (Shown partial for display):

HD1666777888 888777666999999999 23423424220010327074920 PA491AA49IP20010314PR66677788881818181834236 29038412302N20010301 TR1000000001HD1666777888 888777666999999999 23423424220010327074940 PA491AA49IP20010314PR66677788881818181834236 29038412302N20010301 A49IP20010314PR66677788881818181834222 29045412302N20013045 TR1000000002Header Record=HD1 SROI Transaction=A49 Trailer Record=TR1

Header Record=HD1 SROI Transaction=A49 Trailer Record=TR1

HEADER RECORD:HEADER RECORD:

HD1810461738 599012126810302402 59604801120010914124949 PA491A

A49A49 RECORDRECORD 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 RECORDTRAILER RECORD:

TR1000000001

A49 – Release 1 SROI Data Batch Breakdown Example

Release 3Release 3Transactions/RecorTransactions/Recor

EDI301

IAIABC Claims Release 3 Transaction DesignIAIABC Claims Release 3 Transaction Design

BasicA49

Permanent ImpairmentsPayment Adjustments

AdjustmentsPaid to Dates/Reduced Earnings/Recoveries

Death Dependent Payee

SROISROI

Fixed lengthBasic148

FROIFROI

Fixed lengthR1

DifferentDifferentDifferent

Witness

Accident/Injury Description

Companion (R21)

Fixed length

Managed Care Org

Denial Reason CodesDenial Reason Narratives

Suspension Narratives

Companion (R22)

Benefit

Reduced Earnings

Adjustments, Credits, Redistributions

Concurrent Employer

Fixed length

Recoveries

Other BenefitsPayments

Denial Reason CodesDenial Reason Narratives

Anything New or Different from R1 or R2

Release 1 data elements that differ in:

a)Functionality

b)definitionc)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).

HD1 – Release 3 Header HD1 – Release 3 Header RecordRecord

87 byte Fixed Length record(Same as Release 1)

HD1 – Release 3 Header HD1 – Release 3 Header RecordRecorduniquely identifiesuniquely identifies the sender,

the receiver,the date and time batch was prepared

HD1 – Release 3 Header HD1 – Release 3 Header RecordRecordwhether the batch contains test or production dataand the Transaction type

Release 3 FROI recordRelease 3 FROI record148 – 913 Byte Fixed Length Record

Release 3 FROI Companion recordRelease 3 FROI Companion recordR21– Variable Length Record

Variable segment counters determine actual record length

Release 3 SROI recordRelease 3 SROI recordA49– Variable Length Record

Variable segment counters determine actual record length.

Release 3 SROI Companion Release 3 SROI Companion recordrecordR22– Variable Length RecordVariable segment counters determine actual record length.

Release 3 Variable Segments

• The transaction includes one Benefits segment

• Benefits segment = 103 bytes. The R22 record ends at position 753

Partial display of SROI R22 record

Release 3 Variable Segments

• The transaction includes one Benefits segment and one Suspension Narrative

• 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 TR2 – Release 3 Trailer RecordRecord

• designates the end of a batch of transactions

• provides a count of recordsrecords and transactions transactions within a batch• is used to ensure that the entire batch is complete and valid

Release 3 148/R21 – Release 3 148/R21 – First Report of Injury First Report of Injury Batch/Transmission ExampleTransmission 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):TR2000000002000000001Interchange Version ID value for HD1: 14830FROI Companion RecordNew field added to Release 3 Trailer record: Transaction Count (DN0191)

Release 3 A49/R22 – Release 3 A49/R22 – Subsequent Report of InjurySubsequent Report of Injury Batch/Transmission ExampleTransmission 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):TR2000000002000000001Interchange Version ID value for HD1: A4930SROI Companion RecordNew field added to Release 3 Trailer record: Transaction Count (DN0191)

Break Time!

AcknowledgmentOverview

What is an What is an Acknowledgment?Acknowledgment?

Acknowledgment

Electronic Report

Claim Administrator

Jurisdiction

A transaction returned by the jurisdiction as a result of a report sent.

What is an What is an Acknowledgment?Acknowledgment?

It contains enough information to identify the original transaction and any technical and business issues.

How does the How does the acknowledgment acknowledgment

communicate the status communicate the status of the transaction?of the transaction?

Using the Application Acknowledgment Code (DN0111), located in each acknowledgment record.

How does the How does the acknowledgment acknowledgment

communicate the status communicate the status of the transaction?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 Transaction Accepted (TA)(TA)

•The transaction was accepted by the jurisdiction

•No errors were found on the transaction

•No further reporting is required on the specific transaction

•An error was found on an Expected, Expected Conditional or If Applicable/Available data element

Transaction Accepted Transaction Accepted with Error (TE)with Error (TE)

•An MTC CO (Correction) should be submitted to resolve the error(s)

•An error was found on a mandatory or mandatory conditional data element

Transaction Rejected Transaction Rejected (TR)(TR)

•The transaction was not accepted or added to the jurisdiction’s system as a reported claim

Transaction Rejected Transaction Rejected (TR)(TR)

•A review of the error should take place to determine what action should be taken to resolve the issue

•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

TransactionTransaction Rejected Rejected (TR)(TR)

•The Batch is rejected in its entirety

BatchBatch Rejected (HD) Rejected (HD)

•When a Batch Reject Occurs, only one AKC record may be returned in the acknowledgment batch

Batch Reject ReasonsBatch 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:• 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

Rejected by Service Provider Rejected by Service Provider (TN) (TN)

Acknowledgments:Acknowledgments:

Release 1 vs. Release 3Release 1 vs. Release 3

Acknowledgement Record Layout Comparison

Release 1 (AK1)

When Number of Errors > 0

Acknowledgement Record Layout Comparison

Release 3(AKC)

New elements and filler

New Error Text

Release 1 Transaction Release 1 Transaction AcknowledgmentAcknowledgment

148 Record 1

148 Record 2

148 Record 3

148 Record 4

Header

Trailer

FROITransactio

Header (HD1)

Trailer (TR1)

AK1 TA Record 1AK1 TA Record 2AK1 TE Record 3AK1 TR Record 4

Claim Administrator sends: Jurisdiction returns:

Release 3 Transaction Release 3 Transaction AcknowledgmentAcknowledgment

148 Record 1

R21 Record 2

148 Record 3

R21 Record 4

148 Record 5

R21 Record 6

148 Record 7

R21 Record 8

Header

Trailer

FROITransactio

Claim Administrator sends:

Header (HD1)

Trailer (TR2)

AKC TA Record 1

AKC TA Record 3

AKC TE Record 5

AKC TR Record 7

Jurisdiction returns:

Release 1 vs. Release 3Requirement Code Result of Failed Element Requirement

Requirement Code Result of Failed Element Requirement EditM (Mandatory) TR (Transaction Rejected)

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) ORTE (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 3 only** Release 1 only

C (Conditional) ** TR (Transaction Rejected)

O (Optional) ** TE (Transaction Accepted with Errors)

Acknowledgment Acknowledgment Transmission/Batch Transmission/Batch

ExamplesExamples

EDI301

AK1 – Release 1 AK1 – Release 1 Transmission/Batch ExampleTransmission/Batch Example

Transmission Sample Containing 1 Batch (Shown partial for display):HD1999999999 234234242666777888 8887776662001032708134020010327074916PAK101AK10000000012001032708164466677788834236 818181818A49TAINSRPTNUM AK10000000012001032708164466655788834236 818181818A49TEINSRPTNUM TR1000000002Transmission Sample Containing 2 Batches (Shown partial for display):HD1999999999 234234242666777888 8887776662001032708134020010327074933PAK101AK10000000012001032708164466677788834236 818181818148TAINSRPTNUM TR1000000001HD1999999999 234234242666777888 8887776662001032708134020010327074944PAK101AK10000000012001032708164466677788834236 818181818A49TAINSRPTNUM AK10000000012001032708164466655788834236 818181818A49TEINSRPTNUM TR1000000002Header Record=HD1

Acknowledgment Transaction=AK1Trailer Record=TR1

AKC Release 3AKC Release 3 Transmission/Batch Transmission/Batch ExampleExample

AKCAKC

TrailerTrailer

HeaderHeader

AKC Release 3AKC Release 3 Transmission/Batch Transmission/Batch ExampleExample

AKCAKC

TrailerTrailer

HeaderHeader

AKCAKC

TrailerTrailer

AKCAKC

Release 3 - Matching original batch Release 3 - Matching original batch to AKC batch using the Header to AKC batch using the Header

RecordRecordFROI ExampleFROI Example

HEADER RECORD (HD1) for FROIHD1666777888 888777666999999999 23423424220010327074530 P148301 |2 | 3 |4 |5 |6 |7 |8|9 |

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

Release 3 - Matching original batch Release 3 - Matching original batch to AKC batch using Trailer Recordto AKC batch using Trailer Record

FROI ExampleFROI Example

TRAILER RECORD (TR2) for FROI TR2000000002000000001

TR2000000001000000001TRAILER RECORD (TR2) for AKCTransaction 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.

The count should be the same.The count should be the same.

Interpreting Interpreting AcknowledgmentsAcknowledgments

EDI301

Interpreting Release 3 Acknowledgment

AKC acknowledges Release 3 transactions.

Jurisdiction assigned Claim Number is acknowledged.

Date and time the transaction was processed by receiving JurisdictionJurisdictio

n returns value from original transaction, when available

Jurisdiction calculates and returns the position of the transaction within the batch.

Acknowledged transaction is identified.

MTC and MTC Date from original transaction

000000023

Result of jurisdiction’s applied edits;

Number of encountered errors.

Number of Errors determine the overall record length

The AKC includes two Error segments

AKC Fixed length = 248

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

The first error occurred on DN0134 Calculated Weekly Compensation Amount.

Optional Element Error Text assists senders with error resolution.

The amount reported was less than required by the jurisdiction.

The second error occurred on DN0192 Benefit Payment Issue Date.An invalid date was reportedin the second Benefits segment of the SROI transaction.

Error Message 029 clearly describes the error; Element Error Text is optional.

Release 3Error

Correction

EDI301

Error Correction Error Correction ProcessProcess

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.

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

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

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.Refer to Error Correction Process in Release 3 Claims Implementation Guide for additional information.

Questions?

Establishing the EDI Establishing the EDI PartnershipPartnership

STANDARD USAGE FOR ALL PRODUCTS

http://www.iaiabc.org/EDI/default.asp

Partnering Agreement

Jurisdiction

EDI Reporter

Trading Partner Profile

999999999

EDI Reporter

12345 6789

Receiver’s Specifications

Jurisdiction mm/dd/yyyy

999999999

Claims 3.0 AKC EDI

2300 EST

12345 6789

Sender’s Response

mm/dd/yyyy

EDI Reporter

Jurisdiction

999999999 12345 6789

Claims 3.0

EDI Reporter999999999 12345 6789

111111111Best TPA222222222Insurance company333333333Self-Insured Employer

Claim Administrator ID List

mm/dd/yyyy

Maintaining Senders’ Maintaining Senders’ AuthorizationAuthorization

EDI301

Trading Partner Validation Table

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

Trading Partner Validation TableExample 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

In this example, authorization “status” of both the Sender and Claim Administrator/ Insurer/Self-Insured is maintained.

A = Approved

R = Revoked

999999999

123456789

A (Approved)

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.

111111111222222222

333333333

A (Approved)A (Approved)

A (Approved)

EDI Reporter999999999 12345 6789

111111111Best TPA222222222Insurance company333333333Self-Insured Employer

mm/dd/yyyy

Validating Sender Validating Sender Authorization for the Authorization for the

BatchBatch

EDI301

888888888 A (Approved)

888888888

987654321Approved

999999999

123456789

Approved

111111111222222222

333333333

A (Approved)R (Revoked)A (Approved)

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

987654321Approved

999999999

123456789

Approved

111111111222222222

333333333

If Sender ID does not exist in the Validation Table or authorization is revoked, jurisdiction will reject the entire batch.

Validating Sender Validating Sender Authorization for the Authorization for the Claim AdministratorClaim Administrator

EDI301

888888888

987654321Approved

999999999

123456789

Approved

111111111222222222

333333333

During Transaction Level editing, the Claim Administrator FEIN from the FROI or SROI record are checked against the jurisdiction’s Validation Table.

888888888

987654321Approved

999999999

123456789

Approved

111111111222222222

333333333

If the Claim Administrator FEIN exists with Approved status the transaction is processed.

888888888

987654321Approved

999999999

123456789

Approved

111111111222222222

333333333

If Claim Administrator ID does not exist in the Validation Table or authorization is revoked, jurisdiction will reject the transaction.

Trading Partner Trading Partner TablesTables

• Event Table• Element Requirement Table• Edit Matrix

EDI301

Event TableEvent Table

EDI301

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.

1. Describes conditions that “trigger” electronic reports

3. Describes Report due dates based on jurisdictions’ legislative mandates and/or voluntary reporting requirements

2. Provide timeframes for sending the information

Claims Release 1 Event Table

Claims Release 3 Event Table

Interpreting Release Interpreting Release 1 Event Table1 Event Table

EDI301

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

(partially presented)(partially presented)

Release 1Release 1 Event Table Event Table

(partially presented)(partially presented)

When the Event Rule Thru date is blank, reporting requirements apply until further notice.

Interpreting Release Interpreting Release 3 Event Table3 Event Table

EDI301

Release 3 Event Table Release 3 Event Table

Partial Table presented

Jurisdiction's reporting requirements:A report (Maintenance Type Code) is due when the Event Rule Criteriais within Event Rule Date range (From/Thru),

with the conditions described in the Trigger Criteria and Value.Report due date is based on Report Due Value, Type and From)

When the Event Rule Thru date is blank, reporting requirements apply until further notice.

When a Paper Form is indicated, this form must be sent to the Receiver indicated in addition to the electronic report.

Questions?

Element Element Requirement TableRequirement Table

EDI301

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).

M (Mandatory)

E (Expected)EC (Expected/Conditional) IA (If Applicable/Available)

N/A (Not Applicable)

F (Fatal) X (Exclude)

O (Optional)C (Conditional)

RELEASE 1 AND RELEASE 3

RELEASE 1 ONLY RELEASE 3 ONLY

Element Requirement TableRequirement Code Values:

MC (Mandatory/Conditional)

R (Restricted)

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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

Requirement Codes limited to MTC 02 MTC 02 (Change) transaction.(Change) transaction. Release 3 only.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.

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.

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.

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 1Release 1 Element Element Requirement TableRequirement Table

EDI301

Release 1 FROI Element Release 1 FROI Element Requirement TableRequirement Table

Requirement codes limited to: M (Mandatory) - reject if absent/invalidC (Conditional) - reject if absent/invalid with defined conditions O (Optional) - not required

(Partially presented)

Release 3Release 3 Element Element Requirement TableRequirement Table

EDI301

Standard Technical limitations are applied: F (Fatal Technical) X (Exclude)

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)

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)

MTCC and MTCC Date are Fatal on CO (Correction) transactions

These data elements notify the jurisdiction which transaction is being corrected (which requirements apply)

Standard requirement code for CO (Correction) MTC: $ Same requirements as the MTC being

corrected

When MTC 00 is being corrected, those requirements apply

For example, assume the 00 (Original) was missing the Number of Days Worked Per Week.

The jurisdiction returns a TE (Transaction accepted with Errors) acknowledgment.

When submitting the Correction to the error(s) on the 00 (Original)

the $ becomes the requirement code from the 00 (Original).

Questions?

Edit MatrixEdit Matrix

EDI301

Edit Matrix

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

Edit MatrixJurisdiction 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.

Release 1Release 1 Edit Matrix Edit Matrix

EDI301

DN DATA ELEMENT NAME 00

FIRST REPORT 0000 Entire Transaction0001 Transaction Set ID X0002 Maintenance Type Code X0003 Maintenance Type Code Date X X

Applied edits are indicated with an “X” at the intersection of the DN# and Error Message #.

Release 1 Edit Matrix

DN DATA ELEMENT NAME 00

FIRST REPORT 0000 Entire Transaction0001 Transaction Set ID X0002 Maintenance Type Code X0003 Maintenance Type Code Date X X

Failure of applied edits may result in rejection of the transaction.

Release 1 Edit Matrix

Release 3Release 3 Edit Matrix Edit Matrix

EDI301

5. Sequencing illustrates logical transaction sequencing for application of edit 063.

Release 3 Edit MatrixRelease 3 Edit Matrix

4. Population Restrictions contains the jurisdiction’s restrictions applied to the data element(s).

3. 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.

2. Value Table expresses the jurisdiction’s acceptable code values.

1. DN-Error Message contains “standard” editing developed for Release 3 data elements.

The Matrix consists of 5 components:

1. DN-Error Message table

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

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

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

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

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

1. DN-Error Message tableEdits that are “grayed out” will not be applied by the jurisdiction.

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

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

01 2. Value table

2.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)

2.Value Table Y = data element is collected by

the jurisdictionN = data element is not collected

2. Value Table Code values that are not valid are “grayed-out” by the jurisdictionCode values that are not grayed-out are expected to be reported

A E G P

2. 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.

01 3. Match Data table

Match Data elements are used by jurisdictions to: Identify new Claims Find existing Claims,

transactions or previously reported values

3. Match Data

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

3.Match Data P = Primary Match data elementS = Secondary Match data element

Jurisdiction

ClaimsOne use of Match Data is to determine whether the transaction should create a new Claim

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

The jurisdiction uses these Match Data elements to evaluate whether the claim in the incoming FROI transaction exists on their data base.

Jurisdiction

Claims

New Claim: Match Employee ID

Primary Date of Injury

Primary

3. Match Data

If the Match Data keys do not exist, the jurisdiction will establish a new claim from the incoming transaction.

Jurisdiction

Claims

Primary

New Claim

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

Primary

3. Match Data

JurisdictionOnce a claim has been established on the jurisdiction’s data base, Match Data keys may be compared to previously reported data.

Claims

Existing Claim: Match Jurisdiction Claim Number

Primary Employee ID

Secondary Date of Injury

Secondary

Existing claim

3. Match Data

JurisdictionWhen a match is found with the Primary key(s), the Secondary keys are used to validate data integrity. Claims

Existing Claim: Match Jurisdiction Claim Number

Primary Employee ID

Secondary Date of Injury

Secondary

Existing claim

3. Match Data

4. Population Restrictions

4.Population Restrictions Elaborates on data elements’ specific data population limitations or accepted values for standard error messages

0002Maintenance Type Code

042 FROI UI not accepted

MTC’s not accepted: FROI UI

Not statutorily valid

0063Wage Period Code

042 Must be 01 (Weekly)

Code 2, 4, 6 and 7 are invalid

Not statutorily valid

Returned on acknowledgment for reconciliation by senders

01 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.

5. Sequencing

Partial table presented

N = the sequencing edit will not be applied to the SROI report

5. Sequencing

Partial table presented

Y = edit will be applied. Error text indicates why the report was rejected: 1b = 00 Original1c = 04 Denial (FROI)

Event 1b or 1c not accepted by jurisdictionEvent 1b or 1c not accepted by jurisdiction

5. Sequencing

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 youThank youfor attending EDI 301!for attending EDI 301!

EDI301

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

Documents

EDI - kusw.ac.jp · EDI . Created Date: 20151119090446Z

EDI Brochure 2008

IAIABC Annual Convention 2010 Border Wars: The Fight Over Coverage For Out of State Temporary Workers

EDI Rejections/Recent EDI Changes - HealthSystemshealthsystems.net/docs/HS_Feb_2008_EDI_webinar_final.pdf · EDI Rejections/Recent EDI Changes Taz Taylor Presented 2/29/08. 2

1 Florida Division of Workers Compensation Claims EDI Release 3 Training 2008

1 Florida Division of Workers Compensation Claims EDI Release 3 History and Overview 2008 (Review prior to attending EDI training or reviewing Business

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ О COMARCH EDI › assets › download › edi › Comarch-EDI-FAQ.pdf · понятие EDI ( англ. Electronic Data Interchange),

IAIABC MEDICAL BILL PAYMENT RECORDS DICTIONARY Version 1

MAST EDI SOP - Vendor EDI Processing Guide

Ontologizing EDI doug foxvog 23 July 2004. Ontologizing EDI What is EDI? EDI Data Types Ontologizing of EDI Ontologizing Invoice Message Type Summary

Electronic Commerce: EDI & Financial EDI

From SAP/EDI to Nirvana - Home - SupplyOn · PDF fileFrom SAP/EDI to Nirvana SupplyOn Executive Summit 2008 Munich, April 15th, 2008 ... PI •tedrive processes are harmonized (OTC,

EDI guidelines Invoice for goodsinternet.media-saturn.com/edi/iln_gln/Documents/EDI-INVOIC... · 1.0 31.03.2011 initial version Project EDI Invoice final EDI-Team 1.1 06.04.2011 No

Texas Claim EDI Data Dictionary - Texas Department of ... · Web viewElectronic Data Interchange (EDI) Data Dictionary April 2008 The Texas EDI Claims Data Dictionary was created to

Colloque de la facturation électronique - Le portail des ... · PDF filerecevoir dès 2008, format UBL ou GS1 EANCOM, EDI ou Portail de saisie (Web EDI) ... Source : Billentis Report

Manuel d’utilisation EDI TDFC - EDI TVAbuexperts-comptables.sage.com.dl1.ipercast.net/... · EDI-TDFC / EDI-TVA EDI-TDFC / EDI-TVA 3 Information 5 Avertissement important 5

EDI-guideline Electronic delivery noteinternet.media-saturn.com/edi/iln_gln/Documents/EDI_Guide_EDI... · EDI-guideline Electronic delivery note DESADV ... EDI-DESADV Workflow EDI-DESADV

Texas Claim EDI Data Dictionary · Web viewApril 2008 The Texas EDI Claims Data Dictionary was created to assist insurance carriers and trading partners in understanding each data

RETURN TO WORK: A FOUNDATIONAL APPROACH TO RETURN TO FUNCTION · RETURN TO WORK: A FOUNDATIONAL APPROACH TO RETURN TO FUNCTION 3 ©IAIABC 2016 ABOUT THE IAIABC Founded in 1914, the

Texas Claims EDI Imp. Guide Version 1.1 · Web viewThe Texas Claims EDI Implementation Guide supplements the IAIABC Implementation Guide (Release 1) for FROI and SROI claims reporting