January 2016 Bjoern.Nolte@siemens.com

Here are the summary notes from the latest DICOM Working Group 6 Meeting (WG-06).

WG-06 meets five times a year to do technical review and harmonization of the output from the 30 DICOM Working Groups.

Current progress on new DICOM supplements (new chapters to the standard) is shown below. Also change proposals (bug fixes in the standard) are shown grouped into voting packages (CPacks).

Content Assessment

Sup 185, 147 80% After Letter Ballot

This Supplement specifies the IOD representing content assessment by a person or device. It stems from the development of the Quality Assurance with Plan Veto profile in IHE-RO. While the profile originated from use cases to assess RT Plan, the IOD is generalized to allow for reporting of assessment results of any DICOM SOP Instance.

Selected letter ballot comments were discussed.

Working group 6 suggested to use a short string for the modality name of the supplement. This harmonizes with other modality names in the standard. It was decided to use ASMT.

The level of concern (major, moderate, minor and none) was seen as having too less of a prominent position within the supplement. It was decided to move it up to a central position.

It was proposed that the conformance statement section will demand documentation of how rules for level of concern for a specific system are assessed.

It was clarified that there shall exclusively be structured or unstructured constraint observations but not both.

View details on sup 185»

Supplement 147 2nd Gen. RT: Prescription and Segment Annotation

This supplement addresses the need for a new generation of IODs and processes required for use in Radiotherapy, in particular, workflow management. The IODs defined in here represent a base for further definition of Radiotherapy-specific IODs in separate supplements.

Key principles:

  • Follow the enhanced multi-frame paradigm.
  • Different representations of data are encoded in different IODs. This is in contrast to first generation objects.
  • Backward compatibility
  • Use of advanced DICOM objects: 3D segmentation, mesh representation, rigid and deformable registrations.

The existence of new treatment techniques (such as robotic therapy and tomotherapy) have been taken into account, along with new treatment strategies (such as image-guided therapy and adaptive therapy).

The changes from the collected comments were presented. Indexing of treatment phases, especially previous and consecutive, were extensively discussed.

View details on sup 147»

CT Protocol

Sup 121 80% After Letter Ballot

This Supplement defines a pair of storage SOP Classes to distribute defined CT protocols and to record performed CT protocols. The Supplement also defines a Query/Retrieve Service and corresponding C-FIND behaviors. Similar pairs of SOP Classes for other modalities may be added in other supplements.

The two storage SOP Class variants for CT Procedure Protocol Storage are: Defined and Performed.

The SOP Classes address details including:

  • Patient preparation & positioning
  • Equipment characteristics
  • Acquisition technique
  • Reconstruction technique
  • Preliminary image handling such as filtering, enhancement, auto-sending, etc.

In terms of scope, the primary goal is to control the scanner, not to script the entire behavior of the department, or the scan suite. The protocol object supports simple textual instructions relevant to the protocol such as premedication, patient instructions, etc.

The supplement also introduces a Private Data Element dictionary to permit description of unique scanner model characteristics and the ongoing addition of system-specific features and settings. This dictionary allows protocol management systems to display the value with an appropriate label to the operator.

It is expected that the vast majority of protocol objects will be specific to a certain model and version of scanner.

There is no requirement that a scanner must be able to run a protocol from another scanner. If a scanner can parse a foreign protocol and help the user compose a similar local protocol that might be very useful.

It was decided to explicitly mention that all private elements, which the manufacturer wants to make public, shall be stated in the conformance statement. A walk through of the changes introduced from the last comment phase was done.

View details»

Volume Rendering

Sup 190 60% After Public Comment

This supplement extends the family of Volumetric Presentation States beyond Planar MPR Volumetric.

It adds three additional SOP Classes; one restricted to basic volume rendering, one for segmented volume rendering and one for fusion of several different volumes.

Volume Rendering generally consists of a number of steps to generate a 2D rendered view from one or more volumes.

The final 2D view of a pixel in the XY plane is generated by calculating the contribution from color and opacity (transparency) of the different volume elements (voxels) in the z axis (depth) from the XY position of the pixel.

Rendering steps which are described in the supplement are:

  • Segmentation: Assinging different color and opacity lookup tables to different volume elements
  • Classification: Assigning color and opacity
  • Shading: Basic light calculation

Rendering steps which are outside of the scope of this supplement are:

  • Gradient Computation: Finding boundaries between different types of tissues
  • Resampling of voxel values through interpolation
  • Composing: The specific algorithm will remain proprietory

See Section A.X.x3.1 for a list of the parameters that are specified in the Volumetric Presentation State.

An exact match of volume presentation on multiple devices cannot be guaranteed. Nevertheless, reasonable consistency is provided by specification of inputs, geometric descriptions of spatial views, type of processing to be used, color mapping and blending, input fusion, and many generic rendering parameters, producing what is expected to be a clinically acceptable result.

The supplement was presented with the focus on responses to the collection of input from the public comment phase.

Within the perspective view it was recommended to use far values instead of near values.

Depth color mapping was discussed with pros and cons.

In many cases the use of segmentation objects is not wanted or not possible.

It was proposed to support simple use cases for the supplement without relying on segmentation objects.

The introductory slide set for the supplement to product managers and implementers was presented and discussed.

It was made clear to focus on value statements for product managers. The detail level for implementers seemed right.

View details»

Patient Rad. Dose SR

Sup 191 60% Sent to Public Comment

The estimated radiation dose to a patient is recorded in a structured report.

This includes:

  • Radiation dose from CT
  • Projection X-Ray
  • Radiopharmaceutical administration (diagnostic and therapeutic)
  • Dose from an external beam

Excluded are the following:

  • Ion beam therapy
  • Brachytherapy
  • Occupational radiation exposures

There are multiple methodologies and models that can be used to estimate patient dose and these methods are rapidly changing. Once an estimate of the radiation dose absorbed by a patient is performed, storing and transferring the method used, parameters involved with them, and the resulting dose estimate in standard format is needed.

The radiation dose should be to send to a Dose Information Reporter, an actor (in the IHE sense).

The SR dose object allows the data flow and data management of patient estimated radiation dose reports to be disentangled from the data management of images.

Some of the open issues touches upon defining codes. It was made clear that the goal is to reuse existing codes and not to reinvent any new ones.

The possibility to use several calculation methods and the corresponding multiple groups for the same exposure was proposed.

The differences for fetal, lung and breast dose were illustrated. As they have different methodologies they should be coded in different groups.

A general comment was made to use more generic terms, for example to prefer system source over x-ray source. Further the advice was stated to avoid too many possible levels of scoped comments.

The uncertainty regarding absorbed dose and dose equivalent was proposed to be made more explicit with more details.

It was explained how the model characteristic concept is working and how it is used within the supplement. Often the actual patient's age is outside of the minimum and maximum model limits.

The supplement is sent out for public comments.

View details »

Redoc Web Services

Sup 183 40% In Work

This supplement re-documents (rewrites) PS3.18 Web Services with the goals:

  • Bring the Standard into conformance with the latest Web Standards, especially [RFC7230 - 7234], and [RFC3986 - 3987].
  • Use the ABNF defined in [RFC5234] and [RFC7405] to specify the syntax of request and response messages.
  • Use standard terminology throughout the standard.
  • Use a standard format for documenting services and transactions.
  • Clarify ambiguities and underspecified aspects of the Standard using the CP process.

The most important aspect of the re-documentation is that no semantic content of the Standard should be changed. Errors, ambiguities, and underspecified aspects of the existing standard have been corrected through the CP process prior to the finalization of this supplement.

The topic of offset and when to support it was addressed. The functionality is mandatory but the server can report an error during processing of the request if offset is not supported.

The conformance section was presented and discussed. It is believed that from the three versions of web services: URI, WS (Soap) and RS (RESTful) the latter will be most frequently used.

View details »

Multi Energy CT

Sup 188 40% In Work

This Supplement defines new types of images generated by Multi-Energy CT scanners. CT Multi-Energy (ME) imaging techniques including scanning, reconstruction, processing, when the scanner utilizes multiple energies from the X-Ray beam spectrum.

The primary focus of this supplement includes:

  • Making Multi-Energy information available to rendering, processing applications and for clinical display
  • Allowing better differentiation of materials that look similar on conventional CT images, e.g., to differentiate Iodine and Calcium in vascular structures
  • Accurate description of virtual non-contrast acquisition, when the virtual/artificial non-contrast image is generated out of the contrast image.

The following objectives are important:

  • To facilitate fast and easy adoption
  • To address (or at least to minimize) the risk of misinterpretation when the ME images are displayed by a display does not support the new attributes of the ME-image, including incorrect measurements.
  • To adapt existing attributes of the CT / Enhanced CT IOD to fit ME techniques.

A walk trough of the definition section was done, improving many of the terms with respect to precision, consistency and clarity. E.g. The clarification of what enhanced means: The Houndsfield units are boosted for the particular material of interest (for example Calcium).

The additional modules were presented, which are extending the traditional CT object. The working group 6 recommended that all additional modules shall be conditional or optional to avoid breaking older systems expecting traditional object structure only.

To support this the supplement will add "shall be empty for multi energy image" in all attributes which are traditional CT only.

It was clarified how to describe proportion of total exposure time, especially when having several different energy levels.

A walk through was performed of multi energy attributes, which have been carefully added along with the appropriate conditions to the standard CT attributes.

It was advised that the material codes table shall be extensible.

A non-conclusive discussion touched upon how to code segmentation objects.

Among the ideas were:

  • Use segmentation object
  • Create a dummy image with only one bit
  • Create a CT Protocol holding acquisition information
  • Create a raw CT object

Segmentations are instantiated in different ways. It can be with a bit set per pixel for "within organ". It can have bits set when a percentage threshold is reached e.g. 80% Calcium or for probability levels.

View details »

fMRI Blending

Sup 189 40% In Work

The current DICOM standard allows the storage of fMRI images in the Enhanced MR image object.

The fMRI workflow however consists of multiple steps surrounding the actual imaging component, involving roles of patient, trainer, tester, processor and clinical user.

The proposal is to extend the DICOM framework to also capture the workflow and data items like paradigms used during the functional assessment in parallel with the image data documentation.

The fMRI workflow consists of the following steps:

  • Procedure Ordering
  • Patient Assessment and Training
  • Data Acquisition
  • Post-Acquisition
  • Data Processing, Interpretation and Results Distribution

This supplement will focus on: 4D Time Series data and Statistical Maps

It was advised to reuse the same text content as for other look up tables (LUTs) in this supplement.

It was discussed which pipelines are using the concept of thresholds, discarding parts of the image during blending, thus creating holes.

A currently missing overview will be included in the supplement.

During color mapping in a parametric map, the floating point values shall be mapped to RGB values for display. It was suggested to make this more general with a specific parametric blending presentation state.

View details »

Contrast Agent

Sup 164 40% In work

The new SOP Classes introduced describe administration events, flows, pressure, timings, physio-chemical attributes and pharmacological attributes of the agent administration and also consumables related to the administration. These SOP classes do not describe radioactivity or dosimetry administered.

Four types of Imaging Agent Administration SR objects are introduced:

  • Basic (Attribute based instead of structured report based for the simple use)
  • Defined (Generic and extensible)
  • Planned (For the delivery plan)
  • Performed (For reporting and recording)

A walk through of the changes on codes was done.

After some discussion it was decided to add recording of risk factors as an open issue for public comment.

Further input from the comment phase is requested for which variants of these IODs are the right ones. The current idea is to keep basic, planned and performed but to skip defined.

View details»

Instance Approval

Sup 192 40% In Work

This Supplement defines a storage SOP Class to convey assertions of approval for instances. Specific codes and examples are provided for assertions about CT Protocols stored as DICOM instances.

The assertions are encoded using a macro which is also being used for RT. The macro was originally part of Supplement 121. It was decided to move the macro into a separate new supplement for general reuse.

The topic of date time assertions, especially expiry and invalidation, was pondered upon. The goal is to constrain the flexibility to increase interoperability. It was proposed to add this to the open issues to get feedback from the user and vendor communities.

Further it was discussed how to find the sweet spot of information sharing or duplication with protocol objects.

View details »

CPack 84

WG-06 approved Final Text in January 2016

CPack 85

Current set for March 2016 Final Text.

CPack 86 candidates

Current candidates for final text in June 2016
Clicking on one specific Change Proposal above will take to that actual content.