> 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/assignment-algorithm.md).

# Assignment Algorithm

When an Encounter needs a clinician, MDI decides who gets it. This is internal routing logic — unlike Offerings or Questionnaires, partners don't configure it directly — but understanding how it works explains what you'll observe in practice: which doctor gets assigned, why a returning patient often sees the same one again, and when and why an Encounter moves to a different clinician mid-flow.

## Initial Assignment

When an Encounter is created, MDI runs a routing pass to pick a clinician. A few rules govern that pass, in order:

**Continuity of care first.** If the patient has worked with a clinician before, MDI prefers routing the new Encounter back to that same clinician, provided they're available. This is why repeat patients frequently see a familiar doctor rather than a random assignment.

**Eligibility filters.** Before anyone is considered for routing, they must pass a set of hard filters:

* Hold an active license in the patient's state
* Be marked active and accepting assignments
* Hold EPCS clearance, if the Encounter involves a controlled-substance prescription

**Tiered priority pool.** Clinicians are grouped into priority tiers per partner and per offering. Routing draws from the highest tier that has an eligible, available clinician, falling back to the next tier only when the higher one is exhausted:

| Tier          | Description                                                        |
| ------------- | ------------------------------------------------------------------ |
| Exclusive     | Highest routing priority for this partner/offering                 |
| Preferred     | Routed to ahead of standard pool when available                    |
| Normal        | Standard routing pool                                              |
| Non-Preferred | Lowest priority; used when higher tiers have no eligible clinician |

**Caseload balancing.** Within a tier, MDI doesn't assign round-robin. It balances new assignments against each clinician's current caseload, so work is distributed rather than piled onto whoever happens to be next in line.

## Reassignment Triggers

Once assigned, an Encounter isn't locked to that clinician forever. A few conditions can trigger reassignment:

**Active-work grace period (30 minutes).** A physician can have up to two Encounters actively in progress at once. Each gets a 30-minute grace period during which it's protected from reassignment — this keeps active work from being pulled away too soon. This protection shipped in March 2025.

**Out-of-office threshold (50 hours).** If a clinician goes inactive, their open Encounters eventually become eligible for reassignment to someone else. As of June 2025, that threshold is 50 hours of inactivity — reduced from the previous 72-hour window.

**Waiting/Support release.** An Encounter that's parked in a Waiting or Support status — for example, waiting on a patient reply, or held while support resolves a blocker — loops back through this same routing logic when it's released back to the queue. That release re-triggers the full assignment process described above, including the continuity-of-care preference and tiered pool.

This connects to the Encounter status lifecycle documented elsewhere: Created to Assigned is the first routing event, and Assigned to Support/Waiting and back to Assigned re-triggers it.


---

# 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/assignment-algorithm.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.