When the AI Scribe Starts Shaping the Medical Record

An ambient scribe promises to listen while a clinician practices medicine. A more consequential system proposes what the encounter means: a diagnosis, a degree of certainty, a treatment, an order, or a coded condition.

Those functions can coexist inside the same familiar workflow — the phone in the examination room running Epic Haiku, the draft note waiting in Epic, the Dragon Copilot or DAX Copilot output arriving minutes later. They should not be evaluated as though they were the same function.

Public Microsoft documentation describes generating assessment-and-plan diagnoses from ambient recordings, comparing them with Epic encounter diagnoses, and realigning associated plan content. Public Epic documentation describes structured ambient-diagnosis data and a “Heard In Visit Recording” workflow. These are not speculative future capabilities. They are documented elements of contemporary products. They do not, however, establish that any particular implementation autonomously diagnoses patients, changes signed orders, or requires every clinician to reject every unwanted suggestion. [S01, S02, S08]

The question is not whether a computer may help write a note. It is whether everyone who later relies on that note can distinguish what the patient reported, what a clinician concluded, what the software inferred, and what a licensed practitioner actually verified.

A correct-looking note can be unfaithful to the encounter. A faithful note can document a mistaken clinical decision. Safety requires testing both fidelity and clinical correctness — not treating one as a substitute for the other.

What this investigation establishes — and what it does not

This article combines public product documentation, peer-reviewed studies, enacted legislation, official regulatory materials, and clinician reports describing how these workflows behave in practice. Clinician reports are treated as questions to test, not as independently audited product defects; none is attributed to a named organization, and none describes a patient. Clinical examples are synthetic. The diagrams are original analytical illustrations, not vendor engineering drawings.

The central findings are that diagnosis generation and structured diagnostic workflows exist; that available documentation studies do not automatically validate every newer clinical function; and that the final signature cannot be the entire safety strategy. This article does not establish deliberate concealment, unlawful practice, false billing, an inadequately tested deployment at any organization, or a plan to replace physicians.

“Contamination forever” is also too absolute. Records can be corrected. The defensible concern is persistent propagation: an unsupported conclusion may travel through notes, structured data, decisions and external records before someone detects it, while the source needed to reconstruct its origin may have a shorter retention period. Correction is therefore a clinical process, not merely a text-editing command. [S07, S33]

1. One encounter, several systems, different responsibilities

“DAX,” “Dragon Copilot,” “Epic,” “Haiku” and “Heard In Visit” are not interchangeable names for one decision engine.

Nuance DAX Copilot and Microsoft Dragon Copilot are Microsoft product names — Nuance, which built DAX, is a Microsoft company — with changing features and integrations. Epic is the electronic health record environment. Haiku (on smartphones) and Canto (on tablets) are Epic’s clinician-facing mobile applications; Microsoft’s documentation says clinicians “will always use DAX Copilot in Haiku or Canto to create ambient recordings,” with edits transferred to the Epic note through a sync step. Epic configuration, permissions, integrations and note components help determine what happens next. The exact product release, feature flags and organizational settings matter more than a brand-level statement that a hospital or clinic “uses DAX.” [S02, S05, S64]

Epic also markets its own AI for clinicians, Art, which it says “captures conversation during a visit, extracts orders and diagnoses, and drafts the visit note.” That does not establish that every Epic AI function is supplied by Microsoft or enabled in a Microsoft-connected installation. Likewise, Microsoft’s partner ecosystem does not establish that every partner application is active for every customer. [S09, S10]

Figure 1. From recorded encounter to authenticated record

A useful investigation follows the data through separate transitions:

This separation is practical. A clinician may approve a narrative sentence without intending to add a lifelong problem-list entry. A diagnosis may be entered into Epic before the ambient note is generated and then influence that note. An order suggestion may never become an order. Without mapping these transitions, both criticism and reassurance can target the wrong component.

What the public product documents actually say

Microsoft’s diagnosis-retrieval documentation states that “Dragon Copilot and DAX Copilot generate diagnoses for the Assessment and Plan section of the clinical note, based on the ambient recording,” then compares them with diagnoses retrieved from Epic. When the two align, the note uses the Epic diagnoses and the plans are re-aligned; when they do not, the note keeps the Dragon Copilot diagnoses, and an Epic-only diagnosis can appear without an assessment and plan. The feature works with or without diagnosis-aware notes, though Microsoft says the two together improve matching and plan alignment. Its FAQ says that when no Epic visit diagnoses exist, the assessment and plan is based on “the diagnoses said in Dragon Copilot’s ambient recording,” and that a problem-list entry must be promoted to a visit diagnosis to be included. Generation and reconciliation therefore must not be misrepresented as proof that every output is a novel medical judgment. [S01]

Release 3.6 describes diagnosis-aware notes using ambient recording for Dragon Copilot for Epic and DAX Copilot for Epic, with assessment-and-plan information “captured, structured, and sent to Epic.” It requires Epic’s November 2025 base release and Epic Nebula, is configured by the customer’s Epic technical team, and “override[s] custom templates for the Assessment and Plan section” automatically. That makes upgrade-level testing important: a well-tested old template or an older ambient pilot is not necessarily evidence about the new configuration. [S02]

A separate Microsoft diagnosis-specificity feature lets a user accept, dismiss or ignore a suggestion. Its existence is an important counterexample to any overbroad claim that every Microsoft diagnostic suggestion must be acted upon before signing. A different behavior at a particular site could reflect another feature, release, integration or local policy. [S03]

Microsoft’s order documentation calls AI-generated order suggestions “memory aids” and says new orders cannot be created inside DAX Copilot; with integration enabled, suggestions are sent to Epic to be matched to orderable items, and the organization’s own ordering process governs completion. A vendor-generated medication sentence must not be described as a legally executed prescription unless the actual signing and transmission steps are demonstrated. [S04]

Microsoft’s transparency note describes Dragon Copilot as a platform that creates “draft medical documentation,” lists limitations including “omitted findings or hallucinated details,” and states that “all generated content must be reviewed and validated by the clinician before it becomes part of the medical record.” It also states that Dragon Copilot is not intended to be a medical device or “a substitute for professional medical advice, diagnosis, treatment, or judgment.” Those disclosures matter. They are also the vendor’s own account, not independent clinical validation of every feature — and a disclaimer of diagnosis sits uneasily beside a feature that generates diagnoses for the assessment and plan. [S06]

2. The public Epic schema provides a concrete starting point

Epic’s public DOCS_RCVD_DX export specification — a table that “stores discrete diagnosis information received from outside sources” — describes ambient-diagnosis fields, including the following. [S08]

A public schema is not a production audit. It does not establish whether a given organization populates these fields, retains rejection history, exposes it to clinicians, or includes it in a particular export. It does establish that an investigation can ask far more precise questions than “Does Epic save the note?”

The relevant demonstration is a controlled test: generate a synthetic candidate; inspect the displayed text and identifiers; accept, modify or discard it; examine the resulting note, structured fields and permitted event history; then determine which records survive later updates. A ranking field should not be shown to a reviewer as if it were a clinical confidence score unless calibration has actually been established.

The same discipline applies to terminology. A database label containing “diagnosis” does not by itself establish a licensed practitioner’s diagnosis. Conversely, calling something “draft text” does not establish that it has no influence on clinical reasoning or payment.

3. Where documentation can become a new clinical assertion

Useful summarization is not word-for-word copying. A clinician may describe high blood pressure and an appropriate follow-up plan without reciting the exact diagnostic label. Software can reasonably normalize terminology. It may also incorporate an established diagnosis from permitted chart context.

The boundary is crossed when the output materially changes the meaning or status of a clinical assertion: who believes it, whether it is established, whether it is current, whether it concerns this patient, or whether an action was discussed rather than performed.

The following are synthetic test cases, not allegations about actual patients or measured failure rates:

These failures can arise without an obviously absurd hallucination. The most dangerous change may be a plausible sentence with the wrong certainty, speaker or timing.

Two independent dimensions of quality

A useful evaluation separates faithfulness to the encounter from medical appropriateness:

This framework prevents two mistakes. “The AI was right” does not make a false account of what was decided truthful. “The AI accurately captured the conversation” does not establish that the care was medically sound.

A sound product can support both tasks, but the tasks need distinct intended uses, evidence and controls. A documentation assistant should be tested against the clinician’s actual intended record. A diagnostic assistant needs evaluation of diagnostic performance, appropriate uncertainty, evidence use and its effect on real clinical decisions.

4. The rejection-to-sign problem is a testable allegation — not a universal feature finding

Clinician reports reviewed for this investigation describe a workflow in which unwanted diagnostic suggestions cannot simply be bypassed or deleted in bulk: each diagnosis, or diagnosis-and-plan suggestion, must reportedly be rejected individually before the note can be signed. No organization is identified here. The exact controls, labels, release and local configuration have not been independently inspected.

Such reports deserve a technical demonstration. They do not justify declaring that all DAX, Dragon Copilot or Epic implementations operate that way. Nor does a mandatory review step necessarily prove interference with medical judgment: requiring deliberate handling of a candidate might prevent accidental inclusion. The issue is whether the design supports reliable, proportionate review in practice.

Four very different events can otherwise be collapsed into one word — Reject:

A later reviewer — a peer-review committee, a medical board investigator, an expert witness — should not infer a fully considered medical refusal merely from a software event label. At the same time, a clinician cannot assume that labeling an action “documentation cleanup” makes clinically significant warning signs irrelevant. The content, visibility, context, underlying evidence and actual review matter.

A configurable documentation-only route could be valuable. Its availability must be demonstrated, not assumed. A hidden workaround is not equivalent to an approved, supported workflow. Equally, an individual clinician’s unfamiliarity with a control is not proof that the control does not exist.

5. What the published studies do — and do not — validate

The evidence does not support a nationwide conclusion that ambient AI is useless or unsafe. It supports a more specific conclusion: benefits and errors depend on the product, version, user, setting, outcome and review process.

The UC Davis sample was only 4.7% of generated notes. Its potential-severity ratings, and its emphasis on clinician correction, must accompany any quoted percentage. Error categories can overlap and should not be added into a single overall error rate. The study is valuable because it tested a safety question, not because it supplies a universal error estimate. [S16]

This review did not locate a public study that matched all of the following: the current feature and version; independently inferred diagnostic candidates rather than transcription of explicit decisions; linked treatment suggestions; individual rejection as a signature prerequisite; and downstream supervisory concurrence. That is a bounded finding about the public evidence reviewed — not proof that no internal validation occurred.

A hospital’s successful scribe pilot can be relevant evidence. It is not automatically a validation certificate for a later clinical-recommendation feature. Procurement should therefore request feature-specific evidence, with endpoints that match what the organization actually enables.

6. The extra layer in PA supervision: concurrence is not a second encounter

An additional clinician can improve safety, but a second signature is not automatically an independent second assessment.

Consider a general supervisory workflow: a physician assistant conducts an encounter; software drafts or proposes the assessment and plan; the PA reviews and signs; selected charts are routed to a physician for concurrence. The reviewer may see a polished final narrative rather than the original conversation, source context or AI candidates.

The concern is layered reliance: each reviewer may assume an earlier participant established a conclusion. It is not an accusation that PAs fail to think independently. A PA can competently assess a patient, critically review a generated draft and adopt the corrected record as their own.

Figure 2. Layered reliance is not the same as independent verification

California’s practice-agreement framework requires defined services, adequate supervision and ongoing competency evaluation. Business and Professions Code §3502(c) provides that nothing in regulations shall require a physician to review or countersign a medical record “unless required by the practice agreement”; the Physician Assistant Board’s guidance says the same. The agreement and any special conditions therefore matter. [S28, S29, S65]

The operational questions are concrete. Does the attestation mean “reviewed,” “agree with assessment and plan,” “personally examined,” “available for consultation,” or something relevant to billing? Which of those statements is actually true? Does the final note show enough clinical reasoning for the promised review? What happens when concurrence cannot responsibly be given?

These questions existed before AI. AI adds a possible source of interpretation between the encounter and the text being endorsed. It makes clear attestation wording and accessible supporting clinical reasoning more important — not automatically more signatures or routine replay of every recording.

7. The long tail: how an unsupported assertion can outlive its source

A draft can be caught and corrected before it affects anyone. The risk increases when an unsupported assertion is accepted and then reused in other decision contexts.

The following is a foreseeability model, not evidence that each step occurs in every product:

An inferred condition enters a signed note. A downstream workflow treats it as a documented diagnosis. Another clinician sees it in a summary. A later note repeats it. A code or risk-adjustment submission is generated. A new AI tool retrieves the old statement as context. Repetition starts to resemble corroboration, even when every copy traces back to one unverified origin.

Figure 3. The long tail of an unsupported assertion

The corresponding failure is not simply hallucination. It is loss of provenance: recipients cannot reliably distinguish an independently supported conclusion from a copied assertion. Federal inspectors flagged audit-log and copy-and-paste safeguards in electronic health records more than a decade before the current generation of ambient AI. That history is an analogy, not proof of present vendor misconduct. [S50]

There is a further asymmetry. Microsoft’s public FAQ states that Dragon Copilot “retains audio, recognized text, transcript, and flowsheet value data for up to 90 days,” and that data are “deidentified or pseudonymized for AI model improvement”; the applicable contract and configuration must be checked. A long-lived clinical record may therefore outlast a source artifact needed to explain its creation. One cannot assume that audio, transcript, draft and final note share one retention schedule. [S07]

HIPAA permits qualifying requests to amend information in a designated record set, with procedures for linking amendments and notifying relevant recipients when applicable. It does not promise a universal eraser for all downstream copies. That is why the right formulation is “persistent and difficult to unwind,” not “permanently uncorrectable.” [S33]

A correction plan should ask which nodes were affected: note, encounter diagnosis, problem list, order, after-visit instructions, claim, external exchange, patient portal and analytic feed. The correction should be traceable and should not fabricate a new version of history. An accurate amendment explains what changed and when; it does not silently rewrite an earlier encounter.

8. The commercial argument is broader than saving keystrokes

It is no longer necessary to speculate that vendors see value beyond transcription. Microsoft’s October 2025 and March 2026 announcements describe revenue-cycle management, workflow automation, clinical insights, decision support and partner extensibility. These are disclosed commercial ambitions — not evidence of a secret agreement, and not proof that every announced capability is active anywhere in particular. [S10, S11]

The executive case can be legitimate: less after-hours work, better retention, more accessible appointments, more complete documentation and fewer administrative handoffs. The physician’s objection can also be legitimate: an additional recommendation layer may impose verification work that the original scribe did not.

The appropriate local calculation is:

The second term should include setup, consent tasks where applicable, review, source checking, diagnosis and plan reconciliation, rejection clicks, correction, re-dictation, authentication and downstream cleanup. This is a proposed accounting framework, not a measured DAX result. It also needs patient-mix adjustment and a check that apparent speed does not reflect less careful review.

A shorter first-draft generation time is not the same outcome as a shorter safely completed encounter. More visits are not an automatic or necessary consequence of documentation savings. A proposal to increase scheduling or change physician-to-advanced-practice staffing should have its own clinical justification and evaluation.

The workforce concern deserves examination, but not a fabricated conclusion. No evidence reviewed here establishes any employer’s plan to remove physicians. The policy question is whether an organization could reduce direct physician participation while retaining physician signatures as its main risk control. Measuring supervisory time, consultation access, diagnostic outcomes and clinician workload would be more informative than speculating about motives.

9. California’s January 2027 framework: important, but not a blanket AI prohibition

The analysis must distinguish enacted law, future effective dates, professional guidance and proposals that failed. Ordinary California regular-session statutes take effect on January 1 following enactment unless a different provision controls. The following chaptered 2026 statutes are relevant to January 1, 2027 planning. Enacted text was examined through legislative mirrors and bill histories, with enactment and veto status corroborated against official records. [S18–S21, S59, S66]

AB 1979: independent judgment and the documentation boundary

Chapter 854, Statutes of 2026 (approved September 30, 2026), adds Business and Professions Code §22758.5 (“AI Clinical Decision Support”). A health facility, clinic, physician’s office or group-practice office must take reasonable steps so that a licensee “retains the ability to exercise independent professional judgment” when care is informed by AI clinical decision support. Covered entities may not use AI to “independently perform any clinical function that is required by law to be performed by a person with a professional license,” or to direct, guide, supervise or instruct unlicensed personnel as the section specifies. [S18]

The exception is narrow and should be quoted exactly: the section “does not apply to the use of automated decision systems for documentation and communication that does not involve the application of professional judgment,” with examples such as automated messages about record updates, reminders, and helping patients find information at their request. [S18]

That makes function-level classification decisive. A named-diagnosis field is not conclusive; neither is the product label “scribe.” What input is analyzed, what recommendation is produced, how it informs care and what the clinician actually controls must be examined. A transcription that faithfully records a clinician’s decision looks like documentation. A system that proposes a diagnosis the clinician did not state, and links a treatment plan to it, is harder to describe as documentation that “does not involve the application of professional judgment.”

The law does not expressly guarantee every clinician a chosen software platform, an individual sandbox, a universal bypass button or immunity from liability. A review gate may support independence or undermine it, depending on how it operates. No grandfathering provision was identified for continued covered use simply because deployment began before January. That is different from retroactively treating pre-2027 conduct as a violation of a future duty.

SB 503: bias-related duties for both developers and deployers

Chapter 857, Statutes of 2026 (approved September 30, 2026), adds §22758. Developers and deployers must make reasonable efforts to identify systems that carry a risk of biased impacts; developers must make reasonable efforts to mitigate known or reasonably foreseeable risks and give deployers a statement of intended uses and known or reasonably foreseeable risks, with documentation, “upon request or at the time of initial sale, whichever is earlier.” Deployers must regularly monitor and take reasonable and proportionate steps to mitigate. Compliance is not a defense to a claim of unlawful discrimination. [S19]

AB 1637: responsibility for physician notes, with exceptions

Chapter 536, Statutes of 2026 (approved September 27, 2026), adds §2266.1. It defines patient notes as “notes, after-visit summaries, and diagnosis and treatment plans,” makes them the responsibility of the authoring physician “regardless of the clinical setting,” and bars alteration by anyone other than the authoring physician, subject to three exceptions: a scribe, medical assistant or other authorized individual acting under authority the authoring physician delegated; a physician to whom care has been transferred, who may add to — not edit — the notes; and a supervising physician of a postgraduate trainee. [S20]

The section does not mention artificial intelligence. It is therefore not a categorical AI rule, and it should not be applied indiscriminately to PA-authored records. But its definition reaches “diagnosis and treatment plans” — precisely the content that diagnosis-aware ambient features generate. Implementation teams should ask a question the statute makes unavoidable: who is the author of an assessment and plan that software drafted and a physician adopted, and who, if anyone, may change it afterward?

Existing duties and limits on claimed protection

California already regulates accurate records, professional practice, confidentiality and electronic-record integrity. Civil Code §56.101 addresses preservation of electronic information and records of changes and deletions; that does not automatically mandate retaining every model intermediate or every raw recording. The Medical Board’s AB 3030 guidance concerns patient-facing clinical communications generated by generative AI, with an exception for communications read and reviewed by a licensed or certified provider; it is not the same thing as consent to record a visit. [S30, S57, S22]

AB 2575 was vetoed on September 30, 2026. It must not be cited as an enacted AI-override protection. Existing whistleblower rules may protect qualifying reasonable-belief disclosures, but not every software disagreement or every refusal to use an employer-selected system. Employment protection, clinical discretion, malpractice liability and professional discipline remain separate questions. [S21, S48, S66]

A pre-January rollout is not proof of evasion. A defensible inquiry requests the compliance assessment, approval chronology and changes planned for continued covered use — not an unsupported accusation about intent.

Existing medical-practice and physician-advocacy law still matters

California’s corporate-practice guidance concerns improper interference with professional medical judgment, not a categorical prohibition on employer-selected software. Entity-specific exceptions, the clinician’s scope and the actual exercise of control matter. A PA acting lawfully within authorized practice is not an unlicensed person simply because the practitioner is not a physician. Whether an AI workflow unlawfully substitutes for licensed judgment requires substantially more than showing that a candidate diagnosis appeared on a screen. [S62]

Business and Professions Code §2056 addresses qualifying physician advocacy for medically appropriate care; Labor Code §1102.5 may protect disclosures that meet its legal requirements. These provisions should be evaluated separately from a right to choose a preferred interface. Neither makes every software complaint protected, excuses unsafe documentation, or prevents otherwise lawful professional review. [S48, S63]

10. North Carolina illustrates the accountability dilemma — not a presumption that AI is right

North Carolina Medical Board position statement 3.2.1, on medical records, asks licensees to ensure that notes are accurate, “particularly in those instances where medical records are generated with the assistance of dictation software or artificial intelligence.” Its AI discussion is more pointed: “Once a licensee chooses to use AI, they accept responsibility for responding appropriately to the AI’s recommendations.” A licensee who follows a recommendation “should be prepared to provide a rationale for why they made that decision”; one who departs from it “should document the rationale behind the deviation and be prepared to defend the course of action.” The statement adds that simply implementing the recommendations “without a corresponding rationale may not be within the standard of care.” [S17]

The statement was adopted in 2018 and has been amended several times since, most recently in 2026; the amendment history alone does not show when each AI sentence first appeared. It is professional guidance, not a statute, and it does not bind California physicians. [S17]

The difficult policy question is how that approach applies to unsolicited software candidates. The North Carolina text begins with a licensee who “chooses to use AI.” An optional request for diagnostic advice differs from a mandatory interface that generates suggestions during ordinary documentation. Discarding a duplicate or unsupported draft differs from declining a clinically relevant recommendation after evaluating it. And the asymmetry matters: deviation must be documented, while following must merely be defensible — a structure that, applied mechanically to dozens of unsolicited candidates, could make rejection more burdensome than acceptance.

A board should ask what the clinician actually saw, what it represented, what supporting facts were available and whether the chosen care met professional standards. It should not treat software text as presumptively correct, or a “Reject” event as a complete record of clinical reasoning.

The reverse caution is equally important. The mere fact that a warning arrived through software does not make clinically material evidence irrelevant. A physician cannot establish reasonable care just by saying, “I did not ask for that suggestion.” Context and professional judgment remain decisive.

The American Medical Association’s October 29, 2026 framework on liability for clinical AI states that “responsibility should reflect each party’s authority, access to information and ability to prevent or mitigate harm.” The Federation of State Medical Boards announced a workgroup on May 19, 2026 charged with a report and recommendations or model guidelines on regulating AI in medical practice. These are significant policy developments, not statutory immunity or a single national licensing regime. [S26, S27]

11. Federal regulation: a signature and a disclaimer do not answer every question

FDA: evaluate the function, not the logo

FDA’s clinical-decision-support guidance, issued in final form in January 2026, applies a function-level analysis of the statutory non-device CDS criteria. One central issue is whether the software enables a health care professional “to independently review the basis” for a recommendation, so that the professional does not rely primarily on it. Intended use, input, output, urgency and the information available to the user all matter. The guidance also addresses automation bias — “the propensity of humans to over-rely on a suggestion from an automated system.” [S24]

A software disclaimer is relevant to intended use but is not a product-specific FDA determination. Conversely, generating clinical text does not automatically make a function a regulated device. A responsible classification analysis must consider all applicable statutory criteria and other exclusions; it cannot be resolved by declaring either “AI diagnoses, therefore illegal” or “a human signs, therefore exempt.” The ability to review the basis of a recommendation is also not the same as the ability to press Reject.

ONC certification is a different — and shrinking — framework

The federal decision-support certification criterion at 45 CFR §170.315(b)(11) has required certified health IT to support specified source attributes and intervention risk management for predictive decision-support interventions supplied as part of certified health IT. It was never blanket clinical validation of every third-party tool connected to a certified EHR, and it is not FDA clearance. [S25]

Implementation teams should identify which component falls within a certified module, who supplies the intervention, what source information is available, and whether a separate integrated function falls outside that obligation altogether. “Epic is certified” is not a complete answer to the safety of a particular AI-generated plan.

Privacy, recording and secondary use are separate approvals

HIPAA business-associate arrangements and risk analysis govern handling of protected information in covered cloud workflows. They do not prove clinical accuracy. California’s confidential-communication recording law raises a distinct consent inquiry, including applicable exceptions and interstate issues. A general treatment consent, a business associate agreement and an AI-disclosure notice should not be treated as interchangeable permissions. [S31, S56]

The data-governance questions include permitted secondary uses, subprocessors, human access, residency, cross-border support, deletion, model improvement and incident response. Pseudonymization is not automatically HIPAA de-identification. Substance-use treatment records can implicate 42 CFR Part 2, whose revised-rule compliance date was February 16, 2026. These protections depend on the records and program, not merely on the presence of a sensitive word. [S32, S34]

Section 1557’s patient-care decision-support-tool provision, 45 CFR §92.210, adds a discrimination analysis. HHS announced on June 1, 2026 that a court had vacated specified provisions of the 2024 rule to the extent they expanded the definition of sex discrimination to gender identity; HHS stated that the rule’s other provisions remain in force, and §92.210 was not among the vacated provisions. Neither “all AI discrimination rules vanished” nor “every original provision remains fully enforceable” is a safe summary. [S35, S36]

12. The record is also a payment, benefit and public-program input

An unsupported diagnosis is not automatically fraud. It becomes a payment-integrity question when it is used in a relevant submission or representation and the governing legal elements are met.

For outpatient coding, the FY 2027 ICD-10-CM Official Guidelines — applicable from October 1, 2026 — retain the long-standing uncertain-diagnosis rule (Section IV.H): in outpatient settings, conditions documented as probable, suspected or “rule out” are not coded as established, and coding follows the highest degree of certainty for the encounter. Inpatient rules differ. Changing “possible” to “confirmed” can therefore change more than writing style. [S40]

CMS evaluation-and-management guidance emphasizes medical necessity and, for most E/M families, medical decision-making or clinician time. A longer or more sophisticated-looking AI note does not establish that more work was performed. Medicare Advantage risk-adjustment data validation examines support for submitted diagnoses, but a draft candidate does not prove submission or an overpayment. [S41, S42]

The rows without a single controlling citation are screening questions, not claims that every program has an identical AI-specific prohibition. Before asserting a violation, trace the actual data path and obtain the applicable program authorities.

Under the False Claims Act, the analysis must identify the claim or material record, the relevant knowledge standard, and the other necessary elements. An accidental error corrected before use is not equivalent to knowingly causing unsupported claims. Repeated warnings can become relevant evidence, but an internal concern alone is not proof of knowledge, materiality or fraud. [S44]

History shows that EHR vendors are not inherently outside accountability. In 2017 eClinicalWorks agreed to pay $155 million to resolve False Claims Act allegations that it misrepresented its software’s capabilities and paid kickbacks; in 2020 Practice Fusion agreed to pay $145 million to resolve criminal and civil investigations involving kickbacks from a pharmaceutical company in exchange for clinical-decision-support alerts, with the civil claims resolved as allegations. These involved other vendors and other facts. They establish neither misconduct by Microsoft or Epic nor that ordinary AI errors resemble those schemes. [S45, S46]

13. Malpractice, federal coverage and medical-board discipline are different proceedings

Clinicians often assume that a malpractice shield answers every question. It does not. Where a clinician’s malpractice exposure runs through the Federal Tort Claims Act — as it does for federal employees and for covered personnel of HRSA-deemed health centers — the statutory remedy channels qualifying claims for personal injury arising from “medical, surgical, dental, or related functions” into a suit against the United States. Eligibility, the individual, the activity and scope all matter. That remedy concerns civil damages; it is not immunity from state professional discipline, and it is not a license-defense insurance policy. [S37, S38]

HRSA’s compliance manual also requires deemed health centers to maintain risk-management and claims-related processes. Those requirements give such institutions a reason to evaluate reported documentation hazards rather than assume that an individual signature resolves implementation risk. They do not establish that any particular deployment has failed them. [S39]

In ordinary malpractice analysis, a later correct AI suggestion is not by itself proof that rejecting it was negligent. Nor does agreeing with AI establish reasonable care. The inquiry is the applicable professional standard and the circumstances, not perfect hindsight. California’s civil jury instructions on the standard of care (CACI 501) and on success not being required (CACI 505) reflect that distinction; current instructions and case law should be checked in any actual case. [S55, S61]

Board discipline has different statutory elements and procedures from civil damages. A malpractice defense, an employer assurance and an insurance payment do not necessarily settle a licensing question. Certain formal licensure actions can also have National Practitioner Data Bank consequences; a complaint, a draft error or a rejected suggestion is not automatically reportable. [S49, S57]

The practical protection is not a disclaimer that “AI wrote this.” It is accurate care, appropriate verification, truthful attestations and an accessible record of what occurred. Employer and vendor responsibilities should be evaluated alongside clinician conduct, not used as a reason to abandon professional review.

14. What malpractice attorneys and investigators need before interpreting an AI note

A final PDF of the chart may be insufficient to reconstruct an AI-assisted encounter. The relevant evidence can include the source recording where lawfully retained, the transcript, retrieved EHR context, generated versions, clinician edits, structured diagnoses, order history, configuration, training, and the meaning of interface events.

The request should be proportional to the dispute and legally authorized. Discovery is not automatic, and neither is indefinite recording retention. Rules governing relevance, privilege, protective orders and electronically stored information must be applied to the proceeding; Federal Rules of Civil Procedure 26 and 37 provide important examples, and state practice can differ. [S47, S58]

An event saying “rejected” should not be interpreted without the data dictionary, version and user-facing context. Investigators should distinguish: candidate generated, candidate displayed, candidate opened, content clinically considered, content adopted, draft discarded, and diagnosis ruled out. These distinctions are proposed evidentiary safeguards, not an assertion that current systems record each event.

A contemporaneous clinical-safety report may document what was reported and when. It does not independently prove the reported defect. It can also show the reporting clinician’s own knowledge, making subsequent review practices relevant. Forwarding an existing document to counsel does not automatically make the underlying facts privileged; privilege is a separate, fact-specific analysis.

Post-employment access should be planned in advance through lawful institutional and contractual channels. A clinician should not export patient recordings, charts or audit logs to a personal device or a consumer AI tool to build a defense. A litigation hold, when warranted, should be handled through authorized counsel and records custodians — not improvised private retention.

15. The vendor’s best defense deserves a serious answer

A fair investigation must be capable of concluding that some concerns are resolved by an appropriate configuration or by evidence of a well-designed implementation.

The most defensible criticism is not that vendors intentionally withhold information. It is that public information is fragmented across marketing, release notes, user documentation, transparency materials and data dictionaries. That fragmentation can leave procurement teams with a broad commercial narrative and clinicians with incomplete operational knowledge.

The answer is a consolidated feature dossier: intended use, input sources, output types, deployment prerequisites, validation population, known limitations, data destinations, version changes, review obligations and correction controls. A proprietary implementation does not excuse an inability to explain clinically consequential behavior. At the same time, a request for safety evidence is not an entitlement to every trade secret or model weight.

16. A safer implementation should be able to pass these tests

The following is an original proposed governance standard, not a claim that every step is expressly required by statute.

Before deployment, build a function inventory: transcription, summarization, diagnostic normalization, diagnostic suggestion, plan suggestion, structured-field insertion, order staging, order execution and secondary data use. Give each function a clinical owner and a technical owner. Record its legal classification analysis and its evidence base.

Test synthetic and authorized representative cases against a reference record of intended decisions. Include uncertainty, negation, deferred testing, refusal, family history, multiple speakers, interpreters, outdated problem lists, incomplete recordings, interruptions, specialty terminology and patient corrections. Clinical fidelity and diagnostic appropriateness should be adjudicated separately. Do not treat the reference clinician’s opinion as infallible; use independent review for genuine disagreement.

Measure clinically consequential additions, omissions, certainty changes, plan reversals, wrong-person attribution, correction time and residual errors after review. Stratify results by relevant population and workflow. Define denominators: an edited-note percentage is not an error rate, and “unedited” does not necessarily mean “unreviewed.”

Figure 4. Proposed clinical-AI implementation gates

Demonstrate every state change in the actual non-production integration. Can users safely discard a draft without falsely implying clinical exclusion? Do narrative edits leave contradictory structured diagnoses? Can the note say a medication was started while no prescription exists? Can an accepted diagnosis later be reintroduced after correction? Does a new recording overwrite prior edits? What will a supervisor see?

Provide practical training, a supported fallback, clear escalation and protected time for review. Where an individual sandbox is unavailable, demonstrate how equivalent preparation is achieved. A successful pilot by a small enthusiastic group does not necessarily generalize to every specialty, workload or communication environment; equally, one clinician’s non-participation does not prove that no pilot occurred.

Set update controls. A new model, prompt, integration, template or diagnosis-mapping rule can change the safety case. Maintain a rollback path, monitor residual errors and reopen validation when clinically consequential behavior changes. An implementation is not permanently validated because its first rollout was accepted.

Finally, test correction propagation. A safety system should be judged not only by whether it can produce a correct record, but by whether it can repair an incorrect one without obscuring history or leaving contradictory downstream data.

17. What each audience should ask now

Physicians and PAs. Which parts of the record are extracted, inferred or imported? What exactly am I adopting? Can I correct both narrative and structured content? Does my attestation accurately describe my participation and review?

Supervising clinicians. Does concurrence mean clinical agreement or a narrower review obligation? Is the record sufficient for that review? How are discrepancies returned, corrected and closed without silently shifting responsibility?

Implementation specialists and Epic analysts. Which feature generates each object? What are the defaults, prerequisites, locks, permissions, source windows, retention schedules and update behaviors? Can you reproduce the full path in Haiku, Canto and Hyperspace using synthetic data, and show which data do — and do not — leave the system?

Medical boards. How should a reviewer distinguish rejecting draft content from clinically declining advice? What minimum transparency and review conditions are necessary before assigning significance to an acceptance or rejection event? How should employer-required exposure to unsolicited candidates affect the analysis without excusing poor care?

Malpractice and health-system counsel. What was foreseeable, what was tested, who controlled the relevant design, and what actually caused the outcome? Are preservation, authorized record access, indemnity and professional-defense arrangements adequate for the long tail of the record?

Patients. Was the visit recorded with appropriate disclosure and consent? Does the record accurately describe the symptoms, choices and plan? How can an error be corrected, and who follows the correction beyond the visible note?

Vendors and executives. Can the claimed reduction in work be demonstrated after verification and correction? Are financial and clinical endpoints measured separately? What clinical evidence justified enabling a recommendation layer beyond the scribe function clinicians originally requested?

These questions are compatible with adoption. They are how adoption becomes accountable.

Conclusion: preserve the distinction between generated text and adopted judgment

The evidence does not justify claiming that every AI-generated diagnosis is unsafe, every employer rollout is negligent, or every vendor disclaimer is deceptive. It does justify rejecting the idea that ambient clinical documentation is always just dictation with better formatting.

The contemporary workflow can transform conversation and chart context into diagnostic labels, plans, structured suggestions and downstream data. Those transformations may be useful. They may also change clinical meaning. The resulting risk cannot be evaluated by note-generation speed, a brand name, or the existence of a final signature alone.

The governing principle should be straightforward:

No candidate diagnosis should silently become an established clinical fact. No discarded draft should automatically become a recorded medical refusal. No supervisory concurrence should imply an examination or verification that did not occur. And no organization should assume that an individual signature substitutes for a functioning clinical safety system.

The appropriate objective is neither unquestioning adoption nor blanket prohibition. It is traceable, proportionate, clinically validated assistance — with meaningful control over what becomes the patient’s enduring record.

Common questions

Appendix A. Evidence status of the main propositions

Appendix B. Questions for Microsoft, Epic and deploying organizations

These questions are published so that each party can answer them on the record. Neither Microsoft nor Epic was contacted before this edition; a response from either company will be added, with the date received.

Microsoft (Nuance). Which current Dragon Copilot and DAX Copilot features infer diagnostic candidates, reconcile existing visit diagnoses, generate linked plans or increase specificity? For each, what is the intended use, release, input sources, and evidence supporting the clinically consequential function? Which published studies evaluated the current feature rather than an earlier ambient scribe? Which controls permit documentation-only use? Do any configurations require individual rejection before signing, and who controls that requirement? What do product logs retain, for how long, and through what export or access mechanism? What happens after manual editing, a later recording, a model revision or an Epic diagnosis change? How are unsupported certainty, patient refusals, conditional plans, speaker attribution and multilingual visits evaluated?

Epic. Which components capture, generate, display, reconcile and adopt each object? How do the public ambient-diagnosis fields map to the Heard In Visit workflow? What is retained as current state and what as event history? Is there a distinct representation for draft discard, duplicate removal and clinical disagreement? What can affect narrative text, encounter diagnoses, the problem list, orders, coding or after-visit instructions, and which transitions require separate authorization? Can local configuration create a sign-blocking condition? How are suggestions and later corrections represented in authorized exports and in supervisory review?

Deploying organizations. Which clinical function was approved, by whom, and on what evidence? Did validation test the exact version, specialty, staffing and supervision conditions? What training was offered, and how was competency established? What supported alternative exists when a clinician cannot verify an output? What time savings are measured after correction, and have workload expectations changed? Please distinguish documented safeguards from planned improvements: an answer that “the clinician ultimately signs” is not a description of the controls that operate before the signature.

Appendix C. A proposed synthetic challenge set

These are original test specifications — not real patients, vendor test results or treatment recommendations. Qualified clinicians should write and approve the corresponding synthetic conversations and reference decisions, and run them only in an authorized test environment.

T19 is an adversarial robustness test, not a claim of a demonstrated exploit. No test of a live clinical system is proposed.

What to measure. Use a reference record of the clinician’s intended assessment and plan, then independent adjudication of medically appropriate alternatives: the first tests fidelity, the second clinical support. Measure unsupported additions, omissions, certainty changes, plan reversals, speaker errors, wrong-context imports, residual errors after review, narrative-versus-structured inconsistencies, and correction-propagation failures, with denominators at the assertion, note and encounter level. Measure complete workload — setup, waiting, review, source checks, rejection clicks, reconciliation, re-dictation, sign-off and later cleanup — and separate time inside the visit from after-hours work.

Appendix D. A proposed review algorithm: verify the workflow, not the patient’s diagnosis

Original illustrative governance logic. It is not vendor source code, a validated clinical algorithm, or an instruction to accept or reject patient care automatically. Clinical leadership must define the applicable review obligations, thresholds and escalation procedures.

INPUT: an enabled clinical-AI feature and an authorized synthetic test encounter

1. Identify the exact release, configuration, input sources, intended use and owners.
   If unknown: record the gap; do not infer behavior from the product brand.

2. Classify each output object separately:
   draft text / candidate diagnosis / plan suggestion / structured diagnosis /
   pending order / signed order / patient communication / billing abstraction.

3. For every clinically material assertion, compare:
   A. fidelity to the source and to clinician intent;
   B. clinical appropriateness under independent review.
   Agreement with the source is not proof of correct medical care.

4. Demonstrate user actions and state changes in the actual test integration.
   Distinguish modifying or discarding a draft from a clinical decision.
   Do not infer a clinician's rationale from a button label.

5. Check narrative, structured fields, orders and supervisory attestation.
   If they conflict: route for authorized reconciliation before clinical adoption.
   A second signature is not evidence of an unperformed second encounter.

6. Evaluate full review and correction workload, residual errors, privacy,
   retention, accessibility, subgroup performance and available alternatives.
   Compare findings with prospectively defined local safety criteria.

7. Obtain accountable clinical approval, subject to legal and security review.
   Unresolved safety-critical gap: restrict the relevant function and use an
   approved fallback; do not silently turn the gap into an approval.

8. Monitor, investigate and correct after release.
   Material model/template/integration change: reopen affected validation.
   Error adopted downstream: trace destinations and document lawful correction.

OUTPUT:     evidence dossier + unresolved gaps + human governance decision.
NOT OUTPUT: an automatically approved diagnosis, prescription or clinical note.

A minimum provenance record for each candidate would identify: candidate identifier; encounter reference; source category; system and feature revision; generated text; linked plan; time presented; actor; action; stated meaning of the action; adopted version; destinations changed; and correction lineage. These are proposed fields, not a claim that Epic or Microsoft exposes each one. “Not adopted” can be known while “considered and clinically rejected” remains unknown; a rationale should be recorded when clinically relevant, not manufactured to satisfy a logging scheme.

Editorial record and corrections

Source register

Numbered sources cited in the text. Vendor documentation and studies were re-checked against the live pages on 4 November 2026 (UTC); legal and regulatory authorities on 3–4 November 2026, and corrections from that check are applied in the text and recorded above. Product documentation is evidence of a described capability, not independent evidence of safety. Questions and proposed safeguards are original analysis. No confidential vendor material is used.

1. S01 — Microsoft Learn: Intelligent diagnoses retrieval from Epic ↩ back to text

   Type: Vendor technical documentation

   Supports: Generation, comparison with Epic diagnoses, and plan alignment are described. Re-checked 4 November 2026.

   Limitation: Does not independently validate accuracy or establish a particular customer configuration.

   https://learn.microsoft.com/en-us/industry/healthcare/dragon-copilot/specialty-models/intelligent-diagnoses-retrieval

   Accessed 3 November 2026.

2. S02 — Microsoft Learn: Dragon Copilot 3.6 ↩ back to text

   Type: Vendor release documentation

   Supports: Diagnosis-aware notes, structured A&P, Epic/Nebula dependencies, and template behavior. Re-checked 4 November 2026.

   Limitation: Feature availability does not prove activation or mandatory rejection at a particular site.

   https://learn.microsoft.com/en-us/industry/healthcare/dragon-copilot/whats-new/3-6

   Accessed 3 November 2026.

3. S03 — Microsoft Support: Diagnosis specificity ↩ back to text

   Type: Vendor user documentation

   Supports: Specificity suggestions can be accepted, dismissed, or ignored. Re-checked 4 November 2026.

   Limitation: A separate feature; must not be equated with all diagnosis-aware workflows.

   https://support.microsoft.com/en-us/dragon-copilot/physicians/diagnosis-specificity

   Accessed 3 November 2026.

4. S04 — Microsoft Support: Manage orders in DAX Copilot for Epic ↩ back to text

   Type: Vendor user documentation

   Supports: Suggested orders act as memory aids; integration and final ordering steps matter. Re-checked 4 November 2026.

   Limitation: Suggested, staged, signed, and transmitted orders are not equivalent.

   https://support.microsoft.com/en-us/dax-copilot/epic/manage-orders-in-dax-copilot-for-epic

   Accessed 3 November 2026.

5. S05 — Microsoft Support: DAX Copilot for Epic FAQs ↩ back to text

   Type: Vendor user documentation

   Supports: DAX Copilot for Epic FAQs: recording through Epic mobile apps (Haiku, Canto), recording updates, SmartSections and permissions. Re-checked 4 November 2026.

   Limitation: Not an independent audit of site-specific routing or data retention.

   https://support.microsoft.com/en-us/dax-copilot/epic/dax-copilot-for-epic-faqs

   Accessed 3 November 2026.

6. S06 — Microsoft Learn: Dragon Copilot transparency note ↩ back to text

   Type: Vendor transparency documentation

   Supports: Intended use, limitations, human review, source checking, and evaluation approach. Re-checked 4 November 2026.

   Limitation: Vendor disclosures are not proof of independent clinical validation for every feature.

   https://learn.microsoft.com/en-us/industry/healthcare/dragon-copilot/about/transparency

   Accessed 3 November 2026.

7. S07 — Microsoft Learn: Dragon Copilot FAQs ↩ back to text

   Type: Vendor data-handling documentation

   Supports: Describes retention up to 90 days for specified source data and improvement uses. Re-checked 4 November 2026.

   Limitation: Contracts, deployments and data categories must be checked; not a universal retention guarantee.

   https://learn.microsoft.com/en-us/industry/healthcare/dragon-copilot/about/faqs

   Accessed 3 November 2026.

8. S08 — Epic: DOCS_RCVD_DX EHI export specification ↩ back to text

   Type: Vendor public data dictionary

   Supports: Ambient diagnosis, alternatives, rank, state reference, topic grouping and nudge fields. Re-checked 4 November 2026.

   Limitation: Schema definitions do not prove local population, complete history, rejection retention or patient accessibility.

   https://open.epic.com/EHITables/GetTable/DOCS_RCVD_DX.htm

   Accessed 3 November 2026.

9. S09 — Epic: Art product overview ↩ back to text

   Type: Vendor product description

   Supports: Publicly describes drafting outpatient notes, orders and diagnoses from conversations. Re-checked 4 November 2026.

   Limitation: Epic product descriptions do not establish that Microsoft supplies every listed feature.

   https://www.epic.com/software/art/

   Accessed 3 November 2026.

10. S10 — Microsoft: Dragon Copilot nursing and partner innovations, October 16, 2025 ↩ back to text

    Type: Vendor announcement

    Supports: Revenue-cycle management, clinical intelligence and extensibility are explicit commercial objectives. Re-checked 4 November 2026.

    Limitation: Announced examples and previews are not universal deployed capabilities.

    https://news.microsoft.com/source/2025/10/16/microsoft-extends-ai-advancements-in-dragon-copilot-to-nurses-and-partners-to-enhance-patient-care/

    Accessed 3 November 2026.

11. S11 — Microsoft: Dragon Copilot at HIMSS, March 5, 2026 ↩ back to text

    Type: Vendor announcement

    Supports: Expansion into partner apps, work context and decision support.

    Limitation: Marketing claims require feature-level validation and availability checks.

    https://www.microsoft.com/en-us/industry/blog/healthcare/2026/03/05/unify-simplify-scale-microsoft-dragon-copilot-meets-the-moment-at-himss-2026/

    Accessed 3 November 2026.

12. S12 — Ambient AI Scribes in Clinical Practice: A Randomized Trial (NEJM AI 2025;2(12); published online November 26, 2025) ↩ back to text

    Type: Peer-reviewed randomized trial; published November/December 2025

    Supports: UCLA, 238 physicians, 14 specialties; DAX versus Nabla versus usual care, November 4, 2024–January 3, 2025; DAX time-in-note −1.7% vs control (95% CI −9.4% to +5.9%; P=0.66). Re-checked 4 November 2026.

    Limitation: Not a trial of the exact reported rejection-to-sign workflow. DAX nonsignificant time result is not proof of no benefit in all settings.

    https://pubmed.ncbi.nlm.nih.gov/41497288/

    Accessed 3 November 2026.

13. S13 — Ambient artificial intelligence scribes: utilization and impact on documentation time (JAMIA 2025;32(2):381–385; online December 17, 2024) ↩ back to text

    Type: Peer-reviewed implementation study

    Supports: Stanford Health Care; DAX Copilot drafting HPI, exam, results and assessment and plan; used in 55.25% of 17,428 encounters; median time per note 4.86 to 3.64 minutes. Re-checked 4 November 2026.

    Limitation: Documentation outcomes do not establish autonomous diagnostic safety or feature equivalence.

    https://pmc.ncbi.nlm.nih.gov/articles/PMC11756633/

    Accessed 3 November 2026.

14. S14 — Clinicians’ rationale for editing ambient AI–drafted clinical notes: persistent challenges and implications for improvement (JAMIA 2026;33(7), April 27, 2026) ↩ back to text

    Type: Peer-reviewed qualitative study; 2026

    Supports: UC Irvine; 30 clinician interviews; Abridge implementation. Re-checked 4 November 2026.

    Limitation: This study concerns Abridge, not a DAX-specific feature validation.

    https://academic.oup.com/jamia/article/33/7/1345/8663195

    Accessed 3 November 2026.

15. S15 — What do clinicians edit in ambient AI-drafted clinical documentation? A qualitative content analysis (JAMIA 2026;33(8), May 12, 2026) ↩ back to text

    Type: Peer-reviewed qualitative content analysis; 2026

    Supports: UC Irvine; two commercial Epic-integrated ambient systems, unnamed (Vendor A, Vendor B). Re-checked 4 November 2026.

    Limitation: Products are not named; findings cannot be attributed to DAX or any specific vendor.

    https://academic.oup.com/jamia/article/33/8/1457/8676554

    Accessed 3 November 2026.

16. S16 — Quality of Clinical Notes Created by Ambient Listening Generative AI: Pragmatic Prospective Pilot Study ↩ back to text

    Type: Peer-reviewed prospective quality-improvement study; April 17, 2026

    Supports: UC Davis; 31 physicians; 356 of 7,545 notes rated; omissions 18%, hallucinations 11.5%; 19 notes (5.3%) with errors rated serious or imminent risk (severity 4–5); product not named. Re-checked 4 November 2026.

    Limitation: Selected 4.7% sample; potential harm if uncorrected, not observed patient injury. Product is not identified as DAX in the retrieved article.

    https://medinform.jmir.org/2026/1/e86474

    Accessed 3 November 2026.

17. S17 — North Carolina Medical Board, Position Statement 3.2.1 (Medical Records), in the Board’s Position Statement Compendium ↩ back to text

    Type: Official professional guidance; page amended September 2026

    Supports: Accuracy of records generated with dictation software or AI; “Once a licensee chooses to use AI, they accept responsibility for responding appropriately to the AI’s recommendations”; rationale when following, documented rationale when deviating. Adopted 2018; amended since. Re-checked 3–4 November 2026.

    Limitation: Board position statement, not a statute; not binding in California. Amendment dates do not show when each AI sentence first appeared. The live web page is at ncmedboard.org (position statements).

    https://www.ncmedboard.org/images/uploads/other_pdfs/PositionStatementCompendium_072026.pdf

    Accessed 3 November 2026.

18. S18 — California AB 1979 (2026), Chapter 854, Statutes of 2026 — approved September 30, 2026 ↩ back to text

    Type: Primary enacted legislative text reproduced by legislative mirror

    Supports: Adds B&P §22758.5 (AI Clinical Decision Support): reasonable steps so a licensee retains independent professional judgment; limits on AI independently performing licensed clinical functions; exception for documentation and communication “that does not involve the application of professional judgment.” Re-checked 3–4 November 2026.

    Limitation: Bill text as reproduced by a legislative mirror (official text at leginfo.legislature.ca.gov). No separate operative date; ordinary January 1, 2027 effective date.

    https://calmatters.digitaldemocracy.org/bills/ca_202520260ab1979

    Accessed 3 November 2026.

19. S19 — California SB 503 (2026), Chapter 857, Statutes of 2026 — approved September 30, 2026 ↩ back to text

    Type: Primary enacted legislative text reproduced by legislative mirror

    Supports: Adds B&P §22758: developer and deployer reasonable-effort duties on biased impacts; developer statement of intended uses and risks; deployer monitoring and mitigation. Re-checked 3–4 November 2026.

    Limitation: No phased reporting schedule, no agency reporting and no mandatory independent-audit timetable in the chaptered text; impact assessments are an optional compliance route.

    https://calmatters.digitaldemocracy.org/bills/ca_202520260sb503

    Accessed 3 November 2026.

20. S20 — California AB 1637 (2026), Chapter 536, Statutes of 2026 — approved September 27, 2026 ↩ back to text

    Type: Primary enacted legislative text reproduced by legislative mirror

    Supports: Adds B&P §2266.1: patient notes (“notes, after-visit summaries, and diagnosis and treatment plans”) are the authoring physician’s responsibility; alteration limited to listed exceptions. Re-checked 3–4 November 2026.

    Limitation: Exceptions: delegated scribe/assistant; a physician receiving transferred care may add to (not edit) notes; supervising physician of trainees. The section does not mention AI.

    https://calmatters.digitaldemocracy.org/bills/ca_202520260ab1637

    Accessed 3 November 2026.

21. S21 — California Governor legislative update, September 30, 2026 ↩ back to text

    Type: Official enactment/veto record

    Supports: Official enactment and veto record for 30 September 2026, listing AB 2575 among vetoed bills.

    Limitation: A vetoed proposal cannot be cited as operative law. Veto status also corroborated in the bill history [S66].

    https://www.gov.ca.gov/2026/09/30/governor-newsom-issues-legislative-update-9-30-2026/

    Accessed 3 November 2026.

22. S22 — California Medical Board: Generative AI patient notification ↩ back to text

    Type: Official regulatory explanation

    Supports: AB 3030: disclosure on patient clinical communications generated by generative AI (from January 1, 2025), with an exception for communications read and reviewed by a licensed or certified provider. Re-checked 3–4 November 2026.

    Limitation: AI disclosure is distinct from consent to record or permission for data processing.

    https://www.mbc.ca.gov/Resources/Medical-Resources/GenAI-Notification.aspx

    Accessed 3 November 2026.

23. S23 — California Attorney General AI legal advisories, January 13, 2025

    Type: Official enforcement advisory announcement

    Supports: Existing privacy, consumer, civil-rights and medical-practice law can apply to AI.

    Limitation: Advisory is not a judicial determination that a particular product violates law.

    https://oag.ca.gov/news/press-releases/attorney-general-bonta-issues-legal-advisories-application-california-law-ai

    Accessed 3 November 2026.

24. S24 — FDA: Clinical Decision Support Software — final guidance, January 2026 ↩ back to text

    Type: Official nonbinding guidance; PDF inspected

    Supports: Function-level non-device CDS criteria, including enabling the professional to independently review the basis for a recommendation; discussion of automation bias. Re-checked 3–4 November 2026.

    Limitation: Guidance is not a product-specific FDA determination; all applicable criteria and intended use matter.

    https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software

    Accessed 3 November 2026.

25. S25 — ASTP/ONC: Decision support interventions test method ↩ back to text

    Type: Official certification criteria implementation

    Supports: 170.315(b)(11) source attributes and intervention risk management for covered predictive DSI.

    Limitation: Superseded in part: HTI-5 removes the (b)(11) source-attribute and predictive-intervention risk-management requirements (see S67). Never FDA clearance or diagnostic validation.

    https://healthit.gov/test-method/decision-support-interventions/

    Accessed 3 November 2026.

26. S26 — AMA: Liability for clinical AI, October 29, 2026 ↩ back to text

    Type: Professional policy framework

    Supports: “Responsibility should reflect each party’s authority, access to information and ability to prevent or mitigate harm.” Dated 29 October 2026. Re-checked 3–4 November 2026.

    Limitation: Advocacy/framework, not enacted tort immunity or binding allocation of damages.

    https://www.ama-assn.org/practice-management/digital-health/liability-clinical-ai

    Accessed 3 November 2026.

27. S27 — FSMB: AI regulation workgroup announcement, May 19, 2026 ↩ back to text

    Type: Official professional federation announcement

    Supports: Workgroup announced 19 May 2026, charged with a report and recommendations and/or model guidelines on AI in medical practice. Re-checked 3–4 November 2026.

    Limitation: FSMB is not a single national licensing board; state authority remains distinct.

    https://www.fsmb.org/advocacy/news-releases/federation-of-state-medical-boards-announces-new-workgroup-on-regulation-of-artificial-intelligence-in-medical-practice

    Accessed 3 November 2026.

28. S28 — California Medical Board: Supervising physician assistants FAQs ↩ back to text

    Type: Official professional guidance

    Supports: Practice-agreement elements, supervision, competency and authorized services.

    Limitation: Attestation text, agreement and payer rules must be evaluated together.

    https://www.mbc.ca.gov/FAQs/default.aspx?cat=Licensees&topic=Supervising+Physician+Assistants

    Accessed 3 November 2026.

29. S29 — California B&P section 3502 ↩ back to text

    Type: Primary statute reproduced by legal mirror

    Supports: §3502(c): nothing in regulations shall require a physician to review or countersign a medical record of a PA “unless required by the practice agreement.” Re-checked 3–4 November 2026.

    Limitation: Check subsequent amendments and the actual agreement before individual advice.

    https://california.public.law/codes/business_and_professions_code_section_3502

    Accessed 3 November 2026.

30. S30 — California Civil Code section 56.101 ↩ back to text

    Type: Primary statute reproduced by legal mirror

    Supports: Electronic record integrity and recording changes/deletions; confidentiality and sensitive-data provisions.

    Limitation: Not proof that every model intermediate, raw audio file or UI event is legally required to be retained.

    https://law.justia.com/codes/california/code-civ/division-1/part-2-6/chapter-2/section-56-101/

    Accessed 3 November 2026.

31. S31 — HHS: Guidance on HIPAA and cloud computing ↩ back to text

    Type: Official privacy guidance

    Supports: Business associates, BAAs, risk assessment and cloud handling of ePHI.

    Limitation: Contract compliance and security are not clinical validation.

    https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html

    Accessed 3 November 2026.

32. S32 — HHS: De-identification of protected health information ↩ back to text

    Type: Official privacy guidance

    Supports: Safe Harbor and Expert Determination pathways.

    Limitation: Pseudonymization or removal of a name alone is not automatically HIPAA de-identification.

    https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html

    Accessed 3 November 2026.

33. S33 — 45 CFR 164.526: Amendment of protected health information ↩ back to text

    Type: Primary regulation reproduced by legal institute

    Supports: Amendment requests, appended/linked corrections and associated recipient notification duties.

    Limitation: Does not guarantee deletion of every downstream copy or access to all backend logs.

    https://www.law.cornell.edu/cfr/text/45/164.526

    Accessed 3 November 2026.

34. S34 — HHS: 42 CFR Part 2 final-rule fact sheet ↩ back to text

    Type: Official privacy guidance

    Supports: Special SUD-record protections; compliance date February 16, 2026.

    Limitation: Applicability depends on Part 2 program/record status, not merely mentioning substance use.

    https://www.hhs.gov/hipaa/for-professionals/regulatory-initiatives/fact-sheet-42-cfr-part-2-final-rule/index.html

    Accessed 3 November 2026.

35. S35 — 45 CFR 92.210: Patient care decision support tools ↩ back to text

    Type: Official federal regulation

    Supports: Nondiscrimination obligations concerning patient-care decision tools.

    Limitation: Read with applicable court orders and current enforcement notices.

    https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-A/part-92/subpart-C/section-92.210

    Accessed 3 November 2026.

36. S36 — Federal Register notice, June 2, 2026 (2026-11015), and HHS release of June 1, 2026: partial vacatur of the 2024 Section 1557 rule (Tennessee v. Kennedy) ↩ back to text

    Type: Official enforcement status notice

    Supports: Specified provisions vacated to the extent they expand Title IX’s definition of sex discrimination to gender identity; other provisions remain in force; §92.210 not among those vacated. Re-checked 3–4 November 2026.

    Limitation: Do not treat the whole rule as either unaffected or universally invalid.

    https://www.govinfo.gov/content/pkg/FR-2026-06-02/html/2026-11015.htm

    Accessed 3 November 2026.

37. S37 — HRSA FTCA frequently asked questions ↩ back to text

    Type: Official program guidance

    Supports: Deeming; covered individuals; FTCA coverage of claims for negligent acts or omissions in the performance of medical, surgical, dental or related functions within scope. Re-checked 3–4 November 2026.

    Limitation: The FAQ does not address state licensing-board proceedings; the distinction from licensure rests on the statutory remedy (S38).

    https://bphc.hrsa.gov/compliance/ftca/faq

    Accessed 3 November 2026.

38. S38 — 42 USC 233 ↩ back to text

    Type: Primary federal statute reproduced by legal institute

    Supports: Exclusive qualifying medical-injury remedy and defense/deeming provisions.

    Limitation: Does not create blanket state licensing immunity.

    https://www.law.cornell.edu/uscode/text/42/233

    Accessed 3 November 2026.

39. S39 — HRSA Compliance Manual, chapter 21 ↩ back to text

    Type: Official health-center compliance requirements

    Supports: Risk management, training, claims procedures and preservation of relevant records.

    Limitation: Application is program- and deeming-specific.

    https://bphc.hrsa.gov/compliance/compliance-manual/chapter21

    Accessed 3 November 2026.

40. S40 — CMS: FY 2027 ICD-10-CM official guidelines ↩ back to text

    Type: Official coding guidance; PDF inspected

    Supports: Outpatient uncertainty rule, section IV.H; effective October 1, 2026–September 30, 2027.

    Limitation: Inpatient rules differ; potential diagnoses are not universally coded as established.

    https://www.cms.gov/files/document/fy-2027-icd-10-cm-coding-guidelines.pdf

    Accessed 3 November 2026.

41. S41 — CMS: Evaluation and management services ↩ back to text

    Type: Official payment guidance

    Supports: Medical necessity and, for most E/M families, MDM or clinician time determine level.

    Limitation: Longer generated notes do not establish a higher supported service level.

    https://www.cms.gov/training-education/medicare-learning-networkr-mln/compliance/medicare-provider-compliance-tips/evaluation-management-services

    Accessed 3 November 2026.

42. S42 — CMS: Medicare Advantage risk-adjustment data validation ↩ back to text

    Type: Official payment-integrity program

    Supports: Submitted diagnoses must be supported in medical records.

    Limitation: A narrative suggestion does not prove a diagnosis was submitted or that an overpayment occurred.

    https://www.cms.gov/data-research/monitoring-programs/medicare-risk-adjustment-data-validation-program

    Accessed 3 November 2026.

43. S43 — CMS: Federally qualified health centers ↩ back to text

    Type: Official provider/payment resources

    Supports: FQHC-specific encounter and payment framework.

    Limitation: Not ordinary fee-for-service payment for each added diagnosis.

    https://www.cms.gov/medicare/enrollment-renewal/providers-suppliers/information-centers/federally-qualified-health-centers

    Accessed 3 November 2026.

44. S44 — 31 USC 3729: False Claims Act ↩ back to text

    Type: Primary federal statute reproduced by legal institute

    Supports: Knowing false claims/records, materiality and statutory knowledge standards.

    Limitation: An erroneous AI draft alone does not prove a false claim; elements must be established.

    https://www.law.cornell.edu/uscode/text/31/3729

    Accessed 3 November 2026.

45. S45 — DOJ: eClinicalWorks settlement, May 31, 2017 ↩ back to text

    Type: Official enforcement record

    Supports: May 31, 2017: $155 million to resolve allegations that eClinicalWorks misrepresented its software’s capabilities and paid kickbacks. Re-checked 3–4 November 2026.

    Limitation: Different vendor and conduct; settlement allegations are not findings against Microsoft or Epic.

    https://www.justice.gov/archives/opa/pr/electronic-health-records-vendor-pay-155-million-settle-false-claims-act-allegations

    Accessed 3 November 2026.

46. S46 — DOJ: Practice Fusion criminal/civil resolution, January 27, 2020 ↩ back to text

    Type: Official enforcement record

    Supports: January 27, 2020: $145 million to resolve criminal and civil investigations involving kickbacks in exchange for clinical-decision-support alerts. Re-checked 3–4 November 2026.

    Limitation: Civil claims resolved as allegations. Not ambient AI; implies nothing about current named vendors.

    https://www.justice.gov/usao-vt/pr/electronic-health-records-vendor-pay-largest-criminal-fine-vermont-history-and-total-145

    Accessed 3 November 2026.

47. S47 — Federal Rule of Civil Procedure 37 ↩ back to text

    Type: Primary procedural rule reproduced by legal institute

    Supports: Rule 37(e) addresses lost ESI that should have been preserved.

    Limitation: Preservation and sanctions depend on litigation context, duties and facts.

    https://www.law.cornell.edu/rules/frcp/rule_37

    Accessed 3 November 2026.

48. S48 — California DIR: Laws prohibiting retaliation ↩ back to text

    Type: Official employment-law guidance

    Supports: Labor Code 1102.5 qualifying reasonable-belief disclosures.

    Limitation: Not every disagreement with software is protected and not general immunity from lawful supervision.

    https://www.dir.ca.gov/dlse/HowToFileLinkCodeSections.htm

    Accessed 3 November 2026.

49. S49 — NPDB Guidebook: State licensure actions ↩ back to text

    Type: Official reporting guidance

    Supports: Specified formal licensing actions are reportable.

    Limitation: Not every complaint, error or AI rejection is reportable.

    https://npdb.hrsa.gov/guidebook/EStateLicensureActions.jsp

    Accessed 3 November 2026.

50. S50 — HHS OIG: EHR fraud safeguards, 2013 ↩ back to text

    Type: Historical government study

    Supports: Audit-log and copy/paste safeguards were already relevant before generative AI.

    Limitation: Historical analogy, not an AI error rate or present vendor finding.

    https://oig.hhs.gov/reports/all/2013/not-all-recommended-fraud-safeguards-have-been-implemented-in-hospital-ehr-technology/

    Accessed 3 November 2026.

51. S51 — 21 CFR 1306.04: Purpose of prescription ↩ back to text

    Type: Primary federal regulation reproduced by legal institute

    Supports: Controlled-substance prescribing requires legitimate purpose and authorized professional practice.

    Limitation: Draft medication text is not itself an executed prescription.

    https://www.law.cornell.edu/cfr/text/21/1306.04

    Accessed 3 November 2026.

52. S52 — 45 CFR 46.102: Human-subject research definitions

    Type: Primary federal regulation reproduced by legal institute

    Supports: Distinguishes research and human-subject concepts for covered activity.

    Limitation: Not every operational pilot is research; institutional review determination is needed.

    https://www.law.cornell.edu/cfr/text/45/46.102

    Accessed 3 November 2026.

53. S53 — SSA: Evidentiary requirements ↩ back to text

    Type: Official disability program guidance

    Supports: Longitudinal records and objective medical evidence affect disability review.

    Limitation: A diagnostic label alone is not sufficient proof of a medically determinable impairment.

    https://www.ssa.gov/disability/professionals/bluebook/evidentiary.htm

    Accessed 3 November 2026.

54. S54 — HRSA: 340B eligibility ↩ back to text

    Type: Official drug-program guidance

    Supports: Covered-entity/patient framework and record relationships.

    Limitation: Do not infer 340B eligibility from a generated diagnosis; current program litigation must be checked.

    https://www.hrsa.gov/opa/eligibility-and-registration

    Accessed 3 November 2026.

55. S55 — California Judicial Council: CACI 501, Standard of Care for Health Care Professionals (2026) ↩ back to text

    Type: Primary jury instruction reproduced by legal publisher

    Supports: Reasonably careful professional care in comparable circumstances; expert evidence ordinarily establishes the standard.

    Limitation: Civil jury instruction, not a stand-alone Medical Board disciplinary rule.

    https://www.justia.com/trials-litigation/docs/caci/500/501/

    Accessed 3 November 2026.

56. S56 — California Penal Code section 632 ↩ back to text

    Type: Primary statute reproduced by legal publisher; current page dated January 2026

    Supports: Confidential recording and consent principles.

    Limitation: Exceptions and interstate conflicts require case-specific analysis.

    https://codes.findlaw.com/ca/penal-code/pen-sect-632/

    Accessed 3 November 2026.

57. S57 — California B&P section 2266 ↩ back to text

    Type: Primary statute reproduced by legal mirror

    Supports: Adequate, accurate medical records and retention duties.

    Limitation: Not automatic discipline for every corrected draft error.

    https://law.justia.com/codes/california/code-bpc/division-2/chapter-5/article-12/section-2266/

    Accessed 3 November 2026.

58. S58 — Federal Rule of Civil Procedure 26 ↩ back to text

    Type: Primary procedural rule; companion authority

    Supports: Relevance, proportionality, work product and protective orders govern discovery.

    Limitation: Not all logs are discoverable; underlying material is not privileged merely because sent to counsel.

    https://www.law.cornell.edu/rules/frcp/rule_26

    Accessed 3 November 2026.

59. S59 — California Secretary of State: Bill Chapters and effective-date rules ↩ back to text

    Type: Official state explanation and chapter lists

    Supports: Ordinary regular-session statutes generally take effect January 1 of the following year.

    Limitation: Later operative dates, urgency provisions and other exceptions must be checked in each enactment.

    https://www.sos.ca.gov/administration/bill-chapters

    Accessed 3 November 2026.

60. S60 — CMS: Medicare payment systems ↩ back to text

    Type: Official multi-setting payment overview

    Supports: Hospital, outpatient and post-acute settings have different payment rules.

    Limitation: Screening reference, not a substitute for setting-specific billing advice.

    https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/html/medicare-payment-systems.html

    Accessed 3 November 2026.

61. S61 — California Judicial Council: CACI 505, Success Not Required (2026) ↩ back to text

    Type: Primary jury instruction reproduced by legal publisher

    Supports: Unsuccessful outcomes or reasonable errors do not alone establish negligence.

    Limitation: Does not excuse a failure to meet professional standards; not an AI-specific immunity.

    https://www.justia.com/trials-litigation/docs/caci/500/505/

    Accessed 3 November 2026.

62. S62 — Medical Board of California: Practice Information and Corporate Practice of Medicine ↩ back to text

    Type: Official Board guidance

    Supports: Clinical independence and limits on unlicensed corporate interference.

    Limitation: Entity-specific statutory exceptions and professional scope matter; software selection is not automatically unlawful practice.

    https://www.mbc.ca.gov/Licensing/Physicians-and-Surgeons/Practice-Information/default.aspx

    Accessed 3 November 2026.

63. S63 — California Business and Professions Code section 2056 ↩ back to text

    Type: Primary statutory text reproduced by legal publisher; current page January 2026

    Supports: Protection for qualifying advocacy for medically appropriate patient care.

    Limitation: Does not prohibit reasonable peer review or immunize a physician from Board discipline.

    https://codes.findlaw.com/ca/business-and-professions-code/bpc-sect-2056/

    Accessed 3 November 2026.

64. S64 — Microsoft Support: DAX Copilot in Epic mobile apps ↩ back to text

    Type: Vendor user documentation

    Supports: Use of DAX Copilot through Epic’s mobile applications (Haiku and Canto).

    Limitation: User documentation; does not establish a particular organization’s configuration.

    https://support.microsoft.com/en-us/dax-copilot/epic/dax-copilot-in-epic-mobile-apps

    Accessed 3 November 2026.

65. S65 — Physician Assistant Board of California: SB 697 frequently asked questions ↩ back to text

    Type: Official licensing-board guidance

    Supports: Unless the practice agreement requires it, the supervising physician no longer must review or countersign PA charts; the Board may impose review as a probation or reinstatement condition. Re-checked 3–4 November 2026.

    Limitation: General guidance; the actual practice agreement and attestation language control.

    https://www.pab.ca.gov/forms_pubs/sb697faqs.pdf

    Accessed 4 November 2026.

66. S66 — CalMatters Digital Democracy: bill histories for AB 1979, SB 503, AB 1637 and AB 2575 (2026) ↩ back to text

    Type: Legislative history reproduced from official records

    Supports: AB 2575 vetoed September 30, 2026; AB 1979 and SB 503 approved September 30, 2026; AB 1637 approved September 27, 2026. Re-checked 3–4 November 2026.

    Limitation: Secondary reproduction of official legislative records (leginfo.legislature.ca.gov).

    https://calmatters.digitaldemocracy.org/bills/ca_202520260ab2575

    Accessed 4 November 2026.

67. S67 — ASTP/ONC HTI-5 final rule (Federal Register document 2026-21943), released October 26 and published October 28, 2026 ↩ back to text

    Type: Federal rule; summarized by ASTP/ONC and by published legal analyses

    Supports: Removes the (b)(11) source-attribute and predictive-intervention risk-management requirements, according to ASTP/ONC’s HTI-5 page and published legal summaries (e.g., McGuireWoods, October 2026). Reported effective date December 28, 2026.

    Limitation: Operative text and effective date should be confirmed in the Federal Register; this article relies on summaries for the details.

    https://www.federalregister.gov/d/2026-21943

    Accessed 4 November 2026.

Editorial note. This investigation analyzes public product documentation, published research and public law, together with clinician reports that are treated as questions for verification rather than findings. It names no employing institution and no patient, describes no patient’s care, and is written in the author’s individual capacity. It does not allege that Microsoft, Nuance, Epic or any deploying organization has acted unlawfully. Neither Microsoft nor Epic was contacted before this edition; any response will be added with the date received. Product features, releases and law change; recheck primary sources before relying on any statement. General information here does not replace legal advice or clinical judgment about an individual situation.