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).
The latest edition of the DICOM Standard, incorporating all Final Text supplements and change proposals, is available here:
This supplement adds an IOD and a SOP Class for a Planar MPR Volumetric Presentation State to the DICOM Standard, allowing Multi Planar Reconstruction (MPR) rendering of 3D volumes or temporal sequences of 3D volumes (a.k.a., 4D).
The Volumetric Source Information, the underlying images for the VPS can for example be XA-3D, enhanced MR and enhanced CT images.
In the case of multiple sources blending pipelines and image fusion are used.
Volumetric Presentation State creators may also create Secondary Captures or other derived images to convey basic presentation information to systems without these capabilities.
Only minor editorial changes have been incorporated since June 2015. These changes, e.g. renaming a module, were briefly presented.
The Final Text of the supplement was approved and it is now part of the DICOM Standard.
This Supplement to the DICOM Standard specifies a new DICOM Information Object for storing magnetic resonance diffusion tractography (MR DT) results.
An MR diffusion acquisition sequence (e.g. EPI, HARDI, etc.) collects data reflecting the diffusivity of water and the directionality of its movement. Based upon a model of diffusion in tissue (e.g. simple tensor, multiple-tensor, etc.) this information can be used by tracking algorithms to estimate the pathways followed by the white matter fiber tracts.
To calculate diffusion tensors, a base-line MRI without diffusion-weighting and at least six differently weighted diffusion MRIs have to be acquired. After some preprocessing of the data, at each grid point a diffusion tensor can be calculated. This gives rise to a tensor volume that is the basis for tracking. Later refinements to the diffusion model and acquisition method include HARDI, Q-Ball, diffusion spectrum imaging (DSI) and diffusion kurtosis imaging (DKI).
A tracking algorithm produces tracks (i.e. fibers) which are collected into track sets. A track contains the x, y and z coordinates of each point making up the track. Depending upon the algorithm and software used, additional quantities like Fractional Anisotropy (FA) values or color etc. may be associated with the data, by track set, track or point, either to facilitate further filtering or for clinical use.
Examples of tractography applications include:
The solutions to the comments from the letter ballot phase were presented.
The supplement has become a new name Tractography Results Storage SOP class.
After a line by line review, the Final Text of the supplement was approved and it is now part of the DICOM Standard
This supplement defines rendering functionality for Restful Services (RS) that is largely equivalent to the functionality in the URI and WS services. It defines a Retrieve Rendered transaction for Restful Services. This transaction allows a user agent to retrieve rendered images and other resources such as text in non-DICOM media types.
In response to a user agent's request, the origin server will render DICOM instances (images, video, reports, etc.) in consumer format media types. Almost all consumer formats require remapping the pixel depth to 8 bits.
Security is beyond the scope of the RESTful services defined in this supplement. However generic Web security mechanisms are fully compatible.
Media types and resource representation were made more clear and consistent. The concept of video was defined to distinguish it from multi-frames.
How to handle wildcard only and combination of wildcard and typed objects during requests to a server was discussed in detail. It was proposed to define what the server is allowed to return for all different request cases. For example, if the client asks for a single frame in PNG format, and the server doesn't support PNG, should it return JPEG as most clients understand how to render JPEG or should it return an error?
The behavior specification for supporting character sets and how to handle unsupported ones was improved.
The Final Text was not completed. WG-06 will hold focused t-cons to complete the Final Text. If not completed during t-cons, it will return to the Nov. 2015 meeting. The next step is final text.
This supplement describes worklist support for the brachytherapy treatment management and treatment delivery systems. The intention is to offer similar level of support for brachytherapy treatment workflow as was introduced for the external beam radiotherapy in Supplement 74: Utilization of Worklist in Radiotherapy Treatment Delivery.
The key element of the IOD is the RT Brachy Delivery Instruction Module, which contains information on the RT Plan to be used, the channels within the plan that will actually be delivered or omitted.
A walk through of the changes from the last presentation was done.
The supplement was voted to go out for letter ballot.
The next step is Final Text.
This supplement defines use-cases and templates for storage of information related to acquisition of small animal images during preclinical research.
It uses lists of coded name-value pairs to specify acquisition content information, rather than depending on SOP-class-specific sets of traditional Attributes.
Information about the acquisition that is relevant to the interpretation of the imaging may not be known to the modality. This is particularly the case in small animal preclinical research, where a myriad of factors that affect quantitative analysis need to be recorded, which would be overwhelming if required to be captured at the modality console user interface.
The type of information to be recorded needs to be in a structured form, and many of the concepts are expected to be available in external lexicons. This is particularly the case for descriptions of experimental conditions, animal physiology and animal handling.
The Acquisition Context Module in the images will remain unpopulated.
The Acquisition Context SR instances will usually be in the same Study as the acquired images.
This supplement defines a new DICOM SR root template and supporting templates, as well as an IOD and SOP Class specific to that template to facilitate interoperability.
The draft for Letter Ballot was presented. There were no public comments from any vendor or clinical organization. A line by line review was performed. A basic principle is to have nested structures optional to enable the user to record as much as necessary but not having to record everything.
The supplement was voted to go out for letter ballot.
The next step is Final Text.
This Supplement defines two storage SOP Classes to distribute planned CT protocols and to record performed CT protocols.
The SOP Classes address details including:
The primary goal is to control the scanner, not to script the entire behavior of the department, or the scan suite.
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 be able to run a protocol from another scanner.
A discussion took place on the extension of the real world DICOM model. The conclusion was that defined procedure protocols references protocol codes.
Further there was a concern that if attributes in the Radiation Dose SR (RDSR) are also available via direct attributes in the image/protocol through this supplement, then there might be less adoption of RDSR. On the other side this is information for the scan.
A mechanism for stating that a block within private attributes are safe or unsafe regarding containing patient identifying information has been included. This is especially interesting for cloud and data mining use cases.
Categories for protocols were discussed. E.g. Quality assurance, phantom testing and animal trials.
A discussion took place regarding appropriate reasons for using a procedure. After some discussion the reasons shall be coded as one or more items of the type UC.
The acquisition constraints example was unclear. It was agreed to find another code to make it more instructive.
A longer discussion on the purpose of the acquisition element description. What is the purpose or intent with this text comment field? The proposed solution is to add a purpose and a summary element instead of the description element.
There were discussions on which elements need to be mandatory and what elements are machine generated or entered by the operator.
The small Supplement 192, Instance Approval Storage, was extracted out of supplement 121, driven by commonality of the supplements 121 and 147. Further uses beyond CT protocols are expected.
Supplement 192 defines a storage SOP Class to convey assertions of approval for Protocols (and other instances). The assertions are encoded using a macro which is also being used within Radiotherapy.
The next step for supplement 121 is Letter Ballot.
This supplement adds two new IODs: RT Physician Intent Storage and RT Segment Annotation Storage to the standard.
Since the development of the initial radiotherapy IODs, both Radiotherapy practice and the DICOM Standard itself have evolved considerably. In particular, workflow management has been added.
Therefore new RT architecture principles habe been defined:
There were approximately 200 comments during the extended public comment phase. All major vendors and many others submitted comments. Overlapping comments were merged. The 50 resulting distinct comments have then been incorporated into the supplement.
A trial phase is planned before going into the letter ballot voting to let vendors implement prototypes and gather experience. Only private tags shall be used.
A discussion took place on treatment days of the week. Which days are preferred and which days of the week are blocked from treatment. It was debated if this should be enumerated week days or time windows relative to important other events.
The next step will be a Frozen Draft for Trial Implementation.
This Supplement specifies the IOD representing content assessment against reference information. 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.
The changes were presented and walked through line by line.
The information model was discussed. One issue was how to handle Delivery Instruction and Task within the model. The conclusion was to move the lower level structure deeper into the document.
The supplement was voted to go out for public comment.
The next step is Letter Ballot
This supplement re-documents (rewrites) PS3.18 Web Services.
The goals of this re-write are:
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 supplement was not discussed due to the lack of time.
A revisit is planned for November 2015.
The supplement stays in before public comments.
The supplement addresses aligning anatomical and functional data through blending. Optionally data is aligned through registration.
Anatomical data is used to locate the area of the functional activity.
The parametric data describes for example statistics, functional activation, cardiovascular reactivity or functional connectivity.
Registration is used to compensate for different frame of reference or movements during assessment or for image distortion.
A superimposed example was shown with an anatomical image and three parametric maps using thresholds and opacity. Another example shows only the outline of the color areas. It is the job of the application to calculate the outlines. If thresholds change statistics and color areas change accordingly in the application views.
The idea is to avoid restrictions when possible.
Normally enhanced MR objects are used for anatomical data.
A discussion took place on having the color maps in the object or letting the user on the application side decide on which color map to use.
A new blending object is necessary to define when two objects are combined. At least two datasets are necessary: anatomical and parametric. They must have equal number of slices, equal geometry and no registration. These restrictions were not agreed upon.
Further when to allow coloring and opacity was discussed.
Threshold of parametric maps have to be handled. Threshold contour display must be enabled.
The supplement is not covering treatment planning. Working Group 6 argued that this supplement must consider how this supplement alignes treatment planning aspect of other supplements.
A concept presentation was shown. The target objects are volumes not surfaces.
Volume Rendering is a data visualization method where voxels are assigned a color and an opacity. For each xy coordinate, the output pixel value is determined by the set of non-transparent voxels along the z-axis.
The supplement 182 Volume rendering Curved MPR has become less priority within Working Group 11. Supplement 190 has taken precedence.
The supplement stays in the in-work state.
This Supplement defines new types of images generated by multi-energy CT scanners.
CT Multi Energy (ME) imaging techniques, including scanning, reconstruction, processing, are defined as when the scanner utilizes multiple energies from the X-Ray beam spectrum, as opposite to the conventional CT imaging, when a single (accumulated) X-Ray spectrum is used.
The primary potential applications this supplement intends to focus on include:
The division into different image types for multi-energy images was presented.
The different image types and their attributes were walked through and improved.
Use cases and the corresponding solution packages were discussed.
There was advice to reuse and extend the segmentation object where suitable.
A revisit is planned for January 2016.
Many professional, public-health, and regulatory authorities recommend or require recording dosimetric information from diagnostic and therapeutic studies that use radiation in the patient's medical records.
For non-oncology therapeutic applications, the current Information Object Definitions (IOD) used for measuring the radiation dose indices is the Radiation Dose Structured Report (RDSR). The RDSR contains only information about the irradiation system or information the system can determine, i.e. radiation output, geometry, x-ray source, detector system, etc. Yet, these IOD do not include any information about the patient, which is required to adequately estimate the radiation dose to the patient.
It is assumed that the best location for information relative to the dosimetric method used and the estimated patient - radiation dose should be to send this data to a Dose Information Reporter, an actor (in the IHE sense) that may or may not be combined with a RIS, a PACS, or may be a standalone system.
The approach taken here for the Patient - Radiation Dose Structured Report (P-RDSR) is to define a new Structured Report (SR) object template and SOP Class.
This SR object, independent of the images or the MPPS, could be routed to an appropriate Dose Information Reporter System. A system that claims conformance to such an SR object would then be expected, as a concomitant of the conformance claim, to appropriately deal with such data items.
Such an SR dose object allows the data flow and data management of patient estimated radiation dose reports to be disentangled from the data flow and data management of images
The template structure was presented. There was an argument to not have any order significance in the template.
The different possibilities of how to group separate doses were described in detail. Grouping on dose method, organ or RDSR source were prominent examples.
Important concepts like organs, groups of organs, portions, methods and phases were discussed in detail. It is not yet clear how to structure the template and how to relate it with the RDSR model.