This file is used to store data for queued requests before the ECME engine un-queues them and during their processing. The data stored in this file are used to create a record in BPS TRANSACTION file (#9002313.59) to build a claim request or reversal and send it to the insurer (payer). Generally there should be few or no entries in this file unless there are stranded claims/reversal or requests that need to be un-stranded by the user. Per VHA Directive 2004-038, this file definition should not be modified.
.01key1(+)0;1NUMERICBFor claim requests and reversals, this is the prescription IEN that will be processed. For Eligibility Verification requests, this is the Patient IEN that will be processed.
.02key2(+)0;2NUMERICFor billing requests and reversals, this is the fill number where 0 is the original fill and 1-999 are refills. For eligibility verification requests, this is the policy number plus 9000. So, for policy number 4, this would be 9004.
.03acting cob0;3SET OF CODES1:PRIMARY
This field indicates for which insurer (in terms of coordination of benefits) this particular request was created. For example, if the patient has three insurances then three separate requests can be created for the same prescription/refill in order to bill patient's Primary, Secondary and Tertiary insurers. This field indicates for which insurer this request is for.
.04process flag(+)0;4SET OF CODES0:SCHEDULED
State of the request. SCHEDULED - scheduled for the future (for example : the secondary claim is scheduled to be processed after the primary is completed) ACTIVATED - ready to be processed IN PROCESS - currently in process COMPLETED - has been completed CANCELLED - cancelled INACTIVE - the system marks the records with "bad" data as inactive instead of removing them - to keep them for repair or for investigation
.05next request0;5POINTER9002313.77To store the pointer to the next request which should be processed.
.06ecme transaction record0;6POINTER9002313.59CThis is the BPS Transaction. It is not initially populated but is populated after the request is activated and the BPS Transaction record is created.
.07waiting resolution?0;7BOOLEAN0:NO
Flag to mark requests with problems.
.08dont process until0;8DATE-TIMEThe request cannot be processed until the date and time specified in this field. If null then it can be processed at any time (immediately).
1.01rx action1;1FREE TEXTThis is the action that is being performed on this request. It is either the BWHERE parameter passed into BPSNCPDP or 'ELIG' for an eligibility verification request. The list of BWHERE values are documented at the top of routine BPSNCPD3.
1.02outpatient site1;2POINTER59This is the outpatient site that will be used to generate the NPI number for the Service Provider ID (201-B1) field of a NCPDP request.
1.04transaction type1;4SET OF CODESC:CLAIM
This is the type of transaction that is being processed: CLAIM - An NCPDP billing request. UNCLAIM - An NCPDP reversal request. ELIGIBILITY - An eligibility verification request.
1.05billing determination1;5SET OF CODES0:NOT BILLABLE
Billing determination result
1.06eligibility1;6SET OF CODESV:VETERAN
The insurance eligibility type of the claim.
1.07claim status1;7FREE TEXTThe status of the transaction as a percentage of completion. The text value can be obtained by running $$STATI^BPSOSU(). Note that 99 indicates complete.
1.08rate type1;8POINTER399.3The Rate Type selected by the user for billing.
1.09primary payer bill1;9POINTER399Primary bill which should be used to create the secondary bill. This field is used for secondary billing only.
1.1prior payment1;10NUMERICDollar amount paid by the Primary insurer. This field is used for secondary billing only.
1.11cob other payments count1;11NUMERICNCPDP field 337-4C - Coordination of Benefits/Other Payments Count This value corresponds to the number of multiple entries in the #8 multiple field - COB OTHER PAYERS.
1.12other coverage code1;12SET OF CODES00:NOT SPECIFIED
NCPDP field 308-C8 - code indicating whether or not the patient has other insurance coverage.
1.13rx number1;13POINTER52For billing requests and reversal, this is the prescription that will be processed for the request. If an eligibility verification request is initiated from the ECME User Screen, this field will also be populated and will be used to get the Prescriber information from the prescription.
1.14fill no1;14NUMERICFor billing requests and reversals, this is the fill number to be processed, where 0 is the original fill and 1-99 are refills. If an eligibility verification request is initiated from the ECME User Screen, this field will also be populated and will be used to get the Prescriber information from the prescription.
1.15patient1;15POINTER2For billing requests and reversals, this is the patient associated with the prescription. For eligibility verification requests, this is the patient for which the insurance is being verified.
1.16policy number1;16NUMERICThis is the policy number of the patient that is being verified in an eligibility verification request.
2.01date of service2;1DATE-TIMEThis is the date of service that will be used to populate the 401-D1 field of the NCPDP request. It is generally the fill/refill date of the prescription but may also be the release date.
2.02reversal reason2;2FREE TEXTReversal Reason as a free text. Examples: ECME RESUBMIT, RX EDITED, RX DISCONTINUED
2.03durrec2;3FREE TEXTDrug Utilization Review (DUR) information passed by Outpatient Pharmacy to ECME.
2.04override code2;4POINTER9002313.511This is used to store overrides entered by the user via the Resubmit with Edits (RED) option in the ECME User Screen to change certain data elements sent to the payer during resubmission of the claim.
2.05clarification code2;5FREE TEXTThe Submission Clarification Code is entered by the pharmacist and passed by Outpatient Pharmacy to ECME to put into the claim to support/justify the claim request when the payer rejects it. Valid clarification codes are selected from BPS NCPDP CLARIFICATION CODES file (#9002313.25). These codes justify an earlier fill date to the payer. For example if a patient needed an early refill due to being on vacation when the prescription would normally be filled, a VACATION SUPPLY clarification code can be used as justification to the payer for filling the prescription thereby mitigating any claims rejections.
2.06bill ndc2;6FREE TEXTValid NDC# used in the prescription/refill and which is passed to ECME to be used for billing.
2.07pre auth type code2;7FREE TEXTPRIOR AUTHORIZATION TYPE CODE - the first piece of the BPSAUTH parameter passed to ECME engine.
2.08pre auth num sub2;8FREE TEXTPRIOR AUTHORIZATION NUM SUB - the second piece of the BPSAUTH parameter passed to ECME engine.
2.09sc and ei override flag2;9BOOLEAN0:NO
Service Connected and Environmental Indicators override flag. 0 - the system should use the existing answers to SC and EI questions, if there is no answer then SC/EI determination needed and the RX/refill cannot be billed. 1 - the user chose to override all SC and EI related answers with "NO", which means the RX/refill should be billed.
2.1delay reason code2;10POINTER9002313.29This is the Delay Reason Code that is entered by the user from the IB Back Billing Option of Claims Tracking and passed to ECME. It will be be put into field 357-NV of the billing request that is created for third-party billing.
3dur3;0MULTIPLE9002313.771DUR multiple
4.01quantity4;1NUMERICNCPDP quantity (Billing Quantity) - the amount of medication that was dispensed (stored in PRESCRIPTION file (#52)) multiplied by the NCPDP QUANTITY MULTIPLIER (stored in DRUG file (#50)). The negative value -1 indicates an invalid drug.
4.02unit price4;2NUMERICPrice per unit of prescription.
4.03ndc4;3FREE TEXTThe NDC number of the drug involved in this transaction.
4.04refill4;4NUMERICRefill number. 0-original
4.05certify mode4;5SET OF CODES0:OFF
Certify mode is used for certifying software when required by switches and claims end processors.
4.06certification ien4;6POINTER9002313.31This field is used during certification testing, and points to the entry to use to pull certification data.
4.07unit of measure4;7FREE TEXTEnter the Unit of Measure for the drug. This is usually GR (grams), ML (milliliters), or EA (Each).
4.08billing quantity4;8NUMERICThis is the quantity from the prescription and is used to calculate the ingredient cost. It may be different than the quantity used in the actual NCPDP submission.
4.09billing unit4;9FREE TEXTThis is the billing units associated with the billing quantity.
5insurer data5;0MULTIPLE9002313.772Contains set of IB determination data for all billable payers - primary, secondary and tertiary. Should contain at least one entry - usually for the primary payer.
6.01request date and time6;1DATE-TIMEThe Date and Time when the request record was created.
6.02user who made the request6;2POINTER200The user who created the request
6.03activated date time6;3DATE-TIMEThe date and time when the request was activated
6.04user who activated request6;4POINTER200The user who activated the request.
6.05date and time updated6;5DATE-TIMEEThe date and time when the request was updated.
6.06user who updated the request6;6POINTER200The user who updated the request.
7.01close aft rev7;1BOOLEAN0:NO
This field indicates whether the claim should be closed after successful reversal. The ECME engine checks this field when it receives a response from the payer. If the field is set to YES and the reversal was accepted by the payer then the claim will be closed automatically.
7.02close aft rev reason7;2POINTER356.8The NON-BILLABLE REASON selected by the user to be used in IB CLAIM TRACKING system.
7.03close aft rev comment7;3FREE TEXTComment for CLOSE action
8cob other payers8;0MULTIPLE9002313.778This multiple structure stores information about each of the other payers involved in the payment or rejection of the claim. NCPDP has a maximum of 9 occurrences here with a recommendation of less than or equal to 3 occurrences. However, VA only stores data for at most 3 insurance policies for any given claim. So at most there will only be 2 occurrences of this other payer multiple.
9.01inactivation reason9;1FREE TEXTWhen a request is inactivated, the reason that it was inactivated will be stored here so that the cause of the inactivation can be investigated.

Referenced by 4 types

  1. BPS ASLEEP PAYERS (9002313.15) -- prober claim
  2. BPS LOG OF TRANSACTIONS (9002313.57) -- submit request, reversal request
  3. BPS TRANSACTION (9002313.59) -- submit request, reversal request
  4. BPS REQUESTS (9002313.77) -- next request