Section VI - Editing and Other Validation Procedures
A. Editing Process
The PCRB’s editing process is performed to ensure that the medical data provider’s data is consistent with reporting requirements and that it meets quality standards. The edit process for the Medical Data Call is based on three quality components:
-
- Completeness test (e.g., are the data elements appropriately populated?)
- Validation test (e.g., are the data elements populated with valid values?)
- Reasonableness test (e.g., is the distribution of data elements reasonable?)
These tests will be performed within each data element and across Call elements where needed. Editing for the Call is performed within this data type and does not include cross-data type editing.
B. Validating a Submission
Using data element tolerance levels, the editing process determines the overall quality of the Medical Data Call. Data element tolerance levels 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.
Below are the edits and their associated tolerance levels that will be performed on each data element:
| Field No. | Data Element | Tolerance/Edit |
| 1 | Carrier Code* | Required for file acceptance |
| 2 | Policy Number Identifier* | Required for file acceptance |
| 3 | Policy Effective Date* | Required for file acceptance |
| 4 | Claim Number Identifier* | Required for file acceptance |
| 5 | Transaction Code | Required for file acceptance |
| 6 | Jurisdiction State Code | C |
| 7 | Claimant Gender Code | L |
| 8 | Birth Year | L |
| 9 | Accident Date | C |
| 10 | Transaction Date | Required for file acceptance |
| 11 | Bill Identification Number* | Required for file acceptance—Must be unique |
| 12 | Line Identification Number* | Required for file acceptance—Must be unique |
| 13 | Service Date | R—Must be populated if Service From Date and Service To Date are missing. Must be valid if populated. |
| 14 | Service From Date | R —Must be populated if Service Date is missing. Must be valid if populated. |
| 15 | Service To Date | R—Must be populated if Service Date is missing and Service From Date is populated. Must be valid if populated. |
| 16 | Paid Procedure Code | P—Must be formatted correctly. Codes validated against procedure codes |
| 17 | Paid Procedure Code Modifier | P—Validated against a table of valid values. Cannot be missing for every record |
| 18 | Amount Charged by Provider | C—Must be greater than zero |
| 19 | Paid Amount | C—Must be greater than or equal to zero |
| 20 | Primary ICD -- Diagnostic Code | P—Codes validated against valid ICD -- Diagnostic codes |
| 21 | Secondary ICD -- Diagnostic Code | L—Cannot be missing for every record |
| 22 | Provider Taxonomy Code | P—Must be a valid code |
| 23 | Provider Identification Number | P—Priority tolerance where required by state mandate |
| 24 | Provider Postal (ZIP) Code | P/O—Not required if Provider Postal (ZIP+4) Code is reported (Field 29.) |
| 25 | Network Service Code | P |
| 26 | Quantity/Number of Units per Procedure Code | P—Must be numeric |
| 27 | Place of Service Code | P—Must be a valid code |
| 28 | Secondary Procedure Code | R—Must be valid if populated |
| 29 | Provider Postal (ZIP+4) Code | P—Must be populated with 5-digit ZIP code or 9-digit ZIP+4 code. PCRB will validate the first five digits of the ZIP code. |
| Field No. | Key Field Change Data Element | Data Element Category/Edit |
| 1 | Previous Carrier Code* | Required for record acceptance |
| 2 | Previous Policy Number Identifier* | Required for record acceptance |
| 3 | Previous Policy Effective Date* | Required for record acceptance |
| 4 | Previous Claim Number Identifier* | Required for record acceptance |
| 5 | Transaction Code | Required for record acceptance |
| 6 | Carrier Code* | Required for record acceptance |
| 7 | Policy Number Identifier* | Required for record acceptance |
| 8 | Policy Effective Date* | Required for record acceptance |
| 9 | Claim Number Identifier* | Required for record acceptance |
*This data element is considered a key field and must be reported the same as on the original record for all records related to a medical transaction (line). Refer to Key Fields in the Medical Data Call Structure section of this manual.
1. Edit Types
Each Medical Data Call edit is classified into one of the edit types—submission, field, logical, or relational edits:
- Submission edits ensure that the file record length is correct, data provider information is valid, a File Control Record exists, and the record count balances
- Field edits ensure that the data contained in each data field is acceptable
- Logical edits verify that the data makes sense in relation to one or more other fields on the same report
- Relational edits compare the data in a specific field on the report with another data field contained in the same report submission and/or with a corresponding medical report that was previously submitted and already stored on the PCRB’s database
2. File Acceptance
Every Medical Data Call file received by the PCRB goes through three stages of editing. File Acceptance, the first stage of the editing process, includes submission, field, and relational level edits to determine whether the PCRB can process the file. Refer to Edit Types in this section for edit type descriptions.
In the File Acceptance stage, the entire field is either accepted or rejected.
File Acceptance submission level edits determine whether the:
- File name is valid per file naming conventions
- Data reporter is authorized to report Medical Call data and to submit for the Carrier Group Code
- Record length is correct and contains only valid characters
- File contains a File Control Record, there is only one File Control Record per file, and the File Control Record is not a duplicate
- Submission File Type is valid
- Reporting Quarter is valid
- Reporting Year is valid
- Submission Date is valid
- Record Total is valid and matches the number of records in the file
- Replacement file matches a previously submitted file
- Submission Date and Submission Time on a replacement file are later than the file it is intended to replace
Files that fail submission level edits are rejected and not processed. The medical data provider is notified that the file rejected.
To ensure the completeness and validity of the required fields, field and relational level edits are also performed during this stage on any field that is identified as “Required for File Acceptance.” Refer to Validating a Submission in this section for data element tolerance descriptions. The required fields include the – key fields (Carrier Code, Policy Number Identifier, Policy Effective Date, Claim Number Identifier, Bill Identification Number, and Line Identification Number) plus Transaction Code and Transaction Date.
- Field edits ensure the completeness and validity of each data element. For example, Carrier Code cannot be missing and must be a valid PCRB Carrier Code.
- Relational edits check for acceptable relationships between elements on different records, either within the submission or on the PCRB’s database. For example, a Cancellation record (Transaction Code 02) must have an associated Original record (Transaction Code 01) or Replacement record (Transaction Code 03) in the submission or on the PCRB’s database.
When a required field fails an edit, the percentage of edit failure occurrences are counted and compared to tolerance levels. If the percentage of edit failure occurrences is greater than the tolerance, the file will be rejected, and the medical data provider is notified that the file was rejected. If the number of edit failure occurrences is below tolerance, the PCRB will return those records that failed to the data submitter. If more than 1,000 records are rejected (but the file is still accepted) only the first 1,000 records will be returned to the data submitter. The records will be returned via a data download option in the Submission Tracking section of the Medical Data Call Manager online application.
Data providers should review all rejected files and all returned records to identify and correct issues in their source systems.
Once a file passes the File Acceptance stage, all records, except those returned, will be processed.
File Acceptance
| Edit Types | Description | Edit Failure Results |
| Submission | Enables the PCRB to process the file | Reject file |
| Field (required fields) | Ensures complete and valid entry | Greater than tolerance = Reject file Below tolerance = Return record |
| Relational (required fields) | Determines if the relationship between fields in different records is acceptable | Return record |
For details on all Medical Call edits, refer to the Edit Matrix section of the manual.
3. Quality Tracking
Quality Tracking is the second stage of the editing process. It is at this stage that a data provider can gauge the quality of the data they are reporting. In this stage, the data elements of each submission are checked for completeness and validity using field, logical, and relational edits:
- Field edits ensure the completeness and validity of each data element. For example, Birth Year cannot be missing, and the year must be a valid year.
- Logical edits check the relationship between elements within the same record. For example, Birth Year must be before Accident Date.
- Relational edits check for acceptable relationships between elements on different records, either within the submission or on the PCRB’s database. For example, if an Original record (Transaction Code 01) already resides on the PCRB’s database, a new Original with the same key fields (Carrier Code, Policy Number Identifier, Policy Effective Date, Claim Number Identifier, Bill Identification Number, and Line Identification Number) and the same Transaction Code and Transaction Date will invoke an edit.
Refer to Edit Types in this section for edit type descriptions.
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 are evaluated against a tolerance level (Critical, Priority, Low, or Relational). Refer to Validating a Submission in this Part for data element tolerance descriptions.
In the Quality Tracking stage, the results of the edits are communicated to the medical data provider, at the file level, and aggregate level, by the number of data elements that passed Critical, Priority, Low or Relational tolerance levels. The percentage by data element that are available for use, as well as the specific edit or edits that failed for each data element, are also provided.
In addition, Quality Validation results for certain edits are communicated at the file level and aggregate level. Validation results show occurrences and thresholds for the applicable edits.
The PCRB will not reject or return records during this editing stage.
Quality Tracking
| Edit Types | Description | Edit Failure Results |
| Field (required fields) | Ensures complete and valid entry | Count occurrences |
| Logical | Determines if the relationship between fields in the same record is acceptable | Count occurrences |
| Relational (required fields) | Determines if the relationship between fields in different records is acceptable | Count occurrences |
For details on all Medical Call edits, refer to the Edit Matrix section of the manual.
4. Quarter End Validation
Quarter End Validation is the third and final stage of the editing process. This stage begins in the due quarter. During the Quarter End Validation stage, Quality Tracking edits for all the medical 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 section for details. Additional – relational edits are performed in this stage:
- Relational edits check the entire submission for completeness and reasonability. For example, an office visit is the most common Place of Service; therefore, the PCRB would expect to see this Place of Service code reported more frequently than other Place of Service codes.
The Quality Tracking and additional 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 level (Critical, Priority, or Low). Refer to Validating a Submission in this section for data element tolerance descriptions.
Aggregate validation distributions based on the additional relational edits are provided as anticipated expected values (including the corresponding data elements) and as distribution graphs.
The PCRB will not reject or return records during this editing stage.
Quarter End Validation
| Edit Types | Description | Edit Failure Results |
| Quality Tracking (Field, Logical, Relational) | Refer to Quality Tracking in this section for details | Count occurrences |
| Relational (required fields) | Determines if submission meets anticipated values | Display anticipated values and distribution graph |
For details on all Medical Call edits, refer to the Edit Matrix section of the manual.
C. Medical Data Call Edit Matrix
1. Medical Data Call Edit Matrix—All Edits in Production
The Medical Data Call Edit Matrix—All Edits in Production contains details on the enhanced editing process that currently takes place in the PCRB’s database. This online edit matrix is the most comprehensive resource for information on the PCRB’s Medical 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 Medical Data Call Edit Matrix—All Edits in Production can be found in the Medical Data Reporting section of the PCRB’s website, www.pcrb.com.
2. Medical Data Call Edit Matrix—Future Edit Enhancements
The Medical 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 Medical Data Call editing. This advanced information can be used for planning purposes.
The Medical Data Call Edit Matrix—Future Edit Enhancements has not been established since all the edits are currently contained in the Medical Data Call Edit Matrix.
3. Online Edit Matrix Updates
When changes are made to the Medical Data Call Edit Matrix, carriers will be notified.
