Claims EDI Release 3 Training February 11 – 12, 2014 Florida Division of Workers’ Compensation.

Claims EDI Release 3 Training

February 11 – 12, 2014

Florida Division of Workers’

Compensation

EDI Team Members

Linda Yon,Bureau Chief, Bureau of DataQuality & Collection

Tonya Granger, System Project Administrator (EDI Coordinator)

(cont’d…)

EDI Team MembersMichelle Carter,

Operations Review Specialist

Riley Pool, EDI Team Member

Megan Fox, EDI Team Member

(cont’d…)

Laura Cotner, EDI Team Member

Antrine Long, EDI Team Member

EDI Team Members

Housekeeping

Handouts Include: Agenda Copies of Slides Quick Code References Acronym List

Breaks and Lunches

Note Cards for Questions

Throughout this training, we encourage you to raise your hand and ask questions at any time.

We also encourage responses to our games and pop quizzes. We have candy for those who raise their hand and are called upon for a response.

Audience Participation

7

This training assumes you have participated in prior trainings or webinars on the basics of the Clams EDI R3 process,

and have a basic familiarity with the FROI and SROI transactions, MTC’s and FL’s requirement tables.

8

We recognize that your company’s system or your vendor’s software application may use different data element names

and look significantly different than the national standard EDI FROI and SROI transactions.

9

One thing that is universal for all of us is the use of FL’s EDI

Data Warehouse.

For this training, we have elected to display data in the format it is seen in the FL EDI Data Warehouse, in hopes it will be more familiar to you.

Claim Administrator

Data Entry

The Division is developing an enhancement to the Claims EDI Warehouse that will permit approved claim administrators to directly enter FROI and SROI transactions.

Claims EDI Data Warehouse Claim Administrator Data

Entry

This data entry capability can be utilized by small claim administrators for filing all EDI transactions.


Entry

It can also be utilized by claim administrators for submitting or correcting a single transaction they were unable to successfully submit via their own system or a vendor’s system.


Entry

Some questions we have are:

Whether or not this data entry capability would be beneficial?How and where to return AKCs? What information/file would vendors need to process an AKC for a file they did not send, etc…


Entry

If you are interested in providing any feedback on this, please see me (Linda Yon) at one of our breaks during this training.


Entry

16

DWC’s Website URL has changed

to:http://www.myfloridacfo.com/Division/WC/

17

Effective Friday 2-14-14, if you have an old page bookmarked, you will be re-routed to

the new Home Page.

Discussion Topics Claims EDI Warehouse Demonstration Insurer Access View

Clarification of IAIABC 2014 R3 Implementation Guide

Change

Reporting Return to Work Information MTC S1 (Suspension - RTW) vs.

FROI or SROI 02 (Change)

(cont’d…)

Discussion Topics Reinstatement of Benefits (MTC RB and MTC ER)

Top Errors Affecting Claim Administrators and How to

Correct Them

Proper Reporting of Claim Type ‘L’ (Medical Only to Lost Time)

Name That MTC

Scenario

MTC EP (Employer Paid) filed MTC IP (Initial Payment) filed Suspension (Sx) filed Employer is now paying Impairment Income Benefits (IIBs)

What MTC should be filed?

MTC ER Employer

ReinstatementBecause the employer chose

to pay IIB benefits.

Scenario

Claim administrator pays days 1-7 of disability to the injured worker


NOTHING DUEInjured worker has not been disabled for 8 or more days.

Scenario

FROI 04 filed

Denial is rescinded but no indemnity is due at time of rescission


SROI 02Change

Because no benefits are being initiated at this time.

Scenario

00/IP filed reporting TT benefits

TT benefits end and TP benefits begin and AWW/CR was also amended


MTC CBChange in Benefit

TypeBoth events (reporting

change in benefit type and change in AWW/CR)

should be reported on the MTC CB.

An MTC CB trumps an MTC CA.

Scenario

00/IP filed reporting TT benefits MTC CB filed to change benefits from TT to TP Suspension (Sx) filed MMI reached, PI Rating assigned and Impairment Income Benefits (IIBs) need to be reported


MTC RB Reinstatement of

BenefitsBecause indemnity has been

paid after a suspension.

Scenario

00/IP filed reporting Temporary Total

Catastrophic benefits (TTC) MTC CB filed to report Permanent Total and Permanent Total Supp benefits initiated after 26 weeks of TTC Annual increase for PT Supplemental benefits now needs to be reported


MTC CA Change in AmountNet Weekly Amount for PT Supps (BTC 021) changes

every January.

Scenario

00/IP filed reporting TP benefits MTC CB filed to change benefits from TP to IBs IBs paid in full & no further WC benefits dueWhat MTC should be filed?

MTC S7 Suspension –

Benefits Exhausted

Scenario

MTC FN filed Injured worker’s condition worsened, claim reopened because new period of TT benefits needs to be reported


MTC RB Reinstatement of

BenefitsTT paid after claim was

closed.

Scenario

00/IP filed

Claim is further investigated and subsequently denied


SROI 04Full Denial

FL requires a SROI 04 (Full Denial) if indemnity had been

previously reported.

Scenario

Compensable death and dependants need to be paid


00/IP00/CD – Is sent if dependant status could not be verified

at the time the death claim is required to be filed.

If dependants are later identified after the 00/CD is filed, a standalone IP is filed to report the benefits paid.

Scenario

Permanent Total benefits are currently being paid to injured worker

Claim administrator now has knowledge that PT Supp benefits should be commenced


MTC AB Add Concurrent Benefit

Type

Scenario

Benefit Period Start Date of a BTC currently on file with DWC was incorrectly reported


SROI 02 Change (with an ‘02’ in the Benefit

Segment)

(MTC CB or RB is not required)

Scenario

MTC AQ (Acquisition) accepted New claim administrator reports initial payment of indemnity benefits (not a lump sum payment or settlement)


MTC AP Acquired/Payment

Initial payment by acquiring claim administrator.

Scenario

00/IP filed

Claim Administrator determined the Benefit Type on the initial payment (IP) was wrong


MTC CB Change in Benefit

Type With the Reduced Benefit Amount Code (RBAC) ‘R’ -

Reclassification because all indemnity monies are being reclassified from one Benefit

Type to another.

FL will also accept a SROI 02 (with an ‘02’ in the Benefit

Segment) and the RBAC ‘R’.

49

Scenario

00/IP filed

Claim Administrator determined the employer continued salary in lieu of compensation and the MTC and

Benefit Type were wrong


50

MTC 01 Cancel00/IP should be cancelled and followed up with a 00/EP with

BTC 2xx. We recognize that the 00/EP may

be late and if a penalty is assessed, the CPS Team will

remove the penalty if the original 00/IP was timely filed;

however, the claim administrator must contact the CPS Team to advise them of the need to re-

evaluate the penalty because of the previous cancellation.

51

MTC 01 CancelWe recognize there are other ways to correct the benefit

picture by reclassifying benefits; however, this could cause

sequencing issues later in the claim.

Claims EDI Data Warehouse

Insurer Access View

The Division recently enhanced the Claims EDI Data Warehouse to include an “Insurer View” feature.

Claims EDI Data Warehouse Insurer Access View

The “Insurer View” will allow Insurers and Self-Insurers whose claims are handled by TPA’s

to view the transaction results exclusively for their company only.

Claims EDI Data Warehouse Insurer Access View

For example:

Best TPA handles claims for Old Reliable Insurance Co.

Currently, Old Reliable has no way to view claims data submitted to the Division by Best TPA.

This new feature will allow an approved contact person from Old Reliable to access and review the activity of ‘their’ company’s claims which are handled by Best TPA.

The insurer will not be able to view the data for any other Best TPA insurers.

If an Insurer contracts with multiple TPA’s for handling of their claims, an insurer will be able to view the activity of those particular claims under one single sign-on.

To request access to the Insurer View, please contact a member of the EDI Teamat [email protected]

Once your Insurer View account has been created, a member of the EDI Team will contact you to set up a Microsoft Lync web session to walk you through how to use the account.

Questions

60

Clarification of IAIABC 2014 R3 Implementation

Guide Change

61

Latest Return to Work Status Date

(formerly Current

Return to Work Date)

62

Current Date Disability Began,Current Date Last Day Worked andCurrent Return to Work Date

were originally defined to relate to a “subsequent period of disability”.

Latest Return to Work Status Date (formerly Current Return to Work Date)

63

Current Return to Work Date was recently changed to Latest Return to Work Status Date because:

The definition of “current” and “subsequent period of disability” were widely misunderstood,

AND…

64

It was unclear what date to send when the Physical Restrictions Indicator or RTW Type Code had changed but there was no new RTW Date…

65

For example:

IW actually RTW on 1/1/14 with restrictions (IRTW = 1/1/14) IW returned to doctor and was “released to RTW” (actual) with no restrictions on 1/20/14

Dilemma: The date (1/20/14) represents the effective date of a Physical Restrictions change but is NOT a new RTW date as the IW was still at work…

66

… However, the date the IW no longer has physical restrictions is still needed by jurisdictions

as it is directly connected to a possible change in benefits status.

Although the IW was already back at work, he now no longer has restrictions and would no longer be eligible for TP benefits.

This date would now be reported as a Latest Return to Work Status Date.

67

So, in this example, the IW actually RTW on 1/1/14 with restrictions (IRTW = 1/1/14).

On 1/20/14, the IW returned to the doctor and was released to RTW (actual) with no restrictions (IW still working).

68

Here, the Latest Return to Work Status Date would be sent to report the effective date of the Physical Restrictions change.

This is no longer an update to the Initial Return to Work Date

69

From this point on in the claim, any changes to:

Return to Work Type Code, Physical Restrictions Indicator, Return to Work with Same Employer Indicator or Return to Work Date

will be reported as a Latest Return to Work Status Date.

70

Prior to the name and definition change, Current Return to Work Date was intended to represent the date the employee

actually returned to work, or was released to return to work,

following a subsequent period of disability.

71

The prior Current Return to Work Date was not intended to report the date the Return to Work Type Code and/or Physical Restrictions Indicator changed when there was no subsequent period of disability; however, Current RTW Date was being used for this purpose.

72

In the IAIABC R3 Implementation Guide, the DP Rule for the Initial Return to Work Date was initially amended to indicate this date should be updated (via a SROI 02) if

the Return to Work Type Code and/or Physical Restrictions Indicator changed prior to a subsequent period of disability;

however, this was still misunderstood.

73

The IAIABC Claims Committee recently adopted a name and definition change, changing Current Return to Work Date to Latest Return to Work Status Date.

This date now represents either the most recent date the employee returned to work after the Initial Return to Work Date…

OR

74

… the “effective date” of the most recent change to the Return to Work Type Code, Physical Restrictions Indicator or Return to Work with Same Employer Indicator.

75

The IAIABC Claims Committee also recently adopted another DP Rule change for Initial Return to Work Date and FL has amended edits as follows…

76

New FROI 02 (Change) Edit

77

Effective 6/1/2014, if the Initial Return to Work Date is being reported for the first time and no other ‘event’ is due, a FROI 02 must be sent to report:Initial Return to Work DateReturn to Work Type CodePhysical Restrictions Indicator and Return to Work with Same Employer Indicator (if RTW Type Code = ‘A’ (Actual)

New EditFROI 02 (Initial RTW)

78

If an ‘event’ transaction is sent and the Initial Return to Work Date is being reported for the first time,

along with the Latest Return to Work Status Date,

both the IRTW Date and the Latest RTW Status Date will be loaded to DWC’s database.


79

However, the additional RTW fields will be applied to the Latest RTW Status Date (because it is the most recent date) and a TA-FL error will be received requesting the following information for the Initial RTW Date:


80

Return to Work Type CodePhysical Restrictions Indicator andReturn to Work with Same Employer Indicator (if RTW Type Code = ‘A’ (Actual)

This information must be reported on a FROI 02.


81

The FROI 02 transaction is due 14 days after the claim administrator’s notification of the change.

FROI 02 (Reporting Initial RTW

Information)

82

Effective 6/1/2014, a SROI 02 will no longer be accepted to initially report, or update, the Initial Return to Work information.


83

Claim Scenario

Let’s take a look at an example of the Latest Return to Work Status Date (formerly Current Return to Work Date).

84

Example:

6/28/13 = DOI & Initial Date Disability Began7/11/13 = 00/IP sent; Temp Total (050) paid. 8/9/13 = IW is initially released to light duty; Employer could not accommodate

restrictions. 8/22/13 = MTC CB (Change in Benefit Type) sent changing TT (050) to TP (070); Reporting IRTW (8/9/13).

Return to Work Type Code = R (Released)Physical Restrictions Indicator = Y (Yes)

85

9/19/13 = Dr changed the injured worker’s release (to full duty - no restrictions). 9/20/13 = MTC S1 (Suspension – RTW) sent suspending all indemnity and reporting release to full duty and updating RTW Type Code and Physical Restrictions Indicator:

Return to Work Type Code = A (Actual)Physical Restrictions Indicator = N (No)Return to Work with Same Employer

Indicator = Y (Yes)

86

9/19/13 = Effective date of the change to RTW Type Code and Physical Restrictions Indicator.

This was formerly an update to the IRTW Date but was reported by some as a CRTW Date…

87

… This date (9/19/13) did not represent a subsequent period of disability.

FL previously edited for the presence of a subsequent period of disability and this caused confusion and rejections.

As of 1/1/14, this 9/19/13 date would represent the Latest Return to Work Status Date.

88

Effective January 1, 2014, FL will accept this implementation of the name and definition change for Current Return to Work Date to Latest Return to Work Status Date.

We will no longer require evidence of a subsequent period of disability.

89

POP QUIZ:What MTC is to be used

to report an injured worker’s IRTW

information if benefits may continue in the

future?

90

ANSWER:

FROI 02 (Initial Return to Work)

91

Questions Regarding

Latest Return to Work Status Date?

Suspensions

Suspensions

MTC S1-S8

Suspension transactions should only be sent when all indemnity benefits have been suspended and no further indemnity benefits will be paid.

A suspension transaction must include an MTC in the Benefits Segment

for the benefit type being suspended,

because it is considered to be an “Event” Benefit Segment . EVEN

T

If a suspension is sent, the ‘Suspension Effective Date’ is required.

The ‘Suspension Effective Date’ is the last date for which indemnity benefits are due.

The ‘Suspension Effective Date’ could be different from the last day in which benefits were paid on a claim (if there was an overpayment)

and may not be the date the claim administrator decided to suspend benefits.

Are Suspensions an “Event” Benefit

Segment, or “Sweep” Benefit

Segment?

ANSWER:

“Event” Benefit Segment

When a Benefit Type is affected by the “Event” being reported, the MTC is sent in the Benefits Segment and it is considered an “Event” Benefits Segment.

99

An MTC S1 (Suspension – RTW) transaction should only be sent when

all indemnity benefits have been suspended

and no further indemnity benefits will be paid.

MTC S1 (Suspension – RTW)

100

An MTC S1 should not be sent prematurely (before the last indemnity payment has been reported on the transaction).

101

When an MTC S1 is sent prematurely,the claim administrator would be required to reinstate benefits prior to submitting the next applicable transaction.

102

Examples of when the MTC S1 is sent prematurely include, sending the transaction prior to:

the last payment being made, receiving medical evidence that an injured worker has reached MMI or confirming that no further indemnity benefits are due.

103

An MTC S1 transaction should not be sent to solely report an injured worker’s RTW information if benefits may continue in the future.

SEND

MTC S1 vs. FROI or SROI 02

(Reporting RTW Information)

105

FROI 02Reporting Initial RTW Information

106

If an injured worker has been initially released to return to work

and it is uncertain if additional benefits will be paid,

a FROI 02 transaction (as opposed to an MTC S1) should be sent to report this information.


Information)

107

The FROI 02 transaction is due 14 days after the claim administrator’s notification of the change.


Information)

108

SROI 02Reporting Latest RTW Status Date

Information

109

If the claim administrator has already reported the Initial RTW Date

but the injured worker is subsequently out of work and is later released to return to work again

and the Latest RTW Status Date needs to be reported…

SROI 02 (Reporting Latest RTW Status Date

Information)

110

… a SROI 02 transaction (as opposed to an MTC S1) should be sent, unless it is certain that all benefits are being suspended.

The SROI 02 is due 14 days after the claim administrator’s notification of the change.

SROI 02 (Reporting Latest RTW Status Date

Information)

111

By filing either a FROI 02 (Initial Return to Work Date)

or SROI 02 (Latest Return to Work Status Date) whichever is due,

to solely report Return to Work information as opposed to incorrectly using the MTC S1…

FROI or SROI 02 (Reporting RTW Information)

112

… the claim administrator will not be required to file an MTC RB (to reinstate benefits), in the event the injured worker is due additional indemnity benefits.If additional benefits are paid, an MTC CB would be due instead of the MTC RB.

FROI or SROI 02 (Reporting RTW Information)

113

… If a change must be made to correct the Initial RTW Date previously reported,it must be sent via a FROI 02, along with the corresponding Return to Work Type Code and Physical Restrictions Indicator.Return to Work with Same Employer Indicator is also required if RTW Type Code is Actual (A).

Correcting Suspension Information

If the wrong suspension code was sent (e.g. an MTC S7 was filed instead of an MTC S1), it can be corrected by sending the same transaction againwith the correct MTC suspension code…


… The Division’s program will allow the second suspension to process without an intervening reinstatement

as long as the ‘Suspension Effective Date’ remains the same as the date sent on the first suspension.


If the correct suspension MTC code was sent with the wrong ‘Suspension Effective Date’,

this can be corrected by sending a SROI 02 transaction to correct the ‘Suspension Effective Date’…

… The Division’s program will not allow another suspension MTC to be sent with a different ‘Suspension Effective Date’ without an intervening reinstatement.

If previous suspension transactions have been acceptedand a SROI 02 is sent to correct a Suspension Effective Date, the new corrected ‘Suspension Effective Date’ will only apply to the most recent suspension transaction accepted.Sx Eff

Date7/15/12

First

Sx Eff Date

8/7/12

Second

Sx Eff Date

8/10/12

SROI 02

X

Additionally, if benefit information needs to be changed or corrected, a SROI 02 can be sent to update the Benefit Segment.

The SROI 02 must include an ’02’ in the Benefit Segment and not introduce a new Benefit Type Code.

Reminder: An ‘02’ must be included in the Benefit Segment of the MTC 02 in order for the Benefit Segment, or any other money segment on the SROI 02 transaction, to be edited/loaded.

Data was not edited/loaded:

Data was edited/loaded:

What MTC is used to correct an

injured worker’s IRTW information

previously reported?

ANSWER:

FROI 02 (Change)

Questions

Reinstatement of Benefits(MTC RB)

MTC RB(Reinstatement of Benefits)

An MTC RB (Reinstatement of Benefits) should be sent when indemnity benefits previously paid by the claim administrator

are resumed after a suspension or denial that has not been rescinded.

The Benefit Type (BTC) being reinstated may or may not have been previously paid.

In order for an MTC RB to be accepted, one of the following SROI transactions must have been previously reported:

SROI S1-S7 (Suspension) At DWC claim is in ‘suspended

status’SROI 04 (Full Denial)

At DWC claim is in ‘denied status’SROI PD with Partial Denial Code ‘A’ or ‘E’ (indemnity in whole or part)

At DWC claim is in ‘denied status’

For FL, the SROI 02 is used to report the rescission of a denial if no benefits are due at the time of rescission.

The IAIABC standard does not address how to report the rescission of a denial if benefits are not being paid at the present time.

If a SROI 02 is used to report a Denial Rescission Date whenbenefits are not being paid at that time,the claim is no longer in a ‘denied status’ at DWC. If benefits are later paid on this rescinded claim, FL requires an MTC CB to be sent instead of MTC RB.

Both the SROI 04 and SROI PD (with Partial Denial Code A or E) act as a suspension and all indemnity benefits are terminated at the time of the denial.

New EditMTC RB

(Reinstatement)

In the past, the EDI Team has received many requests from claim administratorsto have reinstatements removed from our internal database due to sequencing issues that occurred later on in the claim…

New EditMTC RB (Reinstatement)

… For example:

MTC S1 filed (claim in suspended status)

MTC RB filed (reporting previously paid “back” benefits where the Benefit Period Through Date did not advance)

MTC FN rejected (No SROI S1-7, 04, CD, VE, PY or PD on file)

Another MTC S1 rejected (Duplicate Suspension with Same Eff Date)

A new edit was put in place because Claim Administrators were using the MTC RB (as opposed to the SROI 02) to report previously paid “back” benefits…

NewMTC RB

Edit

For Division Received Dates on or after 2/1/2014, if MTC = RB, the most recent Benefit Period Through Date on the RBmust be greater than the most recent Benefit Period Through Date on the accepted MTC S1-S7, PD or SROI 04which precedes the RB.

Error message:‘RB N/A benefit period has not advanced’

Questions

Top Errors Affecting Claim Administrators and How to Correct

Them

Let’s take a closer look at some of the top errors claim administrators are receiving and discuss ways to prevent them or how to handle them once received…

Error #1:

NBR OF BENEFITS SHOULD NOT BE > WHAT IS ON FILE

This error occurs when the current transaction reported contains a Benefit Type Code(s) that was not reported on the last accepted transaction.

The following scenario is an example of when this error occurs…

Top Errors Affecting Claim Administrators:

NBR OF BENEFITS SHOULD NOT BE > WHAT IS ON FILE (0288-044)

On 8/23/12, the claim administrator submitted a 00/IP and reported the initial payment of TT (050) benefits.

BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date

050TEMPORARY

TOTALIP 128.00 8/7/12 128.00 8/7/12 8/17/12 8/23/12 1 0 128.00 8/23/12

The injured worker reached MMI (3% PIR) and was paid all IB benefits prior to the claim administrator reporting the next event.

On 12/31/12, the claim administrator attempted to suspend the claim because all benefits had been exhausted.

The transaction contained both IB (030) and TT (050) benefits and rejected becausenew benefits cannot be introduced on a suspension. BTC

Benefit Type

MTCGross

Weekly Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date

030PERM PART SCHEDULED

S7 48.00 12/27/12 48.00 12/27/12 12/27/12 2/6/13 6 0 288.00 12/31/12

050TEMPORARY

TOTAL128.00 8/7/12 128.00 8/7/12 8/10/12 12/16/12 18 3 2380.80 12/28/12

In this scenario, BTC 030 (IBs) should have been introduced on an MTC CB prior to the suspension.

The claim administrator should resend the transaction as an MTC CB.

Once accepted, the suspension can then be filed.

IP – Initial Payment EP - Employer Payment CB – Change in Benefit Type ER - Employer Reinstatement

RB– Reinstatement of Benefits

AB– Add Concurrent Benefit Type

PY – Payment Report or AP – Acquired/Payment

Keep in mind that if new Benefit Type Codes are being reported for the first time, those benefits must be “added” on one of the following applicable MTCs…

Let’s take a look at another example of when the error occurs for ‘NBR OF BENEFITS SHOULD NOT BE > WHAT IS ON FILE’…

The claim administrator previously paid and reported TT (050), TP (070) and IB (030) benefits.

In a subsequent event, the claim administrator only reported TT and IB benefits and also reported a Reduced Benefit Amount Code ‘D’,

which allowed the TP (070) segment to drop off…

Drop Off

BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Benefit Payment

Issue Date

050TEMPORARY

TOTAL266.68 1/1/13 266.68 1/1/13 1/1/13 2/11/13 6 0 1600.08

070TEMPORARY

PARTIAL256.00 2/12/13 256.00 2/12/13 2/12/13 3/25/13 6 0 1536.00

030PERM PART

SCHEDULED 100.01 7/1/13 100.01 7/1/13 7/1/13 8/11/13 6 0 600.06

Benefit Information:

Reduced Benefit Amount Code D – DECREASE INDEM

BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Benefit Payment

Issue Date

050TEMPORARY

TOTAL02 266.68 1/1/13 266.68 1/1/13 1/1/13 2/11/13 6 0 1600.08

030PERM PART

SCHEDULED 100.01 7/1/13 100.01 7/1/13 7/1/13 8/11/13 6 0 600.06

Since the ‘D’ code was sent on the SROI 02 below, the benefit picture was reset to reflect TT and IBs only. * TP no longer on file *

Current benefit picture on file at DWC:

MTC SA:

A subsequent MTC SA (Sub-Annual) was filed reflecting all 3 BTCs

and it rejected with the error ‘NBR OF BENEFITS SHOULD NOT BE > WHAT IS ON FILE’

because the ‘D’ code previously reported allowed TP (070) benefits to drop off.BTC

Benefit Type

MTCGross

Weekly Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Benefit Payment

Issue Date

050TEMPORARY

TOTAL266.68 1/1/13 266.68 1/1/13 1/1/13 2/11/13 6 0 1600.08

070TEMPORARY

PARTIAL256.00 2/12/13 256.00 2/12/13 2/12/13 3/25/13 6 0 1536.00

030PERM PART

SCHEDULED 100.01 7/1/13 100.01 7/1/13 7/1/13 8/11/13 6 0 600.06

In this scenario, the claim administrator will need to re-add the TP (070) benefits via a SROI 02 (with an MTC 02 in the Benefits Segment).

New Benefits Type Codes reported for the first time can appear on an MTC SA

(Sub-Annual) Or

FN (Final).

True or False

ANSWER:

FALSE

New BTCs must be added via an MTC IP, EP, CB, RB, AB, PY, ER or AP.

Reporting BTCs Accidentally Left Off

Transactions

If a Benefit Type Code (BTC) previously reported was accidentally left off the last accepted transaction,

those benefits must be “re-added” by filing a SROI ‘02’ (Change)

with an ‘02’ in the Benefits Segment.

If the previously reported BTC was:

‘500’ - Unspecified Lump Sum Payment/ Settlement

- OR –

‘501’ - Medical Lump Sum Payment/Settlement

and was accidentally left off the last accepted transaction…

…those benefits may be ‘re-added’ by filing a SROI ‘02’ (Change) with an ‘02’ at the benefit level in the Benefits Segment.

The SROI ‘02’ re-adding BTC ‘500’ or ‘501’ WILL reject for this error (NBR OF BENEFITS SHOULD NOT BE > WHAT IS ON FILE)

because our program expects a settlement to be reported via an MTC PY.

Once the transaction rejects, send an email to: [email protected]

A member of the EDI Team will validate that the required lump sum settlement data elements were previously reported

and if so, they will reload the rejected SROI 02.

Questions Regarding Error #1?

NBR OF BENEFITS SHOULD NOT BE

> WHAT IS ON FILE

Error #2:

BENEFIT TYPE AMOUNT PAID < PREVIOUSLY REPORTED

Top Errors Affecting Claim Administrators:

BENEFIT TYPE AMOUNT PAID < PREVIOUSLY REPORTED (0086-059)

This error occurs when the Benefit Type Amount Paid (total)

for one or more Benefit Type Codes

was less than what waspreviously reported on thelast accepted transaction.

If the last accepted transaction was a SROI 02 and there was no ‘02’ in the Benefit Segment,

the Benefit Segment data was not edited/loaded;

therefore, although this transaction was accepted, the Benefit Segment information was not.

This error also occurs when the Reduced Benefit Amount Code ‘R’ (Reclassification) was sent

and the total of all Benefit Type Amounts Paid

is less than previously reported on the last transaction.

If benefits have been reclassified from one benefit type to another,

the total of all monies previously paid

should still be equal to or greater than what was reflected on the previous transaction.

Ways To Avoid Receiving Error‘BENEFIT TYPE AMOUNT PAID <

PREVIOUSLY REPORTED’

To avoid receiving this rejection error, a reduction in the amount paid for a Benefit Type, or

the disappearance of a previously reported Benefit Type,

must be ‘explained’ by reporting one of the following…

Reduced Benefit Amount Code ‘R’(Reclassification)

The ‘R’ code can be sent. However, the total of all monies previously paid must still be reflected on the transaction.

The ‘R’ code should only be used for true reclassifications (e.g. Temporary Total (050) paid but Temporary Partial (070) was due).

OR…

Reduced Benefit Amount Code ‘D’(Decrease in Indemnity)

The ‘D’ code can be sent and is used primarily for true reporting errors or monies moved to expense.

OR…

Recovery Code (880 or 830 only)

880 Voided Indemnity Benefit Check or 830 Overpayment Recovery

OR…

A Benefit Adjustment Code

OR…

A Benefit Credit Code

Questions Regarding Error #2:

BENEFIT TYPE AMOUNT PAID < PREVIOUSLY REPORTED

Proper Use of Reduced Benefit Amount Codes

Let’s take a look at Reduced Benefit Amount Codes ‘R’, ‘D’, ‘S’ and ‘N’ and discuss when they are required to be reported…

A Reduced Benefit Amount Code (RBAC) is a code that identifies the reason a Benefit Segment is missing from a transaction or

contains values less than previously reported on the last accepted SROI transaction

due to a benefit amount being decreased or reclassified (‘D’ and ‘R’ code).

Proper Use of Reduced Benefit Amount Codes

A Reduced Benefit Amount Code (RBAC) is also used when a claim is settled under another date of injury (‘S’ Code) or settled with no money (‘N’ Code).

The different types of Reduced Benefit Amount Codes (RBAC) are:

RBAC ‘R’ – Reclassification of Benefit RBAC ‘D’ – Decrease in Indemnity RBAC ‘S’ – Claim Settled Under Another Date of Injury RBAC ‘N’ – No Money Settlement

Proper Use of Reduced Benefit Amount

Code ‘R’ (Reclassification)

PROPER USE OF REDUCED BENEFIT AMOUNT CODE ‘R’

(RECLASSIFICATION)

The presence of the Reduced Benefit Amount Code ‘R’ means that one or more benefits have been reclassified after a transaction was previously reported to the Division.

There are two reasons for reclassifications:

1. All or a portion of the benefits were paid under one benefit type, andadditional information was received by the claim administrator reflecting that benefits should have been paid under a different benefit type.

2. All or a portion of the benefits were paid correctly under one benefit type but was reported to DWC incorrectly and should be reclassified to the appropriate benefit type.

This means that:

A Benefit Type Amount Paid will be less than previously reported because a portion of the money has been reclassified to another benefit type

OR…An entire Benefit Segment may no longer be present because all of the money has been reclassified to a different benefit type.

If benefits have been reclassified, the total of all Benefit Type Amounts Paid

must be equal to or greater than

the total of all amounts previously reportedor the transaction will reject.

The ‘R’ code should only be sent when:

All or part of a BTC previously reported needs to be reclassified to an entirely different BTC or to an applicable recovery code (830 – Overpayment Recovery or 880 – Voided Indemnity Check).

BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date

050TEMPORARY

TOTALIP 439.04 12/17/13 439.04 12/17/13 12/24/13 12/30/13 1 0 439.04 12/30/13

00/IP:

Scenario 1: The following scenario is an example of how to correctly reclassify benefits from one BTC to another.

The claim administrator filed an 00/IP on 12/30/13 reporting the initial payment of TT (050) benefits.

BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date

070TEMPORARY

PARTIAL02 421.45 12/17/13 421.45 12/17/13 12/17/13 1/13/14 4 0 $1703.39

SROI 02:Reduced Benefit Amount Code

R – Reclass of Benefit

The employer later notified the claim administrator that the injured worker was released to RTW light duty on 12/17/13, but the employer could not accommodate his restrictions.

The claim administrator filed a SROI 02 on 1/13/14, reclassifying all benefits from TT (050) to TP (070).

Reminder: If the MTC 02 was accepted and there was no ‘02’ in the Benefit Segment, the Benefit Segment data was not edited/loaded; therefore, benefits will not be reclassified.

The MTC 02 will need to be resubmitted to include the ‘02’ at the Benefit Level.

BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date

050TEMPORARY

TOTALIP 648.29 7/14/13 648.29 7/14/13 7/21/13 7/27/13 1 0 648.29 7/27/13

00/IP:

Scenario 2: The following scenario is an example of how to correctly reclassify a portion of monies from one BTC to another.

The claim administrator filed an 00/IP on 7/27/13 reporting the initial payment of TT (050) benefits.

The claim administrator then filed an MTC CB showing the initiation of TP (070) benefits.

MTC CB:BTC

Benefit Type

MTCGross

Weekly Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date

050TEMPORARY

TOTALCB 648.29 7/14/13 648.29 7/14/13 7/14/13 7/27/13 2 0 1296.58

070TEMPORARY

PARTIALCB 622.32 7/21/13 622.32 7/28/13 7/28/13 8/10/13 2 0 1244.64

The claim administrator later discovered that the injured worker was released to return to work on 7/21/13 but the employer could not accommodate the restrictions.

The claim administrator then filed a SROI 02 reclassifying 1 week of TT (050) benefits. SROI 02:Reduced Benefit Amount Code

R – Reclass of Benefit

BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date

050TEMPORARY

TOTAL02 648.29 7/14/13 648.29 7/14/13 7/14/13 7/20/13 1 0 648.29

070TEMPORARY

PARTIAL02 622.32 7/21/13 622.32 7/28/13 7/21/13 8/10/13 3 0 1892.93

Even though the ‘R’ Code allows the Benefit Type Amount Paid for 1 or more BTCs to decrease,

the Benefit Type Amount Paid for all BTCs+ Recovery Amount + OBT 430 Amount (Total Unallocated Prior Indemnity)

must be greater than or equal to the total of all amounts reported on the last SROI MTC.

Edits have been established to prevent the ‘R’ code from being reported in error.

The ‘R’ code must not be sent on an initial payment (IP) or an equivalent (EP, PY, AP)

because benefits are being reported for the first time and thus are not being reclassified.

The ‘R’ code can be reported on any SROI MTC after an initial payment or equivalent is submitted.

If reported on a SROI 02, an ‘02’ must be present at the Benefit Level.

Additionally, if the ‘R’ code is present on a current transaction

and the total of all benefits has not changed from the amount reported on the last accepted SROI MTC,

the transaction will reject for the error “Red Ben Amt Code R is not applicable”.

If the RBAC ‘R’ was reported in error, we can remove it from the system upon receipt of a written explanation as to why the code needs to be removed.

Requests should be submitted to the EDI Team at: [email protected]

Reduced Benefit Amount Code ‘R’

(Reclassification)

Issue Resolution Request

(IRR)

Recently Submitted Issue Resolution Request

(IRR)

In the past, once the RBAC ‘R’ was reported, it was required to be sent on all subsequent transactions for the life of the claim.

An IRR (Issue Resolution Request) was recently submitted to the IAIABC

recommending this code only be sent to reset the benefit picture on the current transaction when benefits have been reclassified.

This IRR was submitted to make the ‘R’ code usage consistent with the ‘D’ code.

APPLICABLE

Due to consistent problems experienced with keeping the ‘R’ code on subsequent transactions, FL has already removed this requirement in anticipation of the passage of the IRR.

DWC recommends that once sent the ‘R’ code should not remain on subsequent transactions, unless applicable.

Proper Use of Reduced Benefit Amount

Code ‘D’ (Decrease in Indemnity)

PROPER USE OF REDUCED BENEFIT AMOUNT CODE ‘D’

(DECREASE IN INDEMNITY)

The presence of the Reduced Benefit Amount Code ‘D’ indicates indemnity benefits have been fully or partially reducedand the benefit picture being reported on the current transaction is accurate.

The Reduced Benefit Amount Code ‘D’ can be used to explain a reduction ineither the number of benefits or the Benefit Type Amount Paid.

This means the Benefit Type Amount Paid for one or more benefit types may be either reducedor removed.

The ‘D’ code should only be sent on transactions reporting a decrease in indemnity.

It is primarily used for true reporting errors or monies that will no longer be reported

because they have been reclassified to “expense” monies behind the scenes.

Edits have been established to prevent the ‘D’ code from being reported in error.

The ‘D’ code must not be sent on an initial payment (IP) oran equivalent (EP, PY, AP)

because benefits are being reported for the first time and thus are not being decreased.

The Reduced Benefit Amount Code ‘D’ should not be present on subsequent transactions unless an additional decrease is reported.

Important:If you continue to submit transactions with what you feel is the correct Reduced Benefit Amount Code yet the transaction continues to reject (TR – Transaction Rejected),

please do not continue to send the same transaction again and again or change data to what you think will pass edits.

Instead, contact the EDI Team for assistance.

Questions RegardingReduced Benefit Amount

Code?

Error #3:

Trading Partner Paperwork Issues

NO MATCH ON DATABASE FOR INSURER FEIN (DN0006-039)

&

CLAIM ADMIN FEIN MUST BE VALID FOR INSURER (DN0187-064)

Top Errors Affecting Claim Administrators

NO MATCH ON DATABASE FOR INSURER FEIN and

CLAIM ADMIN FEIN MUST BE VALID FOR INSURER

These errors indicate the Insurer FEIN submitted on a particular transaction

does not correspond with the Insurer FEIN submitted on the Trading Partner’s paperwork (form DFS-F5-DWC-EDI-2).

This most often occurs when a TPA begins to handle claims for a new insurer.

In order for the transaction to accept,

updated Trading Partner paperwork needs to be submitted to the EDI Team

or the information will need to be corrected if submitted incorrectly.

Pursuant to 69L-56.300(2)(b):

The claim administrator shall report changes to its profile information,

at least two (2) business days prior to sending transactions to the Division, containing revised profile related information.

Often, Trading Partners will email the EDI -2 with changes and submit transactions the same night with the changed information. This will cause unnecessary rejections.

Please await confirmation from the EDI Team that the changes have been processed, prior to submitting transactions with changed information.

Helpful Hints

As a reminder, if you are amending an EDI-2 to include a self-administering insurer or self-insurer (handling their own claims),

you will also need to update the EDI-2A to include information for the new insurer or self-insurer’s mailing and physical address to avoid a postal code rejection.

Once a claim has been filed with the Division, we do not expect to see a change in the Insurer FEIN(even if the claim has been acquired)…

… If the insurer becomes insolvent and the claims are transferred to a Guaranty Association, the previous Insurer FEIN must now be reported as the Insolvent Insurer FEIN, &must match an inactive or liquidated FEIN in the Division’s database.

The new insurer would be reported as the applicable Guaranty Association.

http://fsiga.org/

Questions Regarding Error #3:

NO MATCH ON DATABASE FOR INSURER FEIN

andCLAIM ADMIN FEIN MUST BE

VALID FOR INSURER

Error #4:

NO SROI S1-7, 04, CD, VE, PY OR PD ON FILE

Top Errors Affecting Claim Administrators

NO SROI S1-7, 04, CD, VE, PY OR PD ON FILE (DN0002-063)This error occurs when the claim

administrator attempts to reinstate benefits:without a previously accepted suspension on file (currently in suspended status at DWC) OR…without a previously accepted Full or Partial Denial on file (currently in denied status at DWC)


This error also occurs when the claim administrator attempts to close out a claim (by filing an MTC FN) with the Divisionwithout previously reporting the cessation of all benefits via:Suspension (MTC S1-7)Full Denial (SROI 04) Compensable Death with No Known Dependants/Payees (CD)

(cont’d…)

Volunteer (VE)Settlement (PY with Lump Sum Payment/Settlement Code ‘SF’ or ‘SP’) or

Partial Denial

(PD with Partial Denial Code ‘A’ or ‘E’)


BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date


IP 275.00 8/20/13 275.00 8/20/13 8/20/13 9/2/13 2 0 550.00 9/1/13

00/IP:

The following scenario is an example of when this error occurs.

The injured worker did not lose more than 7 days from work and continued at his pre-injury wages.

The claim administrator filed an 00/IP on 9/1/13 reporting the initial payment of IB (030) benefits – MMI 8/19/13 with 1% PIR.

BTCBenefit

TypeMTC

Gross Weekly

Amt.

Gross Eff. Date

Net Weekly

Amt.

Net Eff. Date

Start Date

Through Date

Weeks

Days

Amt. Paid

Payment Issue Date


FN 275.00 8/20/13 275.00 8/20/13 8/20/13 9/2/13 2 0 550.00

MTC FN:

The claim administrator closed the claim and attempted to file an MTC FN on 9/9/13. The transaction rejected with the error ‘NO S1-7, 04, CD, VE, PY OR PD ON FILE’ because benefits had not been previously suspended.

In this scenario, the claim administrator should send an MTC S7 (Suspension, Benefits Exhausted).

Once the MTC S7 transaction accepts, the MTC FN can be resubmitted and

the claim will be closed in the Division’s database and will not appear on the Missing SA List.

Keep in mind, every MTC RB, ER or FN must be preceded by a corresponding S1-7, 04, CD, VE, PY or PD.

Questions Regarding Error #4


Proper Reporting of Claim Type ‘L’ (Medical Only to

Lost Time)

‘L’

Two of the most prevalent Claim Type error messages are:

Claim Type Must = I if IDDB = DOI/DOI +1 & no RTW

Claim Type Must = L if IDLT > IDDB + 7

Claim Type Must = I if IDDB = DOI/DOI +1 & no RTW meansthe Claim Type must be Indemnity/Lost Time (I) if the Initial Date Disability Began is equal to the Date of Injury or the next day, and there is no return to work date present. This implies disability is immediate and continuous.

Claim Type Must = L if IDLT > IDDB + 7 meansthe Claim Type must be ‘Became Lost Time’ (L) (Medical Only to Lost Time) if the Initial Date of Lost Time (8th Day)is greater than the Initial Date Disability Began plus 7…

This implies disability is NOT immediate and continuous.

If the claim is a ‘Medical Only’ to ‘Lost Time’ case, the Division expects the following data elements to be present on the transaction:

Claim Type ‘L’ Initial Date of Lost Time (IDLT) - 8th day of disability AND it must be greater than the IDDB + 7 days as disability is not immediate & continuous Date Claim Admin had Knowledge of Lost Time (Knowledge of 8th day) AND Initial Return to Work Date.

There are exceptions to this:

BTC 030 is first BTC, OR BTC 230 is the only BTC, OR MTC 00/PY is on file (combo filing), OR Claim was previously in a Denial Status (Full or Partial)

Today, we are not going to focus on the exceptions.

If the initial period of disability is “broken” (not immediate and continuous) –

in other words, the Initial Date of Lost Time is greater than the Initial Date Disability Began + 7 days,

the Division expects to see a Claim Type ‘L’ and an Initial Return to Work Date…

… The most common error message regarding Claim Type ‘L’ is:

‘Claim Type Must = I if IDDB = DOI/DOI +1 & no RTW’

The error message (Claim Type Must = I if IDDB = DOI/DOI +1 & no RTW) leads claim administrators to believe they must file a Claim Type ‘I’ even though the claim is an ‘MO’ to ‘LT’ case.

Claim administrators – please do not alter the Claim Type previously reported, if it does not apply to the case, in an attempt to pass an edit.

We are seeing many claim administrators receive this error

and subsequently change the Claim Type from ‘L’ to ‘I’

because the error message indicated that an ‘I’ was expected

when IDDB = DOI/DOI +1 & no RTW…

… In reality, the ‘L’ was applicable but the IRTW information was not sent so the edit was expecting a Claim Type ‘I’.

Upon inaccurately changing the Claim Type to ‘I’, claim administrators then received the error:

‘Claim Type Must = L if IDLT > IDDB + 7’

and they subsequently change the Claim Type from ‘I’ back to ‘L’ again…

… Since the IRTW information was still not reported, claim administrators were confused because it appeared they were in a “Claim Type” loop.

In reviewing the original error message (Claim Type Must = I if IDDB = DOI/DOI +1 & no RTW),

The claim administrators overlooked the last part of the error message which indicated ‘& no RTW’…

… If the claim is truly an ‘MO’ to ‘LT’ case and is not one of the exceptions,

an IRTW Date should be present on the transaction.

The claim administrator should resend the transaction with Claim Type ‘L’ (not ‘I’)

and include the IRTW Date.

If the claim is a ‘Lost Time’ case (disability is immediate and continuous), the Division is expecting the following to be present on the transaction:

Claim Type ‘I’ AND

Initial Date Disability Began (IDDB) must equal DOI or DOI +1

The following data elements are not required for Claim Type ‘I’ but if sent, will be edited: Initial Date of Lost Time - IDLT (8th day of disability). If sent, must equal IDDB + 7. Date Claim Administrator had Knowledge of Lost Time. If sent, IDLT is required.

To avoid possible rejection errors, do not send these data elements on the transaction for a true Lost Time case (Claim Type ‘I’).

If Initial Date of Lost Time and Date Claim Administrator had Knowledge of Lost Time are sent and the IDLT is greater than the IDDB + 7 (not continuous), you will receive the following error message:‘Claim Type Must = L & rpt RTW if IDLT > IDDB + 7’…

… The Claim Administrator should check the accuracy of the IDLT and correct it if disability is truly continuous,

or correct the Claim Type from ‘I’ to ‘L’ and report IRTW Date (if disability is not continuous).

Thank You

Questions

Claims EDI R3 Data Warehouse Featured

Functionality

The DWC Claims EDI Data Warehouse reflects the raw data exactly as sent by the claim administrator, with a few formatting exceptions (e.g. dates displayed in readable format).

It does not imply that the EDI filing was accepted and loaded to DWC’s internal database.

Customer Administrato

rResponsibiliti

es

Maintaining Trading Partner Accounts

The EDI Team establishes the initial data warehouse administrator account for each Trading Partner.

Afterwards, this designated “Customer Administrator” is responsible for the maintenance of their company’s account.

Maintaining Trading Partner Accounts

Access to a Trading Partner’s warehouse account should be “revoked” when an employee no longer works for your company.

Access

Denied

From the Main Menu click on Maintain My Company’s Log In Accounts.

Find the user you wish to revoke and click on their user id.

Place a check mark in the ‘Revoked’ box and a date and time revoked will be automatically added.

Click Save and Close. The user will no longer have access; however, their notes will remain as the last note author.

A user account can be deleted if it was established in error or if the employee has not entered “notes”

in the warehouse.

The “Delete this User” button will

be enabled if the criteria mentioned above is met.

Click Delete this User. The user’s account will be deleted and will no longer have access to the Claims EDI Data Warehouse.

Having trouble logging into

the Warehouse?

Password Help

If you receive this error

message…

Click on the “Forgot

your password”

link

Password Help

Enter your 9 digit

Trading Partner ID

Enter your email

address

Password Help

Password Help

Password Help

Enter your 9 digit

Trading Partner ID

Enter your User ID

Password Help

The system generates a password that is valid for 24

hours

Write down or

select/copy the

generated password

Password Help

Enter or paste the generated password

Password Help

Click “Change

my Password”

Password Help

Enter or paste the generated password

Enter a new

password and

confirm

Password Help

Password Help

POP QUIZ: If a transaction receives a TR, and I don’t understand why, what do I do next?

ANSWER:… Login to the Data Warehouse and look up the filing.

Search for an individual claimClaims EDI Data Warehouse

Search for an individual claim or query by date ranges.

Claims EDI Data Warehouse

Let’s look at a “Rejected Record”Click on EE name hyperlink to see the

details of a filing.

Note: You can sort on any column header (defaults to Div Rec’d + Date/Time Processed.)

Caution: There may be more than one page of transactions per query.

Be sure to hit the ‘Next’ key to scroll to the next page, or enter the page number you want to see.

This is a test case.

Click on Errors

There are 3 Tabs of Data

Errors are noted on the Errors Tab

SROI has 1 error; FROI rejected because SROI was not accepted.

Fatal Errors are in Red

What do you do if you do not understand the error?

Note the Element # (0066) and Error # (064)

Go to your copy of the Edit Matrix.

Most recent version is posted on DWC’s Claims EDI webpage at: http://www.myfloridacfo.com/Division/WC/EDI/Clms_EDI.htm

Click on the ‘Population Restrictions’ tab in the spreadsheet.

Find the DN # and Error # from the Error tab in the warehouse, in the 3rd column of the Population Rest.

Read the details of the error in the 5th column.

This error indicates that the Full Wages Paid for Date of Injury Indicator was sent as “N”.

However, since the Initial Date Disability Began is > than the D/A it should = “Y”.

In this example, since the rejection was for an Electronic First Report of Injury,

the claim administrator must quickly correct the error and

resubmit both the FROI 00 and SROI IP

to achieve a “TA” within the timeframes required by Division rules.

Search by Element/Error

Code

This feature allows you to research how many claims have rejected (or received a TA-FL) for a particular DN/Error combination.

**We recommend your query include a reasonable date range to avoid locking up the system.

Search by Element/Error Code



Drop Down Box with all DN/Error Combinations

As with all Search Results, you can import the results into Excel.


Let’s Look At Another

Example in the Warehouse…

The error, “BOTH FROI & SROI MUST PASS EDITS TO ACCEPT FILING” means:

• When submitting an original First Report (MTC 00), you are required to submit a corresponding SROI initial payment or equivalent, so

• If either transactions fails edits, both transactions will automatically fail for this reason.

In this example the SROI failed, so the FROI was not accepted.

All 001 Error requirements/conditions are documented in the Element Requirement Table. Note DN 0196.

Go to your copy of the Element Requirement Table.

Most recent version is posted on the Claims EDI webpage at http://www.myfloridacfo.com/Division/WC/EDI/Clms_EDI.htm

Click on SROI Elements Tab…and find DN 0196.The requirement code

‘MC’ means you must look at the SROI Conditions Tab

Click on SROI Conditions Tab…and find DN 0196.

Reminder: How to research errors?Error 001 – Element Requirement Table (including Conditions Tab)

Error 057 – Edit Matrix: Pop Rest and Duplicate Tab

Error 063 – Edit Matrix: Pop Rest, Sequencing and

Duplicate Tab

Error 117 - Edit Matrix: Pop Rest and Match Data, and Duplicate Tabs

All Other Error #’s: Pop Restrictions Tab

Some Errors for Error # 063 are found in the Sequencing Tab of the Edit Matrix.

Most Errors for Error # 057, and some for #063 and 117 are found in the Duplicate Processing Tab of the Edit Matrix.

‘TR’ Acknowledgement Code means your “transaction rejected” and must be resent. • A TR can not be fixed with an MTC 02 Change.

• Please do not write notes or ask questions related to TR records via the warehouse; instead email the EDI Team at [email protected]

Transaction Rejected Status

Reminder:

• Do not alter any factual data or Benefit/Payment information in an attempt to pass an edit.

• Thoroughly research the problem and either correct the inaccurate data and re-send the transaction,

or email the EDI team if you suspect our program/edit is at fault.

Note:

If inaccurate data results in in a CPS penalty, the claim administrator must send MTC 02 (or other appropriate MTC) to correct the data.

After the MTC is accepted, notify the CPS specialist to re-evaluate the penalty.

If you already investigated an error and still do not understand it,

please send an email to [email protected], rather than individual EDI team members.

This email copies all team members.

When sending emails, please: • Create a subject line related to the error; do not include SSN’s;

• Provide the JCN or your Claim number;

• Provide the MTC and Received Date; &

•Clarify which error in which table you do not understand.

Note: We can not address questions relative to problems in your company’s or vendor’s software.

The Claims EDI Team receives approximately 50+ emails per day;

therefore, if you have not received an answer or some acknowledgement of your emailed question within 2 business days, please resubmit.

Responding to Reconciliation (Non-

Fatal) Errors

TA-FL’s

FL’s program also contains edits that identify data considered to be “suspect”, but

does not warrant rejecting the filing.

• These edits generate “Reconciliation Errors”

Reconciliation (Non-Fatal) Errors

‘Reconciliation Errors’ are assigned an Acknowledgement Code of ‘TA’ on the AKC;

• But are displayed as ‘TA-FL’ in the data warehouse.

• FL does not use ACK Code ‘TE’ – Transaction Accepted with Errors.


FL also does not accept MTC ‘CO’ – Correction.

• Instead, non-fatal ‘TA-FL’ errors are addressed via the data warehouse in conjunction with MTC 02 - Change (or other applicable MTC/response).


DWC sends email notification (next day) to the claim administrator re: the posting of all non-fatal errors in the data warehouse.

• Claim administrators should rectify the error on or before 21 days after the date the error was posted to the data warehouse (see Rule 69L-56.300(1)(i), F.A.C.)


TA-FL errors will not be identified on the AKC or in the warehouse if the transaction is rejected (TR).

• Only one AKC code can be returned on the AKC.

• Therefore, you may receive a TA-FL error after rectifying a TR.


How do I quickly find all my TA-FL

error messages to see what needs to

be addressed?


Responding to Reconciliation ErrorsOn the Search page you can select the Processing Result to display only OPEN TA-FL errors.

Alternatively, you can retrieve all OPEN TA-FL’s (for a specified time period) by selecting ‘Open Reconciliation Errors Listing’ under ‘Notification Listings’.

There is also a feature in the warehouse that allows you to generate a listing of all TA-FL errors by type and the exact claims that received those errors.


The Claims EDI (TA-FL) Errors Detail Report was added in response to a suggestion from a Trading Partner.

From the Main Menu, first select ‘Report Cards and

Statistical Reports’

Then select, ‘Generate TA-FL Detail Report’.

Fill in your search criteria (date range, office

location )

You will receive a ‘Claims EDI (TA-FL) Errors Detail Report’. Results are presented in EE Name order (alpha) and then by TA-FL error # (ascending).

Summaries of TA-FL errors by count, form type, and error # are provided at the end of the report:

Now let’s return to looking up TA-FL’s via the Search screen…

Responding to Reconciliation Errors

On the Search Results screen you can see that there are internal reconciliation errors that are open.


If the last note author is blank or is an EDI Team Member, then the claim administrator knows they must address the error, if it is still open.


If the last note author is the claim administrator, then an EDI Team Member will review the response and determine if the error can be closed.

Angie Adjuster


Reconciliation Errors are in Yellow

Claim Admin’s should check the error for which they are typing a response.

Responding to Reconciliation ErrorsIf there is more than 1

error, you must Select each error and respond

separately.

Claim Admin’s must type a response to the selected error message to advise how the error will be rectified.


DWC response

Claim Admin response

An EDI Team member will type a response back to the Claim Admin.


Claim Admin response

The Claim Admin can check the box “Intend to send 02 transaction to correct”, to indicate an 02 will be sent.



When the error has been rectified an EDI Team Member will close the error.

On the Search Results screen you can see the last person to respond to a message and the status of the errors. The overall error status will remain open until ALL errors have been addressed and closed.


Angie Adjuster

If you would like to export the data into an excel spreadsheet, click on the “Save results as tab delimited text file” , click “Save” , change the file extension to “.xls”.

Responding to Reconciliation ErrorsIf the same Reconciliation Error is generated on more than 1 transaction for the same claim

and the error was fixed via an MTC 02:• You only need to respond on the most recent TA-FL;

• An EDI Team member will close all identical errors for earlier transactions.


Note:

If the Reconciliation Error generated requires an MTC 02 to correct data in the Benefits, Payment, ACR, OBT or Recovery segment….


… an MTC 02 must be included in the Benefits segment(s), or the changes in the segment(s) will not be edited or loaded.


If MTC 02 is not sent in the Benefits segment, the following statement will appear in blue above the Benefits segment in the Data Warehouse…


If you send an 02 to change the Payment Issue Date of the initial payment (a/k/a Date 1st Payment Mailed) …,


… an MTC 02 must be sent in the Benefits segment, AND

• A Payments segment must be sent with the corrected date.

•This date will not be corrected from the Benefits segment.

Overpayment filings:

Filings that only have an overpayment and no other reconciliation error associated with it will reflect ‘OVER PMT’ in the Error Status column.

However, if the overpayment is related to a > than Max Parameter edit on a particular benefit a TA-FL error will be received.

• Overpayment only = OVER PMT

• O/P + non-reconciled non-fatal error = OPEN

O/P’s are currently still posted to the ‘Errors’ tab, but DWC does not require a response to these ‘errors’.

At some point in the future, O/P’s will be identified in a “Notification Listing’ via the Main Menu.

In addition to the ‘OVER PMT’ Error

Status, non-fatal ‘PERM TOT’ errors are also

posted in the warehouse to identify

possible PT Errors.

…Filings with non-fatal reconciliation errors that pertain to PT cases are identified as ‘PERM TOT’ in the Error Status column. **Sort by Error Status

DWC’s PT Section also receives internal reports regarding filing discrepancies, and may solicit responses from the Claim Administrator via letter or email.

Report Card

Report Card(SA Rankings)

After numerous requests from Trading Partners, the Division has updated the EDI Report Card to include “Missing SA Rankings”.


When a Trading Partner runs the Report Card, a comparison can be made to the industry with regards to Missing SAs.


The EDI Team has modified the Report Card to rank those SAs that are late as well as missing.

“Missing” SA does not necessarily mean an SA is late. “Missing” means the Division was expecting an SA, but an SA was not accepted by the SA’s due date.

For example, if the injured worker’s date of accident is 1/1/12, the SA is considered missing if it was not accepted on or before 7/1/12 (due date).

Missing SA(Sub-Annual)

An MTC SA is considered late if it was not accepted on or before 30 days after the SA’s due date.

For example, if the injured worker’s date of accident is 1/1/12, the SA is considered late if it was not accepted on or before 8/1/12.

Missing SA(Sub-Annual)


Listed below is an example of how the new Missing SA Rankings will appear on the Report Card:

Report Card(Reoccurring Errors)

Along with the new Missing SA Rankings, the Division has also included reoccurring errors on the Report Card.

The report will list the top 10 reoccurring errors, per MTC, for the date range selected.

Report Card(Reoccurring Errors)

Listed below is an example of how reoccurring errors will appear on the Report Card:

Report Card

The two new reports can be found at the bottom of the report card below the “Top 10 Reject Errors”.

Follow the steps on the upcoming slides to retrieve this report…

Report Card

Log into the Warehouse

Report Card

Click on Report Cards &

Statistical Reports

Report Card

Click on Generate Claims

EDI Report Cards

Report Card

Select the Date Range

& Filing Type/MTC

Top 10 Reoccurring Errors

Missing SA Rankings

Rejected But Not

Successfully Resubmitted

List

Rejected Not Resubmitted ListEDI DWC-1 equivalents

(e.g., 00/IP, 04, etc.) that reject and have not been successfully resubmitted will be included when this query is run. • Claim administrators can and should check this list frequently and resubmit any outstanding rejections.

Rejected Not Resubmitted ListEmail the EDI Team if the

EDI DWC-1 was re-filed (TA’d) under a different SSN or DOI from that on the Rejected Not Resubmitted List.

• Provide the EE’s Name, File # and Div Rec’d Date for the rejected filing, so the transaction(s) can be excluded from the listing.

Rejected Not Resubmitted ListAlso notify the EDI Team if

an EDI DWC-1 that rejected was actually sent in error and will never be re-sent (e.g., Medical Only), so the transaction(s) can be removed from the list.

The Rejected Not

Resubmitted listing is

updated every Saturday.

Claim Admin Selects Rejected Not Resubmitted List

All outstanding TR’s will be returned

(EDI DWC-1, SA & FN)

The Rejected But Not Resubmitted Listing

includesIncomplete EDI DWC-1

filings (i.e. 00 sent without the

SROI)

Other Features in the Claims EDI

Data Warehouse

Quick Search: If your query returns a listing of various filings, and you want to drill down to just the filings for one EE in the list,

Click on a BOLDED hyperlink to obtain historical filing information for the EE.

Quick Search Hyperlinks Partner ID: Returns all filings found for that EE Name;

DAN (if applicable): Returns all filings found for that DAN;

Claim Admin Claim #: Returns all filings found for that claim #; and

JCN: Returns all filings for JCN.

For example, click on the ‘Partner ID’ for the desired EE:

All filings for DOI’s, Claim #’s, JCN’s associated with that EE Name you have sent to DWC will be presented.

Search by MTC/Filing Type

You can retrieve all 00/IP filings, FROI 04 filings, etc., and further narrow down the results by selecting a date range and processing result (e.g., Rejected).

On the main ‘Search” screen, click on any MTC/MTC combo from the drop down menu under “Filing Type’.

In this example, all rejected 00/IP’s for the selected time period are presented.

Indicator of Last Viewed Record

To help keep track of previously viewed records (such as when you are going down a list of various filings for the same or different EE), the EE name hyperlink will change colors (blue to purple).

When you return to the list, the ‘purple’ will indicate which Henny Penny filing you’ve already viewed.

SSN has been masked for security reasons (along with EE address, nature of injury, and accident description) for confidential profiles.

• DAN will be displayed.

Social Security Number (SSN)

Division Assigned Number (DAN)

If the filing consists of both FROI and SROI tabs, the data warehouse view will default/open to the SROI tab first.

Helpful Hint

ALL questions, either Business or Technical, should be sent via email

to [email protected]

This email address is copied to all members of the EDI team. It is the quickest and most efficient way for

us to respond to your concerns.

Questions?

Claims EDI Release 3 Training February 11 – 12, 2014 Florida Division of Workers’ Compensation.

Documents

edi transactions

fl edi data warehouse

use of fls edi data

claims edi release

edi team member antrine

data entry capability

edi team members linda

national standard edi