Pharmacy Claims Processing Workflow Explained
A patient hands over a prescription and an insurance card. Thirty seconds later, the pharmacist knows exactly what the patient owes. What happens in those thirty seconds involves a chain of systems, protocols, and decisions that most people never see. This guide breaks down every step of the pharmacy claims processing workflow, from the moment a prescription enters the system to the moment a PBM returns a paid or rejected response.
Step 1: Prescription intake and data entry
Everything starts at the pharmacy counter. The pharmacist or technician enters the prescription details into their Pharmacy Management System (PMS):
- •Patient info: name, date of birth, address, phone number
- •Insurance info: BIN, PCN, group ID, cardholder ID, person code (from the insurance card)
- •Prescription info: drug NDC, quantity, days supply, prescriber NPI, DAW code, date written
- •Pricing info: ingredient cost, dispensing fee, usual and customary price
The BIN and PCN numbers on the patient's card determine where the claim gets routed. If you're not familiar with these identifiers, our BIN/PCN lookup guide covers them in detail.
Step 2: Eligibility verification (E1 transaction)
Before submitting a claim, smart pharmacies run an E1 eligibility check first. This confirms the patient has active coverage and returns their plan details, copay structure, and any secondary insurance.
Skipping this step is a gamble. Without eligibility verification, you might fill a prescription only to discover the patient's coverage lapsed last month. Now you have a filled prescription, an unhappy patient, and no reimbursement. Our eligibility verification API guide walks through how to check coverage with a single API call.
Step 3: Claim construction (building the NCPDP message)
Once the prescription data is entered and eligibility is confirmed, the PMS assembles an NCPDP Telecommunication Standard D.0 message. This is where things get complicated.
NCPDP D.0 is a binary, pipe-delimited format with over 400 field definitions organized into segments. Each field has a specific position, separator character, and data type. A single B1 billing claim might look like this on the wire:
AM04 C4197103141 C51 C601 CA01234567890 D20019999999999 D700
Those hex characters are segment separators and field identifiers. Every pharmacy system has to encode and decode this format correctly. Get one byte wrong and the claim gets rejected. For more on why this format exists and how modern APIs replace it, see our post on modernizing NCPDP with JSON.
Step 4: Switch routing
The pharmacy doesn't send claims directly to PBMs. Instead, claims flow through a pharmacy claim switch. The switch acts as a router, using the BIN number to determine which PBM should receive the claim.
The major switches in the US include:
- •Change Healthcare (Relay Health): largest switch network, handles billions of claims annually
- •SS&C (formerly DST/Argus): significant market share in retail pharmacy
- •Emdeon/WebMD Health Services: another major clearinghouse
- •NHIN/SureScripts: handles e-prescribing and some claims routing
Connecting to a switch requires a contract, VPN or dedicated line, and months of certification testing. This is one of the biggest barriers to entry for anyone building pharmacy software. Our switch integration guide covers what the traditional process looks like.
Step 5: PBM adjudication
This is the core of the workflow. The PBM (Pharmacy Benefit Manager) receives the claim and runs it through a series of checks:
Member Verification
Is this patient a member of this plan? Is their coverage active? Does the person code match (subscriber, spouse, dependent)?
Formulary Check
Is this drug on the plan's formulary? If so, which tier? Tier 1 (generic) has the lowest copay; Tier 4+ (specialty) can cost hundreds.
Drug Utilization Review (DUR)
Checks for drug interactions, duplicate therapy, early refills, age/gender conflicts, and dosage limits. DUR alerts are returned as response codes that pharmacists must review.
Prior Authorization
Some drugs require pre-approval. If PA is required and not on file, the claim gets rejected with code 75. The prescriber then needs to submit a PA request to the PBM.
Pricing Calculation
The PBM calculates what it will pay the pharmacy (ingredient cost + dispensing fee) and what the patient owes (copay, coinsurance, or deductible). This is based on the plan design, drug tier, and any accumulator programs.
All of this happens in under two seconds. The PBM sends back a response with a status code: "A" for accepted (paid) or "R" for rejected, along with pricing details or reject codes.
Step 6: Response handling
The PBM's response travels back through the switch to the pharmacy. The PMS parses the response and displays the result:
- •Paid claim: shows patient copay, plan payment amount, and authorization number
- •Rejected claim: shows one or more NCPDP reject codes (e.g., 75 = prior auth required, 79 = refill too soon, 70 = drug not covered)
- •DUR alerts: warnings about drug interactions or therapeutic duplications that the pharmacist must acknowledge
If a claim is rejected, the pharmacy can modify the claim and resubmit. Common fixes include correcting patient info, trying a different insurance, applying a discount card, or contacting the prescriber for a therapeutic alternative.
Step 7: Reversals (B2 transactions)
Sometimes a paid claim needs to be reversed. The patient doesn't pick up the prescription. The pharmacist catches an error. The doctor changes the medication. In these cases, the pharmacy submits a B2 reversal transaction that voids the original claim.
Reversals must reference the original claim's authorization number and match the original transaction data. Once the PBM processes the reversal, it deducts the payment from the pharmacy's reconciliation and credits back the patient's benefit accumulators.
The complete flow at a glance
Where modern APIs change this workflow
The workflow above hasn't changed much in 30 years. What has changed is how developers can access it. Traditionally, you needed to:
- • Sign a contract with a pharmacy claim switch
- • Implement the NCPDP D.0 binary protocol (400+ field definitions)
- • Pass NCPDP certification testing
- • Maintain per-payer field requirements across hundreds of PBMs
With Starlight API, steps 3 and 4 collapse into a single JSON request. You send patient, insurance, and prescription data as JSON. Starlight handles the NCPDP encoding, switch routing, and payer sheet management. You get back a clean JSON response with the adjudication result.
See it in action: our guide to submitting pharmacy claims via API walks through a complete claim from curl command to paid response. Or compare approaches in our claims API comparison.
Common rejection codes and what they mean
When a claim gets rejected, the PBM returns one or more standard NCPDP reject codes. Here are the ones pharmacy teams see most often:
Skip the complexity. Start with JSON.
Starlight handles the NCPDP encoding, switch routing, and payer sheets. You send JSON, you get JSON. Submit your first claim in minutes.