Paperwork in, records out
Referrals, forms and protocols read into records and answers with a source, on a model pool you choose, with request content kept only if you allow it.
The care is the job. The forms are the day.
The referral is a scanned fax, page three sideways.
Someone retypes it before the patient can be booked.
The protocol answer is in a ninety-page PDF.
The nurse calls the one person who knows it by heart.
The phone rings all morning with the same questions.
Hours, parking, what to bring. The urgent call waits.
The forms are many.The patient is one.
The situations, and the guide that builds each
Every one is a build guide: the architecture, the policy, the code that was run, and what was measured.
Referrals and intake forms into your records
Scanned and typed forms into fields that match a schema you define, with a review queue for anything validation rejects and the model and cost stored beside every record.
Build guide: Document extraction to JSON
Questions over protocols and procedures
Retrieval over your own protocol library with the answer cited to the passage it came from, and a plain statement when the passages do not settle the question.
Build guide: RAG over a knowledge base
Routine calls on the front-desk line
A turn-based voice assistant for hours, directions and preparation questions. Measured honestly at 7 to 13 seconds a turn today, which fits an after-hours line and not yet a conversation.
Build guide: Voice agent
Patient questions on your website
A chat that answers from your published pages with a citation, declines clinical advice it should not give, and hands a personal question to a person with the conversation attached.
Build guide: Customer support assistant
Scheduling and case tasks with a person on every write
An agent that reads schedules and cases through tools named in a policy. Reads run at once; any change waits for approval, and every run is one record with its tool calls.
Build guide: Agents with tools and MCPWhat changes for healthcare and life sciences
Forms and referrals to read into records, protocols to answer from, intake over the phone, and a pool of models you can name to an auditor.
A pool you choose
The routing policy names the models that may see a form or a question, and nothing outside it is ever chosen. Your own provider keys or cloud accounts keep the call inside agreements you already hold.
Retention is your decision
Request content is kept for up to 30 days by default and not at all with zero retention on the key or the organisation. The routing decision is kept without the content.
Answers name their source
Protocol answers cite the passage they used, and extracted records keep the document they came from, so a reviewer checks the source rather than the model.
Honest about what is real time
Every design states its measured latency. Voice is a turn-based assistant today, and the guides say so rather than promise a conversation.
Figures with a source
Every number here was measured by us and says when. Where nothing was measured, nothing is claimed.
| One short document extracted to JSON, non-streamed | 1.8 to 3.2 s | Measured 2026-10-14, three runs, client-side from India |
| One voice turn, last word to first sound of the answer | 6.7 to 13 s | Measured 2026-10-14, three turns, client-side from India |
| Streamed answer, first token, latency objective | 1.5 to 3.5 s | Measured 2026-10-14, three runs, client-side from India |
| Time to decide (classify and rank), live traffic | p50 18 to 31 ms | Gateway classifier timer, 2026-10-13 |
Questions from healthcare and life sciences teams
Yes. The extraction design turns a form's text or a page image into fields that match a schema you define, validates them against your rules, and sends what fails to a review queue with the reason. Every record keeps the model and the cost that produced it.
Only the models in your routing policy pool, and a request can narrow the pool but never widen it. Your own provider keys or cloud accounts run the call inside the agreements you already have with those providers.
For up to 30 days by default, deletable at any time, and not at all with zero retention on the key or the organisation. The routing decision is kept without the content.
Yes. The retrieval design numbers the passages it found and the prompt requires a citation after each sentence. When the passages do not settle a question, the answer says so rather than guessing.
Only what your own documents say, with a citation, and the prompt refuses everything outside them. A question about a patient's own case is handed to a person with the conversation attached.
As a turn-based assistant: it transcribes a question, answers in a sentence and speaks the reply. Measured at 7 to 13 seconds a turn on 2026-10-14, which fits an after-hours line, not yet a live conversation. The voice guide lists what would close the gap.
No. Your records, scheduling and documents stay where they are. The generation call goes to Inferbase with the model set to auto; the OpenAI SDK with the base URL changed is the whole integration.
Through tools you define, under a policy that lists which tools a key may call. Reads run at once; writes wait for a person to approve, and every run is recorded with its tool calls.
Whichever models in your policy pool win on the objective for each request: a fast model for a routine question, a strong one for a long protocol. The response always names the model that served.
Put intelligence in the middle.
One gateway in front of every model, with your policies applied and every decision on record. Start on the free plan with 5,000 requests a month, no card required.