Element5
Element5 automates the back office of post acute care: home health, hospice, skilled nursing and senior living. It is based in San Jose with a second headquarters in Chennai, was co founded around 2020 by chief executive Joe Randesi and chief revenue officer Eric Gordon among others, and has raised 48.5 million dollars, with both a 15 million dollar Series A in 2021 and a 30 million dollar Series B in 2022 led by Insight Partners.
The origin is robotic process automation. The company's own early description was of trained robots that log into everyday systems and perform administrative tasks exactly as a person would, saving teams hours of repetitive clicks. That heritage matters when reading the current product, because another vendor in this index builds its whole architectural argument against precisely this approach, on the ground that recorded screen interactions break whenever a payer changes a portal.
The platform has since moved toward agentic automation under the name Neos, described as a modular end to end solution spanning the patient financial journey, with eligibility and authorisation handled across a connected network. The workflow list is specific and long: insurance eligibility verification at admission and during episodes, authorisation processing including polling convenor portals for status changes, hospice benefit period verification, denial categorisation with prioritisation of high value cases, claims submission, cash posting, notice of admission and notice of election filing, physician order exchange, and the transition of assessment data into the federal reporting system. The company positions itself as a bridge between record systems, payers, convenors and clearinghouses, and offers building blocks so customers can deploy their own agents for unusual payer or local workflows.
Distribution includes a partnership with Homecare Homebase, the post acute record system that states it serves around 37 percent of United States home health and hospice providers. Named customers in published case studies include VNA Health Group, VIA Health Partners, Vivie and Buckeye Home Health. The company was named to the CB Insights Digital Health 150.
Capability Axes
An AI Health Index grade measures what a buyer can verify from public sources on the date shown. It is not a rating of how good the product is. A vendor can build an excellent system and grade low on an axis because it publishes nothing an outsider can check. How grades read
The grade describes the mechanism, and this company's own history describes it plainly. It began as robotic process automation, with trained robots logging into systems and performing tasks exactly as a person would, and much of the published workflow list is still that shape: polling a payer portal for an authorisation status, submitting a notice, posting cash.
That is real automation and it is not principally model driven. The index holds a direct contrast: another revenue cycle vendor here builds its entire architectural case against recorded screen interaction, arguing that models trained on payer portal behaviour tolerate interface changes that scripted automation does not.
The company has moved toward agentic automation and describes deploying agents across a connected network, which would change this reading if the agents reason rather than follow recorded paths. Nothing published establishes which it is, so the grade sits at C and should be revisited when the newer platform is better documented.
Unattended by design, with an oversight model that is named rather than implied. The company's stated aim is to let staff work by exception, meaning the automation runs the routine volume and surfaces only what it cannot resolve.
That is the right structure for this work, where the tasks are high volume, individually low stakes and collectively decisive for whether care starts on time. Held at B because no exception rate is published, so a buyer cannot tell what proportion of work actually returns to a person, and because nothing describes what happens when an automation submits something incorrect to a payer.
The workflows are documented in detail and the technology is not. No model is named, no architecture described, and no accuracy or completion figure published for any of the automations.
The two terms that carry the technical claim, agentic automation and building blocks, are used without definition. For a product whose core question is whether it reasons about a payer's requirements or replays a recorded path, that distinction is the whole evaluation and public material does not settle it.
Nothing identifies any party in the chain: no model or model family, no foundation model provider, no hosting arrangement and no sub processor list was located in two passes, and the technical vocabulary used in place of a description is undefined. The integration architecture makes one question sharper than the usual enumeration gap.
The automation authenticates into payer portals and record systems as a user, which means the vendor holds working credentials to systems containing far more than the workflows it was bought to run, and the scope of what it can reach once authenticated is not published. Credential holding is a supply chain fact in the sense this axis measures: it establishes what a party in the chain can access, independent of what it is meant to access.
Nothing states how credentials are held, scoped or rotated, whether they are named service accounts or staff credentials, or what happens to that access when the contract ends. Ask for the credential model, the access scope, a sub processor list, and whether any third party model provider is invoked in interpreting payer requirements.
Better attributed than most and still unmeasured. Published case studies name their subjects rather than describing an anonymous regional provider, covering eligibility and authorisation work at a named visiting nurse organisation, intake eligibility verification at a named hospice provider, and compliance and revenue recognition at another named agency. Naming customers is a real disclosure.
What is absent is the numbers inside those studies. No touchless rate, no reduction in days to authorisation, no denial rate change, no staff hours saved with a baseline. Recognition on an industry innovation list and a partnership with the dominant post acute record system corroborate commercial traction rather than benefit.
Graded on an honest basis. No retention schedule, encryption detail or data handling position was located in this pass.
One architectural feature deserves a direct question rather than an assumption. Automation that logs into payer portals and record systems as a user does so with credentials, and how those credentials are held, scoped and rotated is a materially different security question from an interface based integration. A buyer should ask whether the automation uses named service accounts or staff credentials, and what it can reach once authenticated.
Graded on an honest basis. No compliance statement or agreement posture was located in this pass.
The company operates a substantial second base in India, so a buyer should establish where processing and any human exception handling occur, and confirm that the agreement covers offshore access to patient information explicitly rather than by silence.
Recorded honestly and provisionally: the dedicated trust and security search this index requires was not run in this pass, and no attestation was encountered incidentally. The company describes its automation as enterprise grade and secure, which is a claim rather than an attestation.
A partnership with the dominant post acute record system implies that manufacturer's own supplier review has been passed.
No device pathway applies and none is claimed. Everything here is administrative and financial.
The regulatory texture that does apply is the reporting machinery of post acute care: notices of admission and election carry filing deadlines with payment consequences, assessment data must reach the federal reporting system correctly, and hospice benefit periods are governed by eligibility rules under active enforcement. Automating those filings means automating compliance artefacts, and an automation that files late or files wrong creates a regulatory problem rather than only an operational one.
Nothing published on monitoring, error rates or evaluation of any automation.
One stated feature carries a distributional consequence worth naming. Denial management is described as prioritising high value cases, which is rational for the agency's finances and means that low value denials are worked last or not at all. A denial's value to the agency is the size of the claim; its value to the patient is whether their care is covered. Those are different, and a small claim for an inexpensive service is exactly the kind most likely to belong to a patient with the least ability to absorb it. This is the allocation pattern already recorded elsewhere in the index, applied to advocacy rather than to clinical attention.
The customer authored agents raise the second question, already logged against other vendors here: an agent a customer builds from supplied blocks sits in a different governance position from one the vendor built and tested, and no review process is described.
Two passes located no accuracy or completion figure for any automation, no published limitations, no evaluation methodology and no warranty, indemnity or remediation commitment. The workflows are documented in detail and the technology is not, and the two terms carrying the technical claim, agentic automation and building blocks, are used without definition. For this product that is the whole evaluation rather than a quibble.
Whether the system reasons about a payer's requirements or replays a recorded path determines what happens when a portal changes, a form is revised or a payer varies its rules: a reasoning system adapts and may adapt wrongly, while a recorded path breaks visibly. Those are opposite failure modes with opposite monitoring needs, and public material does not settle which one a buyer is purchasing.
A second exposure follows from the integration method and is now the third instance of this shape in the backfill. Automation that logs into payer portals and record systems as a user does so with credentials, so an action taken by the software appears in those systems as an action taken by whoever the credentials belong to.
Establish whether named service accounts or staff credentials are used, what the automation can reach once authenticated, and whether its actions are separately identifiable in the audit trail, because if they are not, responsibility for a wrong submission cannot be allocated after the fact.
Positioned explicitly as a bridge between record systems, payers, convenors and clearinghouses, which is an accurate description of where the work sits: the friction in post acute administration is that these four parties do not share infrastructure.
The strongest evidence is the partnership with the post acute record system that states it serves around 37 percent of United States home health and hospice providers, which is the same channel this index recorded for the sector's leading predictive vendor. Connecting to the existing toolstack, record system or otherwise, is a stated design principle. Held at B because no interface standard or integration mechanism is described, and because portal automation is a connection method rather than an integration.
Delivered as a managed service, with the company stating that customers deploy automation without development, maintenance or infrastructure investment of their own. That is a clear model and it means the vendor operates the automations rather than handing over software.
What is not published is where any of it runs, what is retained, or how the split works between the United States and the substantial India operation. For a managed service handling patient and claims data, those are the first questions.
Nothing published: no price, no mechanism, no unit of sale.
Automation as a service invites a per transaction or per workflow model, and the range of workflows offered here is wide enough that the difference matters: an agency automating eligibility checks only is buying something very different from one automating the whole financial journey from intake to cash posting. Ask whether pricing is per automation deployed, per transaction processed, per episode or a platform fee, and ask what happens when a payer changes a portal and an automation has to be rebuilt, since that maintenance burden is the known weakness of this architecture and someone pays for it.
Wide within post acute care and confined to it. Four settings are named, home health, hospice, skilled nursing and senior living, and the workflow coverage runs the length of the administrative journey from intake and eligibility through authorisation, claims, denials and cash posting.
That span is the distinguishing feature: most vendors in this index address one step, and this one addresses the sequence. Buyers range from national operators to small agencies, and the company's own material draws attention to lean rural and underserved agencies as a constituency it builds for. Held at B because nothing extends outside post acute care and coverage is United States only, which is inherent since the filings being automated are features of this payment system.
Pricing
Vendor-published figures are labeled as such. Figures labeled “Estimated” are derived from third-party sources and have not been confirmed by the vendor.
| Entry Price | Pricing Basis | BAA Tier | Implementation | Source |
|---|---|---|---|---|
|
—
|
Not published. Managed automation service across post acute administrative workflows. | Not located. The company operates a substantial second base in India, so confirm the agreement covers offshore processing and human exception handling explicitly rather than by silence. | Not published. The company states customers deploy automation without development, maintenance or infrastructure investment of their own, which implies a managed service rather than an installed product. | Third Party Estimated |
Nothing is published: no price, no mechanism, no unit of sale. Automation as a service invites a per transaction or per workflow model, and the breadth offered here makes the difference material: an agency automating eligibility checks alone is buying something very different from one automating the whole financial journey from intake through authorisation, claims and cash posting.
Establish whether the fee is per automation deployed, per transaction processed, per episode of care, or a platform licence. Then ask the question specific to this architecture: what happens commercially when a payer changes its portal and an automation has to be rebuilt. Maintenance is the known weakness of screen driven automation, a competing vendor in this index makes that the centre of its pitch, and somebody pays for the rework.
Ask too how the customer built agents are priced, since building blocks that let an agency create its own automations shift both cost and responsibility. Worth requesting the exception rate from comparable customers before agreeing any per transaction price, because the share of work that returns to a person determines whether the fee replaces staff cost or adds to it.