What DICOM Means in Plain English

A Biomed Introduction to Medical Imaging Communication

A practical introduction to DICOM, PACS, modalities, worklists, AE Titles, image storage, and why an imaging system can work locally but fail the clinical workflow.

Back to Biomed Basics

What This Page Explains

DICOM is one of those terms biomeds hear all the time without always getting a clear explanation.

A nurse may say:

The ultrasound will not send images.

A radiology tech may say:

The worklist is blank.

A vendor may ask:

What is the AE Title, IP address, and port?

IT may say:

The modality can ping PACS.

And the biomed standing in the middle may be thinking:

Cool. What exactly does any of that prove?

This page explains DICOM, PACS, modalities, worklists, image storage, AE Titles, ports, Storage Commitment, and the kinds of imaging communication problems biomeds may run into.

The goal is not to turn every biomed into a PACS administrator.

The goal is to explain enough that when an imaging device will not send, receive, find, or store a study, you understand the basic path and can ask better questions.

Jump to a Section

What DICOM Stands For

DICOM stands for:

Digital Imaging and Communications in Medicine.

In plain English:

DICOM is the standard that lets medical imaging systems create, identify, send, receive, store, retrieve, and display medical imaging information.

DICOM is not one manufacturer’s system. It is not the same thing as PACS. It is not just a file extension.

It is the shared way medical imaging devices and systems communicate with each other.

The Simple Version

An imaging device takes a study.

That study is more than a picture.

It needs to be connected to the correct patient, the correct exam, the correct date and time, the correct study information, and the correct destination.

DICOM helps make that possible.

A basic imaging workflow may look like this:

Patient/exam is ordered
→ Imaging device receives the scheduled exam information
→ Technologist selects the correct patient and exam
→ Imaging device acquires images
→ Imaging device sends images through DICOM
→ PACS stores and displays the study
→ Radiologist or clinician reviews the images
→ Report or image access becomes available through the clinical workflow

In plain English:

DICOM is how the imaging device and imaging systems understand what the images are, who they belong to, and where they need to go.

Why DICOM Matters to Biomeds

A biomed may not own the PACS server. A biomed may not build the radiology workflow. A biomed may not be responsible for every interface or imaging application.

But biomeds absolutely run into DICOM problems.

The important biomed lesson is:

An imaging device can work perfectly as a piece of equipment and still fail its clinical workflow because the images are not getting where they need to go.

An ultrasound system that scans beautifully but cannot send the study is still a problem. A C-arm that produces images but cannot archive them is still a problem.

The device and the data path both matter.

A Simple History of DICOM

Before common imaging standards, medical images could be difficult to move between equipment and systems from different manufacturers.

In the early 1980s, CT and MRI images were often difficult for anyone other than the equipment manufacturer to decode or print.

In 1983, the American College of Radiology and the National Electrical Manufacturers Association formed a committee to improve medical imaging communication.

The first ACR-NEMA standard was released in 1985.

By 1993, the standard had evolved to work across local area networks using TCP/IP, and the name became DICOM: Digital Imaging and Communications in Medicine.

DICOM later expanded beyond basic image transfer to include worklists, structured reports, dose information, web services, and many other parts of modern imaging workflow.

In plain English:

DICOM exists because hospitals needed medical imaging equipment from different manufacturers to stop acting like isolated islands.

DICOM Is More Than an Image File

When people first hear DICOM, they may think:

It is the file format for medical images.

That is partly true. But it is not the whole story.

A DICOM object may contain the image itself and information connected to that image.

That matters because a medical image without the correct patient and exam information can become a serious problem.

A chest X-ray image by itself is not enough. The system needs to know:

What a Modality Is

In imaging language, a modality is the equipment that acquires the medical images.

In plain English:

The modality is the imaging machine taking the pictures.

If someone says the modality cannot send, they mean the imaging equipment cannot successfully send the study or image data to its expected destination.

For biomeds, that usually means figuring out whether the failure is equipment-related, network-related, configuration-related, PACS-related, worklist-related, patient/study-related, or vendor application-related.

What PACS Is

PACS stands for:

Picture Archiving and Communication System.

In plain English:

PACS is the system used to receive, store, organize, retrieve, and display medical imaging studies.

You can think of PACS as the imaging archive and image-management system.

A modality creates images. PACS is commonly where those images are sent so they can be stored and viewed later.

A basic example:

Ultrasound system acquires images
→ Ultrasound sends DICOM study
→ PACS receives and stores images
→ Radiologist or clinician views study
→ Report or image link is available through the clinical system

That is why PACS is such a big deal.

Without PACS or another appropriate archive workflow, imaging equipment may be taking images that cannot be reliably stored, retrieved, or used by the people who need them.

What RIS Is

RIS stands for:

Radiology Information System.

In plain English:

RIS helps manage radiology workflow, including scheduling, exam information, procedure tracking, and reporting-related workflow.

Depending on the hospital, RIS functions may be separate, partly built into another system, or closely connected with the EMR and PACS.

A simple way to think about the roles is:

EMR / Hospital system: Patient chart, orders, patient care information
RIS: Radiology scheduling and imaging workflow information
Modality: The imaging device that acquires the images
PACS: Stores and displays the images
DICOM: The standard that helps imaging systems exchange imaging information

The exact setup varies by hospital. But those basic roles help explain why an imaging problem may involve more than just the device.

How an Imaging Study Usually Moves

A typical scheduled imaging study may move through several systems.

A simplified workflow may look like this:

Provider orders the exam
→ Patient and order information reaches the imaging workflow
→ Imaging device pulls the scheduled exam from worklist
→ Technologist confirms the patient and exam
→ Modality acquires images
→ Modality sends images to PACS
→ PACS stores and makes images available for review
→ Radiologist reviews images and creates a report
→ Report becomes available through the clinical record

Not every department follows this exact workflow. Portable imaging, surgery, cardiology, emergency situations, and point-of-care imaging may use different processes.

But the key concept is the same:

The image is part of a workflow, not just a file being copied from one place to another.

What Modality Worklist Means

Modality Worklist is one of the most useful DICOM concepts to understand.

In plain English:

Modality Worklist is the scheduled exam list that an imaging device pulls so the technologist can choose the correct patient and procedure instead of manually typing everything in.

A patient is scheduled for an ultrasound. The ultrasound system pulls a worklist. The technologist sees the patient name, medical record number, exam type, accession number, and related study information. They select the correct exam. The ultrasound uses that information when building the study and sending it to PACS.

That is much safer than manually typing every detail from scratch.

Why Worklist Matters

A blank worklist may sound like a minor inconvenience. It is not always minor.

If the technologist cannot retrieve the correct patient and exam information, they may need to use a downtime or manual-entry workflow. That creates more room for mistakes.

That is why the question is not only: Can the modality acquire an image?

The question is also:

Can it safely identify, send, and store the correct study for the correct patient?

What DICOM Store Means

DICOM Store is the service used to send images or other DICOM objects to another system, commonly PACS or an imaging workstation.

In plain English:

DICOM Store means sending the study to the archive or destination system.

Example: Ultrasound → PACS

The ultrasound acquires the images. The user selects send. The ultrasound attempts to send the images to the PACS destination configured in the system.

If it works, the images arrive at PACS. If it fails, you may see:

That does not automatically mean the ultrasound itself is broken. It may mean the device cannot communicate with the destination correctly.

What Storage Commitment Means

This one is easy to overlook.

Sending an image is not always the same as knowing it has been safely stored.

Storage Commitment is a DICOM service used to confirm that the receiving system has taken responsibility for storing the images.

In plain English:

DICOM Store says, “I sent the images.”
Storage Commitment says, “The receiving system confirms it has safely stored them.”

Why does that matter? Because a modality may need to know that images are safely archived before local copies are cleared or treated as no longer needed.

What Query/Retrieve Means

Query/Retrieve lets a system search for stored studies and pull them back from an archive such as PACS.

In plain English:

Query means searching for the study.
Retrieve means bringing the study back for viewing or use.

A modality may be able to send images but not retrieve prior exams. Or it may be able to retrieve studies but not send new ones.

Those are different DICOM functions and may fail separately.

What MPPS Means

You may eventually hear the term MPPS, which stands for:

Modality Performed Procedure Step.

In plain English:

MPPS helps the modality report what exam activity was actually performed.

This is not always the first thing a biomed needs to troubleshoot. But it helps explain why imaging workflow has more pieces than just: Device sends picture to PACS.

AE Title Explained

This is one of the big DICOM terms vendors and PACS staff may ask for.

AE Title means Application Entity Title.

In plain English:

The AE Title is the DICOM name of the application or system trying to communicate.

The exact name depends on how the system is configured.

A DICOM destination often needs:

The easiest way to think of it is:

IP address: Which building am I going to?
Port number: Which door am I using?
AE Title: Who am I trying to speak to inside?

A device may be able to reach the network destination but still fail DICOM communication because the AE Title is wrong or not accepted.

IP Address and Port Number in DICOM

DICOM communication still depends on normal networking. The device and destination need to know how to reach each other.

IP address identifies where the destination system lives on the network.

Port number identifies which application door is listening for the communication.

AE Title identifies the DICOM application involved.

Example:

Destination: PACS
AE Title: PACS_ARCHIVE
IP Address: 10.20.30.40
Port: 104

That is only an example. Real settings must come from the hospital imaging/PACS configuration and vendor requirements.

A wrong IP address may send the device to the wrong place. A wrong port may reach the system but not the DICOM service. A wrong AE Title may cause the destination to reject or not recognize the communication.

Why Ping Does Not Prove DICOM Works

This is a huge one.

Someone may say: It pings, so the network is fine.

That information is useful. But it does not prove DICOM is working.

A successful ping may show that the device can reach the destination IP address at a basic network level.

It does not prove:

In plain English:

Ping may prove the building exists. It does not prove the correct department inside the building is open and willing to accept the study.

That is why a device can ping PACS and still fail to send images.

What a DICOM Echo Is

You may also hear about a DICOM Echo or Verification test.

This is more specific than a normal network ping.

In plain English:

A DICOM Echo checks whether two DICOM applications can make basic DICOM contact with each other.

That is better information than a standard ping because it tests communication at the DICOM application level.

But even a successful DICOM Echo still does not prove every workflow works.

So the progression is:

Ping: Can I reach that network address?
DICOM Echo: Can I make basic DICOM contact with that application?
DICOM Store: Can I send the images?
Storage Commitment: Did the receiving system safely accept responsibility for storing them?
Worklist: Can I retrieve the correct scheduled patient/exam information?

That is a very useful troubleshooting mindset.

What a DICOM Conformance Statement Is

This is another term you may hear during device installs or communication problems.

A DICOM Conformance Statement is the manufacturer’s document describing how that system supports DICOM communication.

In plain English:

A DICOM Conformance Statement explains what kinds of DICOM conversations the device knows how to have.

It is not usually light reading. But when two systems are supposed to communicate and do not, the conformance statement may matter.

One device may support a certain service. Another system may expect a different service or configuration. The device may send a type of image object the destination does not handle correctly.

A conformance statement helps the vendor, PACS team, and technical staff understand what the system is designed to support.

Common DICOM Problems Biomeds May See

Common DICOM-related complaints include:

The exact wording depends on the manufacturer and software.

The biomed goal is not to memorize every possible DICOM error.

The goal is to understand which part of the workflow appears to be failing.

When the Imaging Device Works but the Workflow Does Not

This is the most important troubleshooting distinction.

A device may work locally and still fail the imaging workflow.

That means:

Imaging function and imaging communication are related, but they are not the same thing.

Before deciding the equipment is “good” or “bad,” separate the questions:

That gives you a much clearer picture.

Patient Safety and Wrong-Patient Imaging Problems

A DICOM problem is not always just: The images did not send.

Sometimes the more serious issue is: The images are associated with the wrong patient or wrong study.

That is a major problem.

Do not casually rename, resend, delete, or manipulate studies when patient identity is involved.

Follow the facility’s radiology, PACS, correction, and patient safety workflow.

The goal is not merely to make images appear.

The goal is to make sure the correct images are attached to the correct patient and correct study.

What Biomeds Should Check Before Escalating

Before escalating a DICOM complaint, start by defining the problem.

Ask:

You may not fix the DICOM issue yourself. But this information makes escalation far more useful.

What PACS, IT, or the Vendor May Need From Biomed

If you escalate a DICOM issue, give useful information.

They may need:

A useful escalation note sounds like:

Reported ultrasound unable to send studies to PACS. Ultrasound acquires and stores images locally. Modality Worklist loads normally. DICOM send fails to configured PACS destination with association error. Device location, IP address, AE Title, destination AE Title, port, and error screenshot provided to PACS support/vendor.

That tells people where to start.

Documentation Tip

DICOM-related work orders should explain the exact failure point.

Weak note:

Ultrasound not sending. Called IT.

Better:

Reported ultrasound unable to send completed studies to PACS. Device acquired and saved images locally. Verified network cable connected and configured destination present. DICOM send failed with association error for all test studies. Escalated to PACS/vendor support with device location, IP address, AE Title, destination configuration, and displayed error.

Another example:

Reported portable X-ray worklist blank. Device powered on and acquired images locally. Network connection present. Modality Worklist query returned no scheduled exams. Escalated to PACS/radiology IT with device identification, location, AE Title, and observed behavior.

That is better than: PACS issue.

For a deeper explanation of documenting complaints, findings, and resolutions clearly, see the Biomed Basics page on the CCR method.

What DICOM Testing Does and Does Not Prove

A successful test only proves what that test actually checked.

A network ping may show basic network reachability.

A DICOM Echo may show basic DICOM application communication.

A successful worklist query may show the modality can retrieve scheduled exam information.

A successful DICOM Store may show that images transferred to the destination.

A successful Storage Commitment response may show that the receiving system accepted responsibility for safely storing the images.

None of those, by themselves, prove every part of the imaging workflow is correct.

That is why troubleshooting should focus on where the workflow succeeds and where it stops.

Helpful References

These resources provide deeper technical detail on DICOM and imaging workflow:

Final Thoughts

DICOM sounds complicated because it is part of a bigger imaging world most biomeds are not taught in a simple way.

But the basic idea is not impossible.

A modality creates medical images.

DICOM gives those images structure, patient and study information, and a way to move between imaging systems.

PACS receives, stores, retrieves, and displays those images.

Worklist helps get the correct patient and exam information onto the modality.

AE Title, IP address, and port number help systems find and talk to each other.

And when a study will not send, the device may not be the only thing involved.

A good biomed does not need to become the PACS administrator.

But a good biomed should understand enough to ask:

Is the device acquiring images?
Is the worklist working?
Is the destination correct?
Can the systems make DICOM contact?
Did the images actually store?
Are they attached to the correct patient and study?
Where does the workflow stop?

Because in medical imaging, getting the picture is only part of the job.

Getting the right picture to the right place for the right patient is what matters.

— Jake

Important Note

This page is an educational overview for biomedical equipment technicians, clinical engineers, students, and healthcare technology staff. Always follow your facility policy, imaging/PACS procedures, patient identity correction workflow, manufacturer service documentation, IT/security requirements, and the procedures required by your organization.

Related Biomed Basics

Back to Biomed Basics