Koltra for medical practices · Product in development
Koltra is building patient access operations for medical practices: software that answers the phone, schedules and reschedules within your rules, collects intake, routes messages, and hands anything clinical to the care team with the context attached. It is being built so every call ends in a recorded outcome, not a voicemail.
Patient access operations is a design-partner engagement today, not an available off-the-shelf service. This page describes the operating model it is built to.
The routine share of inbound patient contact is structured work: it follows rules the practice already has. That is the work an AI medical receptionist should complete, and the work this product is being built to own.
A reschedule that used to become a callback should finish on the call, against your own providers, locations, visit types, and preparation rules.
The patient should arrive with their details already on file and their forms already chased, instead of completing both at the desk.
Refill, referral, and billing calls should reach the right queue as structured tasks, so the callback pile stops being where requests wait.
Hours, directions, and parking should stop interrupting the desk, because the practice approved those answers once.
Evenings, lunchtime peaks, and short-staffed days should stop converting into voicemail for someone to work through tomorrow.
Symptoms, triage, medical advice, and any question whose answer depends on a patient's condition stop the workflow and route to the designated clinical team with the transcript and collected facts attached. The product does not assess, advise, or decide care. That boundary is the design, not a disclaimer.
Both models answer the phone. They differ in what is waiting for staff afterwards, which is the part that decides whether coverage actually reduces work.
| The call | A message-taking service leaves | An operating layer should leave |
|---|---|---|
| Reschedule request | A callback slip. Staff phone the patient back and repeat the conversation. | The appointment moved under the practice's rules, confirmed to the patient, and written to the record. |
| New patient intake | A name and a number. | The permitted intake fields collected and attached, with forms requested before the visit. |
| Clinical question | A message that may sit in a queue with no owner. | A stop, and a route to the designated clinical team with the transcript and collected facts attached. |
| Call at 9 p.m. | Voicemail until morning. | The same declared workflow, or an escalation under the practice's own rule. |
What a well-run patient call should look like behind the voice: six declared stages, none improvised at call time.
A voicemail pile tells you nothing. A finished call should tell you what was requested, what was done, who accepted any handoff, how long it took, and what it cost. That per-run record is what makes an AI receptionist operable rather than merely subscribed to, and it is the standard Koltra designs against.
Koltra has executed business associate agreements with major infrastructure vendors expected to handle protected health information, including AWS. PHI is handled only under a customer BAA, with the deployment data flow, relevant providers, safeguards, and customer controls approved.
If you are still comparing options, start with the plain-language guides. They cover the mechanics, the cost shapes, and the questions that separate vendors, without the pitch.
The six-stage pipeline behind the voice, and the questions that expose a demo.
Read the guide →The human and AI forms compared, the clinical boundary, and the privacy checks.
Read the guide →The three coverage models compared by call mix, depth, and cost shape.
Read the guide →A useful deployment acts inside the practice's scheduling and record systems through APIs with scoped read and write permissions, rather than taking messages about them. The exact systems, records, and permitted actions are defined with the practice before any live use.
Koltra has executed business associate agreements with major infrastructure vendors expected to handle protected health information, including AWS. Healthcare product work and the shared platform are being built for HIPAA-governed deployments. PHI is handled only under a customer BAA, with the deployment data flow, relevant providers, safeguards, and customer controls approved.
Disclosure is a product rule: the system states what it is and gives every caller a clear route to a person. Callers handle honest software well; what they punish is a system that performs humanity poorly or traps them away from a person.
The product is designed to run the same declared workflows at any hour, which is where much of the value concentrates: after-hours and overflow calls are where missed work piles up. Emergencies follow a declared escalation rule to the practice's designated route.
Category pricing typically combines a subscription, included minutes, and usage overage, while human services bill per call or per minute. Compare options on cost per completed call at your real volume, including setup, integrations, and the staffing behind escalations, rather than on sticker price.
Practices that bring a recurring front-desk workflow get the operating model applied to their real call mix: which requests can complete unaided, which route to staff, where the clinical boundary sits, and what the record proves. That mapping is useful whether or not you deploy Koltra.
Patient access operations is a design-partner engagement today, not an available off-the-shelf service. This page describes the operating model it is built to.