General
What is Beacon?
Beacon is modernizing the 340B program by better aligning 340B price effectuation with Medicaid, Medicare and other government programs. To achieve this, Beacon enables 340B covered entity access to 340B pricing through a direct discount payment made upon receipt of eligible purchase and claims data.
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 credit 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 credit payments. Please note that policies may require the continued submission of claims data in 340B ESP for products not in scope for 340B credit payments depending on the manufacturer policy.
Will my covered entity continue to have access to 340B pricing through my wholesaler for products on Beacon?
Covered entities subject to a manufacturer’s policy will no longer have access to 340B pricing through their wholesalers for those products listed as in scope for 340B credit payments. Please visit the Resources page to view manufacturer policies. For products in scope for 340B credit payments, covered entities subject to a manufacturer’s policy will purchase these products at a commercial price (e.g. wholesale acquisition cost or WAC) and then receive a credit payment on the purchase once sufficient 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 utilizing a virtual inventory model?
340B pricing for all eligible 340B utilization for in-scope products will be effectuated through 340B credit payments. Covered entities will gain access to 340B credit 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 utilizing the credit model in the Beacon Resources page.
What 340B utilization does my entity need to submit to Beacon to receive 340B credit 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 active on Beacon?
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 credit 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.
Beacon Account Creation
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 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?
The same individual that registered a covered entity account on 340B ESP is not required to register the account with Beacon. The individual registering a covered entity account on Beacon 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, and Articles of Incorporation 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 credit 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 credit 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. Covered entities should visit the Beacon Resources page to understand how policies may impact the level in which credit payments are made.
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. Both the certified letter and the ACH information must be successfully verified as associated with the 340B covered entity prior to the payment of 340B credits.
Data Submissions
General
What data does my covered entity need to submit to Beacon?
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.
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 credit payments. Those products listed as in scope for 340B credit payments are managed through Beacon and will be considered invalid if submitted to 340B ESP. However, products not in scope for 340B credit 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 cannot utilize their 340B ESP SDKs to support their Beacon submissions. To submit purchase data and 340B claims data, covered entities should navigate to the appropriate module to upload and submit their purchase and claims data. 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 are used to validate the eligibility of the dispense or administration for a 340B credit payment. Claims data are also used to determine the 340B discount amount after accounting for prohibited duplication with MFP rebates. 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 October 15th, 2024, 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. Credit 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 credit 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.
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.
Purchase Data
What is purchase data?
Purchase data is created when a 340B covered entity purchases products at a commercial price such as WAC. Purchase data is typically available to a covered entity directly through its wholesaler or from its TPA.
How does a pharmaceutical manufacturer use the purchase data submitted to Beacon?
Purchase data submitted by a covered entity is used to validate the eligibility of the purchase for a 340B credit payment. Eligible purchases must be made by the covered entity at a commercial price, purchased after the policy effective date and shipped to a location that is actively registered on the HRSA database as a parent or child site, the shipping address of a parent or child site, or a contract pharmacy eligible under a given manufacturer’s 340B contract pharmacy policy.
How is purchase data validated?
Purchase data is validated using sales and discount data maintained by pharmaceutical manufacturers. For more information on purchase data, please watch Beacon’s Purchase webinar available in the Beacon Support Center.
How does my covered entity get access to this purchase data?
Covered entities should work with their wholesalers or TPAs to gain access to their purchase data.
How does my covered entity submit purchase data to Beacon?
Covered entities can submit purchase data after completing their Beacon enrollment and establishing Beacon credentials. The steps to complete purchase data submissions will feel familiar to submission steps present in 340B ESP. To access available data templates as well as educational tutorials to support the submission process, visit the Data Submission collection in the Beacon Support Center.
Does my covered entity have to do anything after submitting purchase data?
Covered entities should view the status of their submitted purchase data to ensure it was validated and accepted.
My covered entity’s purchase data is made up of packages - how does Beacon ensure that the quantities in my claim submissions accurately align to each package?
Beacon publishes a unit conversion table for each NDC incorporated into the credit model. Covered entities are expected to submit both pharmacy claims data and medical claims data with the appropriate unit based on the claim type and NDC. More information on unit conversions is available on the Beacon Resources page.
What fields are collected as part of purchase data submissions?
Field | Description | Type |
340B ID* | The 340B ID of the covered entity that placed the purchase. This is usually the 340B ID of the covered entity under which you registered. | Alpha numeric ID that may contain dashes-- starts with 2 or 3 letters |
Account Number* | Account number assigned by the wholesaler and used for the purchase. | Alpha numeric |
Invoice Date* | The date on which the invoice for the purchase was issued by the wholesaler to the 340B covered entity. | Standard Date Format |
Invoice Number* | The invoice number assigned by the wholesaler for the purchase made by the 340B covered entity. | Alpha numeric |
NDC-11* | The 11-digit National Drug Code which indicates the manufacturer, product, and the commercial package size. | Numeric, 11 digits, may contain up to 4 leading zeros |
Quantity* | The number of packages of the NDC-11 purchased by the 340B covered entity. | Numeric |
Ship-To Pharmacy (NPI)* | The unique public NPI for the ship to pharmacy. | Numeric |
Wholesaler Name* | Name of the wholesaler through which the covered entity made the purchase. | Alpha numeric |
*Indicates a required field
Claims Data
Pharmacy Claims Data
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?
Field | Description | Type |
340B ID* | The 340B ID of the covered entity where the prescription originated. This is usually the 340B ID of the covered entity under which you registered. | Alpha numeric ID that may contain dashes-- starts with 2 or 3 letters |
Date Prescribed* | Date the prescriber wrote the prescription. | Standard Date Formats |
Date of Service (DOS)* | Date on which the patient filled their prescription. | Standard Date Formats |
Fill Number* | Indicates the number of times a prescription has been refilled. A value of 2 would mean the current prescription claim is for the second refill of the prescription. | Numeric, values 0-99 |
NDC-11* | The 11-digit National Drug Code which indicates the manufacturer, product, and the commercial package size. | Numeric, 11 digits, may contain up to 4 leading zeros |
Prescriber ID* | A unique, public ID for the prescribing physician. Accepted IDs include the NPI and DEA ID. | Numeric, 10 digits, never starts with a leading zero |
Quantity* | The number of units in the prescription. | Numeric, can contain decimals |
Bin Number* | Prescription Drug Bank Identification Number. Enables pharmacies to electronically transmit data to the appropriate PBM for processing and reimbursement. | Alpha numeric, may contain leading zeros |
Rx Number* | The native (unmodified) prescription number for the prescription as generated by the pharmacy. | Numeric, may contain leading zeros |
PCN Number* | Processor Control Number. Identifier used to determine which processor will handle a prescription drug claim. | Alpha numeric, may contain leading zeros |
Service Provider ID* | A unique, public ID for the dispensing pharmacy. Accepted IDs include the NPI, DEA, NCPDP, and Medicaid ID. | Numeric, 10 digits, never starts with a leading zero |
*Indicates a required field
Medical Claims Data
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?
Field | Description | Type |
340B ID* | The HRSA assigned parent 340B ID of the entity that purchased the administered medication at the 340B price. | Alpha-Numeric ID that may contain dashes-- starts with 2 or 3 letters |
Claim Number* | The claim number as assigned by the healthcare provider. | Alpha Numeric (A/N) |
Date of Service (DOS)* | Date on which the medication was administered to the patient. | Standard Date Formats |
HCPCS Code | The five digit HCPCS code for separately payable medications. This value may not exist for medications that are reimbursed as part of procedure (e.g. a blood thinner used as part of an outpatient procedure). | Alpha Numeric (A/N) |
HCPCS Code Modifier | Modifier code associated with a separately payable medication with its own 5 digit HCPCS code. | Alpha Numeric (A/N) |
Health Plan Name* | Name of the patient's primary health insurance plan. Examples include Medicare Part B, MediCal, Aetna POS, etc. | Alpha Numeric (A/N) |
Health Plan ID* | The identifier code of the patient's primary health insurance plan as assigned by the health insurer. | Alpha Numeric (A/N) |
Health Plan ID Qualifier | The qualifier for the patient's primary health insurance plan ID. | Alpha Numeric (A/N) |
Product Service ID (NDC-11)* | The NDC-11 of the medication administered to the patient. | Numeric, 11 digits, may contain up to 4 leading zeros |
Physician / Prescriber ID* | The NPI of the physician that administered the medication to the patient. | Numeric, 10 digits, never starts with a leading zero |
Quantity* | The quantity - as measured in billable units - of medication administered to the patient. | Numeric, can contain decimals |
Service Provider ID* | The NPI of the healthcare entity where the patient received the medication administration. For example, this could be the NPI of a hospital outpatient surgery center or the NPI of an outpatient infusion center. | Numeric, 10 digits, never starts with a leading zero |
340B Credits
How is the 340B credit amount calculated for an individual purchase?
340B credit 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 December 30th, 2024 and the product is dispensed on January 4th, 2025, the WAC and 340B prices will be based on the December 30th purchase date. 340B credit amounts are reduced in instances where the claim is duplicative of an MFP rebate that has already been paid. In instances where an unadjusted 340B credit amount is paid and duplication with an MFP rebate is determined post-payment, a future 340B credit payment may be adjusted to account for the statutorily prohibited duplication.
How long does it take for a 340B credit payment to be processed and paid?
340B credits are typically processed and paid within 7 - 10 days of a covered entity’s submission of sufficient 340B claims. For products that have an equivalent package size and dispensed unit size (e.g. an entire package is dispensed for a single claim), 340B credits will likely be paid prior to payment being due to the wholesaler on the initial purchase so long as the covered entity submits claims data on a timely basis.
Are 340B credits paid on individual dispenses of a product or for purchases of the product?
340B credits are calculated and paid at the NDC-11 level consistent with how 340B prices are determined today. In instances where dispensed units are less than the total units in a package, Beacon will accumulate units across multiple dispenses until there is an equal or greater number of units from the 340B claim submissions. For example, if a single package has three units and a typical dispense is for a single unit, covered entities must submit three claims with one unit per claim before a 340B credit amount is calculated and paid.
Can my covered entity reconcile 340B credit payments back to both purchase submissions and claims submissions?
Covered entities will be able to reconcile 340B credit payments back to both submitted purchase data and submitted claims data. This information will be available in Beacon to review as well as accessible through a downloadable data report.
Is my covered entity able to track the accumulation of credits on my submitted purchase?
Covered entities can track the status of payment accumulation across their submitted purchases from the Purchases module. Within the Purchases module, covered entities can view if additional claim submissions are pending and what 340B credit payments have already been paid.
How does Beacon determine duplication across Medicare and Medicaid?
Beacon utilizes data elements within the submitted claims to identify potential duplication with Maximum Fair Price (“MFP”) eligible claims. The BIN/PCN will inform if an MFP rebate is due on the claim. The credit amount due on that claim will reflect any MFP rebates that are due. Beacon then utilizes subsequent MFP rebate data from the MTF to validate that the appropriate 340B credit was paid to the covered entity.
Beacon compares Medicaid rebate data to submitted 340B claims data to identify potential duplication with Medicaid.
Support
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 EMRs to review the Beacon Support Center. Support designed specifically for TPAs including articles and upcoming training sessions will be made 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.
Security
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?
Beacon 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.
HIPAA and Privacy
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.
Questions?
Reach out to the Beacon Support team.