Provider networks
When the patient is in a state your prescribers are not licensed in.
A clinician network you contracted with can see that patient, and the prescription that comes back enters your order rail already approved — by the clinician who actually saw them, not queued for a second signature from one of yours who did not. This is the newest of the three integration families, it is revealed per workspace rather than on by default, and you contract with the network directly.
What connects
A request, a licensure filter, and a join back into the rail.
neolife supplies the connection, the consult request, the state-licensure check, the status trail, and the join from a returned prescription into fulfilment. It is not a party to your clinical agreement, it does not select the clinician, and it does not receive any part of the consult fee.
Licensure is a filter
Not a preference, and not reorderable.
A consult request carries the patient's state, and a clinician who is not licensed in that state is not eligible — full stop, with no configuration that reorders it. Everything else about routing is yours to set; this one is not, because the alternative is a licensure question resolved by a sort order.
A four-source signature chain
Omission is denial, and nothing resolving blocks the order.
Who signs is decided by an ordered per-workspace policy: a provider you named on the order, then your own credentialed prescriber licensed in the patient's state, then a clinician from a network you connected, then the vendor's own assigned network physician. It 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 can never sign. And if nothing resolves, the order is blocked with the reason visible — not signed by a fallback, not parked in a state that looks approved. The failure mode of a signature chain has to be no signature, never some signature.
Already approved
The returned prescription does not enter your approvals queue.
A completed consult that issued a prescription puts it on the rail already approved, carrying the identity of the network clinician who signed it and the consult it came from, and it routes to a pharmacy under your normal routing policy. Your provider never re-approves it and there is no setting that makes them: a second approval would be a second clinical act by a clinician who never saw this patient, on a chart they were not part of building. That is not extra safety. The consult is the clinical gate, and approving on top of it would dilute what approval means everywhere else on the rail.
No prescription is a success
A consult that declines to prescribe has done its job.
A completed consult with no prescription renders as a neutral outcome, not a failure. A network that always prescribes is not a clinical service — it is an order-taking service wearing a clinician's name, and any interface that colours the honest answer red is teaching operators to want the other one. A declined request or a patient who did not attend are operational states, and those surface as exceptions because they need a human.
Where this stands
The newest surface of the three, and we would rather say so.
The connection object, the consult lifecycle, the licensure filter, the signature chain, and the join from a returned prescription into the order rail are built and documented. What is deliberately not on this page is a roster of named networks: this family is newer than the EMR and lab surfaces, it is revealed per workspace rather than switched on by default, and no clinical network is going to appear here as connected before there is an executed agreement and a per-vendor BAA on file behind it.
That is the same rule that governs every connection on the platform. A connection whose BAA is not on file stays pending even when its credentials work perfectly, because PHI does not move to a vendor on the strength of a working API key. If you have a network already and want to know what connecting it involves, the fastest answer is a conversation rather than a page.
How the money works
Bring your own network contract. We take $0 of the consult.
You contract directly with the network's professional corporation, on your own clinical terms, and the network bills you. neolife is not a party to that agreement and earns nothing on it — not a share of the consult fee, not a per-request fee, and nothing from the network for being connectable. Your flat platform fee does not move with how many consults you request.
That separation is structural rather than decorative. A platform that both selects the clinician and earns on the consult is steering clinical work for money, which is precisely the shape the Anti-Kickback Statute and EKRA exist to catch. So neolife does not pick your doctor, does not practise medicine, and is never paid by a vendor on either side of a connection.
The consult request carries the clinical context the clinician needs and the patient's state — and nothing about your commercial arrangements. The network does not see your pricing, your other vendors, or your volume. On the neolife side the consult record holds ids and status; the clinical content stays with the parties licensed to hold it.
As with every other family here, there is a managed billing mode in the data model where neolife would hold the vendor contract. It is locked behind three independent clearances — the vendor's contract permitting it, counsel clearing it with a fair-market-value basis on file, and your own opt-in — and bring-your-own is the mode that ships. This is a description of how the product behaves, not legal advice.
Already contracted with a clinician network? Bring it, and stop turning patients away by state.
Tell us which network you work with and which states your own roster covers today.
Product names and logos are the trademarks of their respective owners and are used here only to identify the systems NeoLife interoperates with. Their use does not imply affiliation with, sponsorship by, or endorsement from those companies.