Export / Import plan scheme

Mar 23 at 6:45 PM
I am trying to batch transfer DICOM files (where files = { plans, structure sets, images, doses} ) between ARIA systems.

I am able to 'export via script' these things with the EvilDICOM package; but, when I try to import them back into Eclipse, I get DICOM tag errors. I look at the tags present in my files and I know they are present.

I am working to get the needed elements to use the scripting plus DCMTK (written by W.Keranen) process to export files. Has anyone tried this process and able to successfully re-import the files into Eclipse?

I am wondering if there are 'proprietary ARIA DICOM tags' that I am missing or some other obtuse reason.
Mar 23 at 8:10 PM
I haven't re-imported anything into aria but I have pushed to brain lab and MIM without any issues.

I would caution on a scripted plan export. If the varian daemon exports a plan, the editdatetime column of the RTPlan table in the database updates to the time of the export. If someone has the plan open when the export takes place and tries to save after the export, it will force them to reload prior to saving. There is nothing they can do except reload. Even if they havent changed anything, because that editdatetime stamp is after they opened plan, they will have to reload to continue any kind of editing. they wont be notified until they try to save. To avoid this, I would highly recommend checking if there is an entry in the accestatus table for the patient prior to a scripted export.
Mar 24 at 12:30 AM
Thanks for the info.

Out of curiosity, what method did you use for your data export?

I was able to use the exported data in many varying applications, as well. But, it keeps failing on the ARIA import. I have a feeling this is a 'proprietary issue' that I was referring to in the original post (based on further studies).

My goal was to have a way to export data to a research box to bulk modify plans - hence there is no issue with the date.
Mar 24 at 1:39 PM
I used W.Keranen guide to create an export.

What error messages are you getting specifically? Which tags are problematic? My thoughts go straight to duplicate UIDs, ie SOP instance uids that you are trying to import into research box are already in the research database. Aria wont let something in if the UID is already in the DB.

If its just plan edits, have you thought about using evil dicom or another library to tweak the dicom file directly after export, change the SOP instance UID and resave for re-import. Thats what I do for plan edits. Its takes a little time getting used to the DICOM paradigm, but it pays off in the flexibility you get. Adding beams, changing geometry, putting in table params, tweaking mlcs, adjusting ref points, etc
Mar 24 at 4:21 PM
Edited Mar 24 at 5:20 PM
Okay, I haven't been able to use the 'Keranen method' because we do not have the needed "File Daemon Configuration" software on the research box, so I have not been able to pursue this method.

The errors present on import are:

Mandatory element not found (Element: (0008,0018) 'SOP instance UID')
Mandatory element not found (Element: (0008,0016) 'SOP class UID')

I looked at both output the tags present in the DICOM file BEFORE the export (by outputting the present tags to the terminal) and AFTER the export (using MATLAB, among other programs) to see these tags are present in the files. So, this seems to be a incorrect and/or just a default error upon re-import to the research box.

The research box has limited amounts of data present, so I know the issue is not duplicate patients.

I have started to investigate the specific DICOM tags by looking at the tags present in files that I have successfully imported into the database.

I appreciate your information in this matter.
Mar 24 at 6:25 PM
Definitely not proprietary. SOP Class UID is defined in the standard based on the object type, ie RTPlan, RTDose, RTStruct, etc, and SOP instance UID is the UID given to that specific instance of the SOP class (SOP=Service/Object Pair).

I would recommend exporting to file using evilDicom and doing the exact same export with the Varian Daemon and comparing tags one by one. It looks to me like evil dicom is not compliant with something varian is picky about.

Sometimes tag errors can red herrings, a one to one comparison should help identify the differences. For my own curiosity (and out of a love/hate relationship with the DICOM standard) and if you dont mind sharing, Id love to see the problem file.
Mar 28 at 6:23 PM
I meant that the absence of some other dicom tag (like the '0002' group) was making the import fail and then the 'default error message' was just complaining about the 00080018 and 00080016 tags.

I tried manually creating the meta tags of the 0002 group, but this still didn't fix the import issue.

Anyone else have any ideas??