Skip to main content

NCPDP Basics

  1. Last updated
  2. Save as PDF

Medicare Part D is a federal program to subsidize the costs of prescription drugs for Medicare beneficiaries in the United States. This program was originally targeted for only retail pharmacies. Long Term Care (LTC) pharmacies were included in the program. The definition extends to include ICF's/MR and inpatient psychiatric hospitals, along with skilled nursing and nursing facilities.

Medicare Part D Retail Workflow

The Medicare Part D regulations pertain to the clinical workflow imposed on how the prescription is submitted and filled. In the retail world, the prescription will be transmitted to the pharmacy (e-prescribing) or provided by the patient. The pharmacy fills the prescription for the first time (e.g., 30 tablets for a drug taken once per day) and marks the bottle with the remaining refills. The pharmacy can now bill that first fill all at once.

NCPDP

NCPDP stands for the National Council for Prescription Drug Programs. The mission of the NCPDP is to create and promote data interchange standards for the pharmacy services sector of the health care industry.

Pharmacy File Transmissions

The NCPDP file format is a single standard file submission for pharmacy claims. The batch file is to be submitted in a non-real time mode. This file submission can be used to bill pharmacy claims to Medicare Part D prescription drug plans or to other guarantors accepting pharmacy claims. To date, there are very few guarantors accepting the NCPDP file format, but the trend is slowly changing. and the industry as a whole is moving to have all pharmacy claims submitted using the NCPDP file format.

Challenges with Inpatient Workflow

The Federal Regulations set forth by CMS (Centers for Medicaid and Medicare Services) were written specifically for the retail world. Specific regulations for LTC (long term care) facilities have been included, however, there are still many challenges with applying language to our paradigm. The LTC regulations still don't provide enough clarification on how the workflow should be handled in an inpatient treatment setting.

The physician's order must contain the following information not normally captured for inpatient orders:

  • Number of Refills Allowed
  • Dispense As Written
  • Expected Days Supply

The prescription filled by the pharmacy is not done all at once. NDC (national drug code) numbers can change throughout an entire fill (generally a 30-day period) yet each claim representing a fill event must represent the accurate NDC dispensed and must be a full fill period. Billing irregular Days Supply from claim to claim for the same prescription number is prohibited.

myAvatar Pharmacy Billing

NCPDP D.0 File Format

myAvatar supports the ability to bill Medicare Part D claims on the NCPDP D.0 format. The functionality is supported using myAvatar Practice Management, myAvatar Order Entry, myAvatar HL7 Module, and RxConnect. myAvatar eMAR is used for administration of medications. If bill upon administration is set in RxConnect, then charges are created upon successful administration of unit dose medications.

  • myAvatar OE is the CPOE system where the physician's orders originate. This is primarily an inpatient CPOE system but can support outpatient orders as well.
  • RxConnect is the pharmacy system that connects to myAvatar OE. All prescriptions are filled and dispensed in this application.
  • myAvatar PM is the Practice Management system where all of the NCPDP billing originates.
  • myAvatar HL7 Module is needed to support the exchange of data between myAvatar and RxConnect.
  • myAvatar eMAR is used to record the administration of medications. The myAvatar eMAR solution may not be required to implement NCPDP, but it is part of the Closed Loop Solution for myAvatar . RxConnect can be configured to generate charges when the medication is dispensed, rather than administered. ADMs can also be used to generate a charge upon dispense. Bulk items, Leave Meds, and Discharge Meds are billed upon dispense automatically.

837 File Format

myAvatar will support billing pharmacy charges on an 837 Institutional or 837 Professional file. This information will be included in Loop 2410 and will include the NDC #, Drug Quantity, Unit of Measurement, and RxNumber (prescription number). These file formats are standard to myAvatar PM, but do require configuration in the Guarantor/Program Billing Defaults form.

NCPDP Billing Workflow

  1. A client is admitted and assigned a guarantor that is defined as an NCPDP payer. The financial class of the guarantor is defined and mapped to the System Financial Class of Medicare D/NCPDP.
  2. Demographic data is passed to RxConnect via HL7.
  3. The client's physician enters a medication order within myAvatar OE, which is then sent to RxConnect via HL7 to be processed and dispensed by a fill list or Automatic Dispensing Machine (ADM).
  4. The order is sent to the eMAR from OE, and when the medication is filled in RxConnect, the fill details are passed to the eMAR to update the medication description with the information from RxConnect.
  5. Medications are acknowledged and administered by the nurse and recorded in the eMAR.
  6. The successful medication administrations are sent back to RxConnect for billing upon administration. Bulk medications, and Leave or Discharge medications are billed upon dispense in RxConnect.
  7. Charges are sent once a day to myAvatar PM from RxConnect, either based on dispense or administration. These charges are sent to myAvatar at the time set in RxConnect's Configuration screen. The charges are queued up in the HL7 queue waiting for an myAvatar user to access the charges in the HL7 compile form in myAvatar PM.
  8. The pharmacy charges are compiled within the Compile Inbound HL7 Charge Batch File form. An error report is created indicating which charges will be posted and which ones will not be posted, and why. The errors can be corrected and the HL7 recompiled to pick up the corrections. It is important to correct the errors prior to posting the compiled batch.
  9. The pharmacy charges are then posted within the Post Inbound HL7 Charge Batch File form. At this time, the services are rendered and appear on a clients' ledgers and fall to the appropriate guarantor based on each client's eligibility setup. Covered Charge Categories of Pharmacy, Over the Counter, and possible others determine the liability distribution in the myAvatar Benefit Plan.
  10. Charges are CLOSED and put into an UNBILL status in myAvatar PM. The status displays on the Client Ledger.
  11. Charges falling to NON-NCPDP/Medicare D guarantors will bill on the 837I or 837P.
  12. The charges falling to Medicare D are rolled-up for the month using the Compile/Edit/Post/Unpost Roll-Up Services Worklist form in myAvatar . The roll-up process will appropriately gather the charges eligible for pharmacy billing by comparing the Client, Order Prescriber, Prescription Number, and NDC. These charges are rolled into one charge to be billed with the appropriate Days Supply and NDC. The component charges are written off in myAvatar PM leaving only the rolled up charge to be claimed.
  13. A Medicare D batch is created to pick up the clients with rolled-up charges.
  14. The rolled-up charges are then CLOSED and put into an UNBILL status, ready for electronic billing.
  15. Using the Electronic Billing form, an NCPDP billing file can be sorted and claimed. Upon creating the file on the server, the file is then picked up by the third party application CE2000. The path and file name sent to (CE2000 cannot exceed 50 characters. It is a limitation of CE2000).
  16. DayTech's CE2000 software is used to process the data and converts it into a standard NCPDP file format. CE2000 transmits the file to the switch (RelayHealth or Change Healthcare [Retail Solutions]) to be sent to process with the guarantor (PDP). A response file is received immediately and returned back to myAvatar . It is a filename.rtb record.
  17. Avatar imports and processes the response file from CE2000. This process happens automatically and the data is stored is SQL tables for reporting. If a response is not received within 35 seconds then CE2000 sends a default response. An 835 remittance is sent later by the guarantor (PDP) for posting payments and adjustments.
  18. The error correction and rebilling process can begin as soon as the response file is loaded.

DayTech

DayTech is an independent software company that handles its own installation, implementation, documentation and support.

NCPDP Payers must be set up with DayTech.

myAvatar does provide formatted templates designed to crosswalk the data smoothly from myAvatar to their corresponding NCPDP segments field locations within the submission file created by DayTech.

NCPDP Formats

File Transmission Type Supported in myAvatar

  • B1 Billing - Transaction Claim Submission: claims going out of myAvatar for processing with DayTech. This will include rebill claims.
  • B1 Billing - Transaction Claim Response: claim response information coming into myAvatar from DayTech. This file will include the claim status, DUR Reason codes, and possibly Reject codes.
  • The B2 Reversal - Transaction Claim Submission is a reversal of a claim that received some sort of payment. This is nearly identical to the B1 claim submission file.
  • B3 Rebilling - Transaction Claim Rebill: combination of a B2 Claim Reversal of the previously paid claim and a B1 Claim Submission of the new claim within one transaction.
  • E1 Transmissions - Eligibility Verification (Patient Level)

File Transmission Types Supported in RxConnect

  • D1 - Predetermination of Benefits: Transaction for a provider to determine drug coverage and patient financial responsibility.