Code of Maine Rules
90 - INDEPENDENT AGENCIES
351 - WORKERS' COMPENSATION BOARD
Chapter 3 - FORM FILING
Appendix I - Introduction

Current through 2024-38, September 18, 2024

This table was designed to provide a tool to communicate a Receiver's business data element requirements for each of its trading partners. This allows for data element requirements to be defined for each record layout (FROI or SROI) and down to the level of each Maintenance Type Code. Further, it provides for element requirements to differ based on Report Type criteria established on the Event Table. When completing the requirement table, consideration should be given to the point in time when the data was required by statute, rule or current version of EDI. If a data element has not always been required to be reported, but is required now, it should be listed as Mandatory Conditional (MC) on the table, and the condition should identify that from X date this data element is mandatory, but prior to that date, the data element is Not Applicable (NA).

Data elements intended to be used to match a transaction to the jurisdiction's database should be expressed as "Mandatory", with consideration given to "changes" to Match Data values. Refer to Match Data Rules.

When a jurisdiction makes a change to its Element Requirements that requires new elements or functionality, the jurisdiction should make every attempt to give all Claim Administrators at least 180 days notice to allow for program changes and staff notification/training. See Systems Rules in Section 2 and Error Correction Technical Rules in Section 4 for transaction processing rules in regards to transaction acceptance, rejection, or acceptance with errors.

When completing requirements for legacy claims or acquired claims (FROI AQ, AU and SROI AP), special consideration should be given to availability of the data. See Legacy Claims Processing and Acquired Claims Processing in Section 4 prior to completion of the element requirements for these MTCs.

Migration from Release 1: When completing requirements for Claims that were established in Release 1 (jurisdictions migrating from Release 1 to Release 3), special consideration should be given to availability of new Release 3 data elements.

Usage: This table should be completed after the Event Table, as it relates to events described on that table.

The IAIABC Release 3 Element Requirement table contains worksheets to be completed for each report type and its related conditions that apply to the jurisdiction's reporting requirements:

FROI (First Report of Injury) FROI Conditions (First Report of Injury applicable condition restrictions) SROI (Subsequent Report) SROI Conditions (Subsequent Report applicable condition restrictions) Event Benefits Segment (SROI Benefits variable segment) Event Benefits Conditions (SROI Benefits variable segment condition restrictions)

Element Requirement Table Layout:

Rec (Record) - This column indicates in which record the data element must be populated for Release 3 (See Record Layouts for details). DN# (Data Element Number) - This column indicates the assigned Data Element Number. The Data Dictionary in Section 6 provides descriptions of the element. MTCs (Maintenance Type Codes) - These columns indicate the available MTCs that the data elements will apply to. (See the state-specific event table for the MTCs that they will accept and the Data Dictionary for a description of each MTC). To simplify completion, jurisdictions should use their completed Event Table to "hide" MTCs that will not be accepted before completing the FROI or SROI requirement tables (highlight column, right click - select HIDE. Deletion may complicate adding MTCs later). UR MTC is hidden (FROI column K and SROI Column AO). When consistent UR requirements can be defined, jurisdictions may unhide the column and indicate their UR reporting requirements. Jurisdictions that may have varying UR requirements should reserve the right to define the requirements when the request for UR report is made. A separate UR FROI and UR SROI Requirement Table is provided at http://www.iaiabc.org/EDI/implementation.htm [File Link Not Available] to define the requirements when the jurisdiction deems the UR report necessary. SROI - the Benefits segment of the SROI Element Requirement table is blocked out and contains references to R3 standards to assist in completion of the Event Benefits Segment requirements as well as to acquaint senders with "standard" population of the segment. These references should not be removed.

The minimum number of Benefits segments that can be expected on an MTC event is indicated in the segment title row and can be interpreted as follows:

E0 = A Benefits segment may or may not be expected for the MTC. Data elements required when the Benefits segment is populated should be indicated in the Benefit Element Requirement table.

E1 = At least 1 Benefits segment should be expected for the MTC. Data elements required in the benefit segment in the MTC should be indicated in the Benefit Element Requirement table.

E2 = At least 2 Benefits segments should be expected for the MTC. Data elements required in the benefit segment in the MTC should be indicated in the Benefit Element Requirement table.

Event Benefits Segment (SROI Benefits variable segment) - Requirements must be defined based on the Benefit Type Code (and MTC, when applicable). Jurisdictions should be aware of the Event Benefits Segment Rules described in the Variable Segment Population Rules and Lump Sum Payment/Settlement Rules in Section 4 when defining these requirements.

Some cells are pre-populated with Requirement Code Values. The Requirement rules defined below apply. Data elements indicated with a value of "F" (Fatal Technical) or X (Exclude) cannot be changed by the jurisdiction because they are necessary for technical processing or do not apply to the MTC, respectively. Some conditional values have been indicated by a character and apply only if the defined condition exists (see below for exceptions). These conditions are defined in the Conditional section for the report type of the Element Requirement table.

A Requirement Code Value must be entered at each cell marked by the intersection of a Maintenance Type Code column and a Data Element row. Those cells that do not contain a value are open to jurisdictions to assign a valid requirement code. Special characters must be replaced with valid requirement codes.

Conditional Requirements: Each time an MC (Mandatory/Conditional), EC (Expected/Conditional) or YC (Yes Change/Conditional) requirement value is assigned by the jurisdiction on the SROI, FROI or Event Benefits table, the "conditional" data element number, data element name and the applicable condition(s) should be described on the related Conditional requirement tab in addition to the pre-populated values. Special conditions such as jurisdiction rule effective date(s) that are dependent on date of injury, etc. should be included in the described condition, when applicable. Each Conditional requirement tab is pre-populated with suggestions and/or limitations defined in the Release 3 standard. Once conditions have been defined for all applicable data elements, modify the table presentation as follows:

1. Delete rows containing Data Elements that will not be collected or where "conditions" do not apply in your jurisdiction

2. Delete columns A (Req Code) from the table

3. Sort the table by Data Element Number

4. Describe the Business Condition(s) and Technical Condition(s), when applicable for the requirement. Example: DN0065 Initial Date Last Day Worked:

Business Condition: Mandatory when claim is lost time Technical Condition: Mandatory if DN0073 (Claim Status Code) is O or R and DN0074 (Claim Type Code) if Values are I or L

Standard Requirement Code Values:

M = Mandatory. The data element must be present and must be a valid format or the transaction will be rejected. Note: When an M is marked on an MTC 02, then you are not allowed to change the value, but the element is required.

MC = Mandatory/Conditional. The data element becomes mandatory under conditions established by the receiver. If the defined condition exists, the data element becomes mandatory and mandatory rules apply (the data element must be present and must be a valid format or the transaction will be rejected). For example, if the Benefit Type Code indicates death benefits, then the Date of Death becomes mandatory. The receiver must provide senders with the specific circumstances, which cause an element to become mandatory.

E = Expected. The data element is expected on the MTC, yet the transaction will be accepted with errors should it fail any edit. 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. The receiver must provide senders with a document describing the specific circumstances, which cause an element to become expected. The transaction would be accepted with errors should it fail any edit.

IA = If Applicable/Available. Data should be sent if applicable and/or available. The data may or may not be populated. If the data is applicable to the claim, data must be sent. If present, may be edited for valid value and/or format. 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.

Requirement Code Values limited to "Change" transactions (MTC 02) in addition to M, IA and NA, above: 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. All of the previously reported data should be submitted as well.

Changes to Benefits segment data: Some cells are pre-populated to comply with the R3 standard. Cells pre-populated with "N" should not be removed or changed by the jurisdiction; changes to these data elements should be reported on a CA (Change Amount) transaction. Cells pre-populated with YC can only be changed to "N" by the jurisdiction if changes are not allowed. Unpopulated data element can be changed to a Y, N, IA or NA. Jurisdictions should be aware of the limitations to changing data in these segments. Refer to 02 Change Processing Rules in Section 4.

Changes to Match Data elements: Per the Match Data Rules, only one Match Data element can be changed per transaction. In order to communicate requirements for these data, the jurisdiction should populate the requirement code lower case instead of upper case. This does not change the requirement of the data, but only clarifies that Match Data Rules apply to changes to the data element. Refer to Match Data Rules in Section 4. Lower case requirement codes should only be used for Match Data elements indicated as Primary or Secondary in the "Existing Claims" column of the jurisdiction's Match Data table located in the Edit Matrix.

M = Mandatory. Note: When an M is marked on an MTC 02, then you are not allowed to change the value, but the element is required.

IA = If Applicable/Available. Note: Jurisdiction will accept changes to this data element via an 02 Change transaction, but it is not necessary to trigger the 02 change transaction. Jurisdiction may return an error on validity edits.

FY = Fatal Yes Change. Data elements indicated with this requirement code are essential for a transaction to be accepted into a jurisdiction's database or acknowledgment back to the claim administrator. Depending on their ability to recognize and process changes to these data elements, jurisdictions may choose not to allow "changes" by replacing the "FY" with an "F". An 02 Change transaction should be triggered when the value of this "Fatal" data element has changed.

FC = Fatal/Conditional. This data element must be populated with previously reported values if the segment has ever been reported on the claim. Data within the segment can be changed, but not the data element marked with FC. If data element(s) within the segment have changed, it must be sent on an 02 Change transaction if another MTC doesn't apply.

N = No Change. This data element cannot be changed on an 02 transaction, eg. Jurisdiction claim number or the jurisdiction requires another method of reporting, eg. MTC CA, CB or paper. The data element must be reported, if applicable

Y = Yes Change. Changes to the value of the data element are allowed by the jurisdiction. This is the equivalent of an MC or EC; however, it does not require the jurisdiction to define the condition "an 02 must be sent if the data element has changed". Jurisdictions should consider their ability to apply the same edits to the data element as when it was previously reported. If the data element has been marked as M for all FROI or all SROI transactions then it is mandatory on the 02-Change.

YC = Yes Change/Conditional. Some data elements have been pre-populated with YC for 02 Change transactions. This data is expected if the data element changes under these predefined conditions:

Payment segment and its related DN0293 Lump Sum Payment/Settlement Code (if applicable): A previous PY should have been submitted if erroneous data previously submitted in the Payments segment. Benefits segment: Change allowed 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. If any data element in the Benefits segment is being changed, it is considered an Event Benefits segment and the MTC 02 must be present in that segment. Benefit Payment Issue Date: If an erroneous date was reported on a Benefit Type Code

Benefit Segment Data Element Requirement Table (for MTCs other than 02 Change): The Event Benefits segment Element Requirement Table is intended to apply to the Benefits segment reporting the "Event" (refer to Variable Segment Rules for Benefits segment in Section 4). Standard EDI processing assumes that a Benefits segment is expected when benefits have been paid on the claim for each Benefit Type Code value indicated on the jurisdiction Edit Matrix. The following requirement codes may be used to describe jurisdiction's limitations to Benefit Type Codes in the Benefits segment. Standard Requirement Codes described above should be used for other Benefits segment data elements

R = Restricted - The data element value will not be accepted by the jurisdiction. For example, the jurisdiction does not accept Benefit Type Code 080. When this code is inserted in the Benefit Type Code cell, "NA" should be inserted in cells for the remaining data elements in the row (Benefits segment).

RC = Restricted/Conditional - The data element value cannot 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.

Systems/Processing Requirement Codes: These are standards designations only; the codes cannot be used by a jurisdiction or be changed:

F = Fatal Technical. Data elements that are essential for a transmission/transaction to be accepted into a jurisdiction's workers compensation administration database or acknowledgment back to the claim administrator.

X = Exclude - The data element is not applicable to the standard requirements for the MTC and may or may not be sent; edits must not be applied.

Exceptions: These characters represent Requirement Codes that must be changed by the jurisdiction. You must assign either a valid requirement code or change to NA if not used for the MTC.

# = Only If Applicable/Available (IA) or Not Applicable (NA) are valid Requirement codes for these elements.

@ = Only Mandatory/Conditional (MC), Expected/Conditional (EC), If Applicable/Available (IA) or Not Applicable (NA) are valid Requirement codes for these elements. See the Conditional Requirements for the report type (FROI, SROI) for those rules that apply.

> = Only Mandatory/Conditional (MC) or Not Applicable (NA) are valid Requirement codes for these elements. See the Conditional Requirements for the report type (FROI, SROI) for those rules that apply

% = Only Mandatory/Conditional (MC), Expected/Conditional (EC), If Applicable/Available (IA) or Not Applicable (NA) are valid Requirement codes for these elements. See Data Population Rules in the Data Dictionary (Section 6).

& = See Conditional requirements tab for specifications/restrictions on use.

$ = Element Requirements are limited to the requirements applicable to the MTC being corrected. These characters cannot be replaced with any other value. The data submitter will apply the same values of the MTC that they are correcting. See Error Correction Technical Rules in Section 4 for data element requirement limitations on CO transactions.

* = Only Mandatory/Conditional (MC), Expected/Conditional (EC), or Not Applicable (NA) are valid Requirement codes for these SROI Event Benefits segment elements. See Variable Segment Population Rules - Benefits Segment (Section 4).

^ = Only Mandatory/Conditional (MC), Restricted (R) or Restricted/Conditional (RC) are valid requirement codes for the Benefit Type Code (DN0085) in the Benefits Element Requirement tab.

? = Only Mandatory/Conditional (MC), Expected/Conditional (EC), or Not Applicable (NA) are valid Requirement codes for these SROI Payment segment elements. If Payee, Payment Issue Date and/or the amount of the original check must be preserved in the event of a TE or TR on an AP, IP or RB transaction, the Payments segment must be required. Refer to the Variable Segment Population Rules - Payments segment in Section 4.

Legend for Requirement Code/Application Acknowledgement Code:

There is a relationship between the Requirement Code assigned to a data element and DN0111-Application Acknowledgment Code that is returned on the Acknowledgment Record (AKC). The Edit Matrix is designed to convey which data elements have edits applied to them and to provide standard error messages to use in association with these edits. Error messages are communicated in the Acknowledgement Record in the form of error messages using DN0115-Element Number, DN0116-Element Error Number, DN0117-Variable Segment Number and DN0291-Element Error Text. The severity of applied edits (Application Acknowledgment Code: TR, TE, TA), if not passed, is determined by referencing the Jurisdiction's completed "Element Requirement Table". The Application Acknowledgment Code field on the AKC is based on the Requirement Code assigned to the data element as outlined in the table below, where the application acknowledgment code applies to the most severe edit failure for the transaction.

* The result depends on whether the jurisdiction chooses to apply edits to the "IA" data

**The result depends upon the requirements and edits that were originally applied to the element.