EDI medical frequently asked questions

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.

General requirements

EDI filing of medical bills in Oregon is governed by the Oregon Administrative Rules, Chapter 436, Division 160.

Bulletin 359 lists the insurers and self-insured employers required to report medical bill data in Oregon.

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); drugs, medicine, crutches, prosthetic appliances, braces, and supports; and, where necessary, physical restorative services.

Medical bills must be reported and accepted within 60 days of the date of bill payment or denial. Files can 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.

Per OAR 436-160-0415, we require 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.

Per OAR 436-160-0415, medical bills (including interpreter bills under Oregon Medical Fee and Payment Rules) 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.

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

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.

For data element requirements and conditions, see Appendices A and B of Division 160 rules. For data element sources, see our Data Elements by Source table.

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.

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.

Yes, multiple reporter filings are accepted.

In Release 1.1, Oregon's Receiver ID was: Identification Code Qualifier = FI (FEIN) Receiver FEIN = 930952020 Receiver Postal Code = 97301 DN0099 Receiver ID was in two segments. The first was in Loop 1000B, NM1 segment. The second was in the N4 segment.

In Release 2.0, the qualifier is now 46 (Electronic Transmitter Identification Number (ETIN)) for both DN098 Sender ID and DN0099 Receiver ID. N403 (Postal Code) is no longer required in the 1000B loop. Identification Code Qualifier = 46 Receiver FEIN = 930952020

Yes, we are using the suggested IAIABC format:

OR_<reporter FEIN>_<T or P>_<yyyymmdd>_<hhmiss>_<sequence number>_<type>
<T or P> => Test or Production
<yyyymmdd> => year, month, day the file was created
<hhmiss> => hour, minute, second the file was created
<sequence number> => 3 digit number
<type> => 837, TA1, 999, 824 named appropriately.

Example: OR_930952020_P_20141112_164026_001_837 would be acknowledged by
OR_930952020_P_20141112_164026_001_TA1
OR_930952020_P_20141112_164026_001_999
OR_930952020_P_20141112_164026_001_824

Prior to testing

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 the our EDI coordinator at dcbs.edimedical@dcbs.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.

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.

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

Please email the EDI coordinator at dcbs.edimedical@dcbs.oregon.gov. The Trading Partner Profile (Form 4015) is used to set up the trading partner SFTP access, directory, and points of contact. An email will be sent to the contact person, notifying the trading partner of its SFTP user name, password, and directory information.

Testing guidelines

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.

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.

We recommend 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.

Files must be in plain text to be processed.

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.

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.

Because there is no automation in the test environment, you must let our team know your test file is ready to be processed. Email dcbs.edimedical@dcbs.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.

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.

Division processing

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.

Checking the ISA12 element is the best way to tell a 4010 file from a 5010 file.

We accept 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.

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 our database so that these transactions can be processed, and requirements for FEIN, NPI, and state license number will be bypassed.

TA1, 999, and 824, as described below.

TA1 interchange acknowledgments: This acknowledgment 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 reject the entire file; neither a 999 Functional acknowledgment nor an 824 acknowledgment will be made for that file.

999 functional acknowledgments: This acknowledgment 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 acknowledgments. Trading partners must respond to these acknowledgments by correcting the errors and submitting corrections as appropriate. The 999 acknowledgment replaces the 997 acknowledgment (for syntax and Implementation Guide adherence) in Release 2.0.

824 detail acknowledgments: This acknowledgment 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 acknowledgments.

Both a 999 (functional acknowledgment) 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.

Each data element must meet the defined edits and validation rules included in the Element Requirements Table.

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. We will return only Item Accepted (IA) or Item Rejected (IR) acknowledgments in the detail acknowledgment file. Item Accepted with Error (IE) is not used in Oregon.

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.

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.

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.

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 reporters' 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 acknowledgment files locally before deleting them from the server.

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

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.

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

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.

We have found 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.

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.

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.

ANSWER REVISED 6/1/16: The Division 009 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. 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.

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.

ANSWER REVISED 2/1/16:
The adjustments in Release 2.0 are now for either the bill or service-line level. If the bill is adjusted at the line, only send the service-line adjustments in Loop 2430 (Service Line Adjustments and Amounts). If the adjustment is for the entire bill, only send the bill adjustment in Loop 2320 (Bill Level Adjustments and Amounts). It is possible to have both bill-level and line-level adjustments on the same bill, but they must be included in the appropriate loop. The amount reported for DN0501 (Total Charge Per Bill) minus the sum of all adjustment amounts [amounts reported in DN0545 (Bill Adjustment Amount) and DN0733 (Service Adjustment Amount)] must equal the amount reported in DN0516 (Total Amount Paid Per Bill).

ISA11 valid values: ^ (Release 2.0/5010 only) and U (Release 1.1/4010 only)

ISA12 valid values: 00501 (Release 2.0/5010 only) and 00401 (Release 1.1/4010 only)

GS08 valid values: 005010I20 (Release 2.0/5010 only) and 004010 (Release 1.1/4010 only)

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.

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).

To account for eBilling, we have updated edit 072 to Must Be >= Date of Bill to account for eBilling. The change is already in production and our Edit Matrix has been updated.

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 has been updated.

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 has been updated.

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 us using 4010. 5010 must be used for any bills received on or after Oct. 1, 2014.

Enter "P" if worker is enrolled in a WCD certified managed care organization at time of service or if provider participates in a WCD registered fee discount agreement. Enter "H" if care was provided through a health maintenance organization. Enter "Y" for any other agreement, not covered by "P" or "H". Enter "N" for none.

Pharmacy reporting

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.

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.

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 and OAR 436-009, Oregon Medical Fee and Payment, require that all bills from pharmacies must include the prescribing provider's NPI or 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).

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.

Monitoring

Insurers and self-insured employers are encouraged to actively monitor production operations and schedules, identify any issues or defects, and promptly notify us if any problems occur. We provide a Traffic Report that includes information about the overall processing of submitted and accepted 837 files submitted to us. The Traffic Report indicates which acknowledgment 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 acknowledgments 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.

Acknowledgment 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.

We monitor 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 our Performance Section for investigative or audit actions under OAR 436-160-0440, OAR 436-160-0445, and ORS 656.745.

Receive updates to EDI information

Resources
International Association of Industrial Accident Boards and Commissions (IAIABC)
eBilling Rules (Division 008)
EDI Medical Bill Data Rules (Division 160)
EDI Proof of Coverage Rules (Division 162)
Oregon Medical Fee and Payment Rules (Division 009)
The Accredited Standards Committee (ASC) X12
National Council for Prescription Drug Programs (NCPDP)
National Uniform Billing Committee (NUBC)
National Uniform Claim Committee (NUCC)

EDI medical frequently asked questions

Release 2.0

General requirements

What rules govern EDI filing of medical bills for Oregon?

Where is the list of insurers and self-insured employers required to report medical bill data to Oregon located?

Which bills are required to be reported to Oregon?

How frequently must we report medical bill data?

Does Oregon require reporting of denied bills?

What are the required time frames for bill reporting?

When should we report cancellations?

When should we report corrections or replacements?

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)?

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

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

What is Oregon's Receiver ID?

Do you require a file naming convention for inbound EDI files?

Prior to testing

Is a Trading Partner Agreement required?

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

How do you accept ANSI X12 transmissions?

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

Testing guidelines

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?

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

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

What format should files be in?

What acknowledgments will you send?

Where should we place our test files?

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

When can we transition from test to production?

Division processing

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?

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

What transaction types does Oregon accept?

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

What are the acknowledgments in Release 2.0?

Are all of the errors listed on the acknowledgment?

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

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

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

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?

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

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

Will Oregon perform validation of the provider license prefix?

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

How does your translator handle valid but unexpected segments?

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

Since ICD-10 went into effect Oct. 1, 2015, how soon do you expect to receive bills coded in ICD-10? What bills should be reported using ICD-9 versus ICD-10?

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.

How are adjustments different in Release 2.0?

What are valid values for ISA11, ISA12, and GS08?

Did DN0527 change in Release 2.0?

How do we report diagnosis pointers?

We have a question on the edit for DN0511 (Date Insurer Received Bill). Per the Edit Matrix, Edit 072 (Must Be > Date of Bill) would reject any bill where the Date of Bill and Date Insurer Received Bill is the same date. What if the bill is electronic?

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.

Where do I get the jurisdictional claim number?

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?

What are the appropriate codes for DN0507 (Provider Agreement Code)?

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?

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

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?

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?

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?

Monitoring

How should trading partners actively monitor transactions?

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