Skip to main content
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 <DrugDescription> field
  7. Parsing the <Note> field
For Surescripts prescriptions specifically, Blend parses <ProductCode>, <DrugDescription>, and <Note> 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:
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.

Matching reference

The canonical field-level rules

Create an order

Accepts electronic_prescription_ids

Get prescriptions

Filter by patient, product, prescriber

Get orders

has_unmatched_prescriptions=true