Skip to main content
Healthcare AI

AI Agents in Healthcare: 7 Production Use Cases

Short answer: the healthcare AI agents that are actually in production in 2026 are administrative, not clinical. Appointment scheduling, prior authorization assembly, documentation drafting, claims follow-up, patient outreach, lab result routing and care coordination chasing all work today against real EHR systems through HL7 and FHIR interfaces — under HIPAA constraints that shape the architecture from day one. Below is what each agent does, which systems it touches, what compliance demands of it, and an honest read on what is production-proven versus still in pilot.

By Raman Makkar, CEO & Founder··14 min read

🏥Why healthcare is a fit for agents right now

Healthcare runs on structured, rule-bound, high-volume work that lives inside software systems: eligibility checks, authorization requests, claim status calls, referral chasing, result routing. The industry also carries a well-documented administrative burden — clinicians and staff spend a large share of the working day on documentation and coordination rather than direct care. That combination — repetitive digital work plus chronic understaffing — is exactly the profile where software agents earn their keep.

Three things changed recently enough to matter. First, EHR interoperability stopped being theoretical: information-blocking rules under the 21st Century Cures Act pushed the major EHR vendors to expose real FHIR APIs, and every large health system now has some sanctioned programmatic path into its clinical systems. Second, the major cloud and AI platforms will sign Business Associate Agreements, which makes it legally possible to run language models against protected health information inside a compliant boundary. Third, the models themselves crossed the reliability line for drafting and extraction work, which is most of what administrative healthcare tasks require.

The honest frame before the detail: the production wins are administrative and operational. An agent that assembles a prior authorization packet is real and deployed today; an agent making autonomous clinical judgments is not something any responsible operator ships. Every use case below is labelled with where it actually sits on that spectrum as of writing — verify before committing budget, because this space moves quarterly.

🗺️The seven use cases at a glance

Before the detail, here is the map. The readiness column is the one to watch: it reflects what is running in real provider and payer operations today, not what a demo can do on a good day. PHI exposure matters because it drives the compliance architecture — the more protected health information an agent touches, the heavier the controls.

Healthcare software and AI — how we build it

Use casePrimary systemsPHI exposureReadiness (2026)
Appointment scheduling and intake triageEHR scheduling, practice management, phone/SMSModerateProduction-proven for booking and reminders; protocol-bound triage
Prior authorizationEHR, payer portals, clearinghouses, X12 278HighProduction-proven for assembly and status chasing; submission varies by payer
Clinical documentation draftingEHR notes, ambient audio, coding systemsHighProduction-proven with mandatory clinician review and signature
Claims follow-up and denial worklistsPractice management, clearinghouse, X12 835/837HighProduction-proven for status checks and worklist triage
Patient outreach and recallEHR registries, engagement platforms, SMS/voiceModerateProduction-proven for recall and reminders; conversational triage is pilot-stage
Lab result routingLIS, HL7 ORU feeds, EHR inboxHighProduction-proven for matching and routing; human communicates clinical meaning
Care coordination chasingADT feeds, HIEs, referral systems, faxHighPilot-stage to early production; cross-organization friction is the limiter

The pattern in the table: agents are production-proven wherever the task is assembling, checking, chasing or routing information, and pilot-stage wherever the task shades into judgment about a patient. Buy the first category with confidence; pilot the second with a clinician governing the protocol.

📅1. Appointment scheduling and intake triage

What the agent does: answers inbound calls and messages, verifies the caller, finds the right slot across providers and locations, books, reschedules and cancels, sends reminders, and works a waitlist to backfill cancellations. On the intake side it collects the reason for the visit and routes the patient to the right appointment type and duration — new patient versus follow-up, procedure versus consult — which is where most scheduling errors and downstream rework come from.

Systems it touches: the scheduling module of the EHR or practice management system (Epic, Oracle Health, athenahealth and similar), usually through FHIR Schedule, Slot and Appointment resources or, in older environments, HL7 SIU scheduling messages. Voice and SMS agents run through telephony and messaging vendors that must sign a BAA before a single patient word passes through them.

The compliance constraint: verify identity before revealing or changing anything appointment-related, collect only the minimum information needed to route the visit, and keep the symptom conversation inside a clinically approved protocol. Established nurse triage protocols exist precisely so that routing logic is authored and governed by clinicians; the agent executes the protocol, it does not improvise one. Anything the protocol cannot answer goes to a human.

Readiness: booking, rescheduling, reminders and no-show recovery are production-proven and are the safest first agent deployment in a provider organization. Symptom-level triage beyond an approved protocol is pilot-stage and should stay that way until your clinical governance signs off.

📋2. Prior authorization assembly and chasing

What the agent does: detects that an ordered service needs authorization, pulls the relevant clinical documentation from the chart, checks the specific payer requirements for that service, assembles the packet, submits it through whatever channel the payer actually accepts — portal, fax, or an electronic X12 278 transaction — and then does the part humans hate most: checking status, chasing pended requests, and escalating before the request expires.

Systems it touches: the EHR for orders and clinical documentation, payer portals, clearinghouses, and the eligibility (X12 270/271) and authorization (X12 278) transaction sets. FHIR-based prior authorization APIs defined by the Da Vinci project are spreading, and federal rules are pushing regulated payers toward API-based prior authorization on a phased timeline through 2026 and 2027 — as of writing, verify exactly which requirements apply to the payers you work with before designing around them.

The compliance constraint: every transaction carries PHI, so every hop needs a BAA or a covered transaction path, full audit logging, and role-based access. Payer rules also change constantly, which means the knowledge base of requirements needs a maintenance owner — an agent working from stale payer rules produces denials at machine speed.

Readiness: assembly, submission through standard channels and relentless status chasing are production-proven and usually deliver the clearest return of any healthcare agent, because the baseline process is so manual. Auto-drafting appeals for denied authorizations works as a drafting assistant with human review; fully autonomous appeal strategy is pilot-stage.

📝3. Clinical documentation drafting

What the agent does: listens to the clinical encounter (with consent), drafts the note in the structure the clinician prefers, extracts orders, diagnoses and follow-ups, and suggests supporting codes. The clinician reviews, edits and signs. The agent is a drafter with perfect stamina, not an author of record.

Systems it touches: ambient audio capture, the note-entry surface of the EHR, and coding vocabularies (ICD-10, CPT) at the suggestion layer. In mature deployments the draft lands directly in the EHR note for attestation; in lighter ones it lands in a review queue the clinician copies from, which is slower but easier to govern at the start.

The compliance constraint: recording consent is a state-by-state question in the US — some states require all-party consent — so the capture workflow has to be configured per location, not assumed. The audio and transcripts are PHI with retention and access rules, the vendor signs a BAA, and the clinician attestation step is not optional: an unsigned agent-drafted note in the chart is a compliance finding, not an efficiency.

Readiness: this is the most production-proven clinical-adjacent use of generative AI in healthcare, and clinician adoption data across large health systems has been publicly positive. The boundary that holds everywhere: the agent drafts and suggests, the clinician reviews and signs. Auto-coding that bypasses human review is where organizations get into trouble and where we advise staying conservative.

💵4. Claims follow-up and denial worklists

What the agent does: works the accounts receivable queue that revenue cycle teams work manually today — checking claim status through clearinghouse transactions and payer portals, triaging denials into reason categories, assembling resubmissions and corrected claims, flagging underpayments against contracted rates, and escalating the small percentage that genuinely needs a human specialist.

Systems it touches: the practice management or hospital billing system, the clearinghouse, the X12 837 claim and 835 remittance transaction sets, and payer portals for the payers whose electronic transactions still do not answer the real question. Portal automation is unglamorous but is where much of the practical value sits.

The compliance constraint: claims data is PHI plus financial data, so the same HIPAA controls apply, and every agent action on a claim needs an audit trail that a revenue integrity team can review. Resubmissions and corrected claims must follow payer and CMS billing rules — an agent that optimizes for getting claims paid without respecting billing compliance is a False Claims Act risk, not a revenue win. Keep a human in the loop on anything that changes coding or charge content.

Readiness: status checking, worklist triage and resubmission assembly are production-proven. Predictive denial prevention — catching the claim likely to deny before it goes out — works where the data is clean and is best treated as an assist to the scrubber, not a replacement.

📞5. Patient outreach and recall

What the agent does: runs recall campaigns against care-gap registries (patients overdue for screenings, annual visits, immunizations), books the appointment when the patient responds, sends medication adherence and pre-procedure instruction reminders, and conducts structured post-discharge follow-up calls that escalate to a nurse when the answers cross defined thresholds.

Systems it touches: the EHR registry and health-maintenance modules that define who is due for what, patient engagement platforms, and SMS and voice channels. Every outbound channel vendor handling patient-specific content needs a BAA, and the campaign lists themselves are derived from PHI and handled accordingly.

The compliance constraint: two regimes apply at once. HIPAA distinguishes treatment communications from marketing, and the definition of marketing is narrower than most teams assume — get counsel to classify your campaigns. The TCPA separately governs automated calls and texts and requires appropriate consent; an outreach agent without a consent-management layer is a class-action invitation. Escalation thresholds on follow-up calls are clinical decisions and belong to clinical governance.

Readiness: recall, reminders and structured follow-up with escalation are production-proven. Open-ended conversational handling of patient symptoms is pilot-stage and should route to humans aggressively.

🔬6. Lab result routing and 7. Care coordination

Lab result routing: inbound results arrive as HL7 ORU messages from laboratory information systems, and a meaningful share fail to match cleanly to a patient or ordering provider, landing in error queues that humans work by hand. The agent matches and files routine results, flags abnormal results to the ordering provider inbox with the right priority, and triggers patient notification per practice policy. The hard boundary: critical values follow a documented human notification workflow — the agent routes and tracks, a human communicates clinical meaning.

Care coordination: the unglamorous core of coordination is chasing documents — referral letters, consult notes, discharge summaries, records from outside organizations. The agent works ADT (admit, discharge, transfer) feeds, queries health information exchanges where connected, requests records through whatever channel the counterparty supports including fax, and tracks every open loop to closure or escalation. Referral leakage — patients referred out and never completing — is largely a chasing problem, and chasing is what agents do well.

The compliance constraint: both workflows are dense with PHI moving between organizations, which raises the minimum-necessary question on every exchange and requires honest data-sharing agreements with counterparties. The 21st Century Cures Act information-blocking rules generally push toward sharing, but state privacy laws stricter than HIPAA (several states have them, especially around behavioral health and reproductive health data) still govern and vary — this is a legal review item, not an engineering assumption.

Readiness: result matching, routing and tracking are production-proven. Cross-organization coordination chasing is early production at best, limited less by the agent than by counterparty systems — some counterparties still require fax, and the agent has to be built to live with that rather than pretend otherwise.

🔒The HIPAA constraints that shape the architecture

None of these constraints are exotic, but they have to be designed in from the first sprint rather than retrofitted. A healthcare agent that was built without them is usually cheaper to rebuild than to remediate. This is general information, not legal advice — have healthcare counsel review your specific deployment.

HIPAA-compliant development practices

ConstraintWhat it means for an agent deployment
Business Associate AgreementsEvery vendor touching PHI — model API, telephony, messaging, logging, analytics — signs a BAA before any patient data flows
Minimum necessaryPrompts and tool calls carry only the fields the task requires; the architecture constrains data access, not just the policy document
Access controls and auditRole-based access to PHI, and an immutable log of every agent read and write — auditors will ask, and you want the answer to be boring
Human-in-the-loop on clinical contentDrafts, suggestions and routing are fine; clinical sign-off stays with licensed humans and is enforced in the workflow, not by convention
State law overlaysRecording consent, and state health-privacy laws stricter than HIPAA in places, configured per operating location
No training on your PHI by defaultContractually exclude provider data from model training; de-identify before any use in evaluation sets or fine-tuning

The single most common failure mode we see is not a breach — it is a pilot that cannot graduate because the logging, BAA coverage or consent capture was bolted on after the demo. Budget the compliance layer as roughly a third of a serious healthcare agent build and you will rarely be surprised.

🤝What it costs and when to bring in a partner

Honest labelled market ranges for a first production healthcare agent, built against a real EHR with a compliance layer: a focused single-workflow agent (scheduling or claims status chasing) typically runs $60,000 to $150,000 and three to five months, with EHR integration and governance review consuming more of the timeline than the AI itself. A broader revenue-cycle or outreach program across two or three workflows lands at $150,000 to $400,000 over six to twelve months. Annual run costs commonly add 15 to 30 percent of build cost per year.

The build-versus-buy line in healthcare is sharper than in most industries. If a mature vendor product covers your workflow and integrates with your EHR, buy it — the commodity end of this market is real. The case for custom is workflows that span systems no single vendor covers, a payer mix or specialty that commodity tooling fits poorly, or a workflow that is a competitive advantage you want to own.

Bring in a development partner when you have a workflow with measurable baseline pain (hours per authorization, denial backlog, no-show rate), EHR API access or a path to it, and a compliance stakeholder who will engage early. If you are missing the third one, fix that before the first sprint — it is the dependency that kills more healthcare agent projects than any technical one. We build these systems for provider and healthcare-services organizations; the healthcare practice page describes the delivery model and the compliance approach in more detail.

Healthcare AI and software deliveryWhat a healthcare build costs, broken down

FAQ

Frequently Asked
Questions.

Common questions on healthcare ai, answered by the Codazz engineering team.

Ask Us Anything

Both, depending on the workflow. Administrative agents — scheduling, prior authorization assembly, claims status chasing, documentation drafting with clinician review — are in production at provider organizations today. Anything that shades into autonomous clinical judgment is and should remain pilot-stage under clinical governance.

Yes, with the right architecture: BAAs with every vendor touching PHI, minimum-necessary data access, role-based controls, full audit logging, encryption, and contractual exclusion of your data from model training. Compliance is a property of the whole deployment, not of the model. This is general information, not legal advice.

Usually prior authorization chasing or claims status work, because the baseline is heavily manual, the volume is high, the task is rule-bound, and success is measurable in weeks. Scheduling is the other strong first candidate, especially where call-center load or no-shows are the visible pain.

In practice these deployments absorb backlog and growth rather than headcount — most organizations are chronically short-staffed in exactly these roles. The realistic outcome is the same team working a much larger queue, with humans concentrated on the exceptions the agent escalates.

Administrative agents generally do not. The FDA boundary matters when software is intended for diagnosis, treatment or clinical decision support beyond what a clinician independently reviews. Have regulatory counsel classify your specific use case.

A focused single-workflow agent typically reaches production in three to five months, with EHR integration access and compliance review consuming more calendar time than the AI build. Organizations that start governance and API-access conversations before development begins cut months from the timeline.

Running a healthcare operation with manual bottlenecks?

Tell us the workflow — authorizations, claims, scheduling, outreach — and the systems it touches. We will map it to a production-ready agent design with the compliance layer included, scoped in about a week.

Get a Free Quote

Tell us about your project

Or talk to an engineer