Modality workflowworklist, MPPS and storage commitment
This is the DICOM life of one exam: the scanner asks which patients are scheduled, tells everyone when it starts and ends, sends the images and gets a promise that they are safely stored. It is the DICOM half of the IHE Scheduled Workflow.
- DICOM
- Internal action
- Dashed = reply
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
An order becomes a worklist entry
Key detailWhat happens
A referring system sends an order to the RIS, as an HL7 ORM (or OMG in the HL7 v2.5.1 option of IHE). The RIS gives it an accession number, schedules a procedure step on a modality and stores it where the worklist service can read it.
Why it is needed
Worklist is the single source of truth about who is scheduled. Without it the technologist types the patient data by hand, and typing errors are the biggest cause of mismatched studies.
Technical details
- HL7 ORM^O01 (or OMG^O19 in the IHE v2.5.1 option) in from the order placer
- Accession number (0008,0050) created by the order filler
- Scheduled Procedure Step: station, modality, date and time
- Requested Procedure ID, Study Instance UID generated or reserved
C-FIND on the Modality Worklist
Core stepWhat happens
The modality sends a C-FIND using the Modality Worklist SOP Class. The matching keys usually say "my modality, my AE title, today", and the return keys list all the patient and order attributes that the modality needs.
Why it is needed
The modality only shows the exams meant for it, so the technologist picks from a short list instead of searching the whole hospital.
Technical details
- Modality Worklist FIND 1.2.840.10008.5.1.4.31
- (0040,0100) ScheduledProcedureStepSequence with:
- (0008,0060) Modality = CT
- (0040,0001) ScheduledStationAETitle = CT01
- (0040,0002) ScheduledProcedureStepStartDate = today
- Return keys: PatientName, PatientID, AccessionNumber, StudyInstanceUID ...
C-FIND-RSP: the worklist
Core stepWhat happens
The worklist SCP answers with one pending response per scheduled exam, each carrying the patient and order data, and ends with a success response. This is the same C-FIND mechanism as the query lesson.
Why it is needed
The attributes are exactly what the modality must put in every image it makes, so images and order match from the first byte.
Technical details
- Status FF00 per entry, 0000 at the end
- (0010,0010) PatientName, (0010,0020) PatientID, (0010,0030) PatientBirthDate
- (0008,0050) AccessionNumber, (0020,000D) StudyInstanceUID
- (0040,1001) RequestedProcedureID, (0040,0009) ScheduledProcedureStepID
The technologist selects the patient
Key detailWhat happens
The technologist picks the patient on the console. The modality copies the worklist attributes, including the Study Instance UID and accession number, into the images it will create.
Why it is needed
If the technologist types the patient instead of selecting it, the images carry different identifiers than the order, and they land in the PACS as an unmatched study.
Technical details
- Same StudyInstanceUID as in the worklist
- Same AccessionNumber, PatientID and name as the order
- Modality creates a new SeriesInstanceUID and SOPInstanceUIDs
MPPS N-CREATE: IN PROGRESS
Core stepWhat happens
The modality creates a Modality Performed Procedure Step object on the MPPS SCP. It references the scheduled step it is performing and records the start time, the status and the station.
Why it is needed
This tells the rest of the hospital that the exam really began. The RIS can change the order status from scheduled to in progress, and the PACS can expect images for this study.
Technical details
- MPPS SOP Class 1.2.840.10008.3.1.2.3.3
- (0040,0252) PerformedProcedureStepStatus = IN PROGRESS (the only value an N-CREATE may carry)
- (0040,0270) ScheduledStepAttributesSequence: StudyInstanceUID, AccessionNumber, Requested Procedure ID
- (0040,0253) PerformedProcedureStepID, (0040,0241) PerformedStationAETitle
- Usually sent to the PACS / PPS manager, which forwards it to the RIS
C-STORE: send the images
Core stepWhat happens
The modality stores every image of the exam in the PACS. Each C-STORE gets its own response.
Why it is needed
This is the actual image delivery. Because the order attributes were copied from the worklist, the PACS can file the study under the right patient and accession number without any manual work.
Technical details
- One C-STORE-RQ / RSP per instance
- Status 0000 per image, see the C-STORE lesson
- PACS links the study through StudyInstanceUID and AccessionNumber
MPPS N-SET: COMPLETED
Core stepWhat happens
When the exam ends, the modality updates the same MPPS object with N-SET. It sets the status to COMPLETED (or DISCONTINUED if the exam was stopped) and lists the series and images it made.
Why it is needed
The PACS can check that it received everything the modality says it produced. The RIS can mark the order complete, which for example lets the reading workflow start.
Technical details
- (0040,0252) PerformedProcedureStepStatus = COMPLETED (or DISCONTINUED + reason)
- (0040,0340) PerformedSeriesSequence, with (0008,1140) ReferencedImageSequence per series: the list of images the modality made
- The SCP accepts N-SET only while the status is IN PROGRESS, otherwise it answers failure 0110 (processing failure)
- (0040,0250) / (0040,0251) end date and time
- After COMPLETED or DISCONTINUED the modality may not change the MPPS or add images to it; to continue it creates a new MPPS
- The PACS forwards the status to the RIS, often as an HL7 order status message
Storage Commitment N-ACTION
Core stepWhat happens
The modality sends the list of SOP Class and SOP Instance UIDs it just stored and asks the PACS to commit to keeping them.
Why it is needed
A C-STORE success only says "received". Storage commitment says "safely stored", and it is the signal that lets the modality delete its own local copy.
Technical details
- Storage Commitment Push Model 1.2.840.10008.1.20.1
- Well-known SOP Instance UID 1.2.840.10008.1.20.1.1
- ActionTypeID = 1 (request storage commitment)
- (0008,1195) TransactionUID
- (0008,1199) ReferencedSOPSequence: class and instance UID of every image
The PACS makes sure the images are safe
Key detailWhat happens
The PACS checks every listed instance against its archive. Depending on the product, this can include waiting for a copy to a second site or tape.
Why it is needed
The promise is only worth as much as the check behind it. This is why the response can come minutes after the request.
Technical details
- All instances found and stored: success
- Some missing: they go in the failed list
- Policy decides how safe "stored" is (one copy, two copies ...)
N-EVENT-REPORT: committed
ConfirmationWhat happens
The PACS sends the result as an N-EVENT-REPORT with the same Transaction UID. It must be able to send it on a different association than the N-ACTION, and the modality must be able to receive it there. It may try the same association, but the modality is free to release it first.
Why it is needed
On success the modality may remove its local images. On failure it knows exactly which images to send again, and no image is lost silently.
Technical details
- EventTypeID = 1 (commitment successful) or 2 (commitment partially failed)
- (0008,1195) TransactionUID = the one from the request
- (0008,1199) ReferencedSOPSequence = committed instances
- (0008,1198) FailedSOPSequence = not committed; each item has (0008,1197) FailureReason:
- 0110 processing failure, 0112 no such object instance, 0119 class / instance conflict
- 0122 SOP Class not supported, 0131 duplicate Transaction UID, 0213 resource limitation
- Every instance from the N-ACTION appears in the report, either as committed or as failed
- The Transaction UID is used once: after the report it is no longer active and may not be reused
- Different association: the modality accepts it with the SCP role proposed by the PACS, which must use the same AE title as before; configure the modality AE title, IP and port on the PACS
- Same association: the PACS, as association requestor, has to negotiate the SCP role (SCU/SCP role selection)
All steps at a glance
Glossary
- SCU
- Service Class User. The side that asks for a service, such as a scanner that wants to store images.
- SCP
- Service Class Provider. The side that provides the service, such as a PACS that stores images.
- Modality Worklist (MWL)
- A DICOM service where the modality asks the RIS which patients and procedures are scheduled for it, with a C-FIND.
- MPPS
- Modality Performed Procedure Step. A DICOM object, created with N-CREATE and updated with N-SET, that reports the start and the end of an exam.
- Storage Commitment
- A service in which the modality asks a PACS to confirm that listed images are safely stored, with N-ACTION and N-EVENT-REPORT.
- DIMSE-N
- The "normalized" services: N-CREATE, N-SET, N-GET, N-ACTION, N-DELETE and N-EVENT-REPORT. They work on a managed object, unlike the C- services.
- Accession number
- The unique ID of one imaging request. It links an image study to its order and report.
Summary
- Worklist is a
C-FINDon SOP Class1.2.840.10008.5.1.4.31. It gives the modality the patient and order data so nobody has to type it. - MPPS is
N-CREATE(IN PROGRESS) thenN-SET(COMPLETED or DISCONTINUED). It tells RIS and PACS what the modality did. - The images travel with
C-STORE. The PACS matches them with the order throughStudyInstanceUIDandAccessionNumber. - Storage Commitment is
N-ACTIONfrom the modality andN-EVENT-REPORTfrom the PACS. It means "safely stored", which is stronger than a C-STORE success. - Most failed exams with the wrong patient or accession number come from skipping the worklist: the data was typed, not selected.
The 10 steps in plain text
An order becomes a worklist entry
A referring system sends an order to the RIS, as an HL7 ORM (or OMG in the HL7 v2.5.1 option of IHE). The RIS gives it an accession number, schedules a procedure step on a modality and stores it where the worklist service can read it.
Why: Worklist is the single source of truth about who is scheduled. Without it the technologist types the patient data by hand, and typing errors are the biggest cause of mismatched studies.
C-FIND on the Modality Worklist
The modality sends a C-FIND using the Modality Worklist SOP Class. The matching keys usually say "my modality, my AE title, today", and the return keys list all the patient and order attributes that the modality needs.
Why: The modality only shows the exams meant for it, so the technologist picks from a short list instead of searching the whole hospital.
C-FIND-RSP: the worklist
The worklist SCP answers with one pending response per scheduled exam, each carrying the patient and order data, and ends with a success response. This is the same C-FIND mechanism as the query lesson.
Why: The attributes are exactly what the modality must put in every image it makes, so images and order match from the first byte.
The technologist selects the patient
The technologist picks the patient on the console. The modality copies the worklist attributes, including the Study Instance UID and accession number, into the images it will create.
Why: If the technologist types the patient instead of selecting it, the images carry different identifiers than the order, and they land in the PACS as an unmatched study.
MPPS N-CREATE: IN PROGRESS
The modality creates a Modality Performed Procedure Step object on the MPPS SCP. It references the scheduled step it is performing and records the start time, the status and the station.
Why: This tells the rest of the hospital that the exam really began. The RIS can change the order status from scheduled to in progress, and the PACS can expect images for this study.
C-STORE: send the images
The modality stores every image of the exam in the PACS. Each C-STORE gets its own response.
Why: This is the actual image delivery. Because the order attributes were copied from the worklist, the PACS can file the study under the right patient and accession number without any manual work.
MPPS N-SET: COMPLETED
When the exam ends, the modality updates the same MPPS object with N-SET. It sets the status to COMPLETED (or DISCONTINUED if the exam was stopped) and lists the series and images it made.
Why: The PACS can check that it received everything the modality says it produced. The RIS can mark the order complete, which for example lets the reading workflow start.
Storage Commitment N-ACTION
The modality sends the list of SOP Class and SOP Instance UIDs it just stored and asks the PACS to commit to keeping them.
Why: A C-STORE success only says "received". Storage commitment says "safely stored", and it is the signal that lets the modality delete its own local copy.
The PACS makes sure the images are safe
The PACS checks every listed instance against its archive. Depending on the product, this can include waiting for a copy to a second site or tape.
Why: The promise is only worth as much as the check behind it. This is why the response can come minutes after the request.
N-EVENT-REPORT: committed
The PACS sends the result as an N-EVENT-REPORT with the same Transaction UID. It must be able to send it on a different association than the N-ACTION, and the modality must be able to receive it there. It may try the same association, but the modality is free to release it first.
Why: On success the modality may remove its local images. On failure it knows exactly which images to send again, and no image is lost silently.
Common questions
What is the DICOM Modality Worklist?
A service that lets a modality query the RIS (the Worklist SCP) with a C-FIND to get the scheduled patients and procedures for its station. It uses the Modality Worklist SOP Class 1.2.840.10008.5.1.4.31 and returns patient, order and study attributes, including the accession number and Study Instance UID.
What is MPPS and why does it matter?
Modality Performed Procedure Step reports from the modality what was done: when the exam started, when it ended or was stopped, and which series and images were made. The RIS uses it to update the order status, and the PACS uses it to check that all images arrived and to start routing and reading workflows.
What is the difference between C-STORE success and Storage Commitment?
C-STORE success (0000) means the PACS received the image and handled it. Storage Commitment is an explicit, separate promise that the images are stored safely and can be deleted from the modality. It uses N-ACTION from the modality and N-EVENT-REPORT from the PACS.
Why is the worklist query returning nothing?
Usually a matching key does not fit: the Scheduled Station AE Title or Modality does not match what the RIS has for the order, the date is not today, or the worklist provider does not know the calling AE title. Compare what the modality sends in the C-FIND with the order in the RIS.
Why does the PACS need to open a connection to the modality?
For the N-EVENT-REPORT of storage commitment. If the modality closed the association, the PACS opens a new one (as SCU of the commitment SOP Class) to the modality's configured AE title, IP address and port. Allow that in the firewall and configure the modality as a destination on the PACS.
Is MPPS sent to the RIS or to the PACS?
It depends on the site. In IHE Scheduled Workflow the modality sends MPPS to the Image Manager (the PACS), which relays it to the Order Filler (the RIS). Many modalities can send it to both. Check the conformance statement of the modality for the AEs it can send to.