slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Florida Division of Workers’ Compensation Claims EDI Release 3 Technical Training 2008 PowerPoint Presentation
Download Presentation
Florida Division of Workers’ Compensation Claims EDI Release 3 Technical Training 2008

Loading in 2 Seconds...

play fullscreen
1 / 210

Florida Division of Workers’ Compensation Claims EDI Release 3 Technical Training 2008 - PowerPoint PPT Presentation


  • 281 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 'Florida Division of Workers’ Compensation Claims EDI Release 3 Technical Training 2008' - 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
fl technical requirements

FL TechnicalRequirements

69L-56.310, F.A.C.

slide3

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

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

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

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.

slide8

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.

slide9

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
slide10

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

slide11
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.
slide12

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.

slide13

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.

slide14

FL Technical Requirements

Receiver FEIN for FL = 596001874

Receiver Postal Code for FL = 323994226

slide16

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

slide17

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

ftp file naming convention
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

slide19

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

release 3 records
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

release 3 records23
Release 3 Records
  • Some Release 3 Records are Fixedlength and some are Variablelength.
release 3 records24
Release 3 Records

Identified by DN0001-Transaction Set ID

release 3 records25
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 .

release 3 records26
Release 3 Records

Variable Length Record

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

release 3 records27
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.

release 3 records28
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.

slide29
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
Release 3 Records

Variable Length Records

Let’s see how it works…

release 3 variable segments partial display of sroi r22 record
Release 3 Variable SegmentsPartial display of SROI R22 record

Counters determine the overall record length.

release 3 variable segments partial display of sroi r22 record32
Release 3 Variable SegmentsPartial 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
Release 3 Variable SegmentsPartial display of SROI R22 record

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

Ben Seg = 103 Bytes

release 3 records34
Release 3 Records

Variable Length Record

Let’s try one more…

release 3 variable segments
Release 3 Variable Segments

Counters determine the overall record length.

Fixed length

= 650

Overall length

= 803

release 3 variable segments36
Release 3 Variable Segments

The transaction includes one Benefits segment and one Suspension Narrative.

release 3 variable segments37
Release 3 Variable Segments

Benefits segment = 103 bytes;

Suspension Narrative =

50 bytes.

release 3 variable segments38
Release 3 Variable Segments

The R22

record ends

at position

803.

transaction key
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
transaction key42
Transaction ‘KEY’
  • The Claim Administrator Claim Number (DN0015) ties the records together!
  • This ensures proper FROI to SROI combo processing.
transaction key froi
Transaction ‘KEY’ FROI

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

transaction key froi44
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.

transaction key sroi
Transaction ‘KEY’ SROI

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

transaction key sroi46
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.

slide48

F I LE

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

Header

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

Header

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

Header

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

hd1 release 3 header record
HD1 – Release 3 Header Record

uniquely identifies the sender (Claim Admin/Insurer),

the receiver (FL),

and date/time batch was prepared.

hd1 release 3 header record54
HD1 – Release 3 Header Record

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

slide55

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

slide56

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, to ensure proper “combo” processing.
hd1 release 3 header record57
HD1 – Release 3 Header Record

Identifies whether the batch contains test or production data and the

Interchange Version ID (e.g. 14830).

slide59

Release 3 FROI record

148 – 913 Byte Fixed Length Record

slide60

R3 FROI Companion record

R21– Variable Length Record Counters determine record length

slide62

Release 3 SROI record.

A49 – Variable Length RecordCounters determine record length

slide65

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
slide66

Pop Quiz:

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

slide67

Pop Quiz Answer:

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

slide69

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.

data element formats
Data Element Formats

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

data element formats71
Data Element Formats

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

data element formats73
Data Element Formats
  • 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.

slide75

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…

data element formats76
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)

data element formats77
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.

data element formats78
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

data element formats79
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.

data element formats80
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).

data element formats81
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.

data element formats82
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.

data element formats83
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.

data element formats84
Data Element Formats

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

data element formats86
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.

data element formats87
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

data element formats88
Data Element Formats

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
Data Element Formats

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

data element formats92
Data Element Formats

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

Population of the record starts out with 208 spaces.

data element formats93
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

data element formats94
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

data element formats95
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

data element formats96
Data Element Formats

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

The sender populates with zero.

00

data element formats97
Data Element Formats

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

Acknowledgements

Hey! We got your file!

Florida

what is an acknowledgement akc

Electronic

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
What is contained in the Acknowledgement?
  • Enough information to identify the original transaction and any technical and business issues.
how does the acknowledgement communicate the status
How does the acknowledgement communicate the status?
  • By DN0111 - Application Acknowledgement Code, which is located in each acknowledgement record.
what is the application acknowledgement code
What is the Application Acknowledgement Code?
  • A code used to identify the accepted/rejected status of the transaction(s) being acknowledged.
slide104
Application Acknowledgement Code Values for FL:
  • TA - Transaction Accepted
  • TR - Transaction Rejected
  • HD – Entire Batch Rejected

(Header or Trailer error)

slide105

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

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

Transaction Rejected (TR)

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

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

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

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)
slide111
How does the AKC

transaction communicate errors

number of errors dn0114
Number of Errors (DN0114)

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

element number dn0115
Element Number (DN0115)

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

element error number dn0116
Element Error Number (DN0116)

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

variable segment number dn0117
Variable Segment Number (DN0117)

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

variable segment number dn0117116
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.

element error text dn0291
Element Error Text (DN0291)

The free form Element Error Text describes the error.

acknowledgement management119
Acknowledgement Management

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

acknowledgement management120
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.

acknowledgement management121
Acknowledgement Management

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

Header

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
Acknowledgement Management

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

record sequence number dn0107
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.

header record is used to match the original batch to akc batch
Header Record is used tomatch 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
Trailer Record is used tomatch 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
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.

akc batch facts
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)
akc batch facts131
AKC Batch Facts
  • The Acknowledgement transaction is a Variable Length record.
slide132

AKC File/Batch Example

File

Header

AKC

AKC

Trailer

Header

AKC

AKC

AKC

AKC

Trailer

akc variable segments example partial display of akc record
Number of Errors determine the overall record lengthAKC 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

what is a 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.

arc batch facts
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)
caution to claim administrators
Caution to Claim Administrators

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

Electronic

Report

What is anRe-Acknowledgement (ARC)?

Claim

Administrator

Florida

Acknowledgement contains TR(s) due to FL error

Re-Acknowledgement

arc example

Header

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)

what happens if a batch has header errors
What happens if a batch has header errors?
  • The entire batch is rejected.
  • The individual transactions in the batch are not processed.
slide143

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.
what will the acknowledgement batch look like if the batch is rejected
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
what will the acknowledgement record look like
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.

slide146
‘HD’ in the Application

Acknowledgement Code

error segment
Error Segment
  • Element Number in error
  • Element Error Number for the error
  • Variable Segment Number
  • Element Error Text
validate detail records151
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).

how does fl do this
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

how does fl do this153
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.

how does fl do this154
How does FL do this?

Let’s walk through some scenarios…

transaction accepted scenario
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.

transaction accepted akc record
Transaction Accepted AKC Record
  • Acknowledgement Transaction Set ID indicates the type of transaction being acknowledged, either ‘148’ for FROI or ‘A49’ for SROI.
transaction accepted akc record158
Transaction Accepted AKC Record
  • Application Acknowledgement Code will be ‘TA’ meaning Transaction Accepted, there were no errors found.
transaction accepted akc record159
Transaction Accepted AKC Record
  • Number of errors will be 00 which indicates there were no errors found during the edit process.
transaction accepted akc record160
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.
rejected for invalid mandatory data element
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.

rejected for invalid mandatory data element akc record
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.
rejected for invalid mandatory data element akc record165
Rejected for Invalid Mandatory Data Element AKC Record
  • Application Acknowledgement Code will be ‘TR’ meaning Transaction Rejected (Florida did not accept the transaction).
rejected for invalid mandatory data element akc record166
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.
rejected for invalid mandatory data element akc record167
Rejected for Invalid Mandatory Data Element AKC Record

The error segment contains:

  • Element Number DN 0031 (Date of Injury)
rejected for invalid mandatory data element akc record168
Rejected for Invalid Mandatory Data Element AKC Record
  • Element Error Number 029 - Must be a valid date (CCYYMMDD)
rejected for invalid mandatory data element akc record169
Rejected for Invalid Mandatory Data Element AKC Record
  • Variable Segment Number = 00 because data element is not in a Variable Segment
rejected for invalid mandatory data element akc record170
Rejected for Invalid Mandatory Data Element AKC Record
  • Element Error Text provides FL specific error text.
transaction rejected for invalid mandatory data element akc record
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
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
invalid data relationship scenario
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).

invalid data relationship scenario176
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.

invalid data relationship scenario177
Invalid Data Relationship Scenario
  • SROI A49 is being acknowledged with a TR.
invalid data relationship scenario178
Invalid Data Relationship Scenario
  • 1 fatal error was found.
  • The error segment contains the following:

Employment Status Code

what is a match data element
What is a Match data Element?

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

what is the edit process for match data elements
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.

use mtc 02 change to report changes to match data elements
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.

match element values not consistent with previously reported scenario
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
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
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
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
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
Match Element Values Not Consistent with Previously Reported
  • A ‘148’ FROI is being acknowledged with a TR.
match element values not consistent with previously reported190
Match Element Values Not Consistent with Previously Reported
  • 1 fatal error was found.
  • The error segment contains the following:

Social Security Number

invalid event sequence scenario
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.

invalid event sequence scenario193
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.

invalid event sequence scenario194
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.

invalid event sequence scenario195
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).

invalid event sequence scenario196
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)
error in variable segment overview
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.

error in variable segment overview199
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
error in variable segment overview200
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.

error in variable segment scenario
Error in Variable SegmentScenario

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
Error in Variable SegmentScenario

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
Error in Variable Segment AKC Record
  • SROI ‘A49’ SROI is being acknowledged with a TR.
error in variable segment akc record205
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)
error in variable segment akc record206
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’.
slide207

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.

slide208

R3 EDI Contacts at DWC

Linda Yon

EDI Coordinator 850-413-1702 linda.yon@fldfs.com

Karen Kubie

Claims EDI 850-413-1703 karen.kubie@fldfs.com

Margaret Forsman

Claims EDI 850-413-1727 margaret.forsman@fldfs.com

slide209

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