Is URL link from ext system to PacsOne still an option?

cwhamilton · Post by **cwhamilton** » Tue Oct 07, 2014 1:54 pm

Yesterday I found this posting in the forums:

http://www.pacsone.net/forum/viewtopic. ... b456ed2ae9

I have been asked to find out if we can embed a link directly into PacsOne into our RIS. I tried creating the risAccess.php mentioned in the post above, but when I try to test it, all I get is "Error querying PacsOne Server database!"

This is code I am running to generate the link (username/password/server changed for security)

Code: Select all

<html>

<head>
<title>PACs URL Test</title>
</head>

<body>
<form method="POST" action="http://imagearchive.server.org/pacsone/risAccess.php">
<input type="hidden" name="database" value="CIA">
<input type="hidden" name="username" value="dbuser">
<input type="hidden" name="password" value="dbpassw">
<input type="hidden" name="key" value="accessionnum">
<input type="hidden" name="value" value="E233553720140524">
<input type="submit" value="View Study">
</body>

</html>

Is there anything else I am missing or any better method for me to troubleshoot?

Post by **pacsone** » Tue Oct 07, 2014 6:04 pm

Did you verify if the specified MySQL username/password from your HTML POST form is valid? e.g., you can try logging into the same database using the same MySQL username/password from a local command shell:

Code: Select all

C:\mysql\bin>mysql -u dbuser -p CIA

and check if you can login to the specified "CIA" database using that MySQL username/password.

cwhamilton · Post by **cwhamilton** » Tue Oct 07, 2014 6:43 pm

Thank you for your reply. I just tried the command you mentioned above and it seemed like it worked from the command line on the server. This is what was returned:

Code: Select all

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1908
Server version: 5.6.15-log MySQL Community Server (GPL)

Can you think of anything else I can try?

Post by **pacsone** » Wed Oct 08, 2014 3:09 pm

The next step is to run the same SQL query from the MySQL shell prompt after logging to the "CIA" database above:

Code: Select all

mysql>select uuid from study where accessionnum like 'E233553720140524%';

and see if you get any error.

cwhamilton · Post by **cwhamilton** » Wed Oct 08, 2014 3:44 pm

Again, thank you for your help. I ran the command as specified and it also looks like it completed successfully.

Code: Select all

mysql> select uuid from study where accessionnum like 'E233553720140524%';
+-----------------------------------------+
| uuid                                    |
+-----------------------------------------+
| 1.2.840.113704.1.111.11296.1400967874.1 |
+-----------------------------------------+
1 row in set (0.00 sec)

I am sorry I cannot troubleshoot this better myself. In the past I have worked with MS SQL, ASP, and IIS, but I am trying to get acquainted with these open-source alternatives. I really appreciate your assistance. Please let me know what our next steps might be - thank you.

cwhamilton · Post by **cwhamilton** » Wed Oct 08, 2014 7:00 pm

OK, I have been looking through the code and noticed that there was an extra "u" missing from the following line in the risAccess.php code listed on the referenced page in the original post.

The original script read:
$query = "select uid from study where $key LIKE '$value%';";

But according to your command like example it should be "select uuid"... I made the change to the risAccess.php page and it made it a little farther.

I still haven't got the image yet, now I'm getting an "#0 MyDatabse->fetch_array() called at [Program Files (x86)\PacsOne\php\risAccess.php:62] - No image to display." message. I'm still working on it, but if you have any other suggestions I would love to hear them.

cwhamilton · Post by **cwhamilton** » Thu Oct 09, 2014 3:02 pm

OK, I have really been pouring through the code and I found a few more problems with the original code, mostly column names that may have changed through some revisions. I finally got the code to open the PacsOne screen with the standard (Nagoya) viewer. But the images never load, I just get a status message saying "Now Loading Dicom file (1)...." (see screenshot below). I don't get any DICOM tag info either

Right now I have a few extra lines in the code to give me the UID and the Series UID for troubleshooting purposes, so disregard those. Any ideas on why the images never load? I know we are very very close to making this work. Again, thank you for your assistance.

Post by **pacsone** » Thu Oct 09, 2014 3:11 pm

Yes, the database schema has changed since the sample script was posted, i.e., the uid column names have all been changed to uuid instead. We have updated the original post accordingly with the new column names to avoid similar confusions.

The new error you got seems to suggest there is no image contained within this study with UID "1.2.840.113704.1.111.11296.1400967874.1". So can you search for this study by its UID from the Search->Search By Study menu and search for 1.2.840.113704.1.111.11296.1400967874.1 in the Study Instance UID field, and see how many images are contained within that study?

Post by **pacsone** » Thu Oct 09, 2014 3:15 pm

The free/open-source viewer (Nagoya) only supports the Dicom default Little-Endian Implicit VR transfer syntax. So if this study is encoded in some other transfer syntax, it probably won't load properly in the Nagoya viewer. If this is the case, you should try one of the commercial web-based Dicom image viewers (http://www.pacsone.net/download.htm), as all of them support most commonly-used Dicom transfer syntaxes and will be able to load/display the Dicom studies without any trouble.

cwhamilton · Post by **cwhamilton** » Thu Oct 09, 2014 7:04 pm

I had to make one other change to that original code also. This line

Code: Select all

$resultSeries = $dbcon->query("SELECT uuid FROM series where studyuid='$uid' ORDER BY number ASC;");

I had to change to:

Code: Select all

$resultSeries = $dbcon->query("SELECT uuid FROM series where studyuid='$uid' ORDER BY seriesnumber ASC;");

i confess that all these numbers may have me confused. But I did find a study ID in my PacsOne database (1.2.840.113704.1.111.6488.1398651474.1) and when I do a study search it returns 1 matching study with 401 instances. When I check the study and click 'Show' the Nagoya viewer opens and I can see all of the images in the study.

When I try that same study ID to link to the risAccess.php page, the viewer loads, but no image. I think it's important to note that when I slide the ImageNo slider all the way to the right it stops at 401, so it knows how many images are in the study.

I may try to download the Radscaper demo to see if it works any better, but if the Nagoya viewer can view that study's images while logged in normally, shouldn't it also display the images from the external link?

Thanks again for your patience and persistence.

Post by **pacsone** » Fri Oct 10, 2014 3:45 pm

That's a great catch and we'll update the original post accordingly with the new column names.

It seems like a bug where the Nagoya applet viewer would function differently given that it's invoked with the same way, i.e., same list of instance uids passed to the same applet viewer function. Feel free to checkout one of our supported commercial Dicom image viewers instead, since the Nagoya viewer does not appear to be maintained any more.

cwhamilton · Post by **cwhamilton** » Tue Oct 21, 2014 6:53 pm

I seriously didn't want to have to come back again looking for answers, but I am at a complete loss.

We finally received our license file, so I downloaded Radscaper demo version and got it loaded on the server and working well on the PacsOne server. I am able to view any study within their 4 image demo constraint.

When I then run the risAccess.php pointed to a particular study that I was able to pull within PacsOne, I get an error message:

"No images provided to display. Open Java Console for more details"

When I look at the Java Console there isn't much to go on, but this is very similar to the results I was seeing with the Nagoya viewer.

Code: Select all

Java Plug-in 10.67.2.01
Using JRE version 1.7.0_67-b01 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\cwhite
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
0
********************************************************************
Copyright ©2013. Divinev. All Rights Reserved.
WARNING: This program and source code is protected
by copyright law and international treaties. You shall not
modify, alter, adapt, merge, decompile, disassemble or
reverse engineer the program. Unauthorized reproduction
of this program, or any portion of it, may result in severe
civil and criminal penalties, and will be prosecuted to
the maximum extent possible under law.
********************************************************************

Radscaper 13.0 released on 05/10/12
java.version=1.7.0_67
os.name=Windows XP
memory.max=742MB
AppletHelper 9.0

==== Limited license with certain restriction ====

Error: No images provided to display.

And it appears as though Radscaper no longer has a user forum or discussion board, so my support options though them seem quite limited.

Would you be willing to try the risAccess.php code on your system and confirm that the code (as posted in the link in the original post) still actually works? I know we made a few corrections, I just wonder if there could be something else keeping this from working properly.

Thank you!

Post by **pacsone** » Wed Oct 22, 2014 5:32 pm

This should be fairly easy to trouble-shoot, as you can check the implementation of the appletViewer($uids) function in the php/applet.php script provided by the Radscaper applet, and see exactly what that error means.

The appletViewer($uids) function is supposed to take a list of Dicom image UIDs as input argument, and present that list of images for display in the applet viewer. The error you got from the viewer most likely means it has trouble locating the corresponding Dicom image files from the list of UIDs passed to it.

cwhamilton · Post by **cwhamilton** » Wed Nov 05, 2014 4:18 pm

OK, so I am finally getting more time to devote back to these links. I think the ease of the troubleshooting comes with the experience of the troubleshooter though.

I changed the applet tags on the applet.php so that so javascript would not run and I added some code to spit out the variables used in the applet.php When I run the link through the risAccess.php page, something is happening at the fetch_row portion of applet.php, and I cannot figure out why it works through the regular system but fails through the risAccess page.

When I view the image from PacsOne, this is the data I get back:

Code: Select all

uids array = Array ( [0] => 1.2.392.200036.9125.4.0.319806482.2051802472.399170569 ) 
uid = 1.2.392.200036.9125.4.0.319806482.2051802472.399170569
result = mysqli_result Object ( [current_field] => 0 [field_count] => 1 [lengths] => Array ( [0] => 107 ) [num_rows] => 1 [type] => 0 ) 
row array = Array ( [0] => //10.60.9.250/cia/CIA/PACSOne/Archive/MMC/2014/05/26/1.2.392.200036.9125.4.0.319806482.2051802472.399170569 )

When I use the risAccess link to try to view the same image, this is what I get back:

Code: Select all

#0 MyDatabase->fetch_row() called at [C:\Program Files (x86)\PacsOne\php\applet.php:29] #1 appletViewer(Array ([0] => 1.2.392.200036.9125.4.0.319806482.2051802472.399170569)) called at [C:\Program Files (x86)\PacsOne\php\risAccess2.php:73] 
uids array = Array ( [0] => 1.2.392.200036.9125.4.0.319806482.2051802472.399170569 ) 
uid = 1.2.392.200036.9125.4.0.319806482.2051802472.399170569
result = 
row array =

The UIDs are exactly the same, so I'm not dealing with different images, it seems there's something failing in that fetch_row() call and I don't know enough about what it is doing or how it works to troubleshoot it further. When it fails it does not pass the UNC path to the applet parameter and that's why I keep getting the "no image" error.

Do you have any other suggestions as to what I can do to get this working, or least how to better troubleshoot the fetch_row error?

Post by **pacsone** » Thu Nov 06, 2014 3:44 pm

The appletViewer() function in the "php/applet.php" script does take a list of Dicom image UIDs, so it seems what got passed to that function is fine for both cases.

But the question is where did you print the MySQL Result object? the appletViewer() function in the default "php/applet.php" script has no reference to such object at all.