1. 1 Florida Division of Workers Compensation Claims EDI Release 3 Technical Training 2008

2. FL Technical Requirements 69L-56.310, F.A.C.

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

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

5. 5 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 Technical Requirements

6. 6 FL processes transmissions 7 days a week, including holidays.

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

8. 8 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 FROIs and SROIs that are received by the Division on the same day.

9. 9 R3 transactions must be sent to DWC using only the following transmission methods: Advantis Value Added Network (VAN), OR 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 Secure Socket Layer/File Transfer Protocol (SSL/FTP) in accordance with instructions on Form DFS-F5-DWC-EDI-4 FL Technical Requirements

10. 10 Sender ID = Claim Admins/Insurer FEIN + Claim Admins/Insurers Postal Code as reported on: Form DFS-F5-DWC-EDI-1 & EDI-3 FL Technical Requirements

11. 11 NOTE: All 9 digits of the Trading Partners 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.

12. 12 FL Technical Requirements The Sender ID on the Header Record shall represent the insurers or claim administrators FEIN and Postal Code, not that of the vendor.

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

14. 14 Receiver FEIN for FL = 596001874 Receiver Postal Code for FL = 323994226 FL Technical Requirements

15. 15 File Naming Conventions

16. 16 There is no standard file name for Trading Partners using Advantis. Each file is simply a message in the Divisions mail box. However, the Trading Partner must include the FROI/SROI Message Class when they transmit a file (see DWC Receiver Specifications.)

17. 17 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. DFS-F5-DWC- EDI-4 Form: SSL / FTP Instructions for POC EDI and Claims EDIDFS-F5-DWC- EDI-4 Form: SSL / FTP Instructions for POC EDI and Claims EDI FTP File Naming Convention

18. 18 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 claims.edi@fldfs.com

19. 19 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. FTP File Naming Convention

20. Technical Overview

21. 21 Release 3 Records

22. 22 Release 3 Records A Record is a group of related Data Elements that form a transaction. 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

23. 23 Release 3 Records Some Release 3 Records are Fixed length and some are Variable length. Some Release 3 Records are Fixed length and some are Variable length.

24. 24 Release 3 Records Identified by DN0001-Transaction Set ID

25. 25 Fixed Length Record The length of a Fixed Length Record is consistently the same number of data positions each time the record is assembled. Release 3 Records The data within the record is always in the same position within the record, based on the individual record layout.

26. 26 Variable Length Record The length of a Variable Length Record may vary each time the record is assembled. Release 3 Records

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

28. 28 Release 3 Records Although each segment is a fixed length, the total record length will vary depending on the number of segments. Although each segment is a fixed length, the total record length will vary depending on the number of segments. Variable Length Record

29. 29 When a variable length record is sent, the entire segment should be sent, even if there are blanks. 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

30. 30 Release 3 Records Variable Length Records Lets see how it works…

31. 31 Counters determine the overall record length. Release 3 Variable Segments Partial display of SROI R22 record

32. 32 When the transaction includes one Benefits segment, ( Fixed length = 650) Release 3 Variable Segments Partial display of SROI R22 record

33. 33 The Benefits segment = 103 bytes, the R22 record ends at position 753. Release 3 Variable Segments Partial display of SROI R22 record Ben Seg = 103 Bytes

34. 34 Release 3 Records Variable Length Record Lets try one more…

35. 35 Counters determine the overall record length. Release 3 Variable Segments Fixed length = 650 Overall length = 803

36. 36 The transaction includes one Benefits segment and one Suspension Narrative. Release 3 Variable Segments

37. 37 Suspension Narrative = 50 bytes. Benefits segment = 103 bytes; Release 3 Variable Segments

38. 38 The R22 record ends at position 803. Release 3 Variable Segments

39. Transactions

40. 40 Release 3 Transactions consist of 2 records to report a claim event FROI SROI

41. 41 Transaction KEY The Claim Administrator Claim Number (DN0015) is a MANDATORY KEY" used to validate: 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

42. 42 Transaction KEY The Claim Administrator Claim Number (DN0015) ties the records together! The Claim Administrator Claim Number (DN0015) ties the records together! This ensures proper FROI to SROI combo processing. This ensures proper FROI to SROI combo processing.

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

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

45. 45 SROI Companion record relationship is verified by comparing Claim Administrator Claim Number positions 136 to 160 on the A49 record Transaction KEY SROI

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

47. Batches

48. 48 BATCHBATCH Trailer Header FROI Transactions HeaderTrailer FROI Transactions BATCHBATCH 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. FILEFILEFILEFILE

49. 49 BATCHBATCH BATCH: Consists of 1 Header record, one or more Transactions and 1 Trailer record. Note: These would be sent in 2 separate files. Trailer Header FROI Transactions HeaderTrailer SROI Transactions BATCHBATCH

50. 50 Trailer Header FROI Transactions BATCH 148 Rec 1 148 Rec 3 FROI R21 Rec 2 FROI R21 Rec 4 FROI 148 Rec 5 FROI R21 Rec 6 Batch of FROI transactions 8 records; 4 transactions FROI 148 Rec 7 FROI R21 Rec 8

51. 51 Trailer Header SROI Transactions BATCH A49 Rec 1 A49 Rec 3 FROI R22 Rec 2 FROI R22 Rec 4 FROI A49 Rec 5 FROI R22 Rec 6 Batch of SROI transactions 8 records; 4 transactions FROI A49 Rec 7 FROI R22 Rec 8

52. Header Record

53. 53 uniquely identifies the sender (Claim Admin/Insurer), HD1 – Release 3 Header Record and date/time batch was prepared. the receiver (FL),

54. 54 Date Transmission Sent MUST be the same day the file is actually sent to DWC. HD1 – Release 3 Header Record

55. 55 DATE TRANSMISSION SENT – DN0100 Definition: Actual date the batch of data was sent to the receiver. CLAIMS RELEASE 3.0 STANDARDS DATA DICTIONARY HD1 – Release 3 Header Record

56. 56 FL Processing : FL will edit Date Transmission Sent to ensure that the date is within 1 day of receipt (not edited in R1). 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. 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. 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 Record

57. 57 HD1 – Release 3 Header Record Identifies whether the batch contains test or production data and the Interchange Version ID (e.g. 14830).

58. FROI Records

59. 59 148 – 913 Byte Fixed Length Record Release 3 FROI record

60. 60 R21– Variable Length Record Counters determine record length R3 FROI Companion record

61. SROI Records

62. 62 Release 3 SROI record. A49 – Variable Length Record Counters determine record length

63. 63 R3 SROI Companion record R22 – Variable Length Record Counters determine record length

64. Trailer Record

65. 65 TR2 – Release 3 Trailer Record designates the end of a batch of transactions designates the end of a batch of transactions provides a count of records and transactions within a batch provides a count of records and transactions within a batch is used to ensure that the entire batch is complete and valid is used to ensure that the entire batch is complete and valid

66. 66 Pop Quiz: If the Detail Record Count in the Trailer is 6, what would the Transaction Count be? If the Detail Record Count in the Trailer is 6, what would the Transaction Count be?

67. 67 Pop Quiz Answer: If the Detail Record Count in the Trailer is 6, the Transaction Count would be 3.

68. 68 Data Population

69. 69 Prior to population of data elements into the record, all positions are defined as spaces. Data Population This indicates absence of data or no population of data in the field.

70. 70 Data Element Formats The data format becomes applicable only when the data element is populated in the record.

71. 71 Data Element Formats This means that numeric fields that are not being populated should be sent as spaces and not zeros.

72. 72 Data Formats

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

74. 74 Data Element Information

75. 75 Data Element Information Release 3 standard data formats are defined in the System Rules in Section 2 of the Release 3 Implementation Guide. Lets check out the standard data formats… formats…

76. 76 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 Example: 12/01/2007; December 1, 2007, 12-1-07 would be sent as : 20071201 (CCYYMMDD)

77. 77 Data Element Formats All zeros in a date field are considered to be invalid data. All zeros in a date field are considered to be invalid data. 20071201 Dates: Type = DATE: Spaces indicate absence of data, do not zero fill.

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

79. 79 Data Element Formats Time: Type = TIME: The valid values for military time are only (midnight) through 235959. The valid values for military time are only 000000 (midnight) through 235959. Example: HHMMSS: 142903 = 2:29:03 P.M. Spaces indicate absence of data.

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

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

82. 82 Data Element Formats Numeric: Type = N: Example: 3 numeric 123 in 6 byte field = 000123 Spaces indicate absence of data. Negative numbers are not valid. Valid values consist of 0 -9 and are right justified zero filled to the left.

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

84. 84 Data Element Formats Monetary Amounts: Type = $9.2: Valid entries consist of eleven numeric digits with the dollar sign assumed (not populated), and the decimal point between the ninth and tenth position (2 positions from the right) is assumed (not populated). Example: 00000005000 = $50.00 000000050 ^ 00 Spaces indicate absence of data. Negative numbers are not applicable.

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

86. 86 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). Spaces indicate absence of data. Negative numbers are not applicable. Example: 05000 = 50.00% 050 ^ 00

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

88. 88 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 Data Element Formats Alpha numeric: Type = A/N: Spaces indicate absence of data.

89. 89 Data Element Formats Alpha numeric: Type = A/N: When using an alphanumeric field the significant characters are always left justified in the field with any remaining space in the field padded with spaces. SMITH (space)

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

91. 91 Lets start building a SROI transaction

92. 92 Data Element Formats The fixed length portion of the SROI A49 record is 208 bytes. Population of the record starts out with 208 spaces.

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

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

95. 95 Data Element Formats A49 IP 20071201 DN0003 (Maintenance Type Code Date) is an 8 digit DATE field. A valid date replaces the spaces in positions 6 through 13.

96. 96 Data Element Formats In this example, Employee Number of Dependents is required and the Employee has no dependents. The sender populates with zero. 00

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

98. Acknowledgements Florida

99. Acknowledgement Overview

100. 100 What is an Acknowledgement (AKC)? Acknowledgement ElectronicReportClaimAdministrator Florida An AKC transaction is returned by Florida as a result of a transaction sent.

101. 101 What is contained in the Acknowledgement? Enough information to identify the original transaction and any technical and business issues. Enough information to identify the original transaction and any technical and business issues.

102. 102 How does the acknowledgement communicate the status? By DN0111 - Application Acknowledgement Code, which is located in each acknowledgement record. By DN0111 - Application Acknowledgement Code, which is located in each acknowledgement record.

103. 103 What is the Application Acknowledgement Code? A code used to identify the accepted/rejected status of the transaction(s) being acknowledged. A code used to identify the accepted/rejected status of the transaction(s) being acknowledged.

104. 104 Application Acknowledgement Code Values for FL: TA - Transaction Accepted TA - Transaction Accepted TR - Transaction Rejected TR - Transaction Rejected HD – Entire Batch Rejected HD – Entire Batch Rejected (Header or Trailer error) (Header or Trailer error)

105. 105 Transaction Accepted (TA) The transaction was accepted by Florida. The transaction was accepted by Florida. No fatal errors were found on the transaction. 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) Further follow up may be required if non-fatal errors are noted in the FL EDI Online Data Warehouse. (TA-FL)

106. 106 An error was found on a mandatory or mandatory conditional data element. An error was found on a mandatory or mandatory conditional data element. Transaction Rejected (TR) The transaction was not accepted or added to Floridas system as a reported claim. The transaction was not accepted or added to Floridas system as a reported claim.

107. 107 Transaction Rejected (TR) A review of the error should take place to determine what action should be taken to resolve the issue. A review of the error should take place to determine what action should be taken to resolve the issue.

108. 108 An MTC CO (Correction) is not used to respond to a TR acknowledgement, and FL does not accept COs. An MTC CO (Correction) is not used to respond to a TR acknowledgement, and FL does not accept COs. If a transaction rejects, the original MTC must be re-filed (unless wrong MTC was sent). 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. If an error is for a duplicate transaction, invalid event sequence, etc. then resubmission may not be required. Transaction Rejected (TR)

109. 109 The Batch is rejected in its entirety. The Batch is rejected in its entirety. Batch Rejected (HD) When a Batch Reject occurs, only one AKC record will be returned in the acknowledgement batch. When a Batch Reject occurs, only one AKC record will be returned in the acknowledgement batch.

110. 110 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 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 Invalid data in Header Record Duplicate Batch Duplicate Batch Invalid data in Trailer Record Invalid data in Trailer Record Transaction not present in the batch (invalid batch structure) Transaction not present in the batch (invalid batch structure)

111. 111 How does the AKC transaction communicate errors

112. 112 Number of Errors indicate the number of Error Segment occurrences. Number of Errors (DN0114)

113. 113 The Element Number indicates the data element where the error was found. Element Number (DN0115)

114. 114 Element Error Number (DN0116) The Element Error Number identifies the type of error found on an element.

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

116. 116 Variable Segment Number (DN0117) The Claim Administrator must be able to identify the order in which variable segments were sent because FLs 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.

117. 117 Element Error Text (DN0291) The free form Element Error Text describes the error.

118. Acknowledgement Management

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

120. 120 In one day, Claim Admin sends 3 files of FROIs containing 2 batches each (6 FROI batches total). This equates to 6 AKC batches which FL will return in 1 file. Note: SROIs are sent in separate file. Acknowledgement Management

121. 121 Acknowledgement Management The file naming conventions for R3 acknowledgements returned by the Division are: CLMAKC-userid-CCYYMMDD-HHMMSSz.TXT CLMARC-userid-CCYYMMDD-HHMMSSz.TXT Note: The date and time on the AKC and ARC filenames correspond to the date and time (including seconds) the file was created and does not correspond to any original incoming file sent by the trading partner.

122. 122 AKC for each Transaction FROI Example 148Record 1 R21Record 2 148Record 3 R21Record 4 148Record 5 R21Record 6 148Record 7 R21Record 8 Header Trailer FROI Transactions Claim Administrator sends: Header (HD1) Trailer (TR2) AKC TA Record 1 AKC TA Record 2 AKC TR Record 3 AKC TR Record 4 Florida returns:

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

124. 124 Key Data Examples:

125. 125 Record Sequence Number (DN0107) The Claim Admin. must be able to identify the order in which the transactions were sent in the batch, because FLs 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.

126. 126 HEADER RECORD (HD1) for FROI HD1666777888 888777666999999999 23423424220010327074530 P14830 1 2 3 4 5 6 7 8 9 1 12 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 Header Record is used to match the original batch to AKC batch FROI example:

127. 127 Trailer Record is used to match the original batch to AKC batch TRAILER RECORD (TR2) for FROI TR2000000002000000001 TR2000000001000000001 TRAILER RECORD (TR2) for AKC Transaction Count (DN0191) is the total number of transactions sent as part of the batch. The FROI or SROI Transaction Count should be matched to the AKC Transaction Count. The count should be the same. FROI example:

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

129. Acknowledgement File/ Batch Examples

130. 130 AKC Batch Facts Interchange Version ID identifies the batch type: Interchange Version ID identifies the batch type: –AKC30 (Acknowledgement batch) Transaction Set ID values identify the transactions: Transaction Set ID values identify the transactions: –HD1 (Header) –AKC (Acknowledgement) –TR2 (Trailer)

131. 131 AKC Batch Facts The Acknowledgement transaction is a Variable Length record. The Acknowledgement transaction is a Variable Length record.

132. 132 AKC File/Batch Example AKC AKC Trailer Header Header AKC Trailer AKC AKC AKC File

133. 133 Partial display of AKC record AKC Variable Segments Example Partial display of AKC record Number of Errors determine the overall record length The transaction includes two Error segments Error segment = 118 bytes (two 59 byte segments). The AKC record ends at position 366 Fixed length = 248

134. Re-Acknowledgement (ARC)

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

136. 136 ARC Batch Facts Header (HD1) Interchange Version ID is: Header (HD1) Interchange Version ID is: –ARC30 (Re-Acknowledgement batch) Transaction Set ID values with the ARC batch identify the transactions: Transaction Set ID values with the ARC batch identify the transactions: - ARC (Re-processed Transactions) –AKC (Previously Acknowledged Transactions that are unchanged)

137. 137 Caution to Claim Administrators If you choose not to process the Re- Acknowledgement or if your system can not support a 2 nd 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.

138. 138 What is an Re-Acknowledgement (ARC)? Acknowledgement contains TR(s) due to FL error ElectronicReportClaimAdministrator Florida Re-Acknowledgement

139. 139 ARC Example 148Record 1 R21Record 2 148Record 3 R21Record 4 148Record 5 R21Record 6 148Record 7 R21Record 8 Header Trailer FROI Transactions Claim Administrator sends: Header (HD1) ARC30 Trailer (TR2) AKC TA Record 1 ARC TA Record 2 AKC TR Record 3 AKC TR Record 4 Florida returns:

140. Acknowledgement Scenarios

141. Validate Batch- Header Data Elements

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

143. 143 Receiver ID invalid for Florida. Receiver ID invalid for Florida. Date Transmission Sent missing or invalid. Date Transmission Sent missing or invalid. Time Transmission Sent missing or invalid. Time Transmission Sent missing or invalid. Test/Production Code invalid. Test/Production Code invalid. Interchange Version ID invalid. Interchange Version ID invalid. What causes a Batch header error?

144. 144 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 Header record 1 Acknowledgement record 1 Acknowledgement record 1 Trailer record 1 Trailer record

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

146. 146 HD in the Application Acknowledgement Code

147. 147 Number of Errors that were found during the edit process

148. 148 Error Segment Element Number in error Element Number in error Element Error Number for the error Element Error Number for the error Variable Segment Number Variable Segment Number Element Error Text Element Error Text

149. 149 Remaining fields on the AKC (noted in red below) should be spaces.

150. Validate Detail Records

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

152. 152 How does FL do this? Florida will use: Trading partner tables (Event Table, Element Requirement Table, Edit Matrix, etc.) Trading partner tables (Event Table, Element Requirement Table, Edit Matrix, etc.) System Rules to determine the appropriateness of each transaction and ensure data quality System Rules to determine the appropriateness of each transaction and ensure data quality

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

154. 154 How does FL do this? Lets walk through some scenarios…

155. Transaction Accepted (TA)

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

157. 157 Transaction Accepted AKC Record Acknowledgement Transaction Set ID indicates the type of transaction being acknowledged, either 148 for FROI or A49 for SROI. Acknowledgement Transaction Set ID indicates the type of transaction being acknowledged, either 148 for FROI or A49 for SROI.

158. 158 Transaction Accepted AKC Record Application Acknowledgement Code will be TA meaning Transaction Accepted, there were no errors found. Application Acknowledgement Code will be TA meaning Transaction Accepted, there were no errors found.

159. 159 Transaction Accepted AKC Record Number of errors will be 00 which indicates there were no errors found during the edit process. Number of errors will be 00 which indicates there were no errors found during the edit process.

160. 160 Transaction Accepted AKC Record There will be no error segments since Number of Errors = 00. 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. The remaining fields on the AKC should be populated from data on the transaction (148 or A49) being acknowledged.

161. 161 Transaction Rejected (TR) Examples

162. 162 Transaction Rejected for Invalid Mandatory Data Element

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

164. 164 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. Acknowledgement Transaction Set ID indicates the type of transaction is being acknowledged, either 148 for FROI or A49 for SROI.

165. 165 Rejected for Invalid Mandatory Data Element AKC Record Application Acknowledgement Code will be TR meaning Transaction Rejected (Florida did not accept the transaction). Application Acknowledgement Code will be TR meaning Transaction Rejected (Florida did not accept the transaction).

166. 166 Rejected for Invalid Mandatory Data Element AKC Record Number of errors will depend on the number of fatal errors found during the edit process. Number of errors will depend on the number of fatal errors found during the edit process. 01 fatal error was found. 01 fatal error was found.

167. 167 Rejected for Invalid Mandatory Data Element AKC Record Element Number DN 0031 (Date of Injury) Element Number DN 0031 (Date of Injury) The error segment contains:

168. 168 Rejected for Invalid Mandatory Data Element AKC Record Element Error Number 029 - Must be a valid date (CCYYMMDD) Element Error Number 029 - Must be a valid date (CCYYMMDD)

169. 169 Rejected for Invalid Mandatory Data Element AKC Record Variable Segment Number = 00 because data element is not in a Variable Segment Variable Segment Number = 00 because data element is not in a Variable Segment

170. 170 Rejected for Invalid Mandatory Data Element AKC Record Element Error Text provides FL specific error text. Element Error Text provides FL specific error text.

171. 171 Transaction Rejected for Invalid Mandatory Data Element AKC Record Remaining fields on the AKC will be populated from data on the transaction being acknowledged.

172. 172 Lets Look At Some More Acknowledgement Scenarios

173. Invalid Data Relationship

174. 174 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 two or more data elements reported on the same EDI transaction between data on the EDI transaction and data previously reported between data on the EDI transaction and data previously reported

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

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

177. 177 Invalid Data Relationship Scenario SROI A49 is being acknowledged with a TR. SROI A49 is being acknowledged with a TR.

178. 178 Invalid Data Relationship Scenario The error segment contains the following: The error segment contains the following: Employment Status Code 1 fatal error was found. 1 fatal error was found.

179. 179 Match Data Element Values Not Consistent with Previously Reported

180. 180 What is a Match data Element? The Match Data table identifies primary and secondary match data elements. These data elements are used to identify a transaction as: a new claim to create, or a new claim to create, or

181. 181 What is a Match data Element? an existing claim for updating and processing and an existing claim for updating and processing and will be used to match FROI to SROI for combo filings. 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.

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

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

184. 184 Match Element Values Not Consistent with Previously Reported Scenario FL received an MTC 00 Original FROI transaction with the field Employee ID = 332533333 (SSN) FL received an MTC 00 Original FROI transaction with the field Employee ID = 332533333 (SSN)

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

186. 186 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. EDI processing rules require a MTC 02 Change FROI to be submitted when the match data element value changes.

187. 187 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. The MTC 02-Change transaction should have been sent after the MTC 00/SROI and before the MTC 01-Cancel.

188. 188 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. Since Employee ID (SSN) is a match element, FL will consider this a fatal error and return a TR (Transaction Rejected) acknowledgement.

189. 189 Match Element Values Not Consistent with Previously Reported A 148 FROI is being acknowledged with a TR. A 148 FROI is being acknowledged with a TR.

190. 190 1 fatal error was found. 1 fatal error was found. Match Element Values Not Consistent with Previously Reported The error segment contains the following: The error segment contains the following: Social Security Number

191. 191 Invalid Event Sequence

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

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

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

195. 195 Invalid Event Sequence Scenario Floridas rules require a MTC IP, AP or EP SROI transaction to be filed before benefits can be suspended (MTC S1).

196. 196 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 Application Acknowledgement Code of TR (Transaction Rejected) with an Element Error Number of 063 (Invalid Event Sequence) with an Element Error Number of 063 (Invalid Event Sequence)

197. Error in Variable Segment

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

199. 199 When Florida processes the FROI or SROI, Florida will: Edit the data in the Variable Segments Edit the data in the Variable Segments Keep track of which Variable Segment they are editing Keep track of which Variable Segment they are editing Error in Variable Segment Overview

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

201. 201 Error in Variable Segment Scenario In this scenario, the SROI R22 record, Number of Benefits (DN288), contains the value of 02 which indicates that two Benefit segments are present in the SROI.

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

203. 203 Error in Variable Segment AKC Record SROI A49 SROI is being acknowledged with a TR. SROI A49 SROI is being acknowledged with a TR.

204. 204 Error in Variable Segment AKC Record 1 Fatal Error. 1 Fatal Error.

205. 205 Error in Variable Segment AKC Record Element Number 0192 (Benefit Payment Issue Date – located in Benefits segment) Element Number 0192 (Benefit Payment Issue Date – located in Benefits segment) The error is for: Error Number 029 - Must be a valid date (CCYYMMDD) Error Number 029 - Must be a valid date (CCYYMMDD)

206. 206 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. The error is in the second occurrence of the Benefits segment, so the Variable Segment Number will be 02.

207. 207 ALL Questions, either Business or Technical, should be sent via email to claims.edi@fldfs.com 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.

208. 208 R3 EDI Contacts at DWC Linda Yon EDI Coordinator 850-413-1702 linda.yon@fldfs.com linda.yon@fldfs.com Karen Kubie Claims EDI 850-413-1703 karen.kubie@fldfs.com karen.kubie@fldfs.com Margaret Forsman Claims EDI 850-413-1727 margaret.forsman@fldfs.com margaret.forsman@fldfs.com

209. 209 R3 EDI Contacts at DWC Tonya Granger POC & Claims EDI 850-413-1709 tonya.granger@fldfs.com tonya.granger@fldfs.com Debra Lee Claims EDI 850-413-1701 debra.lee@fldfs.com debra.lee@fldfs.com Laura Cotner Claims & POC EDI 850-413-1707 laura.cotner@fldfs.com laura.cotner@fldfs.com

210. 210