How three companies describe human review before AI output enters the record

Three products in the library are recorded as examples of one pattern: a person reviews what the software produced before it enters the record. Abridge Platform drafts a clinical note from a conversation; qXR reads a chest X-ray; SOPHiA DDM annotates and pre-classifies genomic variants. Each company describes a review step on its own pages. This article sets those descriptions side by side, in the companies' own words, and then says what each one does and does not tell a reader. It does not say that any of the three workflows works as described in practice, or how safely: Recent has not tested any of them, and nothing here should be read as an independent finding.

What each company says

The table quotes or paraphrases each company's description from the page cited beside it. Where a phrase is in quotation marks, it is the company's; where it is not, it is Recent's paraphrase of the page.

What the descriptions have in common

All three place the software before a person, not instead of one, and all three name the person's step with a verb of judgement: verify, read, interpret. All three also describe the software's output as a draft of something a person then finishes (a note, a report, a classification) rather than as a result that stands on its own. That is the pattern the library records them under, and it is why they are its evidenced examples.

Beyond that, the three descriptions are of different depth, and the differences are worth reading before drawing anything from the similarity.

What each description says, and what it leaves open

Abridge describes the review mechanism in the most detail of the three. Its pages say what the reviewer can do (highlight a passage, see its source in the transcript, listen to the audio) and say that orders are held “for clinician review”. What the pages do not say is whether a note can enter the record without that review being performed, how the product records that a review happened, or how often reviewers change what was drafted. The description is of a capability, and a capability is not a workflow.

Qure.ai describes qXR's place in the sequence: “pre-read assistance”, and its speed and outputs. The phrase locates the software before the reader's read; it does not describe how a finding is accepted, rejected or amended, or what happens to a pre-filled report that the radiologist does not confirm. The page is a description of what the software returns, and the review step is implied by the word “pre-read” rather than described.

SOPHiA GENETICS describes a sequence of steps in which interpretation is the user's and the software's contribution is annotation and pre-classification that “expedite” it. The page is explicit that the interpretation belongs to the person. It does not say what a pre-classification consists of, whether the user sees the basis for it, or how a disagreement between the user and the pre-classification is recorded.

None of the three pages is written to answer those questions, and it would be wrong to read their silence as an answer. A product page describes what a company wants a buyer to know; the operational detail lives in documentation, contracts and the deployments themselves, none of which is cited here.

What Recent draws from this

Two things, and only two. First, that a reader comparing these products should compare the depth of the description as well as its content: a page that describes the mechanism of review can be checked against the product; a page that only names the step cannot. Second, that “human review” on a product page is a claim about design, and design is the beginning of the question rather than the end of it. Whether the review is performed, by whom, under what time pressure and with what visibility of the software's basis are the questions a buyer, a clinical safety officer or a regulator would ask next, and the guidance the pattern cites, on its own page, is where those questions are framed.

The three product records, with their sources, are here: