DICOM gurus, I need a reality check here.
Charles Bennett Smith
All weekend long I have been trying to answer the following questions.
Can anyone offer some net wisdom on this one?
Question 1:
Is it possible to receive a C-STORE SOP for a CT Image from a database,
alter the image, and then send a C-STORE SOP back to the database to update
the same image?
Question 2:
The way I read the standards a DIMSE-C operation is only used to transmit
enough context with the image to make it possible to store the image in
a database. If you want to update any of the information for a given image,
study component, study, or patient, you must then use the DIMSE-N operations.
Is this true?
Question 3:
The IODs are spearated into Normative and Composite. All of the
IODs seem to be related to one and other via an SOP Common module. Does
anyone save all of the "context" information from the Composite IODs,
or is this information simply used to help qualify where to insert the
IMAGE IE modules into the database?
Many thanks for any help you can offer here.
-- Bennett Smith
--
Bennett Smith SSGI
Senior Software Engineer 1370 Ridgewood Drive, Suite 20
bsm...@prowess.com Chico, California 95926
voice: (916) 898-0662 fax: (916) 342-8966
David Clunie
>Is it possible to receive a C-STORE SOP for a CT Image from a database,
>alter the image, and then send a C-STORE SOP back to the database to update
>the same image?
If the "database" is a Service Class User and Provider for the CT Image
Storage SOP Class, then in principle yes.
Are you going to change the Instance UID of the object ?
If you do, what is the "database" going to do with an object with a
different Instance UID and otherwise the same identifying info like
Patient/Study/Series/Image ? It should of course store it as a
separate entity because the Instance UID is the only attribute that
"uniquely" identifies an object. On the other hand if it is mapping
it to an existing image database, such as on an old modality, then
maybe it will blow off the Instance UID and write over the older
image, or reject it as a duplicate.
If you leave the Instance UID the same because you want to overwrite
it, that doesn't mean it will get overwritten. All this is implementation
dependent, outside the scope of the standard, and rarely documented in
the Conformance Statement.
>The way I read the standards a DIMSE-C operation is only used to transmit
>enough context with the image to make it possible to store the image in
>a database. If you want to update any of the information for a given image,
>study component, study, or patient, you must then use the DIMSE-N operations.
>Is this true?
The standard does not address when you "should" use certain services
or not. It merely defines the format of a particular service, and very
gingerly touches on some of the relationships of such services to
real-world activities. Generally such decisions are left to implementors
who are supposed to specify them in the Conformance Statement.
The only circumstance in which you "must" use N operations is when you
can't do it with C operations. This doesn't mean you can't use N operations
to do what you might do with C operations. On the other hand, almost
no-one implements N operations (other than for printing where there are
no C operations), since there is no form of query using the N
operations, and no way to get the necessary UID's without listening
for N events for the rest of one's life, and no real "profile" to explain
how to use them. Of course there are many things one just can't do
with DICOM.
N operations are going the way of the dodo. Even the new as yet
unimplemented untested modality worklist service is based on C
operations rather than N operations, and can work in a sort of
push or pull fashion which is pretty cute. It will be interesting
to see just how many modality vendors implement this, and how many
IS vendors support it at the other end. Of course if the modalities
could do a little HL7 then things might be different, but I have
probably offended enough people by now ...
BTW. If you are getting the impression that DICOM is really only good
for modalities pushing images to archive and workstations, and
workstations querying servers for images and having them sent
somewhere, and any other form of manipulation (such as correction
of demographics) taking place outside the context of DICOM in
soem unspecified manner on the archive, in a total void as if the
IS didn't exist at all, then you have the idea. This is of course
an enormous improvement over the chaos that reigned before DICOM,
but it is more limited than some customers expect.
>The IODs are separated into Normative and Composite. All of the
>IODs seem to be related to one and other via an SOP Common module. Does
>anyone save all of the "context" information from the Composite IODs,
>or is this information simply used to help qualify where to insert the
>IMAGE IE modules into the database?
Since one isn't going to be able to get that context back very easily,
keeping it around seems to be a good idea. There seem to be 2 approaches
to this, save everything with the image, even though some of it is
extracted and folded into a hierarchical patient/study/series/image
database, if indeed any database is in use, or blow it off having
parsed out all the information that is to be saved and putting that in
some sort of database, and totally recreating a new DICOM object (even
though it will have the same Instance UID) when it is required again
(and describing the result in the Conformance Statement as having been
"coerced" to some degree).
Bear these two alternatives in mind when planning ahead to support
non-image related objects like Standalone Curves et al, which are
not images. If the query model is ever extended to support these
(as was discussed here recently) they might actual get used. And
they may not fit neatly into any pre-existing database schema.
---
David A. Clunie (dcl...@flash.us.com)
at home: http://www.rahul.net/dclunie/html/
alt.image.medical FAQ: http://www.rahul.net/dclunie/medical-image-faq/html/
dicom3tools: ftp://ftp.rahul.net/pub/dclunie/dicom3tools/
PGP Public Key from: ftp://ftp.rahul.net/pub/dclunie/pgpkey.asc
Charles Bennett Smith
David Clunie <dcl...@flash.us.com> wrote:
>In article <4ktnq3$i...@charnel.ecst.csuchico.edu>, bsm...@ecst.csuchico.edu
>(Charles Bennett Smith) writes:
>
>>Is it possible to receive a C-STORE SOP for a CT Image from a database,
>>alter the image, and then send a C-STORE SOP back to the database to update
>>the same image?
>
>If the "database" is a Service Class User and Provider for the CT Image
>Storage SOP Class, then in principle yes.
>
>Are you going to change the Instance UID of the object ?
>
The question was related to NOT changing the Instance UID of the object.
My concern stems from recient information I have read about the DICOM-RT
radiotherapy extensions which are being proposed. They suggest that one
simply sends the composite IOD around between systems (treatment planning
system, virtual simulator, portal imaging device, etc.) and that each
of these systems "adds" and "changes" information in the composite
IOD as necessary.
I am worried that this is a very bad way to handle sensitive information
about the treatment of a cancer patient. There does not seem to be any
way to avoid having two systems "add" information to the composite IOD
and then c-store the IOD into the database. At that time, which change
gets saved, and which one gets lost? There does not seem to be any
data integrity in this scheme.
The way I read the standard, the DIMSE-N operations are designed for
exactly this sort of operation. Without using the management services
for the data, I think there are very serious problems with the proposed
use of only composite IODs.
Am I way off base here?
>If you do, what is the "database" going to do with an object with a
>different Instance UID and otherwise the same identifying info like
>Patient/Study/Series/Image ? It should of course store it as a
>separate entity because the Instance UID is the only attribute that
>"uniquely" identifies an object. On the other hand if it is mapping
>it to an existing image database, such as on an old modality, then
>maybe it will blow off the Instance UID and write over the older
>image, or reject it as a duplicate.
>
>If you leave the Instance UID the same because you want to overwrite
>it, that doesn't mean it will get overwritten. All this is implementation
>dependent, outside the scope of the standard, and rarely documented in
>the Conformance Statement.
I agree that sending the SOP around using the same Instance UID, with
changed data in it, and the associated results of doing this are outside
the scope of the standard. My concern is, should anyone be doing this
at all?
My opinion is that they should not. You mention below that no one is
implementing the DIMSE-N operations. To me this is a very sad thing to
hear. Doesn't anyone care about the integrity of the information which
is being passed around on the network? I know I do, and I would expect that
the patient would also care!
Do you know why no one implements the DIMSE-N operations? Is it too difficult,
or are there some inherient flaws that I am not aware of?
>
>>The way I read the standards a DIMSE-C operation is only used to transmit
>>enough context with the image to make it possible to store the image in
>>a database. If you want to update any of the information for a given image,
>>study component, study, or patient, you must then use the DIMSE-N operations.
>>Is this true?
>
>The standard does not address when you "should" use certain services
>or not. It merely defines the format of a particular service, and very
>gingerly touches on some of the relationships of such services to
>real-world activities. Generally such decisions are left to implementors
>who are supposed to specify them in the Conformance Statement.
I thought that the bulk of the Annexes in PS 3.4 were the "shoulds" of
using the various management services. Am I missing something here?
>
>The only circumstance in which you "must" use N operations is when you
>can't do it with C operations. This doesn't mean you can't use N operations
>to do what you might do with C operations. On the other hand, almost
I thought there were many things that you should not do with the DIMSE-C
operations. I thought they were only intended as a mechanism for moving
large chunks of information from a modality into or out of a database. I
thought the DIMSE-N operations were what one uses for manipulating the
information in the database.
>no-one implements N operations (other than for printing where there are
>no C operations), since there is no form of query using the N
>operations, and no way to get the necessary UID's without listening
>for N events for the rest of one's life, and no real "profile" to explain
>how to use them. Of course there are many things one just can't do
>with DICOM.
Hmm. I was under the impression that the Basic Study Descriptor IOD
was the "glue" which linked the Normative and Composite IODs together
and that a person would "get" the Basic Study Descriptor IOD from the
database first and then use the information contained in it as a means
of querying for various composite IODs in the database. If this were
true, it would not be necessary to watch for all N events unless you are
also a database. If you are just a user of a database then you just
talk with the database when you need information from it.
In my opinion, if you are implementing a database, then you darn well
should be listening for the N events. That is the only way you can
be sure to keep your database in sync with other databases on the
network. I thought that was the whole point of the N-EVENT services.
Once again, I guess I am reading more into the standard than is really
there.
I sure wish that some of the original contributors to the standard were
active on this group and could offer some guidance on these issues.
>
>N operations are going the way of the dodo. Even the new as yet
>unimplemented untested modality worklist service is based on C
>operations rather than N operations, and can work in a sort of
>push or pull fashion which is pretty cute. It will be interesting
>to see just how many modality vendors implement this, and how many
>IS vendors support it at the other end. Of course if the modalities
>could do a little HL7 then things might be different, but I have
>probably offended enough people by now ...
What is this modality worklist service? Where can I find some information
on this?
Also, do you know anything about authentication of DICOM services? I have
not found anything in the standard. Is anyone working on an addition
that would specify what operations which AEs are allowed to perform, and
which might perform some form of name services for AEs, ports, and IP
addresses?
>
>BTW. If you are getting the impression that DICOM is really only good
>for modalities pushing images to archive and workstations, and
>workstations querying servers for images and having them sent
>somewhere, and any other form of manipulation (such as correction
>of demographics) taking place outside the context of DICOM in
>soem unspecified manner on the archive, in a total void as if the
>IS didn't exist at all, then you have the idea. This is of course
>an enormous improvement over the chaos that reigned before DICOM,
>but it is more limited than some customers expect.
Yes, this is the impression I am getting. However, I only get this
impression based on how you are describing the current implementations
of DICOM. I read the standard as being more full featured than what
it appears most vendors have taken the time to implement.
I think that is really sad, and will probably come back to bite them
when hospitals become more fully connected and start having data
integrity problems. I guess the cynic in me says that the vendors will
then offer a "silver bullet" for this data integrity problem and charge
the customers a ton of money to add this new previously unanticipated
feature!
Thank you for taking the time to respond to my query. I really appreciate
the sounding board that the comp.protocols.dicom group provides.
David Clunie
>The question was related to NOT changing the Instance UID of the object.
>My concern stems from recient information I have read about the DICOM-RT
>radiotherapy extensions which are being proposed. They suggest that one
>simply sends the composite IOD around between systems (treatment planning
>system, virtual simulator, portal imaging device, etc.) and that each
>of these systems "adds" and "changes" information in the composite
>IOD as necessary.
I have just taken a look at the current draft of the RT proposal available
as "ftp://ftp.nema.org/dicom/docs/rtapr12.rtf" that is dated April 12th 1996.
As far as I can see the draft is almost entirely devoted to defining
new IOD's and doesn't define any new services. The only reference to
somwthing similar to what you propose is in an informative Annex A to
Part 3 "Complex Use Scenario for RT DICOM Objects" that no where specifies
that the same instance UID will be used for anything that is proposed
to be modified. Indeed the RT Plan seems to be the only thing that gets
modified in this scenario, as it is built up by automated and then manual
systems, which seems reasonable. Maybe earlier drafts were not this way.
Be that as it may, in general ...
>I am worried that this is a very bad way to handle sensitive information
>about the treatment of a cancer patient.
Whether it is a cancer patient or not, radical modification of an instance
without changing the UID seems dangerous to me. Indeed I would imagine some
sort of audit trail of modifications would seem mandatory for such as scheme.
Personally I think the only time it is "safe" to change an instance without
changing the UID is when something like a name spelling correction is
done, and even then perhaps that should be audited somewhere. This is not
to say that various optional stuff is not going to get coerced into
shape or out of existence when objects are shipped around between different
devices without changing the UID but that is probably ok.
> There does not seem to be any
>way to avoid having two systems "add" information to the composite IOD
>and then c-store the IOD into the database. At that time, which change
>gets saved, and which one gets lost? There does not seem to be any
>data integrity in this scheme.
The behaviour of each AE in the scheme would have to be extremely tightly
defined in the Conformance Statment.
>The way I read the standard, the DIMSE-N operations are designed for
>exactly this sort of operation. Without using the management services
>for the data, I think there are very serious problems with the proposed
>use of only composite IODs.
The way I read the standard is that the N-stuff is suppose to operate
on individual entities in the information model. Doing it that way
would still require some decision as to who could modify what, and
when a "new" object (and hence new UID) was required as opposed to
mere "correction" of an old one.
>I agree that sending the SOP around using the same Instance UID, with
>changed data in it, and the associated results of doing this are outside
>the scope of the standard. My concern is, should anyone be doing this
>at all?
No argument there.
>My opinion is that they should not. You mention below that no one is
>implementing the DIMSE-N operations. To me this is a very sad thing to
>hear. Doesn't anyone care about the integrity of the information which
>is being passed around on the network? I know I do, and I would expect that
>the patient would also care!
I don't think that N operations are a magic solution providing such integrity,
they just are an attempt to provide a more fragmented access to objects
that represent single real-world entities rather than a bunch together.
The problem with the N objects is getting their Instance UID's in the
first place in a relatively loosely integrated environment as most
multi-vendor DICOM based imaging systems are.
>Do you know why no one implements the DIMSE-N operations? Is it too difficult,
>or are there some inherient flaws that I am not aware of?
For example, I am a CT scanner. I am scanning Joe Smith. I want to get
his "stuff" (say his old reports) from the IS via DICOM N-services. How
do I find the appropriate UIDs to N-Get them ? I can't because there
is no N-operation to do such a query. If I had listened to and recorded
every single event from the DICOM IS then I might have heard about Joe
sometime in the past few days, but not knowing he was coming for a scan,
would I have recorded every patient admission say ? Would the IS have
deigned to specifically associate with me and send me the event, given
that there is no DICOM broadcast ? What if I were down ? Would it have
queued it for me ?
Is there any composite service I could query to try to find this
information ? Not if Joe has never had any images before since
there will be no study with his name. And even if there were who
is to say that the Composite Study UID is going to be the same as
the Instance UID of the Detached Study object. This is hinted at
but not mandated by the standard.
>I thought that the bulk of the Annexes in PS 3.4 were the "shoulds" of
>using the various management services. Am I missing something here?
Shoulds are not much use in a standard. Only "musts" get implemented and
are interoperable.
>I thought there were many things that you should not do with the DIMSE-C
>operations. I thought they were only intended as a mechanism for moving
>large chunks of information from a modality into or out of a database. I
>thought the DIMSE-N operations were what one uses for manipulating the
>information in the database.
I think that must have been the intent, but the reality is that the N
stuff was defined but not tested in an implementation as far as I
know, and those who have dabbled with them have been disappointed
(or without naming any names, come up with some truely horrendous kludges
outside the spirit of the standard to get the job done).
>Hmm. I was under the impression that the Basic Study Descriptor IOD
>was the "glue" which linked the Normative and Composite IODs together
>and that a person would "get" the Basic Study Descriptor IOD from the
>database first and then use the information contained in it as a means
>of querying for various composite IODs in the database.
I don't think you can "get" it without a UID in the first place.
> If this were
>true, it would not be necessary to watch for all N events unless you are
>also a database. If you are just a user of a database then you just
>talk with the database when you need information from it.
Talk how ? Outside DICOM ?
>In my opinion, if you are implementing a database, then you darn well
>should be listening for the N events. That is the only way you can
>be sure to keep your database in sync with other databases on the
>network. I thought that was the whole point of the N-EVENT services.
How successful can a protocol be that does't have a way of querying for
the information contained in events that might have been missed ?
Consider for instance DNS with the ability to cache things, receive
unsolicited zone transfers, pass queries when information is out of
date or not present ... that is the sort of function the N stuff needs
to provide the sort of full service I think you are suggesting.
>I sure wish that some of the original contributors to the standard were
>active on this group and could offer some guidance on these issues.
I have never actually talked to anyone who claimed responsibility for
the N stuff, but I did have it pointed out to me that it was based on
CMIP/CMIS stuff from ISO (their SNMP equivalent) where a whole scheme
for handling managed objects was developed. It is rather elegant and
included a mechanism for "getting" groups of things based on operation
modification called "scoping" and "filtering" or some such stuff, not
just single objects by single identifier. Unfortunately these functions
didn't make it into DICOM :(.
>What is this modality worklist service? Where can I find some information
>on this?
I think it is on both the PSU and the Duke servers ... see the FAQ Part 8
for their URLs.
>Also, do you know anything about authentication of DICOM services? I have
>not found anything in the standard. Is anyone working on an addition
>that would specify what operations which AEs are allowed to perform, and
>which might perform some form of name services for AEs, ports, and IP
>addresses?
This fits in the category of security which is currently in the too
hard basket I think, though there are people working on a white
paper for the next joint WG VI/CEN TC 251/JIRA/MEDIS-DC meeting
at CAR in Paris at the end of June.
Bottom line is it is more practical to do it a la inetd and tcp_wrapper
and all the rest, given that you believe someone's ip address. Inside
a packet filter that doesn't let your internal ip address in from outside
this may be ok I suppose. No one I know really wants to have to add
the kind of cryptographic user/host authentication that is required
to do this right until the Internet and other standards have
stablized, much less deal with access control, protecting transfer
syntaxes, message authentication and non-repudiation, etc.
With a few hooks to the something like GSS-API in the Association
Establishment this might be easy, but defining the alternative
standards to reference might be tougher. It could all be done out
of band also, with something like the proposed ISO Generic Upper
Layer Security stuff with a separate Security Service Element (SSE)
separate from the Association Control Service Element (ACSE), but
none of this is even standard yet (ISO or RFC). And you would still
need to ammend the DICOM protocol to handle a Protecting Transfer
Syntax if you do it at the Application or Presentation level.
Others feel it should be left at the network level and hope IPv6
will do at least the authentication if not the protection below
a level one has to think about in DICOM. I assume there will be
a few problems like key management to deal with though !
>Yes, this is the impression I am getting. However, I only get this
>impression based on how you are describing the current implementations
>of DICOM. I read the standard as being more full featured than what
>it appears most vendors have taken the time to implement.
I am a terrible cynic as you know. And vendors have implemented what
they needed to implement to get images moving around. All this IS
to imaging equipment stuff is so much harder to do though, unless
you have total control of the entire system, and it is not surprising
it is not readily achievable yet. I really don't think it is a matter
of lack of will or laziness on the part of the vendors though, at
least not judging by the intense activity on the part of those I
know.
I will be interested to see how the Worklist demo at RSNA with
the HL7/DICOM gateway (for this explicit purpose) goes. I hear
that more and more IS companies are sending people to the DICOM
meetings so this sounds promising.