Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DICOM vs .. "raw DICOM" ?

1,686 views
Skip to first unread message

Trevoke

unread,
Nov 24, 2009, 1:54:27 PM11/24/09
to
I'm looking at this sentence:
"Access and store images in DICOM or raw data DICOM formats to meet
medical digital communication standards "
It comes from here: http://www.gehealthcare.com/euen/ultrasound/ultrasound-it/echopac-pc/index.html

And all I can think is .. "Wait, what?" What exactly is the
difference? What do they _mean_ ?

Peter B Schmidt

unread,
Nov 24, 2009, 4:15:37 PM11/24/09
to
Hello Trevoke,

Trevoke wrote:
> "Access and store images in DICOM or raw data DICOM formats to meet
> medical digital communication standards "

DICOM or raw DICOM... wait, _what_? ;o)

> What exactly is the
> difference? What do they _mean_ ?

Probably the author of this sentence is referring to storage of private
information as DICOM Raw Data IOD. Just guessing: This may refer 3D
Ultrasound data which is described in Supplement 43.

Supplement 43 was released in April 2009 and defines:

Enhanced US Volume Storage 1.2.840.10008.5.1.4.1.1.6.2
Arterial Pulse Waveform Storage 1.2.840.10008.5.1.4.1.1.9.5.1
Respiratory Waveform Storage 1.2.840.10008.5.1.4.1.1.9.6.1
General Audio Waveform Storage 1.2.840.10008.5.1.4.1.1.9.4.2

Maybe Supp. 43 was released too late for the device discussed on this
page to make its objects Supplement 43 compliant. Thus it stores the
"modern" data objects not in Enhanced Ultrasound IOD but as DICOM Raw
Data instead.

DICOM Raw Data IOD has the advantage over private IODs that Storage and
Retrieval can be ensured in a "Store-and-Forward" manner without having
to support an extra (private) IOD.

A PACS for instance only has to support DICOM RAW Data IOD (PS3.3-2008
A.37, SOP Class UID 1.2.840.10008.5.1.4.1.1.66).

The RAW Data IOD is a container for privately encapsulated data, i. e.
besides the Patient/Study/Series/Frame of Reference/General Equipment
information, all data is privately defined. But the PACS can rely on the
presence of the 4 or 5 modules above and thus provide the data
appropriately to an application requesting it, even if the PACS itself
cannot interpret the rest of the data object.

It would be nice to see the Supplement 43 Enhanced US IODs supported,
but we should not slam a vendor for not supporting a supplement that has
been released last April in a Product that was released in 2006 (!) and
may well have had years of effort to develop.

Supplement 43 was a tough one and took years itself.

In a nutshell: The RAW objects may not be the real McCoy to store
Ultrasound data now as Supplement 43 is released, but at least, a decent
PACS should be able to store and retrieve it, so the US application in
the box is able to resume work on it.

Maybe the vendor is even storing information in RAW Data IOD that is not
covered by DICOM by now, so using Raw IOD might be a plus somehow... as
long as you have the box still up and running...

My EUR 0.02,


Peter

David Clunie

unread,
Nov 25, 2009, 1:55:46 PM11/25/09
to
I believe GE ultrasound products currently store their raw
data as a private data element inside a standard DICOM
ultrasound image object.

This feature can be turned on and off by configuration.

See, for example, the EchoPAC Dimension DICOM Conformance
Statement at:

"http://www.gehealthcare.com/usen/interoperability/dicom/docs/EY141MSC__DicomConformanceStatement.pdf"

The entire Ultrasound product family's statements can be
found here:

"http://www.gehealthcare.com/usen/interoperability/dicom/products/ultrasound_dicom.html"

David

0 new messages