For this situation, where you have an existing set of references that legitimately should continue to point to the original plan, you are fine with just updating the SOP Instance UID of the RT Plan that you have hand modified. If you have a “set of data” that you are trying to “convert” and maintain relationships (e.g. pseudonymisation), then you need to update the references.
However… the system you are trying to import it back in to may have additional restrictions. It might not allow multiple RT Plans with the same Series Instance UID (but that should become evident pretty quickly if it has that restriction). Technically, because your modification is not the same application you really should not use the same Series Instance UID, because that implies the objects came from the same system that created the Series.
If the original RT Plan encodes creation or instance dates/times, you should either update those to “now” or whenever you did the modifications.
Perhaps more important is eliminating references to RT Dose objects.
If there is a Referenced RT Dose Sequence, you need to be careful with that. The reference is no longer valid and it’s dangerous to point to a dose that doesn’t represent your plan. You should delete it.
In the control point sequence there is the Referenced Dose Sequence as well as the Referenced Dose Reference Sequence (yeah, a bit confusing).
The Referenced Dose Sequence, if there, is no longer valid.
But the Referenced Dose Reference Sequence might be, as long as it isn’t pointing to a UID.
To be safe, I’d delete it, but it is pointing back in to the Dose Reference Sequence (note, doesn’t start with the word Reference… sigh…), so you will want to look through that and see if it’s just pointing to prescriptive data (i.e. no UID present).
You might also want to alter the
RT Plan Name
RT Plan Label
RT Plan Description
RT Plan Date
RT Plan Time
Also, to be polite, and make it relatively easy to track where things came from, you might want to put
the original RT Plan SOP Instance UID in the Referenced RT Plan Sequence → Referenced SOP Instance UID, and use PREDECESSOR for the RT Plan Relationship attribute.
See RT General Plan Module – DICOM Standard Browser for some useful reference information from the DICOM Standard (or get the standard itself, but I like innolitics for the convenience in browsing).
The modified RT Plan will still point to the same structures. (RT Structure Set), via the Referenced RT Structure Set sequence → SOP Instance UID, assuming you aren’t losing anything while modifying the plan. That RT Structure Set has the references to the CT.
You might want to inspect your modified plan to see if it is referencing the CT directly through some kind of “Referenced Image” sequence, but even so, you want that to stay the same for your use case.
The code involved isn’t much different than what @SimonBiggs has shown, but digging in to sequences or eliminating them is a bit more effort. pydicom has examples of that, and there are examples of this in pymedphys (I’m sure in many places, but certainly in the anonymisation code and in the pseudonymisation code).
P.S. Everyone has to start somewhere. There is a lot to DICOM, and it can take a fair amount of time to become proficient. Your use case is not uncommon, certainly not for creating sets of test data in non-clinical test environments. The solution/approach you are taking is quite common, but be very careful about utilising it in a clinical environment.
