Florida Division of Workers’  Compensation
Download
1 / 210

FL Claims EDI Release 3 Technical Training PowerPoint Slides - PowerPoint PPT Presentation


  • 267 Views
  • Uploaded on

Florida Division of Workers’ Compensation Claims EDI Release 3 Technical Training 2008. FL Technical Requirements. 69L-56.310, F.A.C. FL Technical Requirements.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'FL Claims EDI Release 3 Technical Training PowerPoint Slides' - Gideon


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

Florida Division of Workers’ CompensationClaims EDI Release 3 Technical

Training2008


Fl technical requirements l.jpg

FL TechnicalRequirements

69L-56.310, F.A.C.


Slide3 l.jpg

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.


Slide4 l.jpg

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


Slide5 l.jpg

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.



Slide7 l.jpg

FL Technical Requirements holidays.

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.


Slide8 l.jpg

FL Technical Requirements holidays.

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.


Slide9 l.jpg

FL Technical Requirements holidays.

  • 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


Slide10 l.jpg

FL Technical Requirements holidays.

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


Slide11 l.jpg

NOTE: holidays. 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.


Slide12 l.jpg

FL Technical Requirements holidays.

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.


Slide13 l.jpg

FL Technical Requirements holidays.

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.


Slide14 l.jpg

FL Technical Requirements holidays.

Receiver FEIN for FL = 596001874

Receiver Postal Code for FL = 323994226



Slide16 l.jpg

There is no standard file name for Trading Partners using holidays.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”.)


Slide17 l.jpg

FTP File Naming Convention holidays.

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-DWC-EDI-4 Form: SSL / FTP Instructions for POC EDI and Claims EDI.


Ftp file naming convention l.jpg
FTP File Naming Convention holidays.

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 [email protected]


Slide19 l.jpg

FTP File Naming Convention holidays.

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”), followed by .TXT.


Technical overview l.jpg

Technical holidays.Overview


Slide21 l.jpg

Release 3 holidays.Records


Release 3 records l.jpg
Release 3 Records holidays.

  • 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


Release 3 records23 l.jpg
Release 3 Records holidays.

  • Some Release 3 Records are Fixedlength and some are Variablelength.


Release 3 records24 l.jpg
Release 3 Records holidays.

Identified by DN0001-Transaction Set ID


Release 3 records25 l.jpg
Release 3 Records holidays.

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 .


Release 3 records26 l.jpg
Release 3 Records holidays.

Variable Length Record

The length of a “Variable Length Record” may vary each time the record is assembled.


Release 3 records27 l.jpg
Release 3 Records holidays.

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.


Release 3 records28 l.jpg
Release 3 Records holidays.

Variable Length Record

Although each segment is a fixed length, the total record length will vary depending on the number of segments.


Slide29 l.jpg

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


Release 3 records30 l.jpg
Release 3 Records should be sent, even if there are blanks.

Variable Length Records

Let’s see how it works…


Release 3 variable segments partial display of sroi r22 record l.jpg
Release 3 Variable Segments should be sent, even if there are blanks.Partial display of SROI R22 record

Counters determine the overall record length.


Release 3 variable segments partial display of sroi r22 record32 l.jpg
Release 3 Variable Segments should be sent, even if there are blanks.Partial display of SROI R22 record

When the transaction includes one Benefits segment,

(Fixed length = 650)


Release 3 variable segments partial display of sroi r22 record33 l.jpg
Release 3 Variable Segments should be sent, even if there are blanks.Partial display of SROI R22 record

The Benefits segment = 103 bytes, the R22 record ends at position 753.

Ben Seg = 103 Bytes


Release 3 records34 l.jpg
Release 3 Records should be sent, even if there are blanks.

Variable Length Record

Let’s try one more…


Release 3 variable segments l.jpg
Release 3 Variable Segments should be sent, even if there are blanks.

Counters determine the overall record length.

Fixed length

= 650

Overall length

= 803


Release 3 variable segments36 l.jpg
Release 3 Variable Segments should be sent, even if there are blanks.

The transaction includes one Benefits segment and one Suspension Narrative.


Release 3 variable segments37 l.jpg
Release 3 Variable Segments should be sent, even if there are blanks.

Benefits segment = 103 bytes;

Suspension Narrative =

50 bytes.


Release 3 variable segments38 l.jpg
Release 3 Variable Segments should be sent, even if there are blanks.

The R22

record ends

at position

803.


Transactions l.jpg

Transactions should be sent, even if there are blanks.


Release 3 transactions consist of 2 records to report a claim event l.jpg
Release 3 should be sent, even if there are blanks.Transactions consist of 2 records toreport a claim event

FROI

SROI


Transaction key l.jpg
Transaction ‘KEY’ should be sent, even if there are blanks.

  • 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


Transaction key42 l.jpg
Transaction ‘KEY’ should be sent, even if there are blanks.

  • The Claim Administrator Claim Number (DN0015) ties the records together!

  • This ensures proper FROI to SROI combo processing.


Transaction key froi l.jpg
Transaction ‘KEY’ FROI should be sent, even if there are blanks.

FROI Companion record relationship is verified by comparing Claim Administrator Claim Number (positions 205 to 229 in the 148 record),….


Transaction key froi44 l.jpg
Transaction ‘KEY’ FROI should be sent, even if there are blanks.

…to positions 24 to 48 on the R21 (next record in the batch). When a match is found, the relationship is confirmed.


Transaction key sroi l.jpg
Transaction ‘KEY’ SROI should be sent, even if there are blanks.

SROI Companion record relationship is verified by comparing Claim Administrator Claim Numberpositions 136 to 160 on the A49 record


Transaction key sroi46 l.jpg
Transaction ‘KEY’ SROI should be sent, even if there are blanks.

to positions 24 to 48 on the R22 (next record in the batch). When a match is found, the relationship is confirmed.


Batches l.jpg

Batches should be sent, even if there are blanks.


Slide48 l.jpg

F I LE should be sent, even if there are blanks.

Header

FROI

Transactions

Header

FROI

Transactions

Trailer

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.

B

A

T

C

H

Trailer

B

A

T

C

H


Slide49 l.jpg

Header should be sent, even if there are blanks.

FROI

Transactions

Header

SROI

Transactions

Trailer

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

Trailer

B

A

T

C

H


Slide50 l.jpg

Header should be sent, even if there are blanks.

Rec 1

148

FROI

Rec 2

R21

Transactions

Rec 3

148

Rec 4

R21

FROI

Rec 5

FROI

148

FROI

Rec 6

FROI

R21

FROI

Rec 7

FROI

148

FROI

Rec 8

FROI

R21

FROI

FROI

FROI

Batch of FROI transactions

8 records; 4 transactions

B

A

T

C

H

FROI

Trailer

FROI


Slide51 l.jpg

Header should be sent, even if there are blanks.

Rec 1

A49

SROI

Rec 2

R22

Transactions

Rec 3

A49

Rec 4

R22

FROI

Rec 5

FROI

A49

FROI

Rec 6

FROI

R22

FROI

Rec 7

FROI

A49

FROI

Rec 8

FROI

R22

FROI

FROI

FROI

Batch of SROI transactions

8 records; 4 transactions

B

A

T

C

H

FROI

Trailer

FROI


Header record l.jpg

Header Record should be sent, even if there are blanks.


Hd1 release 3 header record l.jpg
HD1 – Release 3 Header Record should be sent, even if there are blanks.

uniquely identifies the sender (Claim Admin/Insurer),

the receiver (FL),

and date/time batch was prepared.


Hd1 release 3 header record54 l.jpg
HD1 – Release 3 Header Record should be sent, even if there are blanks.

Date Transmission Sent MUST be the same day the file is actually sent to DWC.


Slide55 l.jpg

HD1 – Release 3 Header Record should be sent, even if there are blanks.

DATE TRANSMISSION SENT – DN0100

Definition: Actual date the batch of data was sent to the receiver.

CLAIMS RELEASE 3.0 STANDARDS DATA DICTIONARY


Slide56 l.jpg

HD1 – should be sent, even if there are blanks.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, to ensure proper “combo” processing.


Hd1 release 3 header record57 l.jpg
HD1 – Release 3 Header Record should be sent, even if there are blanks.

Identifies whether the batch contains test or production data and the

Interchange Version ID (e.g. 14830).


Froi records l.jpg

FROI Records should be sent, even if there are blanks.


Slide59 l.jpg

Release 3 FROI record should be sent, even if there are blanks.

148 – 913 Byte Fixed Length Record


Slide60 l.jpg

R3 FROI Companion record should be sent, even if there are blanks.

R21– Variable Length Record Counters determine record length


Sroi records l.jpg

SROI Records should be sent, even if there are blanks.


Slide62 l.jpg

Release 3 SROI record should be sent, even if there are blanks..

A49 – Variable Length RecordCounters determine record length


Slide63 l.jpg

R22 should be sent, even if there are blanks. – Variable Length RecordCounters determine record length

R3 SROI Companion record


Trailer record l.jpg

Trailer Record should be sent, even if there are blanks.


Slide65 l.jpg

TR2 – Release 3 Trailer Record should be sent, even if there are blanks.

  • 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


Slide66 l.jpg

Pop Quiz: should be sent, even if there are blanks.

If the Detail Record Count in the Trailer is 6, what would the Transaction Count be?


Slide67 l.jpg

Pop Quiz Answer: should be sent, even if there are blanks.

If the Detail Record Count in the Trailer is 6, the Transaction Count would be 3.


Slide68 l.jpg

Data Population should be sent, even if there are blanks.


Slide69 l.jpg

Data Population should be sent, even if there are blanks.

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.


Data element formats l.jpg
Data Element Formats should be sent, even if there are blanks.

The data format becomes applicable only when the data element is populated in the record.


Data element formats71 l.jpg
Data Element Formats should be sent, even if there are blanks.

This means that “numeric” fields that are not being populated should be sent as spaces and not zeros.


Slide72 l.jpg

Data Formats should be sent, even if there are blanks.


Data element formats73 l.jpg
Data Element Formats should be sent, even if there are blanks.

  • Data Element: A single piece of information.

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.


Slide74 l.jpg

Data Element Information should be sent, even if there are blanks.


Slide75 l.jpg

Data Element Information should be sent, even if there are blanks.

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…


Data element formats76 l.jpg
Data Element Formats should be sent, even if there are blanks.

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)


Data element formats77 l.jpg
Data Element Formats should be sent, even if there are blanks.

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.


Data element formats78 l.jpg
Data Element Formats should be sent, even if there are blanks.

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


Data element formats79 l.jpg
Data Element Formats should be sent, even if there are blanks.

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.


Data element formats80 l.jpg
Data Element Formats should be sent, even if there are blanks.

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


Data element formats81 l.jpg
Data Element Formats should be sent, even if there are blanks.

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.


Data element formats82 l.jpg
Data Element Formats should be sent, even if there are blanks.

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.


Data element formats83 l.jpg
Data Element Formats should be sent, even if there are blanks.

Monetary Amounts: Type = $9.2:Data elements that are assigned the format of $9.2 should be populated with only a valid monetary amount.


Data element formats84 l.jpg
Data Element Formats should be sent, even if there are blanks.

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

Monetary Amounts: Type = $9.2:

Example: 00000005000 = $50.00

000000050^00

Spaces indicate absence of data.

Negative numbers are not applicable.


Data element formats85 l.jpg
Data Element Formats should be sent, even if there are blanks.

Percentage (PI): Type = 3.2:Data elements that are assigned the format of 3.2 should be populated with only a valid percentage.

125%


Data element formats86 l.jpg
Data Element Formats should be sent, even if there are blanks.

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.


Data element formats87 l.jpg
Data Element Formats should be sent, even if there are blanks.

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


Data element formats88 l.jpg
Data Element Formats should be sent, even if there are blanks.

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

Alpha numeric: Type = A/N:

Spaces indicate absence of data.


Data element formats89 l.jpg
Data Element Formats should be sent, even if there are blanks.

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.

Alpha numeric: Type = A/N:

SMITH

(space)


Data element formats90 l.jpg
Data Element Formats should be sent, even if there are blanks.

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


Slide91 l.jpg

Lets start building a should be sent, even if there are blanks.SROI transaction


Data element formats92 l.jpg
Data Element Formats should be sent, even if there are blanks.

The fixed length portion of the SROI A49 record is 208 bytes.

Population of the record starts out with 208 spaces.


Data element formats93 l.jpg
Data Element Formats should be sent, even if there are blanks.

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


Data element formats94 l.jpg
Data Element Formats should be sent, even if there are blanks.

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


Data element formats95 l.jpg
Data Element Formats should be sent, even if there are blanks.

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


Data element formats96 l.jpg
Data Element Formats should be sent, even if there are blanks.

In this example, Employee Number of Dependents is required and the Employee has no dependents.

The sender populates with zero.

00


Data element formats97 l.jpg
Data Element Formats should be sent, even if there are blanks.

If the Employee Number of Dependentswas not known or the data element was not required/sent, it would be populated with spaces (another example: PI rating).


Acknowledgements l.jpg

Acknowledgements should be sent, even if there are blanks.

Hey! We got your file!

Florida


Acknowledgement overview l.jpg

Acknowledgement Overview should be sent, even if there are blanks.


What is an acknowledgement akc l.jpg

Electronic should be sent, even if there are blanks.

Report

Acknowledgement

What is an Acknowledgement (AKC)?

An AKC transaction is returned by Florida as a result of a transaction sent.

Claim

Administrator

Florida


What is contained in the acknowledgement l.jpg
What is contained in the Acknowledgement? should be sent, even if there are blanks.

  • Enough information to identify the original transaction and any technical and business issues.


How does the acknowledgement communicate the status l.jpg
How does the acknowledgement communicate the status? should be sent, even if there are blanks.

  • By DN0111 - Application Acknowledgement Code, which is located in each acknowledgement record.


What is the application acknowledgement code l.jpg
What is the Application Acknowledgement Code? should be sent, even if there are blanks.

  • A code used to identify the accepted/rejected status of the transaction(s) being acknowledged.


Slide104 l.jpg

Application Acknowledgement Code Values for FL: should be sent, even if there are blanks.

  • TA - Transaction Accepted

  • TR - Transaction Rejected

  • HD – Entire Batch Rejected

    (Header or Trailer error)


Slide105 l.jpg

Transaction Accepted (TA) should be sent, even if there are blanks.

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


Slide106 l.jpg

Transaction Rejected (TR) should be sent, even if there are blanks.

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


Slide107 l.jpg

Transaction Rejected (TR) should be sent, even if there are blanks.

  • A review of the error should take place to determine what action should be taken to resolve the issue.


Slide108 l.jpg

Transaction Rejected (TR) should be sent, even if there are blanks.

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


Slide109 l.jpg

Batch Rejected (HD) should be sent, even if there are blanks.

  • The Batch is rejected in its entirety.

  • When a Batch Reject occurs, only one AKC record will be returned in the acknowledgement batch.


Slide110 l.jpg

Batch Reject Reasons should be sent, even if there are blanks.

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


Slide111 l.jpg

How does the AKC should be sent, even if there are blanks.

transaction communicate errors


Number of errors dn0114 l.jpg
Number of Errors (DN0114) should be sent, even if there are blanks.

Number of Errors indicate the number of ‘Error Segment’ occurrences.


Element number dn0115 l.jpg
Element Number (DN0115) should be sent, even if there are blanks.

The Element Number indicates the data element where the error was found.


Element error number dn0116 l.jpg
Element Error Number (DN0116) should be sent, even if there are blanks.

The Element Error Number identifies the type of error found on an element.


Variable segment number dn0117 l.jpg
Variable Segment Number (DN0117) should be sent, even if there are blanks.

The Variable Segment Number identifies the occurrence of the variable segment in error. Default when not applicable is 00.


Variable segment number dn0117116 l.jpg
Variable Segment Number (DN0117) should be sent, even if there are blanks.

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.


Element error text dn0291 l.jpg
Element Error Text (DN0291) should be sent, even if there are blanks.

The free form Element Error Text describes the error.


Acknowledgement management l.jpg

Acknowledgement Management should be sent, even if there are blanks.


Acknowledgement management119 l.jpg
Acknowledgement Management should be sent, even if there are blanks.

An acknowledgement batch contains AKC transactions returned by Florida for each transaction that was sent in the original FROI or SROI batch.


Acknowledgement management120 l.jpg
Acknowledgement Management should be sent, even if there are blanks.

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.


Acknowledgement management121 l.jpg
Acknowledgement Management should be sent, even if there are blanks.

The file naming conventions for R3 acknowledgements returned by the Divisionare:

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.


Akc for each transaction froi example l.jpg

Header should be sent, even if there are blanks.

FROI

Transactions

Trailer

AKC for each TransactionFROI Example

Claim Administrator sends:

Florida returns:

Header (HD1)

148 Record 1

AKCTA Record 1

R21 Record 2

148 Record 3

AKCTA Record 2

R21 Record 4

148 Record 5

AKCTR Record 3

R21 Record 6

148 Record 7

AKC TR Record 4

R21 Record 8

Trailer (TR2)


Acknowledgement management123 l.jpg
Acknowledgement Management should be sent, even if there are blanks.

Each acknowledgement record contains various key data to allow the match of the acknowledgement back to the original report sent….


Slide124 l.jpg

Key Data Examples: should be sent, even if there are blanks.


Record sequence number dn0107 l.jpg
Record Sequence Number (DN0107) should be sent, even if there are blanks.

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.


Header record is used to match the original batch to akc batch l.jpg
Header Record is used to should be sent, even if there are blanks.match the original batch to AKC batch

  • HEADER RECORD (HD1) for FROI

  • HD1666777888 888777666999999999 23423424220010327074530 P14830

  • 1 2 3 4 5 6 7 8 9

  • 2 3 4 5 6 7 8 9

  • HD1999999999 234234242666777888 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)

  • 9=Interchange Version ID (DN0105) DIFFERENT

FROI example:


Trailer record is used to match the original batch to akc batch l.jpg
Trailer Record is used to should be sent, even if there are blanks.match the original batch to AKC batch

FROI example:

TRAILER RECORD (TR2) for FROI

TR2000000002000000001

TR2000000001000000001

TRAILER RECORD (TR2) for AKC

The count should be the same.

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 the AKC Transaction Count.


Trailer record validation l.jpg
Trailer Record Validation should be sent, even if there are blanks.

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.


Acknowledgement file batch examples l.jpg

Acknowledgement File/ Batch Examples should be sent, even if there are blanks.


Akc batch facts l.jpg
AKC Batch Facts should be sent, even if there are blanks.

  • Interchange Version ID identifies the batch type:

    • AKC30 (Acknowledgement batch)

  • Transaction Set ID values identify the transactions:

    • HD1 (Header)

    • AKC (Acknowledgement)

    • TR2 (Trailer)


Akc batch facts131 l.jpg
AKC Batch Facts should be sent, even if there are blanks.

  • The Acknowledgement transaction is a Variable Length record.


Slide132 l.jpg

AKC File/Batch Example should be sent, even if there are blanks.

File

Header

AKC

AKC

Trailer

Header

AKC

AKC

AKC

AKC

Trailer


Akc variable segments example partial display of akc record l.jpg

Number of Errors determine the overall record length should be sent, even if there are blanks.

AKC Variable Segments ExamplePartial display of AKC record

Fixed length = 248

The transaction

includes two Error segments

Error segment = 118 bytes (two 59 byte segments). The AKC record ends at position 366


Re acknowledgement arc l.jpg

Re-Acknowledgement (ARC) should be sent, even if there are blanks.


What is a re acknowledgement arc l.jpg
What is a Re-Acknowledgement (ARC)? should be sent, even if there are blanks.

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.


Arc batch facts l.jpg
ARC Batch Facts should be sent, even if there are blanks.

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


Caution to claim administrators l.jpg
Caution to Claim Administrators should be sent, even if there are blanks.

If you choose not to process the Re-Acknowledgement 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.


What is an re acknowledgement arc l.jpg

Electronic should be sent, even if there are blanks.

Report

What is anRe-Acknowledgement (ARC)?

Claim

Administrator

Florida

Acknowledgement contains TR(s) due to FL error

Re-Acknowledgement


Arc example l.jpg

Header should be sent, even if there are blanks.

FROI

Transactions

Trailer

ARC Example

Claim Administrator sends:

Florida returns:

Header (HD1) ARC30

148 Record 1

AKCTA Record 1

R21 Record 2

148 Record 3

ARCTA Record 2

R21 Record 4

148 Record 5

AKCTR Record 3

R21 Record 6

148 Record 7

AKC TR Record 4

R21 Record 8

Trailer (TR2)


Acknowledgement scenarios l.jpg

Acknowledgement Scenarios should be sent, even if there are blanks.


Validate batch header data elements l.jpg

Validate Batch- should be sent, even if there are blanks.Header Data Elements


What happens if a batch has header errors l.jpg
What happens if a batch has header errors? should be sent, even if there are blanks.

  • The entire batch is rejected.

  • The individual transactions in the batch are not processed.


Slide143 l.jpg

What causes a Batch header error? should be sent, even if there are blanks.

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


What will the acknowledgement batch look like if the batch is rejected l.jpg
What will the acknowledgement should be sent, even if there are blanks.‘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


What will the acknowledgement record look like l.jpg
What will the acknowledgement should be sent, even if there are blanks.‘record’ look like?

The acknowledgement record (AKC) for a batch with header errors will contain ‘all zeros’ in the Record Sequence Number.


Slide146 l.jpg

‘HD’ in the Application should be sent, even if there are blanks.

Acknowledgement Code


Number of errors that were found during the edit process l.jpg
Number of Errors that were found during the edit process should be sent, even if there are blanks.


Error segment l.jpg
Error Segment should be sent, even if there are blanks.

  • Element Number in error

  • Element Error Number for the error

  • Variable Segment Number

  • Element Error Text


Slide149 l.jpg

Remaining fields on the AKC (noted in should be sent, even if there are blanks.redbelow) should be spaces.


Validate detail records l.jpg

Validate Detail Records should be sent, even if there are blanks.


Validate detail records151 l.jpg
Validate Detail Records should be sent, even if there are blanks.

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


How does fl do this l.jpg
How does FL do this? should be sent, even if there are blanks.

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


How does fl do this153 l.jpg
How does FL do this? should be sent, even if there are blanks.

As each transaction is edited, FL will assign 1 of the 2 Application Acknowledgement Code values to each AKC transaction; TA or TR.


How does fl do this154 l.jpg
How does FL do this? should be sent, even if there are blanks.

Let’s walk through some scenarios…


Transaction accepted ta l.jpg

Transaction Accepted should be sent, even if there are blanks.(TA)


Transaction accepted scenario l.jpg
Transaction Accepted Scenario should be sent, even if there are blanks.

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.


Transaction accepted akc record l.jpg
Transaction Accepted AKC Record should be sent, even if there are blanks.

  • Acknowledgement Transaction Set ID indicates the type of transaction being acknowledged, either ‘148’ for FROI or ‘A49’ for SROI.


Transaction accepted akc record158 l.jpg
Transaction Accepted AKC Record should be sent, even if there are blanks.

  • Application Acknowledgement Code will be ‘TA’ meaning Transaction Accepted, there were no errors found.


Transaction accepted akc record159 l.jpg
Transaction Accepted AKC Record should be sent, even if there are blanks.

  • Number of errors will be 00 which indicates there were no errors found during the edit process.


Transaction accepted akc record160 l.jpg
Transaction Accepted AKC Record should be sent, even if there are blanks.

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


Slide161 l.jpg

Transaction Rejected should be sent, even if there are blanks.(TR)

Examples


Slide162 l.jpg

Transaction Rejected for Invalid Mandatory Data Element should be sent, even if there are blanks.


Rejected for invalid mandatory data element l.jpg
Rejected for Invalid Mandatory should be sent, even if there are blanks.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.


Rejected for invalid mandatory data element akc record l.jpg
Rejected for Invalid Mandatory Data Element AKC Record should be sent, even if there are blanks.

  • Acknowledgement Transaction Set ID indicates the type of transaction is being acknowledged, either ‘148’ for FROI or ‘A49’ for SROI.


Rejected for invalid mandatory data element akc record165 l.jpg
Rejected for Invalid Mandatory Data Element AKC Record should be sent, even if there are blanks.

  • Application Acknowledgement Code will be ‘TR’ meaning Transaction Rejected (Florida did not accept the transaction).


Rejected for invalid mandatory data element akc record166 l.jpg
Rejected for Invalid Mandatory Data Element AKC Record should be sent, even if there are blanks.

  • Number of errors will depend on the number of fatal errors found during the edit process.

  • 01 fatal error was found.


Rejected for invalid mandatory data element akc record167 l.jpg
Rejected for Invalid Mandatory Data Element AKC Record should be sent, even if there are blanks.

The error segment contains:

  • Element Number DN 0031 (Date of Injury)


Rejected for invalid mandatory data element akc record168 l.jpg
Rejected for Invalid Mandatory Data Element AKC Record should be sent, even if there are blanks.

  • Element Error Number 029 - Must be a valid date (CCYYMMDD)


Rejected for invalid mandatory data element akc record169 l.jpg
Rejected for Invalid Mandatory Data Element AKC Record should be sent, even if there are blanks.

  • Variable Segment Number = 00 because data element is not in a Variable Segment


Rejected for invalid mandatory data element akc record170 l.jpg
Rejected for Invalid Mandatory Data Element AKC Record should be sent, even if there are blanks.

  • Element Error Text provides FL specific error text.


Transaction rejected for invalid mandatory data element akc record l.jpg
Transaction Rejected for Invalid Mandatory Data Element AKC Record

Remaining fields on the AKC will be populated from data on the transaction being acknowledged.




Invalid data relationship overview l.jpg
Invalid Data Relationship Overview Record

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


Invalid data relationship scenario l.jpg
Invalid Data Relationship Scenario Record

In this scenario, Florida received SROI MTC VE (Volunteer) transaction where the Employment Status Code (DN0058) was reported as ‘1’ (Regular/Full-time Employee).


Invalid data relationship scenario176 l.jpg
Invalid Data Relationship Scenario Record

Florida requires that Employment Status Code (DN0058) equal ‘9’ (Volunteer) when SROI MTC VE (Volunteer) is submitted.

Florida will consider this a fatal error.


Invalid data relationship scenario177 l.jpg
Invalid Data Relationship Scenario Record

  • SROI A49 is being acknowledged with a TR.


Invalid data relationship scenario178 l.jpg
Invalid Data Relationship Scenario Record

  • 1 fatal error was found.

  • The error segment contains the following:

Employment Status Code



What is a match data element l.jpg
What is a Match data Element? Reported

The Match Data table identifies primary and secondary match dataelements. These data elements are used toidentify a transaction as:

  • a new claim to create, or


What is a match data element181 l.jpg
What is a Match data Element? Reported

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


What is the edit process for match data elements l.jpg
What is the Edit Process for Match Data Elements? Reported

The edit process compares match data elements on the incoming transaction to match data elements previously submitted.


Use mtc 02 change to report changes to match data elements l.jpg
Use MTC 02 Change to report changes to Match Data Elements Reported

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.


Match element values not consistent with previously reported scenario l.jpg
Match Element Values Not Consistent with Previously Reported Scenario

  • FL received an MTC 00 Original FROI transaction with the field Employee ID = 332533333 (SSN)


Match element values not consistent with previously reported scenario185 l.jpg
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)


Match element values not consistent with previously reported scenario186 l.jpg
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.


Match element values not consistent with previously reported scenario187 l.jpg
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.


Match element values not consistent with previously reported scenario188 l.jpg
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.


Match element values not consistent with previously reported l.jpg
Match Element Values Not Consistent with Previously Reported Scenario

  • A ‘148’ FROI is being acknowledged with a TR.


Match element values not consistent with previously reported190 l.jpg
Match Element Values Not Consistent with Previously Reported Scenario

  • 1 fatal error was found.

  • The error segment contains the following:

Social Security Number



Invalid event sequence scenario l.jpg
Invalid Event Sequence Scenario Scenario

When Florida receives an MTC, we will determine if that MTC is one we accept, and if so, will perform sequencing edits.


Invalid event sequence scenario193 l.jpg
Invalid Event Sequence Scenario 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.


Invalid event sequence scenario194 l.jpg
Invalid Event Sequence Scenario 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.


Invalid event sequence scenario195 l.jpg
Invalid Event Sequence Scenario Scenario

Florida’s rules require a MTC IP, AP or EP SROI transaction to be filed before benefits can be suspended (MTC S1).


Invalid event sequence scenario196 l.jpg
Invalid Event Sequence Scenario 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)



Error in variable segment overview l.jpg
Error in Variable Segment ScenarioOverview

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.


Error in variable segment overview199 l.jpg
Error in Variable Segment ScenarioOverview

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


Error in variable segment overview200 l.jpg
Error in Variable Segment ScenarioOverview

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.


Error in variable segment scenario l.jpg
Error in Variable Segment ScenarioScenario

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.


Error in variable segment scenario202 l.jpg
Error in Variable Segment ScenarioScenario

After the transaction is edited, a fatal error is found on DN0192-Benefit Payment Issue Date in the second benefits segment. The AKC transaction will contain the following information.


Error in variable segment akc record l.jpg
Error in Variable Segment AKC Record Scenario

  • SROI ‘A49’ SROI is being acknowledged with a TR.


Error in variable segment akc record204 l.jpg
Error in Variable Segment AKC Record Scenario

  • 1 Fatal Error.


Error in variable segment akc record205 l.jpg
Error in Variable Segment AKC Record Scenario

The error is for:

  • Element Number 0192 (Benefit Payment Issue Date – located in Benefits segment)

  • Error Number 029 - Must be a valid date (CCYYMMDD)


Error in variable segment akc record206 l.jpg
Error in Variable Segment AKC Record Scenario

  • The error is in the second occurrence of the Benefits segment, so the Variable Segment Number will be ’02’.


Slide207 l.jpg

ALL Questions Scenario, either Business or Technical, should be sent via email to [email protected]

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.


Slide208 l.jpg

R3 EDI Contacts at DWC Scenario

Linda Yon

EDI Coordinator 850-413-1702 [email protected]

Karen Kubie

Claims EDI 850-413-1703 [email protected]

Margaret Forsman

Claims EDI 850-413-1727 [email protected]


Slide209 l.jpg

R3 EDI Contacts at DWC Scenario

Tonya Granger

POC & Claims EDI 850-413-1709 [email protected]

Debra Lee

Claims EDI 850-413-1701 [email protected]

Laura Cotner

Claims & POC EDI 850-413-1707 [email protected]


ad