What makes MRI different from X-ray or ultrasound
A single MRI exam is not one image, and it is usually not one series either. A routine study can carry T1, T2, FLAIR and diffusion sequences, sometimes several contrast-enhanced phases on top, each its own series with anywhere from dozens to a few hundred slices, all filed under one accession. A PACS that treats an MRI exam like a chest X-ray, one flat study the radiologist pages through image by image, makes for a slow read. The practical bar is a worklist and viewer that group by series and let a radiologist scroll a stack, not click through images one at a time.
Two habits follow from that. First, volume: MRI studies run far larger than plain radiography or a single ultrasound clip, so an archive sized around X-ray-era study weights runs into real numbers fast once MRI volume grows. Second, comparison: MRI is a specialty built on change over time, a lesion, a joint, a spine read against what it looked like months or years earlier, so a viewer that cannot open a current study next to a specific chosen prior, and remember which prior it was, is missing a real part of the MRI read, not a nice-to-have.
One more habit worth naming honestly: many MRI reads lean on multiplanar reconstruction and volumetric tools to reslice a stack into a different plane or build a 3D rendering. That is a dedicated imaging-workstation function, not something a general PACS viewer provides, MiniPACS included. See where MiniPACS honestly does not fit below.
What an MRI center needs from a PACS
Strip away the marketing and an MRI center's PACS requirement comes down to a short, concrete list: take studies in from however many scanners are running, open them fast for whoever is reading, compare against the right prior, get the images and the report to the referring physician, and keep the whole archive somewhere the center actually controls rather than a metered cloud account.
| MRI workflow needs | MiniPACS | |
|---|---|---|
| Multi-scanner intake | One or more MRI units, or MRI alongside CT and ultrasound, feeding one worklist without mixing studies up | Standard DICOM C-STORE from any compliant scanner; sender AE Title and IP logged on every study received |
| Multi-series studies | One exam files as several series, T1/T2/DWI/contrast, each with its own slice count | Worklist and viewer group by series; modality chips filter MR alongside CT and US in one query |
| Reading against priors | Compare the current exam with a specific earlier one, not just whatever is most recent | Compare view opens two studies side by side, panes scroll independently, chosen prior saved in the URL |
| Remote and off-site reading | Open studies without installing viewer software at every reading location | Zero-footprint browser viewer; measured cold-open of about 0.6 seconds on a 10-series, 180-instance study |
| Referrer sharing | Get images and the report to a referring physician without a disc or a drive-over | Expiring, PIN-protected share link with inline image and report viewing, nothing to install on the recipient's end |
| Storage cost shape | MRI studies run far larger than X-ray; a per-study or per-gigabyte bill grows with that | Flat by location, $300 per month, studies live on the center's own server |
Where MiniPACS fits, and where it honestly does not
MiniPACS is a modality-agnostic DICOM PACS, and MRI is simply one more modality it archives and displays correctly rather than a special case bolted on. Studies open in the same zero-footprint browser viewer as every other modality, the Compare view handles the current-versus-prior read that MRI depends on, and the report editor ships with MRI-specific templates, MRI Brain without-and-with contrast, MRI Lumbar Spine, and MRI Knee, among its 13 built-in RadReport-style templates, so a radiologist reading MR is not starting every report from a blank page.
The honest boundary matters here more than in most specialties. MiniPACS does not run a DICOM Modality Worklist service, so it does not push scheduled procedures to the scanner console; that piece stays with a RIS or the console itself. It also does not include MRI quantification, multiplanar reconstruction or volumetric post-processing. An MRI-heavy practice that leans on those tools keeps them as a separate step, with MiniPACS as the archive and viewer on either side of that step. If the requirement is a modern, self-hosted archive and a fast viewer for MRI alongside everything else the center runs, that is the fit. If the requirement is MWL scheduling or quantification built into the PACS itself, say so up front, because a PACS alone will not cover it.
Self-hosted or cloud, and why MRI tips the math
The hosting decision is the same one every modality faces, but MRI pushes it harder than X-ray does. Self-hosting keeps studies on the center's own server, under its own backups and audit trail, at a fixed cost with no per-study cloud fee and no dependence on a vendor to hand the archive back if the relationship ends. A cloud PACS moves that cost and responsibility to the vendor, and usually bills per study or per gigabyte, exactly the two numbers MRI grows fastest. MiniPACS is $300 per location per month, flat, billed yearly, which is $3,600 per location per year; MiniPACS and Vendo together, archive plus the referral and booking portal, are $640 per location per month, or $7,680 per location per year. Neither figure moves with MRI volume. For the full version of that tradeoff, see cloud vs onsite.
What to check before buying an MRI PACS
- Series grouping. Confirm the worklist and viewer group a multi-series MRI study by series rather than flattening it into one long image list.
- Multi-scanner intake. Confirm more than one MRI unit, or MRI alongside CT and ultrasound, can send to the same archive without studies getting mislabeled or lost.
- Compare with a specific prior. Not just "latest study," a named earlier exam, reliably reopened, not just shown once.
- MWL and quantification, named honestly. Ask whether modality worklist scheduling and measurement or post-processing packages are actually in the PACS, or whether they are a separate system you will still need to buy.
- Storage cost shape. Flat by location, or does the bill grow with MRI's larger per-study size. Run the center's real volume against both before deciding.
- Ownership and exit. Who holds the archive and how you get it back. See comparing PACS vendors for the contract terms that matter.
For how a PACS works day to day, see what is PACS. For the general-radiology version of this page, see PACS for radiology. For the open-source route specifically, see the Orthanc alternative comparison, and for reading MRI across sites see teleradiology. For pricing and a live demo you can click through, see the landing.
FAQ
What is an MRI PACS?
An MRI PACS is the archive and viewer behind an MRI scanner. It receives the DICOM study the scanner produces; one exam is rarely a single image, it is usually several series (T1, T2, diffusion, contrast phases) filed under one accession. The PACS stores that study and serves it back to a viewer whenever a radiologist or referring physician needs to open it. It is the same core machinery as a general PACS, sized for MRI's habit of large, multi-series studies rather than one image or a handful of frames.
How much storage does MRI imaging need?
More than plain radiography, by a wide margin. A single MRI exam typically produces several sequences as separate series, each with dozens to a few hundred slices, so one study routinely runs into hundreds of megabytes where a chest X-ray runs into single digits. MiniPACS is priced flat by location rather than by study or by gigabyte stored, so a center's MRI volume does not change the bill; the studies still have to live somewhere, and self-hosting means that somewhere is the practice's own server, sized to its real volume rather than a vendor's storage tier. At scale, an archive that has handled millions of images in production is the bar to clear, not a demo that only proves itself on a handful of test studies.
Can radiologists read MRI remotely?
Yes. MiniPACS opens studies in a zero-footprint browser viewer, so a radiologist reads the same MRI from a second site or from home without installing viewer software on every machine. Measured locally, the viewer cold-opens a 10-series, 180-instance study in about 0.6 seconds, and DICOMweb transcodes to JPEG 2000 Lossless on the fly for slower connections, measured at 149 KB down to 55 KB on one MR instance and roughly 4.2 MB down to 1.5 MB on a 28-slice series. For a read that depends on comparison, the Compare view opens the current study against a chosen prior in two independently scrolling panes, and the chosen prior stays in the page URL, so reloading, or sending the link to a colleague, reopens the same pairing rather than the most recent study by default.
Can multiple MRI scanners send to the same archive at once?
Yes. MiniPACS receives standard DICOM C-STORE from any compliant modality on one dedicated port and is built to be modality-agnostic rather than tuned to a single scanner. A center running two or three MRI units, or an MRI unit alongside CT and ultrasound, sends everything to the same AE Title, and every incoming study is logged with the sending AE, sending IP and receive time, so an admin can tell exactly which scanner, or which branch site, a given study came from. PACS node cards and one-click C-ECHO checks confirm each device is reachable before a dropped connection becomes a missed study.
Does MiniPACS handle MRI modality worklists or quantification?
No, and it is worth saying plainly rather than glossing over. MiniPACS does not run a DICOM Modality Worklist (MWL) service to push scheduled procedures to the scanner console; that piece still comes from a RIS or the scanner's own console. It also does not include MRI quantification or post-processing packages, volumetrics, perfusion maps, spectroscopy analysis, multiplanar reconstruction; those are dedicated workstation or CVIS-style tools, not a PACS function. What MiniPACS does is the archive and viewer around those tools: receive the study from wherever it was acquired or processed, store it, and display it fast to whoever needs to read it.