V2.5 Requirements Tables – What’s New

Recently, Alaska released v2.5 of our EDI Element Requirement Tables. With these tables, our goal is to

improve EDI reporting of Workers’ Compensation Claims, to provide appropriate edits to help reduce

errors in reporting, and to provide better feedback for issue resolution. To accomplish this, we:

• Redesigned our tables to improve the readability, functionality, and printability;

• Reorganized the tables into three manageable spreadsheets;

• Clarified and made more specific many confusing and vague edits; and

• Implemented new error messages that provide better feedback about the issues encountered on

the transaction.

Along with these improvements, we enhanced a few business processes related to reporting. Key business

processes changed include the claim status, Legacy reporting, temporary partial benefits reporting,

misreporting of benefits, and Lump Sum Payments.

Claim Status Code (DN0073)

In Alaska, there are nearly 296,000 open claims in our system. Every year, we get about 20,000 Annual

reports for active claims. That means there are approximately 276,000 claims that are in an open status

in our system with either no reportable activity or have failed to report the year’s activity. To facilitate a

reduction in the number of outstanding open claims, we adopted a change to the way we accept the claim

status code. All notification only claims should report as closed. All other claim types will be reported as

open on the FROI and continue as open until the SROI FN reports it as closed. In conjunction with this

change, AN reporting would be expected on all claims in open status or that were in open status during

the report year.

Legacy Claim Reporting

All of Alaska’s Claims, back through AWCB# 198100000, exist in the Injury Claims Expense Reporting

System (ICERS) database. All claims from 198100000 through 201319999 are Legacy claims. Legacy claims

only accept the SROI 04, AN or FN through EDI reporting. Starting March 1, 2018, the Trading Partner will

have the option to submit the SROI UR to update the financial picture of the claim at the time of

transmission. From that point forward, the trading partner may suspend or reinstate current benefit types

as a starting point for EDI sequential reporting. Like the FROI UR, whose only purpose is to update the

claim with current required match data elements required for EDI reporting, the SROI UR will update the

claims financial reporting and allow for additional SROI compensation reporting.

The SROI UR report will work under the same guidelines as the AN report. The report should include all

financial activity on the claim up to the MTC date of the transaction. Benefits should be reported using

sweep rules (benefit start and through dates, claim weeks and claim days, and cumulative amounts paid).

We understand that the dates, claim weeks, and claim days may not be readily available through the life

of the claim. Therefore, it is acceptable to report older benefit data as OBT 430 and 440 as applicable

through 12-31 of the previous Calendar year of the MTC Date of transaction and normal reporting moving

forward from this point. This will ensure a good starting point for collecting accurate data moving forward.

If a legacy claim is acquired, the SROI UR would not be required. Normal reporting would then continue

based upon acquiring claims processing rules. One noteworthy point, the IP or EP transaction would never

be applicable on a Legacy claim.

Temporary Partial Benefits Reporting (BTC070)

Many trading partners do not report weekly-earned wages for temporary partial benefits. Without this

data, it is impossible to determine the entitlements for the claimant. New edits have been developed that

will require the RE segment for each week of reported 070 benefits. Table 1 is from the Population

Restriction Table.

Table 1.

Data

Element

Name

Population

Restriction

Exception Element

Error

Number

(DN0116)

Error

Message

Element

Error Text

(DN0291)

Number of

Reduced

Earnings

Value should be greater

than zero when Benefit

Level DN0002

(Maintenance Type

Code) = RE or DN0085

(Benefit Type Code) =

070 (TTP).

If Benefit Level

DN0002

(Maintenance Type

Code) = blank

(Sweep) and BTC

= 070.

045 Value is <

required by

jurisdiction

Expected RE

Segment

Missing

Reduced Earnings (RE) report based upon the following:

• Whenever the MTC is required in the benefits segment for the 070 Benefit Type Code (“Event” Benefits Segment), the RE variable segment is populated with a Reduced Earnings Week Number and an Actual Reduced Earnings Amount for all weeks since the Benefit Period Through Date on the previous transaction.

• The number of RE segments should correspond to the number of weeks from the Benefit Paid Through Date on the previous transaction through the date of the actual TPD payment that triggered the event.

• RE segments will only report once for that reporting week.

• Send Reduced Earnings Week Numbers in sequential order and reset on every report.

• The Division requires an RE segment for each week of a temporary partial benefit period even if

no 070 benefits are paid. An updated RE segment is due when a type change or suspension occurs,

or when TPD lasts longer than 52 weeks.

• The Temporary Partial Benefit Period begins when the claimant has returned to limited duty; not

when the first check is cut.

• The first report of a Temporary Partial payment is due to the division within 28 days of cutting the

first check.

Reported Benefit Values

Previously, Alaska has not had edits on reported values. This has led to some transactions that appear to

move backwards in time rather than progressing forward. While the issue can occur based upon the

dynamics of the claim, the IAIABC has developed methods for reporting these issues.

REDUCED BENEFIT AMOUNT CODE – DN0202 Definition: A code that identifies the reason a Benefits segment may be missing from a transaction or may contain values less than reported in a previous transaction due to a benefit amount being decreased or reclassified or a claim being reported that was settled under another Date of Injury. Codes include D for a Decrease in Indemnity, N for No Money Settlement, R for a Reclassification of Benefit, and S for a Claim Settled Under Another DOI.

RECOVERY CODE – DN0226 Definition: A code that identifies the type of recovery being made. The two values of concern for recoveries include 880 for Voided Indemnity Benefit Check Recovery and 890 for Voided Other Benefit Check Recovery. These two recoveries decrease the total amounts previous reported on Indemnity or Other Benefit Types.

Once set, these values should continue to report on subsequent reporting and increment where appropriate. Several partners had asked for manually removing transactions because of recoveries, to facilitate removing previously reported benefits. In these scenarios, the 02 to update the transaction is the preferred method of correction. If a benefit type changes to no value, both Code D for DN0202 and the recovery for the entire amount reports on the 02 transaction.

Another issue seen with reporting is the number of benefits reported on each transaction. Each SROI compensation report, except for the AN and FN reports, will have one event level segment and sweep in all other previously reported segments. Table 2 represents this edit.

Table 2.

Data Element Name

Population Restriction Exception Element Error

Number (DN0116)

Error Message

Element Error Text (DN0291)

Number of Other Benefits

For SROI compensation reports; DN0282 (Number of Other Benefits) must >= DN0282 from the previous SROI report.

If DN0216 (Other Benefit Type Code) = 440; or this SROI is the first submitted SROI.

045 Value is < required by jurisdiction

Missing expected OBT on report.

Number of Benefits

For SROI compensation reports; DN0288 (Number of Benefits) must >= DN0288 from the previous SROI report.

If DN0202 (Reduced Benefit Amount Code) = R; or DN0202 = D and DN0226 (Recovery Code) = 880; or if DN0216 (Other Benefit Type) = 430; or this SROI is the first submitted SROI.

045 Value is < required by jurisdiction

Missing Expected Benefit type

A rejection from this edit tells the trading partner that the current transaction is missing a benefit segment

or other benefit type.

Table 3, as taken from the Benefit Conditions tab on the Requirements table, ensure when the values

differ from those reported on the previous transaction, then the Maintenance Type Code is required at

the benefit level to reflect it as an Event. Event level reporting is required to report changes to existing or

new benefit types.

Table 3.

DATA ELEMENT NAME

BUSINESS CONDITION(S) When Required

TECHNICAL CONDITION(S) for requirement

EXCEPTIONS When not required

NOTES

MTC Required when the Benefit Type Code is new to the claim.

If DN0085 (Benefit Type Code) = a new BTC (not reported on an earlier Benefit Segment)

If DN0002 = AN

All new Benefit Type Codes must be reported as an EVENT on the appropriate MTC Report.

MTC For Existing Benefit Types Codes, Required when benefit segments do not match previously reported.

If DN0086 (Benefit Type Amount Paid), DN0088 (Benefit Period Start Date), or DN0089 (Benefit Period Through Date) ≠ to previously reported values

If DN0002 = AN

All new Benefit Type Codes must be reported as an EVENT on the appropriate MTC Report.

Lump Sum Payments

One of the bigger issues concerning the reporting of lump sum payments has been with the lump sum

payment settlement code (DN0293) in relation to Permanent Partial Impairment. Alaska Statutes require

PPI paid out, Permanent Impairment percentage X $177,000, as a lump sum payment; except as otherwise

provided in AS 23.30.041 (Rehabilitation and Reemployment). The previous accepted values for DN0293

were restrictive in regards to PPI as most codes deal with an award. To remove reporting restrictions, we

have allowed the Non-Specified Lump Sum Payment code. This will enable the trading partner to report

PPI Lump Sum Payments without having to include an inaccurate payment settlement code.

ADOL does not accept the reporting of any lump sum payments using 0xx benefit type codes.

Compensation is due to the claimant every 14 days when entitled or as agreed upon through arbitration.

With the addition of the non-specified payment code, we have consequently removed the unspecified

lump sum benefit type code. We have determined that all of Alaska Indemnity Benefits report in currently

available benefit types. A scenario does not exist that would require reporting an unspecified lump sum

payment. Please report any lump sum payment under the appropriate 5xx benefit type code.

By mistake, some 5xx lump sum payments have first shown up on a CB or Sx report. When reported in this

fashion, edits will not pass along the required information, so in essence we never receive it. To eliminate

this problem, we devised the edits shown in Table 4 to ensure that all lump sum payments initially report

on the PY transaction. Figure 1 represents a current example from a reinstatement that attempted to

report a lump sum payment using an incorrect transaction type.

Table 4. This table shows the edit restricting 5xx coded to the PY, FN and AN report.

DN Element

Error

Number

(DN0116)

Data

Element

Name

Population

Restriction

Exception Error

Message

Element

Error

Text

(DN0291)

0085 044 Benefit

Type

Code

When DN0085 (Benefit

Type Code) does not

match an existing

reported BTC, then the

BTC cannot be reported

on a Claim Level

DN0002 (Maintenance

Type Code) 02, 04, AN,

CD, CO, FN, Sx or VE.

Value is >

required by

jurisdiction

Use

appropriate

MTC for

new BTC

0085 064 Benefit

Type

Code

If DN0085 (Benefit

Type Code) = 5xx, then

Claim Level DN0002

(Maintenance Type

Code) = PY or its

associated CO or 02

transaction.

If DN0085 (Benefit

Type Code) = 5xx

and the benefit

segment values for

DN0088, DN0089,

DN0090, DN0091,

and DN0086

matches the benefit

segment values on

the last accepted PY

report.

Invalid

data

relationship

First

Reports of

5xx on PY

transaction

Other changes implemented with Lump Sum Payments include removing the payment segment and

suggesting that the Benefit level MTC, along with DN0192, populate when reporting a 5xx BTC as an Event.

With the release of V2.5, DN0222, DN0217, DN0195, DN0219, and DN0220 are marked as NA on the

element requirements table for the PY transaction. We found these elements to be duplicitous and caused

errors with past reporting. You may continue to provide the payment segment and the data should be

available within WcCapture, however, the Jurisdiction will not receive it. We will be using DN0192 to

collect the actual Payment Issue Date on the 5xx BTC. In the event that the actual date is missing, late fee

calculations will be taken from the Benefit Period Through Date (DN0089). While we are not requiring the

benefit level MTC or the Benefit Payment Issue Date because of the R3.0 Standards, we are requesting its

use to be consistent with Sweep and Event level reporting of other benefit types.

Figure 1. This example reports a PPI Lump Sum Payment on a RB. JCN 201700349

Review of the table Layouts

Information Table – The information table hosts the Event, the Valid Values Tables, and an easily printable

reference sheet. On the Event table (Figure 2), you will find when each transaction type is due to the

Division, the statute governing the requirement, and required notifications. The valid values table

identifies which codes the jurisdiction accepts and shows invalid codes highlighted in gray. The QC pages

are the Quick Code reference sheets that identify the common codes and transactions typically used for

all reporting. Again, grayed out fields are not accepted in Alaska.

Figure 2. Event Table

Report

Type

Maintenance Type Event Rule Report Trigger When is the Report Due?

Statute

Notifications

Receiver Code Description Criteria From Thru Criteria Trigger Value Value Due Type From

FROI 00 Original 2 07-22-13

A,M All new claims including notification only,

medical only and time loss.

10 Days C C AS 23.30.070

J EE & CA

FROI 01 Cancel 2 07-22-13 J Duplicate claim created / received and

Jurisdiction is aware.

1 Day B J J EE & CA

Requirement Table – This document hosts all the requirements associated with the transactions. It

includes a tab for the FROI Requirements, FROI Conditions, FROI 02 Edit Conditions, SROI Requirements,

SROI Conditions, SROI 02 Edit Conditions, Benefit Segment and Benefit Conditions. These tables capture

the same data from the previous version; reformatted for easier use and printing.

Additions to these tables include Exceptions (to help provide variations in reporting based upon different

scenarios), version changes and a place to include notes. Additionally, we updated the Benefit Segment

to include all benefit type codes with their conditions modified to represent the event or sweep as

applicable.

Transaction Help Table – The Transaction Help table includes the current DN-Error Message, Population

Restrictions, Sequencing, and the Match Data Tables. We organized these tables to make it easier to

research acknowledgement (errors) issues with a transaction.

• The DN-Error Message Tab identifies for each DN number, if the Jurisdiction will edit the field,

what type of edit, the associated error message when the edit fails, and if documented within the

Population Restrictions tab. While the table works the same as before, ADOL added a few

categories to provide more organization to this chart.

o Edit Matrix Population Legend (Column G - BF) - This legend identifies the different

categories that will be found within the body of the chart.

▪ F = Edit applies to the data elements deemed essential for a

transmission/transaction to be processed.

▪ L = IAIABC Standard Edit applies to the data elements (Highlighted to be a

reminder of standard edits)

▪ LN = IAIABC Standard edit that will not be applied by the jurisdiction.

▪ P = Jurisdictional Population Restriction applied (Highlighted to show ADOL

Restrictions)

▪ 2N = Not changed on a 02 transaction.

▪ F2 = Change this DN with a FROI 02 immediately.

▪ S2 = Change this DN with a SROI 02 immediately.

• The Population Restrictions tab includes the new additions for exceptions along with new and

revised error messages. We designed the error messages to provide a detailed explanation of the

error that occurred.

• The Sequencing Tab is the one area that had the most sweeping changes. Please use this table to

identify the order in which transactions can occur. We removed several reports from the

sequence schedules. We have also included a section for sequencing restrictions to help illustrate

any attributes or restrictions that could affect the submitted transaction. Additionally, we have

provided a descriptive term defining the transaction type and the expected use for each

transaction. We implemented these fields to assist with training for the trading partner.

• The last two tabs concern the Match Data for normal and the UR transactions. Changes on match

data include making the Claim Admin Claim Number a Primary Match element, inclusion of the

Employer FEIN and the addition of the Part of Body as an additional match data.

The Trading Partner Registration Process

With the cooperation of Verisk Insurance Solutions, we have enhanced the Trading Partner Profile

Registration process to provide an easily sustainable profile requiring less effort to maintain. Each Trading

Partner will have access to their profile information through an online portal as shown in figure 3.

Figure 3. Registration Main Page

This portal will host all the profiles associated to your user account. For your initial registration, please

select “New Profile” to get started. For this new process, every EDI Sender will have to register their

current profiles into the new system. This will be an opportunity to update all information for each profile

and make everything current. The profiles, once entered, will be static. It will be the responsibility of the

trading partner to ensure the profiles remain current in the system and to submit all changes. After

establishing the Sender Profile, the next section is for the Primary Company Contact, figure 4. For this

contact, please list the contact information for the decision maker or the manager with the appropriate

authority.

Next, figure 5 represents the EDI Preparer Contact information. This section will provide primary contact

information of the person responsible for entering or transacting EDI reports for this sender. A secondary

contact is desired but not required. The person(s) listed should be able to respond to requests from the

Jurisdiction (case establishment requests) as well as access EDI reporting for all claims submitted.

Figure 4. Primary Company Contact

Figure 5. EDI Preparer

The next section is the Technical Contacts for the Sender ID, figure 5. This contact information should

represent a programmer or system developer who might provide assistance with the technical aspects

of EDI submissions. The primary point of contact is required and the secondary, only if available.

Figure 5. Technical Contacts

Once the Sender Profile is complete, the task for inputting all carriers and administrator begins. The next

section begins with the insurers. Figure 6 is the registration page for adding a carrier.

Figure 6. Insurers

The data entered into these fields will be static. All new entities register as ‘Add’ and any future changes

will be to inactivate the carrier or to update any information. This process will collect the same information

as before, the legal entity name, FEIN, and effective date. We did add some additional fields such as

insurer type classifications, required license number for Alaska-licensed Insurers, NAIC number and Group

Name where applicable. The remaining two fields provide the reason for adding this entity and who will

administer this carrier’s claims.

Registration for a Claim Administrator has three sections. Figure 7 represents the primary company

information associated with this entrant. In this section, please provide the status (same as for the insurer

section), effective date, FEIN, Legal Entity Name for the listed FEIN, Representative Name, Representative

Phone Number, Representative Email Address and the Claim Administrator License# for either the

Company or Representative Name, whichever authorizes this entity to conduct business for Alaska

Workers’ Compensation claims. There are three types of administrators to select when entering this party.

When selecting one of the two Alaska licensed entries, the License# is required. Since the Insurer can

administer claims through their own-staffed adjusting facility in the state of Alaska, no license is required

for that selection.

Figure 7. Claims Administrator

Just like the previous process, this one also requires registration of both a mailing and physical address.

The mailing address is the primary address used in the ICERS database. The Jurisdiction mails all

correspondence for a claim to the mailing address on file for this party. There may only be one mailing

address for a registered claim administrator based upon FEIN. This address must be the same for all

Trading Partners that utilize this Entity as a claim administrator and may be for any location, including the

lower 48 states. All mail sent to this location will be the responsibility of that address to forward it to the

appropriate responsible parties. The physical address is required to be an Alaska Address representing the

physical location for this administrator’s services. The insurer and claim administrator will be responsible

for setting up internal business processes to communicate with each other.

Figure 8. Addresses

Figure 9. Claim Acquisition

The last section (figure 9) for registering a claim administrator provides the reason for the addition. The reason will help us understand the scope of any additions. Capacities include a full inventory, unbundled claims, employer or employer groups, or a select few claims. We require the capacity when the reason selected includes acquiring claims or both new and acquire. If you select the employer or unbundled category, please provide a description for the claim movement or FEIN of the employer.

On the Filing method tab, the only update to this portion is to provide a specific contact for the selected method. This person should be familiar with the claim system in use by your company. Alaska is not familiar with the many systems in use by our trading partners and have a difficult time helping on issues that occur before a transaction makes it to WcCapture.

After updating or adding all information, please provide any necessary comments on anything you feel important about this profile. Once completed, please save and submit the profile. The profile submission will send your entire registration to us through email. When making updates to a profile, please go back to this Sender ID and add or update any changes. The new profile would represent a new SENDER profile registration and not a new addition to any current profile. To keep the Jurisdiction aware of changes, please update any changes to the registered profiles as they occur. This includes any contact information, active profile participants, or licensing information.

Annual Reporting

First, we would like to make a distinction between the Annual Report and the Annual SIF/WSCAA report. While these two different reports work in conjunction with the other, due to EDI, they are separate reports. EDI is the preferred method of receiving all Annual Reports for the individual claims information. This includes Legacy or traditional claims for all EDI registered Trading Partners. For approved paper partners, please submit the flat file spreadsheet as indicated in the latest Annual Report Bulleting released at http://labor.alaska.gov/wc/bulletins.htm. Please continue to submit the SIF/WSCAA report to the division contact through the normal procedure. We eventually plan to calculate and invoice the trading partner for any SIF/WSCAA due at the completion of the Annual Reporting period.

For the Flat File Process, it is important to note that all Annual reports submit through EDI. This includes all legacy and paper AN reports. This means that all submissions must meet EDI requirements for the annual report outlined in our requirements tables. The data supplied in the flat file must match existing reports and all match data elements, or delays will occur. We will make every effort to process the flat file submission in a timely manner; but any delays experienced are the responsibility of the trading partner. Upon review of the flat file submission, we will request corrections for any errors found within the file. Rejected transactions will also require corrections. Some submitters have operated on the assumption that once the flat file submits to the jurisdiction, the process is complete. However, we do not consider the Annual Report received until the file accepts in EDI.

For many reasons, some flat file submissions have reported data that is not consistent with the data previously submitted on the claim. When this occurs, the trading partner ultimately has the responsibility of reconciling the claim and Annual Report. This process is time consuming for both the Jurisdiction and the Trading Partner. We will not process any annual report submissions until the reconciliation process is complete. By removing the Jurisdiction as the submitter for the annual report, we could reduce the impact of this process through EDI reporting of all annual reports by each EDI approved trading partner. While we do not require this for paper claims, it is possible for an EDI partner to submit the AN through EDI. This

process might also require a reconciliation, but once completed, ensures a smoother process for future reporting.

The Annual reporting period is from January 1st through March 1st of the year. All annual reports are due during this reporting period. It is best to complete this process as early as possible during this period. For automated EDI systems, triggering the AN report on the 1st of January would be the ideal situation. This provides an additional 89 days for any corrections that may be required.

Paper Claim Submission

For our registered EDI partners, we would like to extend to you the opportunity to pick up reporting on your paper claims. To report on these claims, the requirement is to have the appropriate match data, the trading partner profile that includes the Insurer and Claim Administrator on the claim, and the appropriate report history within your system to continue the current sequence. We are willing to work with you to fulfill the necessary steps to transition. This transition could be as simple as a FROI 02 submission by the trading partner or a complex transfer of historical reporting to your current vendor. EDI reporting is not a current Jurisdictional requirement for our partners, but we have pending legislation that will move us in that direction.