possible bug - Changing the PatientID only at database level

[rrose...@securerad.com]

There seems to be an issue with modifying patient ID's via the GUI where the change only takes place at the database level. This becomes a problem when retrieving via WADO because the original PatientID is what is retrieved.

I'm not sure if there is a jmx-console "switch" or variable that forces a PatientID change to go down to the study's meta-data level.

I'd like others to test this to see their results…..

To verify, I changed a PatientID via the web3 GUI. Then, navigated to the directory where the study is stored. I brought the the file directly into Osirix. The original PatientID is what is displayed.

Additionally, I chose WADO as the retrieve method in Osirix (I had to restart Osirix to get the change to stick). Then I retrieved the study, and again the original PatientID is what transfers. C-Move and C-Get seems to apply the changes that were made in the database, but WADO does not.

If I change the meta data in Osirix for the study, then delete the study from dcm4chee, then send it back with the changed PatientID, it works. That tells me Osirix changes the PatientID at the meta data level. 

Any thoughts on this matter would be helpful. It would be a royal pain if in order to properly change the PatientID, one would have to retrieve the study, make the change on a different device, delete the study from dcm4chee, then send it back with the correct info….

Thanks,

Rich

[fleetwoodfc]

"Then, navigated to the directory where the study is stored. I brought the the file directly into Osirix. The original PatientID is what is displayed."

This would be the expected behaviour as the file contains the original data. Updates are tracked by the database and are applied when the object is accessed through the DICOM interfaces - so I would expect an object retrieved via WADO to include any updates. (did you delete the study in OSIRIX before you tried retrieving again with WADO?)

[Damien Evans]

In addition....  There is the possibility that a WADO-retrieved image is not coerced in the same manner as it is when it is fetched via DICOM retrieve (C-MOVE/C-GET).  It should be, in theory, but if you are not seeing updated metadata in the WADO-retrieved images, there is that possibility.

As far as the image on the file system, David is right, that is expected behavior for it to contain the original metadata.  DICOM objects should be coerced with up to date metadata when retrieved out of the system.

 -- Damien

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che.
For more options, visit https://groups.google.com/d/optout.

[David Davies]

I did a quick test with OSIRIX and dcm4chee-2.17.3  and it works as expected - Query and WADO Retrieve uses the updated version.

On Mar 25, 2014, at 8:38 AM, rrose...@securerad.com wrote:

The study was not there in the first place which is what brought the issue to my attention, and yes, it was deleted before each test. The overall point is that without the study locally, an Osirix WADO retrieve from dcm4chee on any study which has a modified PatientID displays the original PatID, not the updated. Anything else I can do to provide more info? I'd really like to know if others experience the same results.

Additionally, I neglected to point out that for the query itself, the results in Osirix do show the modified PatientID, (but the download does not). Now, that I would expect regardless because the query is only hitting the database.

Also, I guess you answered my question about there being an option in jmx-console….thanks (that there isn't an option). So the design is to have dcm4chee include the updated PatientID when retrieved via WADO… which isn't happening

next?

Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/xrwRzqwBxQg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.

To post to this group, send email to dcm...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che.
For more options, visit https://groups.google.com/d/optout.

David Davies 

Essential Enterprise Solutions

Office: 727.938.3374 ext 102

www.eesimed.com

[rrose...@securerad.com]

This seems to apply, but it's old and I don't know what a "file section" is (#3092)  http://www.dcm4che.org/jira/browse/DCMEE-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

This is from my log - interesting the (useOrig=true). seems it's looking for the original dicom data…

15:57:35,719 INFO  [WADOServlet] 172.22.22.5 - WADO URL:/wado?requestType=WADO&studyUID=1.3.12.2.1107.5.2.36.40442.30000010031709304982800000005&seriesUID=1.3.12.2.1107.5.2.36.40442.2010031710152480622426421.0.0.0&objectUID=1.3.12.2.1107.5.2.36.40442.201003171015389894126451&contentType=application/dicom&useOrig=true

15:57:35,720 INFO  [WADOSupport] Get WADO object for 1.3.12.2.1107.5.2.36.40442.201003171015389894126451

15:57:35,725 INFO  [WADOSupport] Original Dicom object file retrieved (useOrig=true) objectUID:1.3.12.2.1107.5.2.36.40442.201003171015389894126451

15:57:35,725 INFO  [WADOServlet] send WADO response: application/dicom

1

David - does your log say the same thing during a WADO retrieve?  "(useOrig=true)"?

--Rich

[fleetwoodfc]

I think the "useOrig=true" is to allow the DICOM tags of the original file to be rendered in the web interface - when you select the "Display Dicom attributes from file" icon.

Would not expect OSIRIX to add "useOrig=true" to its WADO request.