Aetion

Computational method does the consequential work here, and most of that method is not machine learning. The engine is causal inference and pharmacoepidemiology implemented in software: cohort definition, confounding adjustment, propensity based comparison and effect estimation across large longitudinal datasets. That is the product, a customer buys nothing else, and it would be wrong to call it thin.

It is also not what this index usually means by the term, and the record should say so plainly rather than let a marketing phrase settle the question. The company describes purpose built artificial intelligence and embedded generative capability for defining cohorts, exploring subgroups and translating research questions into results in natural language, and the 2022 acquisition of a synthetic data company added generative modelling of patient records. Those are real learned model components. They are also recent, peripheral and removable: strip the generative layer out and the platform still produces regulatory grade evidence, because the estimation engine is statistical rather than learned. Strip the causal inference engine out and nothing remains.

The middle band is the right instrument for exactly this shape, where models are genuinely present but are not what the buyer is paying for. Rejection would have been the wrong tool, because the index covers vendors whose computational method carries the decision and this one plainly does. Ask which specific functions in your workflow are performed by a learned model rather than by specified statistical method, which model or provider sits behind the natural language and cohort definition features, and whether any of them influence effect estimates rather than only the interface.

The autonomy at stake is analytic rather than clinical, and the design deliberately minimises it. The workflow is built around pre specification: measures and protocols are defined before execution, analysis plans are locked, parameters are transparent at the level of individual study design choices, and the environment produces an audit trail of what was run. A named epidemiologist rather than the software decides the comparison, the covariates and the outcome definition.

That matters more in observational research than an autonomy grade usually does. The characteristic failure of this field is not a model acting without a human but a human iterating over specifications until a result appears, and pre specification with locked plans is the control that prevents it. Building the constraint into the tooling rather than leaving it to analyst discipline is a real design decision and it is documented in the product materials.

Two things hold it below the top band. The newer low code and natural language features move in the opposite direction by lowering the effort required to generate a specification, and nothing published describes what stops a user cycling through cohort definitions in an exploratory module and then carrying a favourable one into a locked protocol. And no published statement describes what the platform prevents rather than merely records, which is the difference between an audit trail and a control. Ask whether the platform enforces protocol locking or only logs changes, whether exploratory analyses are distinguishable from pre specified ones in the audit record, and who inside your organisation can unlock a plan.

Method transparency is high and is the reason this record grades well overall. Study protocols have been published in advance on a public registry, analysis parameters are exposed at the level of individual design decisions rather than behind a configuration, results are reproducible from the recorded specification, and the underlying epidemiologic methods are published in the peer reviewed literature under named authors rather than described as proprietary. A reviewer can see what was done and rerun it, which is the standard this axis is asking about and which very few records in this index meet.

The named module structure adds to it: Discover, Substantiate, Activate and Generate are separable and a buyer can tell which part of the workflow each addresses rather than facing an undifferentiated platform.

The gap is precisely the artificial intelligence layer. No model is named, no provider is identified, no version is stated, no evaluation is published, and no description explains what the natural language and cohort definition features actually do to a query before it becomes a specification. For an index built around disclosure of computational method, a vendor that documents its statistics thoroughly and its models not at all has an asymmetry worth naming. Ask which model powers the natural language and generative features, who operates it, what version you would be running, and how its outputs are validated before they enter a study specification.

Nothing in the chain is identified. The generative and natural language capabilities are described in capability terms with no model named, no provider named, no hosting location stated and no sub processor list published. The synthetic data generator arrived through an acquisition and its architecture and provenance are undescribed. No statement distinguishes components built in house from components licensed.

Data provenance is the second half and is at least as consequential here as model provenance, because in this field the dataset is an input to the finding rather than a substrate the software runs on. Which sources are licensed, from whom, under what terms, and with what known coverage gaps are questions the platform's data agnostic positioning pushes onto the customer without enumerating.

The acquisition sharpens both. The vendor now sits inside a parent whose business is assembling and linking health data across a partner network of several hundred organisations, so the chain behind any given study can extend well past either company. A sponsor whose submission rests on a linked dataset should be able to enumerate every party that touched it, and nothing published lets them. Ask for a written sub processor list covering the platform and any linkage services, the identity and hosting of any third party model reachable from the environment, and the full provenance chain for each dataset in your study.

The strongest validation record in this index, and it is a different kind of evidence from anything else here. Most vendors publish studies showing their product performed well. This vendor was the industry partner in a programme built to find out when its method fails, run with academic pharmacoepidemiologists at Brigham and Women's Hospital and Harvard Medical School and with the Food and Drug Administration as a named collaborator, with FDA staff among the published authors.

RCT-DUPLICATE took randomised controlled trials as the reference standard and asked whether observational database studies could reproduce them. Study protocols were posted to a public trial registry before results were known, which forecloses the retrospective specification that makes most observational research unfalsifiable. First results covering ten cardiovascular and diabetes emulations appeared in Circulation in 2021, and the omnibus analysis of 32 trials appeared in the Journal of the American Medical Association in April 2023. The programme also predicted the outcomes of trials that had not yet read out, which is a genuinely prospective test that almost no analytic vendor in any lane has submitted to. An oncology extension with the FDA Oncology Center of Excellence covers twelve trials across four cancers.

The result was conditional and was published as such: agreement was strong where the trial could be closely emulated in routine care data and diverged where it could not, and the published work characterises the reasons. Publishing the conditions under which your own method should not be trusted is the behaviour this index exists to reward. Two caveats belong in the record. Aetion scientists are co authors, so this is not fully independent evaluation. And a data errors correction to the omnibus paper was published in April 2024, which is the correction mechanism working rather than a defect, but a buyer should know it happened. Ask which emulation characteristics predicted divergence, and whether your specific research question resembles the cases that replicated or the cases that did not.

The stewardship question that matters here is not clinical safety, since no patient is exposed to an output, but what happens to patient data inside the analytic environment and what leaves it. Retrieved: the platform is deployable within a customer's own cloud environment, which keeps data in the customer's control, and the workflow is built around auditability and reproducibility, which means analytic actions are logged.

The synthetic data capability acquired in 2022 raises a specific issue that this record should not pass over. Synthetic patient records generated from real patient data are widely treated as privacy safe, and the research literature is not settled on that, because a generative model fitted closely to a small or unusual subpopulation can reproduce individuals rather than merely their distribution. No privacy guarantee framework, no formal disclosure risk metric and no statement of how generated datasets are tested for leakage was retrieved.

Nothing was found on retention, on whether customer data or study specifications contribute to product development, or on what the newer natural language features transmit and where. That last question is the sharpest one, because a natural language interface over a patient level dataset is a path by which record content can reach a model provider. Ask what disclosure risk testing is applied to synthetic datasets before release, whether any customer data or query text reaches a third party model, and what is retained after a study closes.

The framework that governs is de identification rather than business associate status, and naming it is more accurate than marking the vendor down against a test built for care delivery. Real world evidence work of this kind runs on de identified or limited datasets, where the operative instruments are the two paths the privacy rule provides, safe harbour and expert determination, together with the data use agreements attached to each licensed source. A platform analysing de identified claims is not handling protected health information in the sense a clinical vendor does, and a business associate agreement may not be the controlling document.

What was not established is how any of that is executed here. No de identification methodology statement, no disclosure of whether expert determination is used and by whom, no re identification risk assessment, and no published position on the data use terms attached to customer supplied data was retrieved for Aetion specifically in two passes.

The parent relationship makes this worth pressing rather than assuming. Datavant's core business is tokenisation and privacy preserving linkage, and linkage is precisely the operation that raises re identification risk in an otherwise de identified dataset, since each additional linked source narrows the population a record could belong to. Ask which de identification path applies to each dataset in your study, whether an expert determination exists and who issued it, and what re identification risk assessment covers data that has been linked across sources.

Two passes returned one relevant artefact and it is dated. An engineering post published in 2021 by the company's then head of information security describes building the security programme, states that protected health information was hosted with a provider holding a healthcare security certification, and sets certification through formal independent audit as the goal of the programme. That is a credible account of intent from five years ago and it is not a current attestation.

No trust centre, no current certification, no penetration testing summary and no sub processor list was located. A vendor selling into pharmaceutical sponsors has certainly completed many security reviews under agreement, so documentation very probably exists and is simply not published, which is a commercial choice rather than a control failure.

One distinction matters more than the absence itself and a buyer should not blur it. The parent publicly advertises a service organisation control attestation and a federal cloud authorisation for its own connectivity platform. Those cover a different product with a different architecture and a different scope boundary, and a certification held by a corporate sibling is not a certification held by the software you are licensing. Ask for the current attestation covering the evidence platform specifically by name, its scope boundary and audit period, and confirm in writing whether the parent's federal authorisation extends to this product or stops at the linkage platform.

This vendor has no clearance, no authorisation and no marking, and it needs none. Software that produces evidence for a regulatory submission is not a medical device and is not reviewed as one, so the absence of a clearance number is not a gap and should not be graded as one. The frameworks that govern instead are the electronic records and signatures requirements that apply to systems holding records supporting a submission, the evidentiary standards in the agency's own real world evidence guidance developed under the statutory mandate, and the assessment procedures of the non United States bodies a sponsor files with.

What can be verified is unusually substantial and is a different thing from regulatory standing, which is the trap on this axis. The company was the industry partner in a formal agency demonstration project on whether observational studies can support regulatory decisions, with agency staff named as authors on the published results, and it participates in a continuing oncology calibration project with the agency's oncology centre. That is documented methodological engagement with a regulator. It is not approval of a product, it does not transfer to any particular submission, and no buyer should read it as the agency having endorsed this platform.

What is missing is the operational half. No statement of electronic records and signatures validation, no computer system validation package and no record of specific submissions in which evidence generated on this platform was accepted was retrieved in two passes. Ask for the validation documentation covering electronic records and signatures, and for named submissions, with regulator and outcome, where evidence produced on this platform formed part of the filing.

Bias in this setting means confounding and selection rather than demographic disparity in a model output, and by that definition bias control is the discipline the company is built on. Methods for adjusting for measured confounding, defining comparable treatment groups and testing the sensitivity of an estimate are the substance of the product rather than a governance overlay, and they are published in the peer reviewed literature rather than described in marketing terms. Work with the agency's oncology centre has separately included measurement of healthcare disparities in real world data, which is the demographic sense of the term addressed directly.

The governance apparatus around the newer components is where this falls short, and it is the part most relevant to an index of artificial intelligence. Nothing was retrieved describing evaluation, monitoring or fairness testing of the generative features, and nothing describes whether the synthetic data generator reproduces or amplifies the demographic composition of its training population. A synthetic dataset that under represents a subgroup will silently propagate that into every downstream analysis, and no disclosure addresses it.

Unmeasured confounding also remains the structural limit of the whole method and no amount of governance removes it. Ask what evaluation exists for the generative components, what demographic fidelity testing is applied to synthetic datasets, and how the platform surfaces sensitivity of a given result to unmeasured confounding.

No warranty, indemnity, service level or remediation commitment was located in two passes, and no statement describes what the vendor owes a customer if an analytic defect is found after results have been used.

The consequence structure here is unlike a clinical product and is worth stating precisely, because it is what makes the absence matter. An error does not reach a patient through a screen. It reaches a regulator through a submission, or a payer through a coverage dossier, and it may not surface for months, by which point the filing exists, decisions have been taken on it, and correcting it is a regulatory event rather than a software fix. The exposure is concentrated, delayed and reputational in a way most records in this index never face.

That is not hypothetical. A data errors correction to the flagship published work appeared in a major journal in April 2024. Errors occur in analyses of this complexity and the published literature corrected itself, which is the mechanism functioning as designed rather than a failing. It does make the question concrete: the same class of error inside a commercial study would surface through a different route with no equivalent correction machinery attached. Ask what the vendor commits to on defect disclosure and remediation, what happens if a platform defect is identified after your evidence has been submitted, and who bears the cost of rerunning affected analyses.

The axis as normally applied does not fit, because this software never touches a record system at the point of care and integrates with no clinical workflow. What governs instead is data interoperability upstream: which data types the platform ingests, whether it holds to a common data model, and how a customer's own and licensed sources are brought together.

On that reading the position is moderate and partly documented. The platform is described as data agnostic and works across structured longitudinal sources including claims and record derived data, with a module devoted to transforming complex datasets and defining measures reproducibly, which is where most of the practical integration effort in this field actually sits. Availability through a cloud marketplace for deployment inside the customer's own environment simplifies the procurement and connection path. The stated post acquisition direction places the evidence platform above the parent's linkage layer, which would extend reach considerably if delivered.

What was not established is whether the platform commits to a published common data model, which is the interoperability question that decides whether a study is portable to another vendor or another dataset without being rebuilt. Nor was any statement retrieved on extracting analysis ready datasets and specifications out of the platform. Ask which common data model the platform supports natively, what is required to port an existing study specification in or out, and whether your licensed data sources are already supported or need bespoke transformation.

The deployment position is stated and it is favourable. The platform is offered through a public cloud marketplace for deployment within the customer's own cloud environment, which means a sponsor can run studies inside its own tenancy, in a region it selects, under its existing enterprise cloud agreement and security controls. For a buyer whose data licences restrict where analysis may occur, or who must satisfy a data protection authority about cross border transfer, that is the strongest arrangement available and it does not have to be negotiated as an exception.

The limits keep it below the top band. No region list, no retention schedule and no statement distinguishing which components can run in the customer environment from which require vendor hosted infrastructure was retrieved. The newer development module includes a hosted coding environment, and hosted is the word that matters: whether that sits in the customer tenancy or the vendor's was not established, and it is the module most likely to break an otherwise clean residency story.

The integration path toward the parent's linkage layer raises the same question prospectively, since linkage by design involves a party outside the customer environment. Ask which modules run entirely in your own cloud tenancy and which do not, where the hosted development environment executes, and what changes about residency if linkage services are added.

Two passes across the vendor site, the parent's newsroom, the marketplace listing and independent buyer guidance established no price, no unit of sale and no licensing model. Whether the platform is licensed per seat, per study, per protocol, by data volume or by subscription is not stated, and the split between platform licence and the scientific services the company also sells is not published anywhere retrieved. That split is the one a buyer most needs, because software and study execution are different purchases with different margins.

The ownership change removed the remaining external check. Aetion was venture backed and private before the acquisition and is now inside a private parent, so neither entity files public financials and no independent read on scale, revenue or commitment to the product line is available.

One disclosure issue here is sharper than pricing and is specific to this vendor. Independent buyer guidance now advises treating Aetion and Datavant as a single corporate family rather than as independent bidders. A sponsor running a competitive procurement across real world evidence platforms and data linkage may believe it is comparing two vendors when it is negotiating with one owner, and nothing on either company's public materials makes that obvious at the point a shortlist is drawn. Ask for the licence model and unit of sale in writing, for a clear separation of platform fees from study services fees, and whether any other vendor on your shortlist shares this parent.

This axis normally asks which clinical settings and specialties a product serves, and that question does not apply: no patient is treated and no clinician uses this software. What governs instead is the range of evidence questions and therapeutic areas the platform can address, and on that reading coverage is broad.

The platform is described as data agnostic and is not restricted to a therapeutic area. Published work spans cardiovascular disease, diabetes and oncology through the regulatory demonstration projects, and the commercial use cases named across the product materials and independent guidance cover external control arms, post approval safety, treatment effect heterogeneity, label expansion, market access and health technology assessment submissions. It reaches across the product lifecycle from clinical development into post market, and across buyer types from sponsors to payers to regulators, which is wider than a vendor anchored to a single decision point.

Two limits keep it below the top band. Coverage depends on the underlying data a customer brings or licenses, so the effective specialty reach is set by data availability rather than by the platform, and conditions poorly represented in claims and routine care data are correspondingly poorly served. And the range of non United States regulatory and health technology assessment bodies whose submissions the platform has actually supported was not established in two passes. Ask which therapeutic areas the vendor has executed submission grade studies in, and which specific regulatory or assessment bodies have accepted evidence produced on this platform.