Upload
larissa-well
View
216
Download
1
Tags:
Embed Size (px)
Citation preview
EDI301
Advanced Technical Advanced Technical ConceptsConcepts
2008 IAIABC All Committee Conference
April 7-12, 2008 Austin, TX
ED
I 3
01
Robbie Robbie TannerTanner
email: [email protected]: [email protected]
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:
EDI
ED
I 3
01
Lori RabyLori Rabyemail: [email protected]: [email protected]
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
Your Trainers:Your Trainers:
EDI
ED
I 3
01
Sharon Sharon MarionMarion
email: [email protected]: [email protected]
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
Your Trainers:Your Trainers:
EDI
Transactions/Transactions/Records Records
(Fixed and Variable (Fixed and Variable Length)Length)
EDI301
6
ED
I 3
01
TransactionTransaction
A Transaction consists of 1 or more ‘records’ to communicate an event such as a claim event or policy event.
7
ED
I 3
01
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.
8
ED
I 3
01
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.
9
ED
I 3
01
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.
ED
I 3
01
Technically identified by DN0001-Transaction Set ID
Release 1 records are either fixedfixedor Variable Variable length.
IAIABC Release 1 Records
ED
I 3
01
IAIABC Release 3 RecordsTechnically identified by DN0001-Transaction Set ID Release 3 records are either fixedfixedor Variable Variable length.
Batches/Batches/TransmissionsTransmissions
EDI301
13
ED
I 3
01
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.
14
ED
I 3
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)
Batch
15
ED
I 3
01
• A Transaction can consist of 1 or more ‘Records’ to report a claim event.
TransactionsTransactions
16
ED
I 3
01
Release 1 uses 1 Record per Transaction to report a claim event.
148 148= FROI
A49= SROI
A49
17
ED
I 3
01
Release 3 requires 2 records per transaction to report a claim event.
148 + R21 = FROI
148
R21
A49 + R22 = SROI
A49
R22
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.
148
R21
R22
A49
Release 3 records
19
ED
I 3
01
Acknowledgment Transactions
Both Release 1 and Release 3 Acknowledgment transactions use 1 record to communicate an event.
20
ED
I 3
01
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
21
ED
I 3
01 B
ATCH
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
22
ED
I 3
01
SROITransactions
BATCH
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
23
ED
I 3
01 B
ATCH
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
24
ED
I 3
01
SROITransactions
BATCH
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
25
ED
I 3
01
BATCH
Components of a Transmission
SROITransactions
Header
Trailer
SROI
SROI
SROI
SROI
SROI
SROI
FROITransactions
Header
Trailer
FROI
FROI
FROI
FROI
FROI
FROI
FROI
FROI
BATCH
BATCH:BATCH: Consists of 1 Header record, one or more Transactions and 1 Trailer record.
26
ED
I 3
01
Components of a TransmissionTRANSMISSIOTRANSMISSION:N: Consists of 1 or more batches sent or received during a communication session.
TR
AN
SM
ISSIO
N
BATCH
SROITransactions
Header
Trailer
SROI
SROI
SROI
SROI
SROI
SROI
FROITransactions
Header
Trailer
FROI
FROI
FROI
FROI
FROI
FROI
FROI
FROI
BATCH
ED
I 3
01
Questions?
Data Data ElementElementFormatsFormats
EDI301
29
ED
I 3
01
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.
30
ED
I 3
01
Data Dictionary ExampleData Dictionary Example
Specific Data Element Specific Data Element InformationInformation
31
ED
I 3
01
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.
32
ED
I 3
01
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
33
ED
I 3
01
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
34
ED
I 3
01
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.
35
ED
I 3
01
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.
36
ED
I 3
01
Data Element FormatsData Element FormatsNumeric: Type = N:
Example: 3 numeric ‘123’ in 6 byte field = 000123
Spaces indicate absence of data.
123000
Valid values consist of 0 - 9 and are right justified zero filled to the left.
37
ED
I 3
01
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.
38
ED
I 3
01
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
Spaces indicate absence of data.
00^
$
39
ED
I 3
01
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.
125%
40
ED
I 3
01
Data Data ElementElement Formats FormatsPercentage: Type = 3.2:Valid entries consist of 0 - 9 and are right justified zero filled to the left.
Spaces indicate absence of data.
Example: 50.00% = 05000 ^
The decimal point is assumed between the third and fourth position.
41
ED
I 3
01
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).
42
ED
I 3
01
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)
43
ED
I 3
01
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.
Spaces indicate absence of data.
ED
I 3
01
Release 1Release 1Transactions/RecorTransactions/Recor
dsds
EDI301
ED
I 3
01
HD1 – Release 1 Header HD1 – Release 1 Header RecordRecordThere are 9 data elements
and the record is 87 bytes fixed length
ED
I 3
01
HD1 – Release 1 Header HD1 – Release 1 Header RecordRecorduniquely identifiesuniquely identifies the sender,
the receiver,the date and time batch was prepared
ED
I 3
01
HD1 – Release 1 Header HD1 – Release 1 Header RecordRecordwhether the batch contains test or production dataand the Transaction type
ED
I 3
01
148 - Release 1 FROI Record148 - Release 1 FROI Record 913 Byte Fixed Length Record
50
ED
I 3
01
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
1480020010327PR 666777888ABC INSURER 818181818TPA
TR1000000002
HD1666777888 888777666999999999 23423424220010327074630 P14801
1480020010327PR 666777888ABC INSURER 818181818TPA
TR1000000001
Header Record=HD1 FROI Transaction=148 Trailer Record=TR1
Header Record=HD1 FROI Transaction=148 Trailer Record=TR1
ED
I 3
01
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
dsds
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
R3
Release 1 data elements that differ in:
a)Functionality
b)definitionc)Format
become Filler in the R3 record layout.
ED
I 3
01
Positions in the 148 and A49 records are preserved for R1 usage.
60
ED
I 3
01
Modified data elements were moved to the companion record in Release 3 (R21 or R22).
61
ED
I 3
01
Modified data elements were moved to the companion record in Release 3 (R21 or R22).
ED
I 3
01
HD1 – Release 3 Header HD1 – Release 3 Header RecordRecord
87 byte Fixed Length record(Same as Release 1)
ED
I 3
01
HD1 – Release 3 Header HD1 – Release 3 Header RecordRecorduniquely identifiesuniquely identifies the sender,
the receiver,the date and time batch was prepared
ED
I 3
01
HD1 – Release 3 Header HD1 – Release 3 Header RecordRecordwhether the batch contains test or production dataand the Transaction type
65
ED
I 3
01
Release 3 FROI recordRelease 3 FROI record148 – 913 Byte Fixed Length Record
ED
I 3
01
Release 3 FROI Companion recordRelease 3 FROI Companion recordR21– Variable Length Record
Variable segment counters determine actual record length
67
ED
I 3
01
Release 3 SROI recordRelease 3 SROI recordA49– Variable Length Record
Variable segment counters determine actual record length.
ED
I 3
01
Release 3 SROI Companion Release 3 SROI Companion recordrecordR22– Variable Length RecordVariable segment counters determine actual record length.
Release 3 Variable Segments
Counters determine the overall record length
• The transaction includes one Benefits segment
• Benefits segment = 103 bytes. The R22 record ends at position 753
• Fixed length = 650
Partial display of SROI R22 record
Release 3 Variable Segments
Counters determine the overall record length
• The transaction includes one Benefits segment and one Suspension Narrative
• Benefits segment = 103 bytes; Suspension Narrative = 50 bytes. The R22 record ends at position 803
• Fixed length = 650
Partial display of SROI R22 record
71
ED
I 3
01
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)
ED
I 3
01
ED
I 3
01
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.
78
ED
I 3
01
What is an What is an Acknowledgment?Acknowledgment?
It contains enough information to identify the original transaction and any technical and business issues.
79
ED
I 3
01
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.
80
ED
I 3
01
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.
81
ED
I 3
01
What are the Application Acknowledgment Code
Values?
82
ED
I 3
01
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
83
ED
I 3
01
•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)
84
ED
I 3
01
•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
TR
85
ED
I 3
01
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
86
ED
I 3
01
•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)
87
ED
I 3
01
•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
88
ED
I 3
01
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
89
ED
I 3
01
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)
ED
I 3
01
Acknowledgments:Acknowledgments:
Release 1 vs. Release 3Release 1 vs. Release 3
Acknowledgement Record Layout Comparison
Release 1 (AK1)
Fixed
When Number of Errors > 0
Acknowledgement Record Layout Comparison
Release 3(AKC)
New elements and filler
New Error Text
93
ED
I 3
01
Release 1 Transaction Release 1 Transaction AcknowledgmentAcknowledgment
148 Record 1
148 Record 2
148 Record 3
148 Record 4
Header
Trailer
FROITransactio
ns
Header (HD1)
Trailer (TR1)
AK1 TA Record 1AK1 TA Record 2AK1 TE Record 3AK1 TR Record 4
Claim Administrator sends: Jurisdiction returns:
94
ED
I 3
01
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
ns
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:
ED
I 3
01
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
AKCAKC
TrailerTrailer
HeaderHeader
AKC Release 3AKC Release 3 Transmission/Batch Transmission/Batch ExampleExample
AKCAKC
AKCAKC
TrailerTrailer
HeaderHeader
HeaderHeader
AKCAKC
TrailerTrailer
AKCAKC
AKCAKC
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.
ED
I 3
01
Interpreting Interpreting AcknowledgmentsAcknowledgments
EDI301
Interpreting Release 3 Acknowledgment
AKC acknowledges Release 3 transactions.
Jurisdiction assigned Claim Number is acknowledged.
Interpreting Release 3 Acknowledgment
Date and time the transaction was processed by receiving JurisdictionJurisdictio
n returns value from original transaction, when available
Interpreting Release 3 Acknowledgment
Jurisdiction calculates and returns the position of the transaction within the batch.
Acknowledged transaction is identified.
MTC and MTC Date from original transaction
000000023
Interpreting Release 3 Acknowledgment
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
Interpreting Release 3 Acknowledgment
Element Error segment: 59 bytes x 2 = 118. The AKC record ends at position 366.
Interpreting Release 3 Acknowledgment
The first error occurred on DN0134 Calculated Weekly Compensation Amount.
Interpreting Release 3 Acknowledgment
Optional Element Error Text assists senders with error resolution.
The amount reported was less than required by the jurisdiction.
Interpreting Release 3 Acknowledgment
Interpreting Release 3 Acknowledgment
The second error occurred on DN0192 Benefit Payment Issue Date.An invalid date was reportedin the second Benefits segment of the SROI transaction.
Interpreting Release 3 Acknowledgment
Error Message 029 clearly describes the error; Element Error Text is optional.
ED
I 3
01
Release 3Error
Correction
EDI301
ED
I 3
01
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.
ED
I 3
01
Error Correction Error Correction ProcessProcess
When a Release 3 transaction is acknowledged with a TE (Transaction Accepted with error)
ED
I 3
01
Error Correction Error Correction ProcessProcess
The CO (Correction) transaction corrects the errors. The MTCC and Date are populated with the values from the transaction that had the error.
ED
I 3
01
Error Correction Error Correction ProcessProcess
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.
ED
I 3
01
Questions?
ED
I 3
01
Establishing the EDI Establishing the EDI PartnershipPartnership
121
ED
I 3
01
STANDARD USAGE FOR ALL PRODUCTS
http://www.iaiabc.org/EDI/default.asp
122
ED
I 3
01
Partnering Agreement
Jurisdiction
EDI Reporter
123
ED
I 3
01
Trading Partner Profile
999999999
EDI Reporter
12345 6789
124
ED
I 3
01
Receiver’s Specifications
Jurisdiction mm/dd/yyyy
999999999
Claims 3.0 AKC EDI
2300 EST
12345 6789
125
ED
I 3
01
Sender’s Response
mm/dd/yyyy
EDI Reporter
Jurisdiction
999999999 12345 6789
Claims 3.0
150
126
ED
I 3
01
EDI Reporter999999999 12345 6789
111111111Best TPA222222222Insurance company333333333Self-Insured Employer
Claim Administrator ID List
mm/dd/yyyy
Maintaining Senders’ Maintaining Senders’ AuthorizationAuthorization
EDI301
128
ED
I 3
01
Trading Partner Validation Table
In order to validate Senders’ authorization to submit EDI reporting, the jurisdiction maintains a Validation Table.
129
ED
I 3
01
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”.
130
ED
I 3
01
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 A (Approved)
888888888
987654321Approved
999999999
123456789
Approved
111111111222222222
333333333
A (Approved)R (Revoked)A (Approved)
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 A (Approved)
888888888
987654321Approved
999999999
123456789
Approved
111111111222222222
333333333
A (Approved)R (Revoked)A (Approved)
During Transaction Level editing, the Claim Administrator FEIN from the FROI or SROI record are checked against the jurisdiction’s Validation Table.
888888888 A (Approved)
888888888
987654321Approved
999999999
123456789
Approved
111111111222222222
333333333
A (Approved)R (Revoked)A (Approved)
If the Claim Administrator FEIN exists with Approved status the transaction is processed.
888888888 A (Approved)
888888888
987654321Approved
999999999
123456789
Approved
111111111222222222
333333333
A (Approved)R (Revoked)A (Approved)
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
142
ED
I 3
01
Event TableEvent Table
The Event Table is used by the Jurisdiction to convey the level of EDI reporting currently accepted. It is intended to help senders understand the jurisdictions’ EDI reporting requirements.
143
ED
I 3
01
Event TableEvent Table
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
ED
I 3
01
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)
ED
I 3
01
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
149
ED
I 3
01
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),
150
ED
I 3
01
Release 3 Event Table Release 3 Event Table
Partial Table presented
with the conditions described in the Trigger Criteria and Value.Report due date is based on Report Due Value, Type and From)
151
ED
I 3
01
Release 3 Event Table Release 3 Event Table
Partial Table presented
When the Event Rule Thru date is blank, reporting requirements apply until further notice.
152
ED
I 3
01
Release 3 Event Table Release 3 Event Table
Partial Table presented
When a Paper Form is indicated, this form must be sent to the Receiver indicated in addition to the electronic report.
ED
I 3
01
Questions?
Element Element Requirement TableRequirement Table
EDI301
155
ED
I 3
01
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.
156
ED
I 3
01
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).
157
ED
I 3
01
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)
158
ED
I 3
01
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 TableRequirement Code Values:
159
ED
I 3
01
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 TableRequirement Code Values:
160
ED
I 3
01
Element Requirement TableRequirement 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.
161
ED
I 3
01
Element Requirement TableRequirement 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.
162
ED
I 3
01
Element Requirement TableRequirement 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.
163
ED
I 3
01
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 TableRequirement Code Values:
164
ED
I 3
01
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 TableRequirement Code Values:
165
ED
I 3
01
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 TableRequirement Code Values:
166
ED
I 3
01
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 TableRequirement Code Values:
167
ED
I 3
01
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 TableRequirement Code Values:
168
ED
I 3
01
Requirement Code limited to elements in the Benefits segment. Release 3 only:
R = Restricted. The value of the data element will be accepted if a stated condition exists, as defined by the jurisdiction. For example, the jurisdiction does not accept Benefit Type Code 080 prior to a specified date of accident
Element Requirement TableRequirement Code Values:
169
ED
I 3
01
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.
Element Requirement TableRequirement Code Values:
170
ED
I 3
01
Requirement Codes limited to MTC 02 MTC 02 (Change) transaction.(Change) transaction. Release 3 only.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 TableRequirement Code Values:
171
ED
I 3
01
Requirement Codes limited to MTC 02 MTC 02 (Change) transaction.(Change) transaction. Release 3 only.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 TableRequirement Code Values:
172
ED
I 3
01
Requirement Codes limited to MTC 02 MTC 02 (Change) transaction.(Change) transaction. Release 3 only.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.
Element Requirement TableRequirement Code Values:
Release 1Release 1 Element Element Requirement TableRequirement Table
EDI301
174
ED
I 3
01
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
176
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
Standard Technical limitations are applied: F (Fatal Technical) X (Exclude)
(Partially presented)
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
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)
(Partially presented)
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
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)
(Partially presented)
179
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
MTCC and MTCC Date are Fatal on CO (Correction) transactions
(Partially presented)
180
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
These data elements notify the jurisdiction which transaction is being corrected (which requirements apply)
(Partially presented)
181
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
Standard requirement code for CO (Correction) MTC: $ Same requirements as the MTC being
corrected
(Partially presented)
182
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
When MTC 00 is being corrected, those requirements apply
(Partially presented)
183
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
For example, assume the 00 (Original) was missing the Number of Days Worked Per Week.
(Partially presented)
184
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
The jurisdiction returns a TE (Transaction accepted with Errors) acknowledgment.
(Partially presented)
185
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
When submitting the Correction to the error(s) on the 00 (Original)
(Partially presented)
186
ED
I 3
01
Release 3 FROI Element Release 3 FROI Element Requirement TableRequirement Table
the $ becomes the requirement code from the 00 (Original).
(Partially presented)
M
M
E
EC
MC
ED
I 3
01
Questions?
Edit MatrixEdit Matrix
EDI301
189
ED
I 3
01
Edit Matrix
The Edit Matrix presents standard application of edits to Claims data elements.
190
ED
I 3
01
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
ED
I 3
01
ER
RO
R M
ES
SA
GE
Ma
nd
ato
ry f
ield
no
t p
res
en
t
Nu
mb
er
of
Da
ys
wo
rke
d m
us
t
Nu
mb
er
of
Da
ys
mu
st
be
0-6
Mu
st
be
nu
me
ric
(0
-9)
Mu
st
be
a v
alid
da
te
Mu
st
be
A-Z
, 0
-9, o
r s
pa
ce
s
Mu
st
be
a v
alid
tim
e (
HH
MM
SS
)
Mu
st
be
<=
Da
te o
f In
jury
Mu
st
be
>=
Da
te o
f In
jury
Mu
st
be
>=
Da
te D
isa
bilit
y
DN DATA ELEMENT NAME 00
1
01
8
01
9
02
8
02
9
03
0
03
1
03
3
03
4
03
5
FIRST REPORT 0000 Entire Transaction0001 Transaction Set ID X0002 Maintenance Type Code X0003 Maintenance Type Code Date X X
(Partially presented)
Applied edits are indicated with an “X” at the intersection of the DN# and Error Message #.
Release 1 Edit Matrix
ED
I 3
01
ER
RO
R M
ES
SA
GE
Ma
nd
ato
ry f
ield
no
t p
res
en
t
Nu
mb
er
of
Da
ys
wo
rke
d m
us
t
Nu
mb
er
of
Da
ys
mu
st
be
0-6
Mu
st
be
nu
me
ric
(0
-9)
Mu
st
be
a v
alid
da
te
Mu
st
be
A-Z
, 0
-9, o
r s
pa
ce
s
Mu
st
be
a v
alid
tim
e (
HH
MM
SS
)
Mu
st
be
<=
Da
te o
f In
jury
Mu
st
be
>=
Da
te o
f In
jury
Mu
st
be
>=
Da
te D
isa
bilit
y
DN DATA ELEMENT NAME 00
1
01
8
01
9
02
8
02
9
03
0
03
1
03
3
03
4
03
5
FIRST REPORT 0000 Entire Transaction0001 Transaction Set ID X0002 Maintenance Type Code X0003 Maintenance Type Code Date X X
(Partially presented)
Failure of applied edits may result in rejection of the transaction.
Release 1 Edit Matrix
Release 3Release 3 Edit Matrix Edit Matrix
EDI301
195
ED
I 3
01
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:
ED
I 3
01
1. DN-Error Message table
ED
I 3
01
1. DN-Error Message tableTable is populated with standard default edits
ED
I 3
01
1. DN-Error Message tableF F = Fatal Technical editsmust be applied - data is essential for the transaction to be processed
ED
I 3
01
1. DN-Error Message tableL = logical standard edit for the data element
ED
I 3
01
1. DN-Error Message tableJurisdiction will apply edits?N = Jurisdiction will not apply any of the standard edit(s)
N
ED
I 3
01
1. DN-Error Message tableJurisdiction will apply edits?Y = Jurisdiction will apply standard edits that are not “grayed out”
Y
ED
I 3
01
1. DN-Error Message tableEdits that are “grayed out” will not be applied by the jurisdiction.
Y L
ED
I 3
01
1. DN-Error Message tablePopulation Restrictions Jurisdiction will indicate whether restrictions will be applied to reported values.
ED
I 3
01
1. DN-Error Message tablePopulation Restrictions Y alerts senders to review the restrictions imposed by the jurisdiction.
Y
ED
I 3
01 2. Value table
206
ED
I 3
01
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)
207
ED
I 3
01
2.Value Table Y = data element is collected by
the jurisdictionN = data element is not collected
(Partial Table presented)
Y
N
208
ED
I 3
01
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
(Partial Table presented)
Y
N
A E G P
H K
209
ED
I 3
01
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.
(Partial Table presented)
Y
N
H K
H K
ED
I 3
01 3. Match Data table
211
ED
I 3
01
Match Data elements are used by jurisdictions to: Identify new Claims Find existing Claims,
transactions or previously reported values
3. Match Data
ED
I 3
01
3.Match Data table describes the data elements that will be used as Match Data by the jurisdiction.
ED
I 3
01
3.Match Data P = Primary Match data elementS = Secondary Match data element
P
P
P
S
S
214
ED
I 3
01
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
ED
I 3
01
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
Claim
ED
I 3
01
If the Match Data keys do not exist, the jurisdiction will establish a new claim from the incoming transaction.
Jurisdiction
Claims
New Claim: Match Employee ID
Primary Date of Injury
Primary
New Claim
3. Match Data
ED
I 3
01
If the Match Data keys do exist on the jurisdiction’s data base, this FROI transaction may be rejected as a duplicate.
Jurisdiction
Claims
New Claim: Match Employee ID
Primary Date of Injury
Primary
Claim
X
3. Match Data
ED
I 3
01
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
ED
I 3
01
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
ED
I 3
01
4. Population Restrictions
221
ED
I 3
01
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
ED
I 3
01 5. Sequencing
223
ED
I 3
01
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
224
ED
I 3
01
Application of Jurisdiction’s transaction sequence edits are defined on the Sequencing table.
5. Sequencing
Partial table presented
225
ED
I 3
01
N = the sequencing edit will not be applied to the SROI report
N
5. Sequencing
Partial table presented
226
ED
I 3
01
Y = edit will be applied. Error text indicates why the report was rejected: 1b = 00 Original1c = 04 Denial (FROI)
Y
Y
Event 1b or 1c not accepted by jurisdictionEvent 1b or 1c not accepted by jurisdiction
5. Sequencing
ED
I 3
01
Questions?
ED
I 3
01
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
ED
I 3
01
Thank youThank youfor attending EDI 301!for attending EDI 301!
EDI301