mokbelt commented 5 years ago

ver 5.17.1

I am having an issue where some DICOM tags generated in the HL7 MWL, such as (0038, 0010), (0040, 1002), (0040, 0006) - that correctly appear inside the MWL record on the dcm4che-arc-light UI, are lost after the study is received from the modality (although SUPPLEMENT is selected in the "Link MWL Entry Update Policy").

Please clarify how to keep the above tags in the completed study.

mokbelt commented 4 years ago

Is this issue related to settings?

vrindanayak commented 4 years ago

Link MWL Entry Update Policy is not related to feature Update MWL status to COMPLETED for received studies.

Your use case reflects Update MWL status to COMPLETED for received studies feature.

The above mentioned attributes, do get reflected even when the MWL status is COMPLETED (on receive of study)

Please post further questions in the dcm4che User Forum

mokbelt commented 4 years ago

Dear vrindanayak,

Both "Link MWL Entry Update Policy" and "Update MWL status to COMPLETED for received studies" are not related to my case.

In my case: The MWL is pulled directly from modality and the study is sent to dcm4chee and the modality sends the MPPS COMPLETED message; the problem is that before the MWL record is selected from modality (which is while the MWL record is in SCHEDULED status) I can see on the dcm4che UI the tags (0038, 0010), (0040, 1002), (0040, 0006), however when the study is received from modality the mentioned DICOM tags are no longer visible on the received study on dcm4chee UI.

Please advise!

vrindanayak commented 4 years ago

It is the modality's responsibility to populate the values of tags (of interest) from MWL to the study before sending it to archive! As a workaround, you could configure Coerce received DICOM objects attributes by XSLT feature (refer first Use case - Merge from MWL) and update the default stylesheet provided accordingly to accommodate these 3 tags (as they are not part of default Series IOD defined by DICOM, they are not available in the default stylesheet).

mokbelt commented 4 years ago

Dear vrindanayak, Thank you for the clarification... Is it possible to provide a step-by-step example for the attributes (0038, 0010), (0040, 1002), (0040, 0006) inside which xsl sheet? (mwl2series.xsl ? hl7-order2dcm.xsl?)

vrindanayak commented 4 years ago

It is the mwl2series.xsl as explained in the use case.
Reason for the Requested Procedure (0040,1002) is already available inside the Request Attributes Sequence (0040,0275).
For other two attributes i.e. Admission ID (0038,0010) and Scheduled Performing Physician's Name(0040,0006), to be seen on root level, you can do it similar to Accession Number (0008,0050) as shown in the same stylesheet.

mokbelt commented 4 years ago

Thanks. Shall I need to do anything else after modifying the stylesheet?

vrindanayak commented 4 years ago

You just need to configure the feature - Coerce received DICOM objects attributes by XSLT - Use case - Merge from MWL with your updated stylesheet.
Upload your updated stylesheet as part of the Vendor Data - See point Partial Update

mokbelt commented 4 years ago

Did as mentined above, but the tags above weren't coerced, noting that they were visible in the MWL record before the study is received. The mwl2series.xsl file includes the following:

               <!-- Admission ID -->
      <xsl:copy-of select="DicomAttribute[@tag='00380010']"/>
               <!-- Shueduled Perf Physician -->
      <xsl:copy-of select="DicomAttribute[@tag='00400006']"/>

The log gave:

2019-11-27 11:13:51,822 INFO [org.dcm4chee.arc.store.impl.StoreServiceEJB] (EE-ManagedExecutorService-default-Thread-881) SMLPACS<-XC_DICOM(19): Query for MWL Items with MergeMWLQueryParam{accessionNumber='null', studyIUID='2.25.173908173803804260228738351643212707085', spsID='null'} 2019-11-27 11:13:51,822 INFO [org.dcm4chee.arc.store.impl.StoreServiceEJB] (EE-ManagedExecutorService-default-Thread-881) SMLPACS<-XC_DICOM(19): Found 1 matching MWL Items 2019-11-27 11:13:51,837 INFO [org.dcm4chee.arc.store.impl.StoreServiceImpl] (EE-ManagedExecutorService-default-Thread-881) SMLPACS<-XC_DICOM(19): Coerce Request Attributes from matching MWL item(s) using rule: ArchiveAttributeCoercion[cn=AddDICOMTags, priority=0, DIMSE=C_STORE_RQ, role=SCU, aets=[], hostNames=[], cuids=[], retrieveAsReceived=false, deIdentification=[], xslturi=null, noKeywords=true, leadingCFindSCP=null, mergeMWLMatchingKey=StudyInstanceUID, mergeMWLTemplateURI=file:///SMLPACS/wildfly-17.0.1.Final/standalone/tmp/dcm4chee-arc/mwl2series.xsl, attributeUpdatePolicy=SUPPLEMENT, nullifyIssuerOfPatientID=null, issuerOfPatientIDs=[], issuerOfPatientIDFormat=null, supplementFromDeviceName=null] 2019-11-27 11:13:51,884 INFO [org.dcm4chee.arc.store.impl.StoreServiceEJB] (EE-ManagedExecutorService-default-Thread-881) SMLPACS<-XC_DICOM(19): Supplement attributes of Patient[pk=138, id=PatientID[pk=138, id=X19-41-PID-1623, issuer=null], name=omitted^omitted^omitted]: (0010,0032) TM [000000] PatientBirthTime

gunterze commented 4 years ago

Only attributes extracted in the DB according configured Attribute Filters can be coerced in received objects.

mokbelt commented 4 years ago

Please clarify, what Attribute Entity (MWL?, Series?, Study?, Patient?), Attribute Update Policy shall I use for my case above?

gunterze commented 4 years ago

Patient, Study or Series, depended on the Information Entity (IE) the attribute belongs. Be aware that attributes of the Patient Study Module belongs to the Study and not to the Patient IE, because they may vary for different Studies for the same Patient. The Attribute Update Policy defines how to merge attribute values of existing DB records created on receive of previous objects of that entity with attributes with different values in the new received object.

mokbelt commented 4 years ago

if the MWL has the attributes, and the new received object does not have them, shall I use SUPPLEMENT to make the newly received object have the required MWL attributes?

gunterze commented 4 years ago

Read https://dcm4chee-arc-cs.readthedocs.io/en/latest/networking/config/attributeFilter.html#dcmattributeupdatepolicy . The defaults take care, that Patient attributes can only be supplemented but not changed on receive of DICOM object, where Study and Series attributes are always updated to its value in the latest received object - but not nullified if it has no value in the received object.

mokbelt commented 4 years ago

A bit lost!!!! In order to summarize for the future: My request is that I need (0038, 0010), (0040, 1002), (0040, 0006) that are available inside the MWL, to be available also inside the received object. What steps shall I follow to do this?

gunterze commented 4 years ago

2282 #2283 mwl2series.xsl

gunterze commented 4 years ago

Yes, but you may just take the modified mwl2series.xsl and refer it as Merge MWL Template URI in your configured Attribute Coercion also in v5.17.1.

mokbelt commented 4 years ago

I am using this configuration but the supplement attributes (0038, 0010), (0040, 1002), (0040, 0006) are not being added to the received object: