Luminai

Healthcare trained models doing the hard half of the work, inside an automation platform whose other half is deterministic execution.

The intelligence is real and is applied where it is genuinely needed. The stated problem is fragmented data, unstructured documents and disconnected systems, and turning an inbound referral packet, a payor contract or a denial letter into structured, actionable data is a language and document understanding problem rather than a scripting one. Describing the models as healthcare trained rather than general purpose is a meaningful claim if true, since clinical and payor documents carry vocabulary and structure that generic extraction handles poorly.

The other half is action execution. The platform operates existing systems directly rather than through interfaces, which is robotic process automation in lineage, and the company's earlier cross industry positioning described mimicking human actions and building workflows from uploaded standard operating procedures. Executing a sequence of clicks reliably is engineering rather than inference, however valuable.

What pushes this above the workflow vendors graded lower is that the models decide what the actions should be rather than only carrying them out, and human in the loop validation is described as gating decisions rather than gating keystrokes.

Graded B rather than higher because no model, method or accuracy figure is published anywhere, so the healthcare trained claim cannot be examined. Ask what the models extract, at what accuracy, and which parts of a workflow are learned rather than scripted.

Human oversight is an explicit architectural component rather than an afterthought, and the boundary it draws is undefined.

The design is stated plainly: healthcare trained models combine with workflow automation and human in the loop validation, so automated decisions pass a human check when needed. Building validation into the architecture, and saying so as a defining feature rather than a disclaimer, is the right posture for a system that takes actions in production clinical and financial systems.

The undefined phrase is when needed. Which actions are gated, who set the threshold, whether the customer configures it or the vendor does, and what proportion of steps actually reach a human are all unstated. In a platform that registers patients, processes orders, renews pharmacy prescriptions and appeals denials, the difference between validating every consequential action and validating an occasional sample is the difference between two very different products, and public material does not distinguish them.

The action surface makes this the most important open question in the record. Unlike an alerting system, this platform writes into live systems, and a wrong action is not a missed notification but a change that has already happened. Nothing describes reversal, correction or how an erroneous action is detected after the fact.

No error rate, intervention rate or accuracy figure is published for any workflow.

Graded B for the explicit architecture, and held there by the absent calibration. Ask which actions require validation, who configures the threshold, the intervention rate in production, and how a wrong action is reversed.

The approach is described clearly at the level of what it does, and not at all at the level of how.

Functional disclosure is good. The problem is framed precisely as fragmented data, unstructured documents and disconnected systems; the method is described as structuring chaotic information, automating manual handoffs and deploying end to end workflows across systems; eight specific workflows are enumerated; and the integration approach, operating systems directly rather than through interfaces, is stated openly. Earlier material describes workflows built from uploaded standard operating procedures, which tells a reader how a deployment is actually configured.

The model layer is empty. No model is named, no base or foundation model is identified, no architecture is described, and the healthcare trained claim carries no detail about what data trained them, on what task, or to what standard. No accuracy, precision, recall or error rate exists for extraction, classification or action execution.

Extraction accuracy is the figure that matters most and is entirely absent. When a model reads a referral packet or a denial letter, the downstream workflow inherits whatever it got wrong, and a buyer evaluating whether to route production volume through this has no basis for estimating the error rate they will be absorbing.

One pre emptive note: further workflow announcements cannot move this grade. Only published extraction and action accuracy will.

Ask for extraction accuracy per document type, what healthcare trained means concretely, and whether third party foundation models sit in the pipeline.

A dedicated pass located no base or foundation model, no cloud or infrastructure provider for the managed deployment, no sub processor register, no third party component disclosure and no training data provenance.

The healthcare trained models claim is where the omission concentrates. Domain trained models are ordinarily either fine tuned from a third party foundation model or built in house, and those are entirely different supply chains with different dependencies, different data flows and different contractual exposures. Nothing indicates which applies. If a third party model provider processes referral packets or clinical correspondence, the customer has not been told; if none does, saying so would be a straightforward differentiator that costs nothing.

The deployment options complicate rather than resolve it. On premise and virtual private cloud deployment suggests models can run inside the customer environment, which would preclude an external inference call, and nothing states whether that is true or whether some model calls still leave the perimeter under those models. That is the single most important supply chain question for this vendor and it is unanswered in both directions.

Training provenance is likewise unaddressed. A company differentiating on domain trained models processing health system documents at volume has an evident incentive to train on them, and no statement exists either way.

Ask whether any third party model processes customer data, whether inference stays inside the perimeter in on premise deployments, and the consent basis of the training corpus.

A dedicated pass located no named health system customer, no case study, no quantified outcome and no independent evaluation.

The company states it is trusted by large health systems and identifies none of them. That matters more than a missing logo wall, because every claim about scale, reliability and value currently rests on the vendor's own assertion with nothing external to check it against. A buyer cannot call a reference they have not been given.

The strongest available signal is investor diligence rather than customer evidence. A 38 million dollar Series B in April 2026 led by an established growth investor, with a healthcare specialist fund joining and prior backers continuing, means someone with access to the data room was satisfied. That is a real signal and it is not a substitute for published results, since investors and hospital operations leaders are evaluating different things.

One named customer exists from the company's earlier cross industry period, with a claimed capacity increase, and it is a behavioural health technology company rather than a health system, so it says little about performance in the environment now targeted.

A specific caution belongs on the record. Several artificial intelligence directory sites carry precise figures for return on investment and average time to value for this vendor. Those pages describe testing that could not plausibly have occurred and trace to no primary source. They were excluded here and should be excluded from any refresh.

Ask for two named health system references, the workflows deployed at each, and volume processed with an error rate.

Specific stewardship controls described at the architectural level, which is where they carry weight.

Three named controls do real work. Encrypted data is table stakes. Isolated execution means automation runs in a contained environment rather than sharing a runtime across customers, which limits what a fault or compromise in one tenant's workflow can reach. Customer owned credentials is the strongest of the three and is rare across this index: the platform operates using credentials the customer issues, holds and can revoke, so the vendor never accumulates a standing set of keys to a health system's clinical and financial applications. For a product whose entire method is operating other systems, that is precisely the right control.

The deployment options reinforce it. On premise and customer virtual private cloud options mean the data can stay inside the customer's perimeter, so the stewardship burden shifts to where the customer already has controls.

What is missing is the operational layer. No retention schedule, no deletion process, no audit logging description and no statement on whether customer data contributes to model development.

That last question carries weight for this vendor specifically. The models are described as healthcare trained, the platform processes referral packets, clinical documents and payor correspondence at volume, and nothing states whether that material has fed or continues to feed training. A company whose differentiator is domain trained models has an obvious incentive here and has said nothing about it.

Ask whether customer documents train models, what is retained in managed deployments, and what audit trail the customer receives.

An architectural decision that materially changes the privacy question, alongside a compliance claim stated in hedged language.

The architecture is the substantive part. Deployment can run on premise or inside the customer's own virtual private cloud, which means protected health information need never leave the customer's environment at all. That is a stronger answer than any policy commitment, because a vendor that does not receive data has a much smaller obligation to describe how it protects it. Customer owned credentials extend the same logic to access: the automation acts using the customer's own system credentials rather than the vendor holding a standing set, so access is governed by the customer's own identity controls and can be revoked without depending on the vendor.

Three regimes are claimed, covering United States health privacy law, service organisation controls and European data protection law, which is broader than most vendors at this stage assert.

The hedge is worth naming. The company's own wording is continuous alignment rather than compliance or certification, and alignment is not a term of art with any defined meaning. Third party listings describe a service organisation controls report at the tested tier, and the vendor's own material does not.

No business associate agreement template, execution requirement or subcontractor position was located, and nothing states how the posture differs across the three deployment models, which is the question a compliance officer will ask first.

Ask what alignment means precisely, for the agreement template, and how obligations differ between on premise and managed deployment.

Named credentials across three regimes with specific technical controls beside them, stated in language that stops short of the precision this index looks for.

The substance is real. A dedicated security page exists rather than a footer badge, three frameworks are named covering health privacy, service organisation controls and European data protection, and the controls described are specific rather than generic: encrypted data, isolated execution and customer owned credentials. Naming controls that a buyer can test is more useful than naming standards alone, and the credential control in particular addresses the sharpest risk in this product, which is a vendor accumulating standing access to a health system's applications.

The imprecision costs the grade above. The company's own phrasing is continuous alignment rather than compliance or certification, and alignment has no defined meaning. Third party listings describe a service organisation controls report at the tested tier; the vendor's own material does not state the tier, and the tier is the distinction between controls designed and controls tested over a period. This index has recorded several vendors blurring exactly that line.

Supporting apparatus is absent. No trust centre, no report availability or request process, no assessor, no audit period, no penetration testing disclosure and no vulnerability disclosure policy was located.

The attack surface deserves the scrutiny, since software that authenticates into clinical and financial systems and acts within them is a high value target regardless of where it runs.

Ask for the report type and audit period, the assessor, and what documentation is available under agreement.

Device regulation is genuinely not the relevant regime, and the regimes that are relevant go unaddressed.

No clearance is claimed and none is needed. Referral intake, patient registration, contract management and denial appeals are administrative functions that make no clinical claim and support no clinical decision, so this sits cleanly outside device regulation. Stating that plainly is more useful than treating the absence as a gap.

Two other regimes do apply and neither is described. The platform is stated to support compliance as a workflow domain, which means software is performing or assisting regulatory work, and nothing describes what that covers or what accountability attaches when an automated compliance action is wrong. And European data protection alignment implies exposure to a jurisdiction that now regulates artificial intelligence systems directly, with obligations turning on risk classification and applying to deployed systems rather than only to medical devices. A vendor claiming that alignment will be asked how its agents are classified, and nothing published answers it.

One workflow sits closer to a clinical boundary than the rest. Pharmacy renewals touch prescribing, and while processing a renewal request administratively is not a clinical decision, the line between routing a renewal and effecting one depends entirely on what the automation is permitted to complete without a clinician. Nothing describes where that line falls.

Ask what the compliance workflows cover, the European artificial intelligence risk classification, and precisely what the pharmacy renewal automation is permitted to complete unaided.

A dedicated pass located no governance framework, no fairness testing, no subgroup analysis, no model documentation, no drift monitoring and no external audit.

The bias risk in administrative automation is quieter than in clinical models and reaches patients just as directly. Denial appeals and underpayment recovery are prioritisation problems: a system that decides which denials are worth pursuing will tend to optimise for recoverable value, and the denials with the highest expected value are not the denials affecting the most vulnerable patients. Automating pursuit of profitable appeals while leaving low value ones in a manual queue would produce a systematic difference in who gets their coverage fought for, and nothing published addresses whether prioritisation logic exists or what it optimises.

Patient registration and referral intake carry a more familiar exposure. Extraction from unstructured documents degrades on names, addresses and identifiers outside the pattern a model saw most, and registration errors compound downstream into matching failures, coverage problems and duplicate records that fall hardest on patients with less common names and less stable addresses.

Document quality is a third axis. Referral packets from small, under resourced practices arrive in worse condition than those from large systems, so extraction accuracy plausibly tracks the resourcing of the sending organisation.

Nothing published examines any of this, and no accountable owner for model behaviour is named.

Ask what denial appeal prioritisation optimises for, and extraction accuracy across name and address variation.

Nothing contractual is published, for a platform that takes actions rather than making recommendations.

A dedicated pass located no service level agreement, no accuracy warranty, no uptime commitment, no indemnity, no remediation position and no published terms.

The action surface is what distinguishes this from most records graded the same. An alerting product that is wrong has failed to inform someone. This product registers patients, processes orders and referrals, renews pharmacy prescriptions, manages payor contracts and files denial appeals, so a wrong output is a change already made in a production system. A misregistered patient creates a duplicate record that propagates. A mishandled appeal can pass a filing deadline that cannot be reopened. A wrongly processed order is a clinical event. None of these is recoverable by noticing later, and no accuracy figure exists to characterise how often they occur.

The credential design creates a further question that works against the customer contractually even as it protects them technically. Because automation acts using customer owned credentials, actions appear in system audit trails as the credentialed user, which makes it materially harder to establish after the fact that a given action was automated rather than human. Attribution is the foundation of any liability argument.

One pre emptive note: further security credentials or deployment options cannot move this grade. Only contractual terms, or published action accuracy with a correction process, will.

Ask what is warranted on action accuracy, how automated actions are distinguishable in audit logs, and what recourse exists when an irreversible action is taken in error.

A deliberate rejection of standards based integration, which is a real capability and a real limitation at the same time.

The approach is stated openly: the platform plugs into existing systems without requiring interface development, operating applications the way a person would. That is genuinely valuable in health system operations, because the systems where administrative work is trapped are frequently payor portals, legacy scheduling tools and vendor applications that expose no usable programming interface and never will. A vendor that can reach those is solving a problem standards cannot, and it explains the reported speed of deployment.

The cost is that none of the usual evidence exists. No electronic health record is named, no interface standard is described, no marketplace or validated integration listing was located, and third party assessment notes limited third party platform support. Team members with record system backgrounds are provenance rather than integration.

Two consequences follow that a buyer should weigh. Automation that drives a user interface is brittle in a way an interface is not, because a vendor's screen change can break a workflow overnight, and nothing describes how that is detected or repaired. And operating as a user rather than through an interface means actions appear in audit logs as the credentialed human, which has implications for accountability that no published material addresses.

Ask which systems are automated in production, how interface changes are handled, and how automated actions are distinguished in the customer's audit trail.

Three deployment models offered explicitly, including two that keep data entirely inside the customer's perimeter, which is the strongest answer to this axis available and is rare across this index.

The options are on premise, deployment inside the customer's own virtual private cloud, or vendor managed. That range resolves the residency question by handing it to the customer: an organisation with data location obligations, whether from European data protection rules, state requirements or its own policy, can satisfy them by choosing a model where the vendor never holds the data. Most vendors in this index answer residency with a description of current practice, which is a statement about today rather than a commitment; offering customer controlled deployment is a commitment by construction.

Isolated execution accompanies it, so automation runs contained rather than sharing a runtime across customers, and customer owned credentials mean even the access path stays under customer control.

That combination matters especially for this product's method. Automation that operates a health system's live applications is reaching into the most sensitive systems the organisation runs, and being able to place that execution inside the organisation's own network is the difference between an external service with standing access and a contained internal one.

What is still unstated is thinner than usual: no cloud provider or region is named for the managed option, and nothing describes whether capability, model performance or support differs across the three models, which is the practical question a buyer choosing between them faces.

Ask whether capability differs by deployment model, which provider hosts the managed option, and what the vendor can access under each.

Cost is absent from every published surface. A dedicated pass located no pricing page, no unit of charge, no range, no tiering, no implementation fee position and no minimum commitment.

The unit question is genuinely open here rather than merely unstated, which makes the silence more consequential than usual. An automation platform of this kind could plausibly charge per workflow deployed, per transaction processed, per full time equivalent displaced, per seat, or as an enterprise licence, and each produces a completely different total for the same volume. A health system automating denial appeals at high volume and one automating pharmacy renewals at low volume have opposite exposure under a per transaction model and identical exposure under an enterprise licence. Nothing indicates which applies.

The deployment choice compounds it. On premise, customer virtual private cloud and vendor managed deployments carry materially different cost structures, and nothing states whether the choice affects price.

No return proxy is published by the vendor. The commercial argument is administrative labour displaced, which is one of the more calculable claims in healthcare technology, and no cost per transaction, hours released or staffing figure supports it. Figures circulating on third party directory pages are unsourced and were not used here.

Ask for the unit of charge, whether deployment model affects price, how additional workflows are priced after the first, and the minimum term.

Workflow coverage is enumerated with unusual specificity, and organisational coverage is narrow and unevidenced.

The workflow list is the strength. Referral intake, provider inbox automation, patient registration, order and referral processing, pharmacy renewals, payor contract management, denial appeals and underpayment recovery are named individually rather than gestured at, and they span three distinct operational domains: patient access at the front, revenue cycle at the back, and clinical administration in between. Naming eight specific workflows tells a buyer what has actually been built, which a category label does not.

That spread is also commercially coherent, since the underlying capability, structuring unstructured documents and driving systems that lack interfaces, applies equally to a referral fax and a payor contract.

Organisational coverage is where it thins. The stated target is large health systems, and third party assessment notes the platform is likely too heavy for smaller organisations, so the addressable setting is narrow by design. No customer is named, so nothing establishes how many settings are actually running, at what scale, or which of the eight workflows are production rather than roadmap.

No geography is stated. European data protection alignment implies some non United States exposure and nothing confirms deployment there.

Ask which workflows are live in production today, at how many organisations, and what the smallest viable customer looks like.