There
seems to be a discrepancy between Oregon's Element Requirement
Table documentation and rejections. Why is something listed
as "N/A" on the Element Requirement Table, but is
being rejected? [Answer]

How
can reporters easily tell the difference between a 4010 and
5010 file? [Answer]

How
soon can we expect to receive the 999 and 824 acknowledgments
after submitting an 837 file to Oregon? [Answer]

When
comparing the data elements for the 837 between California and
Oregon, there are some data elements that California requires,
but Oregon does not. If those California fields are written
to the 837, will you ignore those elements, or should this information
be left out completely? [Answer]

The
structural fields (such as the ISA header fields) are not listed
in your data requirements. Are they mandatory? [Answer]

A
batch control number is listed as optional. Is a batch control
number required in our submissions? [Answer]

Will
Oregon perform validation of the provider license prefix? [Answer]

What
kinds of structural errors have you seen in submitted files?
[Answer]

How
does your translator handle valid but unexpected segments? [Answer]

Are
the forth and fifth digits of an ICD-9 diagnosis code optional?
[Answer]

If
ICD-10 goes into effect Oct. 1, 2015, how soon do you expect
to receive bills with ICD-10 values on them? What bills should
be reported using ICD-9 versus ICD-10? [Answer]

In
the past, we provided an external third-party biller in Loop
2310A (Billing Provider Information). In Release 1.1, we sent
FEIN information in NM109, but in Release 2.0 the NPI is required
instead. We are unable to find NPI information in NPPES for
any of our third-party billers. Our current files with third-party
billers are being rejected due to missing NPI numbers. How should
we handle this? Is there a default value we can use? [Answer]

Edit
074 (Must be >= From Service Date) is incorrectly rejecting
legitimate and correct bill information. Bills like this arise
from preauthorization or prepayment; we receive these bills
in advance of the services and pay them up front, before the
services are performed. How should we accurately report these
bills? [Answer]

We
have a question about 4010 history related to 5010 history.
If we previously sent an original bill in 4010 but now need
to adjust the bill - what format do we use? [Answer]

Pharmacy
reporting:

What
do you expect to receive when a pharmacy transaction is processed
through a Pharmacy Benefit Manager (PBM)? Which amount and received
date should we report? [Answer]

Is
there a generic National Drug Code (NDC) code for over-the-counter
(OTC) drugs? [Answer]

When
we report pharmacy bills to Oregon, do you want the NPI for
the pharmacy or the pharmacist? What about the prescribing provider's
NPI? [Answer]

For
a pharmacy bill, if we do not have the rendering bill provider's
NPI, do you want the rendering bill provider's FEIN and license
number? [Answer]

When
we receive pharmacy bills, they often contain a different number
than the NPI or state license number (e.g., the NCPDP number
or DEA number). What number should we use when reporting pharmacy
bills? [Answer]

What
kind of monitoring will you perform for medical bill reporting?
[Answer]

---------------Below
are the questions and answers---------------

Release
1.1 to Release 2.0 Transition Questions & Answers:

When
must reporters report in Release 2.0?

Division
160 Medical Bill Data administrative rules require insurers
to report medical bill data using the IAIABC's EDI Release 2.0
standard, effective Oct. 1, 2014. All insurers must complete
reporting of their fourth quarter 2014 medical bill data to
the division no later than April 1, 2015. After this date, the
division may impose civil penalties for any missing or misreported
fourth quarter 2014 medical bill data. Bills received by the
insurer before Oct. 1, 2014, may be reported to the division
using the IAIABC Release 1.1. Release 2.0 must be used for any
bills received on or after Oct. 1, 2014. [top]

Insurers
and self-insured employers are required to report all paid and
denied medical bills for medical services on accepted claims
within 60 days of the date of bill payment or denial. Per OAR
436-010-0005: "Medical Service" means any medical
treatment or any medical, surgical, diagnostic, chiropractic,
dental, hospital, nursing, ambulance, or other related services
(including interpretative services); or drugs, medicine, crutches,
prosthetic appliances, braces, and supports; and, where necessary,
physical restorative services. [top]

How
frequently must reporters report medical bill data?

Medical
bills must be reported and accepted within 60 days of the date
of bill payment or denial. Files may be submitted to us on a
weekly or monthly basis, depending on volume, but enough time
should be allowed for timely correction and resubmission of
rejected transactions. If your expected volume is high, we prefer
you report on a weekly basis. This will allow us to give quicker
feedback on submissions and reduce the size of any error reports
that need to be processed after each submission. [top]

Does
Oregon require reporting of denied bills?

Per
OAR
436-160-0415, the division requires reporting of denied
bills on accepted claims. A denied bill is defined as any bill
in which there is a non-zero charge and a zero payment. Denied
medical bills for accepted claims must be reported within 60
days of date of denial. [top]

What
are the required time frames for bill reporting?

Per
OAR
436-160-0415, medical bills (including interpreter bills
under OAR
436-009) must be reported within 60 days of the date paid.
To be considered timely, transactions must be received and accepted
by us within 60 days of either the date paid or the date denied.
If a transaction is initially rejected it must be corrected,
resubmitted, and accepted within the original 60 day time period
to be considered timely. [top]

When
should we report cancellations?

Per
OAR
436-160-0415, cancellations must be reported as soon as
the payer knows that a medical bill was sent in error.[top]

When
should we report corrections or replacements?

Per
OAR
436-160-0415, corrections or replacements must be reported
within 60 days of changes to any of the "Fatal Technical,"
"Mandatory," or "Mandatory Conditional"
data elements in Appendices A and B.
[top]

The
division has specific data requirements for some form fields.
Where is that information?

Are
submissions for multiple parties allowed in a single interchange
(as opposed to having to do a separate run for each)?

Yes,
sending information for multiple insurers or self-insured employers
in a single file is acceptable. For the 837 file name, the FEIN
is required as part of the name. Some businesses support two
different lines and have two different FEINs. [top]

Does
the division want separate files for each line of business,
or can we only use one of the FEINs for all of our transactions?

You can pick one of your FEINs and use it for all reporting.
Please let us know so that we can set up our Reporter FEIN table
for matching purposes. [top]

Does
Oregon accept medical bill filings from multiple reporting partners
for a single insurer or self-insured employer?

We
require Trading
Partner Profile (Form 4015) from all data reporters. We
do not require a Trading Partner Profile from each insurer or
self-insured employer. Form 4015 must be completed by new trading
partners and submitted to our EDI coordinator at dcbs.edimedical@oregon.gov.
The EDI coordinator can answer questions about completing the
form. The trading partner is responsible for notifying us of
any changes to its profile. [top]

We're
an existing reporter already reporting to Oregon and are taking
on a new insurer soon. What does the division need from us?

If
the reporter is already one of our active trading partners,
there is no need to tell us which insurer's data they will report.
The trading partner may start reporting the new insurer's data
at any time. [top]

How
does the division accept ANSI X12 transmissions?

To
protect injured workers' identities and personal information,
the division will only accept ANSI X12 transmissions through
a Secure File Transfer Protocol (SFTP). For questions about
an acknowledgement, please reference the location in the acknowledgement
or the subject matter at hand. Do not resend the 837 file in
an email. [top]

Who
is the division contact for assistance to set up a Secure File
Transfer (SFTP) mailbox to report medical bill data?

How
often can we submit medical bill files during the testing period?
Do medical bill files need to be submitted only on the day of
the week indicated in our Trading Partner Profile?

During
testing, medical bill files may be submitted daily and may be
submitted on a different day than initially indicated. Once
production status is achieved, please send files on the day
of the week that has been agreed. [top]

How
many medical bills should be included in the test files?

Initially,
the trading partner can submit a portion or all of its projected
weekly submission volume; however, by the end of the testing
period, the anticipated total weekly submission volume should
be reported. The trading partner should include all bill types
that it anticipates sending in production: SV1 professional,
SV2 institutional, SV3 dental, and SV4 pharmacy. [top]

What
data should be used for testing? Should we create dummy data?

The
division recommends reporters submit current medical bill payments
in the 837 with the appropriate header and trailer records,
rather than using dummy data for testing. Test data will not
be loaded into the production database. [top]

After
we receive and process the file, at least one functional acknowledgment
(TA1, 999, or both) is made available to the trading partner.
If the submission was not successful, error codes in the acknowledgment
will identify the errors or the reason for rejected transactions.
[top]

Where
should we place our test files?

Test
files should be placed on the same server where production files
are placed, but in the /test directory. Acknowledgments
will be placed in the /test/ack directory. All files
left in the production directory will be processed nightly.
[top]

We
dropped off a test file. Why haven't we received an acknowledgement
yet?

Because
there is no automation in the test environment, you must let
our team know your test file is ready to be processed. Send
an email to andrew.d.gawne@oregon.gov
to let us know a file is ready. Turn around time will vary,
but we will reply to your email when your acknowledgments are
ready to be retrieved. In order to avoid errors such as duplicate
interchange control numbers and reusing DN0500 (Unique Bill
ID Number) values, we will delete your test data upon a new
test submission. Please advise us when you send test data that
depends on other files we have already processed. [top]

When
can we transition from test to production?

When
we complete the evaluation of test data received, the trading
partner will be notified of test completion and approval to
transmit data into production. After production approval is
granted, the trading partner must change two indicators for
production. "P" (for production) must be listed in
your file name, instead of "T" (for test). (Format:
OR_<reporter FEIN>_<P>_<yyyymmdd>_<hhmiss>_<sequence
number>_<type>)
Also, you must set the header record in the ISA 15 segment of
the envelope to show "P" for production. [top]

Division
Processing Questions & Answers:

There
seems to be a discrepancy between Oregon's Element Requirement
Table documentation and rejections. Why is something listed
as "N/A" on the Element Requirement Table, but is
being rejected?

While
our element requirements state when rejections caused by business
rules will occur, it does not state what is syntactically required.
You must use the IAIABC Implementation Guide to determine what
elements are required in which segments. If the IAIABC Implementation
Guide states that something is required, but Oregon doesn't,
that means that you must include that element to get past the
999 or 824 edits. [top]

How
can reporters easily tell the difference between a 4010 and
5010 file?

Checking
the ISA12 element is the best way to tell a 4010 file from a
5010 file.
manual. [top]

What
transaction types does Oregon accept?

The
division accepts original (00), cancellation (01), corrected
(02), and replace (05) transactions. Encounter (09) transactions
should not be reported. Within each transaction type, there
are data element requirements and conditions listed in Appendices
A and B. Appendix A shows all medical bill data elements
accepted in Oregon, and whether the data element is "Fatal
Technical" (F), "Mandatory" (M), "Mandatory
Conditional" (MC), "If Applicable/Available with Item
Reject if Invalid" (AR), or "If Applicable/Available
with Item Accept if Invalid" (AA) for each transaction
type. Appendix B lists Oregon mandatory conditional data elements
that are mandatory under specific conditions. [top]

Are
reporters required to report medical bills from providers outside
the United States?

Insurers
and self-insured employers must report medical billing and payment
information when health care is rendered outside the United
States. Country codes for foreign countries have been included
in the division's database so that these transactions can be
processed and requirements for FEIN, NPI, and state license
number will be bypassed. [top]

What
are the acknowledgements in Release 2.0?

TA1,
999, and 824, as described below.

TA1
interchange acknowledgements - This acknowledgement
file is intended to communicate the file status of the inbound
837 file. A TA1 file will be made available only when either
the inbound 837's ISA14 element is "1" or there
is an error at the interchange level, which warrants rejection.
Within each TA1, the TA104 element provides the status of
the file and the TA105 element notes the reason. If an interchange
is rejected, we will reject the entire file; neither a 999
functional acknowledgment nor an 824 acknowledgment will
be made for that file.

999
functional acknowledgements - This acknowledgement file
communicates how well the 837 file adheres to the IAIABC
Implementation Guide. The 999 file is generated by the receiver
of the inbound 837 file and made available to the sender
of the inbound 837 file. If we reject a transaction set,
it is rejecting only that set and the set's bills will not
appear in the 824 acknowledgment. Trading partners are responsible
for monitoring the status of their files and the errors
or status indicators included in the functional acknowledgements.
Trading partners must respond to these acknowledgements
by correcting the errors and submitting corrections as appropriate.
The 999 acknowledgement replaces the 997 acknowledgement
(for syntax and Implementation Guide adherence) in Release
2.0

824
detail acknowledgements - This acknowledgement is sent
when we accept at least one transaction set in an EDI ANSI
837 file. That acknowledgment provides results of applying
the edits found in Appendices A
and B to the data. If any transaction set is rejected,
the EDI ANSI 837 application will indicate whether individual
items (medical bills) were accepted or rejected. Trading
partners are responsible for monitoring the status of their
files and the errors or status indicators included in the
detail acknowledgements.

Both
a 999 (functional acknowledgement) and an 824 (detail acknowledgment)
will be available to the trading partner if the file passes
structural edits. The acknowledgments will identify any errors
that need to be corrected and resubmitted. Files with structural
or detail (data) errors must be corrected and resubmitted within
60 days of the date of payment or denial.

An 837 transaction set consists of a Transaction Set Header
(ST) segment, one or more medical bills, and a Transaction Set
Trailer (SE) segment. If the transaction set does not contain
all three components, it is rejected.

The 837 application first checks every inbound file for structural
validity. Any error outside of a functional group, or in the
GS segment, will cause a rejection and a TA1 will be available
to the sender. No further processing of the file will occur.

If invalid syntax is found below the interchange level, the
999 file will indicate a rejection for the transaction set containing
the error. The data in those transaction sets will not be edited
and those transaction sets will not be acknowledged in the 824
file. At least one transaction set must pass the 999 edits in
order for an 824 file to be created. A trading partner must
monitor its SFTP directories for acknowledgments and delete
processed acknowledgments.

If the 837 application has passed the structural validity of
at least one transaction set in an inbound file, the application
then checks the transaction sets and individual items (bills)
in the accepted transaction sets by validating each field (data
element) in each transaction set and transaction using the edit
rules.

If a data element fails to pass any edit validation, the appropriate
error message will be listed in the 824. All data element errors
will be included in the 824. The division will return only Item
Accepted (IA) or Item Rejected (IR) acknowledgements in the
detail acknowledgement file. Item Accepted with Error (IE) is
not used in Oregon. [top]

Are
all of the errors listed on the acknowledgment?

While
we store all errors, we will only report the first 12 lines
with errors in the Original Transaction Identification (OTI)
loop. The lines with errors are in the OTI loop and up to 100
errors (including bill-level errors) are listed in the Industry
Code (LQ) loop. It will be up to our trading partners to determine
which lines have which errors. There is no longer a logical
tree to follow for a particular error. You will need to know
if it is a bill-level or line-level error based on the data
element number (DN) in RED06 (Industry Code). Despite this limitation,
we tend to order the errors at the bill level first, then the
line level. [top]

What
rejected bills should be resubmitted?

Correct
and resubmit any rejected bills identified in the 824, with
the following exceptions:

Do
not resubmit a transaction rejected as a duplicate. For
example, a transaction where DN0508 (Bill Submission Reason
Code) = 00 after one with the same DN0006 (Insurer FEIN)
and DN0500 (Unique Bill ID Number) values are accepted.

The trading partner may resubmit a transaction from an insurer
or self-insured employer not required to report medical
bill data per Bulletin 359. Just as in Release 1.1, even
when a transaction set is accepted (OTI01=TA), there may
be an error message 039 (No match on database) for DN0006
(Insurer FEIN). That is not a rejection, but rather a notice
that the insurer is not required to report bills to the
division. While the trading partner may fix and report the
bill in another transaction, it is not a requirement. This
will only appear when at least one bill from that insurer
is rejected (OTI01=IR).

A
rejected transaction must be resubmitted using the same DN0500
(Unique Bill ID Number) and DN0006 (Insurer FEIN) as the rejected
transaction. This is required for us to match the transactions
and to remove the rejected transaction from the our Aging Bills
Report once it is corrected and accepted.

If
some errors are deemed by the reporter to be "uncorrectable"
due to internal processing issues, the reporter must contact
our EDI coordinator at dcbs.edimedical@oregon.gov
so that the rejected transactions, at the division's discretion,
may be removed from the Aging Bills Report. Failure to contact
us will result in the rejected transactions continuing to appear
on the Aging Bills Report as late for correction and may result
in penalties against the associated insurer or self-insured
employer. [top]

We
recently dropped off some files on the Secure File Transfer
Protocol (SFTP) server that have not been picked up yet. What's
wrong?

Please
check the file name; that has been the most frequent error to
date. See our file naming convention question and answer. Our
file retrieval program will not recognize misnamed files and
cannot process them. [top]

We
received a TA1 file back from you; what does that mean?

TA1
acknowledgment means there was an interchange-level error that
prevented us from creating a 999. There's a structural error
with your file that must be corrected before resubmission. The
TA1 file name will be formatted just like our other file names,
but ending in "TA1" instead of "999". See
our file naming convention question and answer for proper naming
format. [top]

How
soon can we expect to receive the 999 and 824 acknowledgments
after submitting an 837 file to Oregon?

Files
are processed seven days a week, after 5 p.m., Pacific Time.
Any files that are submitted before 5 p.m. will be processed
that evening and both 999 and 824 acknowledgments will be dropped
off to reporter's SFTP mailboxes overnight. Files submitted
after 5 p.m. will be processed on the next business day and
the acknowledgments will then be returned overnight. In order
to ensure adequate space on the SFTP server, we recommend that
insurers and self-insured employers delete transaction files
that have already been processed. Make sure to save the acknowledgement
files locally before deleting them from the server. [top]

When
comparing the data elements for the 837 between California and
Oregon, there are some data elements that California requires,
but Oregon does not. If those California fields are written
to the 837, will you ignore those elements, or should this information
be left out completely?

We
will skip it if it is not required, but an optional field will
not cause a transaction to rejected. [top]

The
structural fields (such as the ISA header fields) are not listed
in your data requirements. Are they mandatory?

Yes,
these structural fields are required to build the file, and
are mandatory. Your file cannot be processed without all structural
components present and in the correct order.[top]

A
batch control number is listed as optional. Is a batch control
number required in our submissions?

Although
this is listed as optional, we strongly suggest that reporters
include a unique batch control number to help you match acknowledgments
to submissions. We will return the reported batch control number
in our 824 acknowledgement, even if it is all zeroes. [top]

Will
Oregon perform validation of the provider license prefix?

No,
we will not be validating provider license prefixes. You only
need to report the provider license number when the provider
does not have a National Provider Identifier (NPI). The NPI
should be collected and reported for all providers, except in
those rare cases where the provider does not have an NPI. [top]

What
kinds of structural errors have you seen in submitted files?

We
have seen quite a few loop-segment problems. Even if we have
not specified required data fields in segments that begin the
loop containing the required data, the loop-starting segment
itself must be present, or a structural error will be triggered.
For example, NM1 indicates that a new loop is starting and should
be used, with asterisks showing the presence of the fields or
absence of data, before the group of REF segments indicating
a provider's license number, NPI, etc. [top]

How
does your translator handle valid but unexpected segments?

We
do not consider it a structural error if a segment that we do
not use is reported. However, those unused segments must be
structurally correct-including proper codes-as defined in the
IAIABC Implementation Guide. [top]

Are
the forth and fifth digits of an ICD-9 diagnosis code optional?

No.
We require diagnosis codes (with the greatest specificity) to
be reported when the bill is not denied because ICD-9-CM instructs
providers to "assign three-digit codes if there are no
four-digit codes within the code category. Assign four-digit
codes if there are no five-digit codes for that category. Assign
five-digit codes for those categories where they are available."
Provider bills that do not contain a valid diagnosis code according
to these instructions may be returned for completion. [top]

If
ICD-10 goes into effect Oct. 1, 2015, how soon do you expect
to receive bills with ICD-10 values on them? What bills should
be reported using ICD-9 versus ICD-10?

The
Division
009 proposed rules require health care providers to use
ICD-10 codes starting Oct. 1, 2015. For dates of service before
Oct. 1, 2015, use ICD-9 codes; on or after Oct. 1, 2015, use
ICD-10 codes. However, if the federal implementation date changes
to a different date other than Oct. 1, 2015, we will amend our
rulemaking to match the federal date. Under OAR
436-160-0415, insurers and self-insured employers are required
to report all paid and denied medical bills for medical services
on accepted claims within 60 days of the date of bill payment
or denial. [top]

In
the past, we provided an external third-party biller in Loop
2310A (Billing Provider Information). In Release 1.1, we sent
FEIN information in NM109, but in Release 2.0 the NPI is required
instead. We are unable to find NPI information in NPPES for
any of our third-party billers. Our current files with third-party
billers are being rejected due to missing NPI numbers. How should
we handle this? Is there a default value we can use?

In
Release 2.0, NPI is required in Loop 2310A. In Release 1.1,
FEIN information was sent in NM109. Now, the NPI is required.
Since third-party billers are not providers, they will not have
an NPI. Reporters should be able to leave the NPI blank for
those billers. The license number should be set to 99999 and
the FEIN is required. [top]

How
are adjustments different in Release 2.0?

The
adjustments in Release 2.0 are now explicitly for either the
bill or service level. If the bill is adjusted at the line,
then only send the service-line adjustment in Loop 2430 (Service
Line Adjustments and Amounts). If the adjustment is for the
entire bill, then send the adjustment only in Loop 2320 (Bill
Level Adjustments and Amounts). Sending adjustments in both
loops will cause a rejection on DN0516 (Total Amount Paid Per
Bill). [top]

The
data element name for DN0527 (Prescription Date) changed to
"Prescription Date(s) Range" to accommodate more than
a single prescription to be billed at a time, as this was already
permitted by NCPDP. Although the data element name changed,
the RD8 qualifier (Range of dates expressed in format CCYYMMDD-CCYYMMDD)
was not added to the IAIABC Implementation Guide for DTP02 (Date
Time Period Format Qualifier). Oregon now accepts either the
D8 (Date expressed in format CCYYMMDD) or RD8 qualifiers for
this element as long as DTP03 (Date Time Period) is formatted
appropriately. [top]

How
do we report diagnosis pointers?

We
allow the diagnosis code pointers in SV107 to reference any
valid diagnosis code from the HI segment. Please report the
appropriate diagnosis pointers in SV107; we'll accept one or
two digits. They cannot be the letters from the bill; they must
be translated in the obvious way (A=1, B=2, ... L=12). [top]

Edit
074 (Must be >= From Service Date) is incorrectly rejecting
legitimate and correct bill information. Bills like this arise
from preauthorization or prepayment; we receive these bills
in advance of the services and pay them up front, before the
services are performed. How should we accurately report these
bills?

We
relaxed Edit 074 (Must be >= From Service Date) on DN0510
(Date of Bill), as some bills are legitimately received in advance
of services and may be paid before the service is performed.
Our Edit Matrix will be updated in the next rulemaking. [top]

Where
do I get the jurisdictional claim number?

We relaxed the jurisdictional claim number edit when we moved
to production for Release 2.0. We will no longer require jurisdictional
claim numbers nor will we look for invalid jurisdictional claim
numbers. It is acceptable to leave that field blank. Our Edit
Matrix will be updated in the next rulemaking. [top]

We
have a question about 4010 history related to 5010 history.
If we previously sent an original bill in 4010 but now need
to adjust the bill - what format do we use?

In
Release 2.0 (5010), we are using the same database and point
to the same tables as Release 1.1 (4010) just using a different
procedure of reporting bills. If the prior bill was in 4010,
send the adjustment in 5010. By rule, we use the date of the
bill (when the insurer receives it) to determine what format
is required for reporting. Bills received by the insurer before
Oct. 1, 2014, may be reported to the division using 4010. 5010
must be used for any bills received on or after Oct. 1, 2014.
[top]

Pharmacy
Reporting Questions & Answers:

What
do you expect to receive when a pharmacy transaction is processed
through a Pharmacy Benefit Manager (PBM)? Which amount and received
date should we report?

The
reporting entity (regardless if it is a PBM, medical bill review
vendor, or other entity) should report the paid date and paid
amounts for a pharmacy transaction processed by the reporting
entity as the same paid date and paid amount which was paid
by the carrier or third-party administrator directly to the
pharmacy or the pharmacy's assigned billing entity. The pharmacy's
assigned billing entity can be a PBM or a third-party biller.
[top]

Is
there a generic National Drug Code (NDC) code for over-the-counter
(OTC) drugs?

No,
there is no generic NDC code. All OTC drugs have their own NDC
code associated with them. If you pay for OTC drugs, indicate
their correct NDC codes on the line.[top]

When
we report pharmacy bills to Oregon, do you want the NPI for
the pharmacy or the pharmacist? What about the prescribing provider's
NPI?

We
want the pharmacy's NPI, not the individual pharmacist's NPI
or license number. All pharmacies in Oregon have license numbers,
and most, if not all, should have NPIs. If a pharmacy does not
have an NPI, you must report its state license number. Release
2.0 requires reporting of the prescribing provider's NPI. Currently,
the Division
009 Medical Fee and Payment Rules do not require that the
pharmacy bill include the prescribing provider's NPI; however,
this will be rectified later in 2015 when the revised rules
are adopted. In the meantime, report the prescribing provider's
NPI when it is on the bill and report the default value 99999
when there is no NPI for the prescribing provider. [top]

For
a pharmacy bill, if we do not have the rendering bill provider's
NPI, do you want the rendering bill provider's FEIN and license
number?

Yes.
We expect the billing provider's FEIN, the one who is being
paid. In some cases, the billing provider does not have a state
license number (e.g., third-party billing companies that bill
on behalf of the pharmacy). [top]

When
we receive pharmacy bills, they often contain a different number
than the NPI or state license number (e.g., the NCPDP number
or DEA number). What number should we use when reporting pharmacy
bills?

Oregon
requires the pharmacy's NPI, or if the pharmacy does not have
an NPI, the state license number must be reported. All pharmacies
in Oregon must be licensed, so even in those rare instances
when the pharmacy does not have an NPI, the pharmacy will always
have a state license number. We highly recommend you contact
those entities that report pharmacy bills to you and alert them
that the NPI or state license number must be collected and reported
for all pharmacy bills reported to Oregon. [top]

Monitoring
Questions & Answers:

How
should trading partners actively monitor transactions?

Insurers
and self-insured employers are encouraged to actively monitor
production operations and schedules, identify any issues or
defects, and promptly notify the division if any problems occur.
We provide a Traffic
Report that includes information about the overall processing
of submitted and accepted 837 files submitted to the division.
The Traffic Report indicates which acknowledgement files are
created; however, it may not reflect any delivery problems encountered
on the SFTP server.

The Traffic Report provides summary information on processed
date and time acknowledgements generated for each file.

Processed
date/time: The date and time when an accepted file begins
the medical EDI processing workflow. A delay between the
date a file is submitted to the SFTP box for processing
and the date the processing begins may indicate a processing
problem on the state system.

File
name: The name of the inbound file as submitted by the
trading partner without the file extension.

Acknowledgement
sent: An indicator showing that the acknowledgment was
created. For example, if "Y" is displayed for
a TA1 and "N" is shown for both the 999 and 824,
this means that the file failed structural validation. No
999 or 824 will be created for that file. If "N"
is displayed for a TA1 and "Y" is shown for the
999 and 824, this means that the file passed structural
validation and only a 999 and 824 were created for that
file. No TA1 will be created.[top]

What
kind of monitoring will you perform for medical bill reporting?

The
division monitors the timeliness and accuracy of both trading
partner and insurer or self-insured employer performance. Ultimately,
the responsibility of accurate reporting resides with the insurer
or self-insured employer. These entities must be familiar with
billing, payment, and coding standards to ensure accuracy and
should not rely simply on the edits implemented by us to determine
whether or not they are accurately reporting their data. We
will make information available to the trading partner, insurer,
or self-insured employer to help resolve potential issues or
seek clarification. Repeated or egregious violations of reporting
requirements may be referred to the division's Performance Section
for investigative or audit actions under OAR
436-160-0440, OAR
436-160-0445, and ORS
656.745. [top]

If you have questions about this webpage, please contact
Jenni Bertels, 503-947-7742.