AI Agents for Optometry & OphthalmologyThe Two-Payer Build

Most software written for eye care fails for the same reason. It assumes that "vision insurance" and "health insurance" are two payers competing for the same visit. They are not. They are two different products, with different adjudication systems, different eligibility rails, different fee mechanics and different definitions of what counts as a covered service. Which one applies depends on the reason for the visit — and the reason for the visit is frequently only settled once the exam is underway.

A routine refractive exam that discovers diabetic retinopathy changes payers mid-visit. Nothing about the appointment changed. The patient did not move. The chair did not move. But the claim now belongs to a different system, and a front desk that already collected on the wrong assumption now has a refund, a rebill, or a write-off. This is not an edge case in an eye care practice; it is a routine occurrence, and it is the reason the payer-routing decision is still human almost everywhere. We are not going to tell you how often it happens in your practice, because we have found no non-vendor source that counts it — which is exactly why counting it is the first deliverable of the discovery phase.

The structural split as it affects automation. Refraction exclusion: Medicare Benefit Policy Manual, Chapter 16, §90.

The refraction line deserves its own sentence, because it is one of the few things in this specialty that is settled beyond argument. Chapter 16, §90 of the Medicare Benefit Policy Manual states that expenses for all refractive procedures, whether performed by an ophthalmologist (or any other physician) or an optometrist and without regard to the reason for performance of the refraction, are excluded from coverage. That is a statutory exclusion, not a medical-necessity determination. It does not become covered because a disease was present, and no amount of documentation moves it.

Two more structural facts shape everything downstream. The first is that eye care is imaging-dense. OCT and fundus photography are ordinary parts of a routine day, and imaging is where the regulatory line around AI stops being a matter of degree and becomes absolute. The second is that where a practice runs an optical dispensary, it has attached a retail business — with inventory, suppliers, lab turnaround, remakes and a dispense appointment, attached to a clinical business that runs on entirely different rules. Automating one without understanding the other produces a system that is confidently wrong at exactly the moment the two touch.

This article is the implementation guide. It assumes you have already decided that some administrative automation is worth doing and are now asking, in order: what should we build, in what sequence, who owns each phase, how do we know a phase succeeded, and what do we do when it does not.

Before any build, get the regulatory calendar straight, because a meaningful share of what practices are told in 2026 describes obligations that do not exist, imposed on parties that are not the practice. Here is the ground as of today, with the source for each line.

Regulatory ground as of August 12, 2026. Primary sources: 21 U.S.C. §360j, ONC/ASTP Certification Companion Guide, 42 CFR §422.122, 45 CFR §92.210.

The most useful sentence in federal law for a practice administrator is in the device statute, and almost nobody reads it. 21 U.S.C. §360j(o)(1)(A) excludes from the device definition software intended for administrative support of a health care facility, and then enumerates what that means:

"…the processing and maintenance of financial records, claims or billing information, appointment schedules, business analytics, information about patient populations, admissions, practice and inventory management, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, and laboratory workflow"

— 21 U.S.C. §360j(o)(1)(A)

Read that list against an eye care practice. Appointment schedules — your exam lanes and pre-testing resource. Claims and billing information — your two-payer routing paperwork. Practice and inventory management — your optical dispensary, named in the statute. Determination of health benefit eligibility — your 270/271 checks. Population health management — your diabetic retinopathy and glaucoma recall lists. Almost everything worth automating in this specialty is outside the device definition by statute, not by FDA's grace. That is the safest ground you will ever stand on, and it is where a first build belongs.

The moment software starts recommending to a clinician, it moves into §360j(o)(1)(E) and has four criteria to satisfy. FDA's 2026 guidance did not soften Criterion 3 as much as the market claims. A function providing a specific preventive, diagnostic or treatment output or directive still fails it. What FDA announced is an enforcement discretion policy over that failure. Its own words at the March 11, 2026 town hall:

"In cases where a software function provides a specific preventive, diagnostic or treatment output or directive, the software function fails criterion three… if only one recommendation is clinically appropriate and the software function otherwise meets all criteria under section 520(o)(1)(E), FDA intends to exercise enforcement discretion, meaning that FDA does not intend to enforce requirements under the FD&C Act, for such functions."

— FDA town hall transcript, March 11, 2026

Write that down as enforcement discretion, never as exemption or approval. Discretion is a posture FDA can withdraw without notice-and-comment; a statutory exclusion is not. The guidance's own parallel sentence at page 10 uses "option" where the transcript says "recommendation" — same policy, different noun, and worth quoting from whichever document you are actually citing.

On the state layer, three statutes matter operationally for an eye care practice and one is frequently misdescribed. California AB 3030, in force since January 1, 2025, requires a generative-AI disclaimer and instructions for reaching a human on communications pertaining to patient clinical information — and expressly defines that term to exclude "administrative matters, including, but not limited to, appointment scheduling, billing, or other clerical or business matters." It also does not apply where the communication was read and reviewed by a licensed provider. Texas HB 149 §552.051(f) is broader: it requires a provider using AI in relation to health care service or treatment to disclose that use no later than the date the service is first provided, with no human-review exemption on its face. Texas SB 1188 permits a practitioner to use AI for diagnostic purposes provided the practitioner is acting within the scope of the licence "regardless of the use of artificial intelligence," reviews all records created with AI, and discloses the use. Five words in that statute carry the whole doctrine: regardless of the use of artificial intelligence. The licence, and therefore the liability, does not move.

California AB 489, in force since January 1, 2026, is the one that catches practices by surprise. It makes the existing prohibitions on titles implying a health care licence enforceable against the entity deploying AI whose advertising or functionality uses them. Each use is a separate violation and the relevant licensing board has jurisdiction. Naming your intake agent after a clinical role is a per-use violation in California. Name it after the practice.

This is the single most important architectural fact in any medical-practice AI build, and it is the one most often glossed over in a sales call. Certified API access is read-only. The ONC/ASTP Certification Companion Guide for §170.315(g)(10), last updated May 15, 2026, is explicit:

"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 carefully and the whole market re-sorts itself. An agent can read your chart through a regulated, portable pathway in any certified EHR. Every write— booking the slot, posting the charge, filing the note, updating the problem list, touching the recall registry — happens through one of exactly three mechanisms: a vendor-discretionary write interface governed by that vendor's commercial terms and app-review process, robotic automation driving the user interface, or a human being. There is no certification requirement compelling any EHR vendor to offer the first, which is why "integrates with Epic" and "writes into Epic" are different claims with different price tags and different failure modes.

There is a related pair of clocks worth knowing, because vendors sometimes cite them loosely. Under 45 CFR §170.404(b), a Certified API Developer must complete verification within ten business days of a registration request, and must register and enable applications for production use within five business days of completing that verification. Those are two distinct clocks — do not let anyone sum them into a single figure — and they attach to the certified read pathway, not to whatever private write pathway is being offered alongside it.

There is a security dividend hiding in this constraint, and it is worth taking. An agent that cannot write cannot be injected into writing. Read-only by default is the strongest available control against prompt injection, and it costs nothing. When you do enable writes, enable exactly one action, reconcile it daily, and let it run clean for four weeks before adding a second.

Eye care practices tend to have five high-volume administrative workflows. Not all five are equally automatable, and the difference is not about how hard the engineering is — it is about which side of the read/write boundary the workflow sits on and whether the decision at its centre is administrative or clinical.

Sort every proposal you receive into one of three buckets and make the vendor tell you which one it is in. Read-and-reason, available now on any certified EHR: anything that computes over data the chart already holds and hands a human a conclusion — global-period expiry dates, imaging code-pair conflicts, recall lists, missing-document detection, packet assembly. Write, vendor-discretionary: booking, charge posting, note filing, problem-list updates. Outside the health-IT rail entirely: vision plans, optical labs, and the surgical facility's own scheduling system. Each item in that third bucket is its own integration, none is standardized, and several are governed by someone else's terms of use rather than by health-IT regulation.

The highest-yield first build in this specialty is almost always the one nobody asks for: a daily worklist of calendar-derivable events. Which post-operative global periods expire this week. Which co-managed patients have no transfer agreement on file. Which patients are past their monitoring interval. Which optical orders have been at the lab longer than their expected turnaround. Which claims from yesterday carry a same-day imaging pair that will bounce. None of that requires a write, none of it requires a clinical judgment, and all of it is invisible today because it lives across four systems that never speak to each other.

A busy eye care practice generates a great deal of imaging, and imaging creates two separate problems: a billing-deconfliction problem, which software is genuinely good at, and a regulatory boundary, which software must not go near.

Start with the boundary, because it is absolute. Under 21 U.S.C. §360j(o)(1)(E), software intended to acquire, process or analyze a medical image is outside the non-device exclusion entirely. Not "fails a criterion and gets enforcement discretion." Outside. FDA's own worked examples in the 2026 guidance draw the line with unusual clarity: a function that summarizes a radiologist's own findings into a report draft, including a guideline-based recommendation for the clinician to review, revise and finalize, sits inside enforcement discretion — but the same function analyzing the image itself to generate findings or measurements fails Criterion 1 and is a device.

Now the deconfliction problem, which is exactly the sort of tedious, rule-bound, high-frequency check that read-only automation handles well. The 2026 NCCI Policy Manual carries several ophthalmology-specific rules that generate a steady drip of preventable denials.

Coding rules from the CMS National Correct Coding Initiative Policy Manual, 2026 revision; the general-ophthalmological-services rule sits at Chapter XI. Device boundary from 21 U.S.C. §360j.

One detail in that table is worth pulling out because it is the one most often reversed in practice: when both fundus photography and OCT are reported for the same eye on the same day, NCCI puts the modifier — 59 or XU — on 92250. Not on the OCT code. A pre-submission check that verifies the direction of the modifier, not merely its presence, will catch a class of denial that is otherwise easy to absorb as noise.

The general ophthalmological services rule catches even more revenue, in the other direction. NCCI states that when E/M codes are reported, CPT 92002–92014 shall not be reported separately, because the E/M service includes the general ophthalmological services. A practice that reports both is not being clever; it is generating a denial and, at volume, an audit pattern. A pre-submission flag costs nothing and prevents both.

Cataract surgery introduces the other structural complexity in this specialty: a post-operative global period, frequently split between a surgeon and a co-managing optometrist, executed through a documentation workflow that most practice management systems do not model at all.

The Medicare Claims Processing Manual, Chapter 12, sets out the mechanism precisely. Where physicians agree on transfer of care during the global period, the surgeon reports the surgical code with modifier -54 and the post-operative provider reports the same code, same date of service, with modifier -55. Then come three requirements that are pure documentation, and pure automation opportunity:

1. 1.The dates must be on the claim: Providers need not specify on the claim that care has been transferred. However, the date on which care was relinquished or assumed must be shown on the claim, in the remarks field or free-text segment. An agent can compute and populate those dates from the schedule and the transfer record; a biller confirms them.
2. 2.The written transfer agreement lives in both charts: Both the surgeon and the physician providing the post-operative care must keep a copy of the written transfer agreement in the beneficiary's medical record. An agent can check whether the document is present and flag every co-managed patient where it is not. It cannot produce the agreement — that is a signed clinical hand-off between two clinicians.
3. 3.The receiving physician must have done something: The receiving physician cannot bill for any part of the global services until he or she has provided at least one service. An agent that watches for -55 claims with no corresponding post-operative encounter catches this before it becomes a refund.

Global-period awareness pays for itself in a second way that has nothing to do with co-management: it prevents a post-operative visit inside the global window from being billed as a separate encounter. That is a routine, expensive, entirely avoidable error, and it is a pure date calculation over data the chart already holds.

One adjacent detail worth knowing if your practice also touches therapy services: the Medicare Benefit Policy Manual, Chapter 15, restricts who may certify a therapy plan of care, and states that optometrists may certify only low vision services. It is a narrow rule, but it is exactly the sort of constraint an automation layer should encode once rather than rediscover through denials.

The optical dispensary is the part of the practice that most clinical software ignores and most retail software mishandles. It runs on its own clock: a frame and lens order goes to a lab, the lab has a turnaround time, the finished product comes back, and a dispense appointment has to be scheduled with the patient — who may or may not still be reachable at the number they gave three weeks ago. Then there are remakes, which restart the whole cycle and which nobody tracks well.

Two things make this tractable. First, it is squarely inside the statutory administrative exclusion — practice and inventory management is in the §360j(o)(1)(A) list by name — so there is no device question to answer. Second, unlike the vision-plan eligibility problem, most of the data lives in systems the practice controls: your own order records, your own dispense calendar, your own lab relationships.

• Order aging: Every open optical order with days elapsed against the expected lab turnaround, and an escalation when it is exceeded. It is the optical report we most often find missing when we walk a practice's systems.
• Dispense scheduling prompts: When an order returns, the patient needs an appointment. An agent can produce the outreach list and draft the message; the send should be scoped to an order-ID match so a message can never be generated without a real order behind it.
• Remake tracking: Remake rate by lab, by lens type and by dispenser, measured rather than felt. It is a supplier-quality metric and a training metric at the same time.
• Unbilled refraction reconciliation: Refraction is patient- or vision-plan responsibility. An agent can flag exams where a refraction was documented and no corresponding charge exists — a quiet, recurring leak, and one you can size from your own data rather than from anyone's benchmark.
• Inventory against dispensing: Frames on the board versus frames sold, and which suppliers are turning. Retail arithmetic, done nightly instead of quarterly.

The place where optical and clinical genuinely collide is messaging. A text that says "your glasses are ready" is an administrative communication, outside California AB 3030's definition of patient clinical information and squarely inside the device statute's administrative exclusion. A text that says anything about what the exam found is not. Build the message taxonomy first, write down which classes the agent may send unreviewed, and enforce that list in code rather than in a policy document nobody reads.

This is the part of the article that matters. Not a list of benefits — a sequence, with a named owner per phase, an entry criterion that says when you are allowed to start, an exit criterion that says when you are allowed to move on, and an explicit instruction for what to do when the phase fails. A programme that cannot say what "done" means for phase two will still be in phase two in a year.

Three rules govern the whole sequence and they are more important than any individual phase.

1. 1.No phase starts before the previous one has met its exit criterion: Not "mostly met." Met, measured, and written down. The overwhelming majority of failed automation programmes we are called in to rescue skipped an exit criterion because the next phase looked more exciting.
2. 2.A phase that fails its exit criterion twice gets frozen, not expanded: The instinct when a recommendation layer produces a high override rate is to add more data to it. The correct move is to stop, sit at the front desk, and find out what the humans know that the model does not. Almost always the answer is context that never reached the system.
3. 3.Writes come last and come narrow: One write action, reconciled daily, four clean weeks, then the next. Every write is a vendor-discretionary commercial arrangement and every write is a blast-radius expansion. Earn each one.

On the parallel compliance track, which runs alongside every phase rather than as a phase of its own: an executed business associate agreementchain before any PHI moves, and the chain matters — under 45 CFR §160.103 a model provider processing PHI is a business associate, the agent-framework vendor in front of it is a business associate, and the model provider's own cloud host is a subcontractor business associate requiring a downstream agreement. A single BAA with the application vendor does not close the chain.

Then the technical safeguards that actually bind you today. 45 CFR §164.312(a)(2)(i) makes unique user identification required, not addressable, and §164.312(a)(1) already frames access rights as attaching to persons "or software programs" — so the agent needs its own identity, not a borrowed clinician login. §164.312(b) requires audit controls that record and examine activity in systems containing ePHI. And minimum necessaryunder §164.502(b) applies to context windows: retrieval assembled for a billing, scheduling or recall agent is not a treatment disclosure and gets no exception. "Dump the whole chart into the prompt" is the specific practice that rule reaches.

Write this table down, put it in the statement of work, and make the vendor sign it. Ambiguity about what the agent may decide is how a practice ends up with a compliance problem that nobody chose.

The attestation row is the one worth reading twice, because it is the cleanest statement in federal policy on this whole subject and it names AI explicitly. The Medicare Program Integrity Manual, Chapter 3, §3.3.2.4, effective January 17, 2025:

"The treating physician/non-physician practitioner's (NPP's) signature on a note indicates that the physician/NPP affirms the note adequately documents the care provided. We note this type of practitioner concurrence is also required when using Artificial Intelligence (AI) technology to capture the transcription of medical record entries."

— CMS Medicare Program Integrity Manual, Chapter 3, §3.3.2.4

The AI does not sign, and its non-signature is fine — because the practitioner's signature is doing the attesting for both. CMS's model attestation statement is first-person, credentialed, and states in terms that the signer understands that any falsification, omission or concealment of material fact may subject them to administrative, civil or criminal liability. The manual also forecloses the workaround: reviewers shall not consider attestation statements from someone other than the author of the record entry, and attestation cannot be used to backdate. There is no configuration in which an agent attests.

One caution about human-in-the-loop as a control, because it is oversold. FDA's 2026 materials discuss automation bias — the propensity of humans to over-rely on a suggestion from an automated system, producing errors of commission by following incorrect advice and errors of omission by failing to act because nothing prompted them. FDA considers the level of automation and the time-critical nature of the decision when determining whether Criterion 4's independent-review requirement is met. And the Nature Communications work on vision-language models found that adversarial prompts embedded in medical imaging data are non-obvious to human observers. A reviewer who cannot see the problem cannot review it away. Design for a reviewer who is busy, and measure whether review is actually happening: track override rates, review times and dismissal rates per reviewer, per workflow, every month.

Every automation programme in this specialty breaks in roughly the same order. Knowing the order lets you instrument for it in advance, which converts an outage into a metric. Each row below names the failure, the signal that detects it, and the rollback — decided before launch, not during the incident.

The first row is the one that will happen to you, so plan for it explicitly. A pre-visit payer route is a prediction, and the exam is allowed to falsify it. The correct design is not a smarter predictor; it is a workflow in which the prediction is cheap to be wrong about. That means the route is advisory, the front desk owns the final call at check-out, and the mismatch rate is a monitored metric rather than a source of blame.

The second row is the one that will be hidden from you, which is worse. Portal automation does not fail loudly; it fails by returning nothing, or by returning stale data, on a Tuesday, for one plan. Per-portal daily success rates with a two-failure alarm are the minimum instrumentation. And there is a contractual dimension that engineering conversations tend to skip: automating a third party's portal happens under that third party's terms of use, and the practice — not the vendor — is usually the party with the relationship at risk. Ask who indemnifies whom.

The last row is not technical at all and it is the most common cause of quiet failure. If staff stop opening the worklist, the programme has already ended and nobody has said so. Usage telemetry per workstation against schedule volume is a two-hour build and it is the single best early warning you can have. When it drops, the fix is nearly always that the recommendation arrived at the wrong moment in the workflow, not that the recommendation was wrong.

On prompt injection specifically: treat it as unsolved. The best non-vendor evidence available is a controlled simulation published in JAMA Network Open in December 2025, reporting attacks succeeding in 94.4% of 108 evaluations at turn four and persisting in 69.4% of follow-ups, with the authors concluding that even flagship models with advanced safety mechanisms showed high susceptibility. Its limits belong with it: a controlled simulation rather than field data, a main experiment run on lightweight models with a five-dialogue proof of concept on flagship models, and disclosed company roles among three co-authors. We could find no published study of prompt injection through patient portal messages, referral faxes or payer portals in a live practice. That absence is itself the finding: anyone selling you an injection-detection accuracy rate is selling you a number no independent party has ever verified.

This section is the reason to trust the rest of the article. Here is what we went looking for and did not find, stated plainly rather than papered over.

• No independent accuracy benchmark exists for any AI product in this category: We searched for randomized, peer-reviewed or third-party evaluations of multi-step administrative agents in medical practices and found none. Every accuracy, automation, resolution or touchless rate in this market is published by the company that benefits from it, on its own definitions, on its own customer set, usually with no denominator disclosed. We exclude accuracy from any vendor comparison by design.
• Optical capture-rate benchmarks: Every citation we followed led to optical-industry vendor content. No survey, no methodology, no origin. Not printed here.
• Refraction fee ranges: Circulated widely in ophthalmic trade press and billing-service blogs. No survey and no source located. Not printed here.
• The cataract co-management revenue split: The -54/-55 mechanism is primary from CMS Chapter 12. The commonly quoted percentage split — and the "apportioned by days of responsibility" gloss that accompanies it — are trade-press and vendor help-centre material with no CMS document behind either. Not printed here as fact.
• The 90-day global period on cataract surgery: Confirmable in the Physician Fee Schedule relative value file, which we did not fetch. We describe the global-period mechanism and the modifier pair, both of which are primary, and we print no specific Medicare dollar amounts anywhere in this article because we did not fetch the fee schedule addendum.
• Colorado's interim status, not its effective date: The effective date itself is not in doubt: the enrolled SB 26-189, SECTION 5, sets January 1, 2027 and applies the act to consequential decisions made on or after that date, and the earlier date that circulates comes from a general notice about bills passed without a safety clause, which this bill has. What we could not verify from primary documents is the interim — the operative status of the predecessor statute SB 24-205 during the second half of 2026, and a reported April 2026 federal-court filing in which the attorney general said he did not intend to enforce it pending rulemaking. We did not fetch that order and we name no case. Have counsel read the enrolled text and check the rulemaking docket.
• Whether 45 CFR §92.210 is subject to any injunction or pending rescission: We could not verify this either way. What we can say is that it appears in the current Code of Federal Regulations as fetched, and that its inventory-and-mitigation duty is therefore a live obligation to plan around.
• Vendor BAA availability and terms: Whether a particular model provider will sign a business associate agreement, and on which service tier, is a claim sourced only to that provider's own terms and it changes without notice. Re-check the provider's current documentation on the day you sign, not on the day you read an article.
• Vision-plan technical capability: We describe the absence of a standard vision-plan eligibility transaction as a structural fact of the market. We did not audit every vision plan's technical offerings, and a specific plan may expose something we did not find. Ask yours directly.
• State law outside California, Texas and Colorado: A wave of 2026 state health-AI statutes exists, mostly binding payers rather than practices, but the bill numbering circulating in secondary trackers is unreliable — one commonly cited example uses a bill-numbering convention the state in question does not use. We name no statute we did not read.

Vendor selection in this category is mostly an exercise in noticing what is not being said. These are the specific tells, and the specific question each one should trigger.

Add one more to that list that has nothing to do with the product: roster freshness. This market consolidates fast, and a vendor comparison written six months ago may be describing companies that no longer exist independently. One concrete example from the patient-communication category: TrueLark, an AI front-desk automation product, was acquired by Weave — announced May 5, 2025 and closed later that month for $35 million in cash and equity — and no longer exists as an independent purchase. Weave itself is a publicly traded platform serving optometry among other verticals, and it publishes a starting price of $199 per month, which makes it one of very few vendors in this space with any published price at all. Neither of those facts makes it right or wrong for your practice. The point is narrower: before you evaluate anyone, confirm that the company still exists in the form the comparison describes.

And be sceptical of pricing opacity in both directions. "Contact sales" is not a scandal, but it does mean you cannot benchmark, and it means the price you are quoted reflects what the vendor thinks you will pay. Ask for the price list. Ask what changes it. Ask what happens at renewal.

Frenchy Digital scopes healthcare automation in four bands. These are the same figures we quote across every practice type, because the engineering discipline does not change with the specialty — only the domain does.

Senior-led rate is $150–$225 per hour. Ongoing retainers run $2,500–$9,500 per month. Every engagement carries a 30-day post-launch warranty, and you receive a written, fixed-price phased proposal within 5 business days of the discovery call. Full source-code and IP ownership transfers to your practice at delivery — there is no scenario in which your automation becomes hostage to our continued involvement.

On payback, we will not hand you a modelled return before we have seen your data, because the honest inputs are practice-specific: how many visits switched payer route last year and what each one cost you; how many claims bounced on a same-day imaging pair; how many post-operative visits were billed inside a global period; how many co-managed patients have no transfer agreement on file; how many optical orders sat at the lab past turnaround; how many recall-eligible patients never came back. Those are all countable from data you already have, and counting them is the first deliverable of the discovery phase. A vendor who quotes you a return before counting is quoting you someone else's practice.

What the discovery engagement produces, concretely: a payer-split baseline for twelve months of visits; a ranked list of denial reasons by dollar; a written answer from your EHR vendor on which write actions it will expose and on what terms; a message taxonomy separating administrative from clinical communications against the states you operate in; a human-in-the-loop boundary table adapted to your staffing; and a phased plan with the entry and exit criteria filled in for your practice rather than for a generic one.

Book a free 60-minute discovery call or call +1 (424) 272-5601. Frenchy Digital is a senior-led Black-owned agency based in Los Angeles.

Eye care is one of the better candidates for administrative automation in medicine, and for a reason that has nothing to do with how advanced the technology is. It is that most of the recurring pain in this specialty is calendar-derivable and rule-bound: global periods that expire, monitoring intervals that lapse, code pairs that conflict, orders that age at a lab, transfer agreements that are missing from a chart. None of that requires a model to be clever. It requires a system that looks across four disconnected systems every night and hands a human a short, correct list in the morning.

What it does not require, and must not include, is a machine making the calls that belong to a licensed human. The payer route when the exam changes the picture. The monitoring interval. The reading of the scan. The signature. Each of those has a specific legal reason attached, and each of those reasons is older and more settled than the technology being sold against it.

So the sequence is: read-only first, because certification guarantees it and because an agent that cannot write cannot be injected into writing. Recommendations second, with the override logged, because the override rate is the only honest measure of whether the recommendation is any good. Pre-submission checks third, because they pay immediately and they cannot hurt anyone. Administrative messaging fourth, scoped in code rather than in a policy. And write enablement last, one action at a time, reconciled daily, after your EHR vendor has told you in writing what it will actually let you do.

Build it in that order and the worst case is that you have a very good nightly worklist and a practice that knows more about its own operations than it did before. Build it in the reverse order — writes first, on a vendor's promise, with the clinical boundary left vague — and the worst case is considerably worse than nothing.