Next-gen radiology is a stack, not a slogan: AI as a second set of eyes, cloud PACS / DICOMweb so the study is not locked to one workstation, a web DICOM viewer as the cockpit, and hardware that actually changes the pixels (photon-counting CT, helium-free MRI). It is not “what is AI in radiology.” It is not the future of medical imaging as a field.
If you meant what is AI in radiology / will AI replace radiologists → artificial intelligence in radiology. If you meant Merlin / RADAR papers → Merlin / RADAR. If you meant PACS / DICOM handshake → PACS and DICOM. If you meant volume rendering → volume rendering of CT. If you meant radiology workflow / worklist → radiology workflow optimization. If you meant generic AI diagnosis → AI for medical diagnosis. If you meant future of medical imaging as a field (radiomics / ethics) → the future of medical imaging.
If the work is a web DICOM viewer or imaging model inside a next-gen stack, PYCAD is the imaging piece (viewer / model), not a next-gen-radiology vendor.
The stack, not a costume
Traditional radiology is a linear hand-off: scan, park the study on an on-premise PACS, read it on a dedicated workstation, send a report. Every hop is a wait. Next-gen radiology is the same clinical job with four pieces that talk to each other:
- Intelligent automation. AI flags candidates, measures, and bumps the worklist. A mark is a candidate. The signed report is still a person. The AI-in-radiology explainer is 671.
- Cloud access. The archive is a cloud-native PACS talking DICOMweb, not a server in a closet the radiologist has to sit next to.
- Web visualization. A browser DICOM viewer is the cockpit: MPR, annotations, the AI overlay. No thick client, no “only on that workstation.”
- Hardware that changes the pixels. Photon-counting CT and helium-free MRI are not software. They change what you can see and at what dose. Rendering those volumes is 687.
A rural scan read by a sub-specialist in another city, with a triage flag already on the worklist, is the stack working. A slide that says “we do next-gen radiology” is not.
Traditional vs next-gen
| Aspect | Traditional radiology | Next-gen radiology |
|---|---|---|
| Storage | On-premise PACS, capacity you bought last year | Cloud-native archive that scales with volume |
| Access | Dedicated on-site workstation | Any device with a browser, via DICOMweb |
| Analysis | Manual read only | AI-assisted detection and quantification; person still signs |
| Workflow | Linear, siloed, a lot of re-keying | Integrated worklist, fewer hops. The worklist job is 694 |
| Interop | Vendor formats, burn a CD | DICOMweb for images, FHIR for the rest of the chart |
| Infrastructure | Capex servers and a team to babysit them | SaaS / opex; you still own validation and access control |
This is a change of plumbing and of who can open the study. It is not a new disease, and it is not a PYCAD product line.
Four pieces that have to talk
AI as a co-pilot
The model flags a candidate, drafts a measurement, or bumps a critical study. It does not sign. “Will AI make radiologists obsolete?” is one line: no — most cleared imaging AI is assistive — and the full argument lives on artificial intelligence in radiology. Generic diagnosis / CAD as a specialty is 669. CT-native foundation models and 3D report-review are the Merlin and RADAR notes, not this URL.
Cloud PACS and DICOMweb
On-premise PACS was a filing cabinet with a lock. Cloud-native storage plus DICOMweb is the same archive over HTTP: WADO-RS / STOW-RS / QIDO-RS so a viewer, an AI service, and an EHR can fetch the study without a VPN desktop. Encryption at rest and in transit, role-based access, an audit trail — those are the controls, not a slogan. The handshake itself is PACS and DICOM.
Web DICOM viewer
The viewer is the cockpit. Zero-footprint: pixels stream; the file does not sit on a laptop. MPR and volume rendering for the 3D read. A place to land the AI overlay so the radiologist is not bouncing between portals. A generic viewer that cannot read the mark object is how tools die. PYCAD builds that imaging piece when the study has to live inside a clinic app. It does not ship a cloud PACS.
Connected platforms
Order in the RIS, barcode at the scanner, study in the archive, flag on the worklist, report back to the EHR. DICOMweb moves the images; FHIR moves the rest. Manual export-and-email is the failure mode this layer is supposed to kill. Worklist design is radiology workflow optimization, not a second next-gen article.
A roadmap, not a flip of a switch
You do not “install next-gen radiology.” You change the archive, the viewer, and usually one AI job, in that order, against a named bottleneck.
- Discovery. What PACS you have, what the network can carry, where the read actually happens, which hop burns the most minutes. A goal you can measure (report turnaround, not “be modern”).
- One pilot. One department or one model (lung-nodule flag, hemorrhage triage). A pilot is how you learn the integration cost before you bet the archive.
- API integration. DICOMweb and FHIR as the bridges to the EHR / RIS you already run. A sidecar portal is a second login, not an integration.
- Training, then expand. The tool is unused if the reader does not trust the overlay. Train on the real worklist. Then copy the pattern, not the slide deck.
HIPAA does not forbid the cloud. It forbids leaking PHI. A zero-footprint viewer that never downloads the study is often a smaller breach surface than a fat client with a cache on a shared PC. AI bias is a dataset problem: validate on the ages, scanners, and demographics you actually scan, and keep validating after go-live. How to run an AI project in a hospital is a different article — already pointed at from here — not a second stack explainer.
Hardware that changes the pixels
Software does not invent photons. Two machines are what people mean when they say the hardware caught up:
- Photon-counting CT (PCCT). A conventional CT integrates energy. PCCT counts photons and bins them by energy. You get more contrast at a lower dose and thinner slices that actually hold detail. The volumes are large. How you render them is volume rendering of CT, not a second hardware brochure.
- Helium-free MRI. Classic magnets drink liquid helium. Newer designs cut or drop that dependency, which changes siting cost and who can run an MRI, not the pulse-sequence physics.
Both produce datasets that a 2010 workstation was not built to open. That is why the viewer and the archive are part of the same stack as the gantry.
Interventional and digital radiography
Two other pieces sit on the same stack and are not a reason to keep a second URL.
Interventional radiology is image-guided treatment: fluoroscopy, CT, or ultrasound as a live map, instruments through a vessel or a small puncture instead of an open field. The diagnostic archive and the live image have to be the same language (DICOM), or the plan and the procedure drift apart.
Digital radiography is the film-to-pixels hop. A detector writes a DICOM file in seconds; the tech can reject a bad exposure before the patient leaves. Contrast and zoom are post-processing, not a second trip through the processor. Those files are what the cloud archive, the web viewer, and the AI flag actually consume. A market CAGR is not a reason to buy a detector.
FAQ
Is this only for big hospital systems?
No. Cloud / SaaS is how a small clinic gets a viewer and an archive without a capital server room. You still own access control, a BAA, and validation of any model you turn on. “SaaS” is not a waiver.
What happens to the studies we already have?
A modern archive speaks DICOMweb (images) and FHIR (the rest of the chart) so a migration is a mapping, not a pile of CDs. Old files become usable by a new viewer or a new model only if the tags and the pixels survive the hop. Plan the mapping; do not assume “lift and shift.”
Will AI make radiologists obsolete?
No. Assistive, not autonomous — the full argument is artificial intelligence in radiology.
Where does PYCAD sit?
The imaging piece inside the stack: a web DICOM viewer or a model when the study has to live in a clinic app. Not a next-gen-radiology platform, not a cloud PACS, not a photon-counting CT.