PharmaDossier
Specialty

Specialty Pharmacy Transfers: What Happens to a Pending Prior Authorization?

When a specialty Rx transfers between pharmacies while prior authorization is pending, which records actually move, what stays behind, and how Part D party rules apply.

Ran Chen
Ran Chen
21 min read · Published · Source-cited

A prescription transfer is not a prior-authorization transfer

When a specialty prescription is transferred from one dispensing pharmacy to another while an electronic prior authorization (ePA) or coverage determination remains pending with the health plan or pharmacy benefit manager (PBM), the prescription moves. The pending prior-authorization record does not. That procedural separation is not a momentary interface glitch or a vendor software lag; it is the deliberate legal and technical architecture governing pharmacy benefit administration across the United States. For market-access leads, specialty pharmacy operating teams, and clinical hub navigators, confusing prescription routing with coverage adjudication introduces substantial operational friction, avoidable re-submission rejections, and prolonged patient treatment delays.

To manage in-flight prescription transfers effectively, intake coordinators and dispensing pharmacists must separate four distinct operational and regulatory records that are frequently conflated into a single colloquial concept of 'the transfer':

  1. The Prescription Record: The clinical order authored by the licensed prescriber, specifying the drug product, dosage form, strength, quantity, dosing directions, and authorized refills. Under the National Council for Prescription Drug Programs (NCPDP) standards and state pharmacy practice acts, this information is routed between pharmacies using the SCRIPT RxTransfer transaction suite or authenticated pharmacist-to-pharmacist verbal and facsimile communication.

  2. The Pending Coverage Determination / PA Request: The formal administrative and clinical case file pending review within the payer's or PBM's utilization management department. Under Medicare Part D regulations (specifically 42 CFR 423.566) and comparable commercial plan terms, this request is an adjudication file owned exclusively by authorized legal parties—the enrollee, the enrollee's appointed representative, or the prescriber. It is not an asset of the originating dispensing pharmacy and cannot be assigned to another pharmacy through pharmacy-to-pharmacy communication.

  3. The Assigned Prior-Authorization Identifier: The approval voucher and control number generated by the payer's utilization management system once clinical criteria are met. For a pending case, this identifier does not yet exist. When issued, it resides on the payer's eligibility file and may be transmitted to the claim submitter, provided its format complies with strict telecommunication field constraints.

  4. The Point-of-Sale Claim Transaction: The real-time billing transaction transmitted by the dispensing pharmacy to the PBM adjudication engine under the NCPDP Telecommunication Standard D.0. When an authorization is required but absent, the processor returns reject code 75 (Prior Authorization Required). Crucially, the claims engine does not carry status flags indicating that another pharmacy has an open review case pending in the utilization management department.

This analysis stays on one operator job: an in-flight specialty prescription transfer while a pharmacy-benefit prior authorization is still pending. Adjacent jobs live on other PharmaDossier pages: hub-to-specialty enrollment and consent handoffs; manufacturer limited-distribution versus payer-network lockouts; 2027 electronic prior-authorization program readiness; and whether a formulary-change notice changes an already-issued authorization. It is not patient-specific clinical, reimbursement, or transfer advice. The pages below classify the four records that operators keep conflating—prescription, pending coverage-determination request, assigned PA number, and claim—when the dispensing pharmacy changes mid-stream.

Three NCPDP objects, three destinations

The foundational source of operational confusion during specialty pharmacy transfers is the assumption that the National Council for Prescription Drug Programs (NCPDP) maintains a single interoperable pipeline capable of synchronizing dispensing tasks and coverage determinations. In reality, NCPDP defines three separate standards families designed for entirely different endpoints, distinct business purposes, and disparate data models: the Prescription Transfer Standard (implemented via SCRIPT RxTransfer), the SCRIPT Electronic Prior Authorization (ePA) standard, and the Prior Authorization Transfer Standard.

NCPDP Standard / Transaction SetGoverning Standard / BaselineCommunicating EndpointsData Payload & Transaction ScopeBehavior Upon Pharmacy-to-Pharmacy Transfer
Prescription Transfer Standard (SCRIPT RxTransfer)NCPDP SCRIPT Standard (Version 2017071 / 2023011, as incorporated at 42 CFR 423.160)Originating Pharmacy <-> Receiving PharmacyPrescription order details, remaining refills, prescriber identifiers, dispensing historyMoves prescription information between pharmacies; does not move a prior-authorization case file
Electronic Prior Authorization (SCRIPT ePA)NCPDP SCRIPT ePA Transaction Set (42 CFR 423.160)Prescriber EHR / ePA Vendor <-> Payer / ProcessorClinical question sets, supporting attachments, approval/denial determinations, re-authorizationsRemains tethered to prescriber and payer queue; does not route to receiving pharmacy
Prior Authorization Transfer StandardNCPDP Access to Standards CatalogPayer / PBM Processor <-> Payer / PBM ProcessorActive, approved, or historic authorization records migrated during platform conversionsNCPDP's public catalog describes payer/processor file movement when clients, databases, or platforms change; not a pharmacy-to-pharmacy pending-case transaction

The legal separation between these transaction sets is embedded directly in federal regulation. Under 42 CFR 423.160, which establishes the electronic prescribing standards for Medicare Part D, the Department of Health and Human Services (HHS) and the Centers for Medicare & Medicaid Services (CMS) explicitly list these transaction families as distinct regulatory entities. Section 423.160 categorizes RxTransferInitiationRequest, RxTransfer, and RxTransferConfirm side by side with the ePA transaction set: PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification. Performing an RxTransfer does not trigger, populate, or advance a PARequest or PAInitiationRequest under the federal electronic prescribing rules.

When CMS promulgated the 2020 SUPPORT Act electronic prior authorization final rule (85 FR 86824), it established a mandatory requirement for Medicare Part D plan sponsors and prescribers to support the SCRIPT ePA transaction set beginning January 1, 2022. However, CMS crafted that mandate specifically to establish secure, bidirectional electronic exchange between prescribers and Part D sponsors. The regulation was intentionally architected so that prior authorization would be resolved prospectively between the clinician and the insurer before or concurrently with the transmission of the original electronic prescription (NewRx). The rulemaking did not establish, and does not support, a pharmacy-to-pharmacy transaction set for transferring unadjudicated, in-flight coverage determination cases.

Surescripts documents RxTransfer as the NCPDP SCRIPT prescription-transfer path on SCRIPT version 2023011, replacing phone and fax movement of prescription information. It still transmits only prescription data defined by the SCRIPT standard, not the payer's prior-authorization work queue. The prior-authorization case file remains in the payer's utilization management workflow.

flowchart TD
    subgraph PrescriberEndpoint["Prescriber / Clinic Technology"]
        PrescriptionOrder["Electronic Prescription (NewRx)"]
        ePARequest["ePA Initiation / Request (SCRIPT)"]
    end

    subgraph PharmacyNetwork["Dispensing Pharmacy Network"]
        OriginatingPharmacy["Specialty Pharmacy A (Originating)"]
        ReceivingPharmacy["Specialty Pharmacy B (Receiving)"]
        TransferBridge["SCRIPT RxTransfer
(Prescription Data Only)"]
    end

    subgraph PayerAdjudication["Payer / PBM Utilization & Claims"]
        PayerQueue["Prior Authorization Work Queue
(Pending Coverage Determination)"]
        POSClaimsEngine["Point-of-Sale Claims Engine
(Telecommunication D.0)"]
        ApprovedMaster["Approved Authorization Master File
(Numeric ID <= 11 Digits)"]
    end

    PrescriptionOrder -->|Electronic Route| OriginatingPharmacy
    OriginatingPharmacy -->|RxTransferInitiationRequest| TransferBridge
    TransferBridge -->|RxTransferConfirm| ReceivingPharmacy

    ePARequest -->|PAInitiation / PARequest| PayerQueue
    PayerQueue -.->|Isolated from Rx Transfer| ReceivingPharmacy

    ReceivingPharmacy -->|B1 Claim Submission| POSClaimsEngine
    POSClaimsEngine -->|Reject 75: Prior Auth Required| ReceivingPharmacy

    PayerQueue -->|When Approved by Payer| ApprovedMaster
    ApprovedMaster -.->|Field 462-EV Validation| POSClaimsEngine
System architecture separating electronic prescription transfer, ePA exchange, and point-of-sale claims adjudication

Who owns a pending Part D request after the Rx leaves pharmacy A

To understand why a receiving specialty pharmacy cannot simply 'take over' a pending prior authorization, access teams must analyze the statutory nature of a prior authorization under Medicare Part D. In federal healthcare programs, a prior authorization is not an operational workflow ticket owned by a commercial vendor or a pharmacy dispensing system. As established in Chapter 6 of the Medicare Prescription Drug Benefit Manual and formal CMS appeals guidance, any request for coverage of a prescription drug that requires prior authorization constitutes a request for a coverage determination governed by Title 42 of the Code of Federal Regulations, Part 423, Subpart M.

Under 42 CFR 423.566(c), the federal regulations strictly delimit who possesses standing to request a standard or expedited coverage determination. Only three entities are permitted by law to initiate or maintain a coverage determination request:

  • The enrollee (the patient entitled to Part D benefits).

  • The enrollee's appointed representative (designated via Form CMS-1696 or an equivalent legally binding writing).

  • The prescribing physician or other prescriber acting on behalf of the enrollee.

A network dispensing pharmacy is not listed among the requesters in 42 CFR 423.566(c). Chapter 6 of the Medicare Prescription Drug Benefit Manual, pointing to Chapter 18, states that when a prescription cannot be filled as written under the Part D benefit and the issue is not resolved at the point of sale, the network pharmacy must deliver written notice of the enrollee's right to request a coverage determination, including an exception. That pharmacy notice is CMS-10147, Medicare Drug Coverage and Your Rights—not the plan's coverage-determination denial notice (CMS-10146). The corresponding sponsor duty is in 42 CFR 423.562(a)(3) and 42 CFR 423.128(b)(7)(iii): the Part D plan sponsor must arrange with its network pharmacies to distribute those notices. Distributing CMS-10147 is not a coverage-determination filing and does not make the pharmacy a party to a pending request.

As documented in Congressional Research Service (CRS) Report R40611, an enrollee may formally appoint an employee of a pharmacy or a patient advocacy charity to serve as their representative, provided that both parties execute Form CMS-1696 ('Appointment of Representative') or a compliant written equivalent. The July 2026 update to the CMS Parts C & D Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance addresses appointment of representative in section 20. Without that executed appointment, specialty pharmacy B is not a §423.566(c) requester and cannot continue the pending coverage determination in its own name.

Part D party rules do not automatically govern commercial, Medicaid fee-for-service, or ERISA plans. In those markets, pharmacy-initiated ePA remains payer-sheet-specific. Surescripts' electronic prior-authorization product distinguishes a prospective workflow, initiated before the prescription reaches any pharmacy, from a retrospective workflow triggered at the pharmacy's request. If the payer stores a prospective, prescriber-initiated approval as a member- and product-level authorization, that approval may remain usable after the prescription is redirected to another in-network pharmacy. That is a payer-sheet behavior, not an NCPDP transfer of a still-pending case. Approvals that are locked to a dispensing National Provider Identifier (NPI) will not follow the transferred prescription.

Conversely, in a retrospective workflow, originating pharmacy A triggers the prior-authorization case through an online portal after receiving a point-of-sale claim rejection. The resulting case file, portal identification number, and clinical communication history reside within pharmacy A's organizational portal dashboard. When the prescription is transferred to pharmacy B via SCRIPT RxTransfer, portal credentials, user permissions, and case queues do not follow. Pharmacy B cannot view, modify, or append clinical documentation to pharmacy A's retrospective portal case, leaving the receiving pharmacy blind to the exact status of the pending review.

The claim still will not tell pharmacy B that a case is pending

When specialty pharmacy B receives a transferred prescription, its standard operating procedure is to submit a point-of-sale test claim (NCPDP B1 transaction) to determine coverage and patient copayment obligations. When prior authorization remains pending, that claim typically returns NCPDP Reject Code 75 ('Prior Authorization Required'). Operators frequently misinterpret this rejection as evidence that no authorization request has been filed. That assumption is not supported by NCPDP's own Part D FAQ.

In May 2025, the NCPDP Work Group 9 (WG9) Medicare Part D FAQ (Version 37.0) addressed this disconnect. WG9 states that most processor systems do not link prior-authorization denials to claims processing, that reject code 3Y (P/A Denied) is not commonly used for that reason, and that downstream payers should not assume a PA has not been requested merely because the claim returned reject 75 (Prior Authorization Required). Until processors log pending or denied PA status on the claim, a new pharmacy that bills and receives 75 learns only that authorization is required—not that pharmacy A already has a case open.

Reject Code 75 must also be distinguished from NCPDP Reject Code 64 ('Claim Submitted Does Not Match Prior Authorization'). Reject 75 means prior authorization is required; it does not report whether a request is already pending. Reject 64 fires only after a prior authorization has been approved and loaded into the master file, but the claim parameters submitted by the dispensing pharmacy—such as metric quantity, days supply, or servicing prescriber National Provider Identifier (NPI)—do not match the authorized parameters.

Transaction EnvironmentSegment / Message GroupField Name & Technical IdentifierMaximum Length & Permitted Data TypeBehavior and Truncation Risk on Transfer
SCRIPT Electronic Prior AuthorizationePA Response MessageAuthorizationNumberUp to 140 alphanumeric charactersPayer-assigned identifier in the ePA response; alphanumeric, up to 140 characters
SCRIPT Prescription Routing (NewRx / RxTransfer)Prescription-routing message (for example, NewRx)PriorAuthorizationUp to 35 alphanumeric charactersPrescription-routing field is limited to 35 alphanumeric characters; a 140-character ePA number will not fit unless the payer maps a shorter value
Telecommunication Standard D.0 (Claim Submission)Prior Authorization SegmentPrior Authorization Number Submitted (462-EV)Numeric only, maximum 11 digitsUntil Telecommunication F6, D.0 462-EV is numeric up to 11 characters when that is how the claim carries the PA number
Telecommunication Standard D.0 (Claim Response)Response Prior Authorization SegmentPrior Authorization Number Assigned (498-PY)Numeric only, maximum 11 digitsReturned by payer when authorization is recognized; does not exist for a pending coverage determination

As detailed in the NCPDP SCRIPT Implementation Recommendations (Version 1.76, May 2026) and the NCPDP Payer Sheet Template (Version 18, September 2024), these field incompatibilities create severe technical barriers. Until the industry formally adopts Telecommunication Standard F6 under future HIPAA regulatory cycles, Telecommunication D.0 Field 462-EV remains restricted to an 11-digit numeric format. Payers that require 462-EV to be submitted on the claim must ensure that their upstream ePA systems assign voucher numbers that survive this numeric constraint.

Most critically for the transfer scenario: an in-flight, pending prior-authorization case has no assigned 498-PY identifier. Because there is no authorization number to attach to an RxTransfer message or a Telecommunication D.0 claim, an electronic prescription transfer cannot, as a matter of technical standards, deliver a pending-case identifier that receiving pharmacy B can bill against. The claim transaction remains an uninformative blunt instrument until the payer's clinical review reaches a final, recorded determination.

2027 FHIR APIs will not fill this gap unless a final drug rule says so

Health system executives and specialty pharmacy leaders frequently express optimism that the interoperability mandates established under federal digital health rules will automatically resolve the prior-authorization visibility gap by 2027. This expectation represents a fundamental misreading of active federal regulations versus proposed administrative rulemaking.

On January 17, 2024, CMS published the Interoperability and Prior Authorization Final Rule (CMS-0057-F, 89 FR 8758). While CMS-0057-F established groundbreaking requirements for Medicare Advantage organizations, state Medicaid agencies, and qualified health plan (QHP) issuers to implement Fast Healthcare Interoperability Resources (FHIR) Application Programming Interfaces (APIs)—including the Patient Access API, Provider Access API, and Payer-to-Payer API by January 1, 2027—the final rule explicitly and repeatedly excluded prescription drugs. Across every regulatory section mandating prior-authorization transparency via FHIR APIs, CMS inserted the specific qualifying parenthetical: '(excluding those for drugs)'. Consequently, under currently binding federal law, impacted payers are not required to expose pharmacy-benefit prior-authorization statuses, pending determinations, or denial rationales through the 2027 FHIR interoperability infrastructure.

Even if CMS-0062-P is finalized exactly as proposed, its structural design reinforces, rather than dismantles, the boundary between pharmacy-to-pharmacy routing and coverage determination. In the preamble to CMS-0062-P, CMS proposes extending electronic prior authorization, aligned decision timeframes, and more specific denial information to prescription drugs beginning October 1, 2027. Those proposed clocks are program-specific in the NPRM and are not a single 72-hour/24-hour rule for every payer and benefit; Part D coverage determinations already use the timeframes in 42 CFR 423.568 and 423.570. The proposed rule also establishes a jurisdictional split between benefit types:

  • Medical-Benefit Drugs: Specialty pharmaceuticals administered in physician offices, outpatient clinics, and hospital infusion suites (Part B / buy-and-bill) would be governed by the FHIR Prior Authorization API standards.

  • Pharmacy-Benefit Drugs: Specialty drugs dispensed by retail, mail-order, and specialty pharmacies under Part D and commercial pharmacy benefits would be governed exclusively by the NCPDP SCRIPT standard.

The CMS-0062-P preamble characterizes the FHIR Prior Authorization API and the NCPDP SCRIPT standard as 'mutually exclusive' pathways that together encompass a payer's covered drug portfolio. Furthermore, CMS-0062-P models pharmacy-benefit ePA exclusively as a transaction exchange between prescribing healthcare providers and the issuing payer. It contains no regulatory mechanism, data dictionary, or mandate establishing pharmacy-to-pharmacy pending-case handoffs. As a result, neither the 2027 CMS-0057-F mandates nor the proposed CMS-0062-P framework will automatically transfer pending prior-authorization files between competing specialty pharmacies upon prescription transfer.

What else can still block the fill after the records are sorted

Resolving the legal and technical boundaries of prescription transfers and pending prior authorizations addresses only the initial administrative hurdle. Once pharmacy B successfully establishes legal standing, coordinates with the prescriber, and secures prior-authorization approval, the prescription can still encounter secondary fulfillment lockouts. Operating teams must systematically evaluate three additional statutory and regulatory checkpoints:

Fulfillment CheckpointStatutory & Regulatory BasisOperating Rule & GovernanceImpact on Prescription TransferPost-Transfer Dispensing Risk
Controlled Substance Transfer RulesDEA 21 CFR 1306.08 & 21 CFR 1306.25Electronic Schedule II–V initial prescriptions permit a one-time transfer; Schedule III–V refills permit one-time transferTransfers legal prescription data only; regulations do not capture, mention, or transfer prior authorization filesOne-time for the 21 CFR 1306.08 initial-dispense transfer; 21 CFR 1306.25 refill transfers of III–V are also one-time unless the pharmacies share a real-time database
Privacy & Data PermissibilityHIPAA Privacy Rule (45 CFR 160.103 & 164.506)Disclosures permitted for Treatment and Payment without individual authorization; Minimum Necessary applies to paymentPharmacy A is legally permitted to share clinical packets, but is not compelled to reassign proprietary portal accountsPharmacy B must obtain clinical chart notes directly if pharmacy A declines voluntary coordination
Network Adequacy & Limited Distribution42 CFR 423.120(a)(8) & Chapter 6 §30.2.2.3Part D any-willing-pharmacy applies to standard terms; Chapter 6 §30.2.2.3 lists PA-form steering to a sponsor/PBM specialty pharmacy as non-allowable except for manufacturer or FDA limited-distribution drugsPrior authorization approval does not confer network participation or manufacturer distribution allocationClaim rejects for out-of-network provider or pharmacy lacks access to drug inventory, blocking dispensing

First, for specialty medications that are controlled substances (such as certain narcolepsy therapeutics, central nervous system stimulants, or specialty analgesics), the Drug Enforcement Administration (DEA) enforces strict transfer boundaries under 21 CFR 1306.08 and 1306.25. Section 1306.08(e)–(i) permits a one-time, patient-requested transfer of an electronic Schedule II, III, IV, or V prescription between retail pharmacies for initial dispensing, provided that authorized refills for Schedules III–V travel with the initial order, state law permits the transfer, and both pharmacies maintain audit records for two years. Refill transfers of Schedule III–V prescriptions remain governed by § 1306.25, requiring specific pharmacist-to-pharmacist communication of original prescription numbers, dates, and DEA registration numbers. Neither DEA regulation requires, names, or acknowledges prior-authorization records. An electronic controlled-substance transfer moves legal dispensing authority, but transmits zero payer coverage data.

Second, information sharing between pharmacies is governed by the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule. Under 45 CFR 160.103, 'health care' explicitly includes the sale or dispensing of a drug in accordance with a prescription. Under 45 CFR 164.501, 'treatment' encompasses the provision, coordination, or management of health care, including consultations and referrals between providers. Crucially, 45 CFR 164.506(c)(2) permits a covered entity to disclose protected health information (PHI) for the treatment activities of another healthcare provider without requiring patient authorization. Furthermore, 45 CFR 164.506(c)(3) allows disclosures to another covered entity for the recipient's payment activities, subject to reasonable minimum-necessary standards.

While 45 CFR 164.506 legally permits specialty pharmacy A to transfer clinical documentation, lab values, and prior-authorization status records to specialty pharmacy B to facilitate treatment and payment, the regulation does not compel pharmacy A to perform administrative casework on behalf of a competitor. More importantly, HIPAA permissive disclosure cannot electronically reassign proprietary portal accounts or transfer third-party hub authorizations. A manufacturer patient-support hub enrollment form governed by 45 CFR 164.508 is an entirely separate legal instrument that does not transfer through an NCPDP RxTransfer message.

Third, even after an authorization is approved and attached to the patient's cardholder file, network and distribution gates can prevent pharmacy B from dispensing. Under 42 CFR 423.566(b)(1), a plan's refusal to pay for a drug because it is furnished by an out-of-network pharmacy constitutes an adverse coverage determination. Although 42 CFR 423.120(a)(8) requires Part D plan sponsors to contract with any pharmacy that meets standard terms and conditions and forbids requiring insurance risk as a participation condition, plans may still add preferred or subset specialty terms that are tighter than the standard network. Chapter 6 §30.2.2.3 lists, as a non-allowable PA-form practice, steering physicians or beneficiaries to a sponsor's or PBM's own specialty pharmacy except for drugs restricted to select pharmacies based on manufacturer or FDA distribution limitations. Limited-distribution allocation and a separate FDA REMS pharmacy certification remain independent fill gates. If pharmacy B is outside the manufacturer's limited network or lacks a required REMS certification, an approved PA does not create a right to acquire or dispense the product. For those gates, see PharmaDossier's pages on limited-distribution specialty pharmacy lockout and REMS distribution design as a specialty-pharmacy bottleneck.

Operator checklist, then stop

To avoid administrative dismissals, claim submission deadlocks, and unnecessary therapy delays when receiving a transferred specialty prescription, pharmacy intake and access operations should execute the following eight-step protocol:

  1. Classify Benefit Structure: Confirm whether the specialty product is billed under the pharmacy benefit (NCPDP Telecommunication Standard D.0 / SCRIPT ePA) or the medical benefit (buy-and-bill / CMS-1500 / 837P). Do not apply pharmacy transfer workflows to medical-benefit organization determinations.

  2. Identify Case Originator: Determine whether the pending prior authorization was initiated prospectively by the prescriber through their EHR system, or retrospectively by originating pharmacy A through a vendor portal. Prescriber-owned prospective cases remain viable across pharmacies once approved; pharmacy-owned retrospective cases do not.

  3. Verify Part D Requester Standing: For Medicare Part D beneficiaries, ensure the receiving pharmacy does not attempt to modify or resubmit the coverage determination under its own NPI without legal standing under 42 CFR 423.566(c). If direct coordination is required, secure an executed Form CMS-1696 (Appointment of Representative) signed by the enrollee.

  4. Contact Payer Prior Authorization Department Directly: Before generating a new electronic prior-authorization request, telephone the health plan's utilization management department to verify whether an active review case is currently open. Submitting a duplicate request through a second pharmacy can trigger administrative case collisions, duplicate-case cancelations, or clock resets.

  5. Audit Authorization Number Constraints: If the payer reports that an authorization has been approved, obtain the exact authorization voucher number. Confirm that the identifier complies with Telecommunication Standard D.0 Field 462-EV constraints (strictly numeric, 11 digits or fewer). If the number is alphanumeric or longer than 11 digits, request that the payer link the approval directly to the member's cardholder file to allow adjudication without Field 462-EV submission.

  6. Audit Network, LDD, and REMS Dispensing Eligibility: Verify that the receiving pharmacy is actively contracted within the payer's specialty network tier, holds active dispensing authorization within the manufacturer's limited distribution network, and maintains required institutional certification under any applicable FDA REMS ETASU programs.

  7. Request Clinical Support Packet Under HIPAA Treatment Pathways: Request the diagnostic chart notes, prior therapy failure documentation, and laboratory reports from originating pharmacy A under 45 CFR 164.506(c)(2) treatment coordination rules. Do not rely on verbal confirmations that documentation was previously submitted.

  8. Establish Clinical Baseline and Reset Expectations: Never advise a patient or prescribing physician that an electronic prescription transfer 'transfers the prior authorization.' Explicitly communicate that while the prescription has moved, the coverage determination remains subject to payer adjudication timelines.

Treat prescription routing, the pending coverage-determination request, any assigned PA number, and the claim as four separate records. Do not treat RxTransfer as a PA transfer. This sequence is record classification, not advice to transfer or not transfer a named patient's drug, not a named PBM's case-reuse rule, and not a search-volume claim.

Sources

Ran Chen
Contributing Editor
Ran Chen

Founder, PharmaDossier. Life-sciences operator covering market access, specialty pharma, biosimilars, and regulated healthcare growth.

Follow on LinkedIn →