Download presentation
Presentation is loading. Please wait.
Published byThomas Ferguson Modified over 10 years ago
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
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.