November 2015 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).

RT Brachytherapy

Sup 184 100% Final Text in Nov. 2015

The modifications introduced by this supplement describe worklist support for the brachytherapy treatment management and treatment delivery systems, similar to supplement 74 for first generation RT.

This is achieved by the addition of the following:

  • RT Brachy Application Setup Delivery Instruction Storage Composite IOD.
  • It contains the data necessary to instruct a treatment delivery device on what is to be delivered.
  • 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.

This supplement is being driven by the desire to address the lack of support for brachytherapy treatment delivery workflow in the current standard.

The Final Text of the supplement was approved and it is now part of the DICOM Standard.

View details »

Preclin. Acq. Small Animal

Sup 187 100% Final Text in Nov. 2015

This Supplement defines use-cases and templates for storage of information related to acquisition of small animal images during preclinical research.

The Acquisition Context SR instances, a "description of the conditions present during data acquisition", 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 author briefly explained which final comments have been resolved since the last presentation.

  • A Structured Report is used to encode the Acquisition Context, rather than encoding the information in the images in new Modules or the generic Acquisition Context Module.
  • Coding or defining quantity of enrichment material is currently beyond the state of the art. For now, text description, manufacturer and present or not is sufficient.
  • There is a need to model mixtures of anesthetic agents.
  • A specific context group for imaging procedures for preclinical small animals is needed. Preclinical acquisition and management systems may not have access to an ordering/scheduling system to provide codes via a worklist. LOINC codes are used preferentially when available.
  • The scope of what to encode is largely confined to significant factors that affect imaging outcome (e.g., metabolic effects).
  • A single value for housing unit air changes, average temperature, humidity and airflow is sufficient.

Examples have been moved to Part 17. All references to real vendors have been changed to ACME.

After a line by line review, the Final Text of the supplement was approved and it is now part of the DICOM Standard

View details»

Restful Rendering

Sup 174 100% Final Text in Nov. 2015

This supplement defines rendering functionality for Restful Services that is largely equivalent to the functionality in the URI and WS services.

It defines Retrieve Rendered and Retrieve Rendered Presentation State transactions for Restful Services. These transactions allow a user agent to retrieve rendered images and other instances in non-DICOM media types from an origin server.

In response to a user agent's request, the origin server will render DICOM instances (images, video, reports, etc.) and encode them 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.

A telephone conference prior to the November WG6 meeting completed the review of the supplement text.

The supplement was voted to become final text and incorporated into the standard.

View details»

RT Content Assessment

Sup 185 80% Revisit Jan. 2016 Out for Letter Ballot

This Supplement specifies the IOD representing content assessment. 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.

More clarity has been added to the section "level of concern" regarding major, moderate, minor and no concern. The expectation has been made clear, that majors are to be include.

The topic of fiducials was discussed in some detail in the context of Radio Therapy (RT) in general. The usage in RT shall be aligned with the overall DICOM use of the concept: As certain marker points within the image IODs. Working group 6 pointed out to be very careful within RT reuse of general concepts. It has to be decided on a case by case basis if a general concept fits the intended use within the RT use case.

After a line by line review, the supplement was voted to go out for Letter Ballot voting.

View details»

PS Volume Rendering

Sup 190 60% Revisit Jan. 2016 Out for public comment

This supplement extends the family of Volumetric Presentation States by adding two additional SOP Classes to represent Volume Rendering Volumetric Presentation States, one restricted to a single input volume and one allowing multiple input volumes.

Volume Rendering is a data visualization method where a 2D render view through volume data is created. Voxels (volume sample points) are assigned a color and an opacity (alpha), and for each XY coordinate of the render view the output pixel value is determined by accumulating the set of non-transparent voxels samples along the z-axis.

The Volume Rendering Volumetric Presentation State also provides for alpha compositing (blending) of multiple volumes and/or segmented volumes into a single volume dataset in preparation for the Volume Rendering operation.

Volume Rendering generally consists of a number of steps, many of which are parametrically specified in the Volume Rendering SOP Classes. Steps that are usually implemented by proprietary algorithms are not described in this supplement, and are implementation-specific. The processing steps are:

  • Segmentation, or separating the volume data into groups that will share a particular color palette. Segmentation objects are specified as inputs to the Volumetric Presentation State. 95 - Gradient Computation, or finding edges or boundaries between different types of tissue in the volumetric data. Gradient Computation used is an implementation decision outside the scope of the Volumetric Presentation State.
  • Resampling of the volumetric data to create new samples along the imaginary ray behind each pixel in the output two-dimensional view, generally using some interpolation of the values of voxels in the 100 neighborhood of the new sample. The interpolation method used is an implementation decision outside the scope of the Volumetric Presentation State.
  • Classification of ray samples to assign a color and opacity to each sample. Classification parameters are specified in the Volumetric Presentation State.
  • Shading or the application of a lighting model to ray samples indicating the effect of ambient, diffuse, 105 and specular light on the sample. Basic lighting parameters are specified in the Volumetric Presentation State.
  • Compositing or the accumulation of samples on each ray into the final value of the pixel corresponding to that ray. The specific algorithms used are outside the scope of the Volumetric Presentation State.

The result of application of a Volumetric Presentation State is not expected to be exactly reproducible on different systems.

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 scope and field section of the supplement is still limited. There are plans to expand and to be more elaborate in future versions. A walkthrough of the definition and the steps was presented.

Working Group 6 advised to make it very clear in the scope and field section what is an addition on top of supplement 156. It should also be made clear which kind of volume rendering is offered by this supplement. It was advised against having a tutorial in general on volume rendering. Lastly the concept definitions, e.g. camera, camera coordination system, should be moved to a volume rendering concept definition section.

Currently the supplement supports color but not greyscale. It is an important question for the Public Comment phase if this is sufficient. A discussion on rendering, e.g. Geometry, lightning and display, concluded that there is a default application behavior for these aspects if they are not available in an instance of the presentation state object. After some debate it was decided to have three SOP classes for specialization or more general use:

  • Basic volume rendering
  • Volume rendering with segmentation
  • Full functionality

This is to avoid forcing every application to implement a complex pipeline. Details on functionality, e.g. cropping, is still an open issue when it comes to what is included in the basic SOP class.

View details »

Protocol Storage (CT)

Sup 121 80% Revisit Jan. 2015 Out for letter ballot

This Supplement defines a pair of storage SOP Classes to distribute planned CT protocols and to record performed CT protocols. Similar pairs of SOP Classes for other modalities may be added in other supplements.

  • a Defined Protocol SOP Class that describes desired values (and/or value ranges) for various parameters of an acquisition and reconstruction procedure. Defined Protocols are independent of a specific patient. Defined Protocols are typically specific to a certain scanner model and/or version (identified by device attributes in the protocol), but model-non-specific protocols are not prohibited.
  • a Performed Protocol SOP Class that describes the values actually used in a performed acquisition. Performed protocols are patient-specific.

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.

The primary goal is to control the scanner, not to script the entire behavior of the department or scan suite.

Formal coding and management of instructions may be handled with other objects and services such as the Contrast Injection SR or the Unified Procedure Step (UPS).

It 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 be able to run a protocol from another scanner.

New material added to the supplement was presented. Content Qualification and new services for Query and Retrieve have been added:

  • FIND
  • MOVE
  • GET

There is no SOP Class specific behavior for these services.

The supplement was voted to go out for Letter Ballot voting.

View details »

Webservices Redoc

Sup 183 40% Revisit Jan. 2016 Next Step public comments

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.

There has been much work done to separate resources and representation within the re-documentation initiative. A discussion on the use of hast tags for keeping identifying information during subscription use cases took place. E.g.

  • A user 1 subscribes to notifications with his credentials.
  • At some point user 1 needs to pass the stream of notifications to user 2. User 2 of course has his own set of credentials unknown to user 1.
  • User 1 can handover the stream to user 2 with the help of a hash tag based security credentials model.

An overview of the subscribe transaction model was presented.

An elaboration took place on Protected Health Information (PHI) and Personally Identifiable Information (PII). The advice was to use the term de-identified. The overall advice was to be consistent with Part 15, Individual identifiable).

View details »

Patient RDSR

Sup 191 40% Revisit Jan. 2016 Next step public comment

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 sufficient 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 (PRDSR) 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.

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.

A major change to the supplement were presented. The patient radiation dose SR IOD template has become more generic. A discussion took place regarding the concept of Quality Factor. When calculations are made with a certain methodology for organs and the quality factor is different, then this should be made more explicit.

The advice from Working Group 6 was to always be explicit when values are estimated. Further advice was to move sections as high up as possible in the templates. E.g. if a sequence holds info on a group of organs, then it should be a sibling to the organ container. The sibling should be found very close the starting tag of the organ container in the DICOM sequence of tags.

Working group 6 advised to use TDID 300 as an inspiration and to use the appropriate parameters from there. A cut down version should be used for Dose Estimation Parameters. There were strong arguments from the supplement author for keeping the full functionality. An important open question for the Public Comments is if the flexibility within the parameters is just right.

View details »

Webservices Notifications

Sup 193 20% Revisit Jan. 2016 Initial presentation

A slide set with the concepts and basic ideas was presented.

The ideas comes from cache management for internet resources. The author proposed to add conditional create, retrieve and update to optimize and to ensure consistent updates. The concepts foresees the use of entity tags with the following aspects:

  • Meta data based
  • Observing resource state
  • Test mechanism for preconditions
  • Uniqueness for one state of the query context, e.g. Study

If the entity is unchanged then execute the operation.

The intention is to avoid inconsistencies and cache problems.

The supplement stays in before public comments.

View details »

CPack 83

WG-06 approved Final Text in November 2015

1364 Minor corrections to WADO-RS and STOW-RS 1431 Add Beam Effective Dose in RT Fraction Scheme Module 1432 Add Support for Ion Therapy Scanning Modes 1451 Remove retired Point Index List attributes in PS3.5 Annex A 1452 Correct Recommended Presentation Opacity explanation 1457 Identification of groups of pre-clinical research small animal subjects 1463 Clarify Enhanced US Volume Image and Frame Type Values 3 and 4 1464 Add reference region segmentation property type 1465 Add type of finding to measurement SR templates 1466 Add session to measurements group 1467 Correct time point context relationship 1468 Add defined CID for modality in image library 1469 Remove duplicate rows referencing source image or series for segmentation in volumetric ROI 1470 Small animal anatomy for pre-clinical research 1471 Generalize clinical trials attributes to refer to any type of research 1472 Additional responsible persons 1473 Transverse positioning of pre-clinical research small animal subjects 1475 Add patient defined term for Ultrasound Acquisition Geometry 1477 Angles for Positioner with Digital Detector 1478 Identification of species and strain of pre-clinical research small animal subjects 1480 Allow multiple items in the MR Receive Coil Sequence 1486 Add RT Ion References 1487 Add Display Origin Coordinates To RT Plan 1488 Clarify RT Image Exposure Attributes in case of MPEG Encoding 1489 Correct description of Surface Scan IOD 1490 Update top level DICOM diagram for Web Services 1491 Incorrect terms in Part 18 Sections 8.2.5 and 8.2.6 1506 QIDO-RS maximumResults

CPack 84

Current set for January 2016 Final Text.

CPack 85 candidates

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