RTPB Shows Patient-Specific Drug Costs Before a Prescription Is Sent

RTPB, or real-time prescription benefit, brings patient-specific prescription benefit and estimated cost information into the prescribing workflow before the prescription is sent. Instead of discovering a coverage restriction or unexpectedly high out-of-pocket cost only after the prescription reaches the pharmacy, the prescriber can see relevant benefit information while still making the treatment decision.

That distinction matters because a prescription can be clinically appropriate and electronically transmitted without answering a question that matters immediately to the patient: what this medication will likely cost under their prescription benefit, and whether another covered option is worth considering.

What Is RTPB?

RTPB stands for real-time prescription benefit. In practical terms, it is an electronic transaction that allows a prescriber-facing system to request patient-specific prescription benefit information and receive a response during the prescribing process.

The current ASTP/ONC real-time prescription benefit certification criterion describes the capability in concrete terms: a system using NCPDP RTPB Standard Version 13 can request and receive patient-specific prescription benefit information, estimated cost information, and alternative products, then display that information to the user in a human-readable format.

That wording is important. RTPB is not simply a database showing whether a drug generally appears on a formulary. Its value comes from applying benefit information to a particular patient and prescription at the time the prescriber is making the decision.

What RTPB Can Show at the Point of Prescribing

Depending on the benefit information available from the payer or pharmacy benefit manager and the implementation involved, the RTPB workflow can provide information such as:

• Patient-specific prescription benefit information
• Estimated patient out-of-pocket cost
• Drug coverage information
• Relevant coverage restrictions
• Alternative products when available
• Information that helps compare the originally selected drug with another option

ASTP/ONC specifically clarifies that the estimated cost information required in the RTPB request and response relates to patient out-of-pocket costs. Version 13 can also support additional overall-cost information when a plan makes those data available, but that information should not be confused with the core patient-cost estimate.

That is also why describing RTPB as displaying the patient's exact final price would be too strong. It provides patient-specific benefit and estimated cost information based on the data returned through the transaction. Actual amounts can still depend on the eventual claim, pharmacy, benefit status, and other circumstances.

Where RTPB Fits in the Prescription Workflow

RTPB makes more sense as one step in the prescribing process than as a standalone pharmacy product.

A simplified workflow looks like this:

The critical point is that RTPB occurs before the prescription is finalized and sent.

Without that benefit check, the prescriber may choose a clinically appropriate drug without knowing that the patient's benefit places it at a high cost-sharing level or applies a coverage restriction. The patient may not discover the problem until the prescription is already being processed.

With RTPB, that information becomes visible while the prescriber still has a chance to discuss appropriate options with the patient.

RTPB Is Not the Same as a Standard Formulary Check

This is one of the easiest distinctions to miss.

Traditional formulary and benefit information can tell prescribing systems which drugs a plan or benefit structure generally covers. That information is useful, but it is not necessarily specific to the individual patient's current benefit situation.

RTPB goes further by returning patient-specific information during the prescribing transaction.

CMS treats these as separate e-prescribing standards. Its current Part D standards page separately identifies the NCPDP Formulary and Benefit standard and the NCPDP Real-Time Prescription Benefit standard.

For a telehealth operator evaluating an e-prescribing system, asking whether it performs a formulary lookup is therefore not the same as asking whether it supports standardized real-time prescription benefit transactions.

RTPB Is Also Not E-Prescribing Itself

E-prescribing handles the electronic creation and transmission of prescription information between prescribers and pharmacies. It usually runs inside the prescriber's EMR system, and for controlled substances it carries additional requirements covered in our guide to EPCS compliance for telehealth.

RTPB answers a different question before that transmission occurs.

Think of the distinction this way:

E-prescribing asks: Where and how should this prescription be transmitted?

RTPB asks: What does this patient's benefit say about this drug, its estimated cost, and available alternatives before I send it?

The two capabilities work together, but one does not automatically imply the other.

An e-prescribing system can transmit prescriptions without necessarily exposing standardized real-time benefit information to the prescriber. That distinction is becoming increasingly important as federal standards bring RTPB more directly into certified prescribing technology.

Why CMS Made RTPB a Standard, Not Just a Nice-to-Have Feature

Real-time benefit tools have existed for years, but federal policy has increasingly moved from simply requiring access to a tool toward standardizing how the underlying information is exchanged.

CMS states that Part D plans have been required to support prescriber real-time benefit tools since 2021. The agency's more recent rulemaking goes further by standardizing those transactions.

Beginning January 1, 2027, CMS requires NCPDP Real-Time Prescription Benefit Standard Version 13 as the standard for prescriber real-time benefit tools supported by Medicare Part D sponsors.

That date differs from the earlier RTBT requirement. The federal policy did not suddenly create real-time benefit tools in 2027. Rather, 2027 is when the specified Version 13 RTPB standard becomes the required standard for those Part D sponsor-supported prescriber tools.

What the Standardization Solves

Without a common transaction standard, different payers, pharmacy benefit managers, e-prescribing systems, and health IT vendors can implement real-time benefit exchanges in different ways.

Standardization establishes a defined way to request and return the relevant information.

For operators, that matters because prescription cost transparency is not very useful if the e-prescribing interface can obtain patient-specific information from one benefit source but not reliably exchange the same type of information with another.

The NCPDP RTPB standard provides a common framework for that exchange rather than leaving every participant to invent its own transaction.

What This Means for Certified E-Prescribing Technology

The regulatory changes also affect health IT certification.

ASTP/ONC's HTI-4 framework created a specific certification criterion for real-time prescription benefit functionality based on NCPDP RTPB Standard Version 13. The criterion requires certified technology to support sending and receiving the relevant RTPB information and displaying patient-specific benefit, estimated cost, and alternative-product information to the user.

ASTP/ONC's HTI-4 fact sheet on e-prescribing and RTPB states that developers certified to its electronic prescribing criterion must also certify to the RTPB criterion by December 31, 2027, with RTPB entering the Base EHR definition on and after January 1, 2028.

That does not mean every prescriber in the United States must run an RTPB query before issuing every prescription.

It means the federal standards governing Part D sponsor-supported tools and certified health IT are increasingly aligning around a standardized RTPB capability.

For telehealth companies evaluating clinical infrastructure, the distinction matters. The question is no longer simply whether an e-prescribing product can display some insurance information. Operators should understand which standardized RTPB capabilities the system and its connected benefit partners actually support.

Why Prescription Cost Visibility Matters in Telehealth

A physical pharmacy counter is a poor place for the patient to discover that the medication they expected to receive is substantially more expensive than anticipated.

By that stage, the prescriber may no longer be part of the immediate interaction. The pharmacist may need to contact the practice, the patient may need to send a message or schedule another interaction, and the telehealth company's support team may need to get involved in resolving a problem that originated during prescribing.

RTPB moves some of that visibility upstream.

If the prescribing workflow can surface relevant benefit information before the prescription is sent, the clinician can consider cost and coverage alongside the clinical decision, rather than waiting for the pharmacy workflow to surface the problem later.

For virtual care, that can be particularly valuable because there is no shared physical environment where the provider, patient, and pharmacy can easily resolve the issue together.

The entire interaction may cross separate systems:

Telehealth encounter → Prescribing → Benefit check → Pharmacy → Fulfillment → Patient

Every additional handoff makes an unresolved cost or coverage issue harder to correct quickly.

RTPB Can Surface Alternatives, but It Does Not Make the Clinical Decision

One useful part of the RTPB standard is its ability to return alternative products.

That should not be interpreted as software automatically selecting a replacement medication.

The prescriber remains responsible for the clinical decision. A lower-cost alternative may not be appropriate for a particular patient, diagnosis, dosing requirement, treatment history, or other medical circumstance.

RTPB adds information to the decision rather than replacing professional judgment.

A useful workflow therefore looks like this:

Clinically appropriate medication identified → benefit and cost information reviewed → alternatives considered when relevant → clinician makes the prescribing decision.

The cost information can inform the conversation, but clinical appropriateness remains the controlling consideration.

What About Cash-Pay Telehealth Patients?

This is where the term real-time prescription benefit needs careful use.

RTPB is fundamentally a prescription benefit transaction. It is designed to obtain information associated with a patient's drug coverage from a payer or pharmacy benefit manager.

A completely cash-pay patient who isn't using a prescription benefit doesn't have the same insurance benefit for an RTPB transaction to query.

That means RTPB should not be described as a universal cash-price comparison engine.

However, the underlying operational problem still exists for cash-pay telehealth businesses: patients benefit from understanding what medication is likely to cost before reaching the final fulfillment step.

A cash-pay platform may provide that visibility through pharmacy pricing, product pricing, fulfillment integrations, or another source rather than through an insurance RTPB transaction.

RTPB and cash-pay price transparency therefore solve related patient-experience problems through different data sources.

For operators serving a combination of insured and cash-pay patients, this distinction should be explicit in the system architecture. Benefit-derived cost information and direct cash pricing should not be mixed as though they came from the same transaction.

The Cost Shown by RTPB Is Still an Estimate

The word real-time can create the impression that the response is equivalent to a finalized pharmacy claim.

It is not.

ASTP/ONC's certification documentation specifically uses the term estimated cost information. The amount shown to the prescriber represents benefit information available through the RTPB transaction at that moment.

Several downstream factors can still affect what ultimately occurs during pharmacy processing.

For telehealth product teams, this creates an important UX requirement: cost information should be useful without being presented as an unconditional guarantee when the underlying transaction only provides an estimate.

"Estimated patient cost under your current prescription benefit" is materially different from "this medication will cost exactly $X."

That distinction protects the usefulness of the benefit check without creating a second cost surprise when pharmacy adjudication produces a different result.

What Telehealth Operators Should Ask About RTPB

Because RTPB lives inside the prescribing workflow, a telehealth company cannot evaluate it in isolation from its EMR, e-prescribing vendor, benefit connectivity, and pharmacy operations.

Before assuming a platform supports real-time prescription benefit functionality, operators should ask several practical questions:

1.     Which RTPB standard and version does the system support? For current federal alignment, NCPDP RTPB Standard Version 13 is the important reference point.

2.     Which payers and PBMs can actually return responses? Technical support for a standard does not automatically mean every patient's benefit source is reachable through the implementation.

3.     What does the prescriber see? Operators should understand how estimated cost, coverage information, restrictions, and alternatives appear inside the prescribing interface.

4.     What happens if no RTPB information is returned? The prescribing workflow needs to continue safely when benefit information is unavailable.

5.     Can clinicians distinguish insurance estimates from cash pricing? This is particularly important for DTC telehealth businesses operating mixed payment models.

6.     Are alternative products presented as information rather than automated clinical substitutions? The system should support professional judgment rather than obscure it.

7.     Does RTPB connect cleanly with the downstream pharmacy workflow? Cost transparency is most useful when prescribing and fulfillment fit into a coherent patient journey.

The implementation question is therefore bigger than a checkbox labeled "RTPB supported."

The useful question is: Can a prescriber reliably obtain understandable patient-specific benefit information at the moment when it can still influence an appropriate prescribing decision?

How RTPB Connects With Pharmacy Fulfillment

RTPB happens before dispensing, while pharmacy fulfillment happens afterward.

That makes them adjacent, not interchangeable.

A connected medication journey may involve:

Clinical review → RTPB query → Prescription selection → E-prescribing → Pharmacy processing → Fulfillment → Delivery or pickup

If the RTPB response identifies a potential coverage issue or alternative before transmission, the provider can address it upstream.

Once the prescription reaches the pharmacy, the pharmacy still performs its own processing and dispensing responsibilities. RTPB does not eliminate those processes or guarantee successful fulfillment.

For telehealth businesses coordinating prescription-to-door workflows, this distinction matters because patient experience depends on both sides of the handoff.

Cost visibility can clarify the prescription decision. Reliable fulfillment then determines whether the prescribed treatment actually progresses through the pharmacy workflow.

How Bask Health Connects Prescribing and Fulfillment

Bask Health brings the clinical and operational steps around a prescription into one platform, instead of spreading them across separate vendors. Provider review, EMR and e-prescribing, pharmacy fulfillment, and payment processing run inside the same infrastructure, so the handoffs this article describes happen within one connected workflow.

That matters for cost visibility in two ways.

For brands that also serve insured patients, RTPB becomes an infrastructure question to raise early. Operators should confirm which benefit transactions their prescribing setup supports, how estimates are shown to clinicians, and how those estimates stay separate from cash pricing, following the evaluation questions above.

Bask supports synchronous and asynchronous care, customizable treatment pathways, and integrated doctor networks on every plan, and brands can launch in days rather than months. Operators comparing options can review what is included on Bask's plans.

FAQs

What Does RTPB Stand For?

RTPB stands for real-time prescription benefit.

It is a standardized electronic capability for requesting and receiving patient-specific prescription benefit information during the prescribing process, including estimated cost information and alternative products.

The current federal standard referenced by CMS and ASTP/ONC is NCPDP Real-Time Prescription Benefit Standard Version 13.

How Is RTPB Different From a Standard Drug Formulary Check?

A standard formulary check can indicate whether medications are generally covered under a plan or benefit structure.

RTPB returns patient-specific benefit information in real time for the prescription being considered, including estimated cost information and available alternatives.

The difference is therefore not merely that RTPB knows which drugs are on a formulary. It connects the benefit query to the specific patient and prescribing decision.

Does RTPB Apply Outside Medicare Part D?

Yes, RTPB technology can be used beyond Medicare Part D. The NCPDP standard is a technical transaction standard, not a technology that only works for Medicare beneficiaries.

However, the federal requirements discussed in this article apply specifically to the programs and certified technology covered by those rules. CMS's requirement that Part D sponsor-supported prescriber real-time benefit tools use NCPDP RTPB Version 13 beginning January 1, 2027, should not be generalized into a claim that every commercial payer or every prescription nationwide is subject to the same Part D rule.

Why Does Prescription Cost Transparency Matter for Telehealth?

Telehealth separates the prescribing encounter from the pharmacy counter physically and often technologically.

If a cost or coverage problem doesn't become visible until pharmacy processing, resolving it may require communication among the patient, pharmacy, prescriber, and telehealth support team.

Showing relevant benefit information during prescribing gives the clinician and patient an earlier opportunity to consider an appropriate covered or lower-cost option when one exists.

Conclusion

RTPB is a specific part of the e-prescribing workflow: it brings patient-specific prescription benefit, estimated cost, and alternative-product information to the prescriber before the prescription is sent.

Federal standards are making that capability more structured. CMS requires NCPDP RTPB Standard Version 13 for Part D sponsor-supported prescriber real-time benefit tools beginning January 1, 2027, while ASTP/ONC has incorporated RTPB into its health IT certification framework.

For telehealth operators, the practical evaluation is straightforward: determine whether the prescribing technology can surface accurate patient-specific benefit information, understand what happens when that information is unavailable, and keep insurance-based RTPB estimates distinct from cash-pay pricing.

References

1.     Centers for Medicare & Medicaid Services. (n.d.). E-prescribing standards and requirements. https://www.cms.gov/medicare/regulations-guidance/electronic-prescribing/adopted-standard-and-transactions

2.     HealthIT.gov. (n.d.). Real-time prescription benefit. https://healthit.gov/test-method/real-time-prescription-benefit

3.     HealthIT.gov. (2025). E-prescribing and real-time prescription benefit fact sheet. https://healthit.gov/wp-content/uploads/2025/10/eRX-RTPB-Fact-Sheet_HTI-4_OCT2025_508.pdf