Presentation on theme: "Advanced Technical Concepts"— Presentation transcript:
1Advanced Technical Concepts 2008 IAIABC All Committee Conference April 7-12, 2008 Austin, TX
2Assistant Director WC Network Products, ISO Your Trainers:Robbie TannerAssistant Director WC Network Products, ISOIAIABC Participation:EDI SystemsEDI XML Work Group LeaderEDI ClaimsEDI Proof Of CoverageEDI MedicalEDI TrainerIAIABCTraining TeamEDI
3IT Business Analysis Consultant – Ingenix/ROES Your Trainers:Lori RabyIT Business Analysis Consultant – Ingenix/ROESIAIABC Participation:EDI Systems Committee Vice ChairEDI ClaimsEDI XMLEDI Proof Of Coverage (POC)EDI MedicalEDI TriageEDI TrainerIAIABCTraining TeamEDI
5Transactions/ Records (Fixed and Variable Length) EDI301Transactions/ Records (Fixed and Variable Length)
6TransactionA Transaction consists of 1 or more ‘records’ to communicate an event such as a claim event or policy event.
7RecordA 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.
8Fixed Length RecordsA 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.
9Variable 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.
10Technically identified by DN0001-Transaction Set ID IAIABC Release 1 RecordsTechnically identified by DN0001-Transaction Set IDRelease 1 records are either fixedor Variable length.
11IAIABC Release 3 Records Technically identified by DN0001-Transaction Set IDRelease 3 records are either fixedor Variable length.
13Batch Each Transaction Type (transaction) is contained in a batch which is preceded by a Header Recordand concluded with a Trailer Record.HeaderTransactionsTrailer
14The Header Record (HD1)precedes each batch of data. It is the first record in every batchuniquely identifies information about the batch and the data within the batchBatchalong with the Trailer Record forms an “envelope” that surrounds a batch of transactions
15TransactionsA Transaction can consist of 1 or more ‘Records’ to report a claim event.
16Release 1 uses 1 Record per Transaction to report a claim event. 148148= FROIA49A49= SROI
17Release 3 requires 2 records per transaction to report a claim event. 148+ R21= FROI148R21A49A49+ R22= SROIR22
18Release 3 recordsDN Claim Administrator Claim Number is populated in all Release 3 FROI and SROI records.148R21A49This “links” the companion record to its related 148 or A49 record.R22
19Acknowledgment Transactions Both Release 1 and Release 3 Acknowledgment transactions use 1 record to communicate an event.
20The Trailer Record designates the end of a batch of transactions provides a count of records/transactions within a batchis used to ensure that the entire batch is complete and validalong with the Header record completes the “envelope” that surrounds a batch of transactions
21Header B A T FROI C Transactions H Trailer Batch example of R1 FROI transactions8 records = 8 transactionsHeader148 Record 1148 Record 2BATCH148 Record 3FROITransactions148 Record 4148 Record 5148 Record 6148 Record 7148 Record 8Trailer
22Header B A T SROI C Transactions H Trailer Batch example of R1 SROI transactions8 records = 8 transactionsHeaderA49 Record 1A49 Record 2BATCHSROITransactionsA49 Record 3A49 Record 4A49 Record 5A49 Record 6A49 Record 7A49 Record 8Trailer
23Header B A FROI T Transactions C H Trailer Batch example of R3 FROI transactions8 records = 4 transactionsHeader148 Record 1R21 Record 2BATCHFROITransactions148 Record 3R21 Record 4148 Record 5R21 Record 6148 Record 7R21 Record 8Trailer
24Header B A SROI T Transactions C H Trailer Batch example of R3 SROI transactions8 records = 4 transactionsHeaderA49 Record 1R22 Record 2BATCHSROITransactionsA49 Record 3R22 Record 4A49 Record 5R22 Record 6A49 Record 7R22 Record 8Trailer
25Components of a Transmission FROIBATCHFROITransactionsHeaderTrailerBATCH: Consists of1 Header record, one or more Transactions and 1 Trailer record.SROITransactionsHeaderTrailerBATCHSROI
26Components of a Transmission FROIBATCHFROITransactionsHeaderTrailerTRANSMISSION: Consists of 1 or more batches sent or received during a communication session.TRANSMISSIONSROITransactionsHeaderTrailerBATCHSROISROISROISROISROISROI
29Data 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.
30Data Dictionary Example Specific Data Element Information
31Data Element Formats Example: Dates: Type = DATE (CCYYMMDD): Data elements that are assigned the format of DATE should be populated with only a valid date.Example:December 1, 2001 should be populated with
32Data Element FormatsDates: Type = DATE:CCYYMMDDAll zeros in a date field are considered to be invalid data.= invalid data‘ ’ Spaces indicate absence of data.
33Data 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
34Data 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.
35Data Element FormatsNumeric: Type = N: Data elements that are assigned the format of N should be populated with only a valid numeric character.
36Data Element Formats Numeric: Type = N: Valid values consist of and are right justified zero filled to the left.Example:3 numeric ‘123’ in 6 byte field =000123Spaces indicate absence of data.
37Data 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.
38Data Element Formats $ 0000000 50 00 Monetary Amounts: Type = $9.2: Valid entries consist of eleven numeric digits with the dollar sign assumed and the decimal point between the ninth and tenth position assumed.Example: = $50.00$5000^Spaces indicate absence of data.
39Data Element FormatsPercentage: Type = 3.2: Data elements that are assigned the format of 3.2 should be populated with only a valid percentage.125%
40Data Element Formats Example: 50.00% = 05000 Percentage: Type = 3.2: Valid entries consist of0 - 9 and are right justified zero filled to the left.Example: 50.00% = 05000^The decimal point is assumed between the third and fourth position.Spaces indicate absence of data.
41Data 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).
42Data Element Formats SMITH Alphanumeric: Type = A/N: When using an alphanumeric field, the significant characters are always left justified in the field with any remaining space in the field padded with spaces.SMITH(spaces)
43Data Element FormatsAlphanumeric: Type = A/N:Alphanumeric character set includes those selected from the uppercase letters, lower case letters, numeric digits, space character, and special characters.See System Rules of the R3 Implementation Guide.Spaces indicate absence of data.
52A49 - Release 1 SROI record Variable Length Record Variable segment Counters determine actual record length
53Release 1 A49 Variable Segments Partial display of SROI A49 record Counters determine the overall record lengthOne Perm ImpairTwo Pmt/AdjThree PTD/RE/RECFixed length = 208Perm Impair = 8 bytesPmt/Adj = 46 bytes x 2PTD/RE/REC = 14 bytes x 3The A49 record endsat position 350
54A49 – Release 1 SROI Record Batch/Transmission Examples Transmission Sample Containing 1 Batch (Shown partial for display):HD PA491AA49IP PR N TRHeader Record=HD1 SROI Transaction=A49 Trailer Record=TR1Transmission Sample Containing 2 Batches (Shown partial for display):HD PA491AA49IP PR N TRHD PA491AA49IP PR N A49IP PR NTRHeader Record=HD1 SROI Transaction=A49 Trailer Record=TR1
55A49 – Release 1 SROI Data Batch Breakdown Example HEADER RECORD: HD PA491AA49 RECORD BASE DATA- POSITIONS :A49SA MT NVARIABLE 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:TR
57IAIABC Claims Release 3 Transaction Design FROISROIBasic148BasicA49R1Fixed lengthFixed lengthPermanent ImpairmentsPayment AdjustmentsDifferentAdjustmentsDifferentPaid to Dates/Reduced Earnings/RecoveriesDifferentDeath Dependent PayeeAnything New or Different from R1 or R2WitnessAccident/Injury DescriptionCompanion(R21)Fixed lengthManaged Care OrgDenial Reason CodesDenial Reason NarrativesSuspension NarrativesCompanion(R22)BenefitReduced EarningsAdjustments, Credits, RedistributionsConcurrent EmployerFixed lengthRecoveriesOther BenefitsPaymentsDenial Reason CodesDenial Reason NarrativesR3
58Release 1 data elements that differ in: FunctionalitydefinitionFormatbecome Filler in the R3 record layout.
59Positions in the 148 and A49 records are preserved for R1 usage.
60Modified data elements were moved to the companion record in Release 3 (R21 or R22).
61Modified data elements were moved to the companion record in Release 3 (R21 or R22).
62HD1 – Release 3 Header Record 87 byte Fixed Length record(Same as Release 1)
63HD1 – Release 3 Header Record uniquely identifies the sender,the receiver,the date and time batch was prepared
64HD1 – Release 3 Header Record whether the batch contains test or production dataand the Transaction type
65Release 3 FROI record 148 – 913 Byte Fixed Length Record
66Release 3 FROI Companion record R21– Variable Length Record Variable segment counters determine actual record length
67Release 3 SROI record A49– Variable Length Record Variable segment counters determine actual record length.
68Release 3 SROI Companion record R22– Variable Length Record Variable segment counters determine actual record length.
69Release 3 Variable Segments Counters determine the overall record lengthThe transaction includes one Benefits segmentFixed length = 650Benefits segment = 103 bytes. The R22 record ends at position 753Partial display of SROI R22 record
70Release 3 Variable Segments Counters determine the overall record lengthThe transaction includes one Benefits segment and one Suspension NarrativeFixed length = 650Benefits segment = 103 bytes; Suspension Narrative = 50 bytes. The R22 record ends at position 803Partial display of SROI R22 record
71TR2 – Release 3 Trailer Record designates the end of a batch of transactionsprovides a count of records and transactions within a batchis used to ensure that the entire batch is complete and valid
72Release 3 148/R21 – First Report of Injury Batch/Transmission Example Transmission Sample Containing 1 Batch (Shown partial for display):HEADER RECORD (HD1):HD P14830FIRST REPORT (148 ) (Shown partial for display) :PR ABC INSURER TPAFIRST REPORT COMPANION RECORD (R21) (Shown partial for display) :R CLMADMCLNUM ABC INSURERTRAILER RECORD (TR2):TRInterchange Version ID value for HD1: 14830FROI Companion RecordNew field added to Release 3 Trailer record: Transaction Count (DN0191)
73Release 3 A49/R22 – Subsequent Report of Injury Batch/Transmission Example Transmission Sample Containing 1 Batch:HEADER RECORD (HD1):HD PA4930SUBSEQUENT REPORT (A49 ) (Shown partial for display) :A49IP PR NSUBSEQUENT REPORT COMPANION RECORD (R22 ) (Shown partial for display):R CLMADMCLNUM ABC INSURERTRAILER RECORD (TR2):TRInterchange Version ID value for HD1: A4930SROI Companion RecordNew field added to Release 3 Trailer record: Transaction Count (DN0191)
77What is an Acknowledgment? A transaction returned by the jurisdiction as a result of a report sent.ClaimAdministratorElectronicReportJurisdictionAcknowledgment
78What is an Acknowledgment? It contains enough information to identify the original transaction and any technical and business issues.
79How does the acknowledgment communicate the status of the transaction? Using the Application Acknowledgment Code (DN0111), located in each acknowledgment record.
80How 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.
81What are the Application Acknowledgment Code Values?
82Transaction Accepted (TA) The transaction was accepted by the jurisdictionNo errors were found on the transactionNo further reporting isrequired on the specific transaction
83Transaction Accepted with Error (TE) An error was found on an Expected, Expected Conditional or If Applicable/Available data elementAn MTC CO (Correction) should be submitted to resolve the error(s)
84Transaction Rejected (TR) An error was found on a mandatory or mandatory conditional data elementTRThe transaction was not accepted or added to the jurisdiction’s system as a reported claim
85Transaction Rejected (TR) A review of the error should take place to determine what action should be taken to resolve the issue
86Transaction Rejected (TR) An MTC CO (Correction) is not used to respond to a TR acknowledgmentIf an error of duplicate transaction, invalid event sequence, etc. then resubmission may not be required
87Batch Rejected (HD) The Batch is rejected in its entirety When a Batch Reject Occurs, only one AKC record may be returned in the acknowledgment batch
88Batch Reject ReasonsInvalid Sender ID (In most cases, no acknowledgment batch will be returned. Sender is unknown)Invalid data in Header RecordDuplicate BatchInvalid data in Trailer RecordTransaction not present in the batch
89An EDI Service Provider: Rejected by Service Provider (TN)An EDI Service Provider:Performs a service for their client to evaluate data prior to submission to a JurisdictionDetermines that the data fails the Jurisdiction mandatory requirementsReports errors to their client resulting in resubmission of the report to the jurisdiction
91Acknowledgement Record Layout Comparison Release 1(AK1)FixedWhen Number of Errors > 0
92Acknowledgement Record Layout Comparison Release 3(AKC)New elements and fillerNewError Text
93Release 1 Transaction Acknowledgment Claim Administrator sends:Jurisdiction returns:HeaderHeader (HD1)148 Record 1AK1 TA Record 1148 Record 2AK1 TA Record 2FROITransactions148 Record 3AK1 TE Record 3148 Record 4AK1 TR Record 4Trailer (TR1)Trailer
94Release 3 Transaction Acknowledgment Claim Administrator sends:Jurisdiction returns:Header (HD1)148 Record 1AKC TA Record 1HeaderTrailerFROITransactionsR21 Record 2148 Record 3AKC TA Record 3R21 Record 4148 Record 5AKC TE Record 5R21 Record 6148 Record 7AKC TR Record 7R21 Record 8Trailer (TR2)
95Release 1 vs. Release 3 Requirement Code Result of Failed Element Requirement Requirement Code Result of Failed Element Requirement EditM (Mandatory)TR (Transaction Rejected)C (Conditional) **TR (Transaction Rejected)O (Optional) **TE (Transaction Accepted with Errors)MC (Mandatory/Conditional)*TR (Transaction Rejected)E (Expected) *TE (Transaction Accepted with Errors)EC (Expected/Conditional) *TE (Transaction Accepted with Errors)IA (If Applicable/Available) *TA (Transaction Accepted) ORTE (Transaction Accepted with Errors)N/A (Not Applicable) *No requirement edits may be appliedR (Restricted) *TR (Transaction Rejected)F (Fatal) *TR (Transaction Rejected)X (Exclude) *No requirement edits may be applied** Release 1 only* Release 3 only
97AK1 – Release 1 Transmission/Batch Example Transmission Sample Containing 1 Batch (Shown partial for display):HD PAK101AK A49TAINSRPTNUM AK A49TEINSRPTNUMTRTransmission Sample Containing 2 Batches (Shown partial for display):HD PAK101AK TAINSRPTNUMTRHD PAK101AK A49TAINSRPTNUM AK A49TEINSRPTNUMTRHeader Record=HD1Acknowledgment Transaction=AK1Trailer Record=TR1
98AKC Release 3 Transmission/Batch Example HeaderAKCAKCTrailer
99AKC Release 3 Transmission/Batch Example HeaderAKCAKCTrailerHeaderAKCAKCAKCAKCTrailer
100Release 3 - Matching original batch to AKC batch using the Header Record FROI Example HEADER RECORD (HD1) for FROIHD P148301 | | | | | | |8| |HD PAKC30HEADER RECORD (HD1) for AKC1=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
101The count should be the same. Release 3 - Matching original batch to AKC batch using Trailer Record FROI ExampleTRAILER RECORD (TR2) for FROITRTRTRAILER RECORD (TR2) for AKCThe count should be the same.Transaction Count (DN0191) is the total number of transactions sent as part of the batch.The FROI or SROI Transaction Count should be matched to the AKC Transaction Count.
104Interpreting Release 3 Acknowledgment AKC acknowledges Release 3 transactions.Jurisdiction assigned Claim Number is acknowledged.
105Interpreting Release 3 Acknowledgment Date and time the transaction was processed by receiving JurisdictionJurisdiction returns value from original transaction, when available
106Interpreting 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
107Interpreting Release 3 Acknowledgment Result of jurisdiction’s applied edits;Number of encountered errors.
108Interpreting Release 3 Acknowledgment Number of Errors determine the overall record lengthAKC Fixed length = 248The AKCincludes two Error segments
109Interpreting Release 3 Acknowledgment Element Error segment:59 bytes x 2 = 118.The AKC record ends at position 366.
110Interpreting Release 3 Acknowledgment The first error occurred on DN0134 Calculated Weekly Compensation Amount.
111Interpreting Release 3 Acknowledgment The amount reported was less than required by the jurisdiction.Optional Element Error Text assists senders with error resolution.
112Interpreting 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.
113Interpreting Release 3 Acknowledgment Error Message 029 clearly describes the error; Element Error Text is optional.
115Error 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.
116Error Correction Process When a Release 3 transaction is acknowledged with a TE (Transaction Accepted with error)
117Error 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.
118Error 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.
128Trading Partner Validation Table In order to validate Senders’ authorization to submit EDI reporting, the jurisdiction maintains a Validation Table.
129Trading Partner Validation Table Example shows “keys” onlyJurisdiction may store additional details such as address, EDI technical and business Contact information from the Trading Partner Agreement in addition to the “keys”.
130Trading Partner Validation Table A = ApprovedR = RevokedIn this example, authorization “status” of both the Sender and Claim Administrator/ Insurer/Self-Insured is maintained.
131Authorized Sender details from the Trading Partner Profile are loaded into the jurisdiction’s Validation Table.EDI ReporterA (Approved)
132Authorized Insurer/Claim Administrator IDs are loaded into the jurisdiction’s Validation Table. EDI ReporterBest TPAInsurance companySelf-Insured Employermm/dd/yyyyA (Approved)A (Approved)A (Approved)A (Approved)
133Validating Sender Authorization for the Batch EDI301Validating Sender Authorization for the Batch
134If Sender exists with Approved status, the batch is processed. A (Approved)ApprovedR (Revoked)During Batch Level editing, the Sender FEIN and Postal Code from the Header record are checked against the Validation Table.If Sender exists with Approved status, the batch is processed.
135A (Approved)ApprovedR (Revoked)If Sender ID does not exist in the Validation Table or authorization is revoked, jurisdiction will reject the entire batch.
136Validating Sender Authorization for the Claim Administrator EDI301Validating Sender Authorization for the Claim Administrator
137A (Approved)ApprovedR (Revoked)During Transaction Level editing, the Claim Administrator FEIN from the FROI or SROI record are checked against the jurisdiction’s Validation Table.
138A (Approved)ApprovedR (Revoked)If the Claim Administrator FEIN exists with Approved status the transaction is processed.
139A (Approved)ApprovedR (Revoked)If Claim Administrator ID does not exist in the Validation Table or authorization is revoked, jurisdiction will reject the transaction.
142Event TableThe 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.
143Event Table Describes conditions that “trigger” electronic reports Provide timeframes for sending the informationDescribes Report due dates based on jurisdictions’ legislative mandates and/or voluntary reporting requirements
146Release 1 Event Table Jurisdiction's reporting requirements: A Report (Maintenance Type Code)is due in Production environmentwhen FROM/THRU Datesmeet the Report Trigger Criteria and value.(partially presented)
147Release 1 Event TableWhen the Event Rule Thru date is blank, reporting requirements apply until further notice.(partially presented)
158Element Requirement Table Requirement Code Values: Systems/Processing Requirement Code:F = Fatal Technical. Data elements that are essential for a transaction to be accepted into a jurisdictions workers compensation administration database or acknowledgment back to the claim administrator. Release 3 only.
159Element Requirement Table Requirement Code Values: Systems/Processing Requirement Code:X = Exclude. The data element is not applicable to the MTC. Release 3 only.Example: DN# 0005 – Jurisdiction Claim Number for an MTC-00 Original – the data provider would not yet have the data.
160Element 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.
161Element 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.
162Element 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.
163Element Requirement Table Requirement Code Values: O = Optional: The data element is not required to be sent. Release 1 only.If it is sent, edits are applied to it, but unsuccessful edits will not cause a transaction rejection (TR).
164Element Requirement Table Requirement Code Values: E = Expected. The data element is expected on the MTC, yet the transaction will be accepted with errors should it fail any edit. Release 3 only.If an “E” is designated, the transaction will not be rejected if it is the only edit failure.
165Element Requirement Table Requirement Code Values: EC =Expected/Conditional. The data element becomes expected under conditions established by the receiver. Release 3 only.The jurisdiction should describe the specific circumstance which causes the element to become expected.The transaction will be accepted with errors should it fail any edit.
166Element Requirement Table Requirement Code Values: IA = If Applicable/Available. Data should be sent if available. The data may or may not be populated.If present, may be edited for valid value and/or format. Release 3 only.Jurisdiction may or may not return an error on validity edits.
167Element Requirement Table Requirement Code Values: NA = Not Applicable. The data element is not applicable to the jurisdiction’s requirements for the MTC and may or may not be sent; edits must not be applied. Release 3 only.
168Element Requirement Table Requirement Code Values: Requirement Code limited to elements in the Benefits segment. Release 3 only:R = Restricted. The value of the data element will be accepted if a stated condition exists, as defined by the jurisdiction.For example, the jurisdiction does not accept Benefit Type Code 080 prior to a specified date of accident
169Element Requirement Table Requirement Code Values: Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only.Whenever a data element that has been marked as FY, Y, or YC on the Element Requirement table under MTC 02 has changed, the claim administrator must trigger an 02 change transaction unless another MTC applies.Refer to 02 Change Processing Rules in the Release 3 Implementation guide.
170Element Requirement Table Requirement Code Values: Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only.FY = Fatal Yes Change. An 02 Change transaction should be triggered when the value of this Fatal/Technical data element has changed when the jurisdiction’s Element Requirement Table indicates an “FY” requirement code.
171Element Requirement Table Requirement Code Values: Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only.Y = Yes Change. The data element must be sent on an 02 Change transaction if the value has changed.This DN should be populated if it has ever been reported on the claim.Spaces imply intentional removal of previously reported data.
172Element Requirement Table Requirement Code Values: Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only.YC = Yes Change/Conditional. Send an 02 Change transaction if the data element changes under these predefined conditions:Benefit Type Claim Weeks, Benefit Type Claim Days and Benefit Type Amount Paid were reported in error on a Benefit Type Code that was ended.
173Release 1 Element Requirement Table EDI301Release 1 Element Requirement Table
174Release 1 FROI Element Requirement Table (Partially presented)Requirement codes limited to:M (Mandatory) - reject if absent/invalidC (Conditional) - reject if absent/invalid with defined conditionsO (Optional) - not required
175Release 3 Element Requirement Table EDI301Release 3 Element Requirement Table
176Release 3 FROI Element Requirement Table (Partially presented)Standard Technical limitations are applied:F (Fatal Technical)X (Exclude)
177Release 3 FROI Element Requirement Table (Partially presented)Release 3 provides more options to describe requirement severity:E (Expected) EC (Expected/Conditional)M (Mandatory) MC (Mandatory/Conditional)NA (Not Applicable) IA (If Applicable/Available)
178Release 3 FROI Element Requirement Table (Partially presented)A “Conditional Requirements” table is provided for jurisdictions to describe the condition(s) that cause the data element to be Mandatory or Expected:MC (Mandatory Conditional) orEC (Expected Conditional)
179Release 3 FROI Element Requirement Table (Partially presented)MTCC and MTCC Date are Fatal on CO (Correction) transactions
180Release 3 FROI Element Requirement Table (Partially presented)These data elements notify the jurisdiction which transaction is being corrected (which requirements apply)
181Release 3 FROI Element Requirement Table (Partially presented)Standard requirement code for CO (Correction) MTC:$ Same requirements as the MTC being corrected
182Release 3 FROI Element Requirement Table (Partially presented)When MTC 00 is being corrected, those requirements apply
183Release 3 FROI Element Requirement Table (Partially presented)For example, assume the 00 (Original) was missing the Number of Days Worked Per Week.
184Release 3 FROI Element Requirement Table (Partially presented)The jurisdiction returns a TE (Transaction accepted with Errors) acknowledgment.
185Release 3 FROI Element Requirement Table (Partially presented)When submitting the Correction to the error(s) on the 00 (Original)
186Release 3 FROI Element Requirement Table (Partially presented)MMEECMCthe $ becomes the requirement code from the 00 (Original).
189Edit MatrixThe Edit Matrix presents standard application of edits to Claims data elements.
190Edit MatrixJurisdiction indicates edits that are applied to each data element on the Edit Matrixto assist the sender in understanding the edits that will be appliedand the data quality expected by the jurisdiction.
195Release 3 Edit Matrix The Matrix consists of 5 components: DN-Error Message contains “standard” editing developed for Release 3 data elements.Value Table expresses the jurisdiction’s acceptable code values.Match Data describes the data elements that will be used to determine if the report will create a new claim or find an existing claim or transaction in the jurisdiction’s database.Population Restrictions contains the jurisdiction’s restrictions applied to the data element(s).Sequencing illustrates logical transaction sequencing for application of edit 063.
206Value Table conveys code values that are expected to be reported to the jurisdiction, invalid values and values that may be suppressed(Partial Table presented)
207Y = data element is collected by the jurisdiction Value TableY = data element is collected by the jurisdictionN = data element is not collectedYN(Partial Table presented)
208Code values that are not valid are “grayed-out” by the jurisdiction Value TableCode values that are not valid are “grayed-out” by the jurisdictionCode values that are not grayed-out are expected to be reportedHKYAEGPN(Partial Table presented)
209Value TableCode values that are grayed-out in Section 2 are not collected by the jurisdiction. These code values may be suppressed by senders.HKYNHK(Partial Table presented)
2113. Match Data Match Data elements are used by jurisdictions to: Identify new ClaimsFind existing Claims, transactions or previously reported values
212Match Data table describes the data elements that will be used as Match Data by the jurisdiction.
213Match Data P = Primary Match data element S = Secondary Match data elementPPSPS
2143. Match DataJurisdictionOne use of Match Data is to determine whether the transaction should create a new ClaimClaimsNew Claim: MatchEmployee ID PrimaryDate of Injury PrimaryFor instance, a Jurisdiction may define Match Data elements for new claims as:
2153. Match DataJurisdictionThe jurisdiction uses these Match Data elements to evaluate whether the claim in the incoming FROI transaction exists on their data base.ClaimsClaimNew Claim: MatchEmployee ID PrimaryDate of Injury Primary
2163. Match DataJurisdictionIf the Match Data keys do not exist, the jurisdiction will establish a new claim from the incoming transaction.ClaimsNew ClaimNew Claim: MatchEmployee ID PrimaryDate of Injury Primary
2173. Match DataIf the Match Data keys do exist on the jurisdiction’s data base, this FROI transaction may be rejected as a duplicate.JurisdictionClaimsClaimNew Claim: MatchEmployee ID PrimaryDate of Injury PrimaryX
2183. Match DataOnce a claim has been established on the jurisdiction’s data base, Match Data keys may be compared to previously reported data.JurisdictionClaimsExisting Claim: MatchJurisdiction Claim Number PrimaryEmployee ID SecondaryDate of Injury SecondaryExisting claim
2193. Match Data When a match is found with the Primary key(s), the Secondary keys are used to validate data integrity.JurisdictionClaimsExisting Claim: MatchJurisdiction Claim Number PrimaryEmployee ID SecondaryDate of Injury SecondaryExisting claim
221Population Restrictions Elaborates on data elements’ specific data population limitations or accepted values for standard error messagesReturned on acknowledgment for reconciliation by senders0002Maintenance TypeCode042FROI UI not acceptedNot statutorily validMTC’s not accepted: FROI UI0063Wage PeriodCode042Must be 01 (Weekly)Not statutorily validCode 2, 4, 6 and 7 are invalid
2235. SequencingThe 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.
2245. SequencingApplication of Jurisdiction’s transaction sequence edits are defined on the Sequencing table.Partial table presented
2255. SequencingN = the sequencing edit will not be applied to the SROI reportNPartial table presented
2265. SequencingY = edit will be applied. Error text indicates why the report was rejected:1b = 00 Original1c = 04 Denial (FROI)YEvent 1b or 1c not accepted by jurisdictionYEvent 1b or 1c not accepted by jurisdiction
228Implementing EDI with Trading Partners Obtain the IAIABC Implementation GuideObtain the Jurisdiction Implementation/Requirements GuidePrepare your System to send and receive the applicable dataSubmit the required Profiles and Agreements to the JurisdictionBegin the EDI Process