Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "EDI 301 Advanced Technical Concepts 2008 IAIABC All Committee Conference April 7-12, 2008 Austin, TX."— Presentation transcript:

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

2 EDI 301 Robbie Tanner 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 Trainers: EDI

3 EDI 301 Lori Raby 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 Trainers: EDI

4 EDI 301 Sharon Marion EDI Coordinator – Peak Performance IAIABC Participation:  EDI Systems Committee Chair  EDI XML  EDI Medical  EDI Claims  EDI Trainer Your Trainers: EDI

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

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

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

8 EDI 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 EDI 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.

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

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

12 Batches/ Transmissions EDI 301

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

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

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

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

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

18 DN 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 EDI Acknowledgment Transactions Both Release 1 and Release 3 Acknowledgment transactions use 1 record to communicate an event.

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

21 EDI BATCHBATCH Batch example of R1 FROI transactions 8 records = 8 transactions 148Record 1 148Record 2 148Record 3 148Record 4 148Record 5 148Record 6 148Record 7 148Record 8 Header Trailer FROI Transactions

22 EDI SROI Transactions BATCHBATCH Batch example of R1 SROI transactions 8 records = 8 transactions A49Record 1 A49Record 2 A49Record 3 A49Record 4 A49Record 5 A49Record 6 A49Record 7 A49Record 8 Header Trailer

23 EDI BATCHBATCH Batch example of R3 FROI transactions 8 records = 4 transactions 148Record 1 R21Record 2 148Record 3 R21Record 4 148Record 5 R21Record 6 148Record 7 R21Record 8 Header Trailer FROI Transactions

24 EDI SROI Transactions BATCHBATCH Batch example of R3 SROI transactions 8 records = 4 transactions A49Record 1 R22Record 2 A49Record 3 R22Record 4 A49Record 5 R22Record 6 A49Record 7 R22Record 8 Header Trailer

25 EDI BATCHBATCH Components of a Transmission SROI Transactions Header Trailer SROI FROI Transactions Header Trailer FROI BATCHBATCH BATCH: BATCH: Consists of 1 Header record, one or more Transactions and 1 Trailer record.

26 EDI Components of a Transmission TRANSMISSION: TRANSMISSION: Consists of 1 or more batches sent or received during a communication session. TRANSMISSION BATCHBATCH SROI Transactions Header Trailer SROI FROI Transactions Header Trailer FROI BATCHBATCH

27 EDI 301 Questions?

28 Data Element Formats EDI 301

29 EDI 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.

30 EDI Data Dictionary Example Specific Data Element Information

31 EDI 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

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

33 EDI 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

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

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

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

37 EDI 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.

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

39 EDI 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%

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

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

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

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

44 EDI 301

45 Release 1 Transactions/Records EDI 301

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

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

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

49 EDI Release 1 FROI Record Release 1 FROI Record 913 Byte Fixed Length Record

50 EDI TR1 – Release 1 Trailer Record TR1 – Release 1 Trailer Record 12 Byte Fixed Length Record

51 148 – Release 1 FROI Batch/Transmission Example Transmission Sample Containing 1 Batch (Shown partial for display): HD P PR ABC INSURER TPA TR Transmission Sample Containing 2 Batches (Shown partial for display): HD P PR ABC INSURER TPA TR HD P PR ABC INSURER TPA TR Header Record=HD1FROI Transaction=148Trailer Record=TR1

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

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

54 A49 – Release 1 SROI Record A49 – Release 1 SROI Record Batch/Transmission Examples Transmission Sample Containing 1 Batch (Shown partial for display): HD PA491A A49IP PR N TR Transmission Sample Containing 2 Batches (Shown partial for display): HD PA491A A49IP PR N TR HD PA491A A49IP PR N A49IP PR N TR Header Record=HD1SROI Transaction=A49Trailer Record=TR1

55 HEADER RECORD: HD PA491A A49RECORD A49 RECORD BASE DATA- POSITIONS : A49SA MT N VARIABLE SEGMENT COUNTERS – POSITIONS : PERMANENT IMPAIRMENT DATA WHERE COUNTER = 01 – POSITIONS : PAYMENT ADJUSTMENT DATA WHERE COUNTER =02 – POSITIONS : PAID TO DATE/REDUCED EARNINGS/RECOVERIES DATA WHERE COUNTER = 03 – POSITIONS : TRAILER RECORD TRAILER RECORD: TR A49 – Release 1 SROI Data Batch Breakdown Example

56 Release 3 Transactions/Records EDI 301

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

58 Release 1 data elements that differ in: a)Functionality b)definition c)Format become Filler in the R3 record layout.

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

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

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

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

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

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

65 EDI Release 3 FROI record Release 3 FROI record 148 – 913 Byte Fixed Length Record

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

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

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

69 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

70 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 EDI TR2 – Release 3 Trailer Record designates the end of a batch of transactions records transactionsprovides a count of records and transactions within a batch is used to ensure that the entire batch is complete and valid

72 Release 3 148/R21 – First Report of Injury Release 3 148/R21 – First Report of Injury Batch/Transmission Example Transmission Sample Containing 1 Batch (Shown partial for display): HEADER RECORD (HD1): HD P14830 FIRST REPORT (148 ) (Shown partial for display) : PR ABC INSURER TPA FIRST REPORT COMPANION RECORD (R21) (Shown partial for display) : R CLMADMCLNUM ABC INSURER TRAILER RECORD (TR2): TR Interchange Version ID value for HD1: FROI Companion Record New field added to Release 3 Trailer record: Transaction Count (DN0191)

73 Release 3 A49/R22 – Subsequent Report of Injury Release 3 A49/R22 – Subsequent Report of Injury Batch/Transmission Example Transmission Sample Containing 1 Batch: HEADER RECORD (HD1): HD PA4930 SUBSEQUENT REPORT (A49 ) (Shown partial for display) : A49IP PR N SUBSEQUENT REPORT COMPANION RECORD (R22 ) (Shown partial for display): R CLMADMCLNUM ABC INSURER TRAILER RECORD (TR2): TR Interchange Version ID value for HD1: A4930 SROI Companion Record New field added to Release 3 Trailer record: Transaction Count (DN0191)

74 EDI 301

75 Break Time!

76 Acknowledgment Overview

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

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

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

80 EDI 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.

81 EDI What are the Application Acknowledgment Code Values?

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

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

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

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

86 EDI 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 Transaction Rejected (TR)

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

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

89 EDI 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 (TN)

90 EDI 301 Acknowledgments: Release 1 vs. Release 3

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

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

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

94 EDI Release 3 Transaction Acknowledgment 148Record 1 R21Record 2 148Record 3 R21Record 4 148Record 5 R21Record 6 148Record 7 R21Record 8 Header Trailer FROI Transactions 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:

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

96 Acknowledgment Transmission/Batch Examples EDI 301

97 AK1 – Release 1 Transmission/Batch Example Transmission Sample Containing 1 Batch (Shown partial for display): HD PAK101 AK A49TAINSRPTNUM AK A49TEINSRPTNUM TR Transmission Sample Containing 2 Batches (Shown partial for display): HD PAK101 AK TAINSRPTNUM TR HD PAK101 AK A49TAINSRPTNUM AK A49TEINSRPTNUM TR Header Record=HD1 Acknowledgment Transaction=AK1 Trailer Record=TR1

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

99 AKC AKC Trailer Header Header AKC Trailer AKC AKC AKC

100 Release 3 - Matching original batch to AKC batch using the Header Record FROI Example HEADER RECORD (HD1) for FROI HD P |2 | 3 |4 |5 |6 |7 |8|9 | HD PAKC30 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

101 Release 3 - Matching original batch to AKC batch using Trailer Record FROI Example TRAILER RECORD (TR2) for FROI TR TR TRAILER RECORD (TR2) for AKC 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. The count should be the same.

102 EDI 301

103 Interpreting Acknowledgments EDI 301

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

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

106 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

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

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

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

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

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

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

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

114 EDI 301 Release 3 Error Correction EDI 301

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

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

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

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

119 EDI 301 Questions?

120 EDI 301 Establishing the EDI Partnership

121 EDI STANDARD USAGE FOR ALL PRODUCTS

122 EDI Partnering Agreement Jurisdiction EDI Reporter

123 EDI Trading Partner Profile EDI Reporter

124 EDI Receiver’s Specifications Jurisdiction mm/dd/yyyy Claims 3.0AKC EDI 2300 EST

125 EDI Sender’s Response mm/dd/yyyy EDI Reporter Jurisdiction Claims

126 EDI EDI Reporter Best TPA Insurance company Self-Insured Employer Claim Administrator ID List mm/dd/yyyy

127 Maintaining Senders’ Authorization EDI 301

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

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

130 EDI 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

131 A (Approved) Authorized Sender details from the Trading Partner Profile are loaded into the jurisdiction’s Validation Table EDI Reporter

132 A (Approved) Authorized Insurer/Claim Administrator IDs are loaded into the jurisdiction’s Validation Table A (Approved) EDI Reporter Best TPA Insurance company Self-Insured Employer mm/dd/yyyy

133 Validating Sender Authorization for the Batch EDI 301

134 A (Approved) Approved Approved 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.

135 A (Approved) Approved Approved 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.

136 Validating Sender Authorization for the Claim Administrator EDI 301

137 A (Approved) Approved Approved 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.

138 A (Approved) Approved Approved A (Approved) R (Revoked) A (Approved) If the Claim Administrator FEIN exists with Approved status the transaction is processed.

139 A (Approved) Approved Approved 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.

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

141 Event Table EDI 301

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

143 EDI Event 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

144 Claims Release 1 Event Table Claims Release 3 Event Table

145 Interpreting Release 1 Event Table EDI 301

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

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

148 Interpreting Release 3 Event Table EDI 301

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

150 EDI 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 EDI Release 3 Event Table Partial Table presented When the Event Rule Thru date is blank, reporting requirements apply until further notice.

152 EDI 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.

153 EDI 301 Questions?

154 Element Requirement Table EDI 301

155 EDI 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 EDI 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 EDI 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 Table Requirement Code Values: MC (Mandatory/Conditional) R (Restricted)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

172 EDI MTC 02 (Change) transaction. Release 3 only. 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. Element Requirement Table Requirement Code Values:

173 Release 1 Element Requirement Table EDI 301

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

175 Release 3 Element Requirement Table EDI 301

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

177 EDI 301 Release 3 FROI Element Requirement 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)

178 EDI 301 Release 3 FROI Element Requirement 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 EDI Release 3 FROI Element Requirement Table MTCC and MTCC Date are Fatal on CO (Correction) transactions (Partially presented)

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

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

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

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

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

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

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

187 EDI 301 Questions?

188 Edit Matrix EDI 301

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

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

191 Release 1 Edit Matrix EDI 301

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

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

194 Release 3 Edit Matrix EDI 301

195 EDI Sequencing illustrates logical transaction sequencing for application of edit 063. Release 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:

196 EDI DN-Error Message table

197 EDI DN-Error Message table Table is populated with standard default edits

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

199 EDI DN-Error Message table L = logical standard edit for the data element

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

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

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

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

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

205 EDI Value table

206 EDI 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 EDI Value Table Y = data element is collected by the jurisdiction N = data element is not collected (Partial Table presented) Y N

208 EDI Value Table Code values that are not valid are “grayed-out” by the jurisdiction Code values that are not grayed-out are expected to be reported (Partial Table presented) Y N AEGP HK

209 EDI 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 HK HK

210 EDI Match Data table

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

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

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

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

215 EDI 301 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 IDPrimary  Date of InjuryPrimary 3. Match Data Claim

216 EDI 301 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 IDPrimary  Date of InjuryPrimary New Claim 3. Match Data

217 EDI 301 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 IDPrimary  Date of InjuryPrimary Claim X 3. Match Data

218 EDI 301 Jurisdiction Once 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 NumberPrimary  Employee IDSecondary  Date of InjurySecondary Existing claim 3. Match Data

219 EDI 301 Jurisdiction When a match is found with the Primary key(s), the Secondary keys are used to validate data integrity. Claims Existing Claim:Match  Jurisdiction Claim NumberPrimary  Employee IDSecondary  Date of InjurySecondary Existing claim 3. Match Data

220 EDI Population Restrictions

221 EDI Population Restrictions Elaborates on data elements’ specific data population limitations or accepted values for standard error messages 0002 Maintenance Type Code 042 FROI UI not accepted MTC’s not accepted: FROI UI Not statutorily valid 0063 Wage 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

222 EDI Sequencing

223 EDI 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 EDI Application of Jurisdiction’s transaction sequence edits are defined on the Sequencing table. 5. Sequencing Partial table presented

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

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

227 EDI 301 Questions?

228 EDI 301 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

229 EDI 301 Thank you for attending EDI 301! EDI 301


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

Similar presentations


Ads by Google