Here are the summary notes from the most recent DICOM
Base Standard Meeting (WG-06) including associated official
WG-06 meets five times a year to do technical review and harmonization of the output from the 31 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).
Existing radiotherapy IODs were designed to provide a set of containers for use in communicating radiotherapy data of all types, in a generic and flexible way.
The radio therapy planning and treatment recording is stored in a complex set of DICOM objects (the RT model). The RT Course is a top-level container including planned treatments from RT Prescriptions for a defined tumor or group of tumors. A patient undergoing treatments of radiotherapy has one treatment course at a time.
In a course there are one or more treatment phases. Each phase consist of one or more RT Treatment Sessions. An RT Treatment Session is delivered in one patient visit to a venue with a treatment machine and will typically deliver a fraction of one or more RT Radiation Sets.
A new RT Course is necessary when a tumor re-occurs or a new tumor is found, typically after a period of a year or more after the previous RT Course has been finished. The RT Course contains information necessary to prepare, conduct and review the treatment.
The RT Course is a dynamic object that represents the current status of the patient's treatment with necessary references to previous important information. Where possible, use has been made of new and powerful approaches, such as 3D segmentation, mesh representation, rigid and deformable registrations.
Workflow Management: The concept of workflow management using Unified Procedure Step has been fully integrated into the new IODs.
There was a discourse into how specific or generic to structure dosimetric objectives. After a longer discussion it was decided to go with a more rigid and descriptive structure.
The initial idea was to use loose coupling via indexing numbers and coded strings, but it was agreed upon that this would be fragile and that it might lead to interoperability issues. The index indirection was removed to make the structure simpler and more robust.
The variation of "kind of dose" object is expected to grow with new kinds in the future.
Different aspects were considered in detail:
There was a debate on the difference between the types: arbitrary volume and segment combination. The main motivation of having these two types is to have an "other" possibility for the user.
The supplement was approved for frozen draft final text. This state is intended to be used for prototype implementation. The insights gained from these implementations will be used to improve the frozen draft before final text approval.
This supplement introduces IODs that describe the administration of imaging agents.
The supplement applies to all modalities in which radiographic and ultrasonic imaging agents are introduced into a circulatory system in a controlled fashion (CT, MR, XA, US).
The new SOP Classes 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 administration of radiopharmaceuticals, which is addressed by R-RDSR.
The following template IDs were reviewed in detail: CIDs 9300, CIDs xx1, 2, 3, 4, 8, 9, 12, 17, 18, 19, 20, 21.
The different use cases for consumables were presented and the different purposes were discussed, for example billing or adverse event reporting.
It was highlighted that any valid EAN or UPC code can be used when the coding scheme designator equals these abbreviation.
There was an excursion into cartridges and their agent content.
There was no conclusion if this should be coded as an accessory with a contain property of the particular agent or separating the accessory and the agent description.
Further telephone conferences are scheduled to make the supplement ready for public comments.
This extension to the standard specifies web services for managing and distributing DICOM Information Objects, such as medical images, annotations, reports, etc.
It defines services and their APIs using the HTTP family of protocols. It is intended to be used for the distribution of medical imaging studies and related information to healthcare organizations, providers, and patients.
The longer analysis on query parameter values was held.
The main concern was how to handle unsupported query parameters.
The discussion concluded that if the parameter is supported but with an invalid value then a bad request response shall be sent.
Unsupported parameters are ignored as if they were not sent at all.
The next milestone for this supplement is to reach public comment.
This IOD describes how to blend multiple Parametric maps together with optional other images with a consistent color presentation.
Parametric Maps can be used to store the quantification of a specific measurement.
The Parametric Blending Presentation State defines the blending of the content of different Parametric Maps with an optional anatomical image as underlay, showing the measurements (like BOLD fMRI, Diffusion maps, CT/MRI Perfusion maps, FDG PET map) in relation to the anatomical structure.
Blending can be performed on any combination of Images.
The Supplement defines information that is needed to combine the different maps and show the combination. This way the user will be able to relate different items together, giving the opportunity to get a full overview instead of seeing every single item in isolation.
Displayed Area and Graphic modules are included to allow the user to add graphical information, for example, marking the Motor Cortex on the combined image.
The usage is described by using an example of an fMRI study in a new chapter in PS 17 as Informative Annex.
Then what's the walk-through and improvements on the attribute descriptions.
The supplement was voted to go out for letter ballot voting.
This supplement extends the family of Volumetric Presentation States by adding three additional SOP Classes to represent Volume Rendering Volumetric Presentation States:
Note that the technique of Surface Rendering, such as the rendering of Surface Segmentations or surfaces from the Optical Surface Scanner SOP Class, is not in the scope of this Supplement.
Volume Rendering is a data visualization method in which voxels (volume sample points) are assigned a color and opacity (alpha), and a 2D view is created by accumulating a set of non-transparent samples along a ray through the volume behind each pixel of the view. Ray samples are calculated by interpolating the voxel values in the neighborhood of each sample.
Volume Rendering generally consists of a number of steps:
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, the 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.
It was considered to remove AVERAGEIP as a rendering method as this rendering method is not commonly used.
An upcoming telephone conference in February is scheduled to complete all reviews and turn the document into final text by voting.
This supplement defines Restful Services (RS) for retrieving, storing, and searching for non-patient-related IODs such as hanging protocols, color palettes, procedure protocols, etc.
The transactions defined for this service are like those defined for the RS Studies Service. They allow a user agent to retrieve, store, and search for non-patient-related IODs from an origin server in DICOM Media Types.
Generic Web security mechanisms are fully compatible with Restful Services. PS3.14 discusses security.
Since image IODs incorporate the patient/study hierarchy, images of phantoms, QC targets, doorknob swab photos, etc., are expected to be handled as pseudo-patients rather than Non-Patient Instances. Pseudo patient identities will be created to track phantoms, QC targets, etc.
There were improvements in the scope and field done.
After a detailed document walk-through, the supplement was voted into final text.
This Supplement defines Storage SOP Classes to enable en face angiography images based upon ophthalmic computed tomography (OCT) technology.
En Face angiography images are derived from images obtained using OCT technology (i.e., structural OCT volume images plus angiographic flow volume information).
With special image acquisition sequences and post hoc image processing algorithms, OCT angiography detects the motion of the blood cells in the vessels to produce images of blood flow in the retina and choroid with capillary-level resolution.
OCT angiography technology enables a high resolution visualization of the retinal and choroidal vascular network to detect the growth of abnormal blood vessels.
The meeting came to the conclusion that real world value mapping is currently with available technology not useful. It is possible to detect motion but not to put units on it. It will still be included as it is anticipated to be used with future levels of technology.
A new module has been created parallel to the surface mesh module. This is called enhanced surface module. The idea is to support encoding of several services together with an image.
The proposal from working group 6 was instead to create specialization of the OPT sop class and have the surface meshes as separate but linked objects.
There was a debate on how to extend modality defined terms. The base standard group argued strongly to keep to only OPT as a modality and to codify the type of OPT within the series description, e.g. En face or B-scan.
The very illustrative example of the creation of the different OPT objects was presented as described in figure C.8.xx and the corresponding stages.
It was clarified that if a device calculation is done, then it shall be included instead of optionally included.
Further the color profile ICC is included as optional.
The supplement was agreed ready to go out for letter ballot voting.
This supplement retires the WADO-WS Web Service from the Standard. The functionality provided by WADO-WS is now included in and enhanced by DICOMweb, which seems to be much better accepted by the development community. WADO-URI and WADO-RS remain part of the Standard.
Retirement does not imply that these features cannot be used. However, the DICOM Standards Committee will not maintain the documentation of retired features. The reader is referred to earlier editions of the Standard.
The use of the retired features is discouraged for new implementations, in favor of those alternatives remaining in the standard.
The DICOM Standard will not reuse Data Element tags and UIDs that would conflict with retired services.
The scope and field section was improved with the information of what retiring means.
The supplement was voted to go out for letter ballot voting.