Advanced technical concepts
Download
1 / 229

Advanced Technical Concepts - PowerPoint PPT Presentation


  • 69 Views
  • Uploaded on

Advanced Technical Concepts. 2008 IAIABC All Committee Conference April 7-12, 2008 Austin, TX. IAIABC. EDI. Training Team. Your Trainers:. Robbie Tanner email: [email protected] Assistant Director WC Network Products, ISO IAIABC Participation: EDI Systems EDI XML Work Group Leader

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Advanced Technical Concepts' - nita-meyer


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Advanced technical concepts

Advanced Technical Concepts

2008 IAIABC All Committee ConferenceApril 7-12, 2008 Austin, TX


Your trainers

IAIABC

EDI

Training Team

Your Trainers:

  • Robbie Tanner

    email: [email protected]

    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


Your trainers1

IAIABC

EDI

Training Team

Your Trainers:

  • Lori Raby

    email: [email protected]

    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


Your trainers2

IAIABC

EDI

Training Team

Your Trainers:

  • Sharon Marion

    email: [email protected]

    EDI Coordinator – Peak Performance

    IAIABC Participation:

    • EDI Systems Committee Chair

    • EDI XML

    • EDI Medical

    • EDI Claims

    • EDI Trainer


Transactions records fixed and variable length

EDI

301

Transactions/Records (Fixed and Variable Length)


Transaction
Transaction

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


Record
Record

  • A recordis 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.


A fixed length record is consistently the same number of data positions each time the record is assembled.

Fixed Length Records

Based on the individual record layout, the data within the record is always in the same position.


A variable length record may varyeach time the record is assembled.

Variable Length Record

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

orVariable length.


Iaiabc release 3 records
IAIABC Release 3 Records

Technically identified by DN0001-Transaction Set ID

Release 3 records are either fixed

orVariable length.


Batches transmissions

EDI

301

Batches/Transmissions


Batch
Batch

Each Transaction Type (transaction)

is contained in a batch

which ispreceded by a Header Record

and concluded with a Trailer Record.

Header

Transactions

Trailer


The header record hd1
The Header Record (HD1)

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

  • uniquely identifiesinformation 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
Transactions

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


Release 1 uses 1 record per transaction to report a claim event

148

A49

Release 1uses 1 Recordper Transaction to report a claim event.

148

= FROI

A49

= SROI


A49

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

148

+ R21

= FROI

148

R21

A49

+ R22

=SROI

R22


Release 3records

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
Acknowledgment Transactions

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


The trailer record
The Trailer Record

  • designatesthe endof a batch of transactions

  • providesa countof records/transactions within a batch

  • is used to ensure that the entire batch iscomplete and valid

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


FROI

Transactions

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

148 Record 4

148 Record 5

148 Record 6

148 Record 7

148 Record 8

Trailer


SROI

Transactions

Batch example of R1 SROI transactions

8 records = 8 transactions

Header

A49 Record 1

A49 Record 2

B

A

T

C

H

A49 Record 3

A49 Record 4

A49 Record 5

A49 Record 6

A49 Record 7

A49 Record 8

Trailer


148 Record 1

R21 Record 2

148 Record 3

R21 Record 4

148 Record 5

R21 Record 6

148 Record 7

R21 Record 8

FROI

Transactions

Batch example of R3 FROI transactions

8 records = 4 transactions

Header

B

A

T

C

H

Trailer


A49 Record 1

R22 Record 2

A49 Record 3

R22 Record 4

A49 Record 5

R22 Record 6

A49 Record 7

R22 Record 8

SROI

Transactions

Batch example of R3 SROI transactions

8 records = 4 transactions

Header

B

A

T

C

H

Trailer


FROI

Header

FROI

FROI

FROI

Transactions

FROI

FROI

FROI

FROI

Trailer

FROI

Header

SROI

SROI

SROI

SROI

Transactions

SROI

SROI

SROI

Trailer

Components of a Transmission

B

A

T

C

H

BATCH:Consists of

1 Header record, one or more Transactions and 1 Trailer record.

B

A

T

C

H


FROI

Header

FROI

FROI

FROI

Transactions

FROI

FROI

FROI

FROI

Trailer

FROI

Header

SROI

Transactions

Trailer

Components of a Transmission

B

A

T

C

H

TRANSMISSION:Consists of 1 or more batches sent or received during a communication session.

TRANSMISSION

B

A

T

C

H

SROI

SROI

SROI

SROI

SROI

SROI



Data element formats

EDI

301

Data ElementFormats


Data element
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 formats1
Data Element Formats

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 formats2
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 formats3
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 formats4
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 formats5
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 formats6
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

123

000

Spaces indicate absence of data.


Data element formats7
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 formats8
Data Element Formats

Valid entries consist of eleven numeric digits with the dollar sign assumed and the decimal point between the ninth and tenth position assumed.

Monetary Amounts: Type = $9.2:

Example: 00000005000 = $50.00

0000000

50

00

$

^

Spaces indicate absence of data.


Data element formats9
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 formats10
Data Element Formats

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 formats11
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 formats12
Data Element Formats

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.

Alphanumeric: Type = A/N:

SMITH

(spaces)


Data element formats13
Data Element Formats

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

Alphanumeric: Type = A/N:

See System Rules of the R3 Implementation Guide.

Spaces indicate absence of data.


Release 1 transactions records

EDI

301

Release 1Transactions/Records


Hd1 release 1 header record
HD1 – Release 1 Header Record

There are 9 data elements

and the record is 87 bytes fixed length


Hd1 release 1 header record1
HD1 – Release 1 Header Record

uniquely identifiesthe sender,

the receiver,

the date and time batch was prepared


Hd1 release 1 header record2
HD1 – Release 1 Header Record

whether the batch contains test or production data

and the Transaction type


148 - Release 1 FROI Record913 Byte Fixed Length Record


Tr1 release 1 trailer record 12 byte fixed length record
TR1 – Release 1 Trailer Record12 Byte Fixed Length Record


148 release 1 froi batch transmission example
148 – Release 1 FROIBatch/Transmission Example

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

HD1666777888 888777666999999999 23423424220010327074530 P14801

1480020010327PR 666777888ABC INSURER 818181818TPATR1000000001

Header Record=HD1FROI Transaction=148Trailer Record=TR1

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

HD1666777888 888777666999999999 23423424220010327074545 P14801

1480020010327PR 666777888ABC INSURER 818181818TPA

1480020010327PR 666777888ABC INSURER 818181818TPA

TR1000000002

HD1666777888 888777666999999999 23423424220010327074630 P14801

1480020010327PR 666777888ABC INSURER 818181818TPA

TR1000000001

Header Record=HD1FROI Transaction=148Trailer Record=TR1


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


Release 1 a49 variable segments partial display of sroi a49 record

Counters determine the overall record length

Release 1 A49 Variable SegmentsPartial display of SROI A49 record

  • One Perm Impair

  • Two Pmt/Adj

  • ThreePTD/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
A49 – Release 1 SROI RecordBatch/Transmission Examples

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

HD1666777888 888777666999999999 23423424220010327074916 PA491A

A49IP20010314PR66677788881818181834236 29038412302N20010301TR1000000001

Header Record=HD1SROI Transaction=A49Trailer Record=TR1

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

HD1666777888 888777666999999999 23423424220010327074920 PA491A

A49IP20010314PR66677788881818181834236 29038412302N20010301TR1000000001

HD1666777888 888777666999999999 23423424220010327074940 PA491A

A49IP20010314PR66677788881818181834236 29038412302N20010301 A49IP20010314PR66677788881818181834222 29045412302N20013045

TR1000000002

Header Record=HD1SROI Transaction=A49Trailer Record=TR1


A49 – Release 1 SROI Data

Batch Breakdown Example

HEADER RECORD:

HD1810461738 599012126810302402 59604801120010914124949 PA491A

A49RECORD 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 3Transactions/Records


Anything New or Different from R1 or R2

Companion

(R21)

Fixed length

Companion

(R22)

Fixed length

Accident/Injury Description

Benefit

Denial Reason Codes

Payments

Denial Reason Narratives

Other Benefits

Managed Care Org

Adjustments, Credits, Redistributions

Witness

Recoveries

Reduced Earnings

Concurrent Employer

Denial Reason Codes

Denial Reason Narratives

Suspension Narratives

IAIABC Claims Release 3 Transaction Design

FROI

SROI

Basic

148

Basic

A49

Fixed length

Fixed length

R1

Permanent Impairments

Payment Adjustments

Different

Adjustments

Different

Paid to Dates/Reduced Earnings/Recoveries

Different

Death Dependent Payee

R3






Hd1 release 3 header record
HD1 – Release 3 Header Record Release 3 (R21 or R22).

87 byte Fixed Length record

(Same as Release 1)


Hd1 release 3 header record1
HD1 – Release 3 Header Record Release 3 (R21 or R22).

uniquely identifiesthe sender,

the receiver,

the date and time batch was prepared


Hd1 release 3 header record2
HD1 – Release 3 Header Record Release 3 (R21 or R22).

whether the batch contains test or production data

and the Transaction type


Release 3 FROI record Release 3 (R21 or R22).148 – 913 Byte Fixed Length Record


Release 3 FROI Companion record Release 3 (R21 or R22).R21– Variable Length RecordVariable segment counters determine actual record length


Release 3 SROI record Release 3 (R21 or R22).A49– Variable Length RecordVariable segment counters determine actual record length.


Release 3 SROI Companion record Release 3 (R21 or R22).R22– Variable Length RecordVariable segment counters determine actual record length.


Release 3 variable segments

Counters determine the overall record length Release 3 (R21 or R22).

Release 3 Variable Segments

  • The transaction includes oneBenefits segment

  • Fixed length = 650

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

Partial display of SROI R22 record


Release 3 variable segments1

Counters determine the overall record length Release 3 (R21 or R22).

Release 3 Variable Segments

  • The transaction includes oneBenefitssegment and oneSuspension Narrative

  • Fixed length = 650

  • Benefitssegment = 103 bytes; Suspension Narrative = 50 bytes. The R22 record ends at position 803

Partial display of SROI R22 record


TR2 – Release 3 Trailer Record Release 3 (R21 or R22).

  • 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
Release 3 148/R21 – Release 3 (R21 or R22).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
Release 3 A49/R22 – Release 3 (R21 or R22).Subsequent Report of InjuryBatch/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? Release 3 (R21 or R22).


Break Time! Release 3 (R21 or R22).


Electronic Report Release 3 (R21 or R22).

Acknowledgment

Acknowledgment

Electronic Report

Acknowledgment

Overview


What is an acknowledgment

Electronic Release 3 (R21 or R22).

Report

Acknowledgment

What is an Acknowledgment?

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

Claim

Administrator

Jurisdiction


What is an acknowledgment1
What is an Acknowledgment? Release 3 (R21 or R22).

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



Transaction Accepted (TA) transaction?

  • 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 transaction?

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) transaction?

TR

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

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


Transaction Rejected (TR) transaction?

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


Transaction 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 transaction? 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 transaction?

  • 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


Rejected by Service Provider (TN) transaction?

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: transaction?

Release 1 vs. Release 3


Acknowledgement record layout comparison
Acknowledgement Record Layout Comparison transaction?

Release 1

(AK1)

Fixed

When Number of Errors > 0


Acknowledgement record layout comparison1
Acknowledgement Record Layout Comparison transaction?

Release 3

(AKC)

New elements and filler

New

Error Text


Release 1 transaction acknowledgment
Release 1 Transaction Acknowledgment transaction?

Jurisdiction returns:

Claim Administrator sends:

Header (HD1)

Header

148 Record 1

AK1TA Record 1

AK1 TA Record 2

148 Record 2

FROI

Transactions

148 Record 3

AK1 TE Record 3

148 Record 4

AK1TR Record 4

Trailer (TR1)

Trailer


Release 3 transaction acknowledgment

Header transaction?

FROI

Transactions

Trailer

Release 3 Transaction Acknowledgment

Claim Administrator sends:

Jurisdiction returns:

Header (HD1)

148 Record 1

AKCTA Record 1

R21 Record 2

148 Record 3

AKCTA Record 3

R21 Record 4

148 Record 5

AKCTE 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

M (Mandatory) transaction?

TR (Transaction Rejected)

MC (Mandatory/Conditional)*

O (Optional) **

C (Conditional) **

TE (Transaction Accepted with Errors)

TR (Transaction Rejected)

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 vs. Release 3Requirement Code Result of Failed Element Requirement

Requirement Code Result of Failed Element Requirement Edit

* Release 3 only

** Release 1 only


Acknowledgment transmission batch examples

EDI transaction?

301

Acknowledgment Transmission/Batch Examples


Ak1 release 1 transmission batch example
AK1 – Release 1 transaction?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 transaction?Transmission/Batch Example

Header

AKC

AKC

Trailer


AKC Release 3 transaction?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
Release 3 - Matching original batch to AKC batch using the Header RecordFROI Example

HEADER RECORD (HD1) for FROI

HD1666777888 888777666999999999 23423424220010327074530P14830

1 |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 to akc batch using trailer record froi example
Release 3 - Matching original batch to AKC batch using Trailer RecordFROI 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 Trailer Record

301

Interpreting Acknowledgments


Interpreting release 3 acknowledgment
Interpreting Release 3 Acknowledgment Trailer Record

AKC acknowledges Release 3 transactions.

Jurisdiction assigned Claim Number is acknowledged.


Interpreting release 3 acknowledgment1
Interpreting Release 3 Acknowledgment Trailer Record

Date and time the transaction was processed by receiving Jurisdiction

Jurisdiction returns value from original transaction, when available


Interpreting release 3 acknowledgment2
Interpreting Release 3 Acknowledgment Trailer Record

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 acknowledgment3
Interpreting Release 3 Acknowledgment Trailer Record

Result of jurisdiction’s applied edits;

Number of encountered errors.


Interpreting release 3 acknowledgment4

Number of Errors determine the overall record length Trailer Record

Interpreting Release 3 Acknowledgment

AKC Fixed length = 248

The AKC

includes two Error segments


Interpreting release 3 acknowledgment5
Interpreting Release 3 Acknowledgment Trailer Record

Element Error segment:

59 bytes x 2= 118.

The AKC record ends at position 366.


Interpreting release 3 acknowledgment6
Interpreting Release 3 Acknowledgment Trailer Record

The first error occurred on DN0134Calculated Weekly Compensation Amount.


Interpreting release 3 acknowledgment7
Interpreting Release 3 Acknowledgment Trailer Record

The amount reported was less than required by the jurisdiction.

Optional Element Error Text assists senders with error resolution.


Interpreting release 3 acknowledgment8
Interpreting Release 3 Acknowledgment Trailer Record

The second error occurred on DN0192 Benefit Payment Issue Date.

An invalid date was reported

in the secondBenefits segment of the SROI transaction.


Interpreting release 3 acknowledgment9
Interpreting Release 3 Acknowledgment Trailer Record

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


EDI Trailer Record

301

Release 3Error Correction


Error correction process
Error Correction Process Trailer Record

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 process1
Error Correction Process Trailer Record

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


Error correction process2
Error Correction Process Trailer Record

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 process3
Error Correction Process Trailer Record

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? Trailer Record



STANDARD USAGE FOR ALL PRODUCTS Trailer Record

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


Partnering agreement
Partnering Agreement Trailer Record

Jurisdiction

EDI Reporter


Trading partner profile
Trading Partner Profile Trailer Record

EDI Reporter

999999999

12345 6789


Receiver s specifications
Receiver’s Specifications Trailer Record

mm/dd/yyyy

Jurisdiction

999999999

12345 6789

Claims

EDI

3.0

AKC

2300 EST


Sender s response
Sender’s Response Trailer Record

mm/dd/yyyy

Jurisdiction

EDI Reporter

999999999

12345 6789

Claims

3.0

150


Claim Administrator ID List Trailer Record

EDI Reporter

999999999

12345 6789

mm/dd/yyyy

111111111

Best TPA

222222222

Insurance company

333333333

Self-Insured Employer


Maintaining senders authorization

EDI Trailer Record

301

Maintaining Senders’ Authorization


Trading Partner Validation Table Trailer Record

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


Trading Partner Validation Table Trailer Record

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 Trailer Record

A = Approved

R = Revoked

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


999999999 Trailer Record

123456789

A (Approved)

EDI Reporter

999999999

12345 6789

Authorized Sender details from the Trading Partner Profile are loaded into the jurisdiction’s Validation Table.


999999999 Trailer Record

123456789

A (Approved)

EDI Reporter

999999999

12345 6789

mm/dd/yyyy

111111111

Best TPA

222222222

Insurance company

333333333

Self-Insured Employer

Authorized Insurer/Claim Administrator IDs are loaded into the jurisdiction’s Validation Table.

A (Approved)

111111111

222222222

A (Approved)

333333333

A (Approved)


Validating sender authorization for the batch

EDI Trailer Record

301

Validating Sender Authorization for the Batch


999999999 Trailer Record

123456789

Approved

A (Approved)

111111111

R (Revoked)

222222222

333333333

A (Approved)

888888888

987654321

Approved

A (Approved)

888888888

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.


999999999 Trailer Record

123456789

Approved

A (Approved)

111111111

R (Revoked)

222222222

333333333

A (Approved)

888888888

987654321

Approved

A (Approved)

888888888

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 Trailer Record

301

Validating Sender Authorization for the Claim Administrator


999999999 Trailer Record

123456789

Approved

A (Approved)

111111111

R (Revoked)

222222222

333333333

A (Approved)

888888888

987654321

Approved

A (Approved)

888888888

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


999999999 Trailer Record

123456789

Approved

A (Approved)

111111111

R (Revoked)

222222222

333333333

A (Approved)

888888888

987654321

Approved

A (Approved)

888888888

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


999999999 Trailer Record

123456789

Approved

A (Approved)

111111111

R (Revoked)

222222222

333333333

A (Approved)

888888888

987654321

Approved

A (Approved)

888888888

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


Trading partner tables

EDI Trailer Record

301

Trading Partner Tables

  • Event Table

  • Element Requirement Table

  • Edit Matrix


Event table

EDI Trailer Record

301

Event Table


Event table1
Event Table Trailer Record

  • 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 table2
Event Table Trailer Record

  • 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 Trailer Record Event Table

Claims Release 3 Event Table


Interpreting release 1 event table

EDI Trailer Record

301

Interpreting Release 1 Event Table


Release 1 event table
Release 1 Trailer Record 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 table1
Release 1 Trailer Record Event Table

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

(partially presented)


Interpreting release 3 event table

EDI Trailer Record

301

Interpreting Release 3 Event Table


Release 3 event table
Release 3 Event Table Trailer Record

Jurisdiction's reporting requirements:

A report (Maintenance Type Code)

is due when theEvent Rule Criteria

is within Event Rule Date range (From/Thru),

Partial Table presented


Release 3 event table1
Release 3 Event Table Trailer Record

with the conditions described in theTrigger Criteria and Value.

Report due date is based on Report Due Value, Typeand From)

Partial Table presented


Release 3 event table2
Release 3 Event Table Trailer Record

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

Partial Table presented


Release 3 event table3
Release 3 Event Table Trailer Record

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? Trailer Record


Element requirement table

EDI Trailer Record

301

Element Requirement Table


Element requirement table1
Element Requirement Table Trailer Record

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 table2
Element Requirement Table Trailer Record

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

M (Mandatory) Trailer Record

RELEASE 1ANDRELEASE 3

O (Optional)

C (Conditional)

MC (Mandatory/Conditional)

E (Expected)

EC (Expected/Conditional)

IA (If Applicable/Available)

N/A (Not Applicable)

R (Restricted)

F (Fatal)

X (Exclude)

Element Requirement TableRequirement Code Values:

RELEASE 3ONLY

RELEASE 1ONLY


Element requirement table requirement code values1
Element Requirement Table Trailer RecordRequirement 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 values2
Element Requirement Table Trailer RecordRequirement 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 values3
Element Requirement Table Trailer RecordRequirement 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 values4
Element Requirement Table Trailer RecordRequirement 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 values5
Element Requirement Table Trailer RecordRequirement 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 Trailer RecordRequirement 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 values6
Element Requirement Table Trailer RecordRequirement 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 values7
Element Requirement Table Trailer RecordRequirement 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 values8
Element Requirement Table Trailer RecordRequirement 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 values9
Element Requirement Table Trailer RecordRequirement 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 values10
Element Requirement Table Trailer RecordRequirement Code Values:

Requirement Code limited to elements in the Benefitssegment.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 values11
Element Requirement Table Trailer RecordRequirement 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 values12
Element Requirement Table Trailer RecordRequirement 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 values13
Element Requirement Table Trailer RecordRequirement 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 values14
Element Requirement Table Trailer RecordRequirement 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 Trailer Record

301

Release 1 Element Requirement Table


Release 1 froi element requirement table
Release 1 FROI Element Requirement Table Trailer Record

(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 Trailer Record

301

Release 3 Element Requirement Table


Release 3 froi element requirement table
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

  • Standard Technical limitations are applied:

    • F(Fatal Technical)

    • X(Exclude)


Release 3 froi element requirement table1
Release 3 FROI Element Requirement Table Trailer Record

(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 table2
Release 3 FROI Element Requirement Table Trailer Record

(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 table3
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

MTCC and MTCC Date areFatalon CO (Correction) transactions


Release 3 froi element requirement table4
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

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


Release 3 froi element requirement table5
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

  • Standard requirement code for CO (Correction) MTC:

    • $Same requirements as the MTC being corrected


Release 3 froi element requirement table6
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

When MTC 00 is being corrected, those requirements apply


Release 3 froi element requirement table7
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

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


Release 3 froi element requirement table8
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

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


Release 3 froi element requirement table9
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

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


Release 3 froi element requirement table10
Release 3 FROI Element Requirement Table Trailer Record

(Partially presented)

M

M

E

EC

MC

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


Questions? Trailer Record


Edit matrix

EDI Trailer Record

301

Edit Matrix


Edit matrix1
Edit Matrix Trailer Record

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


Edit matrix2
Edit Matrix Trailer Record

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.


Release 1 edit matrix

EDI Trailer Record

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)


Release 3 edit matrix

EDI transaction.

301

Release 3 Edit Matrix


Release 3 edit matrix1
Release 3 Edit Matrix transaction.

The Matrix consists of 5 components:

  • DN-Error Messagecontains “standard” editing developed for Release 3 data elements.

  • Sequencingillustrates logical transaction sequencing for application of edit 063.

  • Value Tableexpresses the jurisdiction’s acceptable code values.

  • Match Datadescribes 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 Restrictionscontains the jurisdiction’s restrictions applied to the data element(s).



1. DN-Error Message table transaction.

Table is populated with standard default edits


1. DN-Error Message table transaction.

F = Fatal Technical edits

must be applied - data is essential for the transaction to be processed


1. DN-Error Message table transaction.

L = logical standard edit for the data element


1. DN-Error Message table transaction.

Jurisdiction will apply edits?

N = Jurisdiction will not apply any of the standard edit(s)

N


1. DN-Error Message table transaction.

Jurisdiction will apply edits?

Y = Jurisdiction will apply standard edits that are not “grayed out”

Y


1. DN-Error Message table transaction.

Edits that are “grayed out” will not be applied by the jurisdiction.

Y

L


1. DN-Error Message table transaction.

Population Restrictions Jurisdiction will indicate whether restrictions will be applied to reported values.


1. DN-Error Message table transaction.

Population Restrictions

Y alerts senders to review the restrictions imposed by the jurisdiction.

Y


2 value table
2. Value table transaction.


  • Value Table transaction.conveys code values that are expected to be reported to the jurisdiction, invalid values and values that may be suppressed

(Partial Table presented)


  • Value Table transaction.

  • Y = data element is collected by the jurisdiction

  • N = data element is not collected

Y

N

(Partial Table presented)


  • Value Table transaction.

  • Code values that are not valid are “grayed-out” by the jurisdiction

  • Code values that are not grayed-out are expected to be reported

Y

A

E

G

P

N

(Partial Table presented)


  • Value Table transaction.

  • Code values that are grayed-out in Section 2 are not collected by the jurisdiction. These code values may be suppressed by senders.

Y

N

H

K

(Partial Table presented)


3 match data table
3. Match Data table transaction.


3. Match Data transaction.

Match Data elements are used by jurisdictions to:

  • Identify new Claims

  • Find existing Claims, transactions or previously reported values


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


  • Match Data transaction.

  • P = Primary Match data element

  • S = Secondary Match data element

P

P

S

P

S


Jurisdiction transaction.

Claims

For instance, a Jurisdiction may define Match Dataelements for new claims as:

  • New Claim:Match

    • Employee ID Primary

    • Date of Injury Primary

3. Match Data

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


Jurisdiction transaction.

Claims

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.

Claim

  • New Claim:Match

    • Employee ID Primary

    • Date of Injury Primary


Jurisdiction transaction.

Claims

3. Match Data

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

New Claim

  • New Claim:Match

    • Employee ID Primary

    • Date of Injury Primary


Jurisdiction transaction.

Claims

3. Match Data

If the  Match Datakeys do exist on the jurisdiction’s data base, this FROI transaction may be rejected as a duplicate.

Claim

  • New Claim:Match

    • Employee ID Primary

    • Date of Injury Primary

X


Jurisdiction transaction.

Claims

3. Match Data

Once a claim has been established on the jurisdiction’s data base, Match Datakeys may be compared to previously reported data.

  • Existing Claim:Match

    • Jurisdiction Claim Number Primary

    • Employee ID Secondary

    • Date of Injury Secondary

Existing claim


Jurisdiction transaction.

Claims

3. Match Data

When a match is found with the Primary key(s),

the Secondary keys are used to validate data integrity.

  • Existing Claim: Match

    • Jurisdiction Claim Number Primary

    • Employee ID Secondary

    • Date of Injury Secondary

Existing claim



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

Returned on acknowledgment for reconciliation by senders

Maintenance Type

Code

FROI UI not accepted

Not statutorily valid

MTC’s not accepted: FROI UI

0002

042

Wage Period

Code

Must be 01 (Weekly)

Not statutorily valid

Code 2, 4, 6 and 7 are invalid

0063

042


5 sequencing
5. Sequencing transaction.


5. Sequencing transaction.

The Sequencingtable in the Edit Matrix is a model of the standard Sequencingoutline 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 transaction.

Application of Jurisdiction’stransaction sequence edits are defined on the Sequencing table.

Partial table presented


5. Sequencing transaction.

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

N

Partial table presented


5. Sequencing transaction.

Y = edit will be applied. Error text indicates why the report was rejected:

1b = 00 Original

1c = 04 Denial (FROI)

Event 1b or 1c not accepted by jurisdiction

Y

Event 1b or 1c not accepted by jurisdiction

Y


Questions
Questions? transaction.


Implementing edi with trading partners
Implementing EDI with Trading Partners transaction.

  • Obtain the IAIABC Implementation Guide

  • Obtainthe Jurisdiction Implementation/Requirements Guide

  • Prepare your System to send and receive the applicable data

  • Submitthe required Profiles and Agreements to the Jurisdiction

  • Begin the EDI Process


Thank you for attending edi 301

EDI transaction.

301

Thank youfor attending EDI 301!


ad