AI in healthcare operations: eight use cases, what the agent does and where a person decides

AI in healthcare pays off first on administrative work: intake, scheduling, the phones, documentation support, prior-authorization paperwork and billing. In each of those an agent can collect, draft and route, while a qualified person decides anything clinical and signs anything that goes in the chart. The size of that workload is well documented. A time and motion study in Annals of Internal Medicine found that for every hour physicians spent face to face with patients, they spent nearly 2 more hours on EHR and desk work. This guide takes eight operational use cases, says what the agent does in each and where a person decides, and explains in plain terms what HIPAA asks of any vendor that touches patient data. It is not clinical, legal or compliance advice.

AI use cases in healthcare operations at a glance

A note before we start

Gigabit is a software vendor. We are not a covered entity, we do not provide care, and nothing below is a clinical claim. When a project touches patient data we work as a business associate and sign a BAA before work starts. Where we use our own numbers, they come from two published builds: a unified intake and EHR integration for a 14-location medical group and a telehealth platform for a chronic disease management company. We have not published a case study for documentation drafting or prior authorization, and we say so where it applies. The realism rating on each use case is our engineering judgment: strong (works with systems most groups already run), conditional (works once a named gap is closed) or buy (a product you should license, not build).

What the public numbers say

• Desk work outweighs face time. The Annals study observed 57 US physicians in four specialties for 430 hours. They spent 27.0% of the office day on direct clinical face time and 49.2% on EHR and desk work, and those who kept diaries reported 1 to 2 more hours of work each night. It dates from 2016 and covered self-selected, high-performing practices.
• Ambient scribes are linked to less burnout. A 2025 study in JAMA Network Open followed 263 clinicians at six US health systems before and after 30 days with an ambient AI scribe. The share reporting burnout fell from 51.9% to 38.8%, and they reported less time documenting after hours. It was a voluntary before-and-after survey with no control group, and one author worked for the scribe vendor.
• Drafted replies eased the load but saved no time. In a 2024 Stanford study, 162 clinicians had AI-drafted replies to patient portal messages for five weeks. They used the drafts for 20% of replies on average. Task load and work exhaustion scores fell, and there was no change in reply, write or read time.
• Prior authorization is moving to deadlines and APIs. Under CMS's interoperability and prior authorization rule, impacted payers such as Medicare Advantage and Medicaid managed care plans must send decisions within 72 hours for expedited requests and seven calendar days for standard ones, and give a specific reason for a denial, beginning in 2026. A Prior Authorization API must be in place from 1 January 2027.
• There is still money in automation. The 2025 Index report from DataSpring, powered by CAQH, cites a $21 billion industry savings opportunity from automation.

The eight use cases

1. Patient intake

Patients fill in forms, and staff retype them into the EHR. An intake agent asks the questions in plain language, captures history, insurance and consent, checks that nothing is missing and writes structured answers to the record. It does not interpret symptoms.

Our closest evidence is the 14-location medical group. We built one intake flow for web, tablet and kiosk covering demographics, insurance, consent and visit prep, with insurance eligibility checks, e-signature and validation, and an HL7 and FHIR bridge that wrote the answers into the EHR with an audit log on every write. Over 12 weeks, median intake and admin time per patient fell 41%, visits per clinician session rose 16% and the form error and rework rate fell 32%. That build was a structured flow and an integration, not a language model. It is also the layer a conversational agent needs underneath it.

• Data it needs: the EHR's API or an integration bridge, your forms and consent wording, and eligibility checks.
• What goes wrong: the agent writes to the wrong chart. Match the patient before any write and log every one.
• Realism: strong. Our guide to patient intake agents and EHR integration covers the pattern.

2. Scheduling and reminders

Booking is a rules problem: which visit types, which providers, how long, which locations. An agent applies those rules in conversation, sends two-way reminders and offers a freed slot to the next patient. It should never judge how urgent a symptom is. Anything that sounds clinical goes to staff, with the conversation attached.

• Data it needs: scheduling rules in writing, and read and write access to the schedule.
• Realism: strong where the practice management system has an API; conditional where it does not.

3. Front-desk calls and messages

Hours, directions, parking, what to bring, how to pay a bill. These fill the phone queue, and the answers are already written down. An agent can answer from your own policies and pass everything else to a person. Note where HHS draws the line on vendors: its business associate guidance lists a third-party chatbot on a provider's patient portal that handles patient information for symptom assessment, reminders and scheduling as an example of a business associate. A HIPAA-compliant chatbot is a system with a contract and controls behind it, not a widget.

• Keep a person on: medication questions, results, symptoms and complaints.
• Realism: strong for non-clinical questions.

4. Documentation support

An ambient scribe listens to the visit, with consent, and drafts the note. The clinician edits and signs it. The JAMA Network Open study above is the best public evidence that this reduces the burden clinicians report. Many EHRs now offer note drafting inside the product, and specialist vendors sell it.

• What goes wrong: a fluent draft with an error in it. The signer is responsible for every line.
• Realism: buy. License a scribe your EHR supports. We have not published a documentation project, and building a scribe from scratch rarely makes sense for a provider group.

5. Patient message drafts

Portal inboxes have grown, and each message needs a careful reply. A model can draft one for the nurse or clinician to edit. The Stanford result is a useful caution: staff felt less loaded, but the clock did not move. Buy this for workload, not for minutes saved, and measure both.

• Keep a person on: every message. Nothing is sent without a clinician or nurse reading it.
• Realism: buy, usually as an EHR feature.

6. Prior-authorization paperwork

A prior authorization is a packet: the order, the diagnosis codes, the supporting notes and the payer's form. An agent can pull those from the chart, check them against the payer's stated requirements and list what is missing. A qualified person reviews and submits it, and the payer makes the decision. The CMS rule matters here because more of this exchange will move to structured APIs from 2027, which suits software better than fax and portals do.

• Data it needs: chart access, payer requirements kept current, and a review queue.
• Realism: conditional. We have no published case, and payer rules change often.

7. Billing and claims

Before the visit, an agent can run eligibility and flag a problem while there is time to fix it. After it, an agent can spot missing fields before a claim goes out, sort denials by reason and draft an appeal with the supporting documents attached. Coders choose the codes. Billers approve what is sent. An agent that suggests a code should show the documentation it relied on, and nothing here promises a higher reimbursement.

• Data it needs: practice management and clearinghouse access, payer rules and denial history.
• Realism: strong for eligibility and denial sorting; conditional for anything near coding.

8. Staff knowledge search

Staff ask where a policy is, which form a payer needs, or how a location handles a referral. A search assistant over your policies and procedures answers with a link to the document, and says not found when the document is silent. It points to the procedure and never replaces it.

• Realism: strong, with a named owner for each document set and access rules that match your roles.

What HIPAA requires of a vendor, in plain terms

This is a summary of HHS's own pages, not legal advice.

• Who counts. A vendor that creates, receives, maintains or transmits protected health information for a covered entity is a business associate. HHS's examples include an app developer that provides a health app to a provider's patients, a cloud service provider that stores electronic PHI, and the vendor of an app that provides transcription to a physician.
• A contract comes first. A covered entity may share PHI with a business associate only with a business associate agreement in place. The BAA must describe the permitted uses and disclosures, and bar any use beyond those or what the law requires. Under the Security Rule it must also have the vendor report security incidents, including breaches of unsecured PHI.
• The chain goes all the way down. A business associate must sign a BAA with each subcontractor before passing PHI to it. For an AI system that means the cloud host and the model provider. HHS's cloud guidance says a provider that stores encrypted PHI is a business associate even if it holds no key.
• The vendor is liable in its own right. HHS's fact sheet lists what a business associate answers for directly, including Security Rule compliance, breach notification to the covered entity, impermissible uses and disclosures, the minimum necessary standard and BAAs with subcontractors.
• Safeguards, not a product list. The Security Rule requires reasonable and appropriate administrative, physical and technical safeguards, starting with an accurate and thorough risk analysis. It names access control, audit controls, authentication and transmission security. It does not dictate specific security measures.
• There is no certificate. AWS states that there is no HIPAA certification for a cloud service provider. A vendor's claim to be HIPAA compliant is a claim about how it builds and operates.

Ask any AI vendor four questions. Will you sign a BAA before any data moves? Which subcontractors see PHI, and do you hold a BAA with each? Where are the access logs, and can we read them? What data do you develop and test on? Our guide to HIPAA compliant AI has the longer checklist.

Where the clinical line sits

Software that helps diagnose or recommends treatment can be a medical device. FDA's final guidance on clinical decision support software, issued in January 2026, sets out which decision-support functions fall outside the device definition. If a tool you are considering scores risk, suggests a diagnosis or ranks patients by urgency, read that guidance with regulatory counsel before anyone builds. Every use case in this guide stays on the administrative side on purpose.

What AI needs before it works

• An EHR and practice management system the agent can reach. An API, or an integration bridge. See EHR integration for how we connect them.
• BAAs at every hop. The host, the model provider, the messaging vendor and us.
• Written rules. Scheduling rules, escalation rules and what counts as a clinical question.
• A review queue with a person on it. Our guide to human-in-the-loop for AI agents covers where to put the checkpoints.
• Synthetic data and a test set. We develop against synthetic data, not your PHI, and measure accuracy on real, reviewed cases before launch and after every change.
• An audit log. Every read and write recorded, so you can answer a patient's or a regulator's question.

The risks, and how to contain them

• A wrong answer that sounds right. Answers come from your record and your policies. If the data is missing, the agent says so and hands over.
• Clinical drift. A scheduling agent starts answering symptom questions. Define the boundary in writing, test for it and route anything clinical to staff.
• PHI in the wrong place. Prompts and logs hold patient data. Keep them inside BAA-covered systems, limit access to the minimum necessary and set retention.
• Wrong chart. Match patients on more than a name before any write.
• Access for everyone. Voice, plain language and a route to a person for patients who cannot or will not use a bot.
• Model and vendor changes. Models are updated on the vendor's schedule. Re-run the test set whenever they are.

Where to start

Pick the workflow with the most volume and the clearest rules, usually intake or the phone queue. Check what your EHR already ships and switch that on first. Build when the built-in version does not fit your process or the work crosses several systems. Buy scribes and inbox drafting; build the parts that connect your own systems.

Where Gigabit fits

• One workflow, such as intake or reminders: the AI Quick Win Sprint is $8,000 fixed over 3 weeks, with integration to up to three tools, error handling and 30 days of light support.
• A production agent for intake or the front desk: Gigabit Agents start at $8,000, flat per agent, with a BAA signed before work starts and an evaluation set and audit log included.
• Not sure where to start: the AI Transformation Sprint is $25,000 over 2 weeks and ends in a scoped pilot. The fee credits toward an agent build.
• A patient app or telehealth platform underneath: healthcare app development, quoted as a fixed price in writing. Our published telehealth platform cost its client $124,000 over 5 months.
• After launch: Managed AI Operations runs $3,000–$20,000 a month, by the number of systems.

We do not build software that diagnoses or treats, and we claim no certification we do not hold. Our healthcare page lists what is in place.