> ## Documentation Index
> Fetch the complete documentation index at: https://docs.byblend.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How does Blend match a prescription to a patient, product, and order?
> Blend matches patients on external_id or Blend id when sent via API, and on name plus date of birth from Surescripts. Products match on product_code, then sku, then name, then NDC. Orders inherit the patient match.
Blend resolves three links for every inbound prescription: which patient it belongs to, which of your products it refers to, and which order it should fill. Each uses a different set of signals, and each degrades gracefully — an unmatched prescription waits rather than failing.
## Prescription to patient
* **Sent via API** — Blend looks for the patient's `id` (Blend UUID) or `external_id` (your identifier, stored on the Blend patient profile). This is definitive.
* **Sent via Surescripts** — Blend matches on patient name (or preferred name) and date of birth, or on patient contact information and date of birth.
Only **definitive** matches are assigned automatically. Blend deliberately does not auto-assign a "possible" match — an ambiguous prescription waits for a human rather than attaching to the wrong chart.
## Prescription to prescriber
Prescribers are matched on **NPI** or **DEA number**.
## Prescription to product
Blend works from highest confidence to lowest:
1. `product_code` — your prescription-product code
2. `sku` — your inventory identifier
3. Product name
4. NDC, including NDCs related through RxNorm
5. Drug name, with common abbreviations normalized before comparison
6. Parsing the SCRIPT `` field
7. Parsing the `` field
For Surescripts prescriptions specifically, Blend parses ``, ``, and `` looking for your products' `sku`, `product_code`, `id`, or `name`.
## Prescription to order
Because an order always carries a patient, Blend uses the patient match to tie orders and prescriptions together. Among the prescriptions eligible for an order line, a candidate must be:
* not cancelled,
* have fills remaining, and
* not expired.
Where several candidates qualify, **the newest prescription wins**, ordered by `written_at` and then by creation time.
**A newer prescription can supersede an older one on an open order.** When a fresh prescription arrives for the same patient and product, Blend re-links the order line to it — but only while the order is in `received`, `exception`, or `paused`. Once an order is picked or verified, its prescription links are fixed.
## Helping the match along
When you already know which prescriptions belong to an order, name them explicitly at creation time:
```json theme={null}
{
"patient": { "external_id": "clinic-pt-4471" },
"electronic_prescription_ids": [
"BFCB96C9-F866-405E-A1B3-3ED031DFB423"
],
"products": {
"prescription": [{ "product_code": "HC-RAPA31", "quantity": 1 }]
}
}
```
`electronic_prescription_ids` is an optional convenience field that removes any ambiguity about which prescription an order should draw from.
Blend staff can also map a prescription by hand when an inbound message needs human judgment — a misspelled name from the prescriber, or a transfer that arrived with partial data. If a prescription you sent hasn't matched, Blend will typically find and address it.
The canonical field-level rules
Accepts `electronic_prescription_ids`
Filter by patient, product, prescriber
`has_unmatched_prescriptions=true`