The MyEyeDr revenue cycle automation case study, with the numbers verified and the part the case study skips
Yes, the MyEyeDr revenue cycle automation case study is real. It is published by UiPath, titled “MyEyeDr. Sharpens the Focus on Growth with Automation.” The named source is Cassie Haag, Director of Systems and Analytics. The documented figures: cash application touched $186 million in remittances in one year, $6.9 million in eyewear claim revenue retained in 2022, over $310,000 saved in payroll on automated claims movement, and 385,000 provider applications processed a year across roughly 850 vision care centers.
Source checked live on 2026-06-22: uipath.com/resources/automation-case-studies/my-eye-dr-growth-with-automation. This is UiPath’s case study, not Mediar’s. We did not run this deployment, and the rest of this page is careful to keep that line clear.
If you searched for this, you probably want two things: the actual numbers, and an honest read on whether the approach behind them is the one you should copy. Most pages on revenue cycle automation give you neither. They paraphrase a vendor blog or list generic benefits. This one reproduces the verified figures from the source, then walks through where the program gets expensive over time and how the same eye-care RCM work runs on a different mechanism.
The figures, straight from the case study
Every number below appears in UiPath’s published case study and was re-checked against the live page on 2026-06-22. Nothing here is estimated or rounded by us.
The number the headline hides: automation does 70 to 80 percent, not 100
Cash application is MyEyeDr’s largest use case, and it is worth reading the split precisely because it is the most honest line in the case study. Haag describes it like this:
“It gets us 30% there, and RPA picks up where the software leaves off and does another 40% to 50%.”Cassie Haag, Director of Systems and Analytics, MyEyeDr., in the UiPath case study
Add it up. The packaged software handles 30 percent. The bots add another 40 to 50. People still close the last 20 to 30 percent of a $186M stream. That is not a knock on MyEyeDr; it is the reality of screen-driven automation against payer remittances. The exceptions, the unmatched payments, the portal that changed its layout last Tuesday, all fall back to a human. A program this large carries a standing remediation cost that no case study puts a dollar figure on.
Where this kind of program gets expensive
The “micro RPA” idea, carving a small repetitive slice out of many people’s days, is a good one. The hidden cost is structural, and it shows up after go-live, not during the pilot:
- Each slice is a separate bot to maintain. 385,000 provider applications and a $186M remittance stream are not one automation; they are dozens of recorded flows against practice-management screens, clearinghouse portals, and payer web sites. Every one is a thing to schedule, monitor, and patch.
- Recorders and selectors break on UI change. Eye-care RCM runs across third-party portals MyEyeDr does not control. When a payer ships a new screen or a credentialing site relabels a field, a bot keyed to pixel positions or DOM selectors stops, and the work it was doing falls back to staff until someone re-records it.
- Per-bot licensing scales with ambition. The more slices you automate, the more attended and unattended runners you license. Enterprise RPA pricing rewards starting small and punishes the very expansion the “micro RPA” philosophy encourages.
“The honest read: enterprise RPA produced real savings at MyEyeDr, and it also produced a standing maintenance surface. The next question for any eye-care RCM team is whether the mechanism has to be that brittle.”
Mediar runs the same workflow class at roughly 20% of UiPath's cost
The same RCM workflows, on a different mechanism
Mediar replaces the recorder-and-selector layer with an agent that reads what each application exposes through OS-level accessibility APIs, the same interfaces a screen reader uses. It watches the workflow once, then executes it by element name and role rather than by pixel coordinate. Here is how a cash-application or credentialing slice runs:
A credentialing or cash-application slice, accessibility-API style
Watch once
An operator runs the task one time. The agent records the intent: which app, which fields, which decision rules, by accessibility role rather than screen position.
Read the live tree
On each run the agent reads the application's accessibility tree, the same data a screen reader consumes, so it finds the right field even after a portal redesign.
Act by name, not pixel
It types into the field labelled 'Member ID' or clicks the button named 'Submit claim', so a moved button does not break the run.
Validate and log
Validation rules catch mismatches; every action is written to an audit log for SOC 2 and HIPAA review.
Self-heal on drift
When a label or layout changes, the agent re-finds the element from the live tree instead of stopping and waiting for a re-record.
This matters most exactly where the MyEyeDr case study is vague: the underlying systems. Browser-only AI agents help with modern SaaS, but eye-care RCM lives in desktop practice-management clients, green-screen terminals, and payer portals with no API. The accessibility-API approach exists for that layer specifically. The same engine is open source as the Terminator SDK if your team wants to extend it.
Two ways to automate the same eye-care RCM work
The MyEyeDr case study describes the left column. The right column is the mechanism Mediar uses on the same class of workflows.
| Feature | Recorder-and-selector RPA | Mediar |
|---|---|---|
| How it finds an element | Recorded pixel position or DOM/UI selector captured at build time | Reads the live accessibility tree by element name and role on every run |
| When a payer portal redesigns | Bot stops; work falls back to staff until someone re-records it | Re-finds the element from the live tree and continues, self-healing |
| Legacy desktop and green-screen apps | Supported, but each app is its own brittle recorded flow | First-class target; the no-API desktop layer is the whole point |
| Time to first production workflow | Often months across build, test, and exception handling | Days, because the agent learns by watching the task once |
| Pricing model | Per-bot attended and unattended runner licensing that scales with ambition | $0.75 per minute of runtime, no per-seat licensing; roughly 20% of UiPath cost |
| Compliance posture | Mature, enterprise-grade | SOC 2 Type II and HIPAA compliant, with audit logs and on-prem or cloud deployment |
Established RPA platforms win when you already run a large bot estate with a staffed center of excellence and the cost of switching outweighs the maintenance savings. If you are staring at a six-figure quote or watching a project stall on legacy desktop apps, the accessibility-API approach is the one to evaluate.
Bring us one RCM slice that keeps breaking
Pick the cash-application or credentialing workflow that costs you the most in re-records and rework. We will show you the same task running on the accessibility-API agent, on your systems, before you commit to anything.
Frequently asked questions
Frequently asked questions
Is the MyEyeDr revenue cycle automation case study real, and who published it?
Yes. It is published by UiPath under the title 'MyEyeDr. Sharpens the Focus on Growth with Automation.' The named source inside the case study is Cassie Haag, Director of Systems and Analytics at MyEyeDr. It documents the company's robotic process automation program across revenue cycle work. Verified at the UiPath case study page on 2026-06-22.
What were the headline numbers in the MyEyeDr case study?
Cash application, MyEyeDr's largest use case, touched $186 million in remittances in a single year. The company retained $6.9 million in eyewear claim revenue in 2022 that it otherwise lacked the staff to work, saved over $310,000 in payroll on automated claims movement, processes upwards of 385,000 provider applications annually, and operates roughly 850 vision care centers. It also reports completing mergers in 60 days or less.
How does MyEyeDr split the work between software, bots, and people?
On cash application, Cassie Haag described the split directly: the underlying software 'gets us 30% there, and RPA picks up where the software leaves off and does another 40% to 50%.' People handle the remainder. So even at MyEyeDr's scale, automation does roughly 70 to 80 percent of cash application and humans still close the gap.
What is the 'micro RPA' philosophy MyEyeDr talks about?
Haag described targeting 'those things that just take a little bit longer than you really want. And it's the same exact movements every single time.' Instead of automating one giant end-to-end process, the team carves a small, repetitive slice out of many people's daily workflows and hands each slice to a bot. It is a sound philosophy. The catch is that each slice is its own bot to build, schedule, and maintain.
Why does the case study not name the EHR or billing systems?
Marketing case studies rarely name the underlying desktop applications because that is where the fragility lives. RCM in eye care runs across practice-management and EHR clients, clearinghouse portals, and payer web sites, most of which expose no automation API. RPA reaches them through screen recorders and UI selectors, which is exactly the layer that breaks when a vendor ships a new screen. The omission is not an accident; it is the maintenance surface.
How would an accessibility-API agent run the same workflows differently?
Instead of recording pixel positions or matching brittle selectors, an accessibility-API agent reads what each application actually exposes through the same OS-level interfaces a screen reader uses, then acts on those elements by name and role. When a payer portal moves a button or relabels a field, a selector-based bot stops; an agent that reads the live accessibility tree re-finds the element and keeps going. That is the difference between a bot you patch every quarter and one that self-heals.
Can Mediar show a MyEyeDr deployment of its own?
No, and we will not imply otherwise. The published MyEyeDr case study is UiPath's, not ours. What Mediar can show is the same class of revenue cycle work, cash application, claims movement, provider credentialing data entry, run on legacy desktop systems without recorders or selectors, at roughly 20% of UiPath's cost and in days rather than months. The honest comparison is on the workflow, not on a logo.
Related reading
Kaiser, Epic Resolute, and RPA claims automation: who does what
A verified map of the healthcare claims automation vendors, and the desktop layer none of them drive.
Healthcare automation software
What actually automates on legacy clinical and billing systems, and what does not.
Automated claims intake with fast setup for carriers
How claims intake moves from 30 minutes to 2 minutes without a months-long RPA build.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.