Here are the summary notes from the most recent DICOM
Base Standard 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.
This Supplement specifies a new IOD to encode the results of an assessment by a person or device of the content of a DICOM SOP Instance. An assessment might be performed when the content of the SOP Instance could cause serious delays in clinical workflow, or outright harm to a patient, if the values are not consistent and safe. DICOM itself does not define the criteria for such assessments or the clinical workflow implications.
There was a final discussion on the mechanism for flexibility and constraints when the clinical user selects between values.
The Final Text was approved by WG-06. See the latest version of the standard for details.
This supplement extends the family of Volumetric Presentation States by adding three additional SOP Classes to represent Volume Rendering Volumetric Presentation States:
Volume Rendering is a data visualization method in which 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 voxel 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.
The processing steps are:
The open issue "location and color of the light source" was explained. Especially within ultrasound there are several different light source models. The goal is to get as much look alike as possible between different implementations.
From the public comments an optional global bounding box cropping alternative was added. When used it avoids multiple item by item cropping.
On which level of granularity to search within a presentation state and its references was discussed. It was considered important to be able to search on much smaller parts than the complete referenced data set. It was suggested to keep the references in a sequence for fine granular access.
New added use cases were presented:
It was agreed to remove spatial registration as a component in the rendering pipeline. Resample should take place implicitly whenever needed.
It was also agreed that CT/PET blending is out of scope for the current SOP classes.
The supplement was agreed to be ready to go out for Letter Ballot voting.
The Supplement was approved to send for Letter Ballot voting. It may become Final Text the week of May 30.
This supplement introduces a simplified SR template for Adult Echocardiography measurements.
It provides similar content to that of TID 5200 while addressing details that were the source of interoperability issues; in particular, varying degrees and patterns of pre- and post-coordination, multiple codes for the same concept and numerous optional descriptive modifiers.
The new template is driven significantly by current ASE Guidelines and Standards.
The supplement was previously approved for Letter Ballot in Sept 2014. It was held up awaiting necessary among others 200+ LOINC Codes. The codes are now all available. The supplement will be sent out for Letter Ballot voting at the end of March.
The supplement was sent for Letter Ballot voting.
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 Classes are:
The SOP Classes address details including:
The primary goal is to set up 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 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.
The level of publicizing private vendor specific attributes was debated. It was concluded that all private attributes including VR and VM attributes should be described. The corresponding paragraph will be added to part 3 of the standard. "Should" means that this is the recommended level of documentation but it is not mandatory.
The concept of equipment specific model group was introduced. It includes manufacturer model group and software version.
Working group 6 suggested to remove acquisition technique and reconstruction technique as they are duplications from the referenced images and can be retrieved from there.
Further working group 6 recommended to make patient specification conditional and type 1. It is required if there are any constraints on the patient characteristics.
WG-06 will continue refining the Final Text content. It may become Final Text the week of May 30.
This supplement addresses the need for a new generation of IODs and processes required for use in Radiotherapy.
The IODs defined represent a base for a set of Second Generation Radiotherapy specific IODs. This document describes the general concepts and architecture for the whole set of IODs.
The relation and concept between phases and interval fractions within treatment planning was presented and discussed. The graphics in the prescription module illustrated the relationships very well.
The advantages and draw backs using notes or tag descriptions were articulated. The general guidance was to use tag descriptions when it is a textual description.
A detailed exploration of life time radiation dose was done. It was made up of dosimetric objective evaluation and prior dose inclusion.
WG-06 will continue to finalize the text of the Supplement to issue for Trial Use. Thereafter the RT industry will conduct trial implementations for about two years.
The following SOP Classes are introduced to 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.
This supplement defines SOP Classes and IODs for persisting and communication of information relevant to the administration of imaging agents used in medical imaging examinations. Furthermore, the supplement is constructed so as to convey planned and delivered Imaging Agent administration using manual methods and automated power-injector devices.
A discussion concluded that the date and time attribute shall be made optional. This avoids several complications.
It was elaborated on which codes can be reused from SNOMED, which can be reused from other coding sources and which have to be defined in the supplement.
WG06 identified commonalities between Radiopharmaceutical RDSR (RRDSR) and supplement 164, it was agreed to factor out selected RRDSR templates for reuse purposes.
WG-06 will continue to review the supplement before issuing for Public Comment.
This supplement focuses on concepts surrounding task-based fMRI. These are generalized from the shared clinical and research experience of the QIBA-fMRI. This was done with the intend to be able to create the DICOM object and relationship definitions as well as procedure steps describing the workflow, inputs, and outputs of functional assessment with imaging.
The Paradigm is the set of stimuli that will be given to the patient combined with timing and other instructions needed for the correct execution. The type of stimuli will depend on the subject of the study (Motor, Hearing, Vision, Language, Cognitive, Memory, etc.) and can be images, sounds and all kind of tasks.
The current 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. This also capture the workflow and data items like paradigms used during the functional assessment.
The fMRI workflow consists of the following steps:
Slides were presented to illustrate the proposed Color Palette using LUT concept. The idea is to use a segmented palette color lookup table, where the RGB values are defined. The RGB values in the lookup table are constant in an interval or they are increasing or declining linear in an interval.
The supplement will be further worked on before submitting for review before issuing for Public Comment.
This supplement defines Restful Services (RS) for retrieving, storing, and searching for non-patient related objects such as hanging protocols, color palettes, procedure protocols, etc.
The transactions defined for this service are very similar to those defined for the RS Studies Service. They allow a user agent to retrieve, store, and search for non-patient related objects from an origin server in DICOM Media Types.
Security is beyond the scope of the RESTful services defined in this supplement. However generic Web security mechanisms are fully compatible. Working group 6 advised to treat these IODs as any other as far as possible. As there are cases where non patient data is huge, e.g. implants, both inline and bulk data mechanisms shall be possible.
The current variants of instances are:
The supplement will be further worked on before submitting for review before issuing for Public Comment.
This supplement describes new Transfer Syntaxes to embed High Efficiency Video Coding (HEVC) in DICOM. It does not introduce any new SOP Classes or IODs.
HEVC allows two new major enhancements of the DICOM standards:
The use of video and still image data in the medical industry has increased and new technologies providing better colors or higher precision are available on the market. Meanwhile, the needs for reduced storage and media exchange cost remains important. To answer the related demand for higher compression efficiency, this supplement proposes to add new profiles for:
The benefits over JPG2000 for iterative transmission were discussed. Bad network performance is better with HVEC. Decoding load is comparable but encoding has a higher load for HVEC. H.265 (HVEC) is about 2 times more efficient than H.264.
Working group 6 advised to add more motivation such as:
It was decided to split the supplement in two parts. One for the 4:2:0 profiles and one for the 4:4:4 scalable lossless.
It was touched upon that HEVC is affected by two pools of patents. There are royalties to pay for when buying or using HEVC codecs. The pools are called MPEG-LA and HEVC Advance.