Modality Performed Procedure Step

Introduction

After the post on Modality Worklist, I felt that it wouldn’t be a complete without explanation on Modality Performed Procedure Step. MWL without MPPS is like a task list without checkboxes, and after all, striking a checkbox on a completed task is great fun. Talking of which, I once red this article about productivity and task lists and since then I’m using a circular checkbox on my paper to do notes because it’s 4 times faster. Instead of 4 lines you only need one. Think of it.

IHE Comes to Rescue

Though the DICOM standard states that it doesn’t go into the details of the implementation and what should be the implications of MPPS on workflow it is very clear from reading the details of the standard that an MPPS is the checkmark of MWL. The gap is closed by IHE radiology technical framework that does a great job and details exactly what should be the workflow and how the implementation should look like. If you are not familiar with IHE, I strongly recommend navigating to their web site and start digging. Getting familiar with the IHE Technical Frameworks can save a lot of expensive software architect hours and more important, save you from implementing things wrong. The IHE TF is high quality software specification document that you can use almost as is for your healthcare IT software projects.


Anyway, if you don’t have time to dig inside the long documents of IHE and DICOM and HL7, here’s a short data and program flow summary:

1. The modality makes a MWL Query. Each result is a requested procedure object with one or more Scheduled Procedure Steps (SPS).
2. The user picks one SPS to perform.  
3. The modality creates a new Modality Performed Procedure Step (MPPS) that references the Study, the requested procedure, and the SPS.  This is done using the N-CREATE command. 
4. There’s a state machine for MPPS with three states:
1. In Progress (A dot at the center of the circular checkbox)
2. Completed (A dash on the checkbox)
3. Discontinued (Back to the beginning)
5. After the images acquisition is done the modality sends an updated status for the MPPS using N-SET command. The N-SET must include a performed series sequence with at least one series in it, even if the procedure was aborted (in which case the series will have no images).
6. At this point the Scheduler should dash the checkbox to mark the task as completed (or discontinued).
7. Though usually you would have a 1-to-1 relationship between a scheduled procedure and a performed procedure, the DICOM data model has a n-to-m relationship between SPS and MPPS. The connection is made by the MPPS that references the SPS that it was performed for.

The DIMSE-N Protocol

Unlike all the other command that we’ve discussed so far in this tutorial namely C-ECHO, C-STORE, C-FIND and C-MOVE that are DIMSE-C commands, MPPS uses the normalized, DIMSE-N protocol commands N-CREATE and N-SET to create and update the Modality Performed Procedure Step normalized  information entity. We’ve discussed the normalized data model (aka DICOM Model of the Real World) briefly in chapter 4 when discussing DICOM Objects and stating that image objects are composites of modules from different information entities.

Like, in MWL before, here’s where MPPS fits into the DICOM Data Model:

Storage Commitment

What is DICOM Storage Commitment Service and why is it needed

Storage commitment (SCM) is a DICOM service that lets you verify if files that were previously sent to the PACS using the DICOM Storage Service were indeed stored by the application you sent it to. The SOP Class UID of this Service is “1.2.840.10008.1.20.1”. One can argue if it is necessary or not because when you send a DICOM image using C-STORE command and get a success status (0x0000) then it is supposed to be stored so the existence of Storage Commitment raises doubts about the meaning of that status in the first place. However, I can defiantly think of reasons for having such service, first because better safe than sorry and second because I already had some programming experience in the days when the DICOM standard was specified, Thanks god, we did make a long way since then. For example, some engineers, for the sake of efficiency and performance considerations, may have decided to first puts the files in a temporary storage or a queue, without even looking at their content and reply immediately with success and then later, when some batch or another thread processes the files in the queue and try to fill the database errors occur. I wouldn’t implement it this way, and I’ll give you reasons for that at the end of this post, but I did run into such implementations. The DICOM standard gives us the service but doesn’t go into the details of what is the implementation meaning should be but IHE does. IHE says that if your application creates instances and send it to somewhere, before deleting them from your local disk it should send a Storage Commitment and if all instances are OK, go ahead and make some space on your hard drive. Sounds like a good idea to me, it’s like double booking. Storage is the transaction and Storage Commitment is the reconciliation, Why not.

Storage Commitment Data Flow

All together SCM is pretty straight forward. All we need to do is to send a list of the instances and get back a reply saying which are in the PACS database and which are not, and that’s exactly how it works. Well, almost.  

Chapter 12: Pixel Data

Frame 0001

I guess that one can't escape talking about pixels when dealing with DICOM. After all, imaging is what DICOM is all about and digital images are built from pixels. So today, to celebrate release 2.0.2.6 (and the x64 version) of the DICOM Toolkit, I'm finally going to touch the heart of every DICOM Image, The Pixel Data.

For today's post I've prepared a little C++ test application that really does nothing much other then putting pixels into the pixel data of a DICOM file and save it. Well, not exactly nothing much, because it creates a huge DICOM file, more then 0.7 GB and compress it and never use more then 20 MB of memory. If you want to know how, read on.

DICOMDIR and Media Interchange

[update 24 March 2023: Latest releases of HRZ software can be found on HRZ website - www.hrzkit.com]

DICOMDIR, Have you heard this term? What does it mean? Do I need this in my system? Lots of questions. Let's try to answer some.

Here's a list with quick information about DICOMDIR:

1. Standard DICOM CD/DVD should have a file named DICOMDIR in its root directory.
2. The DICOMDIR file has in it records that hold paths to DICOM files on the media.
3. DICOMDIR is a DICOM Object holding a sequence of DICOMDIR records nodes each having a type like PATIENT, STUDY, SERIES and IMAGE
4. The DICOMDIR file include key attributes from the data on the media such as Patient Name, Patient ID, Study ID, Study Date.
5. The file names of DICOM files on a standard DICOM CD/DVD should be capital alphanumeric up to 8 characters with no suffix.
6. The CD/DVD may include other files that are not DICOM. The DICOMDIR file does not reference them.
7. The mandatory elements of the DICOMDIR nodes are not 1-2-1 with the mandatory elements in the DICOM Objects. For example Study ID which is Type 2 in DICOM Image objects is Type 1 in DICOMDIR STUDY Record. So when creating your DICOM images if you intend to create DICOMDIR for them, add these elements too.

There are two ways DICOM application can collaborate with one another. They can communicate over TCP/IP network connection or they can exchange files over some physical media.

The first figure in the DIOM standard makes sense eventually

The picture above, which is by the way the first figure in the DICOM standard (page 10 of chapter 1), explains that very well although when I first looked at thirteen years ago it it didn't mean anything to me.
It is worth staying a bit longer on this figure because it has a lot of valuable information in it so lets work it top to bottom.

Converting Bitmap, JPEG and PDF to DICOM

Before we move any further, the examples in this post are included in HRZ's MODALIZER-SDK DICOM C# Examples package. Non programmers, can achieve the same results and much more using MODALIZER+ DICOM Wizard, HRZ's administrative PACS workstation. Let's start.

Imagine you're a dermatologist taking pictures of patients' skin for treatment tracking using a digital camera. The pictures are JPEG's and have no patient info in them. If you could convert them to DICOM and send them to the clinic PACS, that would be a great advancement.

Introduction to DICOM - Chapter 3 - DICOM Elements

Chapter 3 – DICOM Elements

Let’s start with a useful example. Suppose you are a dermatologist and that you use your Smartphone digital camera to record and track patients’ skin condition. You practice a simple procedure that is basically this:

1. Take a photo

2. Send it to yourself by email

3. Open the email on your laptop and save the picture in a folder having the patient name.

As programmers, we don’t have to talk much about the flows of this practice but for a small, one doctor clinic, this might just work.

In this lesson, we’ll take the JPEG image and DICOMIZE it. When we DICOMIZE an Image we wrap the image in a DICOM envelope and add important data that is required by the DICOM standard in order to enable all DICOM enabled applications to read and display the image correctly. It’s true that non DICOM application can display the JPEG image just as it is now without DICOMIZING but that’s another story.

Introduction to DICOM - Chpater 2 - Why is it this way in DICOM?

Introduction to DICOM
Chpater 2 - Why is it this way in DICOM?
Many times when I explain features and aspects of DICOM I get questions like, “Why do you need DICOM if you have JPEG and XML?”; or, ”why is DICOM so complicated?”. Many variants of this question come up over and over again. These types of questions can be very broad or very specific and relate to all kind of choices that the people who write the standard make and the options that they take.