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 Event Table below.
In the same way, if a new paper proof of coverage reporting form arrives at WCD with a mandatory piece of data missing or invalid, we’ll send the paper form back to the insurer. Again,
they must correct the mistake and send the paper back in order to meet the requirements of filing. If the insurer sends the form in late, they’ll be subject to penalties.
Proof
of Coverage Revised Event Table
indicates when insurers have to report coverage events via EDI
to the Division, and what transaction they are to report. EDI
is generally an “event-driven” system, which means
that when something happens at an insurer’s office, i.e.,
a new policy is written, and the information is entered into
their database, a “new policy” EDI transaction to
WCD is automatically triggered.
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.
Draft Trading Partner Agreement for Proof
of Coverage is a legal contract between the Division
and the insurer. The Agreement covers all EDI proof of coverage
transactions and legally binds the insurer to stand behind all
coverage information transmitted via EDI, just as though it
had been sent in on a signed paper form. By using this Agreement,
we can accept EDI coverage transactions without having a signature
on each one.
Draft Trading Partner Agreement Attachment for
Proof of Coverage will be part of the Trading Partner
Agreement for Proof of Coverage, and will specify some Oregon-specific
requirements for how EDI coverage reporting transactions must
be done. For example, the national EDI standard for proof of
coverage allows a transaction called “Delete Jurisdiction.”
In Oregon, we don’t accept or recognize this transaction;
insurers must actively cancel a Guaranty contract in order to
end their liability. The Attachment will specify similar Oregon
proof of coverage requirements, so that insurers understand
what they can and cannot send to us. This will help in programing
EDI systems to report coverage correctly.
If you have questions about the information contained in this document, please contact
Gayle Parrish, 503-947-7626.
Adobe Reader is required to view PDF files. Click the "Get Adobe Reader" image to get a free download of the reader from Adobe. Available for Macintosh or Windows.
