Back-end validations are the set of checks 340B ESP performs after a 340B pharmacy or medical claims has been successfully ingested into the platform. These validations evaluate data consistency, program eligibility, and compliance with manufacturer policies before claims are approved.
What are Back-end Validations?
Back-end validations occur after a claim submission passes all front-end validations and is ingested into ESP. At this stage, ESP evaluates the claim against manufacturer's contract pharmacy policy and eligibility requirements that cannot be fully assessed before ingestion.
These validations help ensure that each claim is not only structurally correct, but also 340B eligible.
Back-end validations are designed to:
Verify submitted data values are valid and active (e.g., NPIs, NDCs, Provider IDs).
Ensure claims submitted meet manufacturer's contract pharmacy policy, including eligibility, timeliness, and non-duplication requirements.
Ensure alignment with expected quantity and measurement qualifications.
Types of Back-end Validations
ESP's back-end validations fall into six primary categories.
Invalid Service Provider ID
The Service Provider ID cannot be linked to an in-house pharmacy or contract pharmacy for the associated 340B ID. These validations assess whether submitted values are valid, active, and appropriate at the time of dispense or administration. Claims with invalid data values are flagged as ineligible.
Claim Expired
The date of the dispense falls outside the manufacturer's lookback period. 340B claim submissions must be made within defined lookback period requirements of a manufacturers contract pharmacy policy. This timeline does not reset to the date of the initial claim submission in instances where the initial claim submission is invalidated.
Invalid 340B ID
The 340B ID does not match a covered entity listed in HRSA OPAIS.
Duplicate
The claim was identified as duplicative of a previously submitted claim. For pharmacy claim submissions the combination of fields includes the Rx number, date of service, service provider ID, NDC. For medical claim submissions the combination of fields includes the claim number, date of service, NDC, and service provider ID.
Aberrant Quantity (Medical)
Total units of the drug is outside an acceptable range, listed in the 340B ESP Medical NDCs Units of Measure. Claims with dispensed or administered quantities that exceed expected thresholds may fail validation.
Invalid Unit of Measure (Medical)
HCPCS code is populated on claim, but is not associated with that NDC or the incorrect NCPDP UOM is provided. For a full list of accepted units of measure, see 340B ESP Medical NDCs Units of Measure.
Tip: For more information on front-end validations, the different types of front-end validations, and how they work, check out Front-end Validations.
Still have questions?
If you have questions or need additional help, our team is here for you — please feel free to reach out using any of the contact options below:
Chat: Available via in-app messenger
Email: [email protected]