RT Brachytherapy Delivery
Sup 184
80% Revisit Nov. 2015
Out for Letter Ballot
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.
View
details»
Preclin. Small Animal Acq.
Sup 187
80% Revisit Nov. 2015
Out for letter ballot
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.
View details »
CT Protocol Storage
Sup 121
60% Revisit Nov. 2015
After public comments
This Supplement defines two storage SOP Classes to distribute planned
CT protocols and to record performed CT protocols.
- The 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.
- The 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 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.
View details »
