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 goes after the failure mode that matters in clinical evidence. Rather than generating prose from a model's parameters, the company states that every answer is grounded in an observational study actually executed against real patient data, and that its framework was built so that hallucinated content cannot reach the clinician by that route. The output is a publication grade study a clinician or researcher can inspect, each answer carries citations to the evidence behind it, and where peer reviewed evidence is not available the response is badged as such with its sources displayed. A per answer Real World Fitness Score sits alongside, so a user sees how well the underlying data supported that specific question rather than receiving an undifferentiated answer.

What is missing is any stated limit. Nothing published states what the system may not do, at what fitness score an answer is withheld rather than shown, what escalation or override path exists when a clinician disputes a generated study, or which conditions route a question to a person instead of to the network. The claim that the framework eliminates hallucination risk reads best as a statement about what the architecture removes from the workflow rather than as a claim that every output is correct, which the fitness score's own existence contradicts.

The approach and the data suppliers are named, and the model layer is not.

What is named is substantial. The products are identified individually: GENEVA OS as the underlying operating system, ChatRWD as the chat application that turns a clinical question into an executed observational study, Green Button as the consultation service returning evidence within 48 hours, and Alexandria as the library of pre-computed evidence briefs. The data suppliers behind the federated network are named too, including Norstella, Arcadia and OneMedNet, alongside contributing institutions and an oncology registry. The network's composition is quantified: over 330 million United States patients, more than 150 million electronic health record entries with clinical notes, and imaging and omics data linked to clinical outcomes and mortality.

What produces the answer is deliberately not identified. ChatRWD is stated to be an LLM independent framework, so an institution can maintain its own model security posture rather than inheriting the vendor's model choice. That is a real architectural commitment, and it is also the reason no model, architecture, parameter count or training corpus is named anywhere, and nothing states which models the company runs by default or how a customer supplied model is validated before it is used. No version identifier or update practice is published for any component.

The chain is structurally short on the side that matters most here, because the transfer does not occur. The federated design links records only at query time and no patient level data is transferred to the querying party, so contributing institutions retain possession of their own source data and there is no central pool for a third party to sit next to. The platform can also run inside the customer's own cloud, which shortens it further.

The parties that do sit in the chain are named. Data partners are identified as Norstella, Arcadia and OneMedNet alongside more than a dozen contributing members, an oncology registry operated by a professional society and an international platform contributing data from fifteen countries. The infrastructure providers are named as Amazon Web Services and Google Cloud, including Google's Healthcare Data Engine application programming interfaces and BigQuery, and the company is listed in AWS Marketplace.

The model layer is the gap. ChatRWD is stated to be model independent, so no model provider is named anywhere and nothing says which model runs by default, who hosts it, or what terms govern a query once it reaches one. Naming a hosting provider does not answer that. Nor is there a subprocessor list, or any statement of what governs a member's query and its results once they have crossed the network.

The evidence is named customers and a vendor reported comparison with no method.

The named deployments are real and the provenance is academic. The company spun out of Stanford's Green Button project, and Stanford Health Care has 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. Mayo Clinic Platform and a major oncology registry are named among the network's contributing members, and adoption through distribution partners is reported as reaching roughly a third of United States physicians and about half of major United States health systems.

What is absent is a measurement anyone else can check. The one comparative claim, that the assistant answers clinical questions more accurately than general models including two named consumer systems, is stated by the company with no method, denominator, question set or reference standard. The Real World Fitness Score average of 79.8 across a 2,000 question beta evaluation is a self assessment of data suitability rather than an accuracy result, and no independent evaluation of the platform's output is cited on the record. A September 2026 claim that temporal queries run up to 50 times faster and 30 times cheaper than traditional analytics is published with no method for the comparison.

The company maintains a publications page, which may show whether independently evaluated performance exists.

A categorical commitment about patient data is published and the architecture is what carries it. Atropos operates a federated evidence network rather than a central data warehouse: its nodal deidentification 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 an unqualified claim of deidentification, because it identifies which of the two methods recognized under the Privacy Rule is in use. The platform can also be installed inside a customer's own cloud environment, so an institution can keep the analysis next to its data. Pooling identified records centrally and deidentifying later creates a concentration of risk that this design avoids by construction rather than by policy.

Two gaps remain. Nothing published states a retention window for queries, generated studies or intermediate outputs, or says who can see a query once it has run across the network, and a query is itself revealing because it discloses what a member is investigating. Nothing states whether queries, outputs or contributed data are used to train models.

One commercial fact belongs with the data question. The network has two sided economics: members may be paid for the use of their data. That is disclosed openly, and it means a contributing institution is entering a commercial arrangement over patient derived material, where the terms that matter are downstream use, exclusivity, and what happens to previously generated evidence if it leaves the network.

Safety engineering, meaning guardrails, hallucination mitigation and how a safety event is handled, is not published.

HIPAA is referenced repeatedly across the company's own material, including a statement that keeping data sets separate is better for HIPAA compliance and that its deidentification maps to the HIPAA Safe Harbor standard. Every one of those references sits in marketing or announcement copy. The company publishes no business associate agreement, no template and no summary of terms, and it does not identify itself as a business associate anywhere in its own material.

The trust portal published at trust.atroposhealth.com does not close this. Its compliance module carries a single item, the 2025 SOC 2 Type II report. There is no HIPAA item, no business associate agreement and no statement of business associate status on it. The portal also links to a privacy policy and to terms of service, either of which may address business associate status.

The architecture may account for part of this. Data deidentified to the Safe Harbor standard is not protected health information, so work confined to the federated network may sit outside the business associate relationship, in the way a deidentified data product does. That is a coherent position, but the company does not state it as its position, and it does not cover the whole product: Atropos also installs its platform inside customer cloud environments and offers informatics consult services, and nothing published says which activities involve identified data and which do not.

No statement says which of its services place it in a business associate role, or how a deployment inside the customer's own environment is treated.

A trust portal is published at trust.atroposhealth.com, served through the compliance vendor HyperComply, and it opens without a request. Its published snapshot is dated 6 August 2025.

The portal names a 2025 SOC 2 Type II report as the company's own certification, described as covering security, availability, processing integrity, confidentiality and privacy. The report file sits behind a request access form, so the certification is named and the artifact is not retrievable. No audit period, auditor or renewal cadence accompanies it, and no scope section is visible. An Information Security Plan and an Acceptable Use Policy are listed and gated the same way. The portal also publishes a governance structure: a Security Officer working with a Privacy Officer, both appointed by and reporting to the Board of Directors or the Chief Executive, responsible for the development, testing, implementation, training and oversight of security and compliance activity.

The Amazon Web Services and Google Cloud infrastructure, and the AWS Marketplace listing, are the host's assurance rather than the vendor's.

The company's own website returned a hosting level 404 at the root on 28 September 2026, and the portal's own links to the privacy policy and the terms of service point into that site and do not resolve.

Nor does anything published say whether the assessment boundary covers the federated network and query infrastructure as well as the corporate environment.

The company publishes no clearance, no de novo authorization and no regulatory position. What is missing is a stated position, not a finding that clearance is required.

The live question is the clinical decision support exclusion under the 21st Century Cures Act, which governs evidence and reference products generally. The exclusion turns substantially on whether the clinician can independently review the basis for a recommendation rather than having to rely on it. Atropos has a strong case 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 center 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. The company has not addressed that distinction in anything published.

The trust portal at trust.atroposhealth.com has no regulatory material.

The company is also silent on which of its delivery surfaces a regulatory position would cover.

Atropos publishes an in product transparency mechanism rather than a governance statement, and the mechanism does the work. 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. It lets a user calibrate trust case by case, which is a different thing from a company level policy document.

The measure points at a different property 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. Nothing published reports a subgroup analysis, the population composition of the network, or a bias assessment.

The trust portal at trust.atroposhealth.com publishes no bias, fairness or model governance material.

Nothing published says how the cohort assembled for a given question is checked against the patient it is being used for, or what is reported when it does not match.

One mechanism here 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 an average alongside it is what makes the score interpretable, since a score with no distribution is not. The method behind the evaluation is not published, so what a buyer has is a figure with a denominator and nothing describing how it was produced.

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.

Nothing attaches commercially. The company publishes no warranty, no indemnity and no remediation commitment, and no statement describes what happens when a study generated through the platform is later shown to be wrong.

The trust portal at trust.atroposhealth.com carries no warranty, indemnity or service commitment either.

What a low fitness score means in practice is left unexplained, as is what the vendor commits to when a study it generated turns out to be flawed.

The integration surface is broad and it is not primarily an electronic health record surface. 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 that is not named. The federated network reads more than a dozen contributing data sources, including an oncology registry operated by a major professional society, an international data platform, and the aggregators Norstella, Arcadia and OneMedNet, through which it reaches a reported 150 million records carrying clinical notes.

Read access to named systems, and one directional delivery into named surfaces, is what the integration surface amounts to. Nothing published names a direct integration with an electronic health record, and nothing describes how a result reaches the patient chart or which party owns and supports that path. That is coherent for a product whose primary object is a data set rather than a patient encounter, and it is the specific gap for anyone expecting evidence inside the clinician's existing workflow.

The integration claims above come from the company's own material as it stood on 22 September 2026.

Nothing published names the ambient documentation partner, says whether that integration is certified or bespoke, or says who supports it when either side ships a release.

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 center 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.

The customer installed route places data in the institution's own environment, which is a residency position of a kind, but nothing published commits to a region. That is a live question for a network that explicitly spans jurisdictions, and nothing published describes tenant isolation or which processing crosses a border. No implementation timeline or resourcing expectation is published for either route.

The trust portal at trust.atroposhealth.com says nothing about residency, tenant isolation or subprocessors.

Nor does anything published say which party operates the customer deployed instance after go live.

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.

Two disclosures give the commercial picture some shape. The AWS Marketplace listing is a public procurement route, and a Marketplace transaction has 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, a two sided arrangement stated openly rather than concealed. Both are stated in the company's own material, and the Marketplace listing may carry commercial detail beyond them.

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.

The pricing unit is the missing piece that matters most, because a per query model and an annual platform model produce very different behavior inside an organization deciding whether a given question is worth paying for. For an evidence product, a pricing model that makes clinicians ration questions works against the reason for buying it.

Coverage is named with scale attached and validation behind part of 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, with three delivery surfaces named for it, ChatRWD for self service, Green Button as a 48 hour consultation service, and Alexandria as a library of pre-computed briefs.

The network behind that scope is quantified rather than gestured at: over 330 million United States patients, more than 150 million electronic health record entries including clinical notes, and imaging and omics data linked to clinical outcomes and mortality, drawn through named data partners and more than a dozen contributing members, with an international platform adding data from fifteen countries. Named institutional use includes Stanford Health Care, where the evidence service is embedded in physician workflow and clinical notes, and Mayo Clinic Platform.

The limit is that coverage is a property of the data rather than a validated operating range. Nothing published establishes which clinical domains the network answers well and which it answers poorly, and the company's own Real World Fitness Score exists precisely because that varies question by question. No specialty level performance is published, so a buyer cannot tell where the platform has been shown to work as against where it can be pointed.