Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DICOM 3.0 Edition Backward compatibility
76 views
Skip to first unread message
Anand
Jan 16, 2012, 1:59:47 AM1/16/12
to
I am facing challenge in DICOM transfer of DICOM 3.0 older edition.
Can a Storage SCU developed in conformance to PS 3.x-2001 & supporting NM IOD defined in PS 3.3-2001 do a DICOM transfer to Storage SCP developed in conformance to PS 3.x-2009 & supporting NM IOD defined in PS 3.3-2009?
If no, then do i need to develop a broker in between & what are the areas i need to address in this broker such as IOD (missing attributes, type mismatch, VR/VM mismatch), the storage service implementation?
Thanks for the help in advance!
Can a Storage SCU developed in conformance to PS 3.x-2001 & supporting NM IOD defined in PS 3.3-2001 do a DICOM transfer to Storage SCP developed in conformance to PS 3.x-2009 & supporting NM IOD defined in PS 3.3-2009?
If no, then do i need to develop a broker in between & what are the areas i need to address in this broker such as IOD (missing attributes, type mismatch, VR/VM mismatch), the storage service implementation?
Thanks for the help in advance!
David Clunie
Jan 16, 2012, 6:58:23 AM1/16/12
to
Hi Anand
There is only one version of DICOM that one can claim conformance to,
and that is DICOM 3.
Each year (or so) we consolidate the additional features and the
corrections into one edition and publish it, but that does not
mean that once can claim conformance to that edition nor should
one.
Conformance is defined at the SOP Class level, and any changes to
SOP Classes are (almost) always in the form of optional additions
(except where there is something really broken).
So, any SCU or SCP that conforms to the NM SOP Class, regardless
of which year it was implemented, should be interoperable.
There should not be any mismatch in mandatory attributes, and
certainly not in type or VR or VM.
Any SCP should be prepared to encountered unrecognized standard
(and private) attributes that have been added to the standard
after the implementation has been deployed, so that should not
be a factor either (though they may be handled as having UN VR).
No "broker" should ever be necessary (at least not for this
reason).
The NM IOD has actually had very few changes (since the original
broken one was retired); the most important one I can think of
was the addition of the slice progression direction stuff (i.e.,
base to apex for short axis cardiac SPECT recons).
David
On 1/16/12 1:59 AM, Anand wrote:
> I am facing challenge in DICOM transfer of DICOM 3.0 older edition.
>
> Can a Storage SCU developed in conformance to PS 3.x-2001& supporting NM IOD defined in PS 3.3-2001 do a DICOM transfer to Storage SCP developed in conformance to PS 3.x-2009& supporting NM IOD defined in PS 3.3-2009?
>
> If no, then do i need to develop a broker in between& what are the areas i need to address in this broker such as IOD (missing attributes, type mismatch, VR/VM mismatch), the storage service implementation?
There is only one version of DICOM that one can claim conformance to,
and that is DICOM 3.
Each year (or so) we consolidate the additional features and the
corrections into one edition and publish it, but that does not
mean that once can claim conformance to that edition nor should
one.
Conformance is defined at the SOP Class level, and any changes to
SOP Classes are (almost) always in the form of optional additions
(except where there is something really broken).
So, any SCU or SCP that conforms to the NM SOP Class, regardless
of which year it was implemented, should be interoperable.
There should not be any mismatch in mandatory attributes, and
certainly not in type or VR or VM.
Any SCP should be prepared to encountered unrecognized standard
(and private) attributes that have been added to the standard
after the implementation has been deployed, so that should not
be a factor either (though they may be handled as having UN VR).
No "broker" should ever be necessary (at least not for this
reason).
The NM IOD has actually had very few changes (since the original
broken one was retired); the most important one I can think of
was the addition of the slice progression direction stuff (i.e.,
base to apex for short axis cardiac SPECT recons).
David
On 1/16/12 1:59 AM, Anand wrote:
> I am facing challenge in DICOM transfer of DICOM 3.0 older edition.
>
>
> If no, then do i need to develop a broker in between& what are the areas i need to address in this broker such as IOD (missing attributes, type mismatch, VR/VM mismatch), the storage service implementation?
Anand
Jan 16, 2012, 7:23:37 AM1/16/12
to
On Jan 16, 4:58 pm, David Clunie <dclu...@dclunie.com> wrote:
> Hi Anand
>
> There is only one version of DICOM that one can claim conformance to,
> and that is DICOM 3.
>
> Each year (or so) we consolidate the additional features and the
> corrections into oneeditionand publish it, but that does not
> Hi Anand
>
> There is only one version of DICOM that one can claim conformance to,
> and that is DICOM 3.
>
> Each year (or so) we consolidate the additional features and the
> mean that once can claim conformance to thateditionnor should
> one.
>
> Conformance is defined at the SOP Class level, and any changes to
> SOP Classes are (almost) always in the form of optional additions
> (except where there is something really broken).
>
> So, any SCU or SCP that conforms to the NM SOP Class, regardless
> of which year it was implemented, should be interoperable.
>
> There should not be any mismatch in mandatory attributes, and
> certainly not in type or VR or VM.
>
> Any SCP should be prepared to encountered unrecognized standard
> (and private) attributes that have been added to the standard
> after the implementation has been deployed, so that should not
> be a factor either (though they may be handled as having UN VR).
>
> No "broker" should ever be necessary (at least not for this
> reason).
>
> The NM IOD has actually had very few changes (since the original
> broken one was retired); the most important one I can think of
> was the addition of the slice progression direction stuff (i.e.,
> base to apex for short axis cardiac SPECT recons).
>
> David
>
> On 1/16/12 1:59 AM, Anand wrote:
>
>
>
>
>
>
>
> > I am facing challenge in DICOM transfer of DICOM 3.0 olderedition.
>
> > Can a Storage SCU developed in conformance to PS 3.x-2001& supporting NM IOD defined in PS 3.3-2001 do a DICOM transfer to Storage SCP developed in conformance to PS 3.x-2009& supporting NM IOD defined in PS 3.3-2009?
>
> > If no, then do i need to develop a broker in between& what are the areas i need to address in this broker such as IOD (missing attributes, type mismatch, VR/VM mismatch), the storage service implementation?
>
> > Thanks for the help in advance!
Thanks David, this is very helpful!
>
> Conformance is defined at the SOP Class level, and any changes to
> SOP Classes are (almost) always in the form of optional additions
> (except where there is something really broken).
>
> So, any SCU or SCP that conforms to the NM SOP Class, regardless
> of which year it was implemented, should be interoperable.
>
> There should not be any mismatch in mandatory attributes, and
> certainly not in type or VR or VM.
>
> Any SCP should be prepared to encountered unrecognized standard
> (and private) attributes that have been added to the standard
> after the implementation has been deployed, so that should not
> be a factor either (though they may be handled as having UN VR).
>
> No "broker" should ever be necessary (at least not for this
> reason).
>
> The NM IOD has actually had very few changes (since the original
> broken one was retired); the most important one I can think of
> was the addition of the slice progression direction stuff (i.e.,
> base to apex for short axis cardiac SPECT recons).
>
> David
>
> On 1/16/12 1:59 AM, Anand wrote:
>
>
>
>
>
>
>
> > I am facing challenge in DICOM transfer of DICOM 3.0 olderedition.
>
> > Can a Storage SCU developed in conformance to PS 3.x-2001& supporting NM IOD defined in PS 3.3-2001 do a DICOM transfer to Storage SCP developed in conformance to PS 3.x-2009& supporting NM IOD defined in PS 3.3-2009?
>
> > If no, then do i need to develop a broker in between& what are the areas i need to address in this broker such as IOD (missing attributes, type mismatch, VR/VM mismatch), the storage service implementation?
>
> > Thanks for the help in advance!
I was planning to compare the NM IOD from PS 3.3 - 2009 & PS 3.3 -
2001 to check for the missing attributes or VR, VM, Type mismatch, but
as you have rightly mentioned any changes to the IOD in a new edition
will only add optional attributes, no mandatory module attributes will
be changed.
I think the problem is in 2009 edition Storage SCP. Do you suggest me
to look for change in the PS 3.8 - 2001 to PS 3.8 -2011, the message
protocol has changed, hence the NM Storage SOP Class is not supported.
Thanks for your help in advance.
Regards,
Anand
David Clunie
Jan 16, 2012, 9:57:58 AM1/16/12
to
Hi Anand
There have been no significant changes in the message protocol (PS 3.8)
since DICOM was first published in 1993.
I presume you are having an actual problem with two products not working.
What exactly is the nature of the problem ?
David
> I was planning to compare the NM IOD from PS 3.3 - 2009& PS 3.3 -
There have been no significant changes in the message protocol (PS 3.8)
since DICOM was first published in 1993.
I presume you are having an actual problem with two products not working.
What exactly is the nature of the problem ?
David
> I was planning to compare the NM IOD from PS 3.3 - 2009& PS 3.3 -
0 new messages