The Triune Health Partners RPA case study does not exist. Here is what the search is really about.

No public one. As of June 2026, searching the three RPA vendors' case study libraries and the open web turns up no automation case study named after a company called Triune Health Partners. The name that does exist is TRIUNE Health Group, a workers' compensation medical case management firm in Lombard, Illinois, and it is not published as an RPA showcase. If you arrived expecting a named bot-deployment story with hours-saved numbers, that artifact does not exist publicly. What follows is the honest version: who the real company is, and what automating that kind of revenue cycle actually requires.

TRIUNE Health Group is a family-owned health care management company headquartered at 200 West 22nd Street in Lombard, Illinois, operating for more than 35 years. Their work is workers' compensation, not hospital billing: medical case management, nurse triage, catastrophic case management, utilization review, telephonic case management, vocational rehabilitation, personal injury protection, and life care planning. That distinction matters, because the revenue cycle behind workers' comp case management looks nothing like the hospital revenue cycle most RPA case studies describe.

Hospital RCM runs through one payer relationship per claim and a clearinghouse that speaks the 837 and 835 EDI standards. Workers' comp does not. A single bill can route to a third-party administrator, an employer, a state fund, and a bill-review vendor, each with its own portal and its own jurisdictional fee schedule. There is no universal clearinghouse that covers all of it, and many of the systems involved (case management platforms, bill-review tools, state filing portals) expose no API. So the work that should be automated is exactly the work that has no programmatic endpoint: a person reading one screen and typing into another.

They can drive the screens, but the no-API, multi-portal nature of workers' comp is where pixel-matched and selector-based bots are most brittle. Each TPA portal, each state filing system, and each bill-review tool has its own layout, and those layouts change. A bot recorded against coordinates or DOM selectors breaks on a redesign and goes back to the automation team to be rebuilt. That maintenance tax is the quiet reason many of these projects stall before they pay back. The generic RPA platforms are real tools; the friction is the brittle way they reach a screen that has no API behind it.

Mediar reads the Windows accessibility tree, the same interface a screen reader uses, so it locates fields by their exposed name rather than by pixel coordinates or DOM selectors. The agent types into a field called Claim Number or Date of Service, not into a rectangle at fixed coordinates. When a portal moves that field or restyles a button, the field is still named Claim Number, so the run keeps going. It watches a workflow once, then executes it. The engine underneath is the open-source Terminator SDK, so a team can extend the workflows themselves.

Mediar is SOC 2 Type II certified and HIPAA compliant, and deploys on-prem or in your own cloud. Because the agent runs on the same workstation or virtual desktop a case manager or biller uses, protected health information and claim data stay inside your environment. The agent operates the existing applications rather than exporting data to a separate service.

Pricing is $0.75 per minute of runtime with no per-seat licensing. There is a $10,000 turn-key program fee that converts to credits, so it is effectively prepaid usage. The contrast with enterprise RPA is the cost shape: per-bot licensing plus a months-long implementation and ongoing maintenance, versus runtime billing with the agent learning a workflow in days.