DEV Community

Redman WorkflowAlpha
Redman WorkflowAlpha

Posted on

Mentary AI Inside the PACS: Why the Radiologist Wants the Model at the Image, Not in the Cloud

The image is the payload

Every "should we use AI on this?" conversation in a hospital eventually hits the same wall, and it is not a model-quality question. It is a transfer question.

A radiology study is not a file you attach to an API call. It is a DICOM series: hundreds of frames, each tagged with patient ID, accession number, slice thickness, scanner serial, protocol name, window/level presets. The metadata is where the clinical meaning lives, and it is also where the PHI lives.

So the moment you say "we'll send it to a cloud model," you have said three things out loud:

  1. The image leaves the hospital network.
  2. The image is stored somewhere, at least temporarily.
  3. Somebody has to sign off on both of those things - and that somebody is not the radiologist.

That third item is what stalls projects. It is not that the cloud model is bad. It is that the sign-off has to come from legal, procurement, IT security, and the vendor's own compliance team, and those four schedules do not overlap.

What "local" actually has to mean

The pitch is usually "runs on your own hardware." The detail that decides whether it is true or marketing:

Does it speak DICOM, or does it speak HTTP?

A model that exposes an HTTP endpoint is a model that wants to be called from outside. A model that sits in front of the PACS as a DICOM node - receiving via C-STORE, answering via the same route - never leaves the VLAN. The radiologist's workflow does not change. The study goes to the model the same way it goes to the PACS. No export step. No staging folder with patient IDs in filenames. No one-off script someone wrote once and nobody owns.

That is the entire difference. Not speed. Routing.

The concrete setup

The shape of this on a real deployment:

  • The model registers as a DICOM Storage SCP inside the imaging VLAN.
  • The PACS is configured with one additional destination - the same way you already add a second archive.
  • A study arrives, the model is handed the series, inference runs on the local GPU, and a result set comes back into the same VLAN.
  • Nothing traverses the firewall in either direction.

Nothing about that requires a new account, a new key, a new vendor relationship, or a new SaaS bill. The hospital already knows how to operate a second destination.

The sizing question everyone gets backwards

People ask "which model should we buy?" First ask: what is your peak study rate?

A busy imaging department does not generate one study at a time. It generates a stream - CTs stacked up behind each other, the outpatient queue and the emergency queue landing on the same box. A model that answers one study in four seconds is fine until the queue is twelve studies deep, at which point it is a bottleneck with a compliance story attached.

Size for the queue, not for the single case. That means thinking about batching, about which studies are stat and which can wait, and about what happens at 2am when there is one tech and a backlog. None of that is a model-architecture question. It is an operations question, and it is the one that decides whether the thing gets used after month three.

This is what I tested

I spent time with the interactive demo on the Mentary AI page rather than reading the marketing. Worth being precise about what that demo is and is not:

It is a local-inference front end you can drive in a browser - you type a query, it answers, and it tells you plainly that processing is local and no bytes were transmitted. That is a real, working demonstration of the interface layer: the query loop, the model init, the response path. It is the part of the product that has to be correct for the interface to feel trustworthy.

It is not a DICOM router. There is no C-STORE in a browser demo, and no browser can be a PACS node. Anyone telling you a web demo proves a PACS integration is telling you something about their own scope, not about the product. The demo proves the inference path and the local-first posture. The DICOM layer is deployment work that happens on your infrastructure, which is exactly why it comes with deployment engineering support rather than a setup wizard.

What the license actually covers

One-time $299.99, lifetime license, no recurring fees. The package is:

  • Model weights plus the optimized inference engine (CPU and GPU runtimes)
  • Deployment scripts for bare-metal Linux servers, workstations and VMs - dependency resolution, model init, health checks
  • A production-ready Docker image with Compose orchestration, persistent volume config, resource limits, and network isolation policies
  • Documentation: installation, configuration, API usage, security hardening, performance tuning, troubleshooting
  • 30 days of priority deployment support by email

The Docker network isolation policies are the part I would actually look at before signing anything. "Air-gapped" is a claim. A network isolation policy file you can read is a fact.

How to pay

Three routes, all accepted:

  • PayPal - send 299.99 USD to redman1309@proton.me (that is the PayPal account). You get a payment request, we confirm it in our inbox.
  • Crypto - 0x078fE079A9440631Bc6AD722D7143dC382b4ea4f on Base. ETH, USDC, USDT.
  • Western Union / MoneyGram - recipient details provided on request, keep your confirmation and MTCN.

After payment, email workflowalpha.ai@gmail.com with the transaction hash or confirmation for verification, and the package is delivered digitally.

No paypal.me link, no checkout page, no account to create. That is deliberate: the transaction stays between the two parties and the record is the email trail.

What I'd say to the person signing this

You are not buying a model. You are buying the right to never explain to a regulator where the image went.

Those are different purchases, and only one of them shows up in a feature list. Read the Docker isolation policies. Ask the vendor what the model speaks - DICOM or HTTP - and whether it can sit as a destination inside your existing VLAN without a new firewall rule. If the answer to either is vague, that is your answer.

Live page with the working demo: https://reggiebro.github.io/WorkflowAlpha.ai/mentary-ai/

Top comments (0)