Claim Related Issues

Claim related issues can often be due to Insurance, Prescriber, Patient or Drug issues.

Insurance Issues

PROBLEM: Missing/Invalid (M/I) Provider ID, non-matched Pharmacy number

Background: In every claim, a Provider ID, or pharmacy number must be included so that the insurance company can identify which pharmacy is sending the claim. The value that will be sent is stored on the File -> Insurance Plan File (F5) screen in the Pharmacy Number field.

For most insurance companies, the pharmacy’s NPI number should be in this field.

The pharmacy should have all their identification numbers stored in their respective fields in the File -> Pharmacy Setup screen.

Possible Reasons/Solutions:

• The wrong number is entered into the field. Example: The insurance company requires the NPI#, but the pharmacist entered the NCPDP# instead. Change the value to the one required by the insurance company.

• The insurance company doesn’t have the pharmacy in their database. The pharmacy will have to call the insurance company and enroll with them if they want to send claims.

• The number was mistyped. Example: Instead of ‘1234567’, they accidentally entered ‘1234568’.

PROBLEM: M/I Provider ID Qualifier

Background: Along with the provider ID, a Provider ID Qualifier must be sent to let the insurance company know which number is being used (NPI, NCPDP, etc.) The Provider ID Qualifier must sync up with what is entered in the pharmacy number field. Click on the drop-down box for the field to see a list of the possible values and their definitions.

Possible Reasons/Solutions:

• The insurance company requires a different ID Qualifier than the one that was transmitted. Example: the pharmacy sent a value of ‘07’ (for NCPDP#), but the insurance company requires a value of ‘01’ (for NPI#). The pharmacy would have to change this and the pharmacy number to what the insurance company wants.

• The ID Qualifier does not match with the pharmacy number. Example: the pharmacy entered a value of ‘01’ (for NPI#) for the qualifier, but entered the NCPDP# into the pharmacy number field. Make sure these 2 values sync up.

PROBLEM: M/I Transaction Count

Background: Most insurance companies allow you to send them up to 4 claims at a time, but there are some that only allow 1 claim at a time. You will get this error message if you try to send multiple claims to an insurance company that only accepts 1 claim at a time.

Possible Reasons/Solutions:

Go to File -> Insurance Plan File, bring up the plan in Edit mode and change Multiple Claims Transmissions to NO.

PROBLEM: M/I Bin Number or M/I Processor Control Number

Background: When claims are sent, they go from the pharmacy computer to the switching company (primary switch is named Relay Health, was formerly known as Per-Se technologies, which was formerly known as NDC or National Data Corporation. It’s confusing and even though they keep changing their name, they are all the same company. Most people still know them by the name NDC. Secondary switch is Emdeon). Then from the switching company, the claims go to the insurance processor and then finally to the insurance company.

Every insurance plan has a BIN number. The BIN number along with the Processor Control Number (PCN) are what identify all the different insurance companies. If the switching company does not recognize the BIN number or processor control number, they won’t know what insurance company they need to send the claim to.

Possible Reasons/Solutions:

The wrong BIN number or processor control number was entered. Go to File -> Insurance Plan File (F5) and make sure the values entered into those fields are correct (they can usually be found on the patient’s insurance plan card). If the values are correct, then the pharmacist needs to call the switching company to see why the claim is being rejected.

PROBLEM: M/I Software Vendor Certification ID

Background: There are a few insurance companies that require a software vendor certification ID. This value is stored in the File -> Insurance Plan File (F5) screen in the Software Vendor ID field.

Possible Reasons/Solutions:

Go to File -> Insurance Plan File (F5) and enter the appropriate software vendor ID for the plan. Click on the hint button next to the field for a list of valid software vendor IDs for our system.

PROBLEM: Rejection 646

Background: The insurance is not sending anything but an arbitrary number with no further explanation.

Possible Reasons/Solutions:

The reason for this rejection is the insurance premium has not been paid by the patient. The full explanation of the rejection is as follows: "Patient not eligible due to non payment of premium. Patient to contact plan". Like the explanation states, the patient will have to speak to their insurance company/employer to go over their premium cost and make sure it is current.

PROBLEM: The pharmacy is getting a rejection message, but the insurance company does not see that claim on their end.

Possible Reasons/Solutions:

• The incorrect BIN number or processor control number has been entered, so the claim is going to the wrong insurance company. Verify that those two values are correct.

• The rejection message is coming from the switching company, so the claim was never sent to the insurance company. Call the switching company and find out why they are rejecting the claim.

• The rejection message is coming from the insurance processor, so the level 1 technicians at the insurance company cannot see the claim. The call has to be escalated for investigation at the insurance company with a supervisor by opening a ticket.

PROBLEM: Message MRAHM or HMMRA in a rejection.

Background: There is a pre/post edit being done by McKesson reimbursement advisement.

Possible Reasons/Solutions:

McKesson reimbursement advisement is editing the claim before it's submitted to the insurance company. You will need to call Access Health at 800-824-1763 (option 4) and obtain either an override, or clarification from the adviser on the issue.

PROBLEM: Rejection 777

Background: Prescriber state license has not been verified to have prescriptive authority.

Possible Reasons/Solutions:

Try using Submission Clarification Code (SCC) 52. This should override the rejection and allow the prescription to go through.

Prescriber Issues

PROBLEM: M/I Prescriber ID or M/I Prescriber ID Qualifier

Background: In every claim, a Prescriber ID must be included so that the insurance company can identify which prescriber wrote the prescription. Values that can be sent are either the DEA#, State License#, NPI#, MMIS#, or the UPIN#.

Most insurance companies require the NPI# or DEA#. A few companies require the State License#. Medicaid plans may require the MMIS#, and Medicare plans usually require the NPI# or UPIN#.

Along with the Prescriber ID, a qualifier is sent so that the insurance company knows that value the pharmacy is trying to send. The values for the qualifiers are 01 for NPI#, 05 for MMIS#, 06 for UPIN#, 08 for State License#, 12 for DEA#.

Possible Reasons/Solutions:

• The pharmacy mistyped the prescriber ID into the system. Example: the prescriber’s DEA# is AA1234567, but the pharmacy accidentally entered a different value.

• The insurance company requires a certain prescriber ID, but the pharmacy is sending a different one. Example: the insurance company wants the prescriber’s state license number, but the pharmacy is sending the DEA#. To fix this, go to File -> Insurance Plan File (F5) and select the correct value for the Prescriber ID to Transmit field. The prescriber ID that is selected here is the one that will be sent whenever transmitting to this insurance company.

PROBLEM: M/I Primary Care Provider ID

Background: Sometimes a prescription has to be submitted with the referring doctor's information included. There is a specific field on the RxProcessing screen called RefPhysician that functions just like the regular prescriber field. The doctor who writes the prescription is entered normally into the prescriber field.

Possible Reasons/Solutions:

• The information is not present. Simply search for and enter the referring prescriber into the field. Submit the claim like normal.

• The information is incorrect. Open a new window of BestRx or clear the prescription off screen then correct the information for the prescriber and attempt to submit the claim again.

Patient Issues

PROBLEM: M/I Patient Date of Birth

Background: The patient’s DOB is sent in each claim. This value is stored in the File -> Patient File (F3) screen in the DOB field.

Possible Reasons/Solutions:

If the wrong DOB is sent, the claim will be rejected.

PROBLEM: M/I Patient Gender

Background: The patient’s gender is sent in each claim. This value is stored in the File -> Patient File (F3) screen in the Gender field.

Possible Reasons/Solutions:

Some insurance companies check to make sure this value is correct. If the incorrect value is sent, the claim may be rejected.

PROBLEM: M/I Patient Name

Background: The patient’s name is transmitted in each claim. This value is stored in the File -> Patient File (F3) screen in the Patient Name field.

Possible Reasons/Solutions:

Some insurance companies will reject the claim if the name is not entered correctly.

PROBLEM: M/I Patient Location

Background: There is a patient location code that is transmitted for each claim. Almost all claims require that the location code is set to ‘0’. PACE (in Pennsylvania) is the only I know of right now that requires a different value. They require a value of ‘1’.

Possible Reasons/Solutions:

Go to File -> Patient File (F3) and make sure the Location Code is set to the correct value (‘0’ for almost all plans).

PROBLEM: M/I Cardholder ID

Background: A patient’s Cardholder ID is sent in each claim. This number allows the insurance company to identify what patient the Rx is for. This value is stored in the Patient File (F3) on the Insurance plans tab.

Possible Reasons/Solutions:

Most of the time when a claim is rejected for this reason, its because the value the pharmacist entered in the system is incorrect.

PROBLEM: M/I Group Number

Background: Some insurance plans assign Group Numbers to patients as well, and these are also sent in claims. This value is stored in the Patient File (F3) on the Insurance plans tab

Possible Reasons/Solutions:

• The value the pharmacist entered into the system is incorrect.

• The insurance plan requires a Group Number but the pharmacist did not enter it into the system.

• The insurance plan does NOT want a Group number but the pharmacist entered one into the system.

PROBLEM: M/I Patient Relation

Background: There is a Relation Code that is sent to insurance companies to let them know how the patient is related to the cardholder of the insurance coverage. Most of the time, this value will be ‘1 – Cardholder’, but the values for Spouse and Child are used often. This value is stored in the Patient File (F3) on the Insurance plans tab.

Possible Reasons/Solutions:

Make sure this field matches up with the insurance policy and what the insurance company expects to receive coming through on the claim.

PROBLEM: M/I Person Code

Background: The Person Code is a field that is sent in insurance claims. Not all insurance companies require this field. If an insurance company does require this field, the value will probably be found on the patient’s insurance card. This value is stored in the Patient File (F3) on the Insurance plans tab.

Possible Reasons/Solutions:

For plans that require a person code, this value could change often, so the pharmacist should check to see that the value in the system is up-to-date. NY Medicaid is an insurance company that updates the person code often.

PROBLEM: M/I Eligibility Clarification Code

Background: There are instances where an insurance company normally would not cover an Rx for a patient, but because of special circumstances, they will pay for it. To let the insurance know of the special circumstances, the Eligibility Clarification Code is used. This value is stored in the Patient File (F3) on the Insurance plans tab in the Elig Clar field. Click on the drop-down box for this field to see a list of possible values and their definitions.

Possible Reasons/Solutions:

If this field is required the insurance company will usually tell the pharmacist what value is needed. ‘1’ and ‘2’ are the values that are used most, but the other values are used often.

Drug Issues

PROBLEM: M/I Product/Service ID

Background: In each claim, a Product ID is sent to identify what drug the prescription is for. For 99% of claims, the value that is sent is the NDC#, which is found in the File -> Drug File (F4) screen. The NDC (National Drug Code) is an 11-digit number that is unique for each drug.

Possible Reasons/Solutions:

• The wrong number is entered into the system. If a wrong NDC is entered, the insurance company won’t recognize what drug the Rx is for so they will reject the drug. Have the pharmacist double-check the NDC number in the system with the one on the bottle of the drug to make sure it is correct.

• The insurance company recognizes the drug, but they do not cover that drug. There are certain drugs that insurance companies won’t pay for. The pharmacist has to either find a substitute drug that the insurance company will pay for or the patient will have to pay cash for the prescription.

PROBLEM: M/I Product/Service ID Qualifier

Background: Along with the Product ID, a Product ID Qualifier is also sent so that the insurance company knows what ID is being sent. As stated above, 99% of the time, the NDC number is sent, and the qualifier that goes with it is ‘03’. But there are instances where another type of Product ID (usually the HCPC code with a qualifier of ‘09’ or the UPC code with a qualifier of ‘01’. The NDC/Product ID and Product ID Qualifier fields should sync up.

Possible Reasons/Solutions:

• The insurance company requires a certain type of ID, but a different one is sent. Example: the pharmacy sends the NDC, but the insurance company requires the HCPC code. The pharmacist should change the Product ID in the Drug File to the HCPC code and the Product ID Qualifier to ‘09’

• The product ID and qualifiers do not sync up. Example: the NDC is sent, but the qualifier is not ‘03’. The product ID and the product ID qualifier must sync up.

PROBLEM: M/I Procedure Modifier code

Background: Most MedB/DME claims require a special HCPCS code be sent with the product ID to explain its use. This number is inserted into the More section on the RX Processing screen, and multiple numbers can be used. Previously this needed to be placed in the drug file, but has been moved per request and to enhance functionality.

Possible Reasons/Solutions:

• The number is not present and must be entered. Make sure to use a comma if using multiple codes and check for to ensure no other special characters are used..

• The number entered is invalid. Refer to the HCPCS Codes article or contact the insurance company to obtain the proper modifier code.

PROBLEM: 70 - Product/Service invalid/not covered, 21 - Product/service invalid

Background: Insurance companies don't always cover medication, and will from time to time deny a claim based on the NDC(s) being sent.

Possible Reasons/Solutions:

Change the medication / NDC number on the RxProcessing screen and try to resend the claim. For compound prescriptions, some/all ingredients have to be adjusted. Claim response might sometimes elude to which ingredient is causing a problem.

PROBLEM: DUR / LASA rejection (Looks as, sounds as)

Background: The switch vendor sees the medication details being sent over and is concerned it might be an incorrect drug that is being filled.

Possible Reasons/Solutions:

Make sure to verify the medication / NDC number on the RxProcessing screen first. If the medication is correct, use PA qualifier 01 and PA number '6666' to get the claim through the switch vendor.

General RX Problems

PROBLEM: M/I Quantity

Background: The quantity of the drug that will be dispensed is sent in each claim.

Possible Reasons/Solutions:

• Sometimes insurance companies will only pay for a certain quantity of a drug in a certain time period. For example, they will only pay for a maximum of 30 pills of a drug in a month. If this is the case, the quantity needs to be reduced.

• The quantity submitted does not make sense for the drug being dispensed. For example, if the drug is liquid and the quantity is measured in MLs, but the pharmacy submits a value of 15 (when the normal value would be in the hundreds) the insurance plan will reject the claim.

• Insurance companies are a lot stricter with this field for controlled items.

PROBLEM: M/I Days Supply

Background: The number days that the Rx is supposed to last is sent for each claim.

Possible Reasons/Solutions:

• If the number of days does not match up with drug, the insurance company will reject it. For example, birth control pills are prescribed for a period of 28 days or a multiple of 28. If the pharmacy submits a value such as 40, the insurance company will reject it because that is not a proper days supply for this drug.

• The days supply does not match up with the quantity. For example lets say a drug is prescribed with a quantity of 120 and it is a drug that should not be taken more than 4 times a day. If the days supply submitted is less than 30, the insurance company will reject it because that is an invalid value.

PROBLEM: M/I Ingredient Cost

Background: A cost is submitted for each claim.

Possible Reasons/Solutions:

• For some reason, the insurance company does not like the cost that is being submitted for the Rx. Usually the pharmacy is submitting a cost that is too high for the drug in the claim.

• There are other reasons a claim could be rejected with this message, and to find out more information the pharmacy should contact the insurance company.

PROBLEM: M/I DAW (Dispensed as Written) Code

Background: A DAW code is sent for each claim. The DAW code gives the insurance company info on why the pharmacy is dispensing a certain version of a drug, such as if they are dispensing the brand version instead of the generic, or vice-versa. Most insurance companies would rather pay for the generic over the brand version of a drug because the generic is much cheaper.

‘0’ and ‘1’ are the most common values for DAW. ‘2’ is also used often, but not as much as ‘0’ or ‘1’. The rest of the values are used much less often. Click on the drop-down box for that field for a list of possible values and their definitions.

Possible Reasons/Solutions:

If the proper DAW is not submitted, the insurance company might not pay for the brand version, or in some cases, they will pay a cheaper price. Example: lets say there is a brand and generic version available for a certain drug. If the pharmacy dispenses the brand version and submits a DAW code of ‘1 – Substitution not allowed by prescriber’, they should get a full payment from the insurance company. This is because they gave the insurance company a good reason for why they dispensed the more expensive version of the medicine. But if they submit a DAW of ‘0 – No product selection indicated’, the insurance company might pay less or reject the claim altogether, since the pharmacy did not give them a good reason for dispensing the more expensive version of the medicine.

PROBLEM: M/I Refills

Background: The number of refills authorized and remaining are sent for each claim.

Possible Reasons/Solutions:

• Some insurance companies only allow a certain number of refills for prescriptions. If the pharmacy submits a number that is too high, the claim will be rejected.

• Some drugs have a limit to the number of refills that they can have. If the number of refills submitted is too high, the claim will be rejected.

• Some drugs, Control Class 2 drugs for example, are not allowed to have any refills. Any value besides ZERO for these prescriptions will cause the claim to be rejected.

PROBLEM: M/I Prior Authorization Number

Background: There are certain drugs that require a prior authorization number to be submitted in order for the insurance company to pay for the Rx. For some insurances, the PA# must be obtained by the doctor, while others require the pharmacy to obtain the PA#.

The PA# is entered on the main RxProcessing screen towards the bottom. If the PA Number is entered, the PA Type must also be entered. Most of the time the PA Type will be ‘1’.

Possible Reasons/Solutions:

• If an Rx requires a PA Number, it should be entered on the main screen.

• PA numbers can have a max length of 11 characters. If someone has a PA number that is 12 characters long, the first character will be the PA Type and the remaining 11 will be the PA number.

PROBLEM: M/I Submission Clarification Code, M/I Denial Clarification Code, M/I Rx Override Code

Background: There are instances where an insurance company normally would not cover an Rx, but because of special circumstances, they will pay for it. To let the insurance know of the special circumstances, the Rx Override Code is used. This field can be found on the RxProcessing screen. Click on the drop-down box for this field to see a list of possible values and their definitions.

Possible Reasons/Solutions:

If this field is required the insurance company will usually tell the pharmacist what value is needed. ‘2’ is the value that is used most, but the other values are also used often.

PROBLEM: Need to send Diagnosis Codes for Rx

Background: There are some insurance plans, such as Medicare, that require 1 or more (usually just 1) diagnosis codes to be sent with the claim. The pharmacist will know what diagnosis code needs to be sent for the Rx. If the pharmacist does not know the code, they need to call the insurance company and ask them what diagnosis code they’re expecting. The diagnosis code field is on the main RxProcessing screen (towards the bottom-center).

Possible Reasons/Solutions:

• If an insurance company is expecting a certain diagnosis code and the pharmacist puts a different diagnosis code there or doesn’t put one in at all, the claim will be rejected.

• Sometimes the pharmacist will enter diagnosis codes in the Patient File (F3), and they will wonder why the insurance company is not receiving the codes in the transmission. The diagnosis codes must be entered on the main screen for them to be sent to the insurance company. When the codes are entered in the Patient File, all that does is it loads them up into the drop-down box when the patient is selected on the main screen so that the pharmacist does not have to always remember what code needs to be used for the patient.

• Sometimes when trying to select a certain diagnosis code, they pharmacist will get a message that says the diagnosis code was not found. This is because the diagnosis code is not in the system. There are over 8000 diagnosis codes pre-loaded into everyone’s system, but if a pharmacist comes across a code that’s not there, they can add it into the system by going to File -> Diagnosis Code File and adding a new code. For the description they can put whatever they want, its for their purposes only so that they know what the code is for.

PROBLEM: M/I DUR Codes

Background: For some insurance plans (especially NY Medicaid), if a patient is taking 2 or more drugs that usually shouldn’t be taken together, they will require an explanation before they’ll pay for the medicine. This is done by sending DUR (Drug Utilization Review) codes. DUR codes are located on the 2nd tab of the main RxProcessing screen. Click on the drop-down boxes for those fields to see a list of DUR codes and their definitions.

Usually when an insplan requires DUR codes, they will send 1 or more Reason for Service codes back in the rejection. Usually, all that is required is a Result of Service and sometimes Professional Service code for the first Reason for Service code from the rejection. The pharmacist should know what values they need to choose for the Professional Service and Result of Service codes. If they do not know what values to enter, they need to call the insurance company.

Two of the more common DUR rejections are for TD and DD. TD (therapeutic duplication) means the patient is taking 2 or more drugs that have the same therapeutic function at the same time. DD (drug-drug interaction) means the patient is taking 2 or more drugs that may negatively interact with each other in the patient’s body. The pharmacist will have to send codes to tell the insplan why the patient is taking this combination of drugs. Example: the pharmacist could send a professional service code of M0 (prescriber consulted) and a result of service code of 1G (filled, with prescriber approval) to explain what’s going on.

Possible Reasons/Solutions:

• If DUR codes are required but the pharmacist hasn’t entered any, the claim will be rejected.

• If the pharmacist sends the wrong DUR codes, the claim will be rejected. The pharmacist should know what codes to transmit. If not, they should call the insurance company.

• If the pharmacist sends DUR codes when they are NOT required, the claim could be rejected. This depends on the insurance company. Some of them don’t care if unnecessary codes are sent while others do.

PROBLEM: R8 - Syntax Error

Background: The insurance processor does not like/understand certain information in the claim, but does not provide any clues or information on what this information is.

Possible Reasons/Solutions:

• The insurance processor does not like an abnormal character included in the claim. Look for anything out of place like an apostrophe, quotations, decimals etc.

• The processor does not like some information provided that's typically not used ie. Compound Modifiers.

PROBLEM: Unable to reverse/transmit after manual reversal.

Background: Sometimes a claim is unable to be reversed and has to be done some manually; this can result in trouble processing the claim afterwards.

Possible Reasons/Solutions:

• For whatever reason the insurance company/processor will not allow for an automatic claim reversal. The insurance company has to be contacted and the claim will have to be reversed out manually.

• In a situation where the claim was reversed manually, BestRx will not understand the situation and the claim has to me edited to reflect the reversal. Change the RxStatus to Unbilled on the main screen and clear the Copay field. Save the claim then pull it back up in edit mode; the claim should now be able to be transmitted.

PROBLEM: Scheduled prescription ID number is not used for this transaction code/is invalid

Background: The Control Triplicate number entered on the main RxProcessing screen is not needed or is simply invalid. For certain states this field is required to have specific values; for some states it is not. Telephoned prescriptions might have a 8 to 12 digit value of all '9', Electronic and Fax all 'E', out of state all 'Z'. A written prescription would have a custom number specific to that RX if required.

Possible Reasons/Solutions:

• Remove the Control Triplicate number if it is not used for this transaction.

• Correct the Control Triplicate number and resubmit the prescription.

PROBLEM: Texas emergency 72 hour supply; requires a specific PA to process

Background: At times when an emergency 3 day (72 hour) supply is required in the state of Texas, the pharmacy must submit a specific PA along with the prescription to get the claim to go through.

Possible Reasons/Solutions:

Pharmacies should re-submit the claim with the following information:

• "8" in "Prior Authorization Type Code" (Field 461-EU).

• "8Ø1" in "Prior Authorization Number Submitted" (Field 462-EV).

• "3" in "Days Supply" (in the Claim segment of the billing transaction) (Field 4Ø5-D5).

The quantity submitted in "Quantity Dispensed" (Field 442-E7) should not exceed the quantity necessary for a three-day supply according to the directions for administration given by the prescriber.

If the medication is a dosage form that prevents a three-day supply from being dispensed (e.g. an inhaler, eye or ear drops, or creams) it ispermissible to indicate that the emergency prescription is a three-day supply, and enter the full quantity dispensed.

PROBLEM: REMS test problems; Patient ID / Intermediary

Background: Even though REMS certifications are suggested to be done through RelayHealth, some customers that are signed up for the Amerisource Elevate program utilize those fields during parts of the transmission to send Amerisource specific codes; the program sends that information and Elevate strips it from the claim, forwarding the rest to insurance. If for some reason any of this information is left over, the insurance carrier won't understand why they're there and most likely reject the certification unable to proceed.

Possible Reasons/Solutions:

• Use the Intermediary field when being asked on Step 2 to send the ID.

• Make sure the correct switch is selected; when utilizing Elevate, the customer has to be utilizing Emdeon/ChangeHealth as their switch.

General Program Issues

PROBLEM: The program displays an error message "Error While Processing Internet Claim" after attempting to submit a claim to the insurance company.

Background: BestRx relies on an external program or service when processing claims securely to the switches. When running properly, a number of Green Clovers is displayed in the bottom right task tray corresponding to the number of BestRx shortcuts on the desktop (default 2) when using Relay Health Internet File Drop. If using Emdeon, the service eRX Connect Client Service needs to properly operate. When these are not running, claims cannot be processed correctly.

Possible Reasons/Solutions:

• The program for processing claims crashed or did not properly start when your computer was started/rebooted. If these icons are not present in the tray (or the hidden section accessible with the upwards triangle) the program must be started manually. Click on Start -> All Programs (Vista, 7)/ Program Files (XP) -> Startup -> Internet for BestRx Win. NOTE: If using Windows 8, please contact us for assistance. The program should again display the Green Clovers and you should be able to process the claim.

• The program for processing claims is being blocked by your Firewall/Security software. Make sure the program STSYS in the folder C:\SecureTrans\ is allowed by your program.

• The eRX Connect Client Service has crashed, stopped, or is stuck. Please call BestRx to have a technician assist with the issue unless you have someone on staff that is comfortable with restarting the service.

PROBLEM: The program says that refills are expired for a certain Rx, but they shouldn’t be expired yet.

Background: Most prescriptions have an expiration date. This date is usually 6 months to a year after the doctor wrote the Rx. This depends on factors such as the type of drug the Rx is for, the insurance company, and what state the Rx was written in.

To determine the refill expiration date, program first checks what value is store in the Refills Expire in field in the Drug File (F4) for the selected drug. For 99% of drugs, this field will be set to ‘Default from Plan’. If the field says ‘Default from Plan’, the program will go check what is stored in the Refills Expire in or Controlled Refills Expire in field in the Insurance Plan File (F5). The program will take the number of months indicated in the field and add that to the written date to come up with the refill expiration date.

Possible Reasons/Solutions:

Check what the Refill Expiration Date on the main screen says and correct that value. If the value comes up wrong for other prescriptions, check the Refills Expire in and Controlled Refills Expire in fields in the Drug File and Insurance Plan File for the respective drug and insurance plan.

PROBLEM: The Rx Status is coming up as ‘Paid-Cash’ for a prescription that should be billed to an insurance company OR the status says ‘Unbilled’ for a cash prescription

Background: Any plan that’s entered into the system will fall under one of 2 major categories, cash plans and third party plans. This is indicated by the Cash Plan field in the Insurance Plan File (F5).

Cash plans can have either a status of ‘Paid-Cash’ or ‘Hold’. Third party plans can have a status of ‘Unbilled’, ‘Hold’, ‘Transmitted’, ‘Paid-By Ins’, or ‘Rejected’.

Possible Reasons/Solutions:

If the wrong status is coming up, the Cash Plan field in the Insurance Plan File (F5) is probably set to the wrong value.

PROBLEM: The pharmacist wants to deactivate/activate a prescription

Background: There are times when a pharmacist may need to deactivate a prescription. It could be because the patient may no longer need the drug, the patient may have started taking new drugs, the doctor may have written a new prescription, etc. By deactivating an Rx, this ensures that the pharmacist won’t accidentally give out any more refills for that prescription.

A prescription can also be made active again after it has been deactivated.

Possible Reasons/Solutions:

• To deactivate a prescription, bring up the Rx in Edit mode and put a checkmark on the Make Rx Inactive check box towards the bottom-right of the main screen.

• To activate an inactive Rx, bring up the Rx in Edit mode and uncheck the Make Rx Inactive check box towards the bottom-right of the main screen.