Near Real Time communication - DICOM
This is a discussion on Near Real Time communication - DICOM ; As a novice in the field, I am looking for a near real-time standard of
medical systems communication? Is there such a standard or is there any
work done in one of the dicom workgroups to support this type or
...
-
Near Real Time communication
As a novice in the field, I am looking for a near real-time standard of
medical systems communication? Is there such a standard or is there any
work done in one of the dicom workgroups to support this type or
capabilities?
Thanks
Assaf
-
Re: Near Real Time communication
Mayby you could better define what you mean by "near real-time".
DICOM provides a means to transmit images between different systems. It
is most widely used as a standard network interchange between imaging
modalities (image generating) devices and image storage/display
systems; but the standard doesn't define the timing of those
interchanges. It can be/ often is employed in "near real time" mode.
For example, most ultrasound devices can be set up to transmit images
to a PACS or display workstation immediately upon image capture.
Typically a DICOM transfer is initiated for a complete object. When the
image acquisition is near instantaneous, a DICOM transmission upon
completion of each image acquisition can meet most people's definition
of "near real time", provided the display application contains logic to
make new images immediately available upon receipt. CT and MR scanners
also support similar transmission capabilities, meaning a
physician/radiologist can see the images in their viewing application
almost as soon as they are acquired
It becomes a little more problematic when you're talking video because
the capture time can run on for quite a long time, longer than the
window which one would normally associate with real time. Thus, the
model of transmitting an object after the acquisition is completed
won't conform most people's concept of near real time.
DICOM recently adopted MPEG2 as a recognized compression transfer
syntax. In theory, an image/video generating device could open a DICOM
communication transfer and begin transmitting a live or near live video
stream, continuing a single DICOM transfer until the acquisition
completed. Similarly the application receiving the DICOM data could
begin decoding the MPEG stream and make the data available as video
while the transmission continued. However, this generally runs counter
to the model used for DICOM transmissions. Also the DICOM protocol
doesn't provide any mechanisms for isochronous data delivery used in
streaming video formats.
I say "in theory" because I've never seen any applications which
actually employ dicom in this manner. Could be they are out there
though.