multiple application profiles in a single dicomdir?

[tclune]

A while ago, I asked on comp.protocols.dicom about multiple application profiles. Dr. Clunie appeared to say (I may have misunderstood) that you could use multiple application profiles on a single CD, which I interpreted as saying that a single dicomdir could contain files that conformed to more than one application profile. I now find that I need to use that if it is, indeed, part of DICOM. I notice that the dcmtk docs say that, when you open a dicomdir for appending new files, you should specify the same application profile that you used before.

So, is it legal to have a single dicomdir with multiple application profiles? If so, does dcmtk support this? And if so, how? TIA.

[Marco Eichelberg]

It is legal in DICOM but very unusual in practice, and "outlawed" in IHE PDI and the German DRG Requirement Specification for Patient CDs.

It is not officially supported in DCMTK - it may or may not work.

The problem is that with a mix of application profile it becomes difficult to decide (or even undecidable) which directory record conforms to which profile. Typically a medium implementing a mix of two profiles will seem non-conformant to readers supporting either profile.

I'd be interested to know about your use case for using multiple application profiles on one CD - is there something that STD-GEN-CD or STD-GEN-DVD-JPEG does not cater for?

[Jörg Riesmeier]

It is not officially supported in DCMTK - it may or may not work.

This is true for the official release DCMTK 3.5.4 but not for the current snapshot

Code: Select all

  +U    --update
          update existing DICOMDIR

From the man page:

The dcmgpdir utility also allows to append new entries to and to update existing entries in a DICOMDIR file. Using option +A new entries are only appended to the DICOMDIR, i.e. existing records like the ones for PATIENT information are not updated. Using option +U also existing records are updated according to the information found in the referenced DICOM files. Please note that this update process might be slower that just appending new entries. However, it makes sure that additional information that is required for the selected application profile is also added to existing records.

Tom, your feedback on this particular feature is welcome ...

[tclune]

Thanks, Jorg. I'll try to give you feedback as soon as I can, but I'm in "crunch mode" right now, and I may not be able to respond appropriately for a month or so. Marco, the thing that is the "odd man out" in most options is either RLE compression support or structured reports. Internally, we generally save our data as palettized RLE -- a nightmare when we deal with the rest of the world, but the right choice if we didn't have to contend with anyone else...

[edited because I finally downloaded the current standard, and find that it gives me more than it used to on the ultrasound profile] The only remaining "gotcha" is that the strutured reports are not defined in the ultrasound profile, and RLE compression is not defined in the std gen profiles. So I'll need to add the std gen profile to support structured reports on the archives tht include the ultrasound images.

--Tom Clune