Artificial Intelligence in Transforming Healthcare Delivery

What is artificial intelligence in healthcare delivery?

Artificial intelligence in healthcare delivery is the use of models on named clinical and administrative jobs, such as visit notes, triage queues, outreach lists or claim coding, where a responsible person accepts, edits or rejects each output. Delivery changes when that job gets faster or more accurate, not when a model is licensed.

Which care delivery jobs can AI take on today?

AI can take on drafting, sorting and summarizing jobs today, as long as a person reviews the output. Jobs that decide care on their own are not ready. The map below sorts delivery jobs by how much review they need.

• Access: Drafting replies to portal messages, sorting referral queues and suggesting appointment types. Ready with a reviewer, because a scheduler or nurse already owns each queue.
• Documentation: Drafting visit notes, discharge summaries and referral letters from audio or the chart. Ready with clinician sign-off on every note.
• Care management: Ranking patients for outreach and drafting outreach messages. Ready as support, provided the care team can see why a patient was ranked and can override the list.
• Revenue cycle: Suggesting codes, drafting prior authorization packets and sorting denials by cause. Ready with a coder or biller who accepts each item.
• Operations: Forecasting bed demand, staffing need or no-show risk. Ready as a planning input that managers act on.
• Clinical decisions: Risk scores, diagnostic suggestions and image findings. Support only, and some of these are FDA-regulated device functions.
• Not ready: Autonomous diagnosis, automated denial of care or coverage, and any write to the chart with no named person accepting it.

Rules that follow AI into care delivery

No single AI law governs care delivery. Instead, existing health rules attach to the job the model performs, and each job can pull in a different one.

• Nondiscrimination: Under Section 1557, 45 CFR 92.210 bars covered entities from discriminating through patient care decision support tools, and since 1 May 2025 requires reasonable efforts to identify tools whose inputs measure race, color, national origin, sex, age or disability and to mitigate the risk.
• Device status: Section 520(o)(1)(E) of the FD&C Act, explained in FDA's Clinical Decision Support Software guidance (January 2026), sets four criteria a recommendation tool must meet to fall outside the device definition, including that the clinician can independently review the basis.
• Prior authorization timing: CMS-0057-F requires impacted payers, such as Medicare Advantage organizations and state Medicaid programs, to decide prior authorization requests within 72 hours for expedited and 7 calendar days for standard requests from 1 January 2026, which puts a clock on any AI that drafts or routes those requests.
• Hosting: HHS guidance on HIPAA and cloud computing treats a cloud provider that stores ePHI for a covered entity as a business associate, so the model host needs a business associate agreement.
• Risk management: NIST AI 100-1, the AI Risk Management Framework published in January 2023, is voluntary, and it asks organizations to establish the context of use before they measure risk.

How do you pick the first delivery job?

Pick the job where a reviewer already exists, the data is reachable and an error is caught before it reaches a patient. This scorecard ranks candidate jobs. A job that fails any of the first three items waits.

• Reviewer: A named role already owns the job and can accept or reject each output without a new hire.
• Data access: The inputs can be read through an API or feed today, not after an integration project.
• Error catch: A wrong output is visible to the reviewer before it changes the chart, the claim or a patient message.
• Baseline: Current time, error rate or backlog for the job is measured, so the pilot has something to beat.
• Volume: The job repeats often enough that time saved per item adds up to a visible change.
• Contract path: The model host will sign a business associate agreement and agree terms on retention and training use.
• Device check: The intended use has been read against FDA's CDS criteria, and the answer is written down.
• Fairness check: If the output ranks or scores patients, the inputs have been reviewed under 45 CFR 92.210.

What a first pilot plan contains

• 1. Job statement: One job, one site, one data class, written in a sentence the reviewer agrees with.
• 2. Baseline: The current measure for the job, taken over a period long enough to show normal variation.
• 3. Evaluation set: A fixed sample of past cases with reviewed answers, scored before launch and after every model or prompt change.
• 4. Reviewer roster: The named people who will review outputs, the hours they have for it, and who covers when they are away.
• 5. Vendor terms: Business associate agreements, retention limits and a clause on whether prompts may be used for model training.
• 6. Exit bar: The written conditions under which the pilot widens, is reworked or is retired.

A plan with these six parts fits on two pages. If a part cannot be written yet, that gap is the first piece of work, ahead of any model call.

What does the reviewer workflow look like?

The reviewer workflow is a queue where each AI output waits until a named person accepts, edits or rejects it. The design of that queue decides whether review is real or a formality.

• Draft label: Every output is marked as a draft in the interface and in the data, so it is never mistaken for a final record.
• Source view: The reviewer sees the inputs behind the output, such as the transcript, the chart excerpt or the claim lines.
• Three actions: Accept, edit or reject, with a short reason required for rejects so the team learns what failed.
• Audit fields: Model identifier, prompt or configuration version, reviewer, action and time are stored with each decision.
• Escalation: Outputs the reviewer cannot judge go to a named second reviewer, not back into the general queue.
• Fallback: When the model is down or turned off, the job runs the old way without data loss.

Review time is a cost line in its own right. If reviewers spend as long checking a draft as they would have spent doing the job, the feature has not changed delivery.

How does the AI feature connect to the record?

The feature reads through standard APIs and writes only through paths the EHR vendor supports, after review. Read and write are separate problems with separate interfaces.

• Reading: Certified EHRs expose a read API under 45 CFR 170.315(g)(10) that returns USCDI data through US Core profiles, SMART App Launch and Bulk Data.
• Writing: The (g)(10) API does not give apps write access, so accepted output is filed through the EHR vendor's own write APIs or an HL7 v2 interface.
• Identity and roles: The feature acts with the same role and permissions as the person who accepts its output, not with a broad service account.
• Minimum necessary: The HIPAA Privacy Rule minimum necessary standard (45 CFR 164.502(b)) limits most uses and disclosures of PHI to what the purpose needs, with exceptions such as disclosures for treatment, so prompts carry only the fields the job needs.
• Logging: Each read, prompt, output and write is logged so a single encounter can be traced end to end.

Signs a delivery AI pilot should stop

A pilot needs a written exit bar before it starts. These are the signals that the feature should be paused, reworked or retired.

• Wrong-patient or wrong-chart events: Any output filed against the wrong person stops the pilot until the cause is fixed.
• Rising edit rate: Reviewers change more of each output over time, which points to drift in inputs or the model.
• Rubber-stamp review: Accept rates near total with very short review times suggest nobody is reading the output.
• Unequal performance: Error rates differ across patient groups in a way the team cannot explain or correct.
• No change in the baseline: Time, backlog or error rate for the job has not moved after the agreed pilot period.
• Contract gaps: The model host changes retention or training terms, or a new vendor joins the data path without an agreement.

How Agnotic can help

Moving one delivery job from manual work to reviewed AI output is a software project with a model inside it, and Agnotic Technologies builds that software for providers, payers and digital health companies. Agnotic engineers scope the job against the scorecard above, build the model path and reviewer queue, connect the EHR through read APIs and supported write paths, and set up the logging and metrics that show whether the job changed.

When the first job proves out, the same queue, audit fields and record connection carry over to the next one, so each later job costs less to stand up than the first.

Sources

• 45 CFR 92.210: Nondiscrimination in the use of patient care decision support tools
• FDA: Clinical Decision Support Software guidance (January 2026)
• CMS: Interoperability and Prior Authorization final rule (CMS-0057-F) fact sheet
• HHS: Guidance on HIPAA and cloud computing
• NIST: AI Risk Management Framework (AI 100-1)
• ASTP/ONC: 170.315(g)(10) Standardized API for patient and population services
• 45 CFR 164.502(b): Minimum necessary standard