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 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:
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.
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.
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
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.
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.
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:
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:
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.
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.
The SOP Classes address details including:
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:
There is no SOP Class specific behavior for these services.
The supplement was voted to go out for Letter Ballot voting.
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.
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.
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).
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.
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:
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.