Hello,

I have see to store in pacs many software encapsul image ( scan,
report .....) in DICOM files.
SOP class dicomencapsuled pdf is not allways supported by pacs. So ok
i can push all visual( image) data in a SC.

But  about no visual data.
I have read than some software create SC wihout image but only whit
private data ( review result, cad result, binarie data , ect...). The
goal, ( supposed) send to the pacs a supported SOP class only useable
by a specific software.

so my question are:

1) is it a good/acceptable practice ( create SC wiht private data ,
wihout image) to be able to push DICOM in every PACS

2) if  yes can i just  insert data in tag (7fe0,0010) or must i add
private tag wiht my data and leaving pixel tag empty ?

3) if no any suggestion ?

3) i have never used or create private tag . they are rules ? free tag
unused ?

Thanks

Hello zurp,

have a look if really there is no IOD in the Standard for the data you
want to store.

There is also Encapsulated CDA in DICOM Part 3 (PS3.3-2008 chapter
A.45.2), and RAW Data IOD (A.37).

zurp wrote:
> 1) is it a good/acceptable practice ( create SC wiht private data ,
> wihout image) to be able to push DICOM in every PACS

This is very *bad* practice. See below, why.

I know there a bad habit crept in not to use Standard IODS (that might
not be supported by your favorite PACS yet) but to use a SC container
instead and even to attach unrelated bogus Image Pixels (like company
logos ;o) to non-Image Instances - or even worse the use private IODs -
please do not do this.

But, as the Standard is evolving, new IODs will be defined, so most PACS
already have a parametrization option to add new IODs - many vendors can
do the trick at runtime. So I would prefer to lobby the PACS vendor into
supporting the new IOD instead of botching your new application right
from the start.

If there is an appropriate IOD, _use it_. If there is none, use a RAW
container (and think about switching to an appropriate IOD later, as
soon as this is "invented").

The overuse of SC as container would have one clear point of
convergence: we dump all of the fuzzy nutsy IODs and put it all in SC
containers, as they are so nice and easy to handle. This is what I would
call DICOM in a bondage suit!

> 2) if  yes can i just  insert data in tag (7fe0,0010) or must i add
> private tag wiht my data and leaving pixel tag empty ?

=:-o No, Please, *do* *not* *abuse* *(7FE0,0010)*!  *Never* *ever*!

(7FE0,0010) lives in the context of a Pixel Data Module, some Viewers
might try to display these "Image Pixels" and fail. And the shame will
be on you!

See DICOM Raw Data for an all purpose Container - this will also put you
in full charge and responsibility of maintenance, so use it with
prudence. No Pixel Data Attribute if there arte no pixel data, full stop.

Please consider if there really is not an appropriate Container IOD (or
maybe Waveform, Report, Encapsulated Data, or whatever IOD) already in
the Standard for what you are planning.

If there is none, look at the Supplements: maybe there is a new IOD
under discussion, then you may use a makeshift DICOM Raw Object and
prepare for easy transition the day the Supplement is released (Caution:
Do never use "new" DICOM Standard Attributes that are not yet
released!). Use private Attributes in your Raw Data IO and prepare them
to be copied to the Standard Attributes as soon as the Supplement is
released instead. This gives you a fine reason to sell a new version
upgrade of your application ;o)

> 3) i have never used or create private tag . they are rules ? free tag
> unused ?

The Mechanism is rather easy and automatically avoids collisions. It is
explained in PS 3.5-2008 chapter 7.8 "PRIVATE DATA ELEMENTS".

In a nutshell:
1) select a group where you want to have your private attribute, e. g.
"(0019,xxxx)"
2) look for the Attributes in (0019,xxxx) beginning at (0019,0010) and
above. Lets say, you find:
(0019,0010) "SOOPER DOOPER SCANNER CORP"
(0019,0011) "Mediprint Desintegration Server"
(0019,0012) "Scandalous System OBFUSCATE 2000"
no more attributes start with (0019,00xx), and the next Attribute you
find is (0019,1010) "V1.0ALPHA"

So you may queue your Private Creator Attribute in the next free slot of
(00019,00xx) and add
(0019,0013) "ZURP SYSTEMS ZURPIFYER 1.0"

Now, that's all for (0019,00xx).

The Rest of the 0019 group in the Instance (!) has the following "owners":

(0019,1000) - (0019,10FF) belongs to "SOOPER DOOPER SCANNER CORP"
(0019,1100) - (0019,11FF) belongs to "Mediprint Desintegration Server"
(0019,1200) - (0019,12FF) belongs to "Scandalous System OBFUSCATE 2000"
and
(0019,1300) - (0019,13FF) belongs to your "ZURP SYSTEMS ZURPIFYER 1.0"

Any Instance may have different layouts of private contributors. Never
rely on always having (0019,0013) for your stuff available! Note, that
you might also have your same information at (0019,17xx) if there would
have been more Private Creators in the Dataset already! If your parser
or creator fails on this, it will fail anyway sooner or later and leave
you as the culprit that messed up other people's data.

3) add your private Attributes to the range reserved to you, and do not
forget to document them as described below.

4) always try to use DICOM VRs other than OB/OW for any structured data
- BLOBs in OB/OW are a fatal idea, as there is an external structure
definition blending into the DICOM structure - this will cost you plenty
of time, nerves and programmers karma to keep them both consistent. So
instead of using a BLOB of Integers for an array, use a sequence of
integers. Instead of using a BLOB with XML (I have seen that already!),
resolve the primitives in the XML to proper DICOM.

5) document the privatizations in your Conformance Statement. At least
the Private Creator String, the Attribute Number, VR and a name to refer
to should be there ("(0019,xx23) SH Special Reconstruction Parameter
#1"). If you are afraid to give away your intellectual property to
competitors, use obfuscated names for the attribute instead of not
documenting it (like in the Example: "Special Reconstruction Parameter
#1", "Special Reconstruction Parameter #2" or the like).

Okay, this was a bit more lines than I expected, but I hope it was at
least a little helpful.

Yours,


Peter

Thank you for your very detailled responce, it is helpfull.

If i understand all, an without mistake.

In regard of you responce, DICOMrawdata  is exactly what i need it
look perfect, specialy if i want send to pacs private cad  data
result.

But unfortunately...

The statement of pacs (i can not use an other) give me,the following
list of sop UID  supported by the standard storage sop class

1.2.840.10008.5.1.4.1.1.1 (CR)
1.2.840.10008.5.1.4.1.1.2(CT)
1.2.840.10008.5.1.4.1.1.3(retUS)
1.2.840.10008.5.1.4.1.1.3.1(US MF)
1.2.840.10008.5.1.4.1.1.4 (MR)
1.2.840.10008.5.1.4.1.1.5 (retNM)
1.2.840.10008.5.1.4.1.1.6(retUS)
1.2.840.10008.5.1.4.1.1.6.1 (US)
1.2.840.10008.5.1.4.1.1.7 (SC)
1.2.840.10008.5.1.4.1.1.12.1 (XA)
1.2.840.10008.5.1.4.1.1.12.2 (RF)
1.2.840.10008.5.1.4.1.1.12.3 (RF-BP)
1.2.840.10008.5.1.4.1.1.20 (NM - MF)
1.2.840.10008.5.1.4.1.1.1.1 (DX-Prs)
1.2.840.10008.5.1.4.1.1.1.1.1 (DX-Proc)
1.2.840.10008.5.1.4.1.1.1.2 (MG-Prs)
1.2.840.10008.5.1.4.1.1.1.2.1 (MG-Proc)
1.2.840.10008.5.1.4.1.1.1.3 (IO-Prs)
1.2.840.10008.5.1.4.1.1.1.3.1 (IO-Proc)
1.2.840.10008.5.1.4.1.1.128 (PET)
1.2.840.10008.5.1.4.1.1.481.1 (RTIMAGE)
1.2.840.10008.5.1.4.1.1.77.1.1 (ES)
1.2.840.10008.5.1.4.1.1.77.1.2 (GM)
1.2.840.10008.5.1.4.1.1.77.1.3 (SM)
1.2.840.10008.5.1.4.1.1.77.1.4 (XC)
1.2.840.10008.5.1.4.1.1.7.2 (SC-MF-Byte)
1.2.840.10008.5.1.4.1.1.7.3 (SC-MF-Word)
1.2.840.10008.5.1.4.1.1.7.4 (SC-MF-Color)
1.2.840.10008.5.1.4.1.1.88.50 (MG CAD
SR)

And i must use this pacs. I have also look statement of differant PACS
and dicom raw data is not allways supported
1.2.840.10008.5.1.4.1.1.66.

have you a suggestion , ??

Thanks

Hello zurp,

zurp wrote:
> [...] i want send to pacs private cad  data
> result.

This is a hint in the direction of Structured Reports:
1.2.840.10008.5.1.4.1.1.88.50 Mammography CAD SR Storage
1.2.840.10008.5.1.4.1.1.88.65 Chest CAD SR Storage
1.2.840.10008.5.1.4.1.1.88.69 Colon CAD SR (Supp. 126)

where the first in the list already is supported.

See the IODs in PS3.3-2008 chp. A.35.5 Mammography CAD SR I, chp. A.35.6
Chest CAD SR, released Supp 126 Colon CAD SR.

Also, did you have a look at PS3.3-2008 A.35.7 Procedure Log Information
Object Definition (1.2.840.10008.5.1.4.1.1.88.40)?


> And i must use this pacs.
Is the software experimental and user specific? Or does it have clinical
relevance? If so, you should be aware that the radiologists have to be
able to reproduce their findings in case of a discussion, which requires
it to be reproduced many years after the study was performed in most
countries.

> I have also look statement of differant PACS
> and dicom raw data is not allways supported
> 1.2.840.10008.5.1.4.1.1.66.

Yes, it is a "modern" IOD, introduced in Supp. 49 as recently as March
2002... ;o)

However, some PACS I have seen have parameterizable association
presentation context tables for Storage Service, so maybe it is possible
to add support to a running system.

> have you a suggestion , ??

Well, maybe you should clarify the use case and decide whether to use
some new privatization or not. Just some questions that may make the
case clearer:

Is there a vendor's representative at hand you might ask if it is
possible to add DICOM Raw (or CAD SR or Procedure Log) Support? The list
of your PACS looks a bit short for a fully fledged modern PACS,
especially on the non-Imaging side. Maybe there is an update available?

As said in my previous post, it is a really bad idea to
abuse^H^H^H^H^H^H privatize an IOD when a matching IOD is defined
already. What scope of usage does your projected application have? If
you spread it into the wild, you will have to maintain all the
privatizations for all installations for the duration of the patient
data lifecycle...

Are the privatizations relevant for the findings? Is the information
reproducible from the Standard information?

If in 30 years a finding is to be discussed, the information has to be
available the physician had when she made the study.

If nobody can read the data anymore, the physician might get into trouble.

If you upgrade your product and the data is not displayed any more, your
customers will not be amused...

Just consider these points before adding another privatization to the
list already too long ;o)

I know it is tempting to just add some privatizations to existing
supported objects instead of introducing an all new IOD, but you should
do it deliberately and you should be clear about the consequences - you
might create a monster that is after you for years!

I hope this helps you a little. Have a nice weekend!


Yours, Peter