Florida Division of Workers’
Compensation
Claims EDI
Release 3 Technical
Training
2008
1
FL Technical
Requirements
69L-56.310, F.A.C.
FL Technical Requirements
The FL Technical
Requirements can be found in
69L-56.310 F.A.C.
The following slides highlight
some of the requirements in the
rule.
FL Technical Requirements
Transmissions received on or
before 9:00 p.m., E.S.T., will be
processed by DWC the same
day the transmission was sent.
It will be acknowledged the next
calendar day (morning).
4
FL Technical Requirements
Transmissions received after 9:00
p.m. EST will be processed by
DWC the following calendar day.
It will be acknowledged the day
after the transmission is processed.
5
FL processes
transmissions 7
days a week,
including holidays.
6
FL Technical Requirements
If either the FROI or SROI (filed to
represent the electronic equivalent
of the First Report of Injury or
Illness) contains an error that
results in the rejection of one of the
transactions,
both the FROI and SROI will be
rejected.
7
FL Technical Requirements
The claim admin must re-send both
the corrected FROI and SROI to
the Division in order for the two
transactions to be processed
together.
The Division will only pair FROI’s
and SROI’s that are received by the
Division on the same day.
8
FL Technical Requirements
R3 transactions must be sent to
DWC using only the following
transmission methods:
Advantis Value Added Network (VAN),
OR
Secure Socket Layer/File Transfer
Protocol (SSL/FTP) in accordance with
instructions on
Form DFS-F5-DWC-EDI-4
9
FL Technical Requirements
Sender ID =
Claim Admin’s/Insurer FEIN
+
Claim Admin’s/Insurer’s Postal Code
as reported on:
Form DFS-F5-DWC-EDI-1 & EDI-3
10
NOTE: All 9 digits of the
Trading Partner’s Postal Code
should be sent in the Sender ID.
This postal code must match
either the Physical or Mailing
Sender Address Postal Code,
and should be a valid location for
the company.
11
FL Technical Requirements
The Sender ID on the Header
Record shall represent the
insurer’s or claim administrator’s
FEIN and Postal Code, not that
of the vendor.
12
FL Technical Requirements
If a vendor is submitting files on
behalf of more than one insurer
or claim administrator, the
vendor shall send separate
header and trailer records for
each client.
13
FL Technical Requirements
Receiver FEIN for FL = 596001874
Receiver Postal Code for FL =
323994226
14
File Naming
Conventions
15
There is no standard file name for
Trading Partners using Advantis.
Each file is simply a message in the
Division’s mail box. However, the
Trading Partner must include the
FROI/SROI Message Class when
they transmit a file (see DWC
“Receiver Specifications”.)
16
FTP File Naming Convention
If you do not have a current FTP
account established with the
Division, you are required to have
one set up prior to sending a
transmission.
FTP Filing instructions are
documented in the DFS-F5-DWCEDI-4 Form: SSL / FTP Instructions
for POC EDI and Claims EDI.
17
FTP File Naming Convention
If you currently have a Medical
(non-claims) FTP account
established with the Division, it is
not necessary to set up a separate
SSL/FTP account for your Claims
submissions.
Please contact the Division about
setting up your Claims SSL/FTP
account at claims.edi@fldfs.com
18
FTP File Naming Convention
Suserid148-CCYYMMDD-HHMMSSz.TXT
SuseridA49-CCYYMMDD-HHMMSSz.TXT
The first letter is fixed and shall = “S”;
“userid” = Division-assigned nine digit TP ID. “148”,
“A49” refer to the electronic formats in which data are
sent.
The CCYYMMDD = date transmission sent.
HHMMSS =hour, minutes, and seconds, and
“z” =file is being sent as test (“T”) or production (“P”),
19
followed by .TXT.
Technical
Overview
Release 3
Records
21
Release 3 Records
 A Record is a group of related ‘Data
Elements’ that form a transaction.
In R3, the FROI and SROI are
comprised of 2 Records each:
148 + R21 = FROI
A49 + R22 = SROI
22
Release 3 Records
Some Release 3
Records are Fixed
length and some are
Variable length.
23
Release 3 Records
Identified by DN0001-Transaction Set ID
24
Release 3 Records
Fixed Length Record
The length of a “Fixed Length
Record” is consistently the same
number of data positions each time
the record is assembled.
The data within the record is always
in the same position within the
record, based on the individual
record layout .
25
Release 3 Records
Variable Length Record
The length of a
“Variable Length
Record” may vary each
time the record is
assembled.
26
Release 3 Records
Variable Length Record
The record length is determined using
the “Variable Segment Counters” which
are the “ Number of ” fields in the FROI
and SROI segments. These segments
occur zero to many times based on the
allowed number of occurrences for the
segment.
Note: These fields must always be present.
27
Release 3 Records
Variable Length Record
Although each segment is
a fixed length, the total
record length will vary
depending on the number
of segments.
28
When a variable length
record is sent, the entire
segment should be sent,
even if there are blanks.
Example:
Benefits segment = 103 characters
Payments segment = 98 characters
Other Benefits segment = 34 characters
29
Release 3 Records
Variable Length Records
Let’s see how it works…
30
Release 3 Variable Segments
Partial display of SROI R22 record
Counters
determine
the
overall
record
length.
31
Release 3 Variable Segments
Partial display of SROI R22 record
When the
transaction
includes
one
Benefits
segment,
(Fixed length =
650)
32
Release 3 Variable Segments
Partial display of SROI R22 record
The
Benefits
segment =
103 bytes,
the R22
record
ends at
position
753.
Ben Seg
= 103
Bytes
33
Release 3 Records
Variable Length Record
Let’s try one more…
34
Release 3 Variable Segments
Counters
determine
the overall
record
length.
Fixed length
= 650
Overall length
= 803
35
Release 3 Variable Segments
The
transaction
includes one
Benefits
segment
and one
Suspension
Narrative.
36
Release 3 Variable Segments
Benefits
segment =
103 bytes;
Suspension
Narrative =
50 bytes.
37
Release 3 Variable Segments
The R22
record ends
at position
803.
38
Transactions
Release 3 Transactions consist of 2
records to report a claim event
148
R21
FROI
A49
R22
SROI
40
Transaction ‘KEY’
The Claim Administrator Claim
Number (DN0015) is a
MANDATORY “KEY" used to
validate:
– 148 record relationship to R21
companion record
– A49 record relationship to R22
companion record
41
Transaction ‘KEY’
The Claim Administrator
Claim Number (DN0015) ties
the records together!
This ensures proper FROI to
SROI combo processing.
42
Transaction ‘KEY’ FROI
FROI Companion record relationship is
verified by comparing Claim
Administrator Claim Number (positions
205 to 229 in the 148 record),….
43
Transaction ‘KEY’ FROI
…to positions 24 to 48 on the R21 (next
record in the batch). When a match is
found, the relationship is confirmed.
44
Transaction ‘KEY’ SROI
SROI Companion record relationship
is verified by comparing Claim
Administrator Claim Number
positions 136 to 160 on the A49
record
45
Transaction ‘KEY’ SROI
to positions 24 to 48 on the R22
(next record in the batch). When a
match is found, the relationship is
confirmed.
46
Batches
FILE: Consists of
1 or more
batches of the
same type of
transaction (e.g.,
FROI)
*A separate SROI file
is sent with 1 or more
SROI batches.
F
I
L
E
B
A
T
C
H
B
A
T
C
H
Header
FROI
Transactions
Trailer
Header
FROI
Transactions
Trailer
48
BATCH:
Consists of 1
Header record,
one or more
Transactions
and 1 Trailer
record.
Note: These would
be sent in 2
separate files.
B
A
T
C
H
B
A
T
C
H
Header
FROI
Transactions
Trailer
Header
SROI
Transactions
Trailer
49
Batch of FROI transactions
8 records; 4 transactions
Header
B
A
FROI
T
Transactions
C
H
Trailer
148
Rec 1
R21
Rec 2
148 Rec 3
R21
FROI Rec 4
FROI
148 Rec 5
Rec 6
FROI
R21
FROI
FROI
148 Rec 7
Rec 8
FROI
R21
FROI
FROI
50
Batch of SROI transactions
8 records; 4 transactions
A49 Rec 1
Header
R22 Rec 2
B
A49 Rec 3
Rec 4
A
R22
FROI
SROI
Rec 5
T
FROI
A49
Transactions
Rec 6
C
FROI
R22
FROI
H
FROI
A49 Rec 7
Rec 8
Trailer
FROI
R22
FROI
FROI
51
Header Record
HD1 – Release 3 Header Record
uniquely identifies the sender (Claim
Admin/Insurer), the receiver (FL),
and date/time batch was prepared.
53
HD1 – Release 3 Header Record
Date Transmission Sent MUST be
the same day the file is actually sent
to DWC.
54
HD1 – Release 3 Header Record
DATE TRANSMISSION SENT –
DN0100
Definition: Actual date the batch of data
was sent to the receiver.
CLAIMS RELEASE 3.0 STANDARDS DATA DICTIONARY
55
HD1 – Release 3 Header Record
FL Processing:
FL will edit Date Transmission Sent to
ensure that the date is within 1 day of
receipt (not edited in R1).
Batch processing order will be determined
by Date Transmission Sent and Time
Transmission Sent.
Time Transmission Sent for FROI batches
must be prior to (at least a fraction of a
second) the Time Sent for SROI batches,
56
to ensure proper “combo” processing.
HD1 – Release 3 Header Record
Identifies whether the batch contains
test or production data and the
Interchange Version ID (e.g. 14830).
57
FROI Records
Release 3 FROI record
148 – 913 Byte Fixed Length Record
59
R3 FROI Companion record
R21– Variable Length Record
Counters determine record length
60
SROI Records
Release 3 SROI record
.
A49 – Variable Length Record
Counters determine record length
62
R3 SROI Companion record
R22 – Variable Length Record
Counters determine record length
63
Trailer Record
TR2 – Release 3 Trailer Record
 designates the end of a batch of
transactions
 provides a count of records and
transactions within a batch
 is used to ensure that the entire
batch is complete and valid
65
Pop Quiz:
If the Detail Record
Count in the Trailer is 6,
what would the
Transaction Count be?
66
Pop Quiz Answer:
If the Detail Record
Count in the Trailer is 6,
the Transaction Count
would be 3.
67
Data Population
68
Data Population
Prior to population of data elements
into the record, all positions are
defined as spaces.
This indicates absence of data or
no population of data in the field.
69
Data Element Formats
The data format
becomes applicable
only when the data
element is
populated in
the record.
70
Data Element Formats
This means that
“numeric” fields that are
not being populated
should be sent as
spaces and not zeros.
71
Data Formats
72
Data Element Formats
Data Element:
information.
A single piece of
Definitions, standard data format,
valid data values and population
rules for Release 3 data elements
are defined in the Data Dictionary
in Section 6 of the Release 3
Implementation Guide.
73
Data Element Information
74
Data Element Information
Release 3 standard data formats
are defined in the System Rules
in Section 2 of the Release 3
Implementation Guide.
Let’s check out
the standard data
formats…
75
Data Element Formats
Dates: Type = DATE
(CCYYMMDD): Data elements that
are assigned the format of DATE
should be populated with only a
valid date.
Example: 12/01/2007;
December 1, 2007, 12-1-07
would be sent as :
20071201 (CCYYMMDD)
76
Data Element Formats
Dates: Type = DATE: 20071201
All zeros in a date field
are considered to be
invalid data.
Spaces indicate absence
of data, do not zero fill.
77
Data Element Formats
Time: Type = TIME: Data elements
that are assigned the format of TIME
should be populated with only a
valid 24-hour military time.
11:54
pm
78
Data Element Formats
Time: Type = TIME:
The valid values for
military time are only
000000 (midnight)
through 235959.
Spaces indicate absence of data.
Example:
HHMMSS: 142903 = 2:29:03 P.M.
79
Data Element Formats
Time: Type = TIME:
There is a difference in
the length and Valid
Values of DN0032 Time of
Injury and the other time
fields (as on the header).
80
Data Element Formats
Numeric: Type = N: Data elements
that are assigned the format of N
should be populated with only a
valid numeric. If the data element is
not populated, spaces should be
sent.
81
Data Element Formats
Numeric: Type = N:
Valid values consist of 0 -9 and are
right justified zero filled to the left.
Example:
3 numeric ‘123’ in 6 byte field = 000123
Spaces indicate absence of data.
Negative numbers are not valid.
82
Data Element Formats
Monetary Amounts: Type = $9.2:
Data elements that are
assigned the format of $9.2
should be populated
with only a valid
monetary
amount.
83
Data Element Formats
Monetary Amounts: Type = $9.2:
Valid entries consist of eleven numeric
digits with the dollar sign assumed (not
populated), and the decimal point
between the ninth and tenth position (2
positions from the right) is assumed (not
populated).
Example: 00000005000 = $50.00
000000050^00
Spaces indicate absence of data.
Negative numbers are not applicable.
84
Data Element Formats
Percentage (PI): Type = 3.2:
Data elements that are
assigned the format of 3.2
should be
populated
with only a valid
percentage.
125%
85
Data Element Formats
Percentage: Type = 3.2:
Valid entries consist of 0 - 9 and are
right justified zero filled to the left. The
decimal point is assumed (not
populated) between the third and fourth
position (2 positions from the right).
Example: 05000 = 50.00%
050^00
Spaces indicate absence of data.
Negative numbers are not applicable.
86
Data Element Formats
Percentage: Type = 3.2:
Caution – 0% is a valid PI rating;
therefore, 00000 should only be
sent when a PI rating is truly a
valid zero %, and not when this
field is not populated.
0
87
Data Element Formats
Alpha numeric: Type = A/N:
Data elements that are defined in the
format of A/N include upper case
letters, lower case letters, numeric
digits, space character, and special
characters defined in System Rules
of the R3 Implementation Guide
Spaces indicate absence of data.
88
Data Element Formats
Alpha numeric: Type = A/N:
When using an alphanumeric field
the significant characters are always
left justified in the field with any
remaining space in the field padded
with spaces.
SMITH
(space)
89
Data Element Formats
Alpha numeric: Type = A/N:
Use of any of the alphanumeric
characters is permitted in data
elements with the alphanumeric data
type unless otherwise indicated in an
Implementation Note or an Edit
Matrix Population Restriction (e.g.
Employee Last Name).
90
Lets start
building a
SROI
transaction
91
Data Element Formats
The fixed length portion of the
SROI A49 record is 208 bytes.
Population of the record starts out
with 208 spaces.
92
Data Element Formats
DN0001 (Transaction Set ID) is a 3
digit A/N (alphanumeric) field.
Valid Transaction Set ID replaces
the spaces in positions 1 through 3.
A49
93
Data Element Formats
DN0002 (Maintenance Type Code)
is a 2 digit A/N (alphanumeric) field.
A valid MTC replaces the spaces in
positions 4 and 5.
A49
IP
94
Data Element Formats
DN0003 (Maintenance Type Code
Date) is an 8 digit DATE field.
A valid date replaces the spaces in
positions 6 through 13.
A49
IP
20071201
95
Data Element Formats
In this example, Employee Number
of Dependents is required and the
Employee has no dependents.
The sender populates with zero.
00
96
Data Element Formats
If the Employee Number of
Dependents was not known or the
data element was not required/sent, it
would be populated with spaces
(another example: PI rating).
97
Acknowledgements
Florida
Acknowledgement
Overview
What is an Acknowledgement (AKC)?
An AKC transaction is returned by
Florida as a result of a transaction
sent.
Claim
Electronic
Administrator
Report
Florida
Acknowledgement
100
What is contained in the
Acknowledgement?
Enough information to
identify the original
transaction and any technical
and business issues.
101
How does the acknowledgement
communicate the status?
By DN0111 - Application
Acknowledgement Code,
which is located in each
acknowledgement record.
102
What is the Application
Acknowledgement Code?
A code used to identify the
accepted/rejected status of
the transaction(s) being
acknowledged.
103
Application Acknowledgement
Code Values for FL:
TA - Transaction Accepted
TR - Transaction Rejected
HD – Entire Batch Rejected
(Header or Trailer error)
104
Transaction Accepted (TA)
The transaction was accepted by
Florida.
No “fatal” errors were
found on the transaction.
Further follow up may be
required if “non-fatal” errors
are noted in the FL EDI Online
Data Warehouse. (TA-FL)
105
Transaction Rejected (TR)
An error was found on
a mandatory or
mandatory conditional
data element.
The transaction was not
accepted or added to Florida’s
system as a reported claim.
106
Transaction Rejected (TR)
A review of the error
should take place to
determine what
action should be
taken to resolve the
issue.
107
Transaction Rejected (TR)
An MTC CO (Correction) is not used to
respond to a TR acknowledgement,
and FL does not accept CO’s.
If a transaction rejects, the original
MTC must be re-filed (unless wrong
MTC was sent).
If an error is for a duplicate transaction,
invalid event sequence, etc. then
resubmission may not be required.
108
Batch Rejected (HD)
The Batch is
rejected in its
entirety.
When a Batch Reject
occurs, only one AKC record
will be returned in the
acknowledgement batch.
109
Batch Reject Reasons
Invalid Sender ID (No
acknowledgement batch will be
returned since the sender is
unknown). DWC will try to
determine who sent file and advise.
Invalid data in Header Record
Duplicate Batch
Invalid data in Trailer Record
Transaction not present in the batch
(invalid batch structure)
110
How does the AKC
transaction
communicate errors
111
Number of Errors (DN0114)
Number of Errors indicate the number
of ‘Error Segment’ occurrences.
112
Element Number (DN0115)
The Element Number indicates the
data element where the error was
found.
113
Element Error Number (DN0116)
The Element Error Number
identifies the type of error found on
an element.
114
Variable Segment Number (DN0117)
The Variable Segment Number
identifies the occurrence of the
variable segment in error. Default
when not applicable is 00.
115
Variable Segment Number (DN0117)
The Claim Administrator must be
able to identify the order in which
variable segments were sent
because FL’s acknowledgement will
reflect the Variable Segment
Number, in the order in which it was
sent in the transaction, to identify
which variable segment was in error.
116
Element Error Text (DN0291)
The free form Element Error Text
describes the error.
117
Acknowledgement
Management
Acknowledgement Management
An acknowledgement batch
contains AKC transactions
returned by Florida for each
transaction that was sent in the
original FROI or SROI batch.
119
Acknowledgement Management
In one day, Claim Admin sends 3
files of FROI’s containing 2 batches
each (6 FROI batches total).
This equates to 6 AKC batches
which FL will return in 1 file.
Note: SROI’s are sent in separate
file.
120
Acknowledgement Management
The file naming conventions for
R3 acknowledgements returned
by the Division are:
CLMAKC-userid-CCYYMMDD-HHMMSSz.TXT
CLMARC-userid-CCYYMMDD-HHMMSSz.TXT
Note: The date and time on the AKC and ARC filenames
correspond to the date and time (including seconds) the
file was created and does not correspond to any original
incoming file sent by the trading partner.
121
AKC for each Transaction
FROI Example
Claim Administrator sends:
Header
FROI
Transactions
Trailer
148
Record 1
R21
Record 2
148
Record 3
R21
Record 4
148
Record 5
R21
Record 6
148
Record 7
R21
Record 8
Florida returns:
Header (HD1)
AKC TA Record 1
AKC TA Record 2
AKC TR Record 3
AKC TR Record 4
Trailer (TR2)
122
Acknowledgement Management
Each acknowledgement
record contains various key
data to allow the match of the
acknowledgement back to the
original report sent….
123
Key Data
Examples:
124
Record Sequence Number (DN0107)
The Claim Admin. must be able to
identify the order in which the
transactions were sent in the batch,
because FL’s acknowledgement
will reflect the Record Sequence
Number in the order in which the
transaction was sent in the batch,
to identify specifically which
transaction was in error.
125
Header Record is used to
match the original batch to AKC batch
FROI example:
HEADER RECORD (HD1) for FROI
HD1666777888
1 2
1
2
HD1999999999
888777666999999999
3
3
234234242666777888
23423424220010327074530
4
5
6
4
5
6
7
P14830
89
7
89
8887776662001032808134020010327074530PAKC30
HEADER RECORD (HD1) for AKC
1=Transaction Set ID (DN0001)
2=Sender ID (DN0098) to 3=Receiver ID (DN0099)
3=Receiver ID (DN0099) to 2=Sender ID (DN0098)
4=Date Transmission Sent (DN0100) to 6=Original Transmission Date (DN0102)
5=Time Transmission Sent (DN0101 to 7=Original Transmission Time (DN0103)
8=Test Production Code (DN0104) to 8=Test Production Code (DN0104)
126
9=Interchange Version ID (DN0105) DIFFERENT
Trailer Record is used to
match the original batch to AKC batch
FROI example:
TRAILER RECORD (TR2) for FROI
TR2000000002000000001
The count should be the same.
TR2000000001000000001
TRAILER RECORD (TR2) for AKC
Transaction Count (DN0191) is the total number of
transactions sent as part of the batch.
The FROI or SROI Transaction Count should be matched to
127
the AKC Transaction Count.
Trailer Record Validation
The claim administrator should
actively check acknowledgements to
determine if the AKC Transaction
Count matched the FROI or SROI
Transaction Count sent.
Note: One Acknowledgement batch
is returned for each FROI and SROI
batch sent.
128
Acknowledgement
File/ Batch
Examples
AKC Batch Facts
Interchange Version ID identifies
the batch type:
– AKC30 (Acknowledgement batch)
Transaction Set ID values identify
the transactions:
– HD1 (Header)
– AKC (Acknowledgement)
– TR2 (Trailer)
130
AKC Batch Facts
The Acknowledgement
transaction is a Variable
Length record.
131
AKC File/Batch Example
File
Header
AKC
AKC
Trailer
Header
AKC
AKC
AKC
AKC
Trailer
132
AKC Variable Segments Example
Partial display of AKC record
Number of Errors
determine the
overall record
length
Fixed length = 248
The transaction
includes two Error
segments
Error segment = 118
bytes (two 59 byte
segments). The
AKC record ends at
position 366
133
Re-Acknowledgement
(ARC)
What is a Re-Acknowledgement (ARC)?
An ARC is a type of acknowledgement
transaction that is returned by Florida
as a result of reloading or reprocessing
a previously acknowledged transaction
that was rejected in error by DWC. The
entire batch is re-acknowledged.
DWC will credit the Claim Administrator
with the original filing date.
135
ARC Batch Facts
Header (HD1) Interchange Version ID
is:
– ARC30 (Re-Acknowledgement batch)
Transaction Set ID values with the ARC
batch identify the transactions:
- ARC (Re-processed Transactions)
– AKC (Previously Acknowledged
Transactions that are unchanged)
136
Caution to Claim Administrators
If you choose not to process the ReAcknowledgement or if your system can
not support a 2nd acknowledgement
outcome for the same transaction, this
may result in subsequent “duplicate”
and “sequencing” errors.
Keep in mind that the ARC may contain
a Jurisdiction Claim Number (JCN) that
is needed.
137
What is an Re-Acknowledgement
(ARC)?
Claim
Administrator
Electronic
Report
Florida
Acknowledgement
contains TR(s) due to FL error
Re-Acknowledgement
138
ARC Example
Claim Administrator sends:
Florida returns:
Header (HD1)
Header
FROI
Transactions
Trailer
148
Record 1
R21
Record 2
148
Record 3
R21
Record 4
148
Record 5
R21
Record 6
148
Record 7
R21
Record 8
ARC30
AKC TA Record 1
ARC TA Record 2
AKC TR Record 3
AKC TR Record 4
Trailer (TR2)
139
Acknowledgement
Scenarios
Validate BatchHeader Data
Elements
What happens if a batch has
header errors?
The entire batch is rejected.
The individual transactions in
the batch are not processed.
142
What causes a Batch header error?
Receiver ID invalid for Florida.
Date Transmission Sent missing
or invalid.
Time Transmission Sent missing
or invalid.
Test/Production Code invalid.
Interchange Version ID invalid.
143
What will the acknowledgement
‘batch’ look like if the batch is
rejected?
The acknowledgement batch that is
returned will consist of:
1 Header record
1 Acknowledgement record
1 Trailer record
144
What will the acknowledgement
‘record’ look like?
The acknowledgement record
(AKC) for a batch with header
errors will contain ‘all zeros’ in the
Record Sequence Number.
145
‘HD’ in the Application
Acknowledgement Code
146
Number of Errors that were
found during the edit process
147
Error Segment
Element Number in error
Element Error Number for the error
Variable Segment Number
Element Error Text
148
Remaining fields on the AKC (noted
in red below) should be spaces.
149
Validate Detail
Records
Validate Detail Records
Once the header/trailer data
elements have been validated
and the batch structure has
been tested, the next step is to
validate each individual detail
record (transaction).
151
How does FL do this?
Florida will use:
Trading partner tables (Event Table,
Element Requirement Table, Edit
Matrix, etc.)
System Rules to determine the
appropriateness of each transaction
and ensure data quality
152
How does FL do this?
As each transaction is
edited, FL will assign 1 of
the 2 Application
Acknowledgement Code
values to each AKC
transaction; TA or TR.
153
How does FL do this?
Let’s walk
through
some
scenarios…
154
Transaction
Accepted
(TA)
Transaction Accepted Scenario
After the transaction (each data
element) is edited for all
applicable requirements for the
specific MTC sent and no
errors are found, the AKC
transaction will contain the
following information.
156
Transaction Accepted AKC Record
Acknowledgement Transaction Set
ID indicates the type of transaction
being acknowledged, either ‘148’
for FROI or ‘A49’ for SROI.
157
Transaction Accepted AKC Record
Application Acknowledgement
Code will be ‘TA’ meaning
Transaction Accepted, there were
no errors found.
158
Transaction Accepted AKC Record
Number of errors will be 00 which
indicates there were no errors
found during the edit process.
159
Transaction Accepted AKC Record
There will be no error
segments since Number of
Errors = 00.
The remaining fields on the
AKC should be populated from
data on the transaction (148 or
A49) being acknowledged.
160
Transaction
Rejected
(TR)
Examples
161
Transaction
Rejected for
Invalid Mandatory
Data Element
162
Rejected for Invalid Mandatory
Data Element
After the transaction is edited,
a fatal error
(mandatory/mandatory
conditional) is found on
DN0031-Date of Injury.
In this scenario DN0031-Date
of Injury had an invalid date.
163
Rejected for Invalid Mandatory Data
Element AKC Record
Acknowledgement Transaction Set
ID indicates the type of transaction
is being acknowledged, either ‘148’
for FROI or ‘A49’ for SROI.
164
Rejected for Invalid Mandatory Data
Element AKC Record
Application Acknowledgement
Code will be ‘TR’ meaning
Transaction Rejected (Florida did
not accept the transaction).
165
Rejected for Invalid Mandatory Data
Element AKC Record
Number of errors will depend on the
number of fatal errors found during the edit
process.
01 fatal error was found.
166
Rejected for Invalid Mandatory Data
Element AKC Record
The error segment contains:
Element Number DN 0031 (Date
of Injury)
167
Rejected for Invalid Mandatory Data
Element AKC Record
Element Error Number 029 Must be a valid date (CCYYMMDD)
168
Rejected for Invalid Mandatory Data
Element AKC Record
Variable Segment Number = 00
because data element is not in a
Variable Segment
169
Rejected for Invalid Mandatory Data
Element AKC Record
Element Error Text provides FL
specific error text.
170
Transaction Rejected for Invalid
Mandatory Data Element AKC Record
Remaining fields on the AKC
will be populated from data
on the transaction being
acknowledged.
171
Let’s Look At Some
More
Acknowledgement
Scenarios
172
Invalid Data
Relationship
Invalid Data Relationship Overview
The edit process will be used to
determine if an improper
relationship exists:
between two or more data
elements reported on the same
EDI transaction
between data on the EDI
transaction and data previously
reported
174
Invalid Data Relationship Scenario
In this scenario, Florida received
SROI MTC VE (Volunteer)
transaction where the
Employment Status Code
(DN0058) was reported as ‘1’
(Regular/Full-time Employee).
175
Invalid Data Relationship Scenario
Florida requires that Employment
Status Code (DN0058) equal ‘9’
(Volunteer) when SROI MTC VE
(Volunteer) is submitted.
Florida will consider this a fatal
error.
176
Invalid Data Relationship Scenario
SROI A49 is being acknowledged
with a TR.
177
Invalid Data Relationship Scenario
1 fatal error was found.
The error segment contains the following:
Employment Status Code
178
Match Data
Element Values Not
Consistent with
Previously
Reported
179
What is a Match data Element?
The Match Data table identifies
primary and secondary match
data elements. These data
elements are used to identify a
transaction as:
a new claim to create, or
180
What is a Match data Element?
an existing claim for updating and
processing and
will be used to match FROI to SROI
for ‘combo’ filings.
Note: Jurisdiction Claim Number (DN 0005)
is required on all filings after the First Report
of Illness or Injury ‘combo’ filing to match to
the existing claim.
181
What is the Edit Process for
Match Data Elements?
The edit process
compares match
data elements on
the incoming
transaction to
match data
elements
previously
submitted.
182
Use MTC 02 Change to report
changes to Match Data Elements
If a change is submitted on a
match data element with any
MTC other than the 02-Change,
the transaction will be rejected
because the key value sent is not
consistent with the value
previously reported.
183
Match Element Values Not Consistent
with Previously Reported Scenario
FL received an MTC 00
Original FROI transaction
with the field Employee ID =
332533333 (SSN)
184
Match Element Values Not Consistent
with Previously Reported Scenario
This report was followed by a MTC 01
Cancel FROI on the same claim with
different data in the field Employee ID
= 332544444 (SSN)
Note: Originally reported Employee ID =
332533333 (SSN)
185
Match Element Values Not
Consistent with Previously Reported
Scenario
EDI processing rules
require a MTC 02 Change
FROI to be submitted when
the match data element
value changes.
186
Match Element Values Not
Consistent with Previously Reported
Scenario
The MTC 02-Change
transaction should have
been sent after the MTC
00/SROI and before the
MTC 01-Cancel.
187
Match Element Values Not
Consistent with Previously Reported
Scenario
Since Employee ID (SSN) is
a “match” element, FL will
consider this a fatal error
and return a TR
(Transaction Rejected)
acknowledgement.
188
Match Element Values Not
Consistent with Previously Reported
A ‘148’ FROI is being
acknowledged with a TR.
189
Match Element Values Not
Consistent with Previously Reported
 1 fatal error was found.
 The error segment contains the
following:
Social Security Number
190
Invalid Event
Sequence
191
Invalid Event Sequence Scenario
When Florida receives an
MTC, we will determine if
that MTC is one we accept,
and if so, will perform
sequencing edits.
192
Invalid Event Sequence Scenario
Sequencing edits are based on
rules defining the sequence in which
business events (MTC) should
occur during the life of a claim (see
Transaction Sequencing table on
Edit Matrix).
Failure of sequencing rules will
result in the transaction being
rejected.
193
Invalid Event Sequence Scenario
In this scenario, FL received a
MTC S1 (Suspension) SROI
transaction, but there is no
record of a MTC IP (Initial
Payment) SROI having been
filed for this claim.
194
Invalid Event Sequence Scenario
Florida’s rules require a MTC IP,
AP or EP SROI transaction to be
filed before benefits can be
suspended (MTC S1).
195
Invalid Event Sequence Scenario
Once the transaction is edited and
determined to be out of sequence,
the AKC transaction will be returned:
with an Application
Acknowledgement Code of ‘TR’
(Transaction Rejected)
with an Element Error Number of
‘063’ (Invalid Event Sequence)
196
Error in Variable
Segment
Error in Variable Segment
Overview
Variable Segment Counters
(‘Number of’ fields in the
segments) contained in the FROI
and SROI records indicate how
many occurrences should be
present for any given segment in
the FROI or SROI records.
198
Error in Variable Segment
Overview
When Florida processes the FROI
or SROI, Florida will:
Edit the data in the Variable
Segments
Keep track of which Variable
Segment they are editing
199
Error in Variable Segment
Overview
If Florida identifies an error in
the variable segments, Florida
will communicate the segment
in which the error occurred by
populating the Variable
Segment Number (DN0117) in
the AKC.
200
Error in Variable Segment
Scenario
In this scenario, the SROI R22
record, Number of Benefits
(DN288), contains the value of
‘02’ which indicates that two
Benefit segments are present
in the SROI.
201
Error in Variable Segment
Scenario
After the transaction is edited, a
fatal error is found on DN0192Benefit Payment Issue Date in
the second benefits segment.
The AKC transaction will
contain the following
information.
202
Error in Variable Segment AKC Record
SROI ‘A49’ SROI is being
acknowledged with a TR.
203
Error in Variable Segment AKC Record
1 Fatal Error.
204
Error in Variable Segment AKC Record
The error is for:
 Element Number 0192 (Benefit Payment
Issue Date – located in Benefits segment)
 Error Number 029 - Must be a valid date
(CCYYMMDD)
205
Error in Variable Segment AKC Record
The error is in the second
occurrence of the Benefits segment,
so the Variable Segment Number
will be ’02’.
206
ALL Questions, either Business or
Technical, should be sent via email
to claims.edi@fldfs.com
This email address is copied to all
members of the EDI team on the next
2 slides, and is also copied to our
Technical Project Manager, Kim
Wiley. It is the quickest and most
efficient way for us to respond to your
concerns.
207
R3 EDI Contacts at DWC
Linda Yon
EDI Coordinator
850-413-1702
linda.yon@fldfs.com
850-413-1703
karen.kubie@fldfs.com
Karen Kubie
Claims EDI
Margaret Forsman
Claims EDI
850-413-1727
margaret.forsman@fldfs.com
208
R3 EDI Contacts at DWC
Tonya Granger
POC & Claims EDI
850-413-1709 tonya.granger@fldfs.com
Debra Lee
Claims EDI
850-413-1701 debra.lee@fldfs.com
Laura Cotner
Claims & POC EDI
850-413-1707 laura.cotner@fldfs.com
209
210