Florida Division of Workers’
Compensation
Claims EDI Release 3 Training
February 11 – 12, 2014
EDI Team Members
Linda Yon,
Bureau Chief, Bureau of Data
Quality & Collection
Tonya Granger,
System Project Administrator
(EDI Coordinator)
(cont’d…)
2
EDI Team Members
Michelle Carter,
Operations Review Specialist
Riley Pool,
EDI Team Member
Megan Fox,
EDI Team Member
(cont’d…)
3
EDI Team Members
Laura Cotner,
EDI Team Member
Antrine Long,
EDI Team Member
4
Housekeeping
Handouts Include:
 Agenda
 Copies of Slides
 Quick Code References
 Acronym List
Breaks and Lunches
Note Cards for Questions
5
Audience Participation
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.
6
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.
7
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.
8
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.
9
Claim
Administrator
Data Entry
10
Claims EDI Data Warehouse
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.
11
Claims EDI Data Warehouse
Claim Administrator Data Entry
This data entry capability can
be utilized by small claim
administrators for filing all EDI
transactions.
12
Claims EDI Data Warehouse
Claim Administrator Data 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.
13
Claims EDI Data Warehouse
Claim Administrator Data 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…
14
Claims EDI Data Warehouse
Claim Administrator Data Entry
If you are interested in providing
any feedback on this, please see
me (Linda Yon) at one of our
breaks during this training.
15
DWC’s Website
URL has changed
to:
http://www.myfloridacfo.com/Division/WC/
16
Effective Friday 2-14-14, if you have an
old page bookmarked, you will be
re-routed to the new Home Page.
17
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…)
18
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)
19
Name That MTC
20
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?
21
MTC ER
Employer Reinstatement
Because the employer chose to pay
IIB benefits.
22
Scenario
 Claim administrator pays days 1-7 of
disability to the injured worker
What MTC should be filed?
23
NOTHING DUE
Injured worker has not been disabled for 8
or more days.
24
Scenario
 FROI 04 filed
 Denial is rescinded but no indemnity is
due at time of rescission
What MTC should be filed?
25
SROI 02
Change
Because no benefits are being
initiated at this time.
26
Scenario
 00/IP filed reporting TT benefits
 TT benefits end and TP benefits begin
and AWW/CR was also amended
What MTC should be filed?
27
MTC CB
Change in Benefit Type
Both 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.
28
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
What MTC should be filed?
29
MTC RB
Reinstatement of Benefits
Because indemnity has been paid
after a suspension.
30
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
What MTC should be filed?
31
MTC CA
Change in Amount
Net Weekly Amount for PT Supps
(BTC 021) changes every January.
32
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
due
What MTC should be filed?
33
MTC S7
Suspension –
Benefits Exhausted
34
Scenario
 MTC FN filed
 Injured worker’s condition worsened,
claim reopened because new period
of TT benefits needs to be reported
What MTC should be filed?
35
MTC RB
Reinstatement of Benefits
TT paid after claim was closed.
36
Scenario
 00/IP filed
 Claim is further investigated and
subsequently denied
What MTC should be filed?
37
SROI 04
Full Denial
FL requires a SROI 04 (Full Denial) if
indemnity had been previously
reported.
38
Scenario
 Compensable death and
dependants need to be paid
What MTC should be filed?
39
00/IP
00/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.
40
Scenario
 Permanent Total benefits are currently
being paid to injured worker
 Claim administrator now has knowledge
that PT Supp benefits should be
commenced
What MTC should be filed?
41
MTC AB
Add Concurrent Benefit Type
42
Scenario
 Benefit Period Start Date of a BTC
currently on file with DWC was
incorrectly reported
What MTC should be filed?
43
SROI 02 Change
(with an ‘02’ in the Benefit Segment)
(MTC CB or RB is not required)
44
Scenario
 MTC AQ (Acquisition) accepted
 New claim administrator reports initial
payment of indemnity benefits (not a
lump sum payment or settlement)
What MTC should be filed?
45
MTC AP
Acquired/Payment
Initial payment by acquiring claim
administrator.
46
Scenario
 00/IP filed
 Claim Administrator determined the
Benefit Type on the initial payment
(IP) was wrong
What MTC should be filed?
47
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’.
48
Scenario
 00/IP filed
 Claim Administrator determined the
employer continued salary in lieu of
compensation and the MTC and
Benefit Type were wrong
What MTC should be filed?
49
MTC 01 Cancel
00/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.50
MTC 01 Cancel
We recognize there are other ways to
correct the benefit picture by reclassifying
benefits; however, this could cause
sequencing issues later in the claim.
51
Claims EDI Data Warehouse
Insurer Access View
52
Claims EDI Data Warehouse
Insurer Access View
The Division recently enhanced the
Claims EDI Data Warehouse to include
an “Insurer View” feature.
53
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.
54
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.
55
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.
56
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.
57
To request access to the Insurer View,
please contact a member of the EDI Team
at claims.edi@myfloridacfo.com
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.
58
Questions
59
Clarification of IAIABC 2014 R3
Implementation Guide Change
60
Latest Return to Work
Status Date
(formerly Current Return to
Work Date)
61
Latest Return to Work Status Date
(formerly Current Return to Work Date)
Current Date Disability Began,
Current Date Last Day Worked and
Current Return to Work Date
were originally defined to relate to a
“subsequent period of disability”.
62
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…
63
 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…
64
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…
65
… 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.
66
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).
67
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
68
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.
69
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.
70
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.
71
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.
72
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
73
… 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.
74
The IAIABC Claims Committee
also recently adopted another
DP Rule change for
Initial Return to Work Date and
FL has amended edits as
follows…
75
New FROI 02 (Change) Edit
76
New Edit
FROI 02 (Initial RTW)
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 Date
 Return to Work Type Code
 Physical Restrictions Indicator and
 Return to Work with Same Employer
Indicator (if RTW Type Code = ‘A’ (Actual)
77
New Edit
FROI 02 (Initial RTW)
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.
78
New Edit
FROI 02 (Initial RTW)
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:
79
New Edit
FROI 02 (Initial RTW)
 Return to Work Type Code
 Physical Restrictions Indicator and
 Return to Work with Same Employer
Indicator (if RTW Type Code = ‘A’ (Actual)
This information must be reported on a FROI
02.
80
FROI 02
(Reporting Initial RTW Information)
The FROI 02 transaction is due
14 days after the claim
administrator’s notification of the
change.
81
New Edit
FROI 02 (Initial RTW)
Effective 6/1/2014, a SROI 02
will no longer be accepted to
initially report, or update, the
Initial Return to Work
information.
82
Claim Scenario
Let’s take a look at an example of the
Latest Return to Work Status Date
(formerly Current Return to Work Date).
83
Example:
6/28/13 = DOI & Initial Date Disability Began
7/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)
84
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)
85
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…
86
… 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.
87
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.
88
POP QUIZ:
What MTC is to be used to
report an injured worker’s
IRTW information if benefits
may continue in the future?
89
ANSWER:
FROI 02
(Initial Return to Work)
90
Questions Regarding
Latest Return to Work Status Date?
91
Suspensions
92
Suspensions
Suspension transactions should only be
sent when all indemnity benefits have
been suspended
and no further indemnity benefits will be
paid.
MTC
S1-S8
93
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 .
EVENT
94
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.
95
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.
96
Are Suspensions an
“Event” Benefit Segment,
or
“Sweep” Benefit Segment?
97
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.
98
MTC S1
(Suspension – RTW)
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.
99
An MTC S1 should not be sent prematurely
(before the last indemnity payment has
been reported on the transaction).
100
When an MTC S1 is sent prematurely,
the claim administrator would be
required to reinstate benefits prior to
submitting the next applicable
transaction.
101
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.
102
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
103
MTC S1 vs. FROI or SROI 02
(Reporting RTW Information)
104
FROI 02
Reporting Initial RTW
Information
105
FROI 02
(Reporting Initial RTW Information)
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.
106
FROI 02
(Reporting Initial RTW Information)
The FROI 02 transaction is due
14 days after the claim
administrator’s notification of the
change.
107
SROI 02
Reporting Latest RTW
Status Date Information
108
SROI 02
(Reporting Latest RTW Status Date Information)
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…
109
SROI 02
(Reporting Latest RTW Status Date Information)
… 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.
110
FROI or SROI 02
(Reporting RTW Information)
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…
111
FROI or SROI 02
(Reporting RTW Information)
… 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.
112
… 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).
113
Correcting Suspension
Information
114
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 again
with the correct MTC suspension
code…
115
Correcting Suspension Information
… 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.
116
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’…
117
… The Division’s program will not
allow another suspension MTC to be
sent
with a different ‘Suspension Effective
Date’
without an intervening reinstatement.
118
If previous suspension transactions have
been accepted
and 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.
First
Sx Eff Date
7/15/12
X
Second
Sx Eff Date
8/7/12
SROI 02
Sx Eff Date
8/10/12
119
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.
120
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.
121
Data was not edited/loaded:
Data was edited/loaded:
122
What MTC is used to
correct an injured
worker’s IRTW
information previously
reported?
123
ANSWER:
FROI 02
(Change)
124
Questions
125
Reinstatement of Benefits
(MTC RB)
126
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.
127
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’
128
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.
129
If a SROI 02 is used to report a
Denial Rescission Date when
benefits 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.
130
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.
131
New Edit
MTC RB (Reinstatement)
132
New Edit
MTC RB (Reinstatement)
In the past, the EDI Team has received
many requests from claim administrators
to have reinstatements removed from
our internal database due to sequencing
issues that occurred later on in the
claim…
133
… 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)
134
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…
New
MTC RB
Edit
135
For Division Received Dates on
or after 2/1/2014, if MTC = RB,
the most recent Benefit Period Through
Date on the RB
must be greater than the most recent
Benefit Period Through Date on the
accepted MTC S1-S7, PD or SROI 04
which precedes the RB.
Error message:
‘RB N/A benefit period has not advanced’
136
Questions
137
Top Errors Affecting Claim
Administrators and How to
Correct Them
138
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…
139
Error #1:
NBR OF BENEFITS SHOULD NOT BE
> WHAT IS ON FILE
140
Top Errors Affecting Claim Administrators:
NBR OF BENEFITS SHOULD NOT BE
> WHAT IS ON FILE (0288-044)
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…
141
On 8/23/12, the claim administrator
submitted a 00/IP and reported the initial
payment of TT (050) benefits.
Gross
BTC Benefit Type MTC Weekly
Amt.
050
TEMPORARY
TOTAL
IP
128.00
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
8/7/12
128.00
8/7/12
8/17/12
8/23/12
Weeks Days Amt. Paid
1
0
128.00
Payment
Issue Date
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.
142
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 because
new benefits cannot be introduced on a
suspension.
Gross
BTC Benefit Type MTC Weekly
Amt.
030
PERM PART
SCHEDULED
050
TEMPORARY
TOTAL
S7
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
48.00
12/27/12
48.00
12/27/12
12/27/12
2/6/13
6
0
288.00
12/31/12
128.00
8/7/12
128.00
8/7/12
8/10/12
12/16/12
18
3
2380.80
12/28/12
Weeks Days Amt. Paid
Payment
Issue Date
143
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.
144
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…
 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
145
Let’s take a look at another example
of when the error occurs for ‘NBR OF
BENEFITS SHOULD NOT BE >
WHAT IS ON FILE’…
146
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’,
Drop
which allowed the TP (070)
Off
segment to drop off…
147
Current benefit picture on file at DWC:
Gross
BTC Benefit Type MTC Weekly
Amt.
TEMPORARY
266.68
050
TOTAL
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
Benefit
Weeks Days Amt. Paid Payment
Issue Date
1/1/13
266.68
1/1/13
1/1/13
2/11/13
6
0
1600.08
070
TEMPORARY
PARTIAL
256.00
2/12/13
256.00
2/12/13
2/12/13
3/25/13
6
0
1536.00
030
PERM 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 *
Benefit Information:
Reduced Benefit Amount Code D – DECREASE INDEM
Gross
BTC Benefit Type MTC Weekly
Amt.
TEMPORARY
02 266.68
050
TOTAL
PERM PART
030
100.01
SCHEDULED
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
Benefit
Weeks Days Amt. Paid Payment
Issue Date
1/1/13
266.68
1/1/13
1/1/13
2/11/13
6
0
1600.08
7/1/13
100.01
7/1/13
7/1/13
8/11/13
6
0
600.06
148
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.
MTC SA:
Gross
BTC Benefit Type MTC Weekly
Amt.
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
Benefit
Weeks Days Amt. Paid Payment
Issue Date
050
TEMPORARY
TOTAL
266.68
1/1/13
266.68
1/1/13
1/1/13
2/11/13
6
0
1600.08
070
TEMPORARY
PARTIAL
256.00
2/12/13
256.00
2/12/13
2/12/13
3/25/13
6
0
1536.00
030
PERM PART
SCHEDULED
100.01
7/1/13
100.01
7/1/13
7/1/13
8/11/13
6
0
600.06
149
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).
150
True or False
New Benefits Type Codes reported
for the first time can appear on an
MTC SA (Sub-Annual)
Or
FN (Final).
151
ANSWER:
FALSE
New BTCs must be added via
an MTC IP, EP, CB, RB, AB,
PY, ER or AP.
152
Reporting BTCs Accidentally
Left Off Transactions
153
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.
154
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…
155
…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.
156
Once the transaction rejects, send an
email to:
claims.edi@myfloridacfo.com
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.
157
Questions Regarding Error #1?
NBR OF BENEFITS SHOULD NOT BE
> WHAT IS ON FILE
158
Error #2:
BENEFIT TYPE AMOUNT PAID
< PREVIOUSLY REPORTED
159
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 was
previously reported on the
last accepted transaction.
160
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.
161
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.
162
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.
163
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…
164
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…
165
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…
166
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
167
Questions Regarding Error #2:
BENEFIT TYPE AMOUNT PAID <
PREVIOUSLY REPORTED
168
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…
169
Proper Use of Reduced Benefit Amount
Codes
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).
170
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).
171
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
172
Proper Use of
Reduced Benefit Amount Code
‘R’
(Reclassification)
173
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.
174
There are two reasons for
reclassifications:
1. All or a portion of the benefits were
paid under one benefit type, and
additional information was received
by the claim administrator reflecting
that benefits should have been paid
under a different benefit type.
175
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.
176
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.
177
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
reported
or the transaction will reject.
178
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).
179
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.
00/IP:
Gross
BTC Benefit Type MTC Weekly
Amt.
050
TEMPORARY
TOTAL
IP
439.04
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
12/17/13
439.04
12/17/13
12/24/13
12/30/13
Weeks Days Amt. Paid
1
0
439.04
Payment
Issue Date
12/30/13
180
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).
SROI 02:
Reduced Benefit Amount Code R – Reclass of Benefit
Gross
BTC Benefit Type MTC Weekly
Amt.
070
TEMPORARY
PARTIAL
02
421.45
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
12/17/13
421.45
12/17/13
12/17/13
1/13/14
Weeks Days Amt. Paid
4
0
$1703.39
Payment
Issue Date
181
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.
182
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.
00/IP:
Gross
BTC Benefit Type MTC Weekly
Amt.
050
TEMPORARY
TOTAL
IP
648.29
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
7/14/13
648.29
7/14/13
7/21/13
7/27/13
Weeks Days Amt. Paid
1
0
648.29
Payment
Issue Date
7/27/13
183
The claim administrator then filed an
MTC CB showing the initiation of TP
(070) benefits.
MTC CB:
Gross
BTC Benefit Type MTC Weekly
Amt.
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
Weeks Days Amt. Paid
050
TEMPORARY
CB
TOTAL
648.29
7/14/13
648.29
7/14/13
7/14/13
7/27/13
2
0
1296.58
070
TEMPORARY
CB
PARTIAL
622.32
7/21/13
622.32
7/28/13
7/28/13
8/10/13
2
0
1244.64
Payment
Issue Date
184
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
Gross
BTC Benefit Type MTC Weekly
Amt.
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
Weeks Days Amt. Paid
050
TEMPORARY
TOTAL
02
648.29
7/14/13
648.29
7/14/13
7/14/13
7/20/13
1
0
648.29
070
TEMPORARY
PARTIAL
02
622.32
7/21/13
622.32
7/28/13
7/21/13
8/10/13
3
0
1892.93
Payment
Issue Date
185
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.
186
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.
187
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.
188
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”.
189
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: claims.edi@myfloridacfo.com
190
Reduced Benefit Amount Code ‘R’
(Reclassification)
Issue Resolution Request
(IRR)
191
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.
192
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.
193
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.
APPLICABLE
194
Proper Use of
Reduced Benefit Amount Code
‘D’
(Decrease in Indemnity)
195
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
reduced
and the benefit picture being reported
on the current transaction is accurate.
196
The Reduced Benefit Amount Code ‘D’
can be used to explain a reduction in
either 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 reduced
or removed.
197
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.
198
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) or
an equivalent (EP, PY, AP)
because benefits are being reported for
the first time and thus are not being
decreased.
199
The Reduced Benefit Amount
Code ‘D’ should not be present on
subsequent transactions unless an
additional decrease is reported.
200
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.
201
Questions Regarding
Reduced Benefit Amount Code?
202
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)
203
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).
204
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.
205
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.
206
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.
207
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.
208
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)…
209
… 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.
210
The new insurer would be reported as
the applicable Guaranty Association.
211
Questions Regarding Error #3:
NO MATCH ON DATABASE FOR
INSURER FEIN
and
CLAIM ADMIN FEIN MUST BE VALID
FOR INSURER
212
Error #4:
NO SROI S1-7, 04, CD, VE, PY OR PD
ON FILE
213
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)
214
NO SROI S1-7, 04, CD, VE, PY OR PD
ON FILE
This error also occurs when the claim
administrator attempts to close out a claim
(by filing an MTC FN) with the Division
without 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…)
215
NO SROI S1-7, 04, CD, VE, PY OR PD
ON FILE
 Volunteer (VE)
 Settlement
(PY with Lump Sum Payment/Settlement
Code ‘SF’ or ‘SP’) or
 Partial Denial
(PD with Partial Denial Code ‘A’ or ‘E’)
216
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 preinjury 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.
00/IP:
Gross
BTC Benefit Type MTC Weekly
Amt.
030
PERM PART
SCHEDULED
IP
275.00
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
8/20/13
275.00
8/20/13
8/20/13
9/2/13
Weeks Days Amt. Paid
2
0
550.00
Payment
Issue Date
9/1/13
217
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.
MTC FN:
Gross
BTC Benefit Type MTC Weekly
Amt.
030
PERM PART
SCHEDULED
FN
275.00
Gross Eff.
Date
Net
Weekly
Amt.
Net Eff.
Date
Start Date
Through
Date
8/20/13
275.00
8/20/13
8/20/13
9/2/13
Weeks Days Amt. Paid
2
0
Payment
Issue Date
550.00
218
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.
219
Keep in mind, every MTC RB,
ER or FN must be preceded by
a corresponding S1-7, 04, CD,
VE, PY or PD.
220
Questions Regarding Error #4
NO SROI S1-7, 04, CD, VE, PY OR PD
ON FILE
221
Proper Reporting of Claim Type ‘L’
(Medical Only to Lost Time)
‘L’
222
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
223
Claim Type Must = I if IDDB = DOI/DOI
+1 & no RTW means
the 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.
224
Claim Type Must = L if IDLT > IDDB + 7
means
the 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.
225
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.
226
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.
227
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…
228
… The most common error message
regarding Claim Type ‘L’ is:
‘Claim Type Must = I if IDDB = DOI/DOI
+1 & no RTW’
229
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.
230
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…
231
… In reality, the ‘L’ was applicable but
the IRTW information was not sent so
the edit was expecting a Claim Type
‘I’.
232
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…
233
… Since the IRTW information was
still not reported, claim administrators
were confused because it appeared
they were in a “Claim Type” loop.
234
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’…
235
… 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.
236
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
237
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’).
238
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’…
239
… 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).
240
Questions
Thank You
241
Claims EDI R3 Data
Warehouse
Featured Functionality
242
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.
243
Customer
Administrator
Responsibilities
244
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.
245
Maintaining Trading Partner Accounts
Access to a Trading Partner’s
warehouse account should be “revoked”
when an employee no longer works for
your company.
246
From the Main Menu click on Maintain
My Company’s Log In Accounts.
247
Find the user you wish to revoke and
click on their user id.
248
Place a check mark in the ‘Revoked’ box
and a date and time revoked will be
automatically added.
249
Click Save and Close. The user will no longer
have access; however, their notes will remain
as the last note author.
250
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.
251
Click Delete this User. The user’s account will
be deleted and will no longer have access to
the Claims EDI Data Warehouse.
252
Having trouble
logging into the
Warehouse?
253
Password Help
If you receive this
error message…
254
Password Help
Click on the
“Forgot your
password” link
255
Password Help
Enter your email
address
Enter your 9 digit
Trading Partner ID
256
Password Help
257
Password Help
258
Password Help
Enter your
User ID
Enter your 9 digit
Trading Partner ID
259
Password Help
Write down or
select/copy
the generated
password
The system generates a password
that is valid for 24 hours
260
Password Help
Enter or paste
the generated
password
261
Password Help
Click “Change
my Password”
262
Password Help
Enter or paste
the generated
password
Enter a new
password
and confirm
263
Password Help
264
POP QUIZ:
If a transaction
receives a TR, and I
don’t understand why,
what do I do next?
265
ANSWER:
… Login to the Data
Warehouse and
look up the
filing.
266
267
Claims EDI Data Warehouse
Search for an individual claim
268
Claims EDI Data Warehouse
Search for an individual claim or query by date ranges.
269
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.)
270
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.
271
There are 3 Tabs of Data
This is a test
case.
Click on Errors
272
Errors are noted on the Errors Tab
SROI has 1 error; FROI rejected
because SROI was not accepted.
273
Fatal Errors are in Red
274
What do you do if you do
not understand the error?
Note the Element # (0066)
and Error # (064)
275
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
276
Click on the ‘Population Restrictions’
tab in the spreadsheet.
277
Find the DN # and Error # from the
Error tab in the warehouse, in the
3rd column of the Population Rest.
278
Read the details of the error in the 5th
column.
279
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”.
280
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.
281
Search by
Element/Error Code
282
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.
283
Search by Element/Error Code
284
Search by Element/Error Code
Drop Down
Box with all
DN/Error
Combinations
285
Search by Element/Error Code
As with all Search Results, you can import
the results into Excel.
286
Let’s Look At
Another Example in
the Warehouse…
287
288
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.
289
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.
290
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
291
Click on SROI Elements Tab…and
The requirement code ‘MC’
find DN 0196.
means you must look at the
SROI Conditions Tab
292
Click on SROI Conditions Tab…and
find DN 0196.
293
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
294
Some Errors for Error # 063 are found in the
Sequencing Tab of the Edit Matrix.
295
Most Errors for Error # 057, and some for
#063 and 117 are found in the Duplicate
Processing Tab of the Edit Matrix.
296
Transaction Rejected Status
‘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 claims.edi@myfloridacfo.com
297
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.
298
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.
299
If you already investigated an error
and still do not understand it,
please send an email to
claims.edi@myfloridacfo.com,
rather than individual EDI team
members.
This email copies all team
members.
300
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.
301
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.
302
Responding to Reconciliation
(Non-Fatal) Errors
TA-FL’s
303
Reconciliation (Non-Fatal) Errors
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”
304
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.
305
Reconciliation (Non-Fatal) 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).
306
Reconciliation (Non-Fatal) Errors
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.)
307
Reconciliation (Non-Fatal) Errors
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.
308
Reconciliation (Non-Fatal) Errors
How do I quickly find all
my TA-FL error
messages to see what
needs to be addressed?
309
Responding to Reconciliation Errors
On the
Search page
you can
select the
Processing
Result to
display only
OPEN TA-FL
errors.
310
Alternatively, you can retrieve all
OPEN TA-FL’s (for a specified time
period) by selecting ‘Open
Reconciliation Errors Listing’ under
‘Notification Listings’.
311
Reconciliation (Non-Fatal) Errors
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.
312
The Claims EDI (TA-FL)
Errors Detail Report was
added in response to a
suggestion from a Trading
Partner.
313
From the Main Menu, first select
‘Report Cards and Statistical Reports’
314
Then select,
‘Generate TA-FL Detail Report’.
315
Fill in your search criteria
(date range, office location )
316
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).
317
Summaries of TA-FL errors by
count, form type, and error # are
provided at the end of the report:
318
Now let’s return to looking up
TA-FL’s via the Search screen…
319
Responding to Reconciliation Errors
On the Search Results screen you
can see that there are internal
reconciliation errors that are open.
320
Responding to Reconciliation Errors
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.
321
Responding to Reconciliation Errors
Angie
Adjuster
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.
322
Responding to Reconciliation Errors
Reconciliation Errors are in Yellow
323
Responding to Reconciliation Errors
If there is more than 1 error, you
must Select each error and
respond separately.
Claim Admin’s should check the error for
which they are typing a response.
324
Responding to Reconciliation Errors
Claim Admin’s must type a response to the selected error
message to advise how the error will be rectified.
325
Responding to Reconciliation Errors
An EDI Team member will type a response
back to the Claim Admin.
DWC response
Claim Admin response
326
Responding to Reconciliation Errors
The Claim Admin can check the box “Intend to
send 02 transaction to correct”, to indicate an 02
will be sent.
Claim Admin response
327
Responding to Reconciliation Errors
When the error has been rectified an EDI
Team Member will close the error.
328
Responding to Reconciliation Errors
Angie Adjuster
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.
329
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”.
330
Responding to Reconciliation Errors
If 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.
331
Responding to Reconciliation Errors
Note:
If the Reconciliation Error generated
requires an MTC 02 to correct data in
the Benefits, Payment, ACR, OBT or
Recovery segment….
332
Responding to Reconciliation Errors
… an MTC 02 must be included in the
Benefits segment(s), or the changes in
the segment(s) will not be edited or
loaded.
333
Responding to Reconciliation Errors
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…
334
Responding to Reconciliation Errors
If you send an 02 to change the
Payment Issue Date of the initial
payment (a/k/a Date 1st Payment
Mailed) …,
335
Responding to Reconciliation Errors
… 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.
336
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.
337
• Overpayment only = OVER PMT
• O/P + non-reconciled non-fatal
error = OPEN
338
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.
339
In addition to the
‘OVER PMT’ Error Status,
non-fatal ‘PERM TOT’ errors
are also posted in the
warehouse to identify possible
PT Errors.
340
…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
341
DWC’s PT Section also receives
internal reports regarding filing
discrepancies, and may solicit
responses from the Claim
Administrator via letter or email.
342
Report Card
343
Report Card
(SA Rankings)
After numerous requests from
Trading Partners, the Division has
updated the EDI Report Card to
include “Missing SA Rankings”.
344
Report Card
(SA Rankings)
When a Trading Partner runs the
Report Card, a comparison can be
made to the industry with regards to
Missing SAs.
345
Report Card
(SA Rankings)
The EDI Team has modified the
Report Card to rank those SAs that
are late as well as missing.
346
Missing SA
(Sub-Annual)
“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).
347
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.
348
Report Card
(SA Rankings)
Listed below is an example of how the
new Missing SA Rankings will appear
on the Report Card:
349
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.
350
Report Card
(Reoccurring Errors)
Listed below is an example of how
reoccurring errors will appear on the
Report Card:
351
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…
352
Report Card
Log into the
Warehouse
353
Report Card
Click on
Report Cards &
Statistical Reports
354
Report Card
Click on Generate
Claims EDI Report
Cards
355
Report Card
Select the
Date Range
&
Filing Type/MTC
356
Top 10 Reoccurring Errors
357
Missing SA Rankings
358
Rejected But Not
Successfully
Resubmitted List
359
Rejected Not Resubmitted List
EDI 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.
360
Rejected Not Resubmitted List
Email the EDI Team if the EDI DWC1 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.
361
Rejected Not Resubmitted List
Also notify the EDI Team if an EDI
DWC-1 that rejected was actually
sent in error and will never be resent (e.g., Medical Only), so the
transaction(s) can be removed
from the list.
362
The Rejected Not
Resubmitted listing is
updated every
Saturday.
363
Claim Admin Selects
Rejected Not Resubmitted List
364
All outstanding TR’s will be returned
(EDI DWC-1, SA & FN)
365
The Rejected But Not
Resubmitted Listing includes
Incomplete EDI DWC-1
filings
(i.e. 00 sent without the SROI)
366
Other Features in the
Claims EDI Data
Warehouse
367
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.
368
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.
369
For example, click on the ‘Partner
ID’ for the desired EE:
370
All filings for DOI’s, Claim #’s, JCN’s
associated with that EE Name you have
sent to DWC will be presented.
371
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).
372
On the main ‘Search” screen, click on
any MTC/MTC combo from the drop
down menu under “Filing Type’.
373
In this example, all rejected 00/IP’s for
the selected time period are presented.
374
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).
375
When you return to the list, the
‘purple’ will indicate which Henny
Penny filing you’ve already viewed.
376
Social Security Number (SSN)
Division Assigned Number (DAN)
SSN has been masked for security
reasons (along with EE address,
nature of injury, and accident
description) for confidential profiles.
• DAN will be displayed.
377
Helpful Hint
If the filing consists of both FROI
and SROI tabs, the data
warehouse view will default/open
to the SROI tab first.
378
ALL questions, either Business or Technical,
should be sent via email to
claims.edi@myfloridacfo.com
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.
379
Questions?
380