Radattest.
For radiologists For hospitals Quality Implementation Contact
Why before the error

The argument.

Radiology QA today means retrospective peer review: a small random sample, scored after the fact, feeding credentialing. This is a different category, not a better version of that one.

Before the error, not after it

The mental model everyone brings to the word “QA” is retrospective. Ours isn't.

It arrives too late to help the patient, the sample is too small to mean much, and its real function is compliance rather than improvement. Every check here runs before signature, on every report, and its output is a finished report — not a score about a radiologist.

Retrospective peer review
  • Finds the error after the report left the building
  • A sample. Most reports are never looked at
  • Produces a discrepancy: a date, a signer, a patient
  • Costs the radiologist time and standing
What we do
  • Catches it while it is still free to fix
  • Every report, every time
  • Produces a non-event: the report was simply correct
  • Costs the radiologist nothing and no clicks

Everything a facility wants out of a quality program — timeliness evidence, closed loops on critical results, follow-up completion, an audit trail — is a byproduct of that prospective work, not a separate audit. The facility gets more evidence and the radiologists get audited less. The second is what produces the first.

The hardest question, answered directly

If it shows the last three impressions, it can show that somebody missed something.

Yes. The prior report is already in the medical record and already discoverable — not surfacing it doesn't delete it, it only guarantees that the first person to notice a discrepancy is someone other than a radiologist. In practice that person is a plaintiff's expert, months or years later, with hindsight and an incentive. Surfacing it at signature means the radiologist is the one who can still fix it, for free, before the report exists.

The single strongest sentence we have on this

The prior report is in the chart either way. The only question is whether a radiologist sees it before signing — or an attorney sees it after.

It is reciprocal, which makes it insurance rather than surveillance: the check that surfaces a colleague's missed finding on your study is the same check that surfaces yours on theirs. And the ledger counts saves, not blame — a hard product requirement, not a slogan. The continuity check records that a discrepancy was resolved at signature. It does not record, display, export, or retain who authored the earlier report.

The data, governed the same way

Configurability, applied a second time.

Who sees what, and who holds the switch

You are always the first person to see your own numbers. Every metric is configurable — what's measured, what's shown, and to whom — and the switch is in the group's hands. Not the hospital's, and not ours. Your group's performance data has always existed. You've just never been given a copy.

The hard parts, and whose they are

A page like this is only useful if it names the parts that are genuinely hard — and says who carries them. These four are hard for anyone building a reporting system. The product decision is that they are ours to carry, not yours:

Integration decides, so it is treated as first-class work. Connectivity is what lets a facility say yes, and it is the least glamorous work in the product — which is why the literal interface message is readable before a feed exists, and why it rides on the report writeback a site already needs.

Migration is more than a file import, so it isn't one. Templates, macros and habits represent years of accumulated investment, and moving them badly is how good software gets abandoned in week three. So they are imported from the real export of the system being left, not retyped — part of starting, not an afterthought.

Clinical reliability is unforgiving. A failure during an urgent read costs more trust than fifty good features earn, so uptime and graceful degradation are product concerns here rather than infrastructure ones.

Support expectations are real, and taken on. Clinical software implies somebody answers at 2am. That is an operational commitment we accept rather than something product quality substitutes for — and the person who answers is the one who can actually fix it.