2.1k likes | 2.42k Views
Florida Division of Workers’ Compensation Claims EDI Release 3 Technical Training 2008. FL Technical Requirements. 69L-56.310, F.A.C. FL Technical Requirements.
E N D
Florida Division of Workers’ CompensationClaims EDI Release 3 Technical Training2008
FL TechnicalRequirements 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).
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.
FL processes transmissions 7 days a week, including holidays.
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.
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.
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
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
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.
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.
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.
FL Technical Requirements Receiver FEIN for FL = 596001874 Receiver Postal Code for FL = 323994226
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”.)
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 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
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 • 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 Records • Some Release 3 Records are Fixedlength and some are Variablelength.
Release 3 Records Identified by DN0001-Transaction Set ID
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 Records Variable Length Record The length of a “Variable Length Record” may vary each time the record is assembled.
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 Records Variable Length Record Although each segment is a fixed length, the total record length will vary depending on the number of segments.
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 Records Variable Length Records Let’s see how it works…
Release 3 Variable SegmentsPartial display of SROI R22 record Counters determine the overall record length.
Release 3 Variable SegmentsPartial display of SROI R22 record When the transaction includes one Benefits segment, (Fixed length = 650)
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 Records Variable Length Record Let’s try one more…
Release 3 Variable Segments Counters determine the overall record length. Fixed length = 650 Overall length = 803
Release 3 Variable Segments The transaction includes one Benefits segment and one Suspension Narrative.
Release 3 Variable Segments Benefits segment = 103 bytes; Suspension Narrative = 50 bytes.
Release 3 Variable Segments The R22 record ends at position 803.
Release 3 Transactions consist of 2 records toreport a claim event FROI SROI
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 ‘KEY’ • The Claim Administrator Claim Number (DN0015) ties the records together! • This ensures proper FROI to SROI combo processing.
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’ 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 SROI Companion record relationship is verified by comparing Claim Administrator Claim Numberpositions 136 to 160 on the A49 record
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.
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
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
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