An overview of the latest progress of the DICOM standard from the recent base standard meeting
This supplement adds the Modality Scheduled Procedure Step
Service and the Modality Performed Procedure Step Service
to DICOMweb to mirror the Modality Worklist (MWL) and
Modality Performed Procedure Step (MPPS) services that are
already available in DIMSE respectively.
The modality procedure step services have been designed
with the intention of facilitating proxies from/to
DIMSE.
This supplement was voted ready as Final Text and to be
incorporated into the next publication of the standard
(2025d).
This supplement to the DICOM Standard introduces new SR
template content to address fetal anatomy survey
assessments in ultrasound reports.
Specifically, a sub-template is added to TID 5000 along
with corresponding CIDs to address the anatomy of interest
and assessments for each.
Clinical guidelines from the International Society of
Ultrasound in Obstetrics and Gynecology (ISUOG) call for a
survey of fetal anatomy in the first, second, and third
trimesters to identify structural anomalies.
In Japan, JSUM guidelines call for first and second
trimester anatomical surveys
The guidelines identify specific lists of anatomy to
consider.
This supplement was voted ready to go out for Letter
Ballot.
This supplement adds the Send in DICOMweb to mirror the
Move Service that is already available in DIMSE.
The DICOMWeb Send services have been designed with the
intention of facilitating proxies from/to DIMSE.
This supplement will be further presented and
discussed in the base standard group before going
out for Public Comments.
This Supplement provides explanatory information on
the creation and usage of RDSR (traditional and
enhanced) within Angiography, Mammography,
Radiography, CT, Dentistry modalities etc.
This supplement excludes Radiopharmaceutical and
Patient Radiation Dose SR.
Given the modality-specific content definition of
the RDSR, and the many different types of system
configurations existing in the field, it becomes
challenging for the manufacturers to have a clear
understanding of the precise requirements for each
type of device.
The purpose of this supplement can be summarized as
follows:
- Give more information beyond the definitions
in PS 3.16: describe real-world scenarios of
typical equipment configurations, provide
examples and encoding guidelines;
- Indicate restrictions on the applicable
scenarios (defined terms recommended, values
ranges, recommended presence of Content
Items);
- Promote usage of optional Content Items
under particular scenarios;
- Assess the applicability for some
conditional Content Items under particular
scenarios;
The scope of the proposed Supplement includes:
- An overview of the landscape of different
modalities and types of equipment
configuration, from simple legacy CR to
modern integrated Angio equipment.
- Guidance on how to use the different TIDs
and Content Items depending on the modality,
equipment types and configurations.
This supplement will be further presented and
discussed in the base standard group before going
out for Public Comments.
This Supplement adds an updated Application Program Interface (API) to
DICOM PS3.19 and retires the previous SOAP API.
The use of this API will allow a client to request an Application to
perform work on given data.
This API was first proposed by the American College of Radiology’s
Data Science Institute (ACR DSI) and has since been extended by the
MONAI Deploy Informatics Gateway (MIG) for inference requests.
This API fills the gap in IHE’s AI Workflow for Imaging (AIW-I)
profile where a Task Performer (Proxy) communicates and exchanges
input data to perform inference and exchange results.
In the profile there are no defined transactions between the Task
Performer (Proxy) to request services from an AI Model (Proxied).
For the purposes of this supplement the Task Performer (Proxy) would
be considered a client and the AI Model (Proxied) would be an
Application.
Out of scope are all DICOM UPS-RS transactions as well as any exchange
of capabilities between a client and the Application.
Also there is no restriction on what role a client plays in the
overall workflow when using this API for requesting services of an
Application.
This supplement will be further presented and discussed in the base
standard group before going out for Public Comments.