A Modality Worklist (MWL) is a DICOM Service Class that enables an imaging modality, acting as a Service Class User (SCU) , to query a central information system, the Service Class Provider (SCP) , for a list of scheduled procedures. The SCP, typically the Radiology Information System (RIS) or a dedicated broker, responds with a dataset containing patient name, ID, accession number, and requested procedure codes, which the modality uses to pre-populate its user interface.
Glossary
Modality Worklist

What is Modality Worklist?
A DICOM service that automates the flow of patient demographics and scheduled procedure information from the Radiology Information System (RIS) to the imaging modality, eliminating manual data entry errors at the scanner console.
This query is executed using the DIMSE C-FIND command, with the modality sending a request containing specific matching key attributes and the SCP returning matching records at the Study and Scheduled Procedure Step query/retrieve levels. By enforcing a strict Association Negotiation for the Modality Worklist Information Model – FIND SOP Class, the standard ensures that technologists no longer manually type patient demographics, thereby preventing dangerous misidentification errors and streamlining high-throughput radiology workflows.
Key Features of Modality Worklist
The Modality Worklist (MWL) service eliminates manual data entry errors at the scanner console by enabling modalities to query the Radiology Information System (RIS) for patient demographics and scheduled procedure details.
Automated Patient Registration
Eliminates the primary source of medical imaging errors: manual data entry. The modality queries the RIS using a C-FIND request at the Study level, retrieving the exact patient name, ID, accession number, and procedure codes. This ensures the DICOM header is populated with the correct Patient ID (0010,0020) and Accession Number (0008,0050) without a technologist typing a single character.
Scheduled Protocol Code (SPS) Retrieval
The worklist returns the Scheduled Protocol Code Sequence (0040,0008) and Scheduled Procedure Step Description (0040,0007), which can be used to automatically select the correct scanning protocol on the modality. This prevents protocol mismatches—such as scanning a routine head instead of a stroke protocol—by mapping the coded procedure to the scanner's internal protocol list.
Patient Weight and Contrast Management
Critical safety attributes like Patient's Weight (0010,1030) and Contrast Allergies (0010,2110) are transmitted via the worklist. This data allows the modality to automatically calculate contrast dose limits and flag allergy warnings before injection, integrating with IHE SWF (Scheduled Workflow) profiles to enforce safety checks at the point of care.
Broad Query with Matching Key Attributes
Modalities can perform a broad query using partial demographic data as matching keys. A C-FIND request with just a partial patient name and scheduled date returns all matching procedures. The Specific Character Set (0008,0005) attribute ensures that names with international characters are correctly encoded and displayed, supporting global healthcare environments.
MPPS Completion Feedback Loop
The worklist integrates with Modality Performed Procedure Step (MPPS) to close the scheduling loop. Once a procedure is completed, the modality sends an N-SET with a status of COMPLETED, updating the RIS. This prevents the same procedure from appearing on future worklist queries, ensuring a clean, real-time view of pending exams for every connected device.
Unified Worklist for Multi-Modality Environments
A single MWL SCP can serve CT, MR, US, and X-ray modalities simultaneously, each filtering for its own Modality (0008,0060) attribute. This centralized approach ensures that a patient registered once in the RIS appears on the correct scanner's worklist without duplicate orders, supporting large hospital networks with dozens of imaging devices.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Frequently Asked Questions
A technical FAQ addressing the core mechanisms, integration patterns, and operational benefits of the DICOM Modality Worklist (MWL) service for eliminating manual data entry at imaging modalities.
A DICOM Modality Worklist (MWL) is a service that enables an imaging modality, such as a CT or MRI scanner, to query a central information system—typically the Radiology Information System (RIS) —and automatically retrieve patient demographics and scheduled procedure details. This process eliminates the need for technologists to manually type patient names, accession numbers, or exam codes at the scanner console. The modality acts as a DICOM Service Class User (SCU) and issues a C-FIND request to the worklist broker, which acts as the Service Class Provider (SCP) . The SCP responds with a list of scheduled procedures matching the query keys, such as a specific modality or date range. The technologist selects the correct patient from the returned list, and the modality populates the DICOM header of the subsequently acquired images with the retrieved data, ensuring data integrity and consistency across the imaging chain.
Related Terms
Modality Worklist (MWL) is a cornerstone of the DICOM workflow. It eliminates manual data entry at the scanner by allowing modalities to query the RIS or HIS for patient demographics and scheduled procedure details. The following concepts define the operational environment and technical dependencies of a successful MWL implementation.
Scheduled Procedure Step
The Scheduled Procedure Step (SPS) is the atomic unit of work queried from the Modality Worklist. It defines a specific imaging act to be performed on a patient at a scheduled time.
- Contains the Requested Procedure ID and Scheduled Procedure Step ID.
- Includes protocol codes (e.g., CT Chest without Contrast) via Scheduled Protocol Code Sequence.
- The modality uses the SPS to auto-select the correct scanning protocol, reducing technologist error.
Modality Performed Procedure Step
Modality Performed Procedure Step (MPPS) is the real-time feedback loop that complements the Modality Worklist. While MWL pulls data, MPPS pushes status updates back to the RIS or PACS.
- Reports states: IN PROGRESS, COMPLETED, or DISCONTINUED.
- Communicates the actual number of acquired images, total radiation dose, and contrast agent volume used.
- Essential for accurate billing and resource utilization tracking in the hospital.
Patient/Study Matching Heuristics
When a modality queries the worklist, the RIS must match the query keys to the correct patient record. Robust matching logic is critical to prevent data integrity errors.
- Primary key matching uses the Accession Number or Requested Procedure ID.
- Fallback heuristics involve fuzzy matching on Patient Name, Patient ID, and Date of Birth.
- A Patient Mismatch can cause a study to be stored under the wrong patient folder in the PACS, requiring complex data correction procedures.
Broad Worklist Query
A Broad Worklist Query is a C-FIND request where the modality returns all scheduled procedures for a specific device or department, rather than a single patient.
- Often used at the start of a shift to pre-cache the day's schedule on the scanner console.
- Technologists can then select a patient from a local list, speeding up workflow.
- Requires careful configuration of the Scheduled Station AE Title in the RIS to ensure only relevant procedures are returned.
DICOM Modality Worklist SOP Class
The technical foundation is the Modality Worklist Information Model – FIND SOP Class (UID: 1.2.840.10008.5.1.4.31). This defines the exact data structure for the query.
- The modality acts as the SCU (Service Class User), and the RIS acts as the SCP (Service Class Provider).
- The query uses a C-FIND command with a set of matching key attributes.
- Returned attributes include Patient Name (0010,0010), Accession Number (0008,0050), and Requested Procedure Description (0032,1060).
HL7 Order Message (ORM)
The Modality Worklist is populated by upstream HL7 Order Messages (ORM) sent from the HIS to the RIS. This is the bridge between hospital operations and the imaging department.
- An ORM^O01 message contains the order control code (e.g., 'NW' for new order) and patient visit data.
- The RIS translates the HL7 order into the DICOM Scheduled Procedure Step object.
- Discrepancies between the HL7 order and the DICOM worklist entry are a common source of workflow breakdowns.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us