AI for healthcare
Assistants over a health institution’s administrative and process documentation: authorizations, requirements, care pathways and provider networks. With one line drawn in writing — they do not diagnose, do not interpret results and do not replace a professional.
Key takeaways
We build this for the administrative layer, not the clinical one: authorizations, procedure requirements, care pathways, provider networks and hours. That is where the query volume sits and where the risk is manageable.
The central constraint is architectural, not a prompt: the system does not diagnose, does not suggest treatment and does not interpret results, and that boundary is measured like any other metric.
The metric that governs here is not coverage but groundedness: every statement has to hold up against the cited document. An invented requirement means somebody loses their appointment.
Patient information is sensitive data under Colombian law. Where identifiable information is involved, we deploy inside the institution’s own cloud and filter before anything reaches the model.
What it answers, concretely
Every one of these has a documented answer inside the institution, repeats thousands of times a month, and is today answered by a person reading an instruction sheet.
- Documents, orders, timelines and where to file. It changes by service and by payer agreement, and it is written in a manual the patient does not have.
- Provider network, sites, services enabled per site. Information that changes often and, out of date, sends people on wasted trips.
- Fasting, medication pauses per the lab’s instruction sheet, what to bring. Taken verbatim from the preparation guide, with the guide cited.
- Requires integration with the institution’s system: without it the assistant can explain the process but not the status of a case.
- Administrative routes, deadlines and channels. Taking these off the phone line is among the most measurable savings a provider can get.
What this system does not do, and how that is guaranteed
It does not diagnose, does not suggest or adjust treatment, does not interpret lab results and does not triage urgency. That is not a statement of intent in a contract: it is a constraint that gets built and verified.
It is implemented in three layers. First, the corpus: only administrative and process documents go into the index; clinical practice guidelines stay out, so there is nowhere for a clinical answer to come from. Second, intent classification: a query asking for medical judgement is routed to the institution’s line before it ever reaches retrieval. Third, measurement: the evaluation set carries a subset of clinical questions whose only correct answer is an escalation, reported separately.
Explicit refusal becomes the default behaviour, not the exception. When retrieval comes back empty or ambiguous, the system says so and hands off to a person — and that gets measured, because an assistant that never escalates is inventing somewhere.
The numbers we ask for before opening it to patients
| What is measured | What it means | Why it matters here |
|---|---|---|
| Groundedness | Every statement holds up against the cited document, adding nothing that is not there. | It is the headline metric, above coverage. An invented requirement means somebody loses an appointment and queues again. |
| Correct escalation on clinical queries | A subset of medical questions whose only correct answer is routing to a professional. | It is the boundary of the service. Reported separately because the overall average hides it. |
| Correct refusal rate | When the documentation does not cover the question, the system says so and escalates. | An assistant that never says "I do not know" is approximating. In healthcare, approximating has consequences. |
| Freshness of the cited document | The answer cites the in-force version of the instruction sheet or directory, with its date. | Provider networks and requirements change. Answering with last year’s version is a silent error. |
Sensitive data, in practice
Health information is sensitive data under Colombia’s Law 1581 of 2012 and comparable regimes elsewhere. These are the architectural decisions that follow from it, taken up front rather than afterwards.
- where identifiable information is involved. Azure OpenAI or Amazon Bedrock in your subscription: documents and queries never leave your cloud.
- Names, national IDs and record numbers are detected and replaced before any text reaches inference.
- The index holds instruction sheets and manuals, not clinical records. Personal data is fetched over API at the moment of the query and not persisted.
- We keep what is needed to debug and audit, under a retention policy written down before production.
- Enterprise plans where data sent through the API does not feed models, in every configuration.
If what you want is diagnostic support, clinical triage or image reading, this is not us. That is a medical device with its own regulatory path, and there are vendors who specialise in that ground.
And if administrative query volume is low, or the documentation is out of date and nobody maintains it, the right project is putting the documentation in order first. A retrieval system over an old manual returns old answers with far more authority than a PDF does, and that is worse than not having it.
Related services
RAG systems
Chunking, reranking and hybrid search, evaluated with recall@k and NDCG.
View serviceAI chatbots and assistants
With the evaluation set run before it ever reaches production.
View serviceProject rescue
The system is already in production and answers badly. We measure it and determine what to fix.
View serviceIntegrations and APIs
MCP servers against the systems already in operation.
View serviceMore from the blog
Frequently asked questions
Can the assistant tell a patient what they have or what to do about a result?
No, and not by instruction but by construction. Clinical practice guidelines do not enter the index, so there is nowhere for that answer to come from; a query asking for medical judgement is classified before retrieval and routed to the institution’s line; and the evaluation set carries clinical questions whose only correct answer is an escalation, measured and reported separately. That boundary is defined in writing with the institution before anything is built.
What about clinical records and data protection?
Health information is sensitive data and the design assumes it from the start. The index holds administrative and process documentation, not clinical records. When an answer needs a specific person’s data — the status of an authorization, say — it is fetched over API at that moment and not persisted. Where identifiable information is in play we deploy on Azure OpenAI or Amazon Bedrock inside the institution’s subscription, and filter personal data before inference.
Does it replace the call centre?
No, and pitching it that way is where the projects that end badly come from. It takes the repetitive, documented part off the queue — requirements, hours, sites, administrative routes — which is usually most of the volume, and leaves the human team what needs judgement or context. The success measure we recommend is not "how many conversations it resolved" but "how many it escalated correctly": an assistant that never escalates is inventing somewhere.
Does it connect to our health information system?
Yes, over API, and that is what separates a useful assistant from an informational one. Without integration it can explain how an authorization works; with integration it can say where that person’s authorization is. We work against whatever exists — HIS, scheduling, patient portal — through MCP servers or direct integrations, with whatever permissions and access logging the institution requires.
Is this for a small clinic or only for a large network?
It depends on volume and on the state of the documentation, not on size. If administrative queries run in the dozens per day and the instruction sheets fit in a few pages, a good FAQ handles nearly all of it and this is unnecessary. The conversation changes with several sites, services with different requirements, agreements that change, and documentation scattered across departments — that is when finding the right answer is already work.
How long does it take and what do you need from us?
Six to eight weeks to production for a defined scope, with something running from week one. Two things are needed from your side and neither is technical: somebody who can say which version of each document is in force, and somebody from the service area to validate the correct answers in the evaluation set. Without that the system can be built but not measured, and without measurement we do not recommend opening it to patients.
We already have a chatbot and people complain about it. Can it be fixed?
Almost always, and it is worth measuring before deciding. In one week we build a reference set from real questions off the channel, measure groundedness and escalation, and hand back the failures ranked by impact with each fix and its estimated effort. The usual cause is not the model: it is that the corpus mixes old and new versions of the same instruction sheet and the system has no way to know which one governs. If the diagnostic does not reach three actionable findings, it is not billed.
Book 15 minutes
Tell us what you are building, or what stopped working. You leave the call with a concrete answer: it can be fixed, it can be built, or it isn't worth it.