— End of inner exception stack trace —
2009-12-03 00:13:27,359 [Pool:15] ERROR - Exception thrown
System.Exception: The file cannot be inserted into the Data Store (.\dicom_interim\jbg05osg.wld.dcm). The file has been moved to C:\ClearCanvas\workstation\badfiles\jv5hj0xd.awz ---> ClearCanvas.Dicom.DicomDataException: Invalid Study Instance UID: Invalid DICOM UID format: 1.3.12.2.1107.5.8.2..200912223559125.9072
at ClearCanvas.Dicom.Validation.DicomValidator.ValidateStudyInstanceUID(String uid)
at ClearCanvas.Dicom.DataStore.Data— End of inner exception stack trace —
2009-12-03 00:13:27,359 [Pool:15] ERROR - Exception thrown
System.Exception: The file cannot be inserted into the Data Store (.\dicom_interim\jbg05osg.wld.dcm). The file has been moved to C:\ClearCanvas\workstation\badfiles\jv5hj0xd.awz ---> ClearCanvas.Dicom.DicomDataException: Invalid Study Instance UID: Invalid DICOM UID format: 1.3.12.2.1107.5.8.2..200912223559125.9072
at ClearCanvas.Dicom.Validation.DicomValidator.ValidateStudyInstanceUID(String uid)
at ClearCanvas.Dicom.DataStore.DataAccessLayer.DicomPersistentStoreValidator.Validate(DicomFile dicomFile)
at ClearCanvas.ImageViewer.Shreds.LocalDataStore.LocalDataStoreService.DicomFileImporter.ParseFile(ImportJobInformation jobInformation)
— End of inner exception stack trace —

 

Looks like the image that caused this has an invalid sop instance uid. Notice the consecutive periods: 1.3.12.2.1107.5.8.2..200912223559125.9072

 

Probably would be best to clean up string and convert .. to .

I have seen this a few times

 

 

 

 

study stores OK in efilm by the way

we fixed this on our end by making the following 1-character change:

Change the following line in Dicom/Validation/DicomValidator.cs

_uidValidationRegex = new Regex("^[0-9]+([\\.][0-9]+)*$");

to

_uidValidationRegex = new Regex("^[0-9]+([\\.]+|[0-9]+)*$");

Hi Everyone,

The format of a DICOM UID does not allow for the inclusion of two periods in a row. Our current position at ClearCanvas is that we should strive to uphold the DICOM Standard as much as we possibly can.

However, we do recognize that there are DICOM instances out there that do not strictly adhere to the DICOM Standard (particularly in research environments) and so we have included a switch to disable SOP validation for the sole purpose of viewing the image. This switch can be found under Tools / Utilities / Configure Settings, SopValidationSettings group. The setting for disable validation can be set to True, and then validation will not be performed on opening images. This will not disable validation for DICOM data store related tasks, including import and send. We also took the decision to not continue to propagate invalid DICOM any further, and that includes restricting it from any operations which may cause the bad UID to be transmitted beyond our control.

You are, of course, free to modify the source code anyway you wish, but we might not be able to fix this at present. Please let us know if you have any thoughts on this topic as well - do you agree/disagree with our position from your point of view as a clinician, a researcher, ...? Are there other use cases we haven't considered?

Thanks,


(Technical Note: We cannot "fix" bad UIDs - if we reassign a new UID, then the instance might lose any links it had with other instances bearing the same UID. If we drop the extra period, then we can no longer guarantee uniqueness of the value, since the UID may - and probably was - generated hierarchically and dropping the extra period effectively drops one level of that hierarchy. The only entity that can properly "fix" the UIDs so as to maintain links and guarantee uniqueness is someone with knowledge of the algorithm and values that generated the UID.)

I agree with the concept of trying to "stop" rather than propagate bad dicom; personally, I'd suggest that the imageserver refuse invalid dicom, whereas the viewer should accept it. The reasoning being, the image server is part of the infrastructure to store, archive, distribute DICOM, and as such refusing bad dicom could be useufl. The image viewer itself is a dead end. Might as well let the user see the study, if some entity outside the image viewer for whatever reason is passing some images with invalid UIDs.

Hi Tommy, for the most part you're right, the viewer is a "dead end", but it can create new sop instances that are then sent back to the server and appended to the study. Right now, that's only Key Objects and Presentation States, but they contain references to the other sop instances in the study, which would result in propagating bad DICOM. When you open images from the local file explorer in the viewer, you can't create Key Images, which is why we've limited opening these "bad" images to the local file explorer only, at least for now.

Best regards,
Stewart