Section VI – Editing and Other Validation Procedures
A. Editing Process
The DCRB’s editing process is performed to ensure that the data provider’s data is consistent with reporting requirements and meets quality standards. The edit process for the Indemnity Data Call is based on file acceptance and three quality components:
- Population tests (e.g., are the data elements appropriately reported?)
- Validation tests (e.g., are the data elements populated with valid values?)
- Reasonableness tests (e.g., is the distribution of data elements reasonable?)
These tests will be performed on each data element and across Call elements where needed.
B. File Acceptance
Call submissions are evaluated at the data element level based on File Acceptance submission level edits and authentication. File Acceptance submission level edits and authentication will either accept or reject the entire file.
File Acceptance submission level edits determine whether:
- The file name is valid per file naming conventions
- The data provider is authorized to report the Indemnity Data Call and to submit for the Carrier Group Code
- The record length is correct and contains only valid characters
- The file contains a File Control Record, there is only one File Control Record per file, the File Control Record is the last record in the file, and the File Control Record is not a duplicate
- A separate file and File Control Record are required for Transactional records, a separate file and File Control Record are required for Quarterly records, and a separate file and File Control record are required for Key Field Change records.
- The Submission File Type is valid
- The Submission Date is valid
- The Reporting Quarter is valid
- The Reporting Year is valid
- The Record Totals are valid and match the number of records in the file
- The replacement file identifier matches a previously submitted file identifier
- The Submission Date and Submission Time on a replacement file are later than those on the file it is intended to replace
C. Record Acceptance
Record acceptance editing checks to ensure that the key fields (Accident Date, Carrier Code, Claim Number Identifier, Policy Effective Date, and Policy Number Identifier) and the processing elements (Record Type Code, Transaction Code, Transaction Date, and Transaction Identifier) are being reported correctly. If any of these elements are missing or invalid, the edits will return the corresponding record. These records, along with their associated edits, will be available for the carrier to download and determine if a correction to a system or process is required.
Record-level editing will be performed, and results will be captured at the data element level in the aggregate. Using data elements categories, the editing process will determine the overall quality of the Indemnity Data Call. Each data element is evaluated against one or more edits and either passes or fails each edit. For each data element, if any edit fails, the transaction is counted and the record is rejected. Varying thresholds will be created based on the specific data element within each of the element categories. If the records rejected is greater than the tolerance threshold, the entire file will reject.
Refer to Quality Tracking in this Section of the Manual for data element category descriptions.
D. Quality Tracking
Quality Tracking is the stage of the editing process that allows a data provider to gauge the quality of the data they are reporting. Records that have passed both the File Acceptance and Record Acceptance stages of editing will be incorporated into the Quality Tracking stage. This stage of editing checks the population and validity of the remaining data elements in the Transactional and Quarterly records. DCRB will then count the occurrences of these edits. The resulting percentages will be reviewed by the Indemnity Data Call validators to determine outreach.
Each data element is evaluated against one or more edits and either passes or fails each edit. For each data element, if any edit fails, the transaction is counted and the number of transactions that fail is evaluated against a tolerance threshold based on the element category (Required, Critical, Priority, or Low).
Data element categories are defined as follows:
- Critical (C) – Indicates that the data element is of critical importance. Elements in this category have a very low tolerance for missing or invalid data. For example, a tolerance of .1% would indicate that the data element can only be missing or invalid for 100 out of 100,000 records. Records with missing or invalid critical elements above this tolerance level are not viable for Call use.
- Priority (P) – Indicates that the data element is very important but the record can still be of some value even with this data element missing. An example of a Priority – tolerance level is in the range of 1%-5%.
- Low (L) – Indicates that the record is still useful when this data element is missing. An example of a Low tolerance level is in the range of 10% – 20%.
- Relational (R) – Indicates the relationship of one data element in relation to another data element as a reasonability test.
- Required – Indicates that the data element must be provided for file acceptance and data processing.
- Required – ETR – Indicates that the Electronic Transmittal Record (ETR) contains all the data elements required for file acceptance and data processing.
- Required – File Control Record – Indicates that the File Control Record contains all the data elements required for file acceptance and data processing.
| Record | Field Type | Category | Conditional** |
|---|---|---|---|
| All | Accident Date* | R | |
| All | Carrier Code* | R | |
| All | Claim Number Identifier* | R | |
| All | Policy Effective Date* | R | |
| All | Policy Number Identifier* | R | |
| All | Record Type Code | R | |
| Transactional and Quarterly | Transaction Date | R | |
| Quarterly | Indemnity Claim Code | R | |
| Transactional | Transaction Code | R | |
| Transactional | Transaction Identifier | R | Yes |
| Transactional and Quarterly | Jurisdiction State Code | C | |
| Quarterly | Act—Loss Condition Code | C | |
| Quarterly | Attorney or Authorized Representative Indicator | C | |
| Quarterly | Cause of Injury Code—Injury Description | C | |
| Quarterly | Classification Code | C | |
| Quarterly | Incurred Indemnity Amount | C | |
| Quarterly | Incurred Medical Amount | C | |
| Quarterly | Indemnity Paid-to-Date | C | |
| Quarterly | Medical Paid-to-Date | C | |
| Quarterly | Nature of Injury Code—Injury Description | C | |
| Quarterly | Part of Body Code—Injury Description | C | |
| Quarterly | Pre-Injury/Average Weekly Wage Amount | C | |
| Transactional | Benefit Type Code | C | |
| Transactional | Lump-Sum Indicator | C | |
| Transactional | Transaction Amount | C | |
| Quarterly | Disability/Loss of Earnings Capacity (LOEC) Percentage | C | Yes |
| Quarterly | Impairment Percentage | C | Yes |
| Quarterly | Impairment Percentage Basis Code | C | Yes |
| Quarterly | Maximum Medical Improvement (MMI) Date | C | Yes |
| Quarterly | Temporary Disability Benefit Extinguishment Code | C | Yes |
| Quarterly | Type of Settlement—Loss Condition Code | C | Yes |
| Transactional | Transaction From Date | C | Yes |
| Transactional | Transaction To Date | C | Yes |
| Quarterly | Accident State Code | P | |
| Quarterly | Birth Year | P | |
| Quarterly | Exposure State Code | P | |
| Quarterly | Method of Determining Pre-Injury/Average Weekly Wage Amount | P | |
| Transactional | Weekly Benefit Amount | P | |
| Quarterly | Allocated Loss Adjustment Expense (ALAE) Paid | P | Yes |
| Quarterly | Employer Legal Amount Paid | P | Yes |
| Quarterly | Medical Extinguishment Indicator | P | Yes |
| Quarterly | Pre-existing Disability Percentage | P | Yes |
| Quarterly | Return to Work Date | P | Yes |
| Transactional | Benefit Offset Amount | P | Yes |
| Transactional | Benefit Offset Code | P | Yes |
| Quarterly | Claimant Gender Code | L | |
| Quarterly | Employment Status Code | L | |
| Quarterly | Hire Date | L | |
| Quarterly | Reported to Insurer Date | L | |
| Quarterly | Zip Code of Injury Site | L | |
| Quarterly | Closing Date | L | Yes |
| Quarterly | Number of Dependents | L | Yes |
| Quarterly | Reopen Date | L | Yes |
| Key Field Change | Previous Carrier Code | R | |
| Key Field Change | Previous Policy Number Identifier | R | |
| Key Field Change | Previous Policy Effective Data | R | |
| Key Field Change | Previous Claim Number Identifier | R | |
| Key Field Change | Previous Accident Date | R |
**Conditional—Indicates that the data element must be provided but is conditional on state-mandated criteria or dependent on a specific condition or set of conditions. This element must be valid if populated.
*This data element is considered a key field and is required to be reported the same as on the original record for all records related to a claim. Refer to key fields in Section II—Indemnity Data Call Structure of this manual.
E. Quarter-End Validation
Quarter End Validation is the final stage of the validation process.
During the Quarter End Validation stage, Quality Tracking edits, for all the indemnity data providers reporting for the carrier group, are summarized for the entire quarter’s data, developing quality statistics across all submissions. Refer to Quality Tracking in this Part for details. Additional relational edits are performed in this stage.
Relational edits check the entire submission for completeness and reasonability. For example, the Attorney and Authorized Representative Flag is set to “Y” when there has been at least one payment for Benefit Type Code 20—Claimant Legal Amount Paid.
The Quality Tracking and additional Quarter End edit failures are aggregated, and the results are provided at the Group level. For each data element, if any edit fails, the transaction is counted and the number of transactions that fail are evaluated against a tolerance threshold based on the element and the element category (Record Acceptance, Critical, Priority, or Supplemental).
Completeness statistics and quality observations are made regarding the reasonability of the data aggregated across all submissions for the entire quarter.
F. Indemnity Data Call Edit Matrix
- Indemnity Data Call Edit Matrix—All Edits in Production
- The Indemnity Data Call Edit Matrix—All Edits in Production contains details on the enhanced editing process that currently takes place in the DCRB’s database. This online edit matrix is the most comprehensive resource for information on the DCRB’s Indemnity Data Call editing and can be used when monitoring quality tracking and quarter end validation to obtain the details on each edit. It is updated frequently to ensure the most current editing information.The Indemnity Data Call Edit Matrix—All Edits in Production can be found in the Indemnity Data Reporting section of the DCRB’s website, www.dcrb.com.
- Indemnity Data Call Edit Matrix—Future Edit Enhancements
- The Indemnity Data Call Edit Matrix—Future Edit Enhancements contains edits scheduled for future implementation. This edit matrix provides you with lead time and projected implementation dates for planned changes to Indemnity Data Call editing. This advanced information can be used for planning purposes.The Indemnity Data Call Edit Matrix—Future Edit Enhancements has not been established since all the edits are currently contained in the Indemnity Data Call Edit Matrix.
- Online Edit Matrix Updates
- When changes are made to the Indemnity Data Call Edit Matrix, carriers will be notified.