Section V – Reporting Rules

A. File Control Records

The File Control Record identifies the carrier, the quarter that the data represents, and the number of Transactional, Quarterly, or Key Field Change records being submitted. For each record type, the following is required:

  • A separate file
  • A File Control Record
  • An Electronic Transmittal Record

The File Control Record should be placed at the end of the file.  

File Control Record for Original File

The following illustrates how to submit a File Control Record for an original file. Submit using a Submission File Type Code O—Original on the File Control Record (Record Type Code—03). For record layout and data element details, refer to Section III—Record Layouts—File Control Record Layout of this manual.

Example: Original file submitted

A carrier group (99990) submits an original file on September 21, 2020. The file contains 5,000 Transactional records for Second Quarter 2020. The File Control Record for the original file is completed as follows:

Field No.Field Title/DescriptionReported As
1Record Type03
2Submission File Type CodeO (Original)
3Carrier Group Code99990
4Reporting Quarter Code2
5Reporting Year2020
6Submission File Identifier999902020TRANS
7Submission Date20200921
8Submission Time124233
9Record Total00000005000
10Reserved for Future Use

File Control Record for File Replacement

Data providers may replace an entire file that was previously submitted by using Submission File Type Code “R” (Replacement) on the File Control Record (Record Type Code—03). For record layout and data element details, refer to the File Control Record Layout section in Section V—Record Layouts of this manual.

Example: Replacing a file submitted in error

A carrier group (99990) submitted an original file on September 21, 2020. The file contained 5,000 Transactional records for Second Quarter 2020. On September 23, 2020, the data provider realizes that 3,500 of the Transactional records were submitted with an incorrect Carrier Code. The data provider chooses to submit a replacement instead of submitting 3,500 individual replacement records in a new file. The File Control Record for the replacement file is completed as follows:

Field No.Field Title/DescriptionReported As
1Record Type03
2Submission File Type CodeR (Replacement)
3Carrier Group Code99990 (Same as original file being replaced)
4Reporting Quarter Code2
5Reporting Year2020
6Submission File Identifier9999022020TRANS (Same as original file being replaced)
7Submission Date20200923
8Submission Time155702 (Time that this file was generated)
9Record Total00000005000
10Reserved for Future Use

File Control Record for File Deletion

To delete an entire file and all of its records from PCRB’s database, submit a File Control Record using Submission File Type Code R—Replacement with no other records in the file.

Example: Deleting a file

A carrier group (99990) submits an original file on January 3, 2022. This file contains 200 Quarterly records for Fourth Quarter 2021. On January 14, 2022, the data provider realizes that the Quarterly records were test records and were submitted in error. To delete all of the records in an individual file, submit a File Control Record as follows:

Field No.Field Title/DescriptionReported As
1Record Type03
2Submission File Type CodeR (Replacement)
3Carrier Group Code99990 (Same as file being deleted)
4Reporting Quarter Code4 (Same as file being deleted)
5Reporting Year2022 (Same as file being deleted)
6Submission File Identifier9999042021QTR (Same as file being deleted)
7Submission Date20220114 (Date that this file was generated)
8Submission Time110000 (Time that this file was generated)
9Record Total00000000000 (Do not include the File Control Record in the count)
10Reserved for Future Use

File Control Record for a Key Field Change File

The following illustrates how to submit a File Control Record for a key field change file. Submit using a Submission File Type Code O—Original on the File Control Record (Record Type Code—03). For record layout and data element details, refer to Section 5f—Record Layouts—File Control Record Layout of this manual.

Example: Original file submitted

A carrier group (99990) submits an original file of key field changes in the Third Quarter 2020 on September 21, 2020. The file contains 10 Key Field Change records. The File Control Record for the original file is completed as follows:

Field No.Field Title/DescriptionReported As
1Record Type3
2Submission File Type CodeO (Original)
3Carrier Group Code99990
4Reporting Quarter Code3
5Reporting Year2020
6Submission File Identifier9999032020KEYFIELDCHANGE
7Submission Date20200921
8Submission Time124233
9Record Total00000000010
10Reserved for Future Use

 

B. Transactional Records

The Transactional record contains indemnity benefit payments or transactions for a specific claim that occurred in a given quarter. These are identified by Record Type Code 01—Transactional Record. For record reporting details, refer to Section III—Record Layouts and Section IV—Data Dictionary of this manual.

Reporting Frequency

As stated in Section I—Indemnity Data Call General Rules, Transactional records are due to the PCRB by the end of the quarter following the quarter in which the benefit was paid. However, since transactional records represent benefit payments that can occur at any time throughout the quarter, data providers can choose to report these records daily, weekly, monthly, or quarterly—whichever makes the most sense for the business processes of the data provider.

Example: An indemnity payment is paid on February 2. The Transactional record can be reported as early as February 3, but not later than June 30.

Reporting Triggers

All indemnity claim activities (new claims and existing claims) that occur within a specific quarter, based on the Transaction Date, must be reported by the end of the next quarter. For example:

  • Payments made to the claimant
  • Payments made to the claimant’s attorney
  • Payments made to the claimant’s dependents (spouse or child[ren])
  • Reimbursement of monies previously paid to the claimant
  • Recoveries from a third-party or state-administered fund (e.g., Second Injury Fund)

Indemnity claim activities that occur in April, May or June are reported in the second quarter submission that is due to PCRB by September 30 of the reporting year. For details, refer to the Reporting Frequency section in Section I—General Rules of this manual.

Changes to Transactional Records

Data providers may need to change previously reported transactions, regardless of whether the transactions were reported in an earlier submission or as a prior transaction in the current submission. A few reasons for changing previously reported transactions may include:

  • Voids—A payment made to the claimant, or on the claimant’s behalf, in error
  • Transactional records submitted to the PCRB in error
  • Transactional records with incorrect codes reported to the PCRB
  • Underpayments and overpayments

A data provider has two options for making changes to Transactional records.

  • Option 1—Reporting With the Transaction Identifier (Using the Cancellation and Replacement Transaction Codes
  • Option 2—Reporting Without the Transaction Identifier (Accounting Method)

PCRB recommends the use of Option 1—Reporting With the Transaction Identifier because this is the option that is common across most data types. Examples of how to report using both options are provided below.

Option 1—Reporting With the Transaction Identifier (Using Cancellation and Replacement Codes)

This option requires the use of the Transaction Identifier on every record and uses the Cancellation and Replacement Transaction Codes to process changes to previously reported transactions. The Transaction Identifier is a unique number that is assigned to each individual payment transaction. The Transaction Identifier is then used by PCRB to correctly process the different transaction types.

The Transaction Code (Positions 3–4) is used to identify changes to a Transactional record as follows:

  • Deleting a record—Transaction Code 02—Cancellation
  • Changing a record—Transaction Code 03—Replacement

Cancelling a Transactional Record—Voids and Transactional Records Submitted in Error

To cancel a previously submitted record, submit a Cancellation record with the following:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Transactional Record:

  • Record Type Code 01—Transactional Record (Positions 1–2).
  • Transaction Code 02—Cancellation (Positions 3–4).
  • Transaction Date (Positions 5–12) reported as the date that the information was changed in the source system of the claim administrator.
  • Transaction Identifier (Positions 13–32) as reported on the previous record being cancelled.
  • All key fields (Carrier Code, Policy Number Identifier, Policy Effective Date, Claim Number Identifier, and Accident Date) must be populated. The key fields must match those reported on the previous record to which the cancellation applies.

All other fields in the Transactional Record may be left blank or zero-filled.

Example:

Carrier 99990 made an erroneous payment to a claimant that was reported to PCRB (A) and later voided in the data provider’s payment system. To cancel the Original record from the database, the data provider submits a Cancellation record (B) with all key fields reported the same as the previous record, Transaction Code (02 in lieu of 01), Transaction Date (the date when the cancellation was performed), and Transaction Identifier reported the same as the previous record.

-1-2-3-4-5-6-7-8-9-11-12-13-14
Rec Type CodeTrans CodeTrans DateTransaction IdentifierCarrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A1120201201AE100000199990WC10012018092562019010120201201202012141000003
B1220201217AE100000199990WC100120180925620190101
Not all data elements are shown. For each record of this example, the data in these elements can be blank or zero-filled.

Replacing an Incorrect Code (Non-Key Fields)

Changes via a Replacement record can only be made to non-key fields. To change key fields, refer to Key Field Changes via Cancellation and Part D of this Section.

To change a non-key field for a previously reported record (Original or Replacement), submit a Replacement record with the following:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Transactional Record:

  • Record Type Code 01—Transactional Record (Positions 1-2).
  • Transaction Code 03—Replacement (Positions 3-4)
  • Transaction Date (Positions 5-12) reported as the date that the information was changed in the source system of the claim administrator.
  • Transaction Identifier (Positions 13-32) as reported on the previous record to which the replacement applies.
  • All key fields (Policy Number Identifier, Policy Effective Date, Carrier Code, Claim Number Identifier, and Accident Date) populated. The key fields must match those reported on the previous record to which the change applies.
  • The current transactional values for all non-key fields (not the change in values).

Note: The Replacement record must include all data elements even if they do not change.

Example: Reporting a Benefit Code change

Carrier 99990 submits an Original record (A) with Benefit Type Code 03 in error. To change the Benefit Type Code, the data provider submits a Replacement record (B) using Transaction Code 03, Transaction Date as the date that the change was performed, and the correct Benefit Type Code.

Scenario12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction IdentifierCarrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A010120201201AE100000199990WC1001201809251006201901012020120120201214100003
B010320201215AE100000199990WC1001201809251006201901012020120120201214100004

Example: Reporting a Transaction Amount change (Underpayment)

Carrier 99990 submits an original record (A) with a Scheduled Benefit payment of $1,000. The data provider realizes that they actually paid a Scheduled benefit payment of $1,500. To change the Transaction Amount, the data provider submits a replacement record (B) using Transaction Code 03, Transaction Date as the date the change was performed, and the revised Transaction Amount of $1,500. All fields other than the Transaction Amount as was reported on the original claim (especially the Transaction Identifier).

Scenario12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction IdentifierCarrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A010120201201AE100000199990WC100120180925100620190101202012012020121410000003
B010320201215AE100000199990WC100120180925100620190101202012012020121415000003
Not all data elements are shown. For record B, all key fields must be identical.

Example: Reporting a Transaction Amount change (Overpayment)

Carrier 99990 submits an original record (A) with a Scheduled Benefit payment of $1,000. The data provider realizes that they actually paid a Scheduled benefit payment of $500. To change the Transaction Amount, the data provider submits a replacement record (B) using Transaction Code 03, Transaction Date as the date the change was performed, and the revised Transaction Amount of $500. All key fields and the Transaction Identifier must be reported as they were on the original claim; all other fields should be reported to reflect their correct values.

Scenario12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction IdentifierCarrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A010120201201AE100000199990WC100120180925100620190101202012012020121410000003
B010320201215AE100000199990WC100120180925100620190101202012012020121415000003
Not all data elements are shown. For record B, all key fields must be identical.

Key Field Changes via Cancellation

In order to change a key field on a single previously submitted record, a Cancellation record must first be submitted to remove the record from the database. Refer to Cancelling a Transaction Record in this section of the manual for details.

After cancelling the previously reported record, submit a new record with the following:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Transactional Record:

  • Record Type Code 01—Transactional Record (Positions 1-2)
  • Transaction Code 01—Original (Positions 3-4)
  • Transaction Date (Positions 5-12) reported as the date the information was changed in the source system of the claim administrator
  • Transaction Identifier (Positions 13-32) as reported on the previous record to which the replacement applies
  • All key fields (Carrier Code, Policy Number Identifier, Policy Effective Date, Claim Number Identifier, and Accident Date) populated with the correct information and the previously reported information for any key fields that are not being changed
  • All other fields populated with the correct information.

Example: Changing a key field—via Cancellation (with Transaction Identifier)

Carrier 99990 submits an Original record (A) with an erroneous Claim Number Identifier of 1006. To change the Claim Number Identifier, the data provider first submits a Cancellation record (B), using Option 1, with all the key fields and Transaction Identifier as previously reported (including Claim Number Identifier 1006), Transaction Code 02, and Transaction Date as the date that the cancellation was performed. After submitting the cancellation, the data provider submits a new record (C) with the corrected Claim Number Identifier and all the other key fields as previously reported, Transaction Code 01, and Transaction Date as the date that the change was performed.

Scenario12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction IdentifierCarrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A010120201201AE100000199990WC100120180925100620190101202012012020121410000003
B010220201215AE100000199990WC10012018092510062019010100000
C010120201215AE100000199990WC100120180925620190101202012012020121410000003
Not all data elements are shown. For record B, all non-processing and non-key fields can be blank or zero-filled.

Refer to Part D of this Section for details on changing key fields on all previously reported, impacted records.

Option 2—Reporting Without the Transaction Identifier (Accounting Method)

This option does not use the Transaction Identifier or the Cancellation and Replacement Transaction Codes; rather, it requires the data provider to report multiple Original records to allow the PCRB to correctly process the changes to previously reported transactions.

Deleting a Transactional Record Without the Transaction Identifier—Voids and Transactional Records Submitted in Error

For PCRB to delete a previously submitted record, the data provider must submit a new Original record with the following:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Transactional Record:

  • Record Type Code 01—Transactional Record (Positions 1–2).
  • Transaction Code 01—Original (Positions 3-4)
  • Transaction Date (Positions 5-12) reported as the date that the information was changed in the source system of the claim administrator.
  • Transaction Identifier (Positions 13-32) would be left blank.
  • All key fields (Carrier Code, Policy Number Identifier, Policy Effective Date, Claim Number Identifier, and Accident Date) must be populated. The key fields must match those reported on the previous Original record being deleted.
  • Transaction Amount (Positions 102–113) would be reported as the negative of the original reported amount.
  • Because the Transaction Identifier is not being reported, all other data fields must be reported exactly as the previous Original record to which the adjustment applies; e.g., Jurisdiction State, Transaction From Date, Transaction To Date, Benefit Type Code, etc.

Example: Voids and Transactional Records submitted in error

Carrier 99990 made an erroneous payment to a claimant that was reported to PCRB (A) and later voided in the data provider’s payment system. For PCRB to void the Original record, the data provider must submit a new Original record (B) with all the fields reported the same as the previous Original record except for the Transaction Date (the date when the cancellation was performed) and the Transaction Amount (which should be the negative of the original Transaction Amount reported).

Scenario12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction Identifier (N/A)Carrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A01012020120199990WC100120180925620190101202012012020121410000003
B01012020121799990WC1001201809256201901012020120120201214–0000010000003
Not all data elements are shown. For each record of this example, the data in the unseen elements is identical.

Replacing an Incorrect Code (Non-Key Fields)

For the data provider to report changes to non-key fields without the Transaction Identifier, they must first submit an Original record to offset the original transaction amount (as above), which nullifies the prior record, followed by a new Original record with the following:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Transactional Record:

  • Record Type Code 01—Transactional Record (Positions 1–2).
  • Transaction Code 01—Original (Positions 3-4)
  • Transaction Date (Positions 5-12) reported as the date that the information was changed in the source system of the claim administrator.
  • Transaction Identifier (Positions 13-32) would be left blank.
  • Transaction Amount (Positions 102–113) would be reported with a new dollar amount.
  • All key fields (Policy Number Identifier, Policy Effective Date, Carrier Code, Claim Number Identifier, and Accident Date) populated. The key fields must match those reported on the previous record to which the change applies.
  • The current correct values for all non-key fields.

Example: Changing Benefit Type Code

Carrier 99990 submits an Original record (A) with Benefit Type Code 03 in error. To change the Benefit Type Code, the data provider would first submit an Original record (B) to offset the previous transaction. After submitting the offsetting Original record, the data provider would submit a new Original record (C) with the corrected Benefit Type Code, all the other key fields as previously reported, Transaction Code 01, and Transaction Date as the date that the change was performed.

12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction Identifier (N/A)Carrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A01012020120199990WC100120180925100620190101202012012020121410000003
B01012020121599990WC1001201809251006201901012020120120201214–0000010000003
C01012020121599990WC100120180925100620190101202012012020121410000004
Not all data elements are shown. For record B, all non-processing and non-key fields must be identical to the Original record A.

Correcting an Underpayment or an Overpayment

A data provider can report changes to the Transaction Amount only by reporting a new Original record with the Transaction Amount being either the additional amount paid or the offsetting amount. Submit the new original Transactional record as follows:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Transactional Record:

  • Record Type Code 01—Transactional Record (Positions 1–2).
  • Transaction Code 01—Original (Positions 3-4)
  • Transaction Date (Positions 5-12) reported as the date that the information was changed in the source system of the claim administrator.
  • Transaction Identifier (Positions 13-32) would be left blank.
  • All key fields (Policy Number Identifier, Policy Effective Date, Carrier Code, Claim Number Identifier, and Accident Date) populated. The key fields must match those reported on the previous record to which the change applies.
  • All other unaffected fields populated as originally reported.
  • Transaction Amount (Positions 102–113)—report the additional amount as a positive number or the offset amount as a negative number.

Example: Reporting an Underpayment

Carrier 99990 submits an Original record (A) with a scheduled benefit payment of $1,000. Two weeks later, the data provider makes an additional payment of $500 for the same time period. To report this additional payment transaction, the data provider submits another Original record (B) with the same key fields as the record being changed, Transaction Code 01, and the additional payment value of $500. The Transaction Date for this new Original record is the date that the additional payment was made in the source system of the claim administrator.

Scenario12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction Identifier (N/A)Carrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A01012020120199990WC100120180925620190101202012012020121410000003
B01012020121599990WC10012018092562019010120201201202012145000003
Not all data elements are shown. For each record of this example, the data in the unseen elements is identical to the previous record.

Example: Reporting an Overpayment

Carrier 99990 submits an Original record (A) with a Scheduled Benefit payment of $2,000. Two weeks later, the data provider realizes that they overpaid the claimant by $500. To correct this overpayment, the data provider submits another Original record (B) with the same key fields as the record being changed, Transaction Code 01, and the offset amount of –$500. The Transaction Date for this record is the date the overpayment was offset in the source system of the claim administrator.

Scenario12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction Identifier (N/A)Carrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A01012018120199990WC1001201809250006201901012018120120181214000000020000003
B01012020121599990WC1001201809250006201901012018120120181214-00000005000003
Not all data elements are shown. For each record of this example, the data in the unseen elements is identical to the previous record.

Key Field Changes

For data providers that do not provide Transaction Identifiers to change a key field on a previously submitted record, an Original record must first be submitted to offset the previous record from the database. Refer to Deleting a Transactional Record Without the Transaction Identifier in this section of the manual for details.

After offsetting the previously reported record, submit a new Original record with the following:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Transactional Record:

  • Record Type Code 01—Transactional Record (Positions 1–2)
  • Transaction Code 01—Original (Positions 3–4)
  • Transaction Date (Positions 5–12) reported as the date that the information was changed in the source system of the claim administrator
  • Transaction Identifier (Positions 13–32) would be left blank.
  • All key fields (Carrier Code, Policy Number Identifier, Policy Effective Date, Claim Number Identifier, and Accident Date) populated with the corrected information and the previously reported information for any key fields that are not being changed

All other fields may be blank or zero-filled.

Example: Changing a key field

Carrier 99990 submits an Original record (A) with an erroneous Claim Number Identifier 1006. To change the Claim Number Identifier, the carrier first submits an Original record (B) with Transaction Code 01, Transaction Date as the date that the information was changed in the source system of the claim administrator, and all the other elements as previously reported (including Claim Number Identifier 1006), except for Transaction Amount, which would be reported as the negative of the original amount. After submitting the offsetting record, the data provider submits a new record (C) with Transaction Code 01, Transaction Date as the date that the change was performed, the corrected Claim Number Identifier, and all the other key fields as previously reported.

Scenario12345678911121314
Rec Type CodeTrans CodeTrans DateTransaction Identifier (N/A)Carrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateTransaction From DateTransaction To DateTransaction AmountBenefit Type Code
A01012020120199990WC100120180925100620190101202012012020121400000010000003
B01012020121599990WC1001201809251006201901012020120120201214–0000010000003
C01012020121599990WC100120180925000620190101202012012020121400000010000003
Not all data elements are shown. For record B, the data in the unseen elements is identical to the previous record.

C. Quarterly Records

The Quarterly record is the inception-to-date reporting of an indemnity claim, identified by Record Type Code 02—Quarterly record in the record layout. For record reporting details, refer to Section II—Indemnity Data Call Structure and Section IV—Data Dictionary of this manual.

Reporting Frequency

As stated in Section I—Indemnity Data Call General Rules, Quarterly records are due to PCRB by the end of the quarter following the valuation date. After the valuation date has passed, the Quarterly records can be submitted all together in a single file or in multiple files—whatever suits your business process, as long as they are all submitted on or before the due date.

Reporting Rule

For the following data elements, the Quarterly record reporting rules are based on the Unit Statistical data rules pursuant to PCRB’s Statistical Plan:

  • Carrier Code
  • Policy Number Identifier
  • Policy Effective Date
  • Claim Number Identifier
  • Accident Date
  • Jurisdiction State Code
  • Injury Description Codes—Part of Body, Nature of Injury, and Cause of Injury
  • Incurred Indemnity Amount
  • Incurred Amount Paid-To-Date
  • Incurred Medical Amount
  • Medical Amount Paid-To-Date
  • Employer Legal Amount Paid
  • Allocated Loss Adjustment Expense (ALAE) Amount Paid
  • Act—Loss Condition Code
  • Type of Settlement—Loss Condition Code
  • Classification Code
  • Exposure State Code

Reporting Triggers

A Quarterly record would be reported to PCRB whenever any of the following circumstances occur during a reporting quarter:

  • A new claim has been reported to the insurer and the incurred indemnity amount > 0
  • A Transactional (Original, Replacement, or Cancellation) record is reported within a quarter
  • Amounts for the following data elements change from the prior quarter:
    • Indemnity Amount Paid-To-Date
    • Incurred Indemnity Amount
    • Medical Amount Paid-To-Date
    • Incurred Medical Amount
    • Allocated Loss Adjustment Expense (ALAE) Amount Paid
  • Changes in the Jurisdiction State for a previously reported claim, when the new jurisdiction state is not an applicable Indemnity Data Call state

If a claim becomes medical-only (i.e., the Incurred Indemnity Amount is reduced to zero), then report the Quarterly record corresponding to the quarter in which this change occurred. No additional quarterly records are required to be reported while the claim is medical-only.

For claims that were open prior to the implementation of the Indemnity Data Call, only report the Quarterly records if a new transaction occurs or the amounts for the fields noted above change from the prior quarter. Quarterly reporting is required for newly opened claims (i.e., no payment made or incurred amount established in the prior quarter[s]). Typically, if a Transactional (Original, Replacement, or Cancellation) record is reported within a quarter, a corresponding Quarterly record would be expected as well.

Deleting or Changing Quarterly Records

Data providers may delete or change previously reported Quarterly records.

Deleting a Quarterly Record

Reasons for deleting Quarterly records that were previously submitted may include that the claim is not a workers compensation claim.

To delete a previously submitted Quarterly record, submit a new Quarterly record with the following:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Quarterly Record:

  • Record Type Code 02—Quarterly record (Positions 1–2).
  • Transaction Date (Positions 3–10) reported as the date that the information was deleted in the source system of the claim administrator.
  • All key fields (Policy Number Identifier, Policy Effective Date, Carrier Code, Claim Number Identifier, and Accident Date) populated. The key fields must match those reported on the Quarterly record to be deleted.
  • Zero fill the following financial fields:

Medical Paid-To-Date, Indemnity Paid-To-Date, Incurred Indemnity Amount, Incurred Medical Amount, Allocated Loss Adjustment Expense (ALAE) Amount Paid, and Employer Legal Amount Paid.

Example: Deleting a Quarterly Record

Carrier 99990 submits a Quarterly submission which includes record (A). Two weeks after this submission, the data provider realizes that the claim was not a workers compensation claim. The data provider reports an updated version of the Quarterly record (B) to delete the original Quarterly record.

Scenario123456732333435
Rec Type CodeTrans DateCarrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateMedical Paid-To-DateIncurred Indemnity AmountIncurred Medical AmountEmployer Legal Amount Paid
A022021010199990WC100120180925000620190701000001000000001000000025000000001000
B022021011799990WC100120180925000620190701000000000000000000000000000000000000

Changing a Quarterly Record

To change a previously submitted Quarterly record for the current quarter, submit another Quarterly record with the following:

File Control Record:

  • Record Type Code 03—File Control (Positions 1–2)
  • Submission File Type Code O—Original (Position 3)
  • All other fields in the File Control Record should be populated

Quarterly Record:

  • Record Type Code 02—Quarterly record (Positions 1–2).
  • Transaction Date (Positions 3–10) reported as the date that the information was changed in the system of the claim administrator, which must be greater than or equal to the Transaction Date of the previously submitted record for the current reporting quarter.
  • All key fields (Policy Number Identifier, Policy Effective Date, Carrier Code, Claim Number Identifier, and Accident Date) populated. The key fields must match those reported on the previous record to which the change applies.

The current values for all non-key fields (not the change in value).

Example: Changing Indemnity Paid-To-Date

Carrier 99990 submits a Quarterly record (A) for a claimant that reflects the claimant’s results as of the end of Fourth Quarter 2020. Two weeks later, the data provider realizes that an additional payment was made in Fourth Quarter 2020. The data provider reports an updated version of the Quarterly record (B) to reflect the additional amounts paid.

Scenario123456732333435
Rec Type CodeTrans DateCarrier CodePolicy Number IdentifierPolicy Effective DateClaim Number IdentifierAccident DateMedical Paid-To-DateIncurred Indemnity AmountIncurred Medical AmountEmployer Legal Amount Paid
A022021010199990WC100120180925000620190701000005000000001000000025000000001000
B022021011799990WC100120180925000620190701000007000000001000000025000000002000

Key Field Change Records

They Key Field Change record is used to change key field(s) on all previously reported, impacted indemnity Data Call records (Transactional and/or Quarterly records). These are identified by Record Type 04—Key Field Change. For record details, refer to Section III—Record Layouts and Section—Data Dictionary of this manual. To change a key field on a single Transactional or a single Quarterly record, refer to Part B or C of this Section.

Reporting Frequency

The Key Field Change file and records can be submitted at any time regardless of quarter-end due dates.

Reporting Triggers

A Key Field Change file and record(s) may be reported when one or more of the key fields are reported incorrectly. The Indemnity Data Call key fields are as follows:

  • Carrier Code
  • Policy Number Identifier
  • Policy Effective Date
  • Claim Number Identifier
  • Accident Date

Key Field Change File and Record Reporting Process

When using this option of changing key fields on all previously reported, impacted records through the Key Field Change file and Key Field Change record, the process below must be followed to allow PCRB to apply the key field changes to all affected records in the Indemnity Data Call database:

 

  • Create an Indemnity Data Call .txt file.
  • Add a File Control Record. The File Control Record must be the last record in the Key Field Change file. Refer to Section III—Record Layouts for the File Control Record layout.
  • The File Control Record should be reported as an Original (Submission File Type Code “O”).
  • The Reporting Quarter Code and Reporting Year should reflect the current reporting quarter and year.
  • The Submission File Identifier is a unique identifier that is used to distinguish the file being submitted from previously submitted files.

Please see the Electronic Submission Guidelines on www.pcrb.com for more information.

Each Key Field Change record—Record Type 04 (refer to Section III—Record Layouts for the Key Field Change record)—should contain:

 

  • All five of the previous key fields, as they were reported, for a given claim

All five of these key fields as they should be reported going forward

Once the Key Field Change file is submitted to PCRB, all future associated Transactional records and Quarterly records must be submitted with the new key fields. This will link these records with the previously submitted records that changed because of the Key Field Change file.

If a Key Field Change file is submitted on the same day as other Transactional or Quarterly files, the Key Field Change file should be submitted first, and all subsequent files should have the corrected key fields.

If the Key Field Change file was submitted in error, a new Key Field Change file can be submitted reflecting the correct data. The File Replacement option (using Submission File Type Code “R” for Replacement on the File Control Record) will not be allowed for the Key Field Change file type.