PACS Integration - PACS to Modality- Work list does not flow to modality

ramashish · September 23, 2019, 8:34pm

Bahmni 0.92 local set up with PACS installed. The Bahmni order gets synced with PACS but does not flow to modality. We have set modality table (with name, description, ip and port of the modality) and order type table as mentioned in the wiki and the “How to Integrate Bahmni with Fuji CR” by @arjun blog. We noticed that the work list on PACS does not display Station AET and Station Name

Whereas the image shown in the blog displays Station AET and Station Name.

When we tried DICOM Echo from DCM4CHEE Application Entities it does not succeed for the modality as shown below

Are we missing any settings?

ramashish · September 23, 2019, 11:44pm

This must be because Default Station AET, Station Name and Modality is not set in ip:8055/jmx-console/HtmlAdaptor as mentioned Setup DCM4CHEE as Modality worklist

In our case we have multiple modalities (CT, US etc.). As mentioned in the above wiki, is there any example of “customising the above mentioned stylesheet to look at the order name and determine the modality”?

@arjun

arjun · September 24, 2019, 6:25am

Getting the MWL to work with individual Modalities:

@ramashish i just had a call with one of your teammates at the site. The Default Station AET, Station name and Modality definitely have to be set through dmc4chee jmx-console.

Supporting multiple modalities would be a subsequent step. I would suggest first is to get it working with hardcoded values for each of the modality one by one. Because in my experience that’s where the major challenge lies as it requires interaction with modality support engineer and work on their part. Usually they don’t have knowledge about this as it seems such kind of integration isn’t very common (your teammate corroborated that based on his conversation with modality support engineers there). So initially you may have to sort out to see whether the MWL feature is available and accessible on modality - usually it requires additional modules to be installed by them, whether it has been setup correctly to pass relevant query params , etc and get the work items flowing from dcm4chee to modality.

Supporting multiple modalities:

Ideally the HL7 message from Bahmni should contain this information. I think the feature is in the product backlog. Not a very big feature and as you have a real usecase to test this against, would be great if you can spare capacity to develop and contribute to product. But for the workaround, customising the stylesheet would be the way forward. I am not aware of any existing example for this specific usecase but should be like any other xsl transformation. Going through general documentation of the same(https://www.w3schools.com/xml/xsl_transformation.asp) and trying it out should help.

ramashish · September 24, 2019, 3:54pm

Thank you for the call. Yes, we have set these parameters through jmx-console but the technical reference manual does not state exact values/names for these parameters.

One more thing that we learned today is to test communication with modality through DCM4Chee. On DCM4Chee there is a menu “Application Entities” where ip and port of the modality can be entered to do a DICOM Echo test. If this echo test succeeds it means that the connection has been established.

The same ip and port is now set in modality in bahmni_pacs database. We are using GE Healthcare’s CT Revolution ACT. Getting the port for the modality was a tough thing but finally we got the port in the modality’s “Revolution ACTs Dicom Conformance Statement”

For the duplicate orders the HL7 Acknowledgement message is rightly seen in /var/log/pacs-integration/pacs-integration.log is as follows

MSH|^~\&||||BahmniEMRBahmniEMR|||ACK|1|P|2.5
MSA|AR|1569084438122436|Duplicate MWLItem[pk=30, spsId=ORD-436.1, spsStartDateTime=2019-09-21 22:17:17.964, spsStatus=SCHEDULED, stationAET=ct99, rqProcId=ORD-436.1, modality=CT, accessionNo=ORD-436, patient->ejb/Patient:9

Though the error thrown is misleading

Unable to send the message to the modality 
 `org.bahmni.module.pacsintegration.services.ModalityService.processAcknowledgement(ModalityService.java:68) ~[ModalityService.class:?]`

But for the new orders it does not show any information in this log so it is difficult to know in such cases if the message was sent to modality or not.

For such new orders we see the related HL7 message in /var/lib/bahmni/dcm4chee-2.18.1-psql/server/default/log/server.log

   MSH-4:BahmniEMR^BahmniEMR
   MSH-7:2019092412
   MSH-9:ORM^O01
   MSH-10:15693070177321274
   MSH-11:P
   MSH-12:2.5
   PID-3:UH-LRU10149
   PID-5:^UH-LRU10149
   PID-7:19740924000000+0530
   PID-8:M
   ORC-1:NW
   ORC-2:ORD-1274
   ORC-3:ORD-1274
   ORC-7:^^^^^ROUTINE
   ORC-10:^^BahmniEMR
   ORC-12:c1c26908-3f10-11e4-adec-0800271c1b75^^Super Man
   OBR-4:CTWAWTC4014^CTWAWTC
   OBR-39:^CT SCAN WHOLE ABDOMEN WITHOUT CONTRAST
   OBR-43:^Ram,IPLit

But such worklist item is not seen on modality.

So as @arjun has rightly mentioned here

We can see the worklist on DCM4Chee but not able to set modality to poll DCM4Chee (Does it actually poll?) to fetch the worklist item and display in modality’s console.

ramashish · September 25, 2019, 1:11am

Does the modality (CT Scanner in our case) really polls DCM4CHEE or does the pacs-integration service sends the message to modality? How to interpret this line of code if it (CT Scanner) is polling?

newClientConnection = hapiContext.newClient(modality.getIp(), modality.getPort(), false);
Initiator initiator = newClientConnection.getInitiator();
return initiator.sendAndReceive(requestMessage);

This question is because though have set DCM4Chee details on the modality (CT Scanner) console

We still get error when work list item menu is selected on modality (CT Scanner) console

arjun · September 25, 2019, 11:02am

pacs-integration service sends messages to PACS (dcm4chee in this case) and doesn’t directly talk to modality (like a CR or CT). The name of the table modality in the service is misleading in that sense.

The modality polls the worklist items from MWL SCP it is configured to poll from. In this case that MWL SCP will be part of dcm4chee. Its not clear from your first screenshot whether the details have been configured at the right place. Just doing some guesswork here : It might be that this is configured for archive service of modality, that is where it is supposed to send the study(image) when it is submitted. Usually that is what support engineers are aware of as that is the common usecase. You need to configure it in the MWL SCU service.

ramashish · September 25, 2019, 5:09pm

Do you think we should state this clearly in wiki? modality table in this case refers to connecting DCM4CHEE’s Modality Worklist or something similar so to bring more clarity in our documentation?

Is it true for all modalities (X-RAY, CT, US etc)? If so this also need direct mention in wiki.

I get your point and also found these definitions in CT Revolution ACT (the modality which we are trying with) Dicom Conformance Statement but we could not find the proper SCU related UI on this modality

Service Class Provider (SCP) – role of an Application Entity that provides a DICOM network service; typically, a server that performs operations requested by another Application Entity (Service Class User). Examples: Picture Archiving and Communication System (image storage SCP, and image query/retrieve SCP), Radiology Information System (modality worklist SCP) .

Service Class User (SCU) – role of an Application Entity that uses a DICOM network service; typically, a client. Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation (image query/retrieve SCU)

ramashish · September 26, 2019, 1:57am

@arjun In order to enable our modality CT Revolution ACT to poll/fetch the modality worklist from DCM4CHEE, we have set HIS Server IP - DCM4CHEE IP AE Title - DCM4CHEE Port - 2575

We still do not see the work list on modality (CT Revolution ACT). Do you know what port DCM4CHEE listens on to fulfill modality’s request? Point # 6.2 “Enable network worklist feature in the modality software” in your blog

OR do you remember what settings you did on FUJI when you set it up to pull worklist from DCM4CHEE?

I feel once we get the right DCM4CHEE port we should be able to see the worklist on modality.

ramashish · September 26, 2019, 6:00pm

I found this video which uses DVTK Modality Emulator connected to Bahmni DCM4CHEE. Order is getting placed from Bahmni synced with DCM4CHEE then a request to get worklist is placed from this modality emulator and it fetches the worklist.

What’s missing is the settings done for the Remote System in Modality Emulator.

Has any one used this emulator?

ramashish · September 26, 2019, 9:24pm

Found out that the modality emulator used here is DVTK But when tried on our system the DICOM Echo is successful but the Request Worklist item fails Configure Remote System as IP - DCM4CHEE IP, Port - 11112 and AE Title - DCM4CHEE

Configure Emulator - System Name - Modality, AE Title - Modality rest is all default.

ramashish · September 26, 2019, 10:51pm

Changed Configure Emulator - System Name - DCM4CHEE, AE Title - DCM4CHEE rest is all default. The images could be sent from Modality Emulator to DCM4CHEE but the DCM4CHEE worklist could not be pulled from modality emulator.

/var/lib/bahmni/dcm4chee-2.18.1-psql/server/default/log/server.log is clearly showing that the Request Worklist (C_FIND_RQ with Dataset, C_FIND_RSP) has reached DCM4CHEE and it has processed with the status: 0 (which means success) but the emulator does not get the worklist.

2019-09-27 04:14:55,980 INFO  -> (TCPServer-1) [org.dcm4cheri.server.ServerImpl] handle - Socket[addr=/68.6.82.157,port=44185,localport=11112]
2019-09-27 04:14:55,980 INFO  -> (TCPServer-1) [org.dcm4cheri.net.FsmImpl] Socket[addr=/68.6.82.157,port=44185,localport=11112]
2019-09-27 04:14:55,985 INFO  DCM4CHEE->DCM4CHEE (TCPServer-1) [org.dcm4cheri.net.FsmImpl] received AAssociateRQ
	appCtxName:	1.2.840.10008.3.1.1.1/DICOM Application Context Name
	implClass:	1.2.826.0.1.3680043.2.1545.1
	implVersion:	dvt2.4.0
	calledAET:	DCM4CHEE
	callingAET:	DCM4CHEE
	maxPDULen:	16384
	asyncOpsWindow:	
	pc-1:	as=1.2.840.10008.5.1.4.31/Modality Worklist Information Model - FIND
		ts=1.2.840.10008.1.2/Implicit VR Little Endian
		ts=1.2.840.10008.1.2.1/Explicit VR Little Endian
		ts=1.2.840.10008.1.2.2/Explicit VR Big Endian
2019-09-27 04:14:55,985 INFO  DCM4CHEE->DCM4CHEE (TCPServer-1) [org.dcm4cheri.net.FsmImpl] sending AAssociateAC
	appCtxName:	1.2.840.10008.3.1.1.1/DICOM Application Context Name
	implClass:	1.2.40.0.13.1.1.1
	implVersion:	dcm4che-1.4.34
	calledAET:	DCM4CHEE
	callingAET:	DCM4CHEE
	maxPDULen:	16352
	asyncOpsWindow:	
	pc-1:	0 - acceptance
		ts=1.2.840.10008.1.2.1/Explicit VR Little Endian
2019-09-27 04:14:56,631 INFO  DCM4CHEE->DCM4CHEE (TCPServer-1) [org.dcm4cheri.net.FsmImpl] received [pc-1] 2:C_FIND_RQ with Dataset
	class:	1.2.840.10008.5.1.4.31/Modality Worklist Information Model - FIND
2019-09-27 04:14:56,633 INFO  DCM4CHEE->DCM4CHEE (TCPServer-1) [org.dcm4cheri.net.FsmImpl] sending [pc-1] 2:C_FIND_RSP
	class:	1.2.840.10008.5.1.4.31/Modality Worklist Information Model - FIND
	status:	0
2019-09-27 04:14:56,936 INFO  DCM4CHEE->DCM4CHEE (ActiveAssoc-116-1) [org.dcm4cheri.net.FsmImpl] received A-RELEASE-RQ
2019-09-27 04:14:56,936 INFO  DCM4CHEE->DCM4CHEE (ActiveAssoc-116-1) [org.dcm4cheri.net.FsmImpl] sending A-RELEASE-RP
2019-09-27 04:14:56,936 INFO  -> (TCPServer-1) [org.dcm4cheri.server.ServerImpl] finished - Socket[addr=/68.6.82.157,port=44185,localport=11112]
2019-09-27 04:14:56,987 INFO  DCM4CHEE->DCM4CHEE (ActiveAssoc-116-1) [org.dcm4cheri.net.FsmImpl] closing connection - Socket[addr=/68.6.82.157,port=44185,localport=11112]

arjun · September 27, 2019, 1:11pm

@ramashish

Few pointers

The port number 2575 is for HL7 server. Try putting port number 11112 in the modality.

In the dvtk log, you are not getting a matching C_FIND_RSP with Dataset (status ff00), instead you are getting just C_FIND_RSP (status : 0). When the dataset is found i think the logs would look like below

  019-09-27 11:42:11,480 INFO  CL-SCU->DCM4CHEE (TCPServer-1-3) [org.dcm4cheri.net.FsmImpl] sending [pc-41] 43:C_FIND_RSP with Dataset
          class:  1.2.840.10008.5.1.4.31/Modality Worklist Information Model - FIND
          status: ff00

And when the request is successful and no data is found the logs would look like

2019-09-27 11:42:11,480 INFO  CL-SCU->DCM4CHEE (TCPServer-1-3) [org.dcm4cheri.net.FsmImpl] sending [pc-41] 43:C_FIND_RSP
        class:  1.2.840.10008.5.1.4.31/Modality Worklist Information Model - FIND
        status: 0

My best guess in this is that none of the dataset is matching the query params being passed. Not sure how to print that in the logs. Don’t have a system to play around with, but there must be some setting in jmx-console.

Also i noticed an entry done in Application Entities for the modality like below (CL-SCU entry)
Screenshot%20from%202019-09-27%2017-37-581291×364 37.3 KB
Not sure why was that required, but try putting it. Correct AE Title, IP Address and port number is to be put based on values from your CT modality.
With respect to modality, dcm4chee communication, if you are not getting request in dcm4chee server, it could be an issue with your firewall settings. By default Bahmni server restricts unknown ports. So you first try by stopping the firewall service and then later on if this helps, put a specific firewall rule to allow connections from this port.

Hope this helps.

ramashish · September 27, 2019, 6:54pm

Though the image was not reflecting it we had already done that as mentioned in

As we did not have a firewall and Modality emulator was able to successfully get DICOM Echo from DCM4CHEE we were not looking into it but your suggestion of firewall forced us to look into networking of DCM4CHEE and Modality emulator. So we brought these 2 on the same network but it still no luck.

Then we started looking into this. On DVTK modality emulator, we noticed that the very first CR_modality_.dcm gets selected by default and has specific patient name. So we used worklistquery1.dcm and modified it to make all query parameters blank and

Jay Ho! (BINGO!)

We got the worklist on modality emulator.

Some of our learning

Bahmni, DCM4CHEE and modality should be on the same network / visible to each other.
Create PACS Procedure Code mappings
As mentioned in this wiki set

Stylesheet = orm2dcm_bahmni.xsl

The default bahmni installation should then automatically sync the Bahmni order with DCM4CHEE. Please note that there is no need to modify anything in modality table of bahmni_pacs database (and of course wiki does not ask to modify but when modality sync failed we started looking “deeper” and first thing we (unnecessarily) tried was this modality table. Should have believed our wiki!). The name modality for this table is little misleading as it actually refers to Modality Worklist Server ie DCM4CHEE in Bahmni’s case.
Once Bahmni Order is synced with DCM4CHEE focus on modality side as DCM4CHEE does NOT push the list to modality but modality polls / sends request to DCM4CHEE to get the worklist on it’s console.
When modality sends request to DCM4CHEE it sends it with a query template (.dcm file) which can have multiple HL7 based parameters/attributes (?) based on which the fetched worklist gets filtered. So locate the .dcm file on modality which is being used while making the “Request Worklist” (Every modality may have a different nomenclature and settings to send this request manually or at specific time interval for auto refresh of it’s own worklist) and edit to keep all these query parameters/attributes blank.

Though today we used DVTK modality emulator (also noted that OpenMRS mentions this emulator) but with all the that we received here (@arjun, thank you!) and with our success on modality emulator we are confident about tomorrow’s real test on modality.

ramashish · September 29, 2019, 7:54pm

It worked absolutely fine and we could sync worklist with modality - GE Logiq P5 Ultrasound (US).

Please note that the image shown is not using any search query parameters so showing all the worklist items even if few are meant for other modalities.

From Services tab we added DICOM QueryRetrieve service with DCM4CHEE settings. Like DVTK Modality emulator on this US console we could not get access to .dcm files to set search parameters. So search parameters like modality = US was set in Seach Criteria as shown in the image.

As we have multiple facilities and every facility has multiple modalities and since neither Bahmni nor pacs-integration service sets the receiving location or modality information while syncing HL7 message with DCM4CHEE, we will look in to this either through the code or through

Will keep posted.

ramashish · October 3, 2019, 6:15am

Problem Statement - Bahmni should does not set location, modality type while syncing HL7 message with DCM4CHEE which creates problem in fetching location and modality specific worklist item from modality.

Solution - Though setting modality based on the order type is the best solution but in our case the end user wants to see X-Ray, CT, US etc under the same order type “Radiology Order”. This is achieved in the following manner

Step 1 - OpenMRS Concept Mapping In addition to PACS Procedure Code (which is Same As relation), one more mapping with “Associated With” relation is used to set the modality type for the required concepts as as shown in the image.

Step 2 - Bahmni Order is placed for those concepts where this mapping is done.

Step 3 - To sync the location and modality information in modality element - OBR-24 of HL7 message while syncing with DCM4CHEE, addOBRComponent function of HL7Service.java in pacs-integration code is modifiied.

    OpenMRSConceptMapping modalityConceptSource = order.getModalityConceptSource();
    if(modalityConceptSource == null) {
        throw new HL7MessageException("Unable to create HL7 message. Missing modality concept mapping for order " + order.getOrderNumber());
    }
    String modality = locationName + " - " + modalityConceptSource.getName();
    obr.getDiagnosticServSectID().setValue(modality);

Also the necessary modifications to get location are done in OpenMRSEncounter.java

Now on modality, query parameter “modality” is set to location-modality type to fetch only the matching worklist items.

This helps to address multiple locations with multiple modalities.

Soon the modified code will be uploaded on github, if any takers. @arjun @angshuonline

angshuonline · December 26, 2019, 8:56am

@ramashish have you raised a PR for this?

ramashish · December 26, 2019, 10:21pm

No I have not raised PR as I was waiting for comments.

angshuonline · December 27, 2019, 6:12pm

Please do. Please create a card in JIRA first. @arjun any other comments?

shelly · April 15, 2021, 9:03am

Hi! I’m implementing a test setup of Bahmni with a Modality Emulator called CONAXX. The problem is, that CONAXX cannot import the Modality worklist from the PACS (DCM4CHEE) because of the generated Study Instance UID which isn’t conform to the DICOM standards as it contains characters (see below).

Does anyone know, how the Study Instance UID is generated and how it can be changed? Thank you!

ramashish · May 2, 2021, 11:48pm

If you are using orm2dcm_bahmni.xsl as mentioned in the wiki then that stylesheet should have the specific address of HL7 message to which refers to Study Instance UID. This file should be in /opt/dcm4chee/etc/