Deleted Studies

[Max White]

Hi All !

Recently all the tests that are sent from a AGFA-DX to dcm4chee are deleted after they are received.

There are no studies with the same Accession Number or Patient ID in dcm4chee, but the study is discarded and deleted.

Please ! How can I avoid this?

17:18:32,551 INFO  [StoreScpService] Received Instance[uid=1.3.51.0.7.11191222821.30829.31296.46016.28747.21578.10537] already exists - ignored

17:18:32,551 INFO  [StoreScpService] M-DELETE file:/home/stratus/archive/2012/12/10/17/C0CD8414/FA0A9A89/4ED94016

17:18:32,553 INFO  [FsmImpl] sending [pc-57] 4:C_STORE_RSP

        class:  1.2.840.10008.5.1.4.1.1.1.1/Digital X-Ray Image Storage - For Presentation

        inst:   1.3.51.0.7.11191222821.30829.31296.46016.28747.21578.10537/?

        status: 0

[Damien Evans]

It appears that these Instance UIDs already exist in dcm4chee:

Received Instance[uid=1.3.51.0.7.11191222821.30829.31296.46016.28747.21578.10537] already exists - ignored

....so, the study must have already been stored.  You say there is no matching accession number or patient id in the database, but is the modality populating the accession number and patient id correctly (i.e. does the patient id and accession number that you are querying with match what is in the images)?

 -- Damien

[Max White]

Tks Damien for your answer !

Yes,  the Accession Number and Patient id are correct in the image. 

One important detail: this same dcm4chee instance is active forward rules to another remote dcm4chee instance.

In remote dcm4chee instance studies are archive without problems. 

[Max White]

Complementing ...

studies are sent by the forward rules to a dcm4chee remote instance, but are deleted locally on dcm4chee local instance.

Any suggestions ?

[Damien Evans]

Can you run these SQL queries on your database and post the results?

select i.pk, p.pat_id, st.accession_no, i.created_time, i.updated_time from patient p, study st, series ser, instance i where p.pk=st.patient_fk and st.pk=ser.study_fk and i.series_fk=ser.pk and i.sop_iuid='1.3.51.0.7.11191222821.30829.31296.46016.28747.21578.10537';

select pk, created_time from priv_instance where sop_iuid='1.3.51.0.7.11191222821.30829.31296.46016.28747.21578.10537';

 -- Damien

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To post to this group, send email to dcm...@googlegroups.com.
To unsubscribe from this group, send email to dcm4che+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che?hl=en.
 
 

[Max White]

Hi Damien

unfortunately the database administrator is not granted me access, however, have some logs, mean something?

2012-11-20 15:53:35,307 WARN  NXRX->DCM4CHEE (TCPServer-1-2) [org.dcm4chex.archive.ejb.session.StorageBean] inserting records for instance[uid=1.3.51.0.7.3175977887.25552.54849.34610.3776.39959.33587] failed: Storage would require forbidden Coercion of (0020,000D) Study Instance UID,UI,*1,#58,[1.3.51.0.7.13386965386.40897.42305.39441.17963.18479.16322] to (0020,000D) Study Instance UID,UI,*1,#54,[1.3.51.0.7.12235967132.9195.3662.48477.28293.6578.5681]

2012-11-20 15:53:35,307 WARN  NXRX-> DCM4CHEE (TCPServer-1-2) [org.dcm4chex.archive.dcm.storescp.StoreScpService] failed to update DB with entries for received 2012/11/20/15/FF6DBAD1/CEE1C91F/6F069080 - retry

org.dcm4che.net.DcmServiceException: Storage would require forbidden Coercion of (0020,000D) Study Instance UID,UI,*1,#58,[1.3.51.0.7.13386965386.40897.42305.39441.17963.18479.16322] to (0020,000D) Study Instance UID,UI,*1,#54,[1.3.51.0.7.12235967132.9195.3662.48477.28293.6578.5681]

        at org.dcm4chex.archive.ejb.entity.AttrUtils.coerceAttributes(AttrUtils.java:80)

        at org.dcm4chex.archive.ejb.entity.StudyBean.coerceAttributes(StudyBean.java:1062)

        at sun.reflect.GeneratedMethodAccessor161.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at org.jboss.invocation.Invocation.performCall(Invocation.java:359)

        at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)

        at org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor.invoke(JDBCRelationInterceptor.java:87)

        at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:284)

        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)

        at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)

        at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:278)

        at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)

        at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)

        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)

        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)

        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)

        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)

        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)

        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)

        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)

        at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)

        at org.jboss.ejb.Container.invoke(Container.java:960)

        at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:430)

        at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:65)

[Damien Evans]

Ah yes...  It looks like someone is storing images with an Instance UID that is already in the database but with a different Study UID.  That's not good.  Do you know what device is sending this data in or what the workflow is?  Something is not happening as it should on the sending side.

[Max White]

Yes Damien ! AGFA CR, i do not like the connectivity dicom unit of this device, terrible!

The other problem I mentioned is because the modality is already sending images with UID's already on the PACS, correct?

already exists - ignored [StoreScpService] M-DELETE

Briefly this is a problem of generating UIDs in the modality, right ?

Apparently there is no problem with the PACS, correct ?

Tks a lot !

[Arnold Maderthaner]

The already exists - ignored message is because the modality uses the same SOP Instance UID for an object that is already in your system. 

The stack trace is because it object that is coming into the system has a different UID Structure (Study/Series/SOPInstanceUID) combination as explained by damien.
The problem will be to define who did the wrong thing (so who generates the wrong UIDs). Maybe you can configure the AGFA CR system to use a different prefix for the UIDs generated.

yours

Arnold

[Max White]

Hi Arnold

Just one question: both exams are sent to two installations of dcm4chee, a remote dcm4chee and a local dcm4chee.

Just local dcm4chee presents this UID problems. The remote instalation works fine.

There is any chance I have some problem with this setup local dcm4chee ?

Thank you !

[Damien Evans]

You probably don't see the problem on the remote dcm4chee instance because the bad images do not get forwarded to it.

We do not think there is a problem with how dcm4chee is set up.  The problem is with the images that are being sent.  From what you have told us, it looks like duplicate instance UIDs are being sent in with a new study or series UI.  You may need to investigate this on the modality side.  For example, instance UID 1.3.51.0.7.3175977887.25552.54849.34610.3776.39959.33587 was first sent to dcm4chee with study UID 1.3.51.0.7.13386965386.40897.42305.39441.17963.18479.16322 but then is sent a second time with study UID 1.3.51.0.7.12235967132.9195.3662.48477.28293.6578.5681.  Another possibility is that these images were originally sent to dcm4chee, then merged to a new study, and then the images were sent in again.  

The bottom line is that you'll need to investigate the workflow to see how this erroneous behavior is happening.

 -- Damien

[Nivaldo Bueno]

hello.

we went through a similar problem, we opened a call for technical AGFA and made ​​some alterations in CR and even returned to work perfectly. He also gave us an explanation not acceptable because it did a reload software (formatting), then returned to normal terms without an explanation

[simonmd]

Hello Nivaldo,

I am having exactly the same problem with some AGFA NX stations recently, do you know what modifications AGFA did on your systems to make it work? Anything I can tell the AGFA support techs here in Colombia so I can guide them? Or did they just reformat without knowing what the problem was?

Thanks !