irrer / dicomclient Goto Github PK

When dealing with sets of files, especially in radiation therapy, it would be helpful for the user to see which series refer to each other. The relations are defined by UIDs, which are user hostile.

Add edit Update feature to find and change next occurrence of an attribute (similar to Eclipse IDE edit)

This would provide a more robust platform on Linux. The GUI has not been thoroughly exercised on Linux.

Search by patient/study/series for a given string. This is useful for finding links between series, and general ability to find something.

Search should be optionally case sensitive. Should have option for regular expressions.

Make installation easier and more automatic. Check for Java being available and possibly assist user with installation. Install shield for Windows would be nice. Create Windows desktop, start menu, and task bar menu items.

This happens when the file being uploaded was removed after loading but before uploading.

Sometimes image sets are incomplete, and if they are rotated by 90 degrees, missing slices become obvious.

This would also generally enhance the tool's utility.

Rotating in increments of 90 degrees around x, y, or z axis would be most beneficial for the least implementation effort. Rotating by arbitrary angles would also be useful.

Some anonymization values (such as below) should enforce properly formatted types.

For example, if an empty string is given for a numeric type, then it can not be inserted. Currently the result is to set the attribute to have no value(s) at all, which is probably OK for most situations, but is not ideal.

0018,1310 US 4  AcquisitionMatrix : 256 \  0 \  0 \  230

When an attribute has multiple lines, it is displayed and edited as a single line (with the newline characters replaced by blanks). There is no way for a user to create an attribute containing new lines.

Note: In the course of editing, if a multi-line value is not modified, then it will retain its multi-line nature.

This is not a big issue but thought it should be noted.

This would be a nice summary to highlight to the user what is being done, and possibly show information that should not have been anonymized.

The aggressive anonymization feature has a potential problem:

Patient's last name is 'Big' and will get anonymized to 'none'

Machine manufacturer model name is 'Big Bore'

Machine name gets aggressively anonymized to 'none Bore'

Someone familiar with the model of machine could reason that the patient's name is 'Big'

When previewing files, large files can take a long time to process. Look at ways to optimize previewing processing.

When editing metadata, currently there is no way to add a private tag.

Sometimes PHI is printed directly in an image (a bad practice). Thorough anonymization would require this information to be blacked out. The feature should be applied to entire series with a single user operation, assuming that each slice displays the PHI in the same place. Optionally the user should be able to black out areas on a slice by slice basis.

Sometimes it does, other times not. Pressing 'Enter' gets to the next one as a workaround. Not totally sure if it should position as user types, because sometimes it would take the user to an unintended place as they type, and then when they complete the search pattern it would not be found, but the text displayed would be positioned in an irrelevant place.

User should be able to select sets of private tags to recognize based on vendor. For example, click a Siemens radio button for Siemens tags.

It might be possible to somewhat automate the selection for the user by looking at the manufacturer in the DICOM file.

The Details checkbox on the Anonymize Details window should also display Value Representation and Value Multiplicity to be consistent with similar functionality in the previewer and the editor. Currently it only shows group and element number.

Show lines drawn around structures.

If the images are not available, just show lines.

This is somewhat beyond the intended vision for this tool, but maybe could be done.

Convenience feature for user to print text or images. Images could be tough because of potential formatting issues.

If a DICOM file contains errors, an exception is thrown and the entire file is ignored. Instead, using the DicomClientReadStrategy to save the latest state, the portion that was readable should be used.

Provide an interface that allows the users to see the differences between two DICOM files.

Some users have done this manually by saving the files as text and then using a text comparison tool, which is the current workaround.

The actual comparison of files is easy to implement, but the construction of tje GUI part is potentially a lot of work.

Could also compare image files, but this is probably a slippery slope that would take the project away from it's original vision and add complexity.

If the user is in edit mode, and uses Create to create a new attribute, they can choose one that already exists, and potentially unintentionally overwrite it.

Allow user to query PACS and show list of results.

Add documentation to manual for editing DICOM files.

Add edit Update feature to change all occurrences of an attribute

Show dose intensity.

This could be a lot of work, and is beyond the intended purpose of this tool. Probably will not implement.

Currently, the Pixelmed library does not have a way to stop the reading of a DICOM file based on application defined criteria. This program gets around this by reading in a small portion (first 4K) of file and interpreting what it can to get the metadata needed to categorize the file. This is done because it is much faster than reading the entire file, and greatly enhances the user experience when reading hundreds or thousands of files.

The proposed solution is to change the Pixelmed library to support a read strategy defined by the application. This would require acceptance by Pixelmed. It would get rid of exception messages thrown and ignored when reading DICOM files. These messages are distracting during development, as are noise that that can obscure noteworthy exceptions.

Showing multiple preview windows would allow users to compare files and jump back and forth between them more easily.

Not sure if this has nasty implementation implications.

Sometimes users load files with undefined attributes that can not be viewed. A GUI interface would make it easy to do so.

The downside of this is yet more complexity, especially in keeping the list of known attributes in a file, keeping that file in a 'good' place, and not over-writing that file when a new version of the software is installed.

The workaround is to define them by editing the configuration file and restarting the application.

When performing multiple anonymizations from the command line, the same UIDs may need to be preserved between runs. If there was an option to persist the anonymization state then users could perform anonymizations in smaller batches rather than all in one go.

Currently the tool creates a log, but there might be use for tracking what users access what data.

Reading the log is not user friendly. Creating an audit trail that is easy to read, or a tool to read it would be an improvement.

Am thinking that this is not a high priority issue.

User should not have to start a file viewing application to load more files. On Linux it is less common to use a separate file browser, and they might not support drag and drop.

Option to save each series in a separate directory.

This is a convenience feature for situations where there are many DICOM files being read, and they are all in the same directory. Organizing them by series can be useful.

Not sure how desirable this feature is - when files are created now they are differentiated by prefix.

When displaying images, voxels are assumed to be square whether they really are or not. This makes some images look compressed either vertically or horizontally when viewed. Their aspect ratio should be used to draw them correctly.

It would be less confusing for novice users if there were not a separate DOS window on MS windows.

When anonymizing, images are sometimes passed to outside parties, and the originator wants to be recognized for the value that the originator has provided.

Most DICOM group 0002 values are overridden when the file is created, so the user can be mislead into thinking that they can control them when they can no.

Support the previewing of DICOM files with image and text via a preview handler. This would be a convenient browsing feature.

Provide a simple, direct way for users to provide feedback and submit requests.

Email seems the simplest here.

Sometimes PHI is put into description fields.

Show character strings that will not be anonymized and let the user decide if they are PHI or not. Highlight strings that share sub-strings with original content that is getting anonymized.

Show the intensity of treatment fields.

This could be a lot of work, and is beyond the intended purpose of this tool. Probably will not implement.

Allow the user to 'rubber band' a line on the screen and measure the distance between two points.

This would require getting the units from the file to show them to the user (eg: centimeters)

Currently there is no testing for any of the GUI mode features.

Sometimes when many cases are loaded the user ends up doing a lot of scrolling on the main screen. If files could be collapsed by patient or study, then the user could better see the list.

Allow loading a DICOM file by reading an XML file. This would allow hand-editing or other generation of an XML DICOM file. (non-image files only). Files that are generated could be modified and re-imported.

Show DICOM errors (bad date format, missing attribute, etc.).

Many simple errors can be caught trivially, and that alone might be helpful, but it is a slippery slope, as the full-blown set of rules is huge and complex. Users might mistakenly believe that if the program does not find errors, then their file is perfect, when in fact it is only checking some standards violations.

When in anonymizing mode, the previewer should show values that will be anonymized in red. There should be a checkbox to switch the previewer to show what the file will look like when anonymized, and those same values be shown in green.

Copy DICOM files from PACS to local host.

While anonymization or uploading is taking place, the user (out of impatience or uncertainty) may try to click them again, which may produce unexpected results. They should be disabled until the current processing (anonymizing or uploading) is complete. This would also provide visual cue that the program is working.

Another visual cue would be to also show a progress bar that indicates 'global' progress instead of progress bars for each individual series. It might even be a replacement for the current progress bars, as it would de-clutter the screen.

DICOM image files that use JPEG 2000 images are not supported. This would require either a platform specific library or an implementation in Java. Both of these are difficult to support and so this will probably not be fixed.