Atropos Health

Generating an observational study from a natural language question is the product. The model translates a clinical question into a study design, executes it against the federated data network, and returns publication grade evidence, which is inference doing analytical work rather than retrieval.

The design directly targets the failure mode that matters in clinical evidence. The company states plainly that hallucinations are unacceptable in this field and built the framework to eliminate that risk by grounding every answer in an executed study against real patient data rather than generating prose from a model's parameters.

Combined with the per answer fitness score and publication grade study output that a clinician or researcher can inspect, the human retains the ability to evaluate the evidence rather than trust the assistant.

Two disclosures put this among the strongest on this axis. First, ChatRWD is stated as an LLM independent framework, so an institution can maintain its own model security and integrity rather than inheriting the vendor's model choice, which is a genuine architectural commitment and rare.

Second, every answer carries a Real World Fitness Score rating how fit for purpose the underlying dataset was for that specific question, with a reported average of 79.8 across a 2,000 question beta evaluation. Publishing a per answer quality score is an explicit admission that evidence quality varies by question, and it hands the user the means to discount a weak result.

The architecture is the disclosure here, and it answers this axis by construction rather than by policy. The company operates a federated evidence network rather than a central warehouse: its nodal approach links records only at query time, no patient level data is transferred to the querying party, and contributing institutions retain possession of their own source data.

The alternative design, pooling identified records centrally and de identifying afterwards, creates exactly the concentration of risk this avoids. The de identification method is also named specifically rather than claimed generically, identifying which of the two methods recognised under the privacy rule is in use, which matters because an unqualified claim of de identification tells a reader nothing about the standard applied.

And the platform can be installed inside a customer's own cloud, so an institution can keep the analysis next to its data. Two residuals a contributing institution should still examine. Nothing published states how long queries, generated studies or intermediate outputs are retained, or who can see a query once it has run across the network, and a query is itself revealing since it discloses what a member is investigating.

The network also has two sided economics, with members potentially paid for use of their data, which is disclosed openly and means a contributor is entering a commercial arrangement over patient derived material. Read the terms on downstream use, exclusivity, and what happens to previously generated evidence on exit.

Provenance is academic rather than commercial: the company spun out of Stanford's Green Button project, and Stanford Health Care has since moved from using the service to embedding it in physician workflow and clinical notes, with a pilot evaluating provider satisfaction and use of the evidence in treatment decisions. Adoption reported through First Edition partners reaches roughly a third of US physicians and about half of major US health systems. The company reports ChatRWD answers clinical questions more accurately than general models including ChatGPT and Gemini, which is vendor stated and should be verified independently.

Atropos operates a federated evidence network rather than a central data warehouse, and the architecture is the disclosure. Its nodal de identification approach links records only at query time, maps the result to the HIPAA Safe Harbor standard, and states that no patient level data is transferred to the querying party, so contributing institutions retain possession of their own source data. Naming Safe Harbor specifically is more useful than the usual unqualified claim of de identification, because it identifies which of the two methods recognised under the Privacy Rule is being used. The company also states that its platform can be installed inside a customer's own cloud environment, so an institution can keep the analysis next to its data.

That combination is among the strongest structural positions on patient data in this category. The alternative design, pooling identified records centrally and de identifying afterwards, creates a concentration of risk that this architecture avoids by construction rather than by policy.

Two things a buyer or a contributing institution should still examine. Nothing published states how long queries, generated studies or intermediate outputs are retained, or who can see a query once it has run across the network. And the network has two sided economics: members may be paid for the use of their data. That is disclosed openly, but it means a contributing institution is entering a commercial arrangement over patient derived data and should read the terms covering downstream use, exclusivity, and what happens to previously generated evidence if it leaves the network.

HIPAA is referenced repeatedly across the company's public material, including a statement that keeping data sets separate is better for HIPAA compliance and that its de identification maps to the HIPAA Safe Harbor standard. But every one of those references sits in marketing or announcement copy. No business associate agreement, template or summary of terms was located, and the company does not identify itself as a business associate anywhere retrieved.

The architecture may genuinely explain part of this. Data de identified to the Safe Harbor standard is not protected health information, so work confined to the federated network may sit outside the business associate relationship altogether, in the same way a de identified data product does. That is a coherent position. But it is not the whole product: the company also deploys its platform inside customer cloud environments and offers informatics consult services, and nothing published tells a buyer which activities involve identified data and which do not.

Buyers should ask the company to state plainly which of its services place it in a business associate role, request the agreement covering those services, and ask specifically how a deployment inside the customer's own environment is treated.

No trust centre, security page or third party attestation was located, and no SOC 2, HITRUST or ISO 27001 claim was found in any retrieved material. The security language that does appear is atmospheric rather than checkable: commitments to the highest levels of data privacy and security, and to meeting the enterprise grade security expectations of major health systems. Neither statement identifies a control, a framework or an auditor.

Partial credit is due to the infrastructure disclosure, which is specific. The platform runs on Amazon Web Services and on Google Cloud, using Google's Healthcare Data Engine application programming interfaces and BigQuery, and the company is listed in AWS Marketplace and belongs to the AWS Partner Network. A Marketplace listing carries its own baseline vendor requirements and is a real procurement route.

This records what was found rather than asserting that no attestation exists, and it should be retested on refresh, particularly since the company sells into academic medical centres whose vendor review processes normally require one. Buyers should ask which attestations are held, request the report and its scope section, and ask whether the assessment boundary covers the federated network and query infrastructure as well as the corporate environment.

No clearance, de novo authorisation or stated regulatory position was located. The grade reflects the absence of a published position rather than a judgement that clearance is required.

The live question is the clinical decision support exclusion under the 21st Century Cures Act, the same question that governs the other evidence and reference products in this category. The exclusion turns substantially on whether the clinician can independently review the basis for a recommendation rather than having to rely on it. Atropos is unusually well placed to argue that they can: outputs carry citations, the underlying observational study is inspectable, and the company states that where peer reviewed evidence is unavailable the answer is badged as such with its sources displayed. A product that hands the clinician the study behind the answer sits close to the centre of the exclusion.

What complicates it is the direction of travel. Generating a patient specific analysis at the point of care, delivered inside a clinical conversation platform or a meeting tool, is closer to a recommendation about this patient than a reference lookup is. Buyers should ask the company to state its regulatory position in writing and to say which of its delivery surfaces it considers covered by that position.

Atropos publishes an in product transparency mechanism rather than a governance statement, and the mechanism is the reason for this grade. Every generated answer carries citations to the evidence behind it. Where peer reviewed evidence is not available to answer a question, the company states that the response is badged as such with its sources displayed. And the platform surfaces a quantified data quality measure alongside each query, its Real World Fitness Score, so a clinician sees how well the underlying data supports that particular question rather than receiving an undifferentiated answer.

A displayed, quantified per answer quality signal is a published mechanism rather than an assertion, and very little in this index offers one. It lets a user calibrate trust case by case, which is a different and in some respects more useful thing than a company level policy document.

Held firmly below the top band because the measure points at a different axis from the risk that matters most here. Fitness of the data for a query is not the same as representativeness of the cohort for the patient in front of the clinician. A federated network drawing on many contributed sources will vary substantially in population composition, and generating patient specific evidence from a cohort that does not resemble the patient is the central epistemic risk of this product. No subgroup analysis, population composition disclosure or bias assessment was located. Publishing how answer quality varies across patient populations would move this materially.

One mechanism here is among the best in the index and it is worth explaining precisely, because it measures the right thing. Every answer carries a fitness score rating how suitable the underlying dataset was for that specific question, with a reported average across a two thousand question evaluation. That is not model confidence, which tells a user how sure the system is; it is data fitness, which tells them whether the evidence base could have answered the question at all.

Publishing a per answer score is an explicit admission that evidence quality varies by question rather than being a property of the platform, and it hands the user the means to discount a weak result at the moment they receive it. Publishing the average alongside is what makes it honest, since a score with no distribution is uninterpretable.

The second disclosure is architectural: the assistant is stated to be model independent, so an institution can maintain its own model security and integrity rather than inheriting the vendor's model choice, which is a real commitment and rare. Held below the top grade because nothing attaches commercially. No warranty, indemnity or remediation commitment was located, and no statement describes what happens when a study generated through the platform is later shown to be wrong. Ask what a low fitness score means in practice, and what the vendor commits to on a flawed study.

The integration surface is broad but it is not primarily an electronic health record surface, and the distinction matters when reading this record against others in the category. Atropos connects to data infrastructure and to other vendors' applications: Google Cloud's Healthcare Data Engine through its application programming interfaces and BigQuery, Amazon Web Services with a Marketplace listing, delivery inside Microsoft Teams, and embedding within a partner ambient documentation platform. The federated network itself links more than a dozen contributing data sources, including an oncology registry operated by a major professional society and an international data platform.

No direct integration with a named electronic health record was located, and no description of how a result reaches the patient chart. That is coherent for a product whose primary object is a data set rather than a patient encounter, but a buyer expecting evidence to surface inside the clinician's existing workflow should establish how that happens, through which partner, and which party owns and supports that integration.

Two deployment routes are published and the choice is real. The platform can run as a service, or it can be installed inside the customer's own cloud environment so that analysis runs next to the institution's data rather than moving it. For an academic medical centre or a health system with a mature cloud practice, the second is the more defensible option, and it is offered rather than assumed. Both major cloud providers are named, and the AWS Marketplace listing is a procurement route as well as a technical one.

Deployment evidence is present rather than asserted. Named institutional relationships include Stanford Health Care, where the underlying method began as a research project, Mayo Clinic Platform, and a major oncology registry. The federated network spans more than a dozen contributing members and includes an international platform adding data from fifteen countries.

Held at B because no data residency commitment naming regions was located, which is a live question for a network that explicitly spans jurisdictions, and because no implementation timeline or resourcing expectation is published for either deployment route.

No pricing of any kind is published. There is no list price, no unit of pricing, no tier structure, and no indication of whether the product is sold per query, per seat, per connected data source or as an annual platform fee. The company markets a simplification of the purchasing model, stating that a complicated model for buying data is no longer necessary, which is a claim about pricing structure made without publishing the structure.

Partial credit for two things. The AWS Marketplace listing is a real public procurement route, and Marketplace transactions have a visible commercial mechanism even where the negotiated figure is not published. And the economics of the evidence network are disclosed in outline: contributing members may be paid for the use of their data, which is an unusual two sided arrangement and is stated openly rather than concealed.

Customer accounts of value are specific in kind but not in denominator, describing formulary decisions changed and medications restricted or removed following an evidence review, with no statement of what obtaining that evidence cost. Buyers should establish the pricing unit before anything else, because a per query model and an annual platform model produce very different behaviour inside an organisation deciding whether a given question is worth asking. For an evidence product, a pricing model that makes clinicians ration questions works against the reason for buying it.

Scope is defined by the question rather than the specialty, which is the right framing for evidence generation: any clinical question answerable from the federated network, spanning bedside decisions, life sciences research, and guideline development. The federated network is reported to exceed 300 million anonymized patient records.