Modality Performed Procedure Step Service
The Modality Performed Procedure Step Service, commonly known as MPPS, provides a mechanism for modalities to pass information about the imaging they are performing back to the RIS and/or PACS. There are 2 different types of message, and normally, one of each is sent, in order:
An N-CREATE message, setting the status to “IN PROGRESS”. This is sent at the start of the procedure step. An N-SET message, setting the status to “COMPLETE”, which is sent at the end of the procedure step.
Overview Modality Worklist, enables primary imaging equipment (modalities) to query (using C-FIND) for Patient Demographics and Study Details from the MWL SCP, normally part of the RIS,. The modality asks for a list of patients with chosen criteria via Standard C-FIND operation and Modality Worklist responds accordingly. It is important to note that this is the only way that MWL can and does work, namely the modality querying data from the SCP, and there is no means for the SCP to broadcast the data out to modality equipment.
A Module is a group of DICOM attributes which provide information for related data, such as the “Patient” or the “Equipment”.
Use of modules make the writing of the DICOM standard easier, as Part 3 re-uses the same modules in multiple SOP Class definitions, but they are not a structural component of a DataSet, as this is instead sorted according to numerical order of the individual attributes.
Every DICOM Association starts with a process of negotiation whereby the Application Entities involved exchange sufficient information about themselves to allow proper communication. The information passed in the initial request includes:
The AETs of the two applications The list of Presentation Contexts request, each containing a list of Transfer Syntaxes Any Reverse Role Negotiation requests Any Extended Negotiation requests Miscellaneous “User Information” including
The name and UID of the software The maximum data packet size that may be received The acceptance packet contains mostly the same information but each Presentation Context is either accepted or rejected, and if accepted, only a single Transfer Syntax” per Presentation Context is specified.
Network Transfer Syntax Control (COM)
The mechanism is quite different for the simple Send methods compared to using DicomConnection
DicomImage.Send / DicomDataSet.Send For these simple method, the list of offered transfer syntaxes comes from the registry, from the default value of the following key
HKEY_LOCAL_MACHINE/Software/Medical Connections/DicomObjects/TransferSyntax NOTE: The above is a Key not a value. You need to edit the list of transfer syntaxes into the default value of that key.
or to change dynamically, it can be controlled by
Network Transfer Syntax Control (NET)
Background in earlier versions of DicomObjects (both .NET & COM), the same basic mechanism was used for selecting transfer syntaxes:
When initiating, they can be created specifically using Contexts.Add etc. When accepting, they can be selected specifically using Context.AcceptedTS or Reject If neither of the above is used (as most people don’t) then a default mechansim is used, based on the TransferSyntax registry hive, which allows: Setting of specific values for different SOP classes using TransferSyntax/SOP class UID A more generic setting for all other SOP classes in the TransferSyntax/ default value This system, which is described here worked well for many years, but has 3 main drawbacks:
lilatac Normalised objects are like Composite Objects in that they persist from one operation to another (normally in an SCP) but unlike Composite Objects, they only make sense in the context of other objects around them. Common examples of Normalised Object are:
In Printing Basic Film Session Basic Film Box Basic Grayscale Image Box Basic Color Image Box In Modality Performed Procedure Step Service Performed Procedure Step Object
Number of Overlays in Image
How overlay data is stored There are two ways to store overlays in DICOM Image:
Overlay data stored in unused bit planes of the Pixel Data (7FE0,0010) with Samples Per Pixel (0028,0002) of 1. This usage has now retired. Overlay data stored in separate “Overlay pixel data” attribute (60xx,3000). Repeating Groups Multiple overlay planes are represented by standard data elements with even group numbers (ranging from 6000H to 601EH).
Object/Memory Management of DicomImage and DicomDataSet
The following diagram shows the relationship between DicomImage and DicomDataSet objects.
PACS, picture archiving and communication systems, is a term used for a set of computers connected by a network, and dedicated to the storage, retrieval, distribution, and presentation of medical images. A PACS is independent of the format of the information.
Some vendors use the term VNA (Vendor Neutral Archive), but in most respects, the terms are synonymous.
The Digital Imaging and Communications in Medicine (DICOM) standard format is the most common format for medical image data found in PACS.
Performed Procedure Step Object
This is a Normalised Instance which represents the state of a procedure step, and is:
Created by the SCU using N-CREATE with a status of “IN PROGESS” Updated as necessary by the SCU using N-SET operations The final status must (updated by the N-SET) must be “COMPLETED” or “DISCONTINUED”
DICOM allows various relationships between the pixel data and how the image should be displayed. The values here are found in element 0028,0004 and every image should have that value.
Pixel Data to Byte Array
We are often asked how to retrieve the pixel data of a DicomImage into a Byte array. The following code will load an image and copy the pixel data into a byte array.