Radattest.
For radiologists For hospitals Quality Implementation Contact
Implementation

Security you can verify,
not a claim you accept.

Every statement here is something your own IT can check, with their own tools, on your own workstation. We publish the limits of our evidence too.

Verifiable, not vouched-for

Four checks. Run by anyone you trust.

Every claim on this page can be checked independently — with standard tools, on your own workstation, by anyone you trust: your security team, your IT, an outside auditor. We hand you the checks. Running them is your option, not your project.

Nothing hidden in what we ship Read every installed file and confirm no outbound path exists in the code — before anything is switched on. The point is that there is nothing to find, not something switched off.
It can't start in a weaker state The build checks its own posture at startup. If that check fails, it refuses to run.
Watch it while it works Network activity, destinations and the connection log, live during a real reading session — not a report generated afterwards. See the panel.
The one that settles it Your own packet capture or firewall log, on the workstation. It doesn't rely on our instrumentation being honest — which is why it's the check that counts. We'll sit with you while you run it.

The claim all four checks exist to prove

Patient data moves only between systems you own, inside your network. It reaches Radattest — or any third party — never. That is the sentence the checks let you test rather than take.

What our own evidence does not prove

Our panel instruments the application's own outbound layer — complete for that process, not for the machine. The browser isn't instrumented. Helper processes run separately, listed with their real last-run times. And all of it is our own instrumentation, which makes it evidence rather than proof. That's why the fourth check is yours.

The third check, open

Watch the network while you read.

Not a datasheet and not a report written afterwards. This panel is in the application, it can be opened mid-shift, and it refreshes every three seconds while somebody is using the product.

Animated: the network panel's live header — a green no-external-connections banner above tiles reading 0 external connections, 0 refused, and an observation clock that ticks upward as the panel refreshes every three seconds.
Live product The clock is really running — these are consecutive refreshes of the panel on a workstation in use.
The network activity panel in full: no external connections, zero refused, an observation clock, an empty external-destinations table, an empty inbound-report-history table, a connection log listing each request by time, destination and result, and a closing note titled what this page does and does not prove.
Live product Every request the application made, by time and destination — and the panel's own closing section naming what it does not prove. Hover to enlarge, click to read every row.Tap the screenshot to open it full size, then drag to read every row.

The part most vendors would have deleted

The panel ends by arguing against itself: the browser isn't instrumented, helper processes run separately and are listed with their real last-run times, and all of it is our own instrumentation — evidence, not proof. That paragraph is in the product, not just on this page, because the fourth check being yours is the whole point.

What leaves, and how

Exactly what leaves, byte for byte.

The most useful security artifact we can hand an interface analyst is the literal message, readable before anything is configured to send it.

Radattest ORU^R01 HL7 v2.5.1 Interface engine mapped EMR / chart Report writeback you already need One message MSH message header PID patient identity OBR order · accession · study description OBX report body, one segment per line LOINC 18782-3 · radiology study observation OBX follow-up recommendation · one group per finding local RADATTEST namespace, mapped at the engine FU_MODALITY FU_EXAM FU_BODYSITE FU_DUE_EARLIEST FU_DUE_LATEST FU_INDICATION FU_BASIS FU_TRACKING_ID FU_CONFIDENCE FU_SOURCE_TEXT the sentence as dictated Rides on the same message. No second interface, no new firewall rule, no new project number in the IT queue.

Why the local code namespace. There is no settled LOINC panel for a radiology follow-up recommendation. Inventing plausible-looking LOINC codes produces a message that passes a syntax check and means the wrong thing in the receiving dictionary, so the follow-up fields use a local namespace and get mapped at the interface engine during integration. That is a conversation, not a guess.

For sites on FHIR R4

The same recommendation expresses as a ServiceRequest plus a Task. The ServiceRequest carries intent: "plan", deliberately: a radiologist recommends a study, they do not order one. A declined recommendation maps to Task status rejected with the reason attached — an answered obligation, not a failure.

Follow-up tracking

The follow-up loop, explained.

Every recommendation sits in exactly one of these states, and every move between them is recorded with who caused it.

registered at signature notified at 75% of the interval max 3 notices · 21d apart accepted an order is expected deferred new date, clock still running closed-declined answered no, with a reason a CLOSED loop, not a miss escalated due passed, unanswered to a navigator worklist

Patient-directed outreach is off unless you enable it, and even then it fires only where the provider route has already been exhausted. Contacting patients carries consent and contact-data obligations that messaging their clinician does not, so it is a deployment decision rather than a default.

The switching costs, carried by us

The hard parts are ours.

Everything that makes changing reporting systems scary is real. The product decision is that we carry those parts, not you.

  • Integration decides, so it comes first. The exact message your engine receives is readable before anything sends — one feed, riding on the report writeback you already need, no new project number in the IT queue.
  • Your templates and macros arrive with you. Imported from your current system's real export format — years of accumulated habits on day one, nothing rebuilt by hand.
  • Clinical reliability is unforgiving, and treated that way. One bad urgent read costs more trust than fifty features earn, so uptime and graceful degradation are product concerns here, not infrastructure afterthoughts.
  • Somebody answers. Support for clinical software is an operational commitment we take on — and you reach the person who can actually fix it, not a ticket queue.
Ask your questions What it checks before signature
Getting started

Three steps to start.

Bring your macros and templates Imported from the reporting system you already use, parsed from its real export format rather than retyped.
Shape it to how you work Dictation mode, impression preference and correction rules, set per radiologist, effective immediately.
Agree the governance before the data Who sees what, and who holds the switch, settled in writing at install.
Ask for it

Want it to work some other way?

Configurability is the whole design, and it does not stop at the settings that happen to exist today. If your group or your facility wants a behaviour changed, a metric defined differently, a template shaped another way or something added outright — ask. It is very often possible, and you will be talking to the radiologist who builds it rather than to a roadmap.

Ask for a change