Healthcare AI Development

There is a strange moment in almost every healthcare AI project.

The prototype works.

Somebody pastes a patient message into an LLM, the answer is excellent, everyone around the table nods, and for approximately 15 minutes the project looks almost finished.

Then somebody asks:

"Fine. How does it know which patient this is, get the schedule from our EHR, book the appointment, follow our insurance rules, log what happened and not invent an answer when the API is down?"

That is where healthcare AI development actually starts.

What we actually build

Our projects usually sit somewhere between software engineering, AI architecture, healthcare operations and systems integration.

Typical work includes:

• AI agents for patient communication — chat, WhatsApp, voice, booking, routing, preparation and human escalation;
• clinical and staff copilots — chart preparation, information retrieval, workflow support and drafting;
• AI medical documentation — scribe flows, note generation, document extraction and documentation audit;
• RAG and healthcare knowledge systems — patient records, protocols, payer rules and internal knowledge;
• EHR and legacy-system integration — APIs, FHIR, HL7, databases, files, interface engines and, when absolutely necessary, controlled RPA;
• conversation and call intelligence — transcription, classification, quality analysis and management findings;
• health-tech product development — when AI is part of the product you are selling rather than an internal clinic automation;
• custom operational automation — the weird projects that do not fit a clean software category but still consume human time every day.

Sometimes the final answer contains a lot of AI.

Sometimes it contains one model call, four integrations and a surprising amount of ordinary software.

I am fine with both.

The expensive part starts after the AI demo works

Modern models made prototypes dramatically easier.

That is a good thing.

What did not disappear is everything required to run the prototype thousands of times with real data and real users.

A production healthcare AI system needs to survive:

• ambiguous patient language;
• missing or stale data;
• tool and API failures;
• several users acting at once;
• authentication and permissions;
• model changes;
• long conversations and intent drift;
• multilingual input;
• patient privacy requirements;
• staff doing something nobody included in the workshop diagram.

That gap between "it answered correctly" and "I am comfortable letting it run in the clinic" is where most of the engineering lives.

A healthcare AI system is more than a model call

A normal architecture may include:

• source systems and data normalization;
• identity and authorization;
• retrieval and context assembly;
• LLM reasoning;
• deterministic business rules;
• narrow tools/actions;
• transaction validation;
• logging and monitoring;
• evaluation suites;
• human review or escalation where appropriate.

I like models to do the work they are good at: language, ambiguity, summarization, synthesis and choosing between well-defined next steps.

I do not like using an LLM as an excuse to remove all deterministic software from the system.

A booking transaction is still a transaction. Permission is still permission. A patient ID should still be a patient ID rather than "probably this person from the context."

For deeper architecture, see AI Agents in Healthcare, RAG in Healthcare and Healthcare AI Guardrails.

Integration is usually the real project

A standalone AI tool can be useful.

An AI tool that knows what is happening inside the clinic can be transformative.

That means integration.

We have spent years around EHRs, scheduling, laboratories, billing, patient apps, CRM, telephony and the less glamorous systems that keep healthcare organizations running.

If the system has a proper API, excellent.

If it has FHIR or HL7, also excellent.

If it has a database, file export, interface engine or some vendor-specific mechanism, we evaluate that.

And sometimes the answer is:

"This thing was written in 2008, there is no API, the vendor stopped answering email, and replacing it would shut down half the clinic."

That is not unusual enough to scare us.

See How to Add AI Without Replacing Your EHR for the less pretty versions of integration.

Safety and testing are product features

Healthcare AI safety is not a disclaimer at the bottom of the screen.

It is architecture.

If the system talks to patients, we define which facts come from trusted sources, which questions can be answered, which actions require confirmation, how identity is established and what must go to staff.

If the system writes clinical drafts, we define physician review and provenance.

If it can act on operational systems, we constrain tools and validate transactions outside the model.

And then we test those rules.

Our evaluation work uses repeatable scenarios rather than "we chatted with it and it looked good": expected tool calls, forbidden actions, state transitions, tool failures, multilingual cases and regression suites.

Read How to Test a Healthcare AI Agent Before Production for the detailed approach.

How development works with us

1. First conversation — free. Tell us the workflow and the problem. You do not need to translate it into technical requirements first.

2. Discovery — when needed, from $50/hour. We map the real process, systems, data, constraints, APIs, security and edge cases. Sometimes this proves the project should be smaller. Occasionally it proves you should buy an existing product instead.

3. Scope and architecture. We define what version one actually does, what it deliberately does not do, the integration boundaries, safety model and how we will know it works.

4. Development — from $90/hour. Backend, frontend, AI logic, integrations, infrastructure, testing and deployment as required.

5. Pilot. We prefer a small production slice, sandbox or shadow mode where possible before making the entire operation dependent on new AI.

6. Production and iteration. Real users reveal the assumptions the workshop missed. We fix them and expand where the product proves value.

Custom does not mean rebuilding everything from zero

I have no desire to train a new foundation model because a clinic needs appointment reminders.

Good custom development uses commodity components where commodity components are good enough.

That may mean commercial LLMs, speech models, cloud infrastructure, messaging providers or existing libraries.

We build the part that creates value:

• workflow;
• integration;
• context model;
• business logic;
• guardrails;
• evaluation;
• user experience;
• proprietary product behavior.

This is also why build vs buy is not a religious question for us.

When AIn't Doctor is a good fit

We are strongest when the project contains several of these at once:

• healthcare workflow complexity;
• patient or clinical data;
• EHR or legacy-system integration;
• custom AI behavior;
• multilingual communication;
• high operational volume;
• a need to go beyond a proof of concept into production.

If you need one generic website chatbot, there are cheaper ways to get one.

If a mature SaaS product already fits the workflow, I may tell you to buy it.

If you already have an excellent internal healthcare AI team, you may only need a second opinion.

Where we make sense is the messy middle:

"We know AI can help here. The problem is that it has to work with our real clinic, real systems and real rules."

That is basically our job description.