> 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/pharmacy-fulfillment/prescription-lifecycle.md). # Prescription Lifecycle A **Prescription** is a distinct object from the Encounter (Case) that produces it, and it runs on its own status machine. An Encounter can result in a Prescription once a clinician reviews the case and approves it, but the two statuses aren't the same thing — they only move in lockstep at a few specific points, and diverge the rest of the time. This page documents the Prescription status machine in isolation; for the Encounter/Case lifecycle itself, see the Patients & Encounters documentation. ## What a Prescription Is A Prescription comes into existence at the moment a clinician approves an Encounter that requires one. Not every Encounter produces one, though — Offerings that don't need a prescription, certain services being the clearest example, let the Encounter proceed straight to `completed` without this object ever being created. Once a Prescription does exist, it tracks its own path toward a pharmacy independently of whatever the Encounter goes on to do next. ## Status Machine | Status | Meaning | | ------------ | -------------------------------------------------------------------------------------------------- | | `pending` | Initial state in the documented status enum. | | `approved` | The clinician has written the prescription, but it hasn't been sent to a pharmacy integration yet. | | `processing` | The prescription has been sent to a pharmacy integration and is awaiting confirmation. | | `completed` | The pharmacy confirmed the prescription. | | `error` | Something went wrong during transmission or fulfillment. | | `cancelled` | The prescription was removed from the flow. | > **Note:** The source material lists `pending` as the first status, but its own walkthrough of the flow starts at "the clinician approves the case, which creates the prescription" and never explains what happens at, or before, `pending`, or exactly what triggers `pending → approved`. Treat `pending` as a real but under-documented state rather than assuming it maps to a specific UI action. Likewise, nothing in the source specifies what triggers `cancelled` for a prescription specifically (as opposed to a case) — confirm with your account team if you're relying on that transition. ## How the Flow Works 1. A clinician approves the Encounter, and that approval is what creates the Prescription. 2. From there, where the Prescription goes next depends on how that Offering is configured for fulfillment — it might route through the standard e-prescribing network (DoseSpot), or through another supported pharmacy integration, including Direct-to-Pharmacy arrangements. 3. The pharmacy integration then transmits the prescription, which moves it from `approved` to `processing`. 4. Confirmation then arrives asynchronously, moving the Prescription to `completed` — or, if transmission or fulfillment fails, to `error`, with the Encounter reverting to `approved` so a clinician can see it needs attention and act on it again. And as noted above, if the Offering doesn't require a prescription at all, the Encounter can reach `completed` without any of this flow running. ## Error Handling and Retries When a Prescription fails at the pharmacy integration stage, the system doesn't just let it stall silently — a few things happen automatically: * It's marked `error` and tagged with a reason. * The associated Encounter reverts to `approved`, surfacing the failure to the clinician so they can review and act again — this is the designed recovery path, not a bug. * Order status updates coming from pharmacy fulfillment only ever move **forward**, never backward — so if you're tracking order status on your own end, a late or out-of-order update can never overwrite a more advanced status you've already recorded. > **Note:** Retry counts and backoff timing are handled internally and aren't partner-configurable or exposed through the API. You get the outcome — the `error` tag and status change — not visibility into the retry mechanics. ## DoseSpot Interaction DoseSpot is MD Integrations' e-prescribing partner, and it's used for standard-network medications, compounds, and supplies — distinct from a Direct-to-Pharmacy relationship, where MDI instead manages the order workflow directly with your own pharmacy. During a DoseSpot transmission, what's visible to your integration is simply the Prescription's own status moving through `approved → processing → completed` — or reverting to `approved` with an `error` tag if something goes wrong — along with a webhook fired on each of those transitions. For controlled substances specifically, DoseSpot requires electronic prescribing of controlled substances (EPCS), an additional identity and PIN verification step the clinician has to complete before the prescription can be sent. This step doesn't introduce a partner-visible status of its own — it simply happens before the transition into `processing`, invisibly to your integration. --- # 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/pharmacy-fulfillment/prescription-lifecycle.md?ask=&goal= ``` `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.