Write generated PID to DICOM file

159 views
Skip to first unread message

Jack Pipes

unread,
Feb 4, 2020, 10:27:15 AM2/4/20
to dcm...@googlegroups.com
Hey folks,

I use dcm4chee-arc-light (secure, 5.19.1, 2c0b8a0, 2019-11-14), running with Docker.

I created 2 Networks AEs, with 2 separated file systems.
The first AE (P1) has a « Export rule » to export received data to the secondary AE (P2). The « Attribute coercion » of the P1 archive is also configured to de-identify (BasicApplicationConfidentialityProfile, RetainDeviceIdentityOption, RetainLongitudinalTemporalInformationFullDatesOption are checked) studies on C_STORE_RQ, so exported studies to P2 are properly anonymized following previously defined rules.

I also configured the PatientID ID Generator to make the format fit with my needs and « Accept Missing Patient ID » is set to CREATE option at archive level.

Everything seems to works as expected: studies received by P1 are automatically forwarded to P2, de-identified, and from what I see through the UI, with a new PatientID sequentially attributed as defined by the generator.

I noticed some issue I do not really understand regarding the attribution of the PID:

1) when I update the pathFormat of the « Storage property » of the P2 filesystem and try to use the PID (00100020) as a component of the path, all I get is a « null » value.

2) the final file written by P2 does not contain the generated PID in DICOM metadata: if I export the file at filesystem level to another DICOM compliant software, the 00100020 attribute is empty. But when accessing the file from a DICOM service (Q/R) the PID attribute is properly distributed with the file. 

So... Am I missing something, somewhere, that could changes this behaviour to have the PID written on-the-fly in the DICOM files of the P2 archive during the process? 
Maybe what I am trying to achieve is not possible at all, or not in this configuration.. 

Any help is greatly appreciated.

Best regards

JP

Gunter Zeilinger

unread,
Feb 4, 2020, 3:01:35 PM2/4/20
to dcm...@googlegroups.com
The file is streamed as received from the TCP channel - therefore only attributes in the received data set are available for the path format. DB update,  including Patient ID generation happens after.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, February 4, 2020 4:27 PM, Jack Pipes <jackp...@gmail.com> wrote:

Hey folks,

I use dcm4chee-arc-light (secure, 5.19.1, 2c0b8a0, 2019-11-14), running with Docker.

I create 2 Networks AEs, with 2 separated file systems.
The first AE (P1) has a « Export rule » to export received data to the secondary AE (P2). The « Attribute coercion » of the P1 archive is also configured to de-identify (BasicApplicationConfidentialityProfile, RetainDeviceIdentityOption, RetainLongitudinalTemporalInformationFullDatesOption are checked) studies on C_STORE_RQ, so exported studies to P2 are properly anonymized following previously defined rules.

I also configured the PatientID ID Generator to make the format fit with my needs and « Accept Missing Patient ID » is defined with CREATE option at archive level.

Everything seems to works as expected: studies received by P1 are automatically forwarded to P2, de-identified, and from what I see through the UI, with a new PatientID sequentially attributed as defined by the generator.

I noticed some issue I do not really understand regarding the attribution of the PID:

1) when I update the pathFormat of the « Storage property » of the P2 filesystem and try to use the PID (00100020) as a component of the path, all I get is a « null » value.

2) the final file written by P2 does not contain the generated PID in DICOM metadata: if I export the file at filesystem level to another DICOM compliant software, the 00100020 attribute is empty. But when accessing the file from a DICOM service (Q/R) the PID attribute is properly distributed with the file. 

So... Am I missing something, somewhere, that could changes this behaviour to have the PID written on-the-fly in the DICOM files of the P2 archive during the process? 
Maybe what I am trying to achieve is not possible at all, or not in this configuration.. 

Any help is greatly appreciated.

Best regards

JP


--
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.

Message has been deleted

Jack Pipes

unread,
Feb 5, 2020, 3:32:15 AM2/5/20
to dcm4che
Ok for the path format. It is what it is. 
But what about DICOM files written in the storage file system that do not include the de-identified PID generated just before?

If I import a de-identified study directly as DICOM files from the filesystem after de-identification, the PID is missing
If I retrieve the same study from the QR service, the study is identified by the expected de-identified PID

It results in a very confusing situation where I can't trust raw DICOM files stored in the FS when stored separated from their dataset informations, which is critical in case of low-level data migration.
Is it a bug or a wanted behaviour regarding de-identification? Any way to change the way it is?

Gunter Zeilinger

unread,
Feb 5, 2020, 3:42:42 AM2/5/20
to dcm...@googlegroups.com
It's intended to preserve the received data sets in the files, separated from potential modified attributes in the DB.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, February 5, 2020 9:28 AM, Rafaël Warnault <rafael....@gmail.com> wrote:

Ok for the path format. It is what it is. 
But what about DICOM files written in the storage file system that do not include the de-identified PID generated just before?

If I import a de-identified study directly as DICOM files from the filesystem after de-identification, the PID is missing
if I retrieve the same study from the QR service, the study is identified by the expected de-identified PID

It results in a very confusing situation where I can't trust raw DICOM files stored in the FS when stored separated from their dataset informations, which is critical in case of low-level data migration.
Is it a bug or a wanted behaviour regarding de-identification? Any way to change the way it is?
--
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.

Jack Pipes

unread,
Feb 5, 2020, 4:05:33 AM2/5/20
to dcm4che
Thank you, understood. What are then my options if I want DB attributes to be systematically written to DICOM files?

If I want for example, to massively export terabytes of DICOM files WITH their modified attributes, my only option is to rely on DICOM / RESTful services to do so?

Sorry to bother, but understanding this is critical to me. 

Gunter Zeilinger

unread,
Feb 5, 2020, 5:48:35 AM2/5/20
to dcm...@googlegroups.com
As already mention, you may use the WADO exporter to trigger retrieve by WADO-URI to another file system for each received object.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
--
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.

Jack Pipes

unread,
Feb 6, 2020, 9:48:09 AM2/6/20
to dcm...@googlegroups.com
Ok, thank you. I made a test by auto-exporting P2 studies to an external AE (for example OsiriX), and I receive DICOM objects including the de-identified PID, as expected.

It leads me to the following idea: I could auto-export to a third network AE (P3) in order to benefit from the attributes coerced from P2.
So I added a P3 network AE to my workflow, in order to auto-export de-identified studies received by P2 from P1.

I was hoping this way, studies were pushed with DB Attributes, but it does not work at all. P3 never store anything.
Reading the logs I see that P3 rejected instances because they already exist:

2020-02-06 15:18:01,552 INFO  [org.dcm4chee.arc.store.impl.StoreServiceEJB] (EE-ManagedExecutorService-default-Thread-136) P3<-P2(44): Found previous received Instance[pk=37, uid=2.25.327705330358166221543229875338335090046, class=1.2.840.10008.5.1.4.1.1.4, no=2]

2020-02-06 15:18:01,552 INFO  [org.dcm4chee.arc.store.impl.StoreServiceEJB] (EE-ManagedExecutorService-default-Thread-136) P3<-P2(44): Ignore received Instance[studyUID=2.25.215971305378796889435305034160506254466,seriesUID=2.25.12269677281930449655034890228342064203,objectUID=2.25.327705330358166221543229875338335090046] from different source

So yes, from what I see, instances already exist in P2, but not in P3, which has a different storage, different Access Control ID, different Store Access Control ID and the Export Rule is set to REPLACE reoccured instances. 

Is that the way it is supposed to work? Is there a way to accomplish what I want? ie. store the same study multiple times in several completely isolated Network AE.

Best regards,

JP

Gunter Zeilinger

unread,
Feb 6, 2020, 11:01:30 AM2/6/20
to dcm...@googlegroups.com
By default configuration, the archive ignores reoccurred objects, received from a different AET as the previous received one.

Again: better to use a wado exporter:

URI: wado:http://<archive-host>:8080/dcm4chee-arc/aets/DCM4CHEE/wado?requestType=WADO&studyUID=[0]&seriesUID=[1]&objectUID=[2]
Property: StorageID=export-fs

and configuring an additional file storage system with matching StorageID.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
JC


--
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.

Reply all
Reply to author
Forward
0 new messages