Advanced Technical Concepts

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

Assistant Director WC Network Products, ISO
Your Trainers: 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 IAIABC Training Team EDI

IT Business Analysis Consultant – Ingenix/ROES
Your Trainers: 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 IAIABC Training Team EDI

EDI Coordinator – Peak Performance
Your Trainers: Sharon Marion EDI Coordinator – Peak Performance IAIABC Participation: EDI Systems Committee Chair EDI XML EDI Medical EDI Claims EDI Trainer IAIABC Training Team EDI

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

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

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.

Fixed Length Records A fixed length record is consistently the same number of data positions each time the record is assembled. Based on the individual record layout, the data within the record is always in the same position.

Variable Length Record
A variable length record may vary each time the record is assembled. The variable length record has a minimum record length and based on the occurrence of the data being reported, a maximum record length.

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

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

Batches/ Transmissions
EDI 301 Batches/ Transmissions

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

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

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

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

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

Release 3 records DN Claim Administrator Claim Number is populated in all Release 3 FROI and SROI records. 148 R21 A49 This “links” the companion record to its related 148 or A49 record. R22

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

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

Header B A T FROI C Transactions H Trailer
Batch example of R1 FROI transactions 8 records = 8 transactions Header 148 Record 1 148 Record 2 B A T C H 148 Record 3 FROI Transactions 148 Record 4 148 Record 5 148 Record 6 148 Record 7 148 Record 8 Trailer

Header B A T SROI C Transactions H Trailer
Batch example of R1 SROI transactions 8 records = 8 transactions Header A49 Record 1 A49 Record 2 B A T C H SROI Transactions A49 Record 3 A49 Record 4 A49 Record 5 A49 Record 6 A49 Record 7 A49 Record 8 Trailer

Header B A FROI T Transactions C H Trailer
Batch example of R3 FROI transactions 8 records = 4 transactions Header 148 Record 1 R21 Record 2 B A T C H FROI Transactions 148 Record 3 R21 Record 4 148 Record 5 R21 Record 6 148 Record 7 R21 Record 8 Trailer

Header B A SROI T Transactions C H Trailer
Batch example of R3 SROI transactions 8 records = 4 transactions Header A49 Record 1 R22 Record 2 B A T C H SROI Transactions A49 Record 3 R22 Record 4 A49 Record 5 R22 Record 6 A49 Record 7 R22 Record 8 Trailer

Components of a Transmission
FROI B A T C H FROI Transactions Header Trailer BATCH: Consists of 1 Header record, one or more Transactions and 1 Trailer record. SROI Transactions Header Trailer B A T C H SROI

Components of a Transmission
FROI B A T C H FROI Transactions Header Trailer TRANSMISSION: Consists of 1 or more batches sent or received during a communication session. TRANSMISSION SROI Transactions Header Trailer B A T C H SROI SROI SROI SROI SROI SROI

Questions?

EDI 301 Data Element Formats

Data Element Data Element: A single piece of information.
The Data Dictionary in the Implementation Guide provides the definitions, format, valid values and population rules for each data element.

Data Dictionary Example
Specific Data Element Information

Data Element 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

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

Data Element Formats Time: Type = TIME: Data elements that are assigned the format of TIME should be populated with only a valid 24-hour military time. 11:54 pm

Data Element 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.

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

Data Element 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 = 000 123 Spaces indicate absence of data.

Data Element Formats Monetary Amounts: Type = $9.2: Data elements that are assigned the format of $9.2 should be populated with only a valid monetary amount.

Data Element 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 $ 50 00 ^ Spaces indicate absence of data.

Data Element Formats Percentage: Type = 3.2: Data elements that are assigned the format of 3.2 should be populated with only a valid percentage. 125%

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

Data Element Formats Alphanumeric: Type = A/N: Data elements that are defined the format of A/N consist of a sequence of any characters from common character code schemes (EBCDIC, ASCII, and CCITT International Alphabet 5).

Data Element 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)

Data Element Formats Alphanumeric: 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.

Release 1 Transactions/Records
EDI 301 Release 1 Transactions/Records

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

uniquely identifies the sender, the receiver, the date and time batch was prepared

whether the batch contains test or production data and the Transaction type

148 - Release 1 FROI Record 913 Byte Fixed Length Record

TR1 – Release 1 Trailer Record 12 Byte Fixed Length Record

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

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

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 Fixed length = 208 Perm Impair = 8 bytes Pmt/Adj = 46 bytes x 2 PTD/RE/REC = 14 bytes x 3 The A49 record ends at position 350

A49 – Release 1 SROI Record Batch/Transmission Examples
Transmission Sample Containing 1 Batch (Shown partial for display): HD PA491A A49IP PR N TR Header Record=HD1 SROI Transaction=A49 Trailer Record=TR1 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=HD1 SROI Transaction=A49 Trailer Record=TR1

A49 – Release 1 SROI Data Batch Breakdown Example HEADER RECORD:
HD PA491A 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: TR

Release 3 Transactions/Records
EDI 301 Release 3 Transactions/Records

IAIABC Claims Release 3 Transaction Design
FROI SROI Basic 148 Basic A49 R1 Fixed length Fixed length Permanent Impairments Payment Adjustments Different Adjustments Different Paid to Dates/Reduced Earnings/Recoveries Different Death Dependent Payee Anything New or Different from R1 or R2 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 R3

Release 1 data elements that differ in:
Functionality definition Format become Filler in the R3 record layout.

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

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

87 byte Fixed Length record (Same as Release 1)

uniquely identifies the sender, the receiver, the date and time batch was prepared

whether the batch contains test or production data and the Transaction type

Release 3 FROI record 148 – 913 Byte Fixed Length Record

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

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

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

Release 3 Variable Segments
Counters determine the overall record length The transaction includes one Benefits segment Fixed length = 650 Benefits segment = 103 bytes. The R22 record ends at position 753 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 Fixed length = 650 Benefits segment = 103 bytes; Suspension Narrative = 50 bytes. The R22 record ends at position 803 Partial display of SROI R22 record

TR2 – Release 3 Trailer Record
designates the end of a batch of transactions provides a count of records and transactions within a batch is used to ensure that the entire batch is complete and valid

Release 3 148/R21 – First Report of Injury Batch/Transmission Example
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: 14830 FROI Companion Record New field added to Release 3 Trailer record: Transaction Count (DN0191)

Release 3 A49/R22 – Subsequent Report of Injury Batch/Transmission Example
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)

Questions?

Break Time!

Acknowledgment Overview
Electronic Report Acknowledgment Electronic Report Acknowledgment Overview

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

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

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

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.

What are the Application Acknowledgment Code Values?

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

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

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

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

An MTC CO (Correction) is not used to respond to a TR acknowledgment If an error of duplicate transaction, invalid event sequence, etc. then resubmission may not be required

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

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

An EDI Service Provider:
Rejected by Service Provider (TN) An EDI Service Provider: Performs a service for their client to evaluate data prior to submission to a Jurisdiction Determines that the data fails the Jurisdiction mandatory requirements Reports errors to their client resulting in resubmission of the report to the jurisdiction

Acknowledgments: Release 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

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

Release 3 Transaction Acknowledgment
Claim Administrator sends: Jurisdiction returns: Header (HD1) 148 Record 1 AKC TA Record 1 Header Trailer FROI Transactions R21 Record 2 148 Record 3 AKC TA Record 3 R21 Record 4 148 Record 5 AKC TE Record 5 R21 Record 6 148 Record 7 AKC TR Record 7 R21 Record 8 Trailer (TR2)

Release 1 vs. Release 3 Requirement Code Result of Failed Element Requirement
Requirement Code Result of Failed Element Requirement Edit M (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) OR TE (Transaction Accepted with Errors) N/A (Not Applicable) * No requirement edits may be applied R (Restricted) * TR (Transaction Rejected) F (Fatal) * TR (Transaction Rejected) X (Exclude) * No requirement edits may be applied ** Release 1 only * Release 3 only

Acknowledgment Transmission/Batch Examples
EDI 301 Acknowledgment Transmission/Batch Examples

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

AKC Release 3 Transmission/Batch Example
Header AKC AKC Trailer

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

Release 3 - Matching original batch to AKC batch using the Header Record FROI Example
HEADER RECORD (HD1) for FROI HD P14830 1 | | | | | | |8| | 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

The count should be the same.
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 The count should be the same. Transaction Count (DN0191) is the total number of transactions sent as part of the batch. The FROI or SROI Transaction Count should be matched to the AKC Transaction Count.

Interpreting Acknowledgments
EDI 301 Interpreting Acknowledgments

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

Date and time the transaction was processed by receiving Jurisdiction Jurisdiction returns value from original transaction, when available

Jurisdiction calculates and returns the position of the transaction within the batch. Acknowledged transaction is identified. MTC and MTC Date from original transaction

Result of jurisdiction’s applied edits; Number of encountered errors.

Number of Errors determine the overall record length AKC Fixed length = 248 The AKC includes two Error segments

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

The first error occurred on DN0134 Calculated Weekly Compensation Amount.

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

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

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

Release 3 Error Correction
EDI 301 Release 3 Error Correction

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.

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

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

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

Questions?

Establishing the EDI Partnership

STANDARD USAGE FOR ALL PRODUCTS

Partnering Agreement Jurisdiction EDI Reporter  

Trading Partner Profile
    EDI Reporter

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

Sender’s Response mm/dd/yyyy Jurisdiction EDI Reporter    
Claims 3.0 150  

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

Maintaining Senders’ Authorization
EDI 301 Maintaining Senders’ Authorization

Trading Partner Validation Table
In order to validate Senders’ authorization to submit EDI reporting, the jurisdiction maintains a 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”.

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

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

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

Validating Sender Authorization for the Batch
EDI 301 Validating Sender Authorization for the Batch

If Sender exists with Approved status, the batch is processed.
A (Approved) Approved R (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.

A (Approved) Approved R (Revoked) If Sender ID does not exist in the Validation Table or authorization is revoked, jurisdiction will reject the entire batch.

Validating Sender Authorization for the Claim Administrator
EDI 301 Validating Sender Authorization for the Claim Administrator

A (Approved) Approved R (Revoked) During Transaction Level editing, the Claim Administrator FEIN from the FROI or SROI record are checked against the jurisdiction’s Validation Table.

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

A (Approved) Approved R (Revoked) If Claim Administrator ID does not exist in the Validation Table or authorization is revoked, jurisdiction will reject the transaction.

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

EDI 301 Event Table

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.

Event Table Describes conditions that “trigger” electronic reports
Provide timeframes for sending the information Describes Report due dates based on jurisdictions’ legislative mandates and/or voluntary reporting requirements

Claims Release 1 Event Table

Interpreting Release 1 Event Table
EDI 301 Interpreting Release 1 Event Table

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)

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

Interpreting Release 3 Event Table
EDI 301 Interpreting Release 3 Event Table

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

Release 3 Event Table with the conditions described in the Trigger Criteria and Value. Report due date is based on Report Due Value, Type and From) Partial Table presented

Release 3 Event Table When the Event Rule Thru date is blank, reporting requirements apply until further notice. Partial Table presented

Release 3 Event Table When a Paper Form is indicated, this form must be sent to the Receiver indicated in addition to the electronic report. Partial Table presented

Questions?

Element Requirement Table
EDI 301 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.

Requirement Codes were developed to express the severity of the jurisdiction's requirement for each data element and report type (FROI, SROI).

Element Requirement Table Requirement Code Values:
RELEASE 1 AND RELEASE 3 M (Mandatory) RELEASE 1 ONLY RELEASE 3 ONLY C (Conditional) E (Expected) O (Optional) EC (Expected/Conditional) IA (If Applicable/Available) N/A (Not Applicable) MC (Mandatory/Conditional) F (Fatal) X (Exclude) R (Restricted)

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

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

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

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

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

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

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

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

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

NA = Not Applicable. The data element is not applicable to the jurisdiction’s requirements for the MTC and may or may not be sent; edits must not be applied. Release 3 only.

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

Requirement Codes limited to MTC 02 (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.

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.

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.

Requirement Codes limited to MTC 02 (Change) transaction. Release 3 only. YC = Yes Change/Conditional. Send an 02 Change transaction if the data element changes under these predefined conditions: Benefit Type Claim Weeks, Benefit Type Claim Days and Benefit Type Amount Paid were reported in error on a Benefit Type Code that was ended.

Release 1 Element Requirement Table
EDI 301 Release 1 Element Requirement Table

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

Release 3 Element Requirement Table
EDI 301 Release 3 Element Requirement Table

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

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

(Partially presented) A “Conditional Requirements” table is provided for jurisdictions to describe the condition(s) that cause the data element to be Mandatory or Expected: MC (Mandatory Conditional) or EC (Expected Conditional)

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

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

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

(Partially presented) When MTC 00 is being corrected, those requirements apply

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

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

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

(Partially presented) M M E EC MC the $ becomes the requirement code from the 00 (Original).

Questions?

EDI 301 Edit Matrix

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

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.

EDI 301 Release 1 Edit Matrix

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

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

EDI 301 Release 3 Edit Matrix

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

1. DN-Error Message table

Table is populated with standard default edits

F = Fatal Technical edits must be applied - data is essential for the transaction to be processed

L = logical standard edit for the data element

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

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

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

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

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

2. Value table

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)

Y = data element is collected by the jurisdiction
Value Table Y = data element is collected by the jurisdiction N = data element is not collected Y N (Partial Table presented)

Code values that are not valid are “grayed-out” by the jurisdiction
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 H K Y A E G P N (Partial Table presented)

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. H K Y N H K (Partial Table presented)

3. Match Data table

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

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

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

3. Match Data Jurisdiction One use of Match Data is to determine whether the transaction should create a new Claim Claims 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 Jurisdiction The jurisdiction uses these  Match Data elements to evaluate whether the claim in the incoming FROI transaction exists on their data base. Claims Claim New Claim: Match Employee ID Primary Date of Injury Primary

3. Match Data Jurisdiction If the  Match Data keys do not exist, the jurisdiction will establish a new claim from the incoming transaction. Claims New Claim New Claim: Match Employee ID Primary Date of Injury Primary

3. Match Data If the  Match Data keys do exist on the jurisdiction’s data base, this FROI transaction may be rejected as a duplicate. Jurisdiction Claims Claim New Claim: Match Employee ID Primary Date of Injury Primary X

3. Match Data Once a claim has been established on the jurisdiction’s data base,  Match Data keys may be compared to previously reported data. Jurisdiction Claims Existing Claim: Match Jurisdiction Claim Number Primary Employee ID Secondary Date of Injury Secondary Existing claim

3. Match Data When a match is found with the Primary key(s),
the Secondary keys are used to validate data integrity. Jurisdiction Claims Existing Claim: Match Jurisdiction Claim Number Primary Employee ID Secondary Date of Injury Secondary Existing claim

4. Population Restrictions

Population Restrictions Elaborates on data elements’ specific data population limitations or accepted values for standard error messages Returned on acknowledgment for reconciliation by senders 0002 Maintenance Type Code 042 FROI UI not accepted Not statutorily valid MTC’s not accepted: FROI UI 0063 Wage Period Code 042 Must be 01 (Weekly) Not statutorily valid Code 2, 4, 6 and 7 are invalid

5. Sequencing

5. Sequencing The Sequencing table in the Edit Matrix is a model of the standard Sequencing outline from Section 4 of the Release 3 implementation guide. It illustrates the sequence in which business events (MTCs) typically occur during the life of a claim.

5. Sequencing Application of Jurisdiction’s transaction sequence edits are defined on the Sequencing table. Partial table presented

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

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

Questions?

Implementing EDI with Trading Partners
Obtain the IAIABC Implementation Guide Obtain the Jurisdiction Implementation/Requirements Guide Prepare your System to send and receive the applicable data Submit the required Profiles and Agreements to the Jurisdiction Begin the EDI Process

Thank you for attending EDI 301!

Advanced Technical Concepts

Similar presentations

Presentation on theme: "Advanced Technical Concepts"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Advanced Technical Concepts

Similar presentations

Presentation on theme: "Advanced Technical Concepts"— Presentation transcript:

Similar presentations

About project

Feedback