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

Current through 2024-29, July 17, 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.
DN
Name
Considerations
0006
Insurer Fein
Change allowed only if value previously sent was
						  erroneous. If a different Insurer assumes the employer's financial
						  responsibility of the claim an MTC AQ transaction applies.
0014
Claim Administrator Postal Code
a) office moved b) if value previously sent was
						  erroneous
0015
Claim Administrator Claim Number (Key Match)
If 02 FROI - Must change in both FROI and companion
						  records If 02 SROI - Must change in both SROI and companion records
0187
Claim Administrator FEIN
Change allowed only if value previously sent was
						  erroneous. If a different entity assumes the responsibility of the adjusting
						  the claim an MTC AQ transaction applies.
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.
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 (No Change)
TR (Transaction Rejected)
NA (Not Applicable)
TA (No error messages may be applied)
R (Restricted)
TR (Transaction Rejected)
RC (Restricted/Conditional)
TR (Transaction Rejected)
F (Fatal)
TR (Transaction Rejected)
FC (Fatal/Conditional)
TR (Transaction Rejected)
FY
TR (Transaction Rejected)
X (Exclude)
TA (No error messages may be applied)
Y
TE (Transaction Accepted with Errors)
OR
TR
						  (Transaction Rejected) **
YC
TE (Transaction Accepted with Errors)
OR
TR
						  (Transaction Rejected) **
* 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.