study_custom1 value in dcm4chee DB getting wiped when new instances are received for an existing study

[jne...@gmail.com]

We have a workflow where we use the study_custom1 column in the study table in the dcm4chee DB to store some data.

A new study is received into the archive. The archive creates a new patient record in the DB, new study, series, and instances as they are received. All these populate the DB correctly. Then, we populate the study_custom1 column with our custom data.

Some time later, an additional series and instances are received by the archive. Dcm4chee creates a new series and instance records, as expected. However, it also seems to update the study/patient DB rows, and in particular - it REMOVES the value we have put in study_custom1.

This is visible in the log as the second series is received:

2013-02-14 19:48:15,219 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4chex.archive.ejb.session.StorageBean] inserting instance FileMetaInfo[uid=1.3.39.19600601.2.2.999.20130211.232319818.232319818.1
        class=1.2.840.10008.5.1.4.1.1.2/CT Image Storage
        ts=1.2.840.10008.1.2.4.90/JPEG 2000 Lossless Image Compression
        impl=1.2.40.0.13.1.1.1-dcm4che-1.4.31]
2013-02-14 19:48:15,222 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4chex.archive.ejb.entity.StudyBean] Update stored objects with additional element/value from new received object - (0008,0005) Specific Character Set,CS,*1,#10,[ISO_IR 100]
2013-02-14 19:48:15,229 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4chex.archive.ejb.entity.SeriesBean] Created Series[pk=611625, uid=1.3.39.19600601.2.2.999.20130211.225257088.18467.232319818, study->ejb/Study:162573]
2013-02-14 19:48:15,237 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4chex.archive.ejb.entity.InstanceBean] Created Instance[pk=17983694, iuid=1.3.39.19600601.2.2.999.20130211.232319818.232319818.1, cuid=1.2.840.10008.5.1.4.1.1.2, series->ejb/Series:611625]
2013-02-14 19:48:15,239 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4chex.archive.ejb.entity.FileBean] Created File[pk=18249042, filepath=2013/2/14/19/2F65B8A7/B20841AE/483C37D5, tsuid=1.2.840.10008.1.2.4.90, filesystem->ejb/FileSystem:9, inst->ejb/Instance:17983694]
2013-02-14 19:48:15,243 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4chex.archive.ejb.session.StorageBean] inserted records for instance[uid=1.3.39.19600601.2.2.999.20130211.232319818.232319818.1]
2013-02-14 19:48:15,247 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4cheri.net.FsmImpl] sending [pc-5] 1:C_STORE_RSP
        class:  1.2.840.10008.5.1.4.1.1.2/CT Image Storage
        inst:   1.3.39.19600601.2.2.999.20130211.232319818.232319818.1/?
        status: 0
2013-02-14 19:48:15,318 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4cheri.net.FsmImpl] received A-RELEASE-RQ
2013-02-14 19:48:15,318 INFO  AE_SENDER->AE_RECEIVER (TCPServer-1-7221) [org.dcm4cheri.net.FsmImpl] sending A-RELEASE-RP

Based on what I'm seeing, the second series comes in with tag (0008,0005) set as 'ISO_IR 100', while the original series does not have a value in that tag. As dcm4chee indexes that data, it applies that update above, and it also wipes out study_custom1 from the study table. It doesn't seem that this should be the behaviour as designed.

Any ideas? If it is by design, any suggestions on what I can do to prevent the study_custom1 column be touched in any way once a study has been created in the dcm4chee DB?

thanks in advance,
Jordan

PS> dcm4chee 2.17.2, pgsql, CentOS.

below is the data in the Database (patient/study/series) before and after the second series arrives and is indexed:

BEFORE:

PATIENT TABLE:
139445;;"214385";"AAA";"TEST^PATIENT^^";"D340";"D543";"";"";"19391210";"M";"";"";"";"2013-02-14 21:24:52.918";"2013-02-14 21:24:52.918";"\010\000\005\000CS\000\000\020\000\020\000PN\020\000TEST^PATIENT \020\000 \000LO\006\000214385\020\000!\000LO\004\000WCH \020\0000\000DA\010\00019391210\020\000@\000CS\002\000M \020\000\000@LT\000\000";
STUDY TABLE:
162700;139445;;"1.3.39.19600601.2.2.999.20130211.225257088.18467";"1111111";"2013-02-11 23:07:13";"2222222";"REF^PHYS^^";"O660";"J520";"";"";"CT CERV SPINE W/O CONTRAST";"";"";"";"";"CT";"1.2.840.10008.5.1.4.1.1.2";1;2;"";"AE_RECEIVER";"";"";0;0;"";"2013-02-14 21:24:52.921";"2013-02-14 21:24:54.675";"\010\000\005\000CS\000\000\010\000 \000DA\010\00020130211\010\0000\000TM\012\000230713.000\010\000P\000SH\010\0002222222 \010\000\220\000PN\014\000OREF^PHYS \010\0000\020LO\032\000CT CERV SPINE W/O CONTRAST \000\015\000UI0\0001.3.39.19600601.2.2.999.20130211.225257088.18467 \000\020\000SH\010\0001111111 \000!@\001AE\014\000AE_RECEIVER ";
SERIES TABLE:
611860;162700;;;"1.2.392.200036.9116.2.6.1.48.1211465793.1360591661.226664";"1";"CT";"";"";"2.0";"HOSPITAL";"ID_STATION";"ID_DEPARTMENT";"";"*";"*";"";"";"2013-02-11 23:07:13";"";"";"AE_RECEIVER";"";2;"AE_SENDER";"";"AE_RECEIVER";"";"";0;1;"2013-02-14 21:24:52.922";"2013-02-14 21:24:54.658";"\010\000\005\000CS\000\000\010\000!\000DA\010\00020130211\010\0001\000TM\012\000230740.328\010\000`\000CS\002\000CT\010\000p\000LO\010\000TOSHIBA \010\000\200\000LO\032\000WHospital ABC\010\000\020\020SH\012\000ID_STATION\010\000>\020LO\004\0002.0 \010\000@\020LO\016\000ID_DEPARTMENT \010\000P\020PN\000\000\010\000\220\020LO\010\000Aquilion\030\000\025\000CS\000\000 \000\016\000UI:\0001.2.392.200036.9116.2.6.1.48.1211465793.1360591661.226664\000 \000\021\000IS\002\0001  \000`\000CS\000\000@\000D\002DA\010\00020130211@\000E\002TM\012\000230713.000\000!@\001AE\014\000AE_RECEIVER "

AFTER:

PATIENT TABLE:
139445;;"214385";"AAA";"TEST^PATIENT^^";"D340";"D543";"";"";"19391210";"M";"";"";"";"2013-02-14 21:24:52.918";"2013-02-14 21:26:32.567";"\010\000\005\000CS\012\000ISO_IR 100\020\000\020\000PN\020\000TEST^PATIENT \020\000 \000LO\006\000214385\020\000!\000LO\004\000WCH \020\0000\000DA\010\00019391210\020\000@\000CS\002\000M \020\000\000@LT\000\000";
STUDY TABLE:
162700;139445;;"1.3.39.19600601.2.2.999.20130211.225257088.18467";"1111111";"2013-02-11 23:07:13";"2222222";"REF^PHYS^^";"O660";"J520";"";"";"CT CERV SPINE W/O CONTRAST";"";"";"";"";"CT";"1.2.840.10008.5.1.4.1.1.2";2;3;"";"AE_RECEIVER";"";"";0;0;"";"2013-02-14 21:24:52.921";"2013-02-14 21:26:32.709";"\010\000\005\000CS\012\000ISO_IR 100\010\000 \000DA\010\00020130211\010\0000\000TM\012\000230713.000\010\000P\000SH\010\0002222222 \010\000\220\000PN\014\000OREF^PHYS \010\0000\020LO\032\000CT CERV SPINE W/O CONTRAST \000\015\000UI0\0001.3.39.19600601.2.2.999.20130211.225257088.18467 \000\020\000SH\010\0001111111 \000!@\001AE\014\000AE_RECEIVER ";
SERIES TABLE:
611860;162700;;;"1.2.392.200036.9116.2.6.1.48.1211465793.1360591661.226664";"1";"CT";"";"";"2.0";"HOSPITAL";"ID_STATION";"ID_DEPARTMENT";"";"*";"*";"";"";"2013-02-11 23:07:13";"";"";"AE_RECEIVER";"";2;"AE_SENDER";"";"AE_RECEIVER";"";"";0;1;"2013-02-14 21:24:52.922";"2013-02-14 21:24:54.658";"\010\000\005\000CS\000\000\010\000!\000DA\010\00020130211\010\0001\000TM\012\000230740.328\010\000`\000CS\002\000CT\010\000p\000LO\010\000TOSHIBA \010\000\200\000LO\032\000WHospital ABC\010\000\020\020SH\012\000ID_STATION\010\000>\020LO\004\0002.0 \010\000@\020LO\016\000ID_DEPARTMENT \010\000P\020PN\000\000\010\000\220\020LO\010\000Aquilion\030\000\025\000CS\000\000 \000\016\000UI:\0001.2.392.200036.9116.2.6.1.48.1211465793.1360591661.226664\000 \000\021\000IS\002\0001  \000`\000CS\000\000@\000D\002DA\010\00020130211@\000E\002TM\012\000230713.000\000!@\001AE\014\000AE_RECEIVER "

[fleetwoodfc]

How do you populate the study_custom1 column ?

[jne...@gmail.com]

Through an external system doing a direct DB connection to the study table. I believe the only thing it does is insert a value in study_custom1, and the column is not used by anything else for any other purpose.

Jordan

[Damien Evans]

You should create your own column for this if you're using it for your own purposes and not using it through dcm4chee.  It is probably getting wiped because it is part of the dcm4chee data model, and dcm4chee is not aware that it is being used.

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[jne...@gmail.com]

Thanks for the replies.

I guess when I said nothing else uses the study_custom1, I meant nothing else *updates* it... It is exposed via the dcm4chee attribute filter to provide custom C-FIND functionality, using the information stored in the column. I'm not sure I can achieve that with an additional custom column/table...

Is there a better way for us to be setting the value in study_custom1, via one of the standard dcm4chee interfaces (ORM, XDS, etc?), which would ensure that dcm4chee is aware that the column has data in it, and not over-write it?

Also, I do have control over the sending application (also a dcm4chee instance). I have tried using coercion at the sender to set the 0008,0005 to 'ISO_IR 100' for all sent images (using out-cstorerq.xsl), but I do not seem to be able to coerce that specific tag. Is it protected in some way? My thought is that if I can make the data consistent at the sender, the receiver would not have the need to update instances received earlier, thereby avoiding the removal of the value in study_custom1 altogether.

Jordan

[jne...@gmail.com]

My eventual workaround was to coerce the Specific Character Set tag to 'ISO_IR 100' on inbound, as the studies were being received, thereby removing the 'update' that was clearing the study_custom1 DB column... I was unable to coerce that tag on outbound, on the system that was sending the images...