Text Size:   A+ A- A   •   Text Only

    Edward C. Lanssens   

EDI proof of coverage overview

Proof of Coverage Revised Element Requirement Table shows what data WCD requires the insurer to submit for various types of coverage filings. Note that more data is required for Establishing Document-type transactions than for other types of filings. This is because, once the insurer has submitted data to WCD, they don’t need to send it again unless it changes. We will “link” the new data to what was originally reported by using a combination of the Policy Number, policy dates, and the Federal Employer Identification Numbers (FEINs) for Insurer, Insured and Employer.

Data elements are either (M)andatory, (C)onditional, or (O)ptional. A mandatory data element must be submitted, and must be valid. A conditional data element must be submitted if another data element value requires it; for example, if this is a rewrite or reissue of a previously submitted policy, the insurer must send the prior policy number so we can link the two policies. An optional data element is one that we want the insurer to send if they have it, but we won’t reject a transaction if it’s not included. Items such as the Business Identification Number (BIN/UI) are optional, because not every employer is required to have a BIN.

If we get an EDI transaction with a mandatory piece of data missing or invalid (like a date of 00/00/00), we will reject the transaction. That means the insurer has not filed the report with us, and may be subject to fines if they don’t correct the mistake and report the data again, within the required time limits. See Proof of Coverage Revised Edit Matrix below.

Proof of Coverage Revised Edit Matrix shows what numeric error codes an insurer will receive if we find something wrong with the coverage data they have submitted electronically. The Acknowledgement that we send back after every EDI transaction will have a list of which records (all the information about a new policy, an endorsement, a cancellation, or a reinstatement) were accepted and which were rejected. The individual data elements that have errors will be identified, and one or more of these error codes will be listed. That way, the insurer will know which piece of data on which transaction is wrong. In the case of a rejected transaction, the insurer will correct the data and send it back to meet filing requirements.
If you have questions about this webpage, please contact Edward C. Lanssens, 503-947-7742.