Understanding the ORUService and mapping from ORU to SR

[Pablo Pazos]

Hi, I'm designing some tests for the ORUService, and I have a couple of questions from reading forum entries about how and where DICOM data should come in the ORU message.

It was stated here (http://forums.dcm4che.org/jiveforums/message.jspa?messageID=18637) that if the Study Instance UID is not present on an OBX segment, then a query by the Accession Number is done to find the right study to link the SR to it.

But I can't find where the Accession Number should be in the ORU message.

Also, looking at oru2sr.xsl it doesn't contain any rule to extract the Accession Number from the ORU.

In the other hand, I found this issue on JIRA "ORU Service shall query for Studies with matching Accession Number" (http://www.dcm4che.org/jira/browse/DCMEE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel). Looking at the code fix (http://sourceforge.net/p/dcm4che/svn/2687), it certainly doesn't complies with the description, it just generate a new Study Instance UID instead of grabbing the one in the ORU message (the one I don't know where to put in the ORU msg). IMO this issue should be considered to be reopened to have a proper fix to the issue. Here is my comment on JIRA:

--------------
Looking at the fix in the ORUService, the code doesn't implement the description of this issue, instead of querying the ORU for the accession number and use that to query DCM4CHEE's DB, if the Study Instance UID is not present in the ORU, the ORUService generates a random  Study Instance UID. I'm sure this behavior can cause many problems, like not linking SRs to the correspondent study.

Also, the location of the accession number in the ORU message is not stated anyware, not here nor in the docs. There is one forum message suggesting to user ORC-3 to put the accession number.

Another important thing: the current oru2sr.xsl is not extracting the accession number from the ORU message, it doesn't contain a rule to do that.
---------------

Sorry for the long email. Please let me know your thoughts.

Thanks!

---
Pablo Pazos
www.CaboLabs.com

[Pablo Pazos]

I've sent some ORUs to see the results and I'm getting these exceptions **, any ideas? Thanks!

**

2014-03-07 00:52:27,772 WARN  -> (TCPServer-2) [org.dcm4cheri.data.StringElement] Illegal UID value: Findings PA evaluation of the chest demonstrates the lungs qwert

2014-03-07 00:52:27,776 WARN  -> (TCPServer-2) [org.dcm4cheri.data.StringElement] Illegal UID value: History Cough

2014-03-07 00:52:27,777 WARN  -> (TCPServer-2) [org.dcm4cheri.data.StringElement] Illegal character '

' in value: Language of Content Item and

         Descendants

This is the test message:

MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|REPOSITORY|XYZ|||ORU^R01|MESA4b141a5d|P|2.3.1||||||||

PID|1||CR3^^^ADT1||CRTHREE^PAUL|||||||||||||PatientAcct|||||||||||||||||||||

OBR|1|A601Z^MESA_ORDPLC|B601Z^MESA_ORDFIL||||20010501141500.0000||||||||||||||||||F

OBX|1|HD|^Study Instance UID||1.3.51.0.7.633918642.633920010109.6339100821||||||F||||||

OBX|2|HD|^SR Instance UID||1.113654.1.2001.30.2.1||||||F||||||

OBX|3|TX|^SR Text||History Cough||||||F||||||

OBX|4|TX|^SR Text||Findings PA evaluation of the chest demonstrates the lungs qwert||||||F||||||

OBX|5|TX|^SR Text||Conclusions Normal PA chest x-ray.||||||F||||||

[fleetwoodfc]

Looks like you are trying to map regular text to a DICOM UI element - which expects a UID value.

[Pablo Pazos]

In fact, I took a the ORU from DCM4CHE forums because I couldn't find any example of a working format and the mapping rules used in dcm4che ORUService, nor in the docs, nor in ORUService tests (don't know if there exists unit/integration tests of the service).

Some questions arises:

Why the service tries to parse the OBX value that is marked as TX with "SR Text" in the Observation ID?

Shouldn't that be processed as text for the SR because it is marked with "SR Text"?

Testing, I reached the conclusion that ORUService expects some UIDs to be in the message to don't throw the "Illegal UID" exception. This is the changed message I needed to send to avoid getting the exception:

MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|REPOSITORY|XYZ|||ORU^R01|123567876543|P|2.3.1

PID|1||5555555||MISTER^CR|||||||||||||123456444

OBR|1|A601Z^MESA_ORDPLC|B601Z^MESA_ORDFIL|^pelvis|||20010501141500||||||||||||||||||F|||||||||||20010109100821

OBX|1|HD|^Study Instance UID||1.3.51.0.7.633918642.633920010109.6339100821||||||F

OBX|2|HD|^Series Instance UID||1.3.51.0.7.11111.22222.33333||||||F

OBX|3|HD|^SOP Instance UID||1.3.51.0.7.11111.22222.33333.5555||||||F

OBX|4|HD|^SR Instance UID||1.3.51.0.7.11111.22222.33333.4444||||||F

OBX|5|TX|^SR Text||History aaaaaaaaaaaaa||||||F

OBX|6|TX|^SR Text||Findings bbbbbbbbbbbbbbbbbbbbbbbbbbb||||||F

OBX|7|TX|^SR Text||Conclusions cccccccccccccccccc||||||F

Does anybody have any ideas why the service requires all those UIDs? Shouldn't the Study Instance UID suffice?

Another question: what's the meaning of SOP Instance UID going in the ORU?

Is that the UID of a related image or is the UID that will be assigned to the SR object in the database? If the second case is correct, what's the difference between SOP Instance UID and SR Instance UID?

Also, I'm getting warnings about the Accession Number not matching the one of the study, but, where does the Accession Number be in the ORU message?

FYI: I've read related threads in the forum, went through JIRA issues, DCM4CHE doc, and also analyzed the oru2sr.xsl and the ORUService.java code, and is still not clear to me 1. where to put required data in the ORU, 2. and what are the mapping rules implemented by default in DCM4CHE. For example, the oru2sr.xsl seems not to search for Accession Number in the ORU, but ORUService throws a warning about not matching Accession Number.

Thanks!

[fleetwoodfc]

Better to supply to much information than not enough :)

Looks to me like the message you are using is from exporting an existing SR object as an ORU^R01 - hence all the UIDs.

 

Here is my theory: To create a SR  then if the Study UID is supplied (in the ORU) then that should be mapped to the SR StudyUID tag. DCM4CHEE will then use the UID to store the SR as a new series in the existing study. 

If no accession number is provided and the existing study has one then you will see the mis-match warning. 

If you map the Accession number and do not provide a Study UID then DCM4CHEE will look-up the study uid using the Accession number and if it finds a match will store the SR with the found study.

p.s. Typically OBR-3 is the Accession number.

[Pablo Pazos]

Hi!

On Friday, March 7, 2014 9:08:57 PM UTC-2, fleetwoodfc wrote:

Better to supply to much information than not enough :)

Looks to me like the message you are using is from exporting an existing SR object as an ORU^R01 - hence all the UIDs.

 

I'm trying to send the ORU to DCM4CHEE to generate the SR and relate it to an existing study (e.g. I have a study in the PACS storage with the Study Instance UID I send in the ORU message).

Do you have any ORU message as a format example to let me try the oru2sr?
 

Here is my theory: To create a SR  then if the Study UID is supplied (in the ORU) then that should be mapped to the SR StudyUID tag. DCM4CHEE will then use the UID to store the SR as a new series in the existing study. 

Totally agree, but where should I put the Study Instance UID in the ORU message?

The only example I could find uses OBX to map UIDs, but I think the right place should be ORC-2 or ORC-3, and maybe on OBR-2 or OBR-3.
 

If no accession number is provided and the existing study has one then you will see the mis-match warning. 

If you map the Accession number and do not provide a Study UID then DCM4CHEE will look-up the study uid using the Accession number and if it finds a match will store the SR with the found study.

p.s. Typically OBR-3 is the Accession number.

As you can see, the message has B601Z^MESA_ORDFIL in OBR-3, but in the reception log of DCM4CHEE tells me that Accession Number is empty. I can send you the full log.

Thanks!
 

[fleetwoodfc]

Had a minute to look at your test message. It is missing OBR-4 Universal Service ID which is a required field - so DCM4CHEE rejects it. Try this:

MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|REPOSITORY|XYZ|||ORU^R01|MESA4b141a5d|P|2.3.1||||||||

PID|1||CR3^^^ADT1||CRTHREE^PAUL|||||||||||||PatientAcct|||||||||||||||||||||

OBR|1|A601Z^MESA_ORDPLC|B601Z^MESA_ORDFIL|B601Z^MESA_ORDFIL^TEST|||20010501141500.0000||||||||||||||||||F

OBX|1|HD|^Study Instance UID||1.3.51.0.7.633918642.633920010109.6339100821||||||F||||||

OBX|2|HD|^SR Instance UID||1.113654.1.2001.30.2.1||||||F||||||

OBX|3|TX|^SR Text||History Cough||||||F||||||

OBX|4|TX|^SR Text||Findings PA evaluation of the chest demonstrates the lungs qwert||||||F||||||

OBX|5|TX|^SR Text||Conclusions Normal PA chest x-ray.||||||F||||||

[Pablo Pazos]

Thanks, I'll try it tonight.

OBR-4 should mean something to the PACS? Should that be the Accession Number? Study UID? Other tag?

Thanks!

BTW if I can gather all these rules I can update dcm4che docs.

Saludos cordiales,
Ing. Pablo Pazos
www.CaboLabs.com

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

[Pablo Pazos]

Hi, I've tried the message and did a little db audit to look for changes, I think I found the problem:

First, this is the sent message:

MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|REPOSITORY|XYZ|||ORU^R01|123567876543|P|2.3.1

PID|1||5555555||MISTER^CR|||||||||||||123456444

OBR|1|A601Z^MESA_ORDPLC|B601Z^MESA_ORDFIL|B601Z^MESA_ORDFIL^test|||20010501141500|||||||||||||||20010109100821|||F|||||||||||

OBX|1|HD|^Study Instance UID||1.3.51.0.7.633918642.633920010109.6339100821||||||F

OBX|2|HD|^Series Instance UID||1.3.51.0.7.11111.22222.33333||||||F

OBX|3|HD|^SOP Instance UID||1.3.51.0.7.11111.22222.33333.5555||||||F

OBX|4|HD|^SR Instance UID||1.3.51.0.7.11111.22222.33333.4444||||||F

OBX|5|TX|^SR Text||History aaaaaaaaaaaaa||||||F

OBX|6|TX|^SR Text||Findings bbbbbbbbbbbbbbbbbbbbbbbbbbb||||||F

OBX|7|TX|^SR Text||Conclusions cccccccccccccccccc||||||F

It seems that the OBR-4-3 component is required ("test" in B601Z^MESA_ORDFIL^test), because ORUService is creating a new record in the "code" database of DCM4CHEE:

  (77,'B601ZMESA_ORDFILtest','test',NULL,'MESA_ORDFIL');

With the schema being:

CREATE TABLE `code` (

 `pk` bigint(20) NOT NULL AUTO_INCREMENT,

 `code_value` varchar(250) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,

 `code_designator` varchar(250) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,

 `code_version` varchar(250) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL,

 `code_meaning` varchar(250) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL, ...

I was receiving an exception of null "code_designator".

Then, that "code" record with pk 77 is referenced from a new record created on "content_item" table, as it's "code_fk": (38,21,76,77,'HAS OBS CONTEXT',NULL);

This "content_item" with pk 38 seems not be used anywhere (no other table has a fk to it).


I also got some warnings about information that doesn't match the existing study: (this shows the received value and the current value in the study)

Where should these field be in the ORU message so DCM4CHEE process them properly?

• study date, study time (doesn't seems to match with OBR-7 Observation Date/Time, nor OBR-22 Results Rpt/Status Chng Date/Time),
  
• Accession Number,
  
• Study Description.

2014-03-10 11:35:52,674 WARN  DCM4CHEE->DCM4CHEE (TCPServer-1) [org.dcm4chex.archive.ejb.entity.StudyBean] Coerce
(0008,0020) Study Date,DA,*0,#0,[] to (0008,0020) Study Date,DA,*1,#8,[20010109]

2014-03-10 11:35:52,679 WARN  DCM4CHEE->DCM4CHEE (TCPServer-1) [org.dcm4chex.archive.ejb.entity.StudyBean] Coerce
(0008,0030) Study Time,TM,*0,#0,[] to (0008,0030) Study Time,TM,*1,#6,[100821]

2014-03-10 11:35:52,679 WARN  DCM4CHEE->DCM4CHEE (TCPServer-1) [org.dcm4chex.archive.ejb.entity.StudyBean] Coerce
(0008,0050) Accession Number,SH,*0,#0,[] to (0008,0050) Accession Number,SH,*1,#10,[0000000006]

2014-03-10 11:35:52,679 WARN  DCM4CHEE->DCM4CHEE (TCPServer-1) [org.dcm4chex.archive.ejb.entity.StudyBean] Coerce
null to (0008,1030) Study Description,LO,*1,#6,[pelvis]


Thanks!

To unsubscribe from this group and all its topics, send an email to dcm4che+unsubscribe@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.

To unsubscribe from this group and all its topics, send an email to dcm4che+unsubscribe@googlegroups.com.

[fleetwoodfc]

Re: Where should these field be in the ORU message so DCM4CHEE process them properly?

I would say DCM4CHEE does process them properly. You have provided a Study UID in the ORU and DCM4CHEE has used this to locate an existing study record and copied the study info from this record to the SR - the study info. is now consistent and there is no need to supply study date/ time etc in the ORU.

To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.

To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.

[Pablo Pazos]

The Study UID is not mentioned in the warning messages, I only asked about those fields that DCM4CHEE is raising warnings because doesn't match the values in the db. IMO those warnings show that DCM4CHEE is not processing the values properly and that can be because:

1. Those values are in the wrong place of the ORU (this seems not to be the case)

2. DCM4CHEE is not processing them while receiving the ORU, but when the DICOM file generated is processed for storage, that checks if the values on the DCM matched the values on the DB (my guess is that's storage validation because the warning is raised by org.dcm4chex.archive.ejb.

entity.StudyBean)

Also, the rules about OBX text and values are still not clear. Please remember my message about that if I didn't include UIDs for series and instance, DCM4CHEE tries to process the SR Text as an UID. It seems DCM4CHEE is not happy to have only the Study Instance UID :) and for the next OBX is not considering the OBX text to do the mapping to the right DICOM tag.

I'll run another test round to try this with the OBR-4 value included to see what I get and I'll report results later.

Thanks!

--

Atte. Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 Skype: cabolabs

http://www.cabolabs.com pablo...@cabolabs.com

[fleetwoodfc]

The oru2sr.xsl is designed to handle 'Structured Report Export' - see section 4.28 IHE_RAD_TF_Vol2

What are you trying to do?

[Pablo Pazos]

Sorry, I don't understand your message. Did you read my previous message? I don't mention oru2sr.xsl anywhere :)

After trying what you proposed about having data on OBR-4, my question was about how DCM4CHEE handles/maps study date, study time, accession number and study description while receiving an ORU from the ORUService to transform it internally and store it as an SR related to an existing study in DCM4CHEE DB.

Sorry if this wasn't clear enough.

As I said, I'm using ORUService and that's to import SRs into DCM4CHEE by sending an ORU^R01 to it, like described here: http://www.dcm4che.org/confluence/display/ee2/ORU+Service

That says ORU is converted to SR using oru2sr.xsl, considering this, I think that should answer your question :)

Thanks!

From the docs:

Description

The ORU HL7 Service converts ORU^R01 into structured reports, so a viewer can just use the PACS system to access the report.

Stylesheet

Stylesheet for HL7 ORU^R01 to DICOM SR mapping.
A relative path name is resolved relative to archive-install-directory/server/default/.

Default Value: conf/dcm4chee-hl7/oru2sr.xsl

[Pablo Pazos]

Should I open an issue on JIRA to check for the warning messages? (and maybe improve the ORU Service docs?).

Cheers,
Pablo.

...

[fleetwoodfc]

In my opinion the warning messages are by design so opening a JIRA will serve no purpose.

The ORU Service is designed to allow for the processing of the many different ORU^R01 mappings that vendors may use. The oru2xsl.xsl file is the default mapping stylesheet but you are free to design your own - whatever works for your particular application. 

The ORU^R01 message could be exported from a reporting system where accession number only is known or could come from a dicom system where Study UID is known. 

p.s. If available, Study UID is not always supplied in OBX  e.g. I have seen it supplied in ZDS. 

 

On Friday, March 7, 2014 1:39:17 PM UTC-5, Pablo Pazos wrote:<blockquote style="margin

...

[Pablo Pazos]

Hi, sorry for the delay, another project demanded full attention :)

On Wednesday, March 12, 2014 4:40:52 PM UTC-3, fleetwoodfc wrote:

In my opinion the warning messages are by design so opening a JIRA will serve no purpose.

The ORU Service is designed to allow for the processing of the many different ORU^R01 mappings that vendors may use. The oru2xsl.xsl file is the default mapping stylesheet but you are free to design your own - whatever works for your particular application. 

Thanks for the description, I understand. IMO the issue is that the default mapping rules are not fully documented and is hard to get a working example as I did without changing the oru2sr.xsl file.

In order to design a new XSL or change the default one, we need to have thorough knowledge of the target XML format, knowledge that I personally don't have.
Can you point me to the documentation and/or XSD that specifies the XML DICOM file used for SRs?
 

The ORU^R01 message could be exported from a reporting system where accession number only is known or could come from a dicom system where Study UID is known. 

That's not my case, as I said: I'm sending ORUs to DCM4CHEE, not exporting ORUs from it.

Just out of curiosity because you mentioned exporting ORUs a couple of times, which service is used for that purpose?
 

p.s. If available, Study UID is not always supplied in OBX  e.g. I have seen it supplied in ZDS. 

That should require to modify the XSL file I think...


Thanks!
 

In the other hand, I found this issue on JIRA "ORU Service shall query for Studies with matching Accession Number" (http://www.dcm4che.org/jira/browse/DCMEE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a

...