ThetaRho

The company draws the line itself: clean data alone is not intelligence, and the layer it sells as its differentiator is the one that adds medical ontologies, semantic embeddings and clinical natural language processing on top of normalised records. Its two shipped applications are both generative and both would not exist without the model layer.

The normalisation work underneath is genuine infrastructure and is the kind of asset this index grades down elsewhere when it IS the product, but here it is explicitly positioned as the foundation rather than the offering, and the commercial pitch is the reasoning built on it.

Verification is designed in at the answer level. Clinical question answering is described as grounded in the patient's own data with traceable citations, every response verifiable and every source linked, sitting on top of a platform that maintains a complete audit trail and data lineage. That combination lets a clinician check any statement and lets an organisation reconstruct where a piece of data came from, which is more than most of this category offers.

Held at B because no confidence signal, routing threshold or abstention behaviour is published, and because the company's own framing substitutes an assertion for a control: stating that nothing is hallucinated describes a desired property rather than a mechanism that enforces it. Ask what happens when the record does not contain the answer, and whether the system says so or produces something anyway.

One of the better disclosures in this category, undercut by one sentence.

ThetaRho names the models it runs on, citing Llama, Aloe and GPT models for clinical question answering, which is the fourth vendor anywhere in this index to answer the whose model is it question and the only one to name an open medical model family. It also names its full ontology stack rather than gesturing at standards, listing RxNorm for medications, SNOMED CT for diagnoses, LOINC for laboratory results, MeSH for research concepts and ICD-10, and it describes a complete audit trail and data lineage. Responses are described as grounded in patient data with traceable citations and every source linked.

Held at B rather than A for two reasons. No accuracy figure, benchmark or evaluation methodology exists for any of it. And the same sentence that describes the grounding concludes that nothing is hallucinated. That is an absolute claim, unfalsifiable as written, and it sits oddly against a category where the dominant failure mode is silent omission. Publishing a measured rate instead would move this to A.

The model layer is named individually, which very few vendors anywhere in this index do, and it includes an open medical model family alongside commercial ones, so a reader can identify not just that a third party model is involved but which lineage the clinical reasoning comes from.

The ontology stack is named rather than gestured at, covering separate standards for medications, diagnoses, laboratory results, research concepts and classification, which tells a buyer how content is normalised and therefore where a mapping error could arise. A complete audit trail and data lineage are described. Held below the top grade by the ingest surface, which is the substance here.

The platform draws from four sources and they do not all arrive under the same regime: clinical records from a provider are protected information held by a covered entity, exchange data comes with its own conditions, public research corpora raise no patient question at all, and patient generated data from wearables and remote monitoring originates outside the privacy rule entirely, governed instead by a device maker's terms and consumer law.

When that stream flows into a clinical platform it crosses into the rule's scope, and the crossing point is where obligations change hands. A patient who accepted a wearable manufacturer's terms did not thereby consent to a clinical platform holding the same stream. Ask for retention per source, and the consent path for patient generated data specifically.

External technical validation without customer outcome data. Both products are carried on the athenahealth Marketplace and RISA is described as certified there, which means a major EHR vendor applied its own review before listing, and that is a real signal of the kind this index credits. Physician testimonials appear on the company's site and are unattributed.

Beyond that, no customer is named, no funding is disclosed, no deployment scale is stated, and no accuracy, time saving or outcome measure of any kind was located. For a platform positioning itself as infrastructure others build on, the absence of any named organisation building on it is the gap to press.

No retention period, training use statement or de identification posture was located in a second pass. The scope concern from the earlier assessment is confirmed and it resolves into something sharper than breadth.

The platform ingests from four sources: record systems via interfaces, health information exchanges through the national networks, patient generated data from wearables and remote monitoring devices, and public research corpora. Those do not all arrive under the same regime.

Clinical records from a provider are protected health information held by a covered entity. Data from a consumer wearable is not: it originates outside the privacy rule, governed instead by the device maker's own terms, general consumer protection rules including the health breach notification requirements, and state law. When that data flows into a clinical platform it crosses into the rule's scope, and the crossing point is where obligations change hands.

So a buyer cannot ask one retention question and be done. Establish what is retained from each source, whether patient generated data is treated differently from clinical data, what the basis for ingesting it was, and who obtained the patient's agreement to that flow. A patient who consented to a wearable manufacturer's terms did not thereby consent to a clinical platform holding the same stream.

The research corpora sit outside all of this and raise no patient privacy question, but their presence means the store is not uniform.

The training question is unanswered in either direction, and for a platform assembling this much per patient it is the one to get in contract language.

Ask for the schedule per source, and the consent path for patient generated data.

HIPAA compliance is claimed specifically for the intelligence layer API, which the company describes as versioned and HIPAA compliant, with no business associate agreement terms published. That is the standard middle rung. One question the layered architecture raises: because third parties are invited to build applications on layers one and two, establish who holds the agreement when a clinician uses somebody else's product running on this platform, and whether the buyer's BAA reaches ThetaRho or stops at the application vendor.

A second pass located no attestation and no trust centre. The clarification from the earlier assessment stands: a complete audit trail and data lineage capability is a product feature supporting compliance work, not an independent examination, and should not be counted here.

One obligation is worth establishing precisely rather than assuming, because the national exchange framework carries a healthcare specific security certification requirement for participating networks. This vendor connects through those networks rather than operating as one, so the requirement may attach to its exchange partners rather than to it directly. That distinction matters both ways. It means the certification may not be compulsory for this company, and it means a buyer should not read the vendor's participation in a certified network as evidence about the vendor's own controls. Ask which obligations flow through to it under its participation agreements.

The access profile is what an examination would need to cover, and it is unusual. Through those network connections the platform can retrieve records about a patient from organisations that have no relationship with this vendor at all. The credentials and query rights that make that possible are the most sensitive thing it holds, more so than any single customer's data, because their misuse would reach across institutions rather than within one.

Distribution through a major record system's marketplace means that vendor performed its own diligence before listing. That assessment exists and is the artefact a practice would find most useful.

Ask what report is held or scheduled, what the network participation agreements require, and whether the marketplace partner's review can be shared.

No clearance, device authorisation or exemption analysis was located. The credit recorded in the earlier assessment stands and the second pass supports it, while surfacing one boundary the vendor's framing does not obviously cover.

The framing first, because it is a genuinely coherent scoping argument. The company positions the product as context work performed before physician judgement rather than as the judgement itself, and the retrieval examples it publishes bear that out: asking for the discharge summary from the latest hospital visit, or whether a patient is on a particular medication class. Those are questions with answers already in the record. The system finds and presents; it does not conclude. A clinician testimonial describing it as a resident gathering information captures the same division of labour.

The boundary is the research corpora. The platform also ingests published literature and clinical trial registries alongside the patient's record. Answering a question from a patient's own chart is retrieval. Answering one from the literature is clinical reference, which is a different category occupied by dedicated products, and a system holding both can be asked questions that blend them. The distinction will not be obvious to a clinician typing into a single box.

So establish what the product does when a question cannot be answered from the record: does it decline, or does it answer from the literature, and is the source of an answer made plain.

And the earlier assessment's instruction remains the right one. The scoping argument is sound and it should be documented by the vendor as a written position rather than inferred by a reader from marketing material.

The grade describes disclosure. Positives first: naming the underlying models is itself a governance disclosure, since a buyer cannot reason about model behaviour without knowing which models are involved, and citation plus audit trail supports accountability after the fact. Against that, no fairness, subgroup or demographic performance disclosure of any kind was located, no evaluation framework is described, and no responsible AI documentation exists.

The claim that nothing is hallucinated is the specific problem: an absolute assurance offered in place of a measurement discourages exactly the scrutiny a governance programme is supposed to invite, and a buyer should treat it as a prompt to ask for the measured rate rather than as a reassurance.

Responses are described as grounded in patient data with traceable citations and every source linked, which is the right control for this product type and it is what carries the grade. The same sentence that describes the grounding concludes that nothing is hallucinated, and that claim is worth examining rather than passing over, because it fails in two ways at once. It is an absolute, unfalsifiable as written and refuted by a single counterexample the vendor would then have to explain.

And it addresses the wrong failure mode. In a grounded summariser the characteristic error is not fabrication but silent omission: the system retrieves what it found and presents it confidently, and the clinician has no way to see the note it did not surface. A guarantee against inventing content says nothing about leaving content out, so even if the claim were true and demonstrable it would not answer the question a buyer needs answered.

This index has recorded elsewhere that an assurance of this kind removes the reason to build the review step that would catch the exception. Nothing is measured: no accuracy figure, benchmark or evaluation methodology exists, and no warranty, indemnity or remediation commitment was located. Publishing a measured omission rate on clinically significant content instead of the absolute would be worth more than the claim. Ask for it.

Strong on breadth and standards, thin on evidenced deployment. Four EHRs are named explicitly, athenahealth, Epic, Cerner and Meditech, alongside health exchange connectivity through both CommonWell and TEFCA, patient generated data from wearables and remote monitoring devices, and public research corpora.

Everything is normalised to FHIR R4 with deduplication and reconciliation across sources, and annotated against a named ontology stack, which is real interoperability engineering rather than a claim of seamless integration. Two products are carried on the athenahealth Marketplace with RISA described as certified. Held at B because athenahealth is the only integration externally corroborated, the other three EHRs are named but not evidenced, and no customer deployment is described anywhere.

A hosted, versioned API is the described delivery model for the intelligence layer, with applications running on top of it, which establishes cloud delivery and no customer hosted option. Nothing further is published: no cloud provider, region, residency commitment or statement about where assembled records are processed. Graded C because the delivery model is clear and the residency picture is entirely absent.

No price, tier or pricing mechanism was located.

The layered model makes the commercial question unusually important. Establish whether you are buying an application, API access to the intelligence layer, or the normalisation infrastructure, because those are three different products with three different cost structures sold under one name, and a quote for one is not comparable to a quote for another.

Broad rather than deep, and broad across two dimensions that rarely appear together. On the clinical side the products are specialty agnostic and ambulatory led through the athenahealth install base, with the company offering demonstrations framed around a buyer's own specialty.

On the customer side it addresses three distinct buyer types with the same stack: clinicians using its own applications, and separately EHR vendors, health systems and other clinical AI companies building on the layers beneath. Graded B rather than A because no specialty specific behaviour or instrument level depth was located, and because coverage does not extend to inpatient or post acute settings.