Both are normally generated by the modality. The standard is silent on
the content of the fields, except for their value representation.

Series ID is often woefully abused by the modality vendors, many
assigning the value "1" to most/all series in the study. This makes it
not terribly useful as an index value for applications to do operations
such as sorting a presentation list of series in a study. Thus it is
also not unusually for Series ID values within a study to be coerced to
a different value (in cases where these things are done).

Study ID is different. Modalities usually generate Study ID, when they
generate them. Since Study ID has not been co-opted into a framework
for cross system integration or workflow, one would think it would also
be available to be coerced with some other identifier at the
convenience of the PACS/storage SCP. However, the modality console
application often uses maintains a hidden database of information about
studies it has previously acquired. This information is retained after
the study is no longer resident on the modality console. If the study
is returned to the modality console, the Study ID is the key that
database uses to look up information about the study. It may also be
used to keep track of CD, DVD, or MO disk where the study was backed up
from the modality (just in case that damn pacs vendor screws it up and
loses it). All these things are proprietary features - the standard
doesn't say what you do with it or how it is used. If you're a
modality, do whatever you please with your study id. If you're a
pacs/external app, change it at your own risk of screwing up whatever
the modality vendor intended it for.

Thank you eric,
I feel standard has to do something for this. Generating study ID at
the modality might lead to problems like One Study instance UID may
have multipe study IDs, i dont know wheather this is valid in standard.
eric.goodall@gmail.com wrote:
> Both are normally generated by the modality. The standard is silent
on
> the content of the fields, except for their value representation.
>
> Series ID is often woefully abused by the modality vendors, many
> assigning the value "1" to most/all series in the study. This makes
it
> not terribly useful as an index value for applications to do
operations
> such as sorting a presentation list of series in a study. Thus it is
> also not unusually for Series ID values within a study to be coerced
to
> a different value (in cases where these things are done).
>
> Study ID is different. Modalities usually generate Study ID, when
they
> generate them. Since Study ID has not been co-opted into a framework
> for cross system integration or workflow, one would think it would
also
> be available to be coerced with some other identifier at the
> convenience of the PACS/storage SCP. However, the modality console
> application often uses maintains a hidden database of information
about
> studies it has previously acquired. This information is retained
after
> the study is no longer resident on the modality console. If the study
> is returned to the modality console, the Study ID is the key that
> database uses to look up information about the study. It may also be
> used to keep track of CD, DVD, or MO disk where the study was backed
up
> from the modality (just in case that damn pacs vendor screws it up
and
> loses it). All these things are proprietary features - the standard
> doesn't say what you do with it or how it is used. If you're a
> modality, do whatever you please with your study id. If you're a
> pacs/external app, change it at your own risk of screwing up whatever
> the modality vendor intended it for.