AI Agents for Healthcare: Back-Office Workflows You Can Govern
Prior authorization, referrals, claims follow-up, intake, scheduling, and coding drafts are the healthcare workflows agents can carry today. What decides whether they are safe to run is governance: PHI scoped to the minimum, every action logged, a human on consequential calls.
Key takeaways
- Healthcare agents split into administrative (prior auth, referrals, claims follow-up, intake, scheduling, coding drafts) and clinical (documentation, decision support). Only the administrative group is safe to deploy today.
- Governance decides whether they can run, not model quality: PHI scoped to the minimum necessary, a full audit trail, and a named human approving consequential actions.
- No product is HIPAA compliant on your behalf. Compliance is a property of your implementation, including the BAA chain covering whoever hosts the model.
- Diagnosis, treatment selection, triage acuity, medication decisions, and medical-necessity calls stay with a clinician.
- Scope note: administrative workflows only. Not clinical decision support, not a medical device, not a compliance opinion.
What are AI agents in healthcare?
AI agents in healthcare are systems that plan and carry out multi-step work across the EHR, payer portals, and scheduling systems. In practice they split into two groups. Administrative agents handle prior authorization, referrals, claims follow-up, intake, scheduling, and coding drafts, where the work repeats and a payer rule defines correct. Clinical agents touch documentation and decision support, where a licensed clinician is accountable. Only the first group is safe to deploy today, and only with scoped PHI access, full logging, and human sign-off. (If the underlying concept is new, start with what an AI agent is.)
A prior-authorization packet shows why. Someone reads the order, checks what the payer requires for that code, pulls the chart notes and the imaging report, assembles the submission, then chases the status for a week. None of that is medicine. All of it touches protected health information.
That split is the whole argument. IBM's overview of AI agents in healthcare divides the space the same way, putting billing, coding, prior authorization, and referral management on the administrative side, clinical documentation and decision support on the other, with governance policy and human review across both. Administrative work repeats, the volume is high, and correctness is measurable against a rule the payer publishes rather than against clinical judgment.
The clinical side carries a different accountability structure. A clinician signs and a clinician is liable, and software that participates in diagnosis or treatment selection can fall under medical device regulation, a product decision with a regulatory pathway attached. Everything below is administrative.
Six back-office healthcare agent workflows
These six are the administrative work agents can carry today. Each row names what the agent does, the PHI it touches, and where a human has to approve.
- Prior-authorization intake and submission. What the agent does: Detects the auth requirement, gathers required documents, assembles the request against payer rules, submits, polls status · PHI touched?: Yes: diagnosis codes, chart notes, imaging reports · Human approval point: Admin approves before submission; denials route to a person
- Referral routing and tracking. What the agent does: Reads the referral order, matches network and specialty, sends the packet, tracks whether the visit happened · PHI touched?: Yes: referral reason, demographics · Human approval point: Referral coordinator confirms the destination before sending
- Claims-status follow-up. What the agent does: Polls payer or clearinghouse for status, classifies pended and denied claims, drafts the next action · PHI touched?: Yes: claim-level PHI · Human approval point: Biller approves any resubmission or appeal
- Patient intake and data capture. What the agent does: Collects registration and insurance details, verifies eligibility, writes structured fields into the practice system · PHI touched?: Yes: demographics, coverage · Human approval point: Front-desk staff confirms before the record is finalized
- Scheduling and reminders. What the agent does: Books, reschedules, and sends reminders against clinic rules and provider templates · PHI touched?: Limited: name, contact, appointment time · Human approval point: Rules approved once; exceptions escalate to scheduling staff
- Coding and billing support. What the agent does: Drafts code suggestions from documentation with the supporting text cited · PHI touched?: Yes: full clinical documentation · Human approval point: Certified coder reviews and signs every code before billing
Prior-authorization intake and submission
The agent watches for orders that need authorization, then does the assembly work. It reads the payer's documentation requirements for that service, pulls the fields and attachments the requirement names, and builds a submission that either clears the payer's checklist or reports which item is missing.
The gotcha is that payer requirements are not stable. They differ by plan, by service, and by month, so the rule set has to live somewhere it can be versioned, not inside a prompt someone edited in March. CMS's Interoperability and Prior Authorization final rule (CMS-0057-F) requires impacted payers to decide expedited requests within 72 hours and standard requests within seven calendar days, to give a specific reason on denials from January 1, 2026, and to stand up a Prior Authorization API generally from January 1, 2027. Better payer plumbing makes this more automatable, and it means the requirements you encode will keep moving.
Referral routing and tracking
Referrals leak. The order gets written, the packet goes to an out-of-network specialist, and nobody notices until the patient calls three weeks later. An agent holds the loop: match the referral to an in-network specialist with capacity, send the packet, then track whether the appointment was booked and attended, escalating the ones that stall. The tracking half matters more than the routing half. Routing is a lookup. Tracking is state that has to survive weeks, which is exactly what a chat session cannot hold.
Claims-status follow-up with payers
Someone in every revenue-cycle team spends their week checking portals. The agent polls status, sorts claims into paid, pended, and denied, reads the denial reason code, and drafts the next step. A missing-modifier denial gets a correction draft. A medical-necessity denial routes to a person, because arguing medical necessity is a clinical argument.
If you have read our piece on AI agents for insurance (claims and governance), this is the provider-side mirror of the same pattern.
Patient intake and data capture
Intake is form-filling plus eligibility verification. The agent takes what the patient submitted, checks coverage with the payer, flags mismatches between the submitted policy number and what the payer returns, and writes structured fields into the practice management system rather than a free-text blob a human retypes later. Staff confirm before the record is finalized.
Appointment scheduling and reminders
The least PHI-exposed workflow here, and a reasonable first build for that reason. The agent works against clinic rules: provider templates, visit-type durations, prep requirements, cancellation windows. Reminders carry appointment time and location, nothing clinical. A request that does not fit the rules goes to a scheduler instead of being forced into a slot.
Coding and billing support
Draft only. The agent proposes codes from the documentation and cites the text supporting each one, which is what makes review fast. A certified coder reviews and signs. The agent never submits a code no human approved, and the audit record shows which codes were suggested, which were changed, and by whom.
What governance do healthcare AI agents require?
Model quality is not what determines whether these agents are safe to run. Access scope, logging, approval gates, and the BAA chain are. Four requirements decide it.
Minimum necessary access. The HIPAA Privacy Rule generally requires covered entities to take reasonable steps to limit the use and disclosure of PHI to the minimum necessary for the intended purpose. For an agent, that means field-level scoping, not database access. A prior-auth agent needs the diagnosis code, the ordered service, and the named supporting documents. It does not need the full chart, and it should not be technically able to read one.
A complete audit trail. Every PHI read, every write back to the practice system, every submission, and every approval needs a durable record with a timestamp and an actor. After an incident, a compliance officer asks which records were accessed, by what, under whose authority, and when. An agent whose reasoning happened inside a model call and left no artifact cannot answer that. This is the same containment argument we make in AI agent security and containment, applied to PHI.
Business associate agreements. Any vendor processing PHI on your behalf, including whoever hosts the model, sits inside your BAA chain. Check that before the pilot, not after.
Human sign-off on consequential actions. Submission, resubmission, appeal, and final coding all get a named human approver. The agent prepares. A person commits.
Be careful with the phrase "HIPAA compliant." A product cannot be compliant on your behalf. Compliance is a property of your implementation: how access is scoped, what gets logged, who signed the BAA, and what a human approves. A vendor that answers the compliance question with a badge rather than an architecture is answering a different question. The rest of the enterprise-grade governance checklist applies here with sharper teeth than in most industries.
What healthcare tasks should AI agents not do?
Diagnosis. Treatment selection. Triage acuity assignment. Medication decisions. Any determination of medical necessity, including on the appeals side of a denial. Anything a licensed clinician signs and is accountable for stays with that clinician, and an agent that drafts language in that territory is creating liability, not saving time.
Two more boundaries. An agent should not hold standing access to full charts when its task needs six fields. And it should not give a patient clinical guidance, because the line between a scheduling instruction and medical advice is thinner than it looks.
Nothing described here is a medical device or clinical decision support, and none of it should be deployed as such.
Build the prior-auth intake agent in Major
Take the first workflow and make it concrete. On Major, the agent is a predictable agent: when it works out the repeatable part of prior authorization, it builds an app for that part and runs the app instead of reasoning through the same sequence on every case.
That app holds the payer rules, keyed by plan and service, so a requirement change is a data edit with a version history rather than a prompt someone rewrites. It connects to the practice system to read the fields the rule names, to a payer portal or clearinghouse to submit and poll status, and to Slack or email to route the packet to an admin. The flow is fixed, and it runs in this order:
- Detect that the ordered service requires authorization.
- Gather the documents and fields the payer's rule names for that service.
- Check the assembled packet against the rule and report anything missing.
- Route the packet to a named admin for approval.
- Submit only after that approval is recorded.
- Poll until a decision lands, and escalate denials to a person.
That is a standard intake-submit-follow-up shape, worth reading alongside our other agentic workflow patterns.
State and governance sit in the app rather than in a conversation. The database holds the case, the payer rules, the approval record, and a log of every PHI field the agent read. Credentials are scoped at the platform layer to the minimum-necessary fields, so the agent's access is a property of the deployment and not a promise in a system prompt. The reasoning the model still does is narrow: read this case's inputs, judge whether the packet satisfies the rule, flag what is missing. It does not re-derive the workflow, because the workflow is code now.
That is the honest boundary of the claim. If your prior-auth volume is twenty cases a month, a governed app is more machinery than the problem deserves, and you should keep doing it by hand. At real volume, with real PHI exposure and a compliance officer who will eventually ask what touched which record, the difference between an agent that re-reasons every case and one that runs an inspectable app is the difference between a pilot and production. Reason once, run forever, and keep the log.
If the blocker has been governance rather than capability, this is a workflow you can build and inspect end to end, starting with the queue that hurts most. Major handles the database, the scoped credentials, the permissions, and the audit trail at the platform layer, so what you build is the payer logic and the approval gate. Get started on Major and build your prior-authorization intake agent.
Related articles
Frequently asked questions
- What are AI agents in healthcare?
- AI agents in healthcare plan and carry out multi-step work across systems like the EHR, payer portals, and scheduling tools. They divide into administrative agents, which handle prior authorization, referrals, claims follow-up, intake, and coding drafts, and clinical agents, which touch documentation and decision support. Administrative work is where agents are safe to deploy today, with scoped PHI access and human approval.
- Are AI agents HIPAA compliant?
- No product is HIPAA compliant on your behalf. Compliance depends on how you implement it: PHI access scoped to the minimum necessary under the Privacy Rule, a business associate agreement with every vendor that processes PHI including the model host, audit logging of every read and write, and a named human approving consequential actions.
- What healthcare tasks should AI agents not do?
- Diagnosis, treatment selection, triage acuity assignment, medication decisions, and any determination of medical necessity. Anything a licensed clinician signs and is accountable for stays with that clinician. Agents should also avoid giving patients clinical guidance and should never hold standing access to full patient charts when their task needs only a handful of fields.
- Can AI agents handle prior authorization?
- Yes, on the administrative side. An agent can detect that an authorization is required, gather the documents the payer's rule names, assemble the request, submit it after a human approves, and poll for status. It should not argue medical necessity. Denials on clinical grounds go to a person.
- Do healthcare AI agents replace staff?
- No. They take document gathering, portal polling, and status chasing off the queue so revenue-cycle and front-office staff spend their time on exceptions and patients. Human sign-off stays in the loop on every consequential action: submissions, resubmissions, appeals, and final coding all get a named approver.