> For the complete documentation index, see [llms.txt](https://docs.mdintegrations.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mdintegrations.com/partner/key-concepts/offerings.md).

# Offerings

Configure the treatments available for physician review and fulfillment.

An **Offering** is a predefined treatment available for physician review. It defines the medication, dosage, refill schedule, and communication rules that govern a specific treatment. Offerings matter because they let MDI's team build consistent, replicable treatment plans — by standardizing most of what a physician needs to review up front, an Offering simplifies the approval process and, ultimately, makes for a faster and more predictable prescribing experience for everyone involved.

## Types of Offerings

MDI supports several categories of Offering, covering pharmacy fulfillment, e-prescribing, and non-prescription workflows. Which type you use depends mainly on how you want prescriptions transmitted and fulfilled.

### Direct to Pharmacy (DTP) offerings

Direct to Pharmacy offerings use MDI's own pharmacy integrations for both prescription transmission and order fulfillment, which makes this the simplest way to send medications and manage orders entirely within MDI.

<table><thead><tr><th width="270.3671875">Type</th><th>Description</th></tr></thead><tbody><tr><td><strong>Medication</strong></td><td>A medication from a pharmacy catalog.</td></tr><tr><td><strong>Compounds</strong></td><td>A free-text compound sent to selected pharmacies.</td></tr></tbody></table>

Before you can create a DTP Medication offering, a pharmacy catalog needs to be set up. Some pharmacies maintain a global catalog that works across all partners out of the box, while others require you to set up your own pharmacy credentials first, at which point their catalog becomes available to you.

### DoseSpot offerings

DoseSpot offerings work differently: they transmit electronically through the Surescripts network, and MDI handles prescription transmission only. From there, your team manages ordering and fulfillment directly with your pharmacy of choice, rather than routing that work through MDI.

<table><thead><tr><th width="270.11541748046875">Type</th><th>Description</th></tr></thead><tbody><tr><td><strong>Medication</strong></td><td>Standard over-the-counter medications.</td></tr><tr><td><strong>Compound</strong></td><td>A free-text prescription for use with compounding pharmacies.</td></tr><tr><td><strong>Ingredient-Based Compound</strong></td><td>A compound built from a predefined set of ingredients.</td></tr><tr><td><strong>Supplies</strong></td><td>Medical supplies, including devices, syringes, patches, and more.</td></tr></tbody></table>

### Other offerings

Beyond pharmacy-routed treatments, a few other offering types round out what a comprehensive treatment plan can include: cases where a lab exam needs to be ordered, a free-text medical letter or prescription needs to be written, or a non-medication treatment needs to be prescribed.

<table><thead><tr><th width="269.6553955078125">Type</th><th>Description</th></tr></thead><tbody><tr><td><strong>Non-Rx</strong></td><td>Anything that does not require a prescription, such as exercise plans or diets.</td></tr><tr><td><strong>Services</strong></td><td>A free-text prescription that produces a PDF. It is not transmitted to a pharmacy. Use this for workflows that do not fit the other types.</td></tr><tr><td><strong>Lab Orders</strong></td><td>A lab requisition sent directly to an integrated laboratory.</td></tr></tbody></table>

## What an Offering contains

Regardless of type, each Offering carries the same core configuration:

* **Offering ID** — A platform-wide identifier used to reference the Offering in Vouchers, Questionnaires, Encounters, Automations, and other workflows.
* **Medication details** — The medication name, formulation, refills, dosage, and related prescription details.
* **Pharmacy information** — The pharmacy where the Offering is routed, including routing notes.
* **Communication** — The message sent to the patient when a doctor approves the treatment.
* **Associations** — Links to tags, FAQs, upsell opportunities, available states, taxonomies, and other related configuration.
* **Store listing** — How the Offering appears on your storefront, including its URL, name, and image. Store listings can be used for upsell opportunities.

Because an Offering represents one specific treatment configuration, you'll want to create a separate Offering for each distinct variant rather than trying to make a single Offering cover several at once.

For example, a one-month supply and a three-month supply of the same medication should be two separate Offerings, since dosage, refill cadence, and pricing can all differ between them. Give each one a clear, distinguishing name so it's easy to identify during review and fulfillment later on.

{% hint style="warning" %}
MDI reviews every new or edited Offering for clinical and regulatory compliance before it becomes available. Plan for review time when managing offerings, as changes do not publish immediately.
{% endhint %}

### Clinical eligibility and the States field

The **States** association is the only built-in clinical eligibility restriction at the Offering level — it controls which US states a patient must be in to request that Offering. Leave it empty and the Offering becomes available in every state by default.

Any other kind of clinical gating — age, BMI, pregnancy, prior conditions, or similar criteria — isn't something you configure on the Offering itself. Instead, enforce it through **Questionnaire Rules**, using conditions on the intake form connected to the Offering.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.mdintegrations.com/partner/key-concepts/offerings.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
