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).
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.
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.
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.
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:
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.
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:
Rendering steps which are outside of the scope of this supplement are:
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.
The estimated radiation dose to a patient is recorded in a structured report.
Excluded are the following:
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.
This supplement re-documents (rewrites) PS3.18 Web Services with the goals:
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.
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:
The following objectives are important:
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:
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.
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:
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.
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:
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.
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.