patient, prescriber, electronic_prescription, order — and each one follows the same required fields as its individual endpoint. Patients and prescribers can be referenced instead of created, so a returning patient doesn’t need their profile re-sent.
The whole request is atomic. If any single entity fails validation, the entire request fails and nothing is created.
A new patient, new prescription, and order in one request
{ id, created } for each entity plus a summary reporting entities_created and entities_referenced — so you can tell at a glance whether the patient was newly created or matched to an existing record.
Referencing instead of creating
For a returning patient, drop the full profile and pass a reference:id or npi. See how Blend matches entities for the full matching rules.
Order merging still applies. If the patient already has an open order, the order in your composite request merges into it. Pass
force_new=true as a querystring argument to prevent that — see Order Merging.When to use it
Reach for composite when your system already holds everything at once — a checkout flow, an intake form, an EMR pushing a completed visit. Use the individual endpoints when entities arrive at different times, which is the more common pattern for businesses whose prescriptions come through Surescripts.Composite creation
POST /prescriptions/electronic_prescriptions/composite
Create an order
POST /orders
Create a patient
POST /patients
Create an electronic prescription
POST /prescriptions/electronic_prescriptions