At UM Rad Onc we push series to our PACS, and on occasion someone will
copy it from the PACS before the push has completed, and so they only
get part of the series.
It is possible that using an incomplete series could result in an
error in treatment, so we are interested in finding a way to keep it
from happening. One suggestion was to use the Storage Commitment
service class, but as I understand it, this only gives an
acknowledgement that the images have been stored, and that the
accessing of a partial series could still happen while the push was
underway.
Is my understanding of Storage Commitment correct? Ideally we would
like to push a series to a PACS and then at the end 'enable' it,
something like a database transaction where a group of operations
(transfer of the individual series images) either all succeed or all
fail. Is there a way to provide such assurances? Would it be
possible to somehow combine the series into one big file and push that
instead?
Since one or more Series are wholly contained within a performed
procedure step, an MPPS COMPLETE message will tell you the list
of SOP Instances were "created during the acquisition of the
procedure step".
That said, the PACS may never receive all the instances in the
MPPS (theoretically), since they may not be configured or intended
to be sent (e.g., thin slices, or for processing images go to
the CAD server, not the PACS, etc.). See PS 3.7.1.9 for additional
discussion of this, particularly the text added in CP 832:
The lack of concordance between a modality might "create" as
oppose to "send" (to any specific AE, like the IHE IM/IA) has
been the subject of much debate in DICOM WG 6 and IHE RadTech,
hence CP 832 (which did not make everybody happy) and the
aborted IHE CP-RAD-037, which was entitled "IM/IA receives more
or less instances than it expects as per MPPS".
You cannot assume anything about what is in a Storage Commitment
message, since that is only about hand off of responsibility
for persistence at a "list of instances" level, and you cannot
assume anything about completeness (or anything else) about
the Series. Once upon a time, Storage Commitment did include
a reference to the MPPS, but this was removed in Sup 68, to
make sure it was not abused for purposes like this. What
remains in PS 3.4 J.3.2.1.1.2 is a note that says:
"This section formerly specified a means of referencing a Study
Component that has been completed and semantics that the list
of images in the commitment request represented a complete set.
This section has been retired since the Modality Performed
Procedure Step SOP Classes provide the same facility in a
more appropriate service"
Combining the instances within a series into "one big file"
does not help either (assuming that there was a standard way
to do that), since it still begs the question of how one knows
that all instances have been received before doing that.
One approach is for the PACS (IM/IA) to not make the series or
its contents queriable or retrievable until it has decided
(through whatever means, like MPPS or human interaction or
timeout heuristics) that the series (or study) is "ready".
Finally, as a C-FIND SCP, the PACS may return a Number of
Series-Related Instances attribute in the response, but if
the PACS doesn't know there are more instances coming from
the modality, this count may be inaccurate (i.e., just
reflect what it has received so far). Likewise, if the
modality is a C-FIND SCP, this count (or a list of the
instances) may be more complete, but still incomplete if
not everything has been acquired (or reconstructed) yet.
If you are not a "modality" (e.g., you are what IHE calls
an "evidence creator"), as perhaps you are not if you are
creating RT objects, then you can also use GP-PPS or UPS
to achieve a similar goal (even if you don't schedule
creation), or you can overload MPPS and pretend you
are a modality (like the IHE Creator Procedure Step
transactions), but that begs the question of what the
PACS (and the workflow manager for scheduling, if any),
supports in this regard.
Bottom line though is if a) you get an MPPS complete, and b)
have received all the instances listed in that MPPS, you
can be pretty sure that you are good to go.
David
PS. Note that none of this says anything about when the Study,
as opposed to the Series or MPPS, is "complete" (if indeed, it
ever is).
PPS. Also note that it is not necessarily safe to make assumptions
based on the observed behavior of a particular modality (or PACS)
software version, since manufacturers change these things when
they feel like it, sometimes without telling you. This is
especially true about assumptions about associations and
storage commitment messages.
> At UM Rad Onc we push series to our PACS, and on occasion someone will
> copy it from the PACS before the push has completed, and so they only
> get part of the series.
> It is possible that using an incomplete series could result in an
> error in treatment, so we are interested in finding a way to keep it
> from happening. One suggestion was to use the Storage Commitment
> service class, but as I understand it, this only gives an
> acknowledgement that the images have been stored, and that the
> accessing of a partial series could still happen while the push was
> underway.
> Is my understanding of Storage Commitment correct? Ideally we would
> like to push a series to a PACS and then at the end 'enable' it,
> something like a database transaction where a group of operations
> (transfer of the individual series images) either all succeed or all
> fail. Is there a way to provide such assurances? Would it be
> possible to somehow combine the series into one big file and push that
> instead?
> Since one or more Series are wholly contained within a performed
> procedure step, an MPPS COMPLETE message will tell you the list
> of SOP Instances were "created during the acquisition of the
> procedure step".
> That said, the PACS may never receive all the instances in the
> MPPS (theoretically), since they may not be configured or intended
> to be sent (e.g., thin slices, or for processing images go to
> the CAD server, not the PACS, etc.). See PS 3.7.1.9 for additional
> discussion of this, particularly the text added in CP 832:
> The lack of concordance between a modality might "create" as
> oppose to "send" (to any specific AE, like the IHE IM/IA) has
> been the subject of much debate in DICOM WG 6 and IHE RadTech,
> hence CP 832 (which did not make everybody happy) and the
> aborted IHE CP-RAD-037, which was entitled "IM/IA receives more
> or less instances than it expects as per MPPS".
> You cannot assume anything about what is in a Storage Commitment
> message, since that is only about hand off of responsibility
> for persistence at a "list of instances" level, and you cannot
> assume anything about completeness (or anything else) about
> the Series. Once upon a time, Storage Commitment did include
> a reference to the MPPS, but this was removed in Sup 68, to
> make sure it was not abused for purposes like this. What
> remains in PS 3.4 J.3.2.1.1.2 is a note that says:
> "This section formerly specified a means of referencing a Study
> Component that has been completed and semantics that the list
> of images in the commitment request represented a complete set.
> This section has been retired since the Modality Performed
> Procedure Step SOP Classes provide the same facility in a
> more appropriate service"
> Combining the instances within a series into "one big file"
> does not help either (assuming that there was a standard way
> to do that), since it still begs the question of how one knows
> that all instances have been received before doing that.
> One approach is for the PACS (IM/IA) to not make the series or
> its contents queriable or retrievable until it has decided
> (through whatever means, like MPPS or human interaction or
> timeout heuristics) that the series (or study) is "ready".
> Finally, as a C-FIND SCP, the PACS may return a Number of
> Series-Related Instances attribute in the response, but if
> the PACS doesn't know there are more instances coming from
> the modality, this count may be inaccurate (i.e., just
> reflect what it has received so far). Likewise, if the
> modality is a C-FIND SCP, this count (or a list of the
> instances) may be more complete, but still incomplete if
> not everything has been acquired (or reconstructed) yet.
> If you are not a "modality" (e.g., you are what IHE calls
> an "evidence creator"), as perhaps you are not if you are
> creating RT objects, then you can also use GP-PPS or UPS
> to achieve a similar goal (even if you don't schedule
> creation), or you can overload MPPS and pretend you
> are a modality (like the IHE Creator Procedure Step
> transactions), but that begs the question of what the
> PACS (and the workflow manager for scheduling, if any),
> supports in this regard.
> Bottom line though is if a) you get an MPPS complete, and b)
> have received all the instances listed in that MPPS, you
> can be pretty sure that you are good to go.
> David
> PS. Note that none of this says anything about when the Study,
> as opposed to the Series or MPPS, is "complete" (if indeed, it
> ever is).
> PPS. Also note that it is not necessarily safe to make assumptions
> based on the observed behavior of a particular modality (or PACS)
> software version, since manufacturers change these things when
> they feel like it, sometimes without telling you. This is
> especially true about assumptions about associations and
> storage commitment messages.
> On 1/29/12 8:37 PM, Jim Irrer wrote:
> > At UM Rad Onc we push series to our PACS, and on occasion someone will
> > copy it from the PACS before the push has completed, and so they only
> > get part of the series.
> > It is possible that using an incomplete series could result in an
> > error in treatment, so we are interested in finding a way to keep it
> > from happening. One suggestion was to use the Storage Commitment
> > service class, but as I understand it, this only gives an
> > acknowledgement that the images have been stored, and that the
> > accessing of a partial series could still happen while the push was
> > underway.
> > Is my understanding of Storage Commitment correct? Ideally we would
> > like to push a series to a PACS and then at the end 'enable' it,
> > something like a database transaction where a group of operations
> > (transfer of the individual series images) either all succeed or all
> > fail. Is there a way to provide such assurances? Would it be
> > possible to somehow combine the series into one big file and push that
> > instead?
> > Thanks,
> > - Jim
Thank you David, for the extremely thorough answer. It looks like
this has
been a hot issue at some point. :)
An issue in our clinic has been that sometimes people get DICOM files
on
a thumb drive or a CD, and want to put them on out ConQuest PACS, so I
wrote a little Pixelmed program that pushes them to the PACS. Our
users
then use another one of our programs to get them from the PACS onto
our
own radiation oncology planning system (UMPLAN - runs on OpenVMS, long
story).
It looks like I'm going to have to store the state of the series
transfer 'out
of band', a persistent object that would be accessible by both
programs, the
former producing the state and the latter consuming it.
> An issue in our clinic has been that sometimes people get DICOM files
> on
> a thumb drive or a CD, and want to put them on out ConQuest PACS, so I
> wrote a little Pixelmed program that pushes them to the PACS. Our
> users
> then use another one of our programs to get them from the PACS onto
> our
> own radiation oncology planning system (UMPLAN - runs on OpenVMS, long
> story).
> It looks like I'm going to have to store the state of the series
> transfer 'out
> of band', a persistent object that would be accessible by both
> programs, the
> former producing the state and the latter consuming it.
The IHE Import Reconciliation Workflow (IRWF) profile might address
some of your needs, but is probably overkill for your situation,
particularly in its scheduled varieties that use MPPS (and there
is more ongoing work in this area for this year's IHE cycle).
Another option would be to just create a KOS manifest that essentially
listed the "state" you are talking about, i.e. a list of all instances
that constitute some set for some purpose (e.g., the entire set of
images in a study at a particular point in time). This would be
the same as the "manifest" that one stores in an XDS repository when
doing XDS-I (i.e., the "imaging document set" is described by the
KOS manifest, which itself is the content of the "document set"
that is registered with the XDS registry). So there would be a
certain symmetry with the way IHE does things in this respect. Note
also that in IHE we use such KOS objects (which are just very simple
SR objects) for all sorts of things, like listing sets of instances
that have been rejected for quality reasons (used in Image Object
Change Management (IOCM)), or are part of a teaching file submission
(Teaching File and Clinical Trial Export (TCE)). The IHE Imaging
Sharing pilot project also uses a KOS as a manifest.
> > An issue in our clinic has been that sometimes people get DICOM files
> > on
> > a thumb drive or a CD, and want to put them on out ConQuest PACS, so I
> > wrote a little Pixelmed program that pushes them to the PACS. Our
> > users
> > then use another one of our programs to get them from the PACS onto
> > our
> > own radiation oncology planning system (UMPLAN - runs on OpenVMS, long
> > story).
> > It looks like I'm going to have to store the state of the series
> > transfer 'out
> > of band', a persistent object that would be accessible by both
> > programs, the
> > former producing the state and the latter consuming it.
> The IHE Import Reconciliation Workflow (IRWF) profile might address
> some of your needs, but is probably overkill for your situation,
> particularly in its scheduled varieties that use MPPS (and there
> is more ongoing work in this area for this year's IHE cycle).
> Another option would be to just create a KOS manifest that essentially
> listed the "state" you are talking about, i.e. a list of all instances
> that constitute some set for some purpose (e.g., the entire set of
> images in a study at a particular point in time). This would be
> the same as the "manifest" that one stores in an XDS repository when
> doing XDS-I (i.e., the "imaging document set" is described by the
> KOS manifest, which itself is the content of the "document set"
> that is registered with the XDS registry). So there would be a
> certain symmetry with the way IHE does things in this respect. Note
> also that in IHE we use such KOS objects (which are just very simple
> SR objects) for all sorts of things, like listing sets of instances
> that have been rejected for quality reasons (used in Image Object
> Change Management (IOCM)), or are part of a teaching file submission
> (Teaching File and Clinical Trial Export (TCE)). The IHE Imaging
> Sharing pilot project also uses a KOS as a manifest.
> David
David -
IRWF does seem like overkill, and as I understand it, it is a
standard,
not a software infrastructure, so it would mean doing lots of
implementation.
Looking deeper into MPPS, I'm trying to understand how it works.
Suppose a situation where a device is pushing a series containing
multiple
files to a PACS. Would each file in the series contain some sort of
field that has a manifest listing all of the files in the series? Or,
is there
an MPPS object sent prior to the series being sent that indicates the
list of files, and it is up to the PACS to only expose the series when
it is complete according to the list?
It would be nice to implement something that conforms to standards,
but it looks like MPPS is not widely supported. I could not find any
reference to it in Pixelmed (although I defer to you here), ConQuest
does not support it, and a PACS vendor we are talking with has it on
their list of future features but does not know when it will be
available.
Right now I'm leaning towards a non-standard solution. It would only
work for us, but it will only take a few days to implement.
There would be no need for MPPS if series were sent in a single file,
maybe that will happen in the future.
> Looking deeper into MPPS, I'm trying to understand how it works.
> Suppose a situation where a device is pushing a series containing
> multiple
> files to a PACS. Would each file in the series contain some sort of
> field that has a manifest listing all of the files in the series? Or,
> is there
> an MPPS object sent prior to the series being sent that indicates the
> list of files, and it is up to the PACS to only expose the series when
> it is complete according to the list?
More like the latter; by the time the MPPS status is set to COMPLETE,
it should have been set to contain a complete list of instances in
that procedure step, though the timing of the MPPS messages relative
to the C-STORE messages (if any) is not specified (i.e., the MPPS
may come before, during or after the C-STOREs).
The list is stored in MPPS inside Performed Series Sequence (0040,0340)
which contains series information as well as the list of instances in
Referenced Image Sequence (0008,1140) and Referenced Non-Image Composite
SOP Instance Sequence (0040,0220).
> It would be nice to implement something that conforms to standards,
> but it looks like MPPS is not widely supported. I could not find any
> reference to it in Pixelmed (although I defer to you here), ConQuest
> does not support it, and a PACS vendor we are talking with has it on
> their list of future features but does not know when it will be
> available.
It is very widely supported on the sending (acquisition modality) end,
because it is required for IHE SWF compliance. Whether recipients make
use of it is another matter.
PixelMed doesn't support it yet because I have had no use for it either,
but that will change as I build MPPS radiation dose extractors to
convert transient information into RDSR. That said, it should be
pretty straightforward to implement an MPPS receiver using the
PixelMed (or any other toolkit) components.
> Right now I'm leaning towards a non-standard solution. It would only
> work for us, but it will only take a few days to implement.
I doubt that implementing MPPS or sending of an accompanying KOS manifest
(XDS-I like) "by hand" would take longer than "something proprietary".
> There would be no need for MPPS if series were sent in a single file,
> maybe that will happen in the future.
