Notable

Agents performing workflows end to end are the product, and Flow Builder sells the capability to author more of them. There is no non AI version of the offering.

Agents are described as handling workflows autonomously and as virtual team members performing end to end work, including prior authorization submission and denial management, which are consequential actions with financial and access implications. No escalation criteria, confidence thresholds, human review checkpoints, or exception handling policy were retrieved. This is the same pattern flagged for Waystar and Elation in this index: strong autonomy claim, thin oversight disclosure, in workflows where errors cost patients access or money.

No foundation model is named, no architecture is described, no evaluation methodology is published and no accuracy figure was located for any individual agent.

What is published is operational rather than technical: dashboards, workflow performance reporting and analytics intended to let a customer benchmark and demonstrate return. That lets a buyer see whether a deployed agent is working in their own environment, which has real value, but it is measurement of outcomes rather than disclosure of method.

The gap is sharpest on the agents that act rather than inform. Authorisations, denial management and risk coding chart review all produce consequential output, and none carries a published accuracy figure or confidence threshold. For a platform that also lets customers train their own agents, the absence of a stated evaluation method is compounded, because customer authors have no published standard to test against.

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 no retention period, de identification posture or position on whether customer data trains the agents was found. The scale and the reach are what make the silence consequential rather than routine.

The company reports deployment at more than twelve thousand sites of care automating over a million workflows a day, reading and writing structured and unstructured data across several major record systems and payer portals. Reading and writing matters: a platform that writes into a record and submits to a payer is acting inside systems the customer is accountable for, and the identity of every party in that path is a question a compliance function would normally ask before granting the access.

The audit logging credited on the other axis is worth distinguishing here, because it answers a different question. An audit log tells a customer who touched a record inside their own environment. It does not tell them what the vendor retains, for how long, where it sits, or what improves from it. Ask for a sub processor list, the hosting arrangement, retention, and an explicit training position covering both the vendor's agents and any customer built ones.

Named health system deployments at Intermountain, Trinity Health, and MUSC, with published customer results that state both the metric and the site: 64 percent voice containment and roughly $360,000 in annual savings at one system, registration reduced to 30 seconds at another, and an insurance FAQ voice assistant at a stated $4 saving per call. Containment rate is the correct metric for voice deflection and it is rarely published. Held back from A because the figures are customer stories curated by the vendor rather than independently audited.

One specific control is published and it is worth crediting: all access to information within the platform is stated to be subject to immutable audit logs, traceable to individual users, and subject to regular review. Immutability and per user traceability are concrete claims rather than general assurances, and few vendors here state either.

The grade stays at C because the stewardship questions themselves are unanswered. No retention period, no statement on whether customer data is used to train or improve agents, and no de identification posture was located.

Scale makes those answers matter more here than for most. The company reports deployment at over 12,000 sites of care automating more than a million workflows a day, reading and writing structured and unstructured data across Epic, Oracle Health, MEDITECH, athenahealth and payer portals. An audit log tells a customer who touched a record. It does not tell them what the vendor retains, for how long, or what improves from it.

Compliance with the HIPAA Security Rule is claimed among the frameworks the company names, and a privacy policy is published. No business associate agreement terms and no HIPAA specific posture document were located.

Business associate status is structurally certain given deployment across named health systems and read and write access to the electronic health record. The claim that is made concerns the Security Rule specifically, which addresses safeguards for electronic protected health information rather than the privacy rule obligations or the contractual instrument.

Worth establishing separately for the patient facing side. The platform runs registration, intake and voice interactions with patients directly, so a buyer should confirm how the agreement treats data collected from a patient before they are established in the record, which is a different flow from data read out of the chart.

Notable states full compliance with HITRUST, the HIPAA Security Rule, NIST SP 800-171, PCI requirements and an ISO 27001 information security management system. That is a broader framework stack than most vendors in this index name, it appears in the company's own formal announcements rather than on third party listings, and it is credited accordingly.

Held at B rather than A on precision. No HITRUST level is stated, and e1, i1 and r2 represent materially different assurance. The ISO 27001 reference describes a management system without stating certification or naming a registrar. No SOC 2 report is claimed at all, which is unusual alongside this stack. And the phrase full compliance with sits between holding a certification and operating to a standard, which are different things.

No trust centre or self serve report access was located across two searches. Ask for the HITRUST level and validity dates, the ISO 27001 certificate and its scope, and whether any of it covers the agent products or only the underlying platform.

No FDA pathway applies and none is claimed. The agents perform patient access, revenue cycle and care operations work rather than diagnosis or treatment selection, and the company makes no clinical decision support claim, which is the correct scope for operational automation.

Graded C because several regimes do govern the functions being sold and no position is published on any of them. Prior authorisation work reaches the CMS interoperability and prior authorisation requirements and the state laws now conditioning AI involvement in coverage decisions. Risk adjustment chart review sits under CMS risk adjustment rules and audit. Patient payment estimate work touches price transparency requirements. Outbound patient voice contact reaches the consumer telephone consent framework, where the FCC has ruled that AI generated voices are artificial voices requiring prior express consent.

The buyer inherits all of these at once. Enumerate the workflows being deployed, ask which regime the company believes governs each, and note that for customer built agents the answer may be that the obligation sits with the customer.

No AI governance framework, model monitoring disclosure or bias evaluation was located.

The governance question here has a shape the index has not met before, and it comes from the product's central feature. Flow Builder is a no code interface explicitly sold to let an organisation's own IT and non technical staff build, train and deploy agents. That moves authorship of consequential automation to the customer, and with it the questions of who validates a new agent before it runs, what testing is required, whether anything prevents a non technical author from deploying an agent that acts on patient access or authorisation decisions, and who is accountable when a customer built agent behaves badly.

Nothing published addresses any of it. The point is not that customer authorship is wrong; it is that a platform selling it needs published guardrails, and a buyer should ask what the review and approval path looks like before staff start building. Note that where the customer authors the agent, the customer is likely to own the governance obligation too.

One control is stated concretely enough to be worth something, and the gap sits exactly where the product acts rather than informs. All access to information within the platform is subject to immutable audit logs, traceable to individual users, and subject to regular review.

Immutability and per user traceability are specific claims rather than general assurances, and they are what makes a later dispute answerable: an organisation can establish what the system did and who touched it rather than reasoning about the product in general. Held at C because nothing measures the agents. No accuracy figure, confidence threshold or evaluation methodology was located for any individual agent, and the gap is sharpest on the ones that act.

Authorisations, denial management and risk coding chart review all produce consequential output, and an authorisation submitted wrongly or a code proposed without support has effects that an audit log records without preventing. What is published instead is operational reporting, dashboards and workflow performance analytics, which let a customer see whether a deployed agent is working in their own environment.

That has real value and it is measurement of outcomes rather than disclosure of method. One structural point compounds it: customers can build their own agents, and with no published evaluation standard those authors have nothing to test against. Ask for accuracy and thresholds on the acting agents, and what standard customer built agents are expected to meet.

Among the most pragmatic integration positions in the index, and the honesty is the point: the company states it uses whichever method actually reaches the field, including APIs, RPA, and HL7, across Epic, Oracle Health, MEDITECH, athenahealth, and payer portals, reading and writing both structured and unstructured data.

Acknowledging RPA rather than claiming pure API integration is a more truthful description of how healthcare data access actually works, and buyers should note RPA based paths are more brittle to vendor interface changes than certified APIs.

No hosting provider, region, tenancy model or data residency commitment published by the company was located, and no subprocessor list was found. Third party profiles describe a cloud native multi cloud stack, but aggregator descriptions are not treated as vendor disclosure in this index.

The integration approach makes one question more pressing than usual. The company states plainly that it uses whichever method reaches the field, including robotic process automation alongside APIs and HL7. Robotic process automation works by driving the user interface with credentials, which means service accounts inside the customer's own systems and a different security and access profile from an API integration.

Establish where those credentials live, how they are scoped and rotated, and what the vendor can reach with them. That is the deployment question that actually matters for this architecture, more than the hosting region.

No public pricing. Contact the vendor. Enterprise agreements with health systems; no published rate card. Buyers evaluating this against a point solution should establish whether pricing is per agent, per workflow, or platform level, since the platform model is only economical if multiple workflows are deployed.

Broad but clearly enumerated by function rather than vaguely claimed: patient access, revenue cycle, and care operations, with named workflows under each. The company makes no clinical decision support claims, which is the correct scope for operational automation.