Modifying (or not Modifying!) RT Objects¶
In the Supplements 11 (introduction of RT Objects, namely RT Structure Set, RT Dose, Image and RT Plan) and 29 (Introduction of the different RT Treatment Records) the "Scope and Field of Application" speaks of RT object as "containers" which may be modified during treatment course:
"Essentially the objects are intended to be used as 'containers' for related radiothreapy data, with data being added as the object flows through the department."
This rises the question what may happen, if for example a plan gets modified and should be stored back to an archive where it resided before, too. Modifying an object (to my interpretation) seems to be to result in changing some attributes (e.g. appending treatment sessions to a plan), letting the SOP Instance UID keeping the same value (this is the way I interpret the sentence above). The archive (PACS) now would have to decide what to do with this Storage request: Reject it (as it would probably do for most image objects like CT) or accept it and overwrite the existing object in the archive.
A question also came up in the comp.protocols.dicom newsgroup in 1996, before actually Supplement 11 was balloted:
David Clunie in response to Charles Bennett Smith:
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.
According to that explanation it is not too clear whether a DICOM RT object instance could be modified and how the archive (or any other system should react). So I guess this is left to the application which should document this tightly in its Conformance Statement (see quote above).
Actually only the RT Plan IOD (more exactly: the included RT General Plan Module) define very basic attributes for tracking changes to a specific object instance (plan). There are the attributes RT Plan Date and RT Plan Time which record the "Date (or Time) treatment plan was modified". This could be read as an implicit hint that an RT Plan object instance could be modified. On the other hand, the RT General Plan Module also allows for referencing other RT Plans, with specifing the relationship between "this" and the referenced plan. Permitted values are (PRIOR, ALTERNATIVE and PREDECESSOR) which would also allow copying the plan, changing the desired fields, changing the SOP Instance UID and marking the new plan as "PREDECESSOR" (->"plan used in derivation of current plan").
Overall the conclusion could be that the behaviour in modifying RT objects is application-specific.