Provider networks

When a patient is in a state none of your prescribers is licensed in, a connected clinician network can see them — and the prescription that comes back enters your order rail already approved. Not queued for your provider. Already approved, by the clinician who actually saw the patient.

That last sentence is the load-bearing one on this page, and the rest of it explains why the alternative would be worse than a bottleneck.

Gated by provider_network_consults (dark by default). BYO only: you contract directly with the network's professional corporation, and neolife takes $0 of the consult.

What neolife is and isn't in this relationship#

Is: the connection, the request, the state-licensure check, the status trail, and the join from a returned prescription into the fulfillment rail.

Isn't: a party to your clinical agreement, the entity that selects a clinician, and the recipient of any part of the consult fee. neolife relays a request between two parties who contracted with each other directly. It does not practice medicine and it does not pick your doctor.

That distinction isn't decoration. A platform that both selects the clinician and earns on the consult is steering clinical work for money, which is exactly the shape AKS and EKRA exist to catch.

State-licensure routing#

A consult request carries the patient's state. Routing is a filter, not a preference: a clinician who is not licensed in that state is not eligible, full stop, and no configuration reorders that.

Where the request lands is decided by your physician source policy — an ordered list, where omission is denial.

Source	Who signs
order_override	A specific provider you named on this order
clinic_prescriber	Your own credentialed prescriber, licensed in the patient's state
provider_network	A clinician from a network you connected through neolife
vendor_network	The vendor's own assigned network physician

The chain resolves top-down and stops at the first source that is both enabled for your workspace and available for this patient. A source you never added to the policy can never sign — omission is denial, so a clinic that never enables vendor_network cannot have an order signed by one, even accidentally.

If nothing resolves, the order is blocked. Not signed by a fallback, not held in a state that looks approved, not routed to whoever is closest. Blocked, with the reason visible. The failure mode of a signature chain must be "no signature", never "some signature".

Rule: a clinic's own credentialed prescriber outranks any network by default. The network is what you reach for when your own roster can't cover the patient — not a cheaper substitute for credentialing your own providers.

The consult lifecycle#

Status	Meaning
routing	Requested. Finding a clinician licensed in the patient's state
assigned	A clinician has accepted the consult
in_progress	The visit is underway (sync or async, per the network's model)
completed_rx_issued	The clinician saw the patient and issued a prescription
completed_no_rx	The clinician saw the patient and did not prescribe
declined	The network declined the request
patient_no_show	The patient didn't attend

completed_no_rx is a success, and it renders as a neutral outcome rather than a failure. A network that always prescribes is not a clinical service, it is an order-taking service wearing a clinician's name. A consult whose honest answer is "not appropriate for this patient" has done its job, and any UI that colours it red is teaching operators to want the other answer.

patient_no_show and declined are operational states that need a human — they're exceptions, and they surface as exceptions.

The returned prescription#

A completed_rx_issued consult produces a prescription. Here is exactly what happens to it:

1. It enters the order rail already approved, carrying the identity of the network clinician who signed it and the consult it came from.
2. It routes to a pharmacy under your normal routing policy — the same rules, the same failover, the same meter.
3. It appears in your console as an order in flight. It does not appear in your approvals queue.

Your provider never re-approves it, and there is no setting that makes them.

A second approval would be a second clinical act, performed by a clinician who never saw this patient, on the basis of a chart they weren't part of building. That isn't extra safety — it is a licensed provider putting their signature on someone else's clinical judgement, which is a worse position than not signing at all. The consult is the clinical gate. Approving on top of it would dilute the meaning of approval everywhere else on the rail.

What you do keep is visibility: the order carries the consult id, the clinician, and the network, and every one of those is on the order timeline. You can see who decided and when. You just can't decide again.

What the request carries#

A consult request carries the clinical context the clinician needs and the patient's state, and nothing about your commercial arrangement — the network does not see your pricing, your other vendors, or your volume. The consult record on the neolife side carries ids and status; the clinical content lives with the parties who are licensed to hold it, exactly like every other callback on the platform.

Roles: consults.view to see requests and outcomes, consults.request to make one. consults.request is deliberately not in the clinical permission set — requesting that a licensed clinician see a patient is an operational act, and it is the network's clinician who performs the licensed one. Your patients see their own consults through patient.consults.view.

Next steps#

• Billing & compliance — why neolife takes $0 of a consult.
• Orders & fulfillment — where the returned prescription goes.
• Labs — the other place the physician source chain decides who signs.
• Connection health — what a degraded network connection does to an in-flight consult.