A radiologist opens a chest CT, scrolls through three hundred slices, adjusts the window until a nodule separates from the surrounding tissue, measures it in millimeters, and signs a report. Almost none of that is something a basic DICOM viewer can support. A DICOM viewer that renders the pixel data in a .dcm file is close to a commodity. A DICOM viewer a radiologist can read a study on, and stake a signature on, has to clear a specific and checkable list of requirements.
What Opening a Study Actually Requires
Before a viewer renders anything, it has to get the study, and getting the study is a protocol problem, not a display problem. A viewer connected to an archive asks two separate questions: which studies match this patient, this date or this accession number, and then, having picked one, which series should be sent over. Those are two distinct DICOM operations, C-FIND and C-MOVE, together known as Query/Retrieve. A viewer that cannot do both is not really opening from the archive; it is rendering whatever files happen to already be local.
Rendering local files is fine for a one-off case, a CD a patient brought in. It is not sufficient for a department reading hundreds of studies a day from a shared archive. EBM mAIn PACS® implements Query/Retrieve as one of its native DICOM services, alongside C-STORE, MWL, and Storage Commitment, so a partner’s own viewer can pull directly from the archive without custom middleware in between.
This matters for the build-versus-license decision because Query/Retrieve is invisible right up until it is not there. A demo viewer loaded with a handful of sample files looks identical to a production viewer, until someone tries to pull a five-year-old prior for comparison and the retrieve step does not exist.
Windowing and Window Level
A DICOM image is not an 8-bit photograph. CT data in particular is typically captured at 12 to 16 bits per pixel, thousands of distinct values, because Hounsfield units need that range to represent bone, soft tissue, and air in the same slice. A standard monitor shows roughly 256 shades of gray. Something has to map that wide range down to what the screen can display, and that something is windowing.
Window width sets how much of the value range gets compressed into visible gray at all. Window level sets where the center of that range sits. A radiologist reading a chest CT moves between two windows on the same image, often dozens of times per study. One is a lung window, wide and centered low, so air-filled tissue shows detail; the other is a mediastinal window, narrower and centered higher, so soft tissue and vessels separate from each other.
A viewer that hardcodes one window, or flattens the data to 8-bit before it ever reaches the display layer, has already thrown away the information a radiologist needs. This is one of the fastest ways to tell a diagnostic-grade viewer from a basic one: ask whether window width and level are live, per-image controls or a fixed default.
Display Calibration: Where GSDF Lives
Correct windowing only matters if the physical display renders each gray step consistently. Two monitors can receive identical pixel data and show visibly different images because their underlying luminance curves differ, and the human eye does not perceive luminance linearly to begin with. This is the problem DICOM Part 14, the Grayscale Standard Display Function, exists to solve. The standard states that it “specifies a standardized Display Function for display of grayscale images”, and it gives methods for measuring a display system against that function.
In practice, that means a diagnostic display gets measured with a luminance meter and calibrated to the standardized curve. A given pixel value then produces a perceptually consistent step in brightness regardless of which monitor, which vendor, or which room it is displayed in. A viewer that skips this step can still render an image that looks fine to an untrained eye while systematically under- or over-representing the faint density differences a radiologist is trained to catch.
On EBM mAIn PACS®, calibration is a listed capability rather than a manual, easy-to-skip configuration step. EBM lists DICOM curve calibration for diagnostic accuracy in the reading room, and DICOM curve calibration for iPad with luminance meter support on the UDE workstation.
Measurement and Annotation Tools
A viewer that lets a radiologist draw a line and see a number is not the same as a viewer that lets them measure correctly. A distance measurement is only accurate if it is calculated from the pixel spacing recorded in the study’s own DICOM metadata, not eyeballed against an assumed scale. An area or angle measurement compounds that same dependency.
CT adds a second dependency on the header. Sampling a Hounsfield unit value at a point or over a region requires reading the raw pixel value and applying the correct rescale slope and intercept. Reporting whatever the display happens to show at that brightness setting is a different number entirely.
Annotation carries a lighter but still real bar. Markups need to persist with the study, travel with it if it is shared or referred out, and stay anchored to the correct image and plane rather than drifting if the series is reformatted. EBM lists advanced tools and measurements among the UDE workstation’s capabilities, and pairs diagnostic viewing with structured reporting from desktop to iPad.
A measurement tool that does not read the study’s own pixel spacing is not a measurement tool. It is a ruler laid on a picture.
Multi-Planar Reconstruction and Series Handling
Many CT and MRI studies are not acquired as a single flat image. They are acquired as a stack of thin, closely spaced slices, meant to be reconstructed into whichever plane the reader actually needs: axial, coronal, sagittal, or an oblique cut through none of those. A viewer that only plays back the original acquisition plane as a flat sequence cannot do this. Multi-planar reconstruction (MPR) rebuilds any of those planes from the volume on demand, and it is what separates a viewer for cross-sectional imaging from one for single-frame modalities.
Series handling sits alongside MPR. A single study can carry multiple series: different sequences on an MRI, pre- and post-contrast phases on a CT. A reader needs them arranged the way they actually work, side by side, in a consistent layout, with a prior study available for comparison without a separate search. That arrangement logic is what a hanging protocol does, and it is a feature line item rather than something a viewer gets right by default.
EBM mAIn PACS® supports MPR, and lists hanging protocol handling as part of its reading-room solution alongside worklist and measurement tools.
Zero-Footprint Versus Installed DICOM Viewers
The deployment model is a separate question from the rendering engine. A zero-footprint viewer runs entirely in a browser: nothing installed, nothing for IT to provision, a link opens the study on whatever device is in front of the reader. That is the right model for a referring physician checking a result, or for a remote expert pulled in for a second opinion.
The browser is a harder model for the primary reading workflow. Large volumetric series and MPR reconstruction put real load on whatever is doing the rendering, and a browser sandbox is not always where that load belongs.
The retrieval question does not go away in the browser either. A browser client cannot open the raw DICOM network connections that C-FIND and C-MOVE run over. It reaches the archive through the DICOMweb services instead, QIDO-RS for the search and WADO-RS for the retrieve, or through a server-side component that translates. Ask which, because the answer decides what has to sit between the browser and the archive.
An installed viewer (native to a desktop, a dedicated workstation, or a tablet) can use local hardware more directly and keep working when the network does not. EBM mAIn PACS® covers both ends of that split instead of forcing one. EPS Pi, the edge appliance, lists web-based access, which is the zero-footprint end. UDE is the installed end: EBM’s mobile diagnostic workstation, which turns an iPad into a full reading tool with offline-capable workflows.
The Mac mini option sits underneath those two rather than alongside them. EBM describes it as a server for clinics that need more horsepower or a centralized reading room, and lists it as ready for both the web viewer and UDE. Which surface a product team needs depends on where their end users actually read: a bedside, a mobile clinic with unreliable internet, or a fixed reading room.
Where Regulatory Clearance Enters
Not every DICOM viewer needs regulatory clearance. A viewer used by a referring physician to review a result, or by a patient to look at their own images, is not making a primary diagnostic call. It generally does not carry the same requirement. A viewer intended for primary diagnostic interpretation is a different category.
The FDA classifies software that provides review and digital processing of medical images for interpretation by a trained practitioner under 21 CFR 892.2050, as Class II. The same regulation covers the diagnostic-radiology displays those images are read on. The agency’s dedicated premarket guidance for those displays says it applies to “display devices intended for diagnostic radiology as identified by their classification regulation (21 CFR 892.2050) and product codes.” Viewer software and the monitor in front of the reader can land in the same regulation, and clearance in either case attaches to a specific device and intended use.
UDE is EBM’s mobile diagnostic workstation, which turns an iPad into a full reading tool. It carries FDA 510(k) clearance, as a Class II medical device, for diagnostic viewing as that specific device, and its cleared indications exclude mammography. That clearance does not extend to EBM mAIn PACS® as a platform. A vendor who lets that distinction blur in a sales conversation is a vendor worth asking more questions of, not fewer.
What This Means for Your Evaluation
None of this is a reason to build every one of these capabilities from a blank page, and it is not a reason to accept “we support DICOM” as a complete answer either. The useful question for a product or engineering leader is the itemized one:
- Does the viewer implement Query/Retrieve against a real archive, and over which services?
- Are window width and level live, per-image controls?
- Is the display calibrated to the Grayscale Standard Display Function, or left to whatever monitor happens to be plugged in?
- Are measurements calculated from the study’s own pixel spacing?
- Does it reconstruct multiple planes from a volumetric series?
- Which component, if any, carries a regulatory clearance, and for what intended use?
Answering those six questions is also what ties a viewer back to the PACS architecture underneath it, because Query/Retrieve and prior comparison resolve against the archive rather than the display. A vendor who answers all six with the single word “compliant” has answered none of them. The price of accepting that word does not come due during evaluation. It comes due later: a five-year-old prior that will not retrieve, a study read on a monitor nobody calibrated, a clearance claim repeated as if it covered a platform rather than one component.