AI for hospitals works best when it is sorted by risk. The lowest-risk and most common uses are administrative: coding support, prior authorization packets, patient letters, scheduling and intake, staff questions about policies and procedures, and revenue cycle denials. Clinical documentation support comes next, and decision support sits at the top, always with a clinician reviewing the output. HIPAA, the Section 1557 rule on patient care decision support tools, ONC certification rules, Joint Commission guidance and state laws decide what each tier needs, which is why many hospitals run these models behind their own firewall.
AI for hospitals in 2026: how it is used today
Ask a hospital CIO where AI is live and the answer rarely starts with diagnosis. It starts with the back office: the coding queue, the prior authorization backlog, the denial worklist and the policy binder nobody can search. These jobs involve large volumes of text, clear rules and a person who already checks the work, which makes them a good match for language models.
Clinical use is growing, but more slowly and with more review. A model that drafts a discharge summary for a physician to edit carries different risk from one that suggests a diagnosis, and both differ from a chatbot answering a patient at midnight.
This guide sorts hospital AI into three tiers by the harm a wrong answer could cause, then covers the rules that apply and the deployment choices that follow. Regulatory sources were read on regulators’ and standards bodies’ own sites on 25 October 2026.
| Tier | Typical tasks | Who checks the output | Main rules in play |
|---|---|---|---|
| 1. Administrative | Coding support, prior authorization packets, patient letters, scheduling and intake, policy Q&A, denial appeals | Coders, access staff, revenue cycle analysts | HIPAA, payer rules, state disclosure laws for patient messages |
| 2. Documentation support | Chart summaries, discharge summary drafts, referral letters, handover notes | The treating clinician | HIPAA, medical records standards, state AI laws |
| 3. Decision support | Risk flags, guideline reminders, differential suggestions | A licensed clinician before any care decision | Section 1557 (45 CFR 92.210), ONC certification, FDA device rules where they apply |
Tier 1: AI for hospital administration
Administrative work is where most hospitals start, because the output is a draft that an experienced employee already reviews.
Coding support
A model can read a closed encounter and propose ICD-10 and CPT codes with the passage of the note that supports each one. The coder accepts, edits or rejects every suggestion. The useful version flags documentation gaps, such as a diagnosis mentioned in the assessment with no supporting findings, so the coder can raise a query with the physician before the claim goes out. The medical coding validation use case shows that review loop.
Prior authorization packets
Assembling a prior authorization request means pulling the order, relevant notes, imaging and lab results, prior treatments and the payer’s medical policy into one package. An agent can gather those pieces and draft the cover letter, leaving staff to verify and submit. The timing matters more now: under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), Medicare Advantage, Medicaid and CHIP programs and their managed care plans must answer expedited requests within 72 hours and standard requests within seven days from 1 January 2026, and must offer a Prior Authorization API from 1 January 2027. A complete first submission avoids the back-and-forth that eats into those windows.
Patient letters and messages
Appointment reminders, pre-procedure instructions, results letters in plain language and replies to portal messages are all drafting tasks. Administrative messages carry little clinical risk. Messages that contain clinical information are different, as the state law section below explains.
Scheduling and intake
Referral faxes, web forms and call notes arrive in every format. A model can extract the patient details, reason for referral, urgency and insurance information, then route the request to the right clinic queue. The patient intake and scheduling use case walks through that triage step.
Policy and procedure questions from staff
Hospitals keep hundreds of policies on infection control, consent, restraints, medication administration and escalation. A nurse at 3 a.m. needs the current version of one paragraph, not a search result list. Retrieval over the approved policy library, returning the passage and its revision date, answers that need without touching patient data at all, which makes it one of the safest first projects.
Revenue cycle denials
Denial work is repetitive reading: the remittance advice, the claim, the record and the payer policy. An agent can group denials by reason, pull the supporting documentation and draft the appeal letter for an analyst to finish. Measure it on overturn rate and analyst time per appeal, not on letters produced. The operational efficiency use case and our walk-through of agents for administrative healthcare workflows cover these patterns in more depth.
Tier 2: Clinical documentation support
The second tier drafts clinical text for a clinician to own. Typical tasks include summarising a long admission before a handover, drafting the discharge summary from the record, writing a referral letter, or condensing outside records that arrived as a 200-page PDF.
Three habits keep this tier safe:
- Every statement links to the source. A summary sentence about a medication change should point to the order or note it came from, so the clinician can check it in one click.
- The clinician signs, not the model. The draft enters the record only after a named clinician has reviewed and accepted it.
- Omissions get as much attention as errors. Summaries fail quietly by leaving things out. Review checklists should ask what is missing, such as allergies, pending results or code status.
A note on ambient scribes. Tools that listen to the patient visit and write the note are a separate product category with their own vendors, consent questions and evaluation literature. VDF AI does not provide ambient scribing, and this guide does not assess those products.
Tier 3: Decision support with clinician review
Decision support surfaces information during care: a sepsis risk flag, a reminder that a guideline recommends a test, a list of possible diagnoses for a complex presentation. This is the tier where federal civil rights law, health IT certification rules and, for some software, FDA device regulation apply directly.
Section 1557 and patient care decision support tools. HHS’s 2024 Section 1557 final rule added 45 CFR 92.210. It prohibits discrimination on the basis of race, color, national origin, sex, age or disability through the use of patient care decision support tools, which the rule defines broadly as any automated or non-automated tool used to support clinical decision-making. Covered entities have an ongoing duty to make reasonable efforts to identify tools that use those characteristics as inputs and to mitigate the resulting risk of discrimination. The identification and mitigation duties applied 300 days after the rule took effect on 5 July 2024, which was 1 May 2025.
In practice that means an inventory of every clinical score, calculator and model in use, a note of which inputs measure a protected characteristic, and a documented review of each. Scoring tools that adjust for race or sex belong on that list alongside newer machine learning models.
Texas SB 1188. Since 1 September 2025, Texas has allowed practitioners to use AI for diagnostic purposes, including recommendations on diagnosis or treatment, only if they act within their licence, the use is not otherwise prohibited, and they review all AI-created records under Texas Medical Board standards. Practitioners must also disclose that use to patients.
The common thread is that a licensed clinician stays responsible. A decision support tool proposes; the clinician decides and documents why.
AI governance for hospitals in 2026
The rules come from several directions. None of them bans AI; all of them expect the hospital to know where it is used and to control it.
HIPAA and business associate agreements
Any vendor that creates, receives, maintains or transmits PHI on the hospital’s behalf is a business associate under 45 CFR 160.103 and needs a business associate agreement. HHS’s cloud computing guidance adds that encryption does not change this: a cloud provider holding only encrypted ePHI, without the key, is still a business associate. For AI, that covers model APIs, transcription services, vector databases and logging tools if PHI passes through them. HHS proposed a substantial update to the HIPAA Security Rule in January 2025; as of 25 October 2026 no final rule has been published, so the existing Security Rule still applies. Our guide to HIPAA compliant LLM options lists which model APIs sign a BAA.
ONC decision support interventions
The ONC HTI-1 final rule replaced the old clinical decision support certification criterion with decision support interventions at 45 CFR 170.315(b)(11). Certified EHR developers must let users select evidence-based and predictive interventions and, for predictive ones, expose source attributes such as intended use, training data and fairness testing, and apply intervention risk management practices. In December 2025 ASTP/ONC published the HTI-5 proposed rule, which would remove the source attribute and risk management requirements while keeping a revised criterion. Comments closed on 27 February 2026 and no final rule had appeared in the Federal Register by 25 October 2026. Hospitals that relied on vendor model information for their own reviews should plan to collect it through contracts if the requirement goes.
Joint Commission and CHAI
On 17 September 2025 the Joint Commission and the Coalition for Health AI published the Guidance on the Responsible Use of AI in Healthcare. It names seven elements: AI policies and governance structures, patient privacy and transparency, data security and data use protections, ongoing quality monitoring, voluntary blinded reporting of AI safety events, risk and bias assessment, and education and training. On 1 June 2026 the Joint Commission launched a voluntary Responsible Use of AI in Healthcare certification built on that work. It assesses how an organization governs AI, does not certify individual products, and is open to organizations that are not Joint Commission accredited.
State laws
California AB 3030, in force since 1 January 2025, requires hospitals, clinics and physician offices that use generative AI to write messages containing patient clinical information to include a disclaimer and clear instructions for reaching a human. Messages read and reviewed by a licensed or certified provider are exempt, and administrative messages about scheduling or billing fall outside it. Texas SB 1188 adds the diagnostic AI conditions above and, from 1 January 2026, requires electronic health records under a covered entity’s control to be physically maintained in the United States, including records held by cloud providers. Other states are legislating too, so compliance teams should track the states where they treat patients.
Why hospitals run AI behind their own firewall
Cloud AI is a reasonable choice for many hospital tasks, especially policy search and administrative drafting with no PHI. Several hospital-specific reasons still push sensitive workloads onto infrastructure the hospital controls.
PHI and the vendor chain. Every service that touches PHI needs a BAA, a security review and a place in the breach response plan. A model running inside the hospital network keeps prompts, retrieved chart passages and outputs in systems the security team already monitors, and removes one link from that chain.
Data residency. Texas now requires EHR data to stay in the United States, and hospital systems with international affiliates face their own transfer rules. Local deployment answers the residency question by design.
Latency inside clinical workflows. A summary that takes 40 seconds to appear will not be used during a busy shift. Models running on servers in the same data centre as the EHR avoid internet round trips and shared-tenant queues.
Downtime. Hospitals rehearse EHR downtime because care cannot stop. A tool that depends on an outside API fails whenever the internet link or the provider does, and it should either be listed in downtime procedures or run where the hospital controls its availability.
Predictable cost. Per-token pricing makes heavy summarisation and coding workloads hard to budget. Fixed hardware with open-weight models turns that into a capacity planning question. The CIO and CISO guide to private AI in healthcare covers the architecture choices in more detail.
Choosing AI software for hospitals
The options fall into three groups, and most hospitals end up using more than one.
EHR-native assistants. EHR vendors now build AI features into their products. They sit inside the clinician’s workflow and the vendor already holds a BAA, which makes them the easiest route for tasks that start and end in the record. Ask how the vendor will document each model under the decision support interventions criterion, and what happens to that documentation if HTI-5 is finalised.
Point solutions. Single-purpose tools for coding, prior authorization, denials or patient messaging can move quickly. Each one is another vendor holding PHI, another login and another audit log to collect.
A private AI platform. A platform installed on the hospital’s own infrastructure can serve many tasks from one governed place: policy Q&A, letters, prior authorization packets and appeals, with shared identity, permissions and logging. It requires more internal ownership than buying a point solution.
Questions to ask any vendor:
- Where is PHI processed and stored, including logs, caches and conversation history?
- Will you sign a BAA, and which subcontractors process our data?
- Can we restrict which staff roles see which data sources?
- Does every answer cite the document or record it came from?
- Can we export a full audit trail of prompts, sources, model versions and outputs?
- What happens to the tool during an internet or vendor outage?
| Workflow | Touches PHI? | Typical deployment |
|---|---|---|
| Policy and procedure Q&A for staff | No | Cloud or on-premises |
| Scheduling and intake triage | Yes | On-premises, or cloud under a BAA |
| Coding support | Yes | On-premises, EHR-native or cloud under a BAA |
| Prior authorization packets | Yes | On-premises or cloud under a BAA |
| Denial appeals | Yes | On-premises or cloud under a BAA |
| Patient letters with clinical content | Yes | Any, with clinician review or AB 3030-style disclosure where required |
| Discharge summary drafts | Yes | EHR-native or on-premises, close to the record |
| Decision support | Yes | EHR-native or on-premises, inside the 92.210 inventory |
How VDF AI fits a hospital
Hospitals deploy VDF AI on servers in their own data centre, inside a private cloud tenancy, or on a network with no internet connection at all. With local models only, prompts, retrieved chart passages, policy documents, indexes, conversation history and logs never leave the hospital’s environment for a third-party model service. It is not a medical device. It has no FDA clearance, HITRUST certification or other approval of its own, and it operates within the hospital’s existing HIPAA and governance program.
The administrative tier maps directly onto the platform. A policy assistant can answer from the approved policy library with each passage and its revision date shown. Permission-aware retrieval keeps the revenue cycle team’s collections separate from clinical ones, so a scheduler never retrieves a psychiatry note. Governed agents can assemble prior authorization packets or draft denial appeals with tool access granted per role and an approval step before anything leaves the building, and each run records the requesting user, the model used, the passages retrieved and the tools called. Clinical documentation drafts follow the same pattern, with the clinician as the approver. VDF AI does not record or transcribe patient visits.
Models are managed in the VDF AI Router: the hospital registers open-weight models running on Ollama, vLLM or any OpenAI-compatible server, and can admit a cloud model for non-PHI tasks only if its policy says so. Clinicians and staff sign in with Microsoft Entra ID, which the platform supports natively on-premises; hospitals on Okta, Keycloak or another SAML or OIDC provider put an SSO-aware reverse proxy in front. Role-based access control comes with every plan rather than as an add-on. A hospital can run its first workflow under a three-month on-premises platform trial before committing to a seat bundle.
The healthcare and life sciences solution explains the wider deployment, the healthcare AI use case library lists more workflows, and the healthcare executive brief summarises the case for leadership. Before scoping a first project, the free AI readiness assessment helps a hospital see where data access, governance or staffing could hold it back. Nothing here is legal or clinical advice for a particular organisation.
Sources
Verified 25 October 2026.
- 45 CFR 92.210, nondiscrimination in the use of patient care decision support tools (Cornell LII)
- HHS, Nondiscrimination in Health Programs and Activities final rule, 89 FR 37522, 6 May 2024 (GovInfo)
- HHS, Guidance on HIPAA and cloud computing
- 45 CFR 160.103, definitions including business associate (Cornell LII)
- HHS, HIPAA Security Rule to Strengthen the Cybersecurity of ePHI, proposed rule, Federal Register, 6 January 2025
- ASTP/ONC, 170.315(b)(11) decision support interventions certification criterion
- ASTP/ONC, HTI-5 proposed rule, 90 FR, 29 December 2025 (GovInfo)
- ASTP/ONC, HTI-5 proposed rule overview
- Joint Commission and CHAI, Guidance on the Responsible Use of AI in Healthcare, September 2025 (PDF)
- Joint Commission, launch of the Responsible Use of AI in Healthcare certification, 1 June 2026
- Medical Board of California, AB 3030 generative AI notification requirements
- Texas Legislature, SB 1188 enrolled text, 89th Legislature
- CMS, Interoperability and Prior Authorization final rule (CMS-0057-F) fact sheet