A referring physician with no portal login asks for a printed film. A patient wants a copy to carry to a second opinion. A PACS that has sailed through every other conformance check suddenly cannot get a single sheet out of the printer on the loading dock. DICOM print is not a legacy footnote.
It is Annex H of PS3.4, the Print Management Service Class, and it is current in the 2026 edition of the standard. Print SCU and Print SCP roles, a Film Session, Film Box, and Image Box hierarchy, and a Presentation LUT that decides what the film actually records are all still part of it. It is also the part of a conformance statement most integrators never read, because nothing forces the question until a customer asks for hardcopy and the association negotiation fails.
Print Management: Two Roles Negotiating an Association
Print Management is a service class built the same way any other DICOM service class is: two peer applications negotiate an Association, and one side requests operations the other performs. The standard defines its scope plainly: “The Print Management Service Class defines an application-level class-of-service that facilitates the printing of images and image related data on a hard copy medium.” Its own vocabulary is broader than the word suggests. As the standard puts it, “the word film” stands in as “a general name for different types of hard copy media (e.g., photographic film, paper)”, so a paper printer and a laser film camera are the same kind of target from DICOM’s point of view.
The two roles carry the same shape as C-STORE or Query/Retrieve. A Print Management SCU controls the print job. A Print Management SCP corresponds to a hard copy printer, or to a print server sitting in front of one, and the two negotiate which SOP Classes they support during Association establishment. A workstation, viewer, or PACS is normally the SCU.
Where one host has to reach more than one printer, the standard lays out two configurations. One SCP can front several printers, with no per-printer control from the SCU. Or the host can open one Association per printer, with full control over each printer’s own parameters.
The Film Session, Film Box, and Image Box Hierarchy
Everything in a print job hangs off one hierarchy, and each level has its own SOP Class.
- Basic Film Session. The root of the job: one or more films, all belonging to one host and destined for one printer, plus session-wide parameters like number of copies and film destination. The standard is direct about what deleting one takes down with it: the hierarchy “consists of one Basic Film Session SOP Instance, one or more Basic Film Box SOP Instances, one or more Image Box SOP Instances, zero or more Basic Annotation Box SOP Instances, zero or more Presentation LUT SOP Instances, and zero or more Basic Print Image Overlay Box SOP instances.”
- Basic Film Box. One sheet of film, “an abstraction of the presentation of one film of the film session.” Its own instance has to exist before any Image Box can be created underneath it, and it carries the layout: how many image positions the sheet has and how they sit on it.
- Image Box. The leaf, and the only level that carries pixel data. A Basic Grayscale or Basic Color Image Box instance exists for every image position on the sheet, and the SCP creates them itself the moment the Film Box is created, one per position the requested layout defines.
- Basic Annotation Box and Presentation LUT. Both optional, both referenced rather than embedded. A Film Box or Image Box points at a Presentation LUT instance instead of carrying the density transform itself.
Printing the whole session is one N-ACTION issued against the Film Session, which triggers every film underneath it in one call. Ask for two copies of a four-film session and the standard spells out the exact order the printer has to produce them in: “if two copies of four films has been specified, the printed sequence is 12341234.”
Presentation LUT: What the Screen Showed Versus What the Film Records
A radiologist’s monitor and a film printer never receive the same numbers. Between a stored pixel value and whatever the display shows, DICOM applies a Modality LUT and then the windowing operation that picks which slice of the dynamic range renders as gray. Print Management adds two more stages on top of that: polarity, then the Presentation LUT.
The Presentation LUT converts the polarity pixel values into Presentation Values, or P-Values, a common currency meant to be independent of the specific display device. That is what lets hardcopy media, with entirely different physics, optical density instead of screen luminance, land on the same display standard a calibrated monitor is held to.
The standard is precise about what that transform is for: “P-Values are approximately related to human perceptual response. They are intended to facilitate consistent display with common input for both hardcopy and softcopy display devices and be independent of the specific class or characteristics of the display device.” The printer takes it from there: “Hardcopy devices convert P-Values into optical density for printing”, a conversion the printer’s own conformance statement, not the sending system, is responsible for getting right.
This is where print repeats a failure mode covered elsewhere on this site. Converting a study out of DICOM entirely bakes in whichever window happened to be active at export time, because a JPEG has nowhere else to put it. Film does the same thing for a related but distinct reason: it is, definitionally, a fixed physical mark.
DICOM gives the print path a named, negotiable SOP Class for that transform. An integrator who never checks whether Presentation LUT is supported on both ends has quietly accepted whatever default density mapping the printer ships with instead.
What’s Actually Retired, and What Isn’t
Print Management’s age shows in its own text. Buried in the middle of the grayscale transformation section is a retirement notice the standard writes about itself: “This section previously described Modality LUT and VOI LUT transformations in more detail. Since Referenced Print SOP Classes have been retired, these descriptions no longer apply to the Print Management Service Class. See PS3.4-1998.”
What got retired was the more ambitious version of print: a store-and-pull model. A sending system left a formatted, print-ready object on an archive, and the print system itself retrieved it for printing later, decoupled from the session that originally created it. The current table of contents for Annex H marks the casualties by name:
- Referenced Grayscale Print Management Meta SOP Class
- Referenced Color Print Management Meta SOP Class
- Pull Stored Print Management Meta SOP Class
- Referenced Image Box SOP Class
- VOI LUT Box SOP Class
- Image Overlay Box SOP Class
- Pull Print Request SOP Class
Every one of those is labeled retired in the current edition. One more entry carries the same label without belonging to that cleanup. The Basic Print Image Overlay Box SOP Class was an optional part of the basic path, the class that laid text or graphics over a printed image without burning them into the pixel data. It was retired on its own, after the others.
The standard’s own delete clause, quoted earlier, still names it as part of the Film Session hierarchy.
What survived is the workflow described above:
- Basic Grayscale and Basic Color Print Management Meta SOP Classes
- Basic Film Session, Basic Film Box, and Basic Image Box SOP Classes
- Printer and Print Job SOP Classes
- Presentation LUT SOP Class
An implementation has to support at least one of the two Basic Meta SOP Classes to claim Print Management conformance at all. Everything layered on top of that floor, annotation, Print Job status, Presentation LUT, Printer Configuration Retrieval, is optional.
So the accurate statement is neither that print is legacy nor that print is fully current. It is narrower: the direct, session-based hardcopy path a modality or workstation uses today survived the standard’s own cleanup. The decoupled, store-and-pull version that older literature describes did not.
Why DICOM Print Still Shows Up in 2026
Three reasons keep this service class in active conformance statements instead of quietly fading out.
Legacy hardware has a long service life. A laser film printer or a dry imager bought a decade ago has no reason to be replaced if it still prints, and it speaks the same Print Management SOP Classes it always has. A new PACS or modality that has to share a network with that printer needs an SCU that can still negotiate with it.
Referring physicians and patients still ask for a physical copy. Not every referring practice has portal access to the ordering site’s PACS. And patients have a federal right to a copy of their own health information in the form they request it, medical images included. In practice, that still sometimes means a printed sheet or a film jacket handed across a desk instead of a login.
And in workflows between organizations that have never integrated their systems, a printed image is still the lowest common denominator two disconnected PACS can agree on. A DICOM Association is what produces it, but what arrives at the other end is closer to a fax, and it works because it requires no shared infrastructure at all.
None of that adds up to print being common. It adds up to something less forgiving: rare enough to skip testing, consequential enough that skipping it shows up in front of a customer.
What to Check in a Conformance Statement Before You Promise It Works
The standard is unusually specific about what a Print Management conformance statement has to disclose, more specific than it is for most other service classes. It has to be, because so much of print’s actual behavior sits in vendor-defined ranges rather than fixed values. Before telling a customer that a printer or a PACS supports DICOM print, an OEM or VAR should be able to answer each of these. The answer should come from the two conformance statements in hand, not from a sales conversation:
- Which Meta SOP Class. Basic Grayscale, Basic Color, or both, on each side of the connection. Claiming Print Management support without naming one says nothing about grayscale versus color capability.
- Which optional SOP Classes. Annotation, Presentation LUT, Print Job status, and Printer Configuration Retrieval are all optional. A printer that skips Presentation LUT still accepts the image. It just applies its own default density mapping instead of the one the sending system asked for.
- Printable pixel matrix range, per supported film size. The SCP’s conformance statement has to state the minimum and maximum pixel matrix it can print at each film size, which is what decides whether a full-resolution image demagnifies, crops, or decimates to fit the sheet.
- Image display formats. Every custom layout the printer accepts, how many image positions per sheet and where they sit, has to be documented by name.
- Collated film count. If the SCP supports printing a whole Film Session in one N-ACTION, its conformance statement has to state the maximum number of films it will collate in a single job.
- Color-on-grayscale behavior. What a grayscale printer does with a color image it is asked to print has to be documented, not assumed from the product name.
- Cropping algorithm. If the printer crops an oversized image instead of demagnifying it, the rule for which rows and columns get removed has to be specified.
Two conformance statements that both claim Print Management support can fail every item on that list against each other and both still be telling the truth. Conformance is a claim about following the standard, not a promise that two implementations will work together. Reading both documents first is what keeps that from surfacing at a customer site.
Read Both Documents Before the Demo
That reading has to happen before the demo, not after a customer asks why nothing came out of the printer. EBM mAIn PACS® already publishes its supported DICOM services this way, naming C-STORE, Q/R, MWL, and Storage Commitment specifically rather than leaving them as a general claim of DICOM compatibility. That is the standard of disclosure any conformance statement should meet, Print Management included. Name the Meta SOP Class, name the optional SOP Classes actually implemented, and put a number on the pixel matrix range instead of a marketing claim.
The work here is reading two documents, an SCU’s and an SCP’s, side by side before either one ships to a customer. No new integration path is involved, only the discipline every other service class already gets.
Print Management just rarely gets exercised until the day someone actually needs a film. By then, the pixel matrix range and the collation limit stop being theoretical questions. They are why the print job that worked cleanly in the demo comes out cropped, demagnified, or not at all in production.