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

2. EDI Team Members Linda Yon, Bureau Chief, Bureau of Data
Quality & Collection
Tonya Granger,
System Project Administrator (EDI Coordinator)
(cont’d…)

3. EDI Team Members Michelle Carter, Operations Review Specialist
Riley Pool,
EDI Team Member
Megan Fox,
(cont’d…)

4. EDI Team Members
Laura Cotner,
EDI Team Member
Antrine Long,

5. Housekeeping Handouts Include: Agenda Copies of Slides
Quick Code References
Acronym List
Breaks and Lunches
Note Cards for Questions

6. 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.

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.

10. Claim Administrator Data Entry

11. 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.

12. Claims EDI Data Warehouse Claim Administrator Data Entry
This data entry capability can be utilized by small claim administrators for filing all EDI transactions.

13. 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.

14. 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…

15. 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.

16. DWC’s Website URL has changed to:

17. Effective Friday , if you have an old page bookmarked, you will be re-routed to the new Home Page.

18. Discussion Topics FROI or SROI 02 (Change) (cont’d…)
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…)

19. Discussion Topics Top Errors Affecting Claim Administrators and How to
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)

20. Name That MTC

21. 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?

22. Employer Reinstatement Because the employer chose to pay IIB benefits.
MTC ER
Employer Reinstatement
Because the employer chose to pay IIB benefits.

23. Scenario disability to the injured worker What MTC should be filed?
Claim administrator pays days 1-7 of
disability to the injured worker
What MTC should be filed?

24. Injured worker has not been disabled for 8 or more days.
NOTHING DUE
Injured worker has not been disabled for 8 or more days.

25. Scenario
FROI 04 filed
Denial is rescinded but no indemnity is due at time of rescission
What MTC should be filed?

26. Because no benefits are being initiated at this time.
SROI 02
Change
Because no benefits are being initiated at this time.

27. 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?

28. 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.

29. 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?

30. MTC RB Reinstatement of Benefits
Because indemnity has been paid after a suspension.

31. 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?

32. Net Weekly Amount for PT Supps (BTC 021) changes every January.
MTC CA
Change in Amount
Net Weekly Amount for PT Supps (BTC 021) changes every January.

33. 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?

34. MTC S7
Suspension –
Benefits Exhausted

35. 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?

36. Reinstatement of Benefits TT paid after claim was closed.
MTC RB
Reinstatement of Benefits
TT paid after claim was closed.

37. Scenario
00/IP filed
Claim is further investigated and subsequently denied
What MTC should be filed?

38. SROI 04
Full Denial
FL requires a SROI 04 (Full Denial) if indemnity had been previously reported.

39. Scenario dependants need to be paid What MTC should be filed?
Compensable death and
dependants need to be paid
What MTC should be filed?

40. 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.

41. 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?

42. Add Concurrent Benefit Type
MTC AB
Add Concurrent Benefit Type

43. Scenario What MTC should be filed?
Benefit Period Start Date of a BTC currently on file with DWC was incorrectly reported
What MTC should be filed?

44. (with an ‘02’ in the Benefit Segment) (MTC CB or RB is not required)
SROI 02 Change
(with an ‘02’ in the Benefit Segment)
(MTC CB or RB is not required)

45. 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?

46. Initial payment by acquiring claim administrator.
MTC AP
Acquired/Payment
Initial payment by acquiring claim administrator.

47. Scenario What MTC should be filed? 00/IP filed
Claim Administrator determined the Benefit Type on the initial payment (IP) was wrong
What MTC should be filed?

48. 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 What MTC should be filed? 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?

50. 00/IP should be cancelled and followed up with a 00/EP with BTC 2xx.
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.

51. 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.

52. Claims EDI Data Warehouse Insurer Access View

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

54. 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.

55. 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.

56. 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.

57. 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.

58. To request access to the Insurer View, please contact a member of the EDI Teamat
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.

59. Questions

60. Clarification of IAIABC 2014 R3 Implementation Guide Change

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

62. 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”.

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. 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)

78. 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.

79. 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:

80. 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.

81. FROI 02 (Reporting Initial RTW Information)
The FROI 02 transaction is due
14 days after the claim administrator’s notification of the change.

82. 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.

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 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)

85. 9/19/13 = Dr changed the injured worker’s. release (to full duty - no
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
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/ 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. (Initial Return to Work)
ANSWER:
FROI 02
(Initial Return to Work)

91. Latest Return to Work Status Date?
Questions Regarding
Latest Return to Work Status Date?

92. Suspensions

93. 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

94. 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

95. 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.

96. 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.

97. “Event” Benefit Segment, or “Sweep” Benefit Segment?
Are Suspensions an
“Event” Benefit Segment, or
“Sweep” Benefit Segment?

98. “Event” 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. 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.

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

104. MTC S1 vs. FROI or SROI 02 (Reporting RTW Information)

105. Reporting Initial RTW Information
FROI 02
Reporting Initial RTW Information

106. 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.

107. FROI 02 (Reporting Initial RTW Information)
The FROI 02 transaction is due
14 days after the claim administrator’s notification of the change.

108. Reporting Latest RTW Status Date Information
SROI 02
Reporting Latest RTW Status Date Information

109. 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…

110. 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.

111. 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…

112. 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.

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).

114. Correcting Suspension Information

115. 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…

116. 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.

117. 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’…

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

119. X 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.
Sx Eff Date
7/15/12
First
8/7/12
Second
8/10/12
SROI 02 X

120. 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.

121. 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.

122. Data was not edited/loaded:
Data was edited/loaded:

123. What MTC is used to correct an injured worker’s IRTW information previously reported?

124. ANSWER:
FROI 02
(Change)

125. Questions

126. Reinstatement of Benefits (MTC RB)

127. 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.

128. At DWC claim is in ‘suspended status’ SROI 04 (Full Denial)
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)

129. 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.

130. 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.

131. 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.

132. MTC RB (Reinstatement)
New Edit
MTC RB (Reinstatement)

133. MTC RB (Reinstatement)
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…

134. MTC S1 filed (claim in suspended status)
… 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)

135. 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

136. 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’

137. Questions

138. Top Errors Affecting Claim Administrators and How to Correct Them

139. 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…

140. Error #1:
NBR OF BENEFITS SHOULD NOT BE > WHAT IS ON FILE

141. 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 ( )
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…

142. On 8/23/12, the claim administrator submitted a 00/IP and reported the initial payment of TT (050) benefits.
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
050
TEMPORARY TOTAL
IP 
128.00
8/7/12
8/17/12
8/23/12 1
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.

143. new benefits cannot be introduced on a suspension.
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.
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
030
PERM PART SCHEDULED
 S7
48.00
 12/27/12
48.00 
12/27/12
2/6/13 6
288.00
12/31/12 
050
TEMPORARY TOTAL
128.00
8/7/12
8/10/12
12/16/12 18 3
12/28/12 

144. 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.

145. CB – Change in Benefit Type ER - Employer Reinstatement
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

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

147. 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

148. Benefit Payment Issue Date Benefit Payment Issue Date
Current benefit picture on file at DWC:
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Benefit Payment Issue Date
050
TEMPORARY TOTAL
266.68
1/1/13
2/11/13 6
070
TEMPORARY PARTIAL
256.00
2/12/13
3/25/13
030
PERM PART SCHEDULED
100.01
7/1/13
8/11/13
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
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Benefit Payment Issue Date
050
TEMPORARY TOTAL 02
266.68
1/1/13
2/11/13 6
030
PERM PART SCHEDULED
100.01
7/1/13
8/11/13
600.06

149. Benefit Payment Issue Date
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:
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Benefit Payment Issue Date
050
TEMPORARY TOTAL
266.68
1/1/13
2/11/13 6
070
TEMPORARY PARTIAL
256.00
2/12/13
3/25/13
030
PERM PART SCHEDULED
100.01
7/1/13
8/11/13
600.06

150. 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).

151. True or False
New Benefits Type Codes reported for the first time can appear on an MTC SA (Sub-Annual) Or
FN (Final).

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

153. Reporting BTCs Accidentally Left Off Transactions

154. 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.

155. 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…

156. …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.

157. Once the transaction rejects, send an email to: claims
Once the transaction rejects, send an to:
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.

158. Questions Regarding Error #1?
NBR OF BENEFITS SHOULD NOT BE > WHAT IS ON FILE

159. Error #2:
BENEFIT TYPE AMOUNT PAID < PREVIOUSLY REPORTED

160. This error occurs when the Benefit Type Amount Paid (total)
Top Errors Affecting Claim Administrators: BENEFIT TYPE AMOUNT PAID < PREVIOUSLY REPORTED ( )
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.

161. 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.

162. 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.

163. 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.

164. the disappearance of a previously reported Benefit Type,
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…

165. OR… 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…

166. 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…

167. OR… Recovery Code (880 or 830 only)
880 Voided Indemnity Benefit Check or Overpayment Recovery
OR…
A Benefit Adjustment Code
A Benefit Credit Code

168. Questions Regarding Error #2:
BENEFIT TYPE AMOUNT PAID < PREVIOUSLY REPORTED

169. 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…

170. 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).

171. 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).

172. 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

173. Reduced Benefit Amount Code ‘R’
Proper Use of
Reduced Benefit Amount Code ‘R’
(Reclassification)

174. 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.

175. There are two reasons for reclassifications:
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.

176. 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.

177. OR… 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.

178. 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.

179. 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).

180. 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:
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
050
TEMPORARY TOTAL IP
439.04
12/17/13
12/24/13
12/30/13 1
12/30/13 

181. 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
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
070
TEMPORARY PARTIAL 02
421.45
12/17/13
1/13/14 4 $

182. 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.

183. 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:
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
050
TEMPORARY TOTAL IP
648.29
7/14/13
7/21/13
7/27/13 1
7/27/13 

184. The claim administrator then filed an MTC CB showing the initiation of TP (070) benefits.
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
050
TEMPORARY TOTAL CB
648.29
7/14/13
7/27/13 2
070
TEMPORARY PARTIAL
622.32
7/21/13
7/28/13
8/10/13

185. 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
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
050
TEMPORARY TOTAL 02
648.29
7/14/13
7/20/13 1
070
TEMPORARY PARTIAL
622.32
7/21/13
7/28/13
8/10/13 3

186. 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.

187. 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.

188. 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.

189. 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”.

190. 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:

191. Reduced Benefit Amount Code ‘R’ Issue Resolution Request
(Reclassification)
Issue Resolution Request
(IRR)

192. 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.

193. 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.

194. DWC recommends that once sent the ‘R’ code should not remain on
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

195. Reduced Benefit Amount Code ‘D’ (Decrease in Indemnity)
Proper Use of
Reduced Benefit Amount Code ‘D’ (Decrease in Indemnity)

196. 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.

197. 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.

198. 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.

199. 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.

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

201. 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.

202. Reduced Benefit Amount Code?
Questions Regarding
Reduced Benefit Amount Code?

203. Trading Partner Paperwork Issues
Error #3:
Trading Partner Paperwork Issues
NO MATCH ON DATABASE FOR INSURER FEIN (DN )
&
CLAIM ADMIN FEIN MUST BE VALID FOR INSURER (DN )

204. 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).

205. 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.

206. Pursuant to 69L (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.

207. 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.

208. 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.

209. 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)…

210. … 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.

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

212. Questions Regarding Error #3:
NO MATCH ON DATABASE FOR INSURER FEIN and CLAIM ADMIN FEIN MUST BE VALID FOR INSURER

213. Error #4:
NO SROI S1-7, 04, CD, VE, PY OR PD ON FILE

214. 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)

215. 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…)

216. 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’)

217. 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.
00/IP:
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
030
PERM PART SCHEDULED IP
275.00
8/20/13
9/2/13 2
550.00
9/1/13 

218. The transaction rejected with the error
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:
BTC
Benefit Type
MTC
Gross Weekly Amt.
Gross Eff. Date
Net Weekly Amt.
Net Eff. Date
Start Date
Through Date
Weeks
Days
Amt. Paid
Payment Issue Date
030
PERM PART SCHEDULED FN
275.00
8/20/13
9/2/13 2
550.00

219. 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.

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

221. Questions Regarding Error #4
NO SROI S1-7, 04, CD, VE, PY OR PD ON FILE

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

223. Two of the most prevalent Claim Type error messages are:
Claim Type Must = I if IDDB = DOI/DOI & no RTW
Claim Type Must = L if IDLT > IDDB + 7

224. 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.

225. 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.

226. 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.

227. 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.

228. 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…

229. ‘Claim Type Must = I if IDDB = DOI/DOI +1 & no RTW’
… The most common error message regarding Claim Type ‘L’ is:
‘Claim Type Must = I if IDDB = DOI/DOI +1 & no RTW’

230. 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.

231. 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…

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

233. 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…

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

235. 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’…

236. … 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.

237. 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

238. 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’).

239. 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’…

240. … 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).

241. Questions
Thank You

242. Claims EDI R3 Data Warehouse Featured Functionality

243. 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.

244. Customer Administrator
Responsibilities

245. 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.

246. 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

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

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

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

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

251. 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.

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

253. Having trouble logging into the Warehouse?

254. If you receive this error message…
Password Help
If you receive this error message…

255. Click on the “Forgot your password” link
Password Help
Click on the “Forgot your password” link

256. Enter your email address
Password Help
Enter your address
Enter your 9 digit
Trading Partner ID

257. Password Help

258. Password Help

259. Password Help
Enter your User ID
Enter your 9 digit
Trading Partner ID

260. Password Help
Write down or select/copy the generated password
The system generates a password that is valid for 24 hours

261. Enter or paste the generated password
Password Help
Enter or paste the generated password

262. Click “Change my Password”
Password Help
Click “Change my Password”

263. Enter a new password and confirm Enter or paste the generated password
Password Help
Enter a new password and confirm
Enter or paste the generated password

264. Password Help

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

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

268. Claims EDI Data Warehouse Search for an individual claim

269. Claims EDI Data Warehouse
Search for an individual claim or query by date ranges.

270. 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.)

271. 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.

272. There are 3 Tabs of Data
This is a test case.
Click on Errors

273. Errors are noted on the Errors Tab
SROI has 1 error; FROI rejected because SROI was not accepted.

274. Fatal Errors are in Red

275. not understand the error?
What do you do if you do
not understand the error?
Note the Element # (0066) and Error # (064)

276. Go to your copy of the Edit Matrix.
Most recent version is posted on DWC’s Claims EDI webpage at:

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

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

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

280. 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”.

281. 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.

282. Search by Element/Error Code

283. 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.

284. Search by Element/Error Code

285. Search by Element/Error Code
Drop Down Box with all DN/Error Combinations

286. Search by Element/Error Code
As with all Search Results, you can import the results into Excel.

287. Let’s Look At Another Example in the Warehouse…

289. 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.

290. 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.

291. Go to your copy of the Element Requirement Table.
Most recent version is posted on the Claims EDI webpage at

292. Click on SROI Elements Tab…and find DN 0196.
The requirement code ‘MC’ means you must look at the SROI Conditions Tab

293. Click on SROI Conditions Tab…and find DN 0196.

294. 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 Edit Matrix: Pop Rest and Match Data, and Duplicate Tabs
All Other Error #’s: Pop Restrictions Tab

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

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

297. 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 the EDI Team at

298. 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 the EDI team if you suspect our program/edit is at fault.

299. 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.

300. If you already investigated an error and still do not understand it,
please send an to rather than individual EDI team members.
This copies all team members.
CLAIMS EDI

301. 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.

302. The Claims EDI Team receives approximately 50+ emails per day;
therefore, if you have not received an answer or some acknowledgement of your ed question within 2 business days, please resubmit.

303. Responding to Reconciliation (Non-Fatal) Errors
TA-FL’s

304. 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”

305. 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.

306. 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).

307. Reconciliation (Non-Fatal) Errors
DWC sends 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 (1)(i), F.A.C.)

308. 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.

309. Reconciliation (Non-Fatal) Errors
How do I quickly find all my TA-FL error messages to see what needs to be addressed?
TA-FL

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

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

312. 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.

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

314. From the Main Menu, first select ‘Report Cards and Statistical Reports’

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

316. Fill in your search criteria (date range, office location )

317. You will receive a ‘Claims EDI (TA-FL) Errors Detail Report’
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).

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

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

320. Responding to Reconciliation Errors
On the Search Results screen you can see that there are internal reconciliation errors that are open.

321. 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.

322. 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.

323. Responding to Reconciliation Errors
Reconciliation Errors are in Yellow

324. 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.

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

326. Responding to Reconciliation Errors
An EDI Team member will type a response back to the Claim Admin.
DWC response
Claim Admin response

327. 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

328. Responding to Reconciliation Errors
When the error has been rectified an EDI Team Member will close the error.

329. 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.

330. 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”.

331. 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.

332. 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….

333. 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.

334. 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…

335. 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) …,

336. 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.

337. 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.

338. Overpayment only = OVER PMT
O/P + non-reconciled non-fatal error = OPEN

339. 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.

340. In addition to the ‘OVER PMT’ Error Status, non-fatal ‘PERM TOT’ errors are also posted in the warehouse to identify possible PT Errors.

341. …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

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

343. Report Card

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

345. 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.

346. Report Card
(SA Rankings)
The EDI Team has modified the Report Card to rank those SAs that are late as well as missing.

347. 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).

348. 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.

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

350. 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.

351. Report Card
(Reoccurring Errors)
Listed below is an example of how reoccurring errors will appear on the Report Card:

352. 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…

353. Report Card
Log into the Warehouse

354. Report Cards & Statistical Reports
Click on
Report Cards & Statistical Reports

355. Click on Generate Claims EDI Report Cards

356. Report Card
Select the
Date Range
&
Filing Type/MTC

357. Top 10 Reoccurring Errors

358. Missing SA Rankings

359. Rejected But Not Successfully Resubmitted List

360. 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.

361. Rejected Not Resubmitted List
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.

362. 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 re-sent (e.g., Medical Only), so the transaction(s) can be removed from the list.

363. The Rejected Not Resubmitted listing is updated every Saturday.

364. Claim Admin Selects Rejected Not Resubmitted List

365. All outstanding TR’s will be returned
(EDI DWC-1, SA & FN)

366. The Rejected But Not Resubmitted Listing includes
Incomplete EDI DWC-1 filings
(i.e. 00 sent without the SROI)

367. Other Features in the Claims EDI Data Warehouse

368. 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.

369. 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.

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

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

372. 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).

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

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

375. 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).

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

377. 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.

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

379. ALL questions, either Business or Technical, should be sent via email to claims.edi@myfloridacfo.com
This 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.

380. Questions?