A cath lab or echo service produces three things in one morning: cine runs of a beating heart, waveforms carrying no pixel data at all, and measurement reports keyed to specific cardiac anatomy. A general radiology PACS is built around a fourth thing, the still slice. Each of those three asks it for something it was not built to do.
That is what makes cardiology a technical boundary rather than a relabeled product line. Looping a multiframe object at its acquired rate and routing an object with no pixels are both additions to a general PACS, and DICOM is specific about what each one requires.
What Separates a Cardiology PACS: Its Own Domain and Object Types
The distinction is not a marketing claim. IHE, the standards body that coordinates how DICOM and HL7 get used in real clinical workflows, runs a dedicated Cardiology domain, sponsored by the American College of Cardiology. “IHE Cardiology was formed in 2003 to address issues specific to clinical workflow, information sharing and improved patient care in the clinical domain of cardiology.” Two of its named profiles describe exactly the workflows a general radiology PACS was not built around: Cardiac Cath Workflow and Echocardiography Workflow, each one integrating “ordering, scheduling, imaging acquisition, storage and viewing” for its own procedure type.
DICOM backs that separation with its own object types. Cardiac studies routinely produce multiframe cine images, waveform data such as ECG and hemodynamic pressure tracings, and structured reports built from cardiac-specific measurement sets. None of those three are exotic edge cases in radiology. All three are standard output from an echo lab or a cath lab on an ordinary day.
For a product team, that means the question is never whether a viewer can open a DICOM file, since a generic viewer already does that. The real question is narrower: can it loop a multiframe object at the rate it was recorded, and route a waveform object that has no pixels at all? Can it produce a report shaped around the specific anatomy a cardiologist measures, rather than a generic field? Those are additions to a general PACS, not a relabeling of it.
The Object Is a Loop, Not a Slice
A chest X-ray or an MRI slice is a still image. A cardiac study is frequently a loop: the heart is a moving organ, and a still frame of it in motion tells a reader far less than a beating sequence does. The DICOM X-Ray Angiographic Image IOD, the object type used for cardiac catheterization imaging, provides for exactly that: it “can be used to encode a Single-frame Image, or a Cine Run encoded in a single Multi-frame Image” and it covers “images of the heart and all blood vessels.”
Echocardiography works the same way: a cardiac ultrasound exam is built from cine loops far more often than single frames, because valve motion and wall contraction are the finding. A viewer built to open and window one slice at a time has to be extended to loop dozens or hundreds of frames as a continuous sequence. It then has to let a reader step through that sequence, freeze on a specific frame, and measure against it. That is a different interaction model, not a cosmetic one.
Frame Rate and Temporal Resolution
A loop is only useful if it plays back at the rate it was acquired, and DICOM’s Cine Module carries the attributes that make that possible. Cine Rate, tag (0018,0040), is defined as the “Number of Frames per second.” Frame Time, tag (0018,1063), is the “nominal time (in milliseconds) between individual Frames of a Multi-frame Image.” A Recommended Display Frame Rate attribute, tag (0008,2144), carries the “Recommended rate at which the Frames of a Multi-frame Image should be displayed in Frames/second.”
For irregular acquisitions, a Frame Time Vector carries “the real time increments (in msec) between Frames” instead of one fixed value, and a Preferred Playback Sequencing flag tells the viewer whether to loop the sequence or sweep it back and forth. A general radiology viewer that can window and pan a still image has no reason to implement any of this. A cardiac viewer cannot skip it: temporal resolution is part of what a cardiologist is reading.
What a Cine Loop Does to Storage and Bandwidth
A multiframe object with a recommended display rate of thirty frames a second is, by construction, dozens of individual frames bundled into one instance. That is a different sizing problem than a cross-sectional study built from a fixed slice count. As sizing medical imaging storage for real study volume already establishes, a cine loop or procedure recording “lands as a single multi-frame object”. Its size scales with frame count and duration, not with a slice tally.
A cath lab or echo service running mostly cine acquisitions is not a marginal addition to a storage and network plan built around still radiology studies. It is a different throughput profile, and it deserves its own line item rather than an assumption that it fits inside existing headroom.
ECG and Hemodynamic Waveforms Travel With the Images
A cath procedure does not produce images alone. DICOM defines a separate family of Waveform IODs, and two of them carry exactly the electrical and pressure signals a cardiac procedure generates alongside its pictures. The 12-Lead ECG IOD is “the specification of digitized electrical signals from the patient cardiac conduction system collected on the body surface,” acquired by an ECG modality or by an ECG function built into an imaging modality.
Catheterization adds a second waveform type entirely: the Hemodynamic Waveform IOD, “the specification of digitized pressure, electrical, and other signals from the patient circulatory system, which has been acquired by a hemodynamic modality.” A PACS built to move pixels has no equivalent object to route, store, or display either kind of signal. A cardiology PACS has to carry two data families side by side, waveform and image, tied to the same procedure.
DICOM even distinguishes the acquisition context by setting: for “ECG acquired in the cardiac catheterization lab,” the standard calls for a different context template, TID 3403, rather than the TID 3401 template used for “routine resting or stress ECG”. Neither waveform type has pixel data at all, so a viewer that renders images has nothing to fall back on when one arrives. Displaying a waveform object correctly means plotting a signal against time on its own axis, not opening it as if it were a picture. A platform that only knows how to route and render DICOM images will drop these objects, store them unopened, or reject them outright.
Structured Reporting Built Around Cardiac Measurement
DICOM structured reporting already encodes findings as a coded content tree instead of free text, and cardiology builds two dedicated report templates on top of that same model. TID 5200, the Echocardiography Procedure Report, “forms the top of a Content Tree that allows an ultrasound device to describe the results of an adult echocardiography imaging procedure.” Underneath it sit separate, structure-specific measurement sets: one code set for the left ventricle, another for the aortic valve, another for the vena cava. Each pulls from its own defined value set, rather than one generic measurement field.
One of those coded values shows what “structure-specific” means in practice. Left Ventricular Ejection Fraction is not a free-text field a reader types into. It is its own coded concept, “Left Ventricular Ejection Fraction by US”, listed among DICOM’s left ventricle volume measurements, the same measurement set the LV section of TID 5200 draws from. A reporting layer that only knows how to attach a numeric value to a generic label has to be extended before it can produce that as a coded, queryable result rather than a sentence.
Cardiac catheterization has its own template family, headed by TID 3800. “The Cardiac Catheterization Report provides the overall clinical results of the catheterization procedure and interventions”, built from included sub-templates covering patient history, the procedure itself, findings, and outcomes. When a report includes its discharge summary section, the template covers the full set of information required for submission to ACC NCDR version 2.0, the national cardiovascular data registry catheterization labs report into. A generic radiology SR template has no equivalent destination waiting on the other end of it.
What This Means for a Product or Engineering Team
A cardiology PACS is still built on the same foundation as a general radiology one. The underlying platform still has to be built and still has to work: archive, DICOM services layer, routing, reporting integration, access control. What changes is the surface it has to expose above that foundation.
Before assuming an existing viewer, archive, or reporting pipeline covers cardiology, a product team should get direct answers to a short list of questions:
- Can the viewer loop a multiframe cine object at its recommended display rate, rather than just paging through frames one at a time?
- Does the archive and network plan account for cine-heavy studies, instead of assuming radiology-scale files?
- Do waveform objects have a defined storage and display path alongside the images they accompany?
- Can the reporting layer produce the structured, per-anatomy measurement sets a cardiology read expects, rather than a single free-text field?
A platform that answers no to any of those is not necessarily a bad radiology PACS. It is simply not yet a cardiology PACS, and the standard is specific enough that the gap will not close by accident.
Once a partner signs a cardiology customer, all of it becomes obligatory. A cath lab or echo service will produce cine objects, waveform objects, and structure-specific measurements whether or not the platform underneath was built to expect them. The DICOM sections above are the actual scope of the work, not a rough estimate of it. That is exactly why they are worth reading before a contract is signed, rather than after the first dropped waveform object.
They are also the questions to put to any platform a partner is evaluating, EBM Fabric™ among them.