Rebate Model Frequently Asked Questions

What is the 340B Rebate Model Pilot Program?
​

In July 2025, HRSA released guidance for a 340B rebate model pilot program (“340B Rebate Model”). The 340B Rebate Model initially applies to the 10 products selected for Medicare’s maximum fair price (MFP) program and will operate for a minimum of one year. For any products approved for participation in the 340B Rebate Model, covered entities will initially purchase the product at the wholesale acquisition cost (WAC), submit the required data to Beacon and then receive payment of a 340B rebate which will lower the net cost of the product to the 340B ceiling price.

What is Beacon?
​
Beacon is a technology platform operated by Second Sight that enables the 340B Rebate Model. Covered entities will utilize Beacon to initiate a 340B rebate request by submitting the required data, track the status of a 340B rebate request, receive payment of the 340B rebate and access data to perform financial reconciliations. Covered entities will also use Beacon to research a 340B rebate status and initiate a good faith inquiry in instances where the covered entity believes it has not received a 340B rebate that it is due.
​

How is the Beacon platform different from the 340B ESP platform and does my covered entity still need to use 340B ESP?
​

The 340B ESP platform supports manufacturers’ contract pharmacy policies and will continue to do so by enabling covered entities to make contract pharmacy designations, apply for wholly owned contract pharmacy exemptions and submit 340B claims data. Contract pharmacy eligibility from 340B ESP will be effectuated through 340B claims validation in Beacon and utilization for ineligible contract pharmacies will remain ineligible for 340B rebate payments.
​

In addition to retail claims data, Beacon also supports the collection of claims for utilization across separately payable product administrations, and outpatient product administrations for subsequent 340B rebate payments. Although covered entities will not be required to submit 340B claims data to 340B ESP for products that are part of the 340B Rebate Model, please note that pharmaceutical manufacturer policies may require the continued submission of claims data in 340B ESP for products not in scope for the 340B Rebate Model.

Will my covered entity continue to have access to 340B pricing through my wholesaler for products in the 340B Rebate Model
​
Covered entities will no longer have access to 340B pricing through their wholesalers for those products in the 340B Rebate Model. Please visit the Resources page to view manufacturer policies. For products in scope for the 340B Rebate Model, covered entities will purchase these products at a commercial price (e.g. wholesale acquisition cost or WAC) and then receive a rebate payment on the purchase once 340B claims have been submitted, validated, and accumulated in Beacon.
​

Does my covered entity need to register an account with Beacon if it already has an account with 340B ESP?
​

Covered entities will need to register a new account on Beacon regardless of their existing account status with 340B ESP. Covered entities can register a Beacon account by navigating to the registration page. For a step-by-step tutorial on successfully completing the Beacon registration, visit the Beacon Support Center. Accounts are administered for each covered entity (340B ID) individually, but an authorized user may register multiple covered entity accounts during the registration process if all appropriate information and documentation is provided. Beacon accounts do not need to be registered by the same individual that registered a covered entity’s 340B ESP account.
​

Does my covered entity have to register for a Beacon account if my covered entity is already registered with Beacon MFP?
​
Second Sight operates a separate technology platform under the Beacon brand to support the MFP program. Beacon MFP is available to dispensing entities that receive MFP rebate payments as part of the MFP program. Many covered entities will participate in both the MFP and 340B Rebate Model programs and may utilize both Beacon MFP and Beacon Rebate Model. Separate registration is required for each of these technology platforms due to the very different functionality that is supported in each platform.
​

Are the Beacon Rebate Model and Beacon MFP platforms integrated?
​

Users will log in to Beacon Rebate Model separately from Beacon MFP and the user interfaces are not integrated. However, 340B rebate data created in Beacon Rebate Model is integrated with Beacon MFP in order to account for duplication in MFP and 340B rebates.
​​

Does my covered entity have to register for a Beacon account if my covered entity is already utilizing a virtual inventory model?
​

340B pricing for all eligible 340B utilization for in-scope products will be effectuated through 340B rebate payments. Covered entities will gain access to 340B rebate payments by submitting valid purchase data and associated 340B eligible dispense or administration data to Beacon. Please review the manufacturer policy or the NDC list of products in scope for Beacon Rebate Model in the Beacon Resources page.

What 340B utilization does my entity need to submit to Beacon to receive 340B rebate payments?
​

Covered entities should refer to the Beacon Resources page for more information on the claims required for a given policy. For in-scope products, covered entities should submit 340B utilization for all eligible contract pharmacies as well as in house pharmacies. Beacon supports the submission of retail dispenses, separately payable product administrations, and outpatient product administrations.

Do 340B contract pharmacy policies still apply to products that are part of the 340B Rebate Model?
​

Beacon will determine eligibility of 340B rebate requests submitted by 340B covered entities in part based on the eligibility of the dispensing pharmacy considering a manufacturer’s contract pharmacy policy. Covered entities should utilize 340B ESP to make eligible contract pharmacy designations. Covered entities must remain in compliance with the 340B contract pharmacy eligibility requirements for all products subject to the 340B contract pharmacy policy in order to be eligible for 340B rebate payments on utilization dispensed through contract pharmacies.
​

How does Beacon associate 340B claims with 340B purchases shipped to a contract pharmacy location?

Claim submissions dispensed through a 340B contract pharmacy location will only be associated with purchases made by the covered entity and shipped to the same 340B contract pharmacy location.

Can my covered entity utilize our ESP account credentials to log in to Beacon?

Covered entities must complete their Beacon enrollment and registration on the Beacon Rebate Model platform. During enrollment the authorized administrator of the covered entity is asked to first provide and validate their email address. Once approved, the account administrator must provide the requested documentation for each of their selected covered entities before establishing their Beacon credentials. After Beacon credentials are finalized, an administrator can complete the entity’s account setup once logged in to Beacon.
​

How does my covered entity register a Beacon account?
​

Covered entities can register a Beacon account by navigating to the registration page. Registering users are first asked to provide basic contact information and select one or multiple covered entities that they are authorized to register. Following verification of the provided contact details, registering users provide documentation to establish registration authorization. For a step-by-step tutorial on successfully completing the Beacon registration, visit the Beacon Support Center.
​

Does Beacon require that my covered entity registers with the same authorized user from ESP or Beacon MFP?
​

The same individual that registered a covered entity account on 340B ESP or a dispensing entity account on Beacon MFP is not required to register the account with Beacon. The individual registering a covered entity account on Beacon Rebate Model must be authorized to do so, verify their email, and have all required information and documentation to complete account registration.

Can my consultant or TPA complete the Beacon registration on my covered entity’s behalf?
​

Covered entities may have a third party register an account on their behalf assuming appropriate authorization has been established between the covered entity and third party. The individual registering an account for a covered entity must have all required information and documentation in order to successfully complete the registration process. Additional information regarding what is required to complete the Beacon registration process is available in the Beacon Support Center as well as in the following FAQs.
​

What information is required to register an account with Beacon?
​
Covered entities can register an account with Beacon free of charge. A registering user must first establish affiliation with the 340B covered entity by providing an EIN, IRS letter (CP575) with the entity address, Articles of Incorporation, and a W-9 for the covered entity. This information is validated by a third party adhering to Know Your Business standards. Once validated, the registering user establishes their Beacon account credentials and sets up their multi-factor authentication (MFA). Following successful enrollment of a 340B covered entity, the registering user or another user established as an Administrator on the enrollment needs to request and submit a Bank Letter from its US financial institution with bank account information for ACH payments.. This occurs once logged in to Beacon. The ACH information must be successfully verified as associated with the 340B covered entity prior to any 340B rebate payments.
​

Why is my covered entity asked to submit a Bank Letter from its US financial institution?
​

Covered entities must validate their bank account information as part of the registration process. This final registration step will occur once the Administrator has completed the initial enrollment steps and established their Beacon credentials. Eligible covered entities submitting valid purchase data and 340B claims data for in-scope products receive 340B rebate payments to this approved bank account facilitated through Beacon.
​

Does my covered entity have to complete registration for each child site?
​

Hospital covered entities only need to register an account for the parent 340B ID. Grantee covered entities must register each unique 340B ID though users may register and manage multiple covered entities in a single account.

To support additional flexibility in how 340B rebate payments are managed and reconciled, users may register multiple bank accounts with a single Beacon account. Individual bank accounts can be associated with different pharmacy locations (i.e. a distinct NPI) though only one bank account can be associated with any single pharmacy location.
​

Can my covered entity complete Beacon registration without bank account information?

After completing the initial enrollment and registration, users establish their Beacon account credentials and their multi-factor authentication (MFA). Once logged in to their Beacon account, the Beacon platform prompts the Administrator to provide and verify the banking details for their covered entity. This includes submitting a certified Bank Letter from its US financial institution and providing the appropriate bank account information for ACH payments. This documentation must be successfully verified as associated with the 340B covered entity prior to the payment of 340B rebates.
​

What data does my covered entity need to submit to Beacon to receive 340B rebate payments?

Beacon supports the submission of eligible purchase data and 340B claims data for eligible retail pharmacy dispenses, separately payable product administrations, and outpatient product administrations. 340B rebate payments are made following the successful submission, validation and accumulation of these data.

Does my covered entity have to submit data to Beacon if my covered entity is already submitting data to ESP?
​

Covered entities should review each specific manufacturer’s policy to determine which products are in scope for 340B rebate payments. 340B claim submissions for products participating in the 340B Rebate Model can only be made in Beacon. Users that attempt to submit 340B claims for 340B Rebate Model products in 340B ESP will be notified of the requirement to submit the 340B claims in Beacon and the 340B claims will not be ingested into 340B ESP. However, products not in scope for 340B rebate payments may still require the submission of 340B claims data in 340B ESP. Visit the Beacon Resources page to learn more.
​

My TPA is currently submitting data to ESP via a software development kit (SDK), can my covered entity leverage this same SDK for Beacon?
​

Covered entities and TPAs should utilize the Beacon SDK to facilitate direct data submissions. The 340B ESP SDK will not support data submissions for 340B rebate payments. Covered entities and their TPAs can contact Beacon’s customer support to learn more about how to receive and install the Beacon SDK. Covered entities can also navigate to the appropriate module to upload and submit their purchase and claims data in Beacon. Additional support on navigating submissions is available in the Beacon Support Center.
​

How does a pharmaceutical manufacturer use the 340B claims data submitted to Beacon?

340B claims data submitted by a covered entity or TPA are used to validate the eligibility of the dispense or administration for a 340B rebate payment. Validated 340B rebate data are also used to determine the MFP refund amount after accounting for prohibited duplication with 340B pricing. Furthermore, 340B claims data may be used to identify ineligible rebates on Medicaid and commercial utilization. Please review the policies posted in the Beacon Resources page for more information on the eligibility business rules used in the claims validation process.

How frequently can my covered entity upload claims data to Beacon?
​
Beginning January 1, 2026, covered entities can submit 340B claims data to Beacon as soon as claims are qualified as 340B eligible by the covered entity or its TPA. 340B rebate payments can only be made following the submission and validation of purchase and 340B claims data to Beacon and covered entities are encouraged to submit the claims data in a timely manner.
​

How are inconsistencies in the unit of measure between pharmacy and medical claims resolved in Beacon?
​

Certain products may be billed using different units of measure when dispensed to a patient and reimbursed under the pharmacy benefit versus when administered to a patient and reimbursed under the medical benefit. For example, a product may be dispensed in milliliters but administered in milligrams. Beacon is configured to accept pharmacy and medical claims in pre-established unit volumes and unit validations are performed prior to claims data submission to ensure Beacon ingests an expected unit value for pharmacy and medical claims. Look up tables with the unit validations are available online on the Beacon Resources page and covered entities are encouraged to review these unit validations prior to 340B claims submissions.
​

How are claim reversals submitted and processed in Beacon?
​

Submission of a claim to Beacon is a request for payment of a 340B rebate and covered entities should only submit final claims. In the event that a previously submitted and validated claim must be reversed, covered entities should submit the same claim detail with a negative unit amount. The negative unit amount will be used to reverse the positive unit amount of the earlier claim. Reversed 340B claims will offset payment of a similar number of units on a future 340B rebate request.
​

How should my covered entity correct data that was incorrectly submitted?
​

If a covered entity submits claims data that is initially rejected by Beacon, then the covered entity can resubmit the claims data with the corrected information. If a covered entity submits claims data that is initially accepted by Beacon, but later deemed incorrect by the covered entity then the covered entity must submit a reversal for that initial submission and then resubmit the claims data with the corrected information.
​
​

What is a pharmacy claim?

A pharmacy claim is an adjudicated prescription claim originating from a retail, mail-order or a specialty pharmacy dispense of a medication for subsequent self-administration by the patient.
​

What fields are collected as part of pharmacy claim submissions?

What is a medical claim?

A medical claim is a healthcare claim originating from a physician’s administration of a medication directly to a patient in an outpatient setting. The physician administered product may have been separately reimbursed (e.g. an infused oncology medication) or may have been reimbursed as part of an outpatient procedure (e.g. the administration of a blood thinner). The claims are generally reimbursed by a patient’s medical benefit and are identified using a HCPCS code such as a J-Code. These are the same types of product administrations that would be covered by Medicare Part B.
​

How should my covered entity submit multiple administrations of the same product to the same patient on the same day?
​

When multiple administrations of the same product are administered to the same patient, on the same day, covered entities should aggregate these administrations into a single claim where the quantity reflects the total units of the product administered to the patient on that specific date of service. After a claim has been submitted, subsequent claims submitted for the same combination of Date of Service, Claim Number, Service Provider ID and NDC-11 will be treated as duplicates and will not be accepted. However, reversals (i.e., claims with a negative unit amount) of the initial claim will be accepted to fix incorrect or invalid submissions.
​

What fields are collected as part of medical claim submissions?
​
​

How is the 340B rebate amount calculated for an individual purchase?​​

340B rebate amounts are determined based on a combination of purchase and claims data. The WAC and 340B prices are established based on the purchase date of the product. For example, if a product is purchased on February 1st, 2026 and the product is dispensed on February 4th, 2026, the WAC and 340B prices will be based on the February 1st purchase date.
​
340B rebate amounts are not reduced to reflect duplication in other channels such as Medicare, Medicaid or commercial channels. Instead, the 340B rebate data is used to identify instances of duplication in those channels and the corresponding rebate in the other channel is reduced or rejected. For example, the MFP refund amount for an MFP rebate that was already paid a 340B rebate will be reduced to account for the prohibited duplication between 340B and MFP discounts.
​

How long does it take for a 340B rebate payment to be processed and paid?
​

340B rebates are typically processed and paid within 10 days of a covered entity’s submission of eligible 340B claims and purchase data. 340B rebates are paid on individual 340B claim submissions which allows for 340B rebate payments upon receipt of the 340B claims data and without the need to accumulate up to the package level.
​

Are 340B rebates paid on individual dispenses of a product or for purchases of the product?

Although the 340B price is determined based on the purchase date of the product, 340B rebate payments are made at the claim level upon submission of eligible 340B claims data. In instances where the dispensed units are less than the package size, 340B rebate payments will be initiated as soon as eligible 340B claim submissions are made and corresponding purchase data submissions are made. For example, a package of a product may contain 100 units and a typical dispense of that product may contain 30 units. A 340B claim submission for 30 units will result in a 340B rebate payment that represents 3/10 of the package level 340B rebate amount.
​

Can my covered entity reconcile 340B rebate payments back to both purchase submissions and claims submissions?
​
Covered entities will be able to reconcile 340B rebate payments back to both submitted purchase data and submitted claims data. This information is available in Beacon to review as well as accessible through a downloadable data report.
​

How does Beacon determine duplication across Medicare and Medicaid?
​
Beacon utilizes data elements within the submitted claims data to identify potential duplication with MFP and Medicaid rebate requests. MFP rebate requests that are duplicative with 340B rebate payments will be reduced to reflect the 340B price already made available to the dispensing entity. In instances where the MFP rebate has already been paid, a corresponding credit will be recorded with the MTF’s credit/debit ledger. Duplication in Medicaid will be addressed by rejecting or reversing Medicaid rebates. Depending on state law, this rejection or reversal of the Medicaid rebate may trigger changes in reimbursement to the covered entity.

Are there available resources for educating my covered entity?
​
The Beacon Support Center hosts an array of content including educational videos that range in topics from Account Registration to Data Submissions, step-by-step guides on utilizing Beacon, downloadable data templates to streamline the data intake process, and articles that help further elucidate Beacon functionality. Visit the Beacon Support Center and the Resources page to learn more.
​

How should my covered entity educate our TPA/EMRs?
​

Covered entities should encourage their TPA and EMR providers to review the Beacon Support Center. Support designed specifically for TPAs including articles and training sessions are available in the Beacon Support Center.
​

Who can my covered entity speak to if there are questions?

Beacon Support is available via email, phone, or Beacon’s in-platform support messenger. To reach the team by email, please utilize [email protected]. To reach the team by phone Monday to Friday 9am-9pm ET, dial (878)-788-8907. For real-time responses from Beacon Support Monday to Friday 9am-9pm ET, utilize Beacon’s in-platform support messenger. This is available in the bottom right corner of the Beacon platform. For inquiries outside of Monday to Friday 9am-9pm ET, users can email the support inbox or create a ticket utilizing the in-platform messenger on Beacon.
​

How does Beacon handle protected health information (PHI)?
​

Data elements protected under HIPAA are de-identified through a HIPAA compliant hashing process known as SHA-3 hashing. An additional layer of security called a “salt” is applied prior to the hashing process and before any data is uploaded to Beacon. This process was granted an Expert Determination and meets the definition of a De-Identified Data Set under HIPAA. This means that Beacon does not collect or maintain identifiable PHI.
​

How does Beacon secure financial information provided as part of the registration process?
​
Beacon supports a multi-layer security protocol that is consistent with security practices commonplace with financial technology services in the marketplace today. Visit the Beacon Trust Center to learn more about the security protocols in place today.
​

How does Beacon ensure the security of submitted data?
​

BeBeacon supports physical, technical, and operational security protocols that are consistent with industry standard security best practices. This includes secure transfer of data from clients to Beacon (e.g., data-in-transit encryption), secure storage of that data once in Beacon (e.g., data-at-rest encryption), and secure network segmentation designed to ensure that data is protected in the inner most security ring of the Beacon environment. All of that is coupled with a least privilege access control model designed to limit access to data based on need alone. Visit The Beacon Trust Center to learn more about the security protocols in place today.
​

What type of data encryption does Beacon utilize?
​

Beacon encrypts all data throughout its lifecycle to ensure data integrity and confidentiality. All data is encrypted at rest with AES-256 encryption using Azure managed keys. Data in Beacon cloud products is encrypted in transit over public networks using TLS 1.2+.
​

How does Beacon manage access control?
​
​Before registering administrators are associated with a Beacon account, administrators must demonstrate authenticity by providing supporting documentation. This documentation undergoes a third-party review adhering to Know Your Business standards. Once approved, registering users establish a password and a Multi-Factor Authentication that meets Beacon’s stringent criteria.
​

How does Beacon manage data deletion and retention?
​
All data associated with Beacon will be retained indefinitely. Any data purge or deletion requests from covered entities will be discussed and only approved after written authorization from all impacted parties. Visit The Beacon Trust Center to learn more about Beacon’s data deletion and retention policies.

What technology requirements are necessary to successfully upload data to Beacon?
​

Users will need an internet connection and access to a supported browser to successfully upload data. Beacon is compatible with most internet browsers including Microsoft Edge, Google Chrome, Safari, and Firefox. However, Beacon strongly recommends using Google Chrome for the best user experience.
​

How does Beacon protect privacy?
​

Beacon enforces a robust privacy policy and data safeguard management program to ensure data safety. For more information, visit Beacon’s Privacy Policy.
​

What data is de-identified for claims submissions?​
​

Rx number, product serialization number and claim number are deidentified. This process was granted an Expert Determination and meets the definition of a De-Identified Data Set under HIPAA.

How does Beacon regulate data integrity before submission?
​

Data elements protected under HIPAA are de-identified through a HIPAA compliant hashing process known as SHA-3 hashing. An additional layer of security called a “salt” is applied prior to the hashing process and before any data is uploaded to Beacon. This occurs in local memory accessed by the user’s browser ensuring that no native PHI is submitted to Beacon.
​