Create Phlebotomy Order
Atomic create: validate refs + the client-rendered PDF → upload → insert Document + PatientPhlebotomyOrder.
The order PDF is stamped in the browser onto OneBlood’s published Form-96
(the single source of truth shared with the preview) and sent as the
pdf part; the structured fields arrive as a JSON payload part. This
endpoint validates the patient / ordering provider / recipient (if
present) references and that the upload is a real PDF, then persists the
passed-in bytes — it does not re-derive the document. provider
(CurrentProvider) gates the caller to an authenticated provider; the
ordering provider is chosen on the form and validated in the service, so
it need not match the caller.
Headers
The tenant you are making this request on behalf of
Your api key
Response
Successful Response
Draw frequency on the OneBlood Form-96 phlebotomy order.
Rendered as checkboxes on the form but functionally exclusive — a single
selection, not independent booleans. OTHER carries free text in
PatientPhlebotomyOrder.other_frequency.
ONE_TIME, WEEKLY, EVERY_2_WEEKS, EVERY_4_WEEKS, EVERY_8_WEEKS, OTHER ^(?!^[-+.]*$)[+-]?0*\d*\.?\d*$Draw amount on the OneBlood Form-96 phlebotomy order.
Rendered as checkboxes on the form but functionally exclusive — a single
selection, not independent booleans. OTHER carries a free-text mL
amount in PatientPhlebotomyOrder.other_amount_ml.
ONE_UNIT, OTHER A channel a phlebotomy order's document went out on.
Derived, never stamped — each member corresponds to a link that already exists once the document leaves the building:
FAX: afax_attachmentrow references the documentEMAIL: anemail_attachmentrow references the documentPORTAL:document.shared_with_patientis set (a portal share, or the SMS that texts the patient a portal link)
An order can therefore be on several channels at once, which is why the response carries a list rather than one "how was it sent" value.
EMAIL, FAX, PORTAL 
