AI Agents for Orthopedic PracticesSurgery, DME and Work Comp

Most automation proposals arrive at an orthopedic practice priced off its commercial payer mix. That is the first mistake, and it is expensive, because a meaningful share of orthopedic volume is not health insurance at all. Workers' compensation and personal injury have different authorization mechanics, different documentation obligations — causation, apportionment, work restrictions, return-to-work status — different payment timelines, and, critically, no eligibility API and often no electronic remittance. Automation built on the assumption of standard X12 270/271/278/835 transactions simply does not reach that revenue.

So before anyone demos anything, sort your practice into its actual rails. Ours is a three-way split, and the third one is where the unautomated hours live.

The scheduling picture is equally two-headed. An orthopedic practice reconciles a high-volume clinic — post-op checks, injections, new injury evaluations — against operating room block time that is allocated by a hospital or ambulatory surgery centre, is use-it-or-lose-it, and is booked well ahead. A cast and DME room and an in-office imaging suite are separate constrained resources on top of that. The clinic calendar and the OR calendar have different owners, different granularity and different consequences for failure, and the software that manages one usually has no visibility into the other.

One piece of evidence about physician time is worth citing here precisely because of how carefully it has to be cited. Sinsky and colleagues, publishing in the Annals of Internal Medicine in December 2016, found that for every hour of direct clinical face time, physicians spent nearly two additional hours on EHR and desk work. Orthopedics was one of the four specialties observed. The limits matter as much as the number: 57 physicians, 430 observed hours, four states, with 21 physicians self-reporting after-hours diaries showing one to two hours nightly, and the authors state the data came from “self-selected, high-performing practices and may not be generalizable.” It is a 2016 study. We cite it because it is real, and we date it because it is old — which is more than can be said for most numbers in this market.

This is the single most important architectural fact in practice automation, and almost no vendor deck contains it. The ONC/ASTP certification criterion at 45 CFR 170.315(g)(10) — the one behind every “we integrate with your EHR” claim — requires read services only. From the Certification Companion Guide, last updated May 15, 2026:

The § 170.315(g)(10) certification criterion requires Health IT Modules to support API-enabled “read” services for single and multiple patients. … These services specifically exclude “write” capabilities, where authenticated and authorized third-party applications would be able to create or modify EHI through a secure API.

— ONC/ASTP Certification Companion Guide, § 170.315(g)(10), updated May 15, 2026

Read that again with a surgical scheduler in mind. An agent can be guaranteed to read demographics, problems, medications, allergies, results, notes and coverage, to search, and to export in bulk. Everything else — booking the block, writing the note, filing the document, updating the insurance record, placing the order, posting the payment — is not covered by certification. It exists only if your EHR vendor chose to build it and chose to let your automation vendor use it.

Do not overstate the constraint either. Some EHR vendors voluntarily publish write-capable FHIR endpoints; Epic's developer documentation, for example, documents create support on resources including DocumentReference, Observation, QuestionnaireResponse, AllergyIntolerance, Condition, Communication and BodyStructure, and update support on a smaller set. The honest characterisation is that the documented write surface is narrow and resource-specific — it is not a general ability to modify the clinical record. And Epic is a health-system EHR; a three-surgeon independent practice generally cannot buy it at all, so for most readers this is a question about athenahealth, eClinicalWorks, NextGen, ModMed or a specialty orthopedic system rather than about Epic.

Is this changing? On the federal agenda, yes; in today's rules, no. ASTP/ONC published a proposed rule on December 29, 2025 signalling an intent to move beyond read-only interactions in future API requirements and proposing to remove the “third party seeking modification use” condition from the information-blocking Infeasibility exception. It remains a proposed rule; the comment period ran into late February 2026 and we located no final rule as of August 12, 2026. Write access is on the agenda. It is not a right today, and no procurement decision should assume it will be one by the time your build ships.

Booking a case is not one task. It is the reconciliation of a facility block, an implant or vendor representative, a prior authorization, and a set of medical and cardiac clearances that live in other practices' charts. The scheduler's real job is chasing the fourth item, and it is chased across fax machines, portals and phone calls that belong to organisations you do not control and cannot integrate with.

That makes pre-op clearance the highest-yield first agent in an orthopedic practice, for a reason that has nothing to do with how clever the model is: the entire coordination layer is computable from data the chart already holds, and none of it requires a write.Which cases are booked, on what dates, needing which clearances, from which consultants, requested when, received or not — that is a join across the surgical calendar and the document inbox. It is exactly the shape of problem a read-only agent is good at. How many staff hours it consumes across practices is not something we could source to any published measurement — capture it in your own Phase 0 baseline rather than accepting anyone's figure for it.

Note where the line falls. The agent may compute, draft, notify and escalate. It may not decide that a returned clearance is adequate, and it may not release the case. The reason is statutory rather than stylistic: 42 CFR 410.26(a)(1) defines auxiliary personnel as “any individualwho is acting under the supervision of a physician,” who has not been excluded from federal health care programs and who “meets any applicable requirements to provide incident to services, including licensure, imposed by the State.” Software is not an individual, cannot be excluded by the OIG and cannot hold state licensure. There is no “incident to” pathway for AI-performed professional work. Whatever the agent does is either an administrative task requiring no licensure, or a task whose professional component was performed by a named licensed human.

The second surgical-side agent worth building is a global-period guard. Orthopedic E/M denials cluster around a distinction CMS states plainly in the Medicare Claims Processing Manual, Chapter 12: “If evaluation and management services occur on the day of surgery, the physician bills using modifier ‘-57,’ not ‘-25.’ The ‘-57’ modifier is not used with minor surgeries because the global period for minor surgeries does not include the day prior to the surgery.” That single distinction generates a large share of orthopedic E/M denials, and it is deterministic — which makes it a rule engine, not a language model, and you should insist that your vendor implement it as one.

In-office dispensing — braces, boots, slings, bone stimulators — looks like retail and bills like a supplier relationship. That mismatch is where the money leaks. The payable artifact is not really the claim line; it is the documentation package behind it, and the package is assembled by whoever happened to be in the cast room.

The regulation is clear on one point and deliberately silent on several others. 42 CFR 424.57 defines a DMEPOS supplier to include a physician or Part A provider that sells or rents Part B covered items, and conditions payment on having a DMEPOS supplier number — but that requirement “does not apply to items furnished incident to a physician's service.” That carve-out is the reason many orthopedic practices dispense without a separate supplier enrollment.

What an agent can do here is narrow, unglamorous and worth real money: completeness checking before the item leaves the room.For each dispensed item, does the record hold the order, the medical-necessity documentation the payer's policy actually names, the delivery evidence, the patient acknowledgement, and the correct linkage to the encounter and the diagnosis? Every one of those is a read-only question. The agent computes the gap list and hands it to the person standing in the cast room while the patient is still there — which is the only moment at which a gap is cheap to close.

1. 1.Pre-dispense gap check: Against the specific payer's published documentation requirements for that HCPCS item, not against a generic checklist. The rule set is versioned content with a named owner, re-verified quarterly.
2. 2.Delivery evidence capture: The agent can prompt for it, timestamp it and file it into the work queue. Whether it can file it into the chart depends entirely on your write path — see the previous section.
3. 3.Post-dispense reconciliation: Items dispensed against items billed against items with complete documentation. Three lists that should be identical and rarely are. Surfacing the difference weekly is a read-only report and a genuine revenue finding.
4. 4.Denial pattern feedback: When a DME denial reason code enters your top five, the gap check that should have caught it is either missing or stale. Treat every new denial code as a defect report against the rule set.

What the agent must not do is decide medical necessity, or assert it. Necessity is a clinical determination that a licensed clinician attests to, and an attestation is the one act that no configuration permits software to perform. The agent surfaces whether the documentation supporting the clinician's determination is present. It does not form the determination.

Here is the part of an orthopedic practice that nobody's software models, and the one rail with no standardized transaction to automate against at all. Workers' compensation is a parallel payment universe: no explanation of benefits or coordination of benefits as commercial billing understands them, no in-network or out-of-network distinction, no deductible or out-of-pocket maximum, and rates set by state fee schedules rather than a single national schedule. Billing errors in this rail can carry regulatory consequences rather than merely a denial.

California is the most concretely documented example we can offer, and it illustrates the shape of the problem everywhere. Treatment requires a request for authorization submitted to the claims administrator, and Labor Code section 4610(i)(1) requires the utilization review determination “within five normal business days from the receipt of a request for authorization … but in no event more than 14 days from the date of the medical treatment recommendation by the physician.” Revised Division of Workers' Compensation utilization-review regulations are reported to have taken effect April 1, 2026, replacing references to the specific DWC form with a general “request for authorization” and requiring an incomplete request to be accepted or returned marked “not complete,” with reasons, within five business days.

So what is automatable? The clock and the packet — never the submission decision and never the clinical opinion. Obtaining a workers' compensation authorization is a document exchange with a claims administrator on state-specified forms and timelines, with no interoperable rail to build against. An agent can assemble the packet from the chart against the treatment guideline the state applies, prove and log transmission, watch the statutory clock, and escalate when a determination is overdue. A human signs and sends. That is not a compromise; it is the correct design, because the request carries a physician's treatment recommendation and the timelines attach to that recommendation.

Personal injury is a third rail again, and its automation is inventory rather than transaction. Payment runs through third-party liability, personal injury protection or medical payments coverage where the state has it, and liens or letters of protection where payment waits on settlement — which can be years. The useful agent here is an aging and obligation tracker: which cases have an executed lien or letter of protection on file, which attorney has which records request outstanding and for how long, which balances sit against an unsettled matter, and which documentation obligations remain open.

Orthopedic prior authorization runs on two fronts: imaging, frequently through a delegated radiology-benefit or musculoskeletal-benefit manager rather than the plan itself, and the procedure. The burden numbers most worth citing are the ones physicians reported themselves. The AMA 2025 Prior Authorization Physician Survey, a nationwide survey of 1,000 practising physicians fielded in December 2025 and released in May 2026, reports 40 prior authorizations per physician per week, 13 hours of physician and staff time weekly, and 40 percent of practices with staff working exclusively on prior authorization. Ninety-four percent say it increases burnout and 74 percent say denials have increased over five years. It is a self-reported physician survey and should be attributed as one — but it is a physicians' association surveying practising physicians and publishing its methodology, not a vendor measuring its own product.

One finding from that survey deserves to sit at the centre of any vendor conversation: 60 percent of physicians are concerned that AI is increasing, or will increase, prior authorization denial rates — while the entire vendor category sells AI as the cure. Both things can be true simultaneously, and a buyer should hold both.

Now the specifically orthopedic development. The CMS WISeR model was implemented January 1, 2026 and runs six performance years through December 31, 2031. It introduces machine-assisted review into Original Medicare in six states, each with a named participant company, and its selected service categories reach straight into orthopedic and spine practice.

The service categories listed in the CMS WISeR Provider and Supplier Operational Guide version 7.0, dated July 24, 2026, include arthroscopic lavage and debridement for the osteoarthritic knee, epidural steroid injections for pain management, percutaneous vertebral augmentation, cervical fusion under local coverage determinations L39741, L39758 and L39793, and several nerve-stimulator categories. The sites of service include the office at POS 11 and the ambulatory surgery centre at POS 24, so this is not a hospital-only programme. Four decision types exist — provisional affirmation, non-affirmation, provisional partial affirmation and dismissal — with resubmission and peer-to-peer review available.

There is a real exemption programme attached, and it is worth engineering for. Section 5 of the guide states that beginning July 2026, CMS and the WISeR participants automatically exempt providers and suppliers from prior authorization and pre-payment review on demonstrated compliance, on two stated requirements: submit at least ten prior authorization requests across WISeR select items and services during an assessment period, and achieve a minimum affirmation rate threshold. Exemptions are granted at the individual NPI level, not to the facility or organisation; they are added quarterly, held for at least a year, and removal requires at least 60 days' notice before the next quarter. CMS does not publish the affirmation threshold — each participant sets and publicly posts its own. So any specific percentage you are quoted is either that participant's own posted criterion, which you should read at the source, or a confusion with the Texas commercial gold-card standard, which is a different programme entirely.

WISeR is politically unstable and legally operative, and both halves of that sentence matter. The Government Accountability Office concluded on May 12, 2026 that the model meets the Administrative Procedure Act definition of a rule, which triggered expedited Congressional Review Act procedures; the Senate rejected the resolution of disapproval in late July 2026; and a House appropriations amendment that would bar CMS from funding the model passed committee in June 2026 and, as far as we can establish, has not been enacted. Do not plan on it disappearing, and do not describe it as cancelled.

A conflict worth knowing before you shortlist software: Cohere Health and Humata Health, both marketed as prior-authorization AI companies, are the entities reviewing Medicare prior authorization requests in Texas and Oklahoma under WISeR.Optum's Digital Auth Complete, live since January 2026, is powered by Humata Health. None of this is illegal and the arrangements are publicly disclosed. It is simply a conflict a practice should know about before buying prior-auth software from the company adjudicating its Medicare requests, and we have not seen it disclosed in a single vendor comparison article.

Two more calibrations. First, on how electronic “electronic prior authorization” actually is: the 2025 CAQH Index, published by DataSpring (formerly CAQH) and released February 19, 2026, puts electronic prior authorization adoption at 40 percent, up from 31 percent in the 2023 Index, built on data from more than 600 provider organisations and health plans representing 63 percent of insured lives. The corollary is the useful half — roughly 60 percent of prior authorizations are still not fully electronic in 2026. Disclose what that benchmark is: as of January 2026 the publishing organisation is for-profit and owned by health-plan-affiliated shareholders. It is an industry benchmark, not an independent one.

Second, the most quotable primary-source reality check available: CMS's own AI-assisted prior authorization model publishes fax cover-sheet instructions in a document dated July 2026. The guide directs that when submitting by fax, the prior authorization form goes on the page immediately after the cover sheet. Every one of the six participants publishes a fax number or a portal URL; none publishes an X12 278 or FHIR endpoint in the guide. Any claim that prior authorization became broadly automatable in 2026 collides with that document.

And a negative finding that belongs in every procurement conversation: we could not find a single payer that publicly states it accepts prior authorizations submitted by an autonomous AI agent, nor any payer policy that explicitly permits it. A payer accepting a FHIR transaction is not the same as a payer accepting an agent-authored submission; the standard is silent on who or what composed the payload. Nobody has blessed the agent.

Every implementation needs this table written down before the first line of code, because the boundary is where the liability sits and because “human in the loop” used as a slogan is worse than useless. Federal law draws its sharpest line not between AI and not-AI, but between administrative data movement and clinical recommendation. 21 U.S.C. 360j(o)(1)(A) excludes from the device definition software intended for “administrative support of a health care facility, including the processing and maintenance of financial records, claims or billing information, appointment schedules, business analytics … practice and inventory management … [and] determination of health benefit eligibility.” That is a statutory exclusion, not FDA grace, and almost everything in this article lives inside it.

Two entries deserve expansion. The first is attestation. The Medicare Program Integrity Manual, Chapter 3, section 3.3.2.4 — revision 13008, effective January 17, 2025 — names AI directly: the treating practitioner's signature “indicates that the physician/NPP affirms the note adequately documents the care provided,” and CMS notes that “this type of practitioner concurrence is also required when using Artificial Intelligence (AI) technology to capture the transcription of medical record entries.” The same section forbids reviewers from considering an attestation from anyone other than the author of the entry, forbids attestations where no associated record entry exists, and states that an attestation cannot be used to backdate a plan of care. There is no configuration in which an agent attests.

The second is the recommendation boundary. FDA's Clinical Decision Support Software guidance was issued January 29, 2026, superseding a January 6, 2026 version which itself replaced the September 2022 guidance. It is widely misdescribed. FDA did not reclassify single-output software as non-device: software providing a specific preventive, diagnostic or treatment output or directive still fails Criterion 3. What FDA announced is an enforcement discretion policyover that failure where only one option is clinically appropriate and the function otherwise meets the statutory criteria. Enforcement discretion is revocable without notice-and-comment; a statutory exclusion is not. Write it as discretion, and never write that FDA “approved” or “cleared” anything here.

FDA also moved automation bias into the Criterion 4 analysis. At its March 11, 2026 town hall, FDA stated that in determining whether a function meets Criterion 4 it considers both the level of automation and the time-critical nature of the clinician's decision-making, because “in situations that require urgent action, automation bias increases because there is not sufficient time for the user to adequately consider other information.” Read that as a consideration rather than a test — in FDA's own examples a time-critical workflow becomes a device when paired with a specific directive output. The defensible design conclusion is analytical: the more autonomous and the more time-pressured the workflow, the harder it is to claim the clinician is independently reviewing. In an orthopedic practice, almost nothing needs to be both.

This is the section the article exists for. Each phase has an owner, an entry criterion, an exit criterion and a defined response when it fails. Phases overlap deliberately — Phase 4 can start while Phase 3 is measuring — but no phase starts before its entry criterion is met, and no phase is declared done on a demo.

Failure in these systems is rarely dramatic. It is silent: the agent keeps producing confident output while quietly doing the wrong thing, and nobody notices for a billing cycle. So every failure mode below is paired with a detection signal — something observable in a dashboard or a log without anyone having to suspect a problem first — and a rollback that a non-engineer can execute.

The first row is the one to plan for, because it is the most likely and the least discussed. Where a vendor cannot get an API write, the write happens by robotic process automation — a robot typing into the EHR's user interface. RPA breaks on interface changes, is usually invisible in the EHR audit log as a system action, and attributes actions to whatever human's credentials it runs under. Ask any vendor how many payer portals and EHR screens it maintains automation against, and what its mean time to repair is after an interface change. No vendor publishes this. Getting a number in a contract is the point of asking.

Portal automation carries three risks a practice can evaluate without a legal opinion. Credential risk: a scraping vendor generally operates under your staff's portal login, so the audit trail says your employee did it — ask directly whether it runs on a named human's credentials. Unilateral termination risk: the payer or EHR can cut access without breaching anything, and your workflow breaks with no notice and no remedy; there is documented precedent of platform owners terminating third-party data access unilaterally. Fragility: a portal redesign breaks the bot. We found no FTC action, court ruling or regulatory guidance specifically addressing AI agents scraping payer portals, so anyone who tells you the legality is settled in either direction is wrong.

In the medical-practice AI market, almost every circulating operational statistic was published by a company selling software to the specialty it describes. Our house rule is that when we cannot find a non-seller source, we say so in the article. Naming the absence is more useful to an operator than repeating the number, and it is the only way a reader can tell the difference between our figures and a brochure's.

The general form of the problem deserves stating explicitly, because it governs how you should read every ranked list of AI vendors you encounter, including ours: there is no independent benchmark for accuracy in any of these categories. Not for agent platforms, not for prior-authorization automation, not for voice agents, not for ambient scribes. Every accuracy, containment, resolution and auto-approval figure in the market is vendor-published, none discloses a denominator, a payer mix or a service line, and the terms are not even comparable to each other — “containment,” “resolution,” “answer rate” and “routine interactions” are four different denominators, none defined publicly. Score vendors on things that can be checked: ownership and corporate stability from public record, named and verifiable EHR integrations, published security posture, whether a BAA is offered in writing, pricing transparency, and conflicts of interest. Those are all verifiable. Accuracy is not.

These are not stylistic objections. Each one is a question whose answer materially changes what you are buying, and each has produced a real failure in this market.

1. 1."We write back into your EHR" without naming the mechanism: Certified API access is read-only. So a vendor claiming write-back is either in a private commercial integration programme with that specific EHR, running a bot on a human's login, or not actually writing. Make them say which, in the contract.
2. 2.An accuracy, containment or auto-approval percentage on the pricing page: Every one is self-published with no denominator and no third party. Its presence tells you what the vendor thinks you will not check. Ask for the denominator, the payer mix and the service line; the answer is more informative than the number.
3. 3."HIPAA-compliant AI" presented as a property of the product: HIPAA attaches duties to covered entities and business associates, never to software. There is no OCR guidance defining a compliant AI product. Rewrite the claim in your own head as "used under a BAA with these specific controls" and then ask to see the BAA and the controls.
4. 4.No SOC 2 Type II report or BAA offered before the demo: Across the vendor research behind this cluster, not one vendor in the prior-auth and RCM category publicly stated on its own site that it offers a BAA, and SOC 2 Type II status was rarely published. That makes it a question you must ask in writing, and a reasonable vendor answers it in a day.
5. 5.The vendor is on the other side of your table: Cohere Health and Humata Health adjudicate Medicare prior authorizations under WISeR in Texas and Oklahoma while selling prior-auth AI, and Optum's Digital Auth Complete is powered by Humata. Availity, the free provider portal, is part-owned by payer organisations. None of this is improper; all of it is a disclosure you should have before signing.
6. 6.A static list of WISeR codes, or any "prior auth is solved in 2026" claim: The WISeR guide reached version 7.0 in nine months and still prints fax cover-sheet instructions. A vendor whose material has not been updated against the current guide version is telling you how often it re-checks its own facts.
7. 7.No named EHR integrations, only logos: In our vendor research, exactly one company in the prior-auth and RCM category published a fully verifiable named-integration list. Logos are not integrations. Ask for the customer reference on your specific EHR, at your specific version.
8. 8.A single point of failure with no export path: The February 2024 Change Healthcare cyberattack affected 192.7 million individuals — the largest healthcare breach in US history — and took down claims processing for practices that had no second rail. Ask what happens to your workflow when this vendor is offline for three weeks, and require a documented data-export format in the contract.
9. 9.Pricing that will not be stated: Across sixteen prior-auth and RCM vendors researched, zero published a price other than one clearinghouse's free tier for sponsoring payers, and across seventeen patient-communication vendors exactly one published a starting price. That is the category norm rather than a scandal — but it means every third-party "2026 pricing" page you find was written by a competitor or an affiliate, and none of it is reliable.
10. 10."Your EHR can't do this" — check first: In 2026 the EHR vendors moved into the agent layer themselves. Before buying a third-party platform, ask your own EHR vendor what agentic capability ships natively, on what timeline, and at what price. The honest buying question is no longer "which agent platform" but "what does my EHR already ship, and what is genuinely left over."

These are Frenchy Digital's published ranges for healthcare automation work. They are the same across this cluster, and they are ranges rather than a price because the honest answer depends on your write path, your payer mix and how much of your revenue sits on the workers' compensation and personal-injury rails.

Senior-led engineering runs $150–$225 per hour; ongoing retainers run $2,500–$9,500 per month; every build carries a 30-day post-launch warranty; and full source-code and IP ownership transfer to the client. We send a written, fixed-price, phased proposal within 5 business days of the discovery call. Frenchy Digital is a senior-led Black-owned Los Angeles agency; you can reach us at +1 (424) 272-5601 or book directly at calendly.com/frenchydigital/discovery-call.

On payback, we will not hand you a multiplier, because every ROI figure in this market is modelled by the party selling the software. What we will do is tell you the arithmetic to run on your own Phase 0 baseline. The AMA's figure of 13 hours of physician and staff time per week on prior authorization is a starting point for the burden, but the number that matters is yours, at your loaded labour cost. Add to it the dollars sitting in your top denial codes that trace to documentation gaps rather than clinical disagreement, and the balances aging on comp and PI cases whose obligations nobody is tracking. That figure, minus the run-rate cost of the agent and the human review time it still requires, is your payback. If your vendor computes it for you from their own benchmark instead of your data, you are reading a brochure.

Every article should carry this section and almost none do. These are the specific things we went looking for and did not establish to our own standard. Where we could not verify something, we left it out of the body or hedged it explicitly — and where a fact matters to your build, this is your list of things to check before you rely on it.

• DMEPOS accreditation and surety-bond position for physician practices: The supplier-number carve-out for items furnished incident to a physician's service is confirmed in 42 CFR 424.57. Whether a given orthopedic practice qualifies for the statutory accreditation exemption, and what bond position applies, is not. We print no bond amount and no blanket exemption claim.
• The California DWC utilization-review regulation effective date: The April 1, 2026 date rests on utilization-review industry summaries rather than the DWC rulemaking record, which we could not parse. Verify it directly before building a California-specific workflow around it.
• Workers' compensation as a general proposition: No single primary document establishes the general characterisation of workers' comp as a parallel payment universe; it is synthesised from state agency fee-schedule material and specialty billing sources. The California statutory citation is specific; the general framing is not.
• Exact Medicare payment amounts for any code named here: We did not fetch the Physician Fee Schedule Addendum B, so we print no Medicare dollar figures anywhere in this article.
• The WISeR affirmation-rate threshold: CMS does not publish it; each participant sets and posts its own. Any specific percentage you are quoted for WISeR exemption is either a participant's own posted criterion or a confusion with the Texas commercial gold-card standard.
• Whether the House appropriations rider against WISeR was enacted: It passed committee in June 2026. We found no evidence of enactment and therefore do not describe WISeR as defunded.
• Any vendor's SOC 2 Type II status, HITRUST certification or published BAA offer: Across the vendor research behind this cluster, these were rarely published on vendors' own sites. We treat that as a buying instruction — ask in writing — not as a finding about any named company.
• Any vendor price: Effectively none is published in these categories. Every third-party pricing page we examined was written by a competitor or an affiliate.
• State gold-carding statute citations outside Texas: Several states are named in secondary coverage as having gold-carding laws. We could not verify the citations or effective dates, so we name none of them here. Reporting also suggests state gold-card programmes have delivered limited relief in practice — do not model savings on one.
• The effective-date reading of Colorado's SB 26-189: Our source materials conflict. The enrolled bill's own effective-date section places the substantive duties at January 1, 2027, applying to consequential decisions made on or after that date, with narrow rulemaking provisions effective on passage. A separate reading placed part of the act earlier in 2026. We follow the enrolled text and flag the disagreement rather than resolving it for you.
• State AI-in-utilization-review statutes: A growing number of states have legislated on payer use of automated decision systems in medical-necessity determinations. We could not verify individual bill numbers or effective dates, and bill numbering in the secondary coverage we found is itself unreliable. We name no bill we did not read.
• Prompt injection through faxes, referral PDFs or payer portals in a live practice: No published study exists that we could locate. Our reasoning about those channels is extrapolation from dialogue and imaging research and is labelled as such in the text.

A last note on the regulatory backdrop, because it moves. The HIPAA Security Rule notice of proposed rulemaking published January 6, 2025 is still only proposed, with final action projected for July 2027 on the Unified Agenda — so the 2003 Security Rule as amended in 2013 governs your practice today, and encryption at rest remains addressable rather than required. Do not let a vendor tell you that multi-factor authentication, asset inventory or encryption at rest are currently mandated by that rule; they are proposals. Separately, CMS-0057-F binds payers rather than practices: decision timeframes, specific denial reasons and public prior-authorization metrics are live now for covered payers, and the FHIR prior authorization API is a January 1, 2027 obligation on the payer side. Your practice benefits from that API only if your EHR or vendor builds a client against it — payer readiness is not practice capability.