Rarely implemented DICOM services (Part-2)

A continuation to my previous post about the rarely implemented DICOM services, I am talking this time about two services which are rarely used inside the imaging department workflow and replaced by vendor’s proprietary solutions , I illustrates here short description about these services , their application and benefits within the digital environment.

The services are:

• Printer configuration Retrieval SOP and Service Class
• Media creation management SOP and Service class

Printer Configuration Retrieval SOP Class

This service allows a device (workstations, Modalities, Etc...) to determine the capabilities of the printer and its imaging parameters and reduce the manual configuration which should be done to all devices.

The normal criteria is to keep tables of configuration information inside the workstation for all printers to which they are connected, these tables for sure may be long and complex and requires a system admin to make any required changes to it, Upon implementing that service the workstation will dynamically retrieve the required information from each printer support that service.

Information like pixel spacing, allowed medium types, configuration information (CI), Display format, number of Rows and columns could be exchanged through that service which reflect the printer capabilities as we mentioned before.

Having such service in use will reduce the configuration and setup headache to be done at the workstation or modalities that connect to the printer. Especially when these configuration tables are to be re-entered for any reason like updating or reinstalling the software.

This SOP class consists of Printer configuration IOD and DICOM service element N-GET

The Printer Configuration Retrieval SOP Class UID is “1.2.840.10008.5.1.1.16.376”.

Media Creation Management Service Class

The Media Creation Management Service Class defines a mechanism by which an SCU can instruct a device to create Interchange Media containing a set of Composite SOP Instances that have already been transferred to the media creation device using the Storage Service Class.

This service class defines parameters to specify the specifications of the required interchange media, these parameters like Requested media application profile for the listed instances, Allowing Lossy compression or no, including display application or no into the requested media, Also it includes parameters for controlling if label is required and it should be extracted from the DICOM instances or from text explicitly specified in the request, the label style, allowing media splitting and more other parameters.  

This SOP class managed through these DICOM Service elements or commands N-ACTION,N-CREATE,N-GET.

Let’s imagine that scenario as an application for that service “The SCU transmits the SOP Instances to the SCP using the Storage Service Class. The request for media creation is transmitted to the SCP and contains a list of references to one or more SOP Instances. Success or failure of media creation is subsequently indicated by the SCU requesting the status from the SCP on the same or a separate association.”

Having this service in use will standardize the centralized CD/DVD burning process, also it will make this process an independent process regardless the participant parties or vendors as long as they comply with that DICOM service class,

The Media Creation Management SOP Class shall be uniquely identified by the Media Creation Management SOP Class UID, which shall have the value “1.2.840.10008.5.1.1.33”.

 References:

·                     PS 3.3-2011. Digital Imaging and Communications in Medicine (DICOM). Part 3: Information Object Definitions

·                     PS 3.4-2011. Digital Imaging and Communications in Medicine (DICOM). Part 4: Service Class Specifications

·                     OTECH DICOM Basics Book

Rarely implemented DICOM services

There are some of DICOM services implemented rarely within the imaging solutions and usually replaced by the vendor's private and proprietary methods , We illustrates here some of these services which are:

• General Purpose Worklist Service Class
• Hanging Protocol Storage and Query/Retrieve Service Class

General Purpose Worklist Service Class  Provides tasks to be done by the users such as interpretation at a diagnostic workstation while managing their status so that multiple users can use same pool of exams without any conflict on running jobs.

Imagine several radiologists reading images through multiple Workstations from a common pool of exams, when a radiologist start reading in a certain study a signal is sent back to the image manager to lock that study and share that status to the other radiologists which minimize the chance of double reading

This service will be useful in the environment that includes multiple information and imaging systems to sync between all jobs running on all systems to manage the interpretation, reporting, etc... Processes between systems in a vendor neutral environments

Jobs that could be exchanged using that service are a lot such as image processing, QC,Transcription, interpretation and CAD ….

General purpose Worklist SOP Class is implemented using C-FIND Dicom service element which allow the workstation to retrieve its jobs and tasks, devices with roles of SCU and SCP should conform with the GPWL SOP Class as illustrated in Part 3 and Part 4 of DICOM Standard

In conjunction with General purpose worklist service there are 2 additional services should be in use as well which are General Purpose Scheduled Procedure Step which allow locking of jobs to be performed using DICOM N-Action command and General Purpose Performed Procedure Step SOP Class which communicate the status of the job when finished using a group of normalized services and commands (N-ACTION,N-SET,N-GET)

General Purpose Information Model - FIND	1.2.840.10008.5.1.4.32.1
General Purpose Scheduled Procedure Step SOP Class	1.2.840.10008.5.1.4.32.2
General Purpose Performed Procedure Step SOP Class	1.2.840.10008.5.1.4.32.3

Hanging protocol (Storage and Query/Retrieve) service class  This service allow storing and Query/retrieve of hanging protocols between servers and workstation,

In other words, it allow exchanging of hanging protocol IOD  using associated C-store ,c-find and c-move between servers and workstations so all hanging protocols could be stored in a standard manner and this is for sure an optimum for the VNA environments

As illustrated before this operation usually managed through a private and proprietary methods implemented by the vendors

Hanging Protocol Storage	1.2.840.10008.5.1.4.38.1
Hanging Protocol Information Model - FIND	1.2.840.10008.5.1.4.38.2
Hanging Protocol Information Model - MOVE	1.2.840.10008.5.1.4.38.3

 References:

• PS 3.3-2011. Digital Imaging and Communications in Medicine (DICOM). Part 3: Information Object Definitions
• PS 3.4-2011. Digital Imaging and Communications in Medicine (DICOM). Part 4: Service Class Specifications
• OTECH DICOM Basics Book
• Medical Connections (https://www.medicalconnections.co.uk/)