Glass Health

The reasoning engine is the product. Ranked differentials, cited clinical question answering across a 38 million article index, and drafted assessment and plan are all model outputs, and the Developer API sells that intelligence directly as a component to other platforms.

The verification mechanism is a strong structural answer, and the operating limit is not published.

What exists is real and it is the right control for this product. Every response carries inline citations to source literature and guidelines, so a clinician can check any individual statement against the evidence rather than trusting the output, and an error is contestable at the moment of use rather than discoverable after the fact. The company states the product is decision support requiring physician judgment on every output and declines to position it otherwise. It also acknowledges publicly that reasoning is strongest on common presentations and weaker on complex multi system cases, which is a vendor publishing where its product is weaker and few do.

What is missing is the threshold at which the system stops. Nothing describes abstention behavior, so a clinician cannot tell whether a confident ranked differential for a complex multi system case means the system judged it well or simply answered anyway. No confidence signal accompanies an output, no statement says what the product will not attempt, and the acknowledged weakness on hard cases is a published limitation rather than a limit built into the product's behavior.

That distinction is the whole of the gap. An acknowledged limitation tells a buyer where to be careful; an abstention rule tells the product when to stop. Glass Health has the first and not the second, and the output is a ranked differential diagnosis, which is the shape where overconfidence on a hard case does the most damage.

Citation traceability also does not address the failure mode that matters most in retrieval systems, a correct citation attached to a claim the source does not support, and nothing published describes whether citations are validated against the claims they carry.

Unusually specific about what the system reasons over, and silent about what does the reasoning.

The corpus is disclosed precisely: an index of more than 38 million peer reviewed articles, consensus guidelines and regulatory drug information covering more than 154,000 compounds, with inline citations exposing the sources behind any given answer. That is the approach named, and for a retrieval based product it is substantive rather than decorative, because a clinician can see what the answer was built from and go and read it.

Beyond that, the model is not disclosed at all. No foundation model is identified, proprietary or adapted, no model family, no version, and no account of how changes are tested or released. A customer cannot establish what produces the output today, whether it is the same thing that produced it last month, or how they would learn it had changed.

That gap matters more here than it would for a note writer, and it compounds a second fact. The evidence position rests on an external benchmark placement recorded at a point in time. A benchmark result describes the system that was evaluated. Where the model behind it is unnamed and unversioned, a buyer cannot establish that the system they are buying is the system that was measured, and nothing published would tell them if it had been swapped.

Disclosing an evidence corpus and disclosing a model answer different questions, and Glass Health answers one of them well.

The evidence corpus is disclosed with unusual specificity and the model layer is not.

The system is described as reasoning over an index of more than 38 million peer reviewed articles, consensus guidelines and regulatory drug information covering more than 154,000 compounds, with inline citations exposing the sources behind any given answer. For a decision support product that is a real answer to half of the supply chain question, because the material contributing to the output is both named by category and traceable per answer.

The other half is absent. No foundation model provider, model class or version is named, no hosting arrangement is published, and no sub processor register exists. Nor is it stated how the chain differs between the free individual tier and an enterprise agreement, and that distinction matters here because the product also performs ambient scribing and draws patient and visit context into subsequent questions, so a clinician on a free tier may be sending encounter content through a chain governed by consumer terms.

One direction of flow is unusual enough to name. The developer interface sells the whole stack to other companies building clinical products, so this vendor is a link in other people's chains as well as having one of its own. A health system buying a product built on this interface inherits an unnamed model layer at one remove, and the supplier in front of it may not be able to answer either.

The company publishes a buyer's guide telling readers to establish subprocessors, retention, logging and regions before committing. That is the right list and it is not answered here.

Independently evaluated by a named academic benchmark, which is the appropriate evidence standard for a product that proposes differentials and is rarer here than vendor accuracy claims.

The platform was assessed in the ARISE NOHARM evaluation, a physician validated clinical safety benchmark run out of Harvard and Stanford, where it ranked among the top medical AI systems in the results published at the time. Submitting to an evaluation the vendor does not control and publishing the placement is categorically stronger than publishing an internal accuracy figure. The same independent testing documents the limits rather than only the result, noting that reasoning is weaker on complex multi system cases than on common presentations.

Two qualifications matter, and neither undoes the placement.

The placement is a point in time result. The model behind the product is not named or versioned anywhere, so a buyer cannot establish that the system evaluated in the benchmark is the system running now, and nothing published would tell them if it had changed. For a benchmark result to stay meaningful the artifact it measured has to stay identifiable, and here it does not.

And the evaluation covers the reasoning output. The product also performs ambient scribing and, on the evidence of the company's own site structure, now runs a patient facing line as well. No evidence of any kind covers those, and a benchmark placement earned by the differential engine says nothing about them.

The evaluator is named, so the benchmark's method and the platform's current standing in it can be checked at the source rather than taken from the vendor.

This product handles protected health information at depth and at volume, and the published answer stops at the compliance frame.

The exposure is wide and getting wider. Ambient scribing means recorded patient encounters. The platform draws patient and visit context into subsequent questions. The developer interface accepts production data of this kind under a business associate agreement. And the company's published site map now carries a patient facing section, including guides on connecting medical records and organizing wearable data, which would mean patients handing over their own records directly rather than a clinician doing it on their behalf.

What is published is the compliance position and essentially nothing beyond it. The agreement route is stated clearly, and answers carry in text citations and structured reference sections so a clinician can audit the evidence behind an output.

The stewardship questions are unanswered: whether encounter audio or transcripts are retained and for how long, whether customer content or protected health information is used to train or improve models, what the deletion path is, or how any of it differs between the free individual tier and an enterprise agreement. That last distinction matters here, because the same product is sold both ways and a clinician on a free tier recording a patient encounter is the bottom up adoption pattern that causes institutional compliance problems.

One limit on that statement should be explicit. A privacy route exists on the company's own site and may publish those answers.

The mechanism is the notable part here, and it is an operationally concrete route to a business associate agreement. The developer documentation states that Glass is end to end HIPAA compliant and that teams can review and accept such an agreement in API settings before sending production protected health information. An agreement executed as a self serve step inside the product, gating transmission of that data, is a different and better thing than one promised in a sales conversation.

Three gaps remain. The statement sits in the developer API documentation, so it is not established that the same self serve path governs the clinician facing product. End to end HIPAA compliant is a strong self assertion with no attestation published behind it. And no terms, tier, subprocessor list or execution detail is published. Whether the in product agreement covers the main application or only API customers is the most important open question.

The developer, legal and marketing pages show no SOC 2 report of either type, no HITRUST certification, no ISO 27001, no penetration testing statement and no public trust center for this vendor. The absence is now tested rather than assumed, and two things make it matter more here than it would elsewhere.

The market context is unflattering. Clinical reference and ambient documentation are categories where an independently examined security posture has become the procurement baseline. In that market, an absence is conspicuous rather than merely unstated.

The second point is specific to Glass Health. The company sells a developer interface delivering clinical question answering, record summarization, differential generation and ambient scribing to other companies building clinical products. A developer buyer does not simply trust this vendor, it inherits this vendor's posture into its own product and passes it downstream to health systems. Subprocessors, retention, logging and hosting regions are more load bearing for an interface business than for a direct application, not less.

The sharpest point is the company's own. Glass Health publishes a buyer's guide to evaluating healthcare AI interfaces which tells readers to establish business associate agreement scope, eligible services, retention, logging, regions and subprocessors before committing. That is the right list. The company does not publicly answer it for itself.

This is about what a counterparty can verify before entering a sales conversation, not a judgment that controls are absent. A company holding production protected health information under business associate agreements will have security documentation and enterprise buyers will have seen it under non disclosure.

No clearance, none claimed and none apparently sought, and the company's site now raises a second question.

On the clinician side the decision support exclusion position is supported by architecture rather than merely asserted. Outputs carry in text citations and structured reference sections, the company states the product is decision support requiring physician judgment on every output, and independent testing is acknowledged rather than suppressed. That is the shape the exclusion asks for.

It still sits close to the line. Comparable products answer questions or surface protocols. This one generates a ranked differential diagnosis with suggested workups from a case description. Producing an ordered list of candidate diagnoses is a materially different act from retrieving what the literature says, and the exclusion turns on whether the clinician can independently review the basis for the recommendation, which is harder when the output is a ranking whose ordering logic is not itself shown. The citations show what each statement rests on; nothing shows why one diagnosis was ranked above another.

The second question is new and sharper. The company's published site map carries a patient facing section, including a how to use it for patients page and a set of patient guides covering medical records, laboratory results and wearable data. The decision support exclusion is available for software whose output goes to a healthcare professional who can independently review the basis for it. Output directed to a patient does not sit inside that exclusion on the same footing, and a company running both a clinician differential engine and a patient facing line needs a position on each. None is published, though the patient pages may say more.

A third exposure follows from the developer interface, which lets third parties embed the same differential engine in products this company does not control.

The vendor submitted itself to an external, third party, physician validated safety benchmark, and the result is public. The Harvard and Stanford ARISE NOHARM evaluation placed the platform among the top medical AI systems when that evaluation was run. Submitting to an evaluation you do not control is categorically stronger than publishing principles about evaluation.

The company also states its outputs are evaluated by clinicians and benchmarked on clinical use cases with healthcare specific safety review, and it acknowledges publicly that reasoning is strongest on common presentations and weaker on complex multi system cases. A vendor that publishes where its product is weaker is being candid.

Several things are absent: no model card, no bias or demographic subgroup analysis of any kind, no error taxonomy, no performance breakdown by specialty or presentation type, and no published error rate. The leading subscription reference product makes the opposite trade. This vendor submitted to someone else's measurement and published the result but offers no framework of its own; the other published a framework for evaluating clinical AI and withheld every result from it. One has the measurement without the framework, the other the framework without the measurement.

The mechanism here is the right one for a decision support product and it is well executed.

Answers carry inline citations and structured reference sections, so a clinician can follow any statement back to the article, guideline or regulatory record it came from and judge the source directly. For a decision support product that is more useful than an accuracy percentage, because a clinician who can see the underlying evidence is not relying on the system's judgment at all, they are using it as a retrieval layer over material they can assess themselves. It is also the mechanism that makes an error contestable at the moment of use rather than discoverable after the fact.

Nothing measures how often the system is right and nothing stands behind it. No accuracy figure, error rate or evaluation methodology is published by the company, no warranty, indemnity or remediation commitment exists, and the external benchmark placement is a comparative ranking rather than a rate this product commits to.

Citation traceability also leaves the failure mode that matters most in retrieval systems untouched: a correct citation attached to a claim the source does not actually support. Nothing describes whether citations are validated against the claims they carry, and a clinician checking a reference sees that the article exists rather than that it says what the answer says it says.

Two commercial details bear on recourse and neither is settled. The same product is sold to individual clinicians on a free tier and to institutions, so what a given user has agreed to depends on a tier, and the terms for each tier may say more. And the developer interface puts the same engine inside products this company does not control, which means the person affected by an error may have no relationship with this vendor at all and no way to know it was involved.

Four record systems have been named and the company's own published site map carries dedicated integration pages for three: Epic, athenahealth and eClinicalWorks. Elation, named in earlier material, has no page in the site map.

The language has been assisted workflows rather than integration, the capability is gated to the top paid tier, and the company's own comparison material tells teams to confirm the current implementation path directly. That is the vendor hedging its own integration claim. No marketplace listing appears on any of the three systems, no standards conformance statement, no named access route inside the chart and no published integration effort. The integration pages may say more.

The real interoperability strength is a different shape. The developer interface exposes the whole stack, covering clinical question answering, chart summarization, differential generation, care planning and scribing, so other platforms can embed the clinical intelligence directly. That is an unusual surface, and it is an integration path for other software vendors rather than depth inside the record system a clinician works in.

It also inverts the usual risk. A developer buyer inherits this vendor's posture into its own product and passes it downstream to health systems, so the questions a health system would ask about retention, subprocessors and hosting regions land one step removed from the people who live with the answers.

The delivery model is clear and unusually self serve for clinical software: a web platform with a free tier, a published plan ladder with direct signup, team and enterprise tiers above it, and a developer interface as a separate deployment surface for embedding. A clinician can be using this product within minutes without an institutional purchase, which is a real and deliberate distribution choice.

What is missing is the institutional side. No data residency statement, no region and no hosting provider is published, which matters because the product accepts production protected health information and records patient encounters. No named health system deployment, implementation shape, uptime commitment or support model is published either, and the only adoption figure available dates from 2023 alongside an enterprise offering described as a pilot at that time.

A self serve product with no published institutional deployment evidence is a different procurement risk from a gated one. The risk is not that nobody uses it, it is that a health system discovers its clinicians already do, on consumer terms, with recorded encounters going somewhere the organization never assessed. Establishing where those encounters physically rest is worth doing before any pilot, and worth doing whether or not a pilot is planned.

One structural fact compounds it. The developer interface means the same infrastructure serves other companies' clinical products, so a health system may be exposed to this vendor's hosting and residency posture through a supplier that never names it.

Freemium with a usable free tier for individuals covering limited scribing and decision support, a published plan ladder with direct signup above it, and team, enterprise and developer interface pricing quoted through sales.

The posture is the disclosure here. A clinician can evaluate and adopt the product without procurement, at a price the vendor publishes rather than quotes. The pricing route is the company's own and a buyer opening it in a browser sees the tiers.

A Pro plan figure of around $90 a month circulates in third party review with no reviewing party named, so it is not a disclosure. The plan ladder itself is the published basis.

The pricing page may carry current figures for each tier.

What stays undisclosed is the institutional end, which is where the money is. No enterprise rate, no unit of charge, no seat or usage basis, and no developer interface pricing of any kind, which matters because that product is sold to other companies building clinical software and its cost structure determines theirs.

Coverage is broad across both the documentation and the reasoning sides, and it is enumerated rather than implied.

Note types span clinic notes, history and physical notes, progress notes, discharge summaries and patient handouts. Reasoning outputs span ranked differential diagnosis with suggested workups, problem oriented assessment and plan drafting, and clinical question answering. The grounding corpus is stated as more than 38 million peer reviewed articles plus consensus guidelines and regulatory drug information covering over 154,000 compounds, which is breadth on the scale of the largest literature indexes and far wider than any curated corpus product.

The audience has widened. The company's published site map carries separate sections for clinicians, practices, developers and patients, the last including a how to use it for patients page and guides on organizing medical records, understanding laboratory results, connecting records to a health application and organizing wearable data. A patient facing line is a different product with different obligations. The patient pages may describe what that product does.

The company itself acknowledges a limit: independent testing notes that reasoning is strongest on common presentations and weaker on complex multi system cases. Breadth of coverage is established; depth at the hard end is not. No specialty specific validation, performance breakdown by presentation type, or named specialty society content partnership is published, and a specialty society partnership is the usual third party credential for reference products.