Ok so its been some time since I first posted about the web viewing system that I am making. Since then there where a lot of project under way and it sort of got filled under the pile for a while.

I have recently had some time to re-visit the web viewer and I am making some progress and I hope to have something available on Sourceforge in the next few weeks.

I have also been busy adding some more features to the system.
This is what I am working on at the moment:

* Migrated system from IIS to Apache (WAMP)
* Active directory authentication
* Zip file download of series dicom data for local viewing
* Better user management
* System documentation
* Updated user interface slightly

Please see my sourceforge page for screenshots of some of the user interface elements.

Features to date:

* View patient list for the current day.
* Search for patients on various criteria.
* Thumbnail roll-over preview of images.
* Download whole series dicom images in a zip file.
* Allow only certain users to see certain patients based on Dicom tags.
* Converts images to jpg for view in browser.
* Usage statistics
* System log including failed logins, image views, remote ip address, etc.

I am still looking for a decent opensource image viewer that will allow for image manipulation such as image zoom, brightness contrast, etc. To date I have not found one that is compatible with the system I am writing, but I am hopefull that something will be released soon that fits this need.

PACS World.

Bookmark to:
         

I found an interesting quirk of Conquest Dicom server today while doing some house keeping. I deleted some images in the image directory and decided to re-initialise the database. I suddely noticed that Conquest was shuffeling through the recycle bin and pulling out all the images I had just deleted! (See image)

This seems to happen when you have the data directory (MAGDevice0=D:\) of Conquest Dicom Server set as the root of a drive. (In this instance D:\) to rectify the problem I created a new folder called DICOMDATA and pointed conquest to that directory to store its images. (MAGDevice0=D:\DICOMDATA\)

I would reccomend that you do not use the root of a disk as the place to store your Dicom images. Rather create a seperate folder in that directory for image storage. I have not verified that this happens on all operating systems yet, but the system I am testing this on is Windows Vista Business Edition 64bit, with MySQL as a DB Server.

PACS World: Conquest Server Digging in the Bin.

Bookmark to:
         

The issue is that, while 99% of the images in Conquest with eight zeros are garbage and can be quickly removed through maintenance, they periodically end up causing duplicate SOP records, which then causes images to not transfer properly. I do not profess to truly understand how SOP IDs are used, I just know that when duplicates appear, so does trouble. And since this is most often caused by apparently poor programming of the ultrasound modalities, it would sure be nice if GE and Philips saved the PID to the file when the capture button is pressed.

While Conquest has served us very well for what it is, and given how we use and abuse it, I am anxiously looking forward to our IntelePACS solution, with modality worklists and RIS integration. Just including those two elements alone will make a world of difference, IntelePACS, Conquest, or any PACS system. I am sure there will be problems with it, just as there are with Conquest, at least they will be new problems, and we will have better ability to address them.

Bookmark to:
         

Last week I made another discovery, this one I suspect being the culprit. Twice last week I was able to respond to calls about slowdowns immediately, and rather then just restart Conquest to fix the problem, I spent some time looking into it. Auto-forwarding of images over the WAN had been turned off, but since the problem continued, it did not seem to be the cause of the problem. We also auto-forward images from Conquest to several eFilm workstations to expedite review. Upon closer inspection of one of these eFilm PCs, I noticed that its hard drive was full, or at least, it had reached the threshold eFilm has for maximum drive space usage, so eFilm was in the process of deleting images. It would seem that eFilm is not very good at multitasking, as it was severely slowing down the receiving of files for this review station. On the eFilm computer, I killed the DICOM server service, which was behind in receiving images from Conquest. Immediately, Conquest sprang back to its regular pace, and started receiving/sending images in a quick manner.

So now that I have apparently narrowed down the issue to eFilm and disk space, I still need a way to automatically manage it. The eFilm process that manages disk space is called Disk Manager, and its exe is DM.EXE. This file has some command line parameters, but I was unable to get them to do much. I was hoping to run it after hours each evening, so it would have lots of space for the upcoming day, but had no luck.

What I did setup was a process using PSTOOLS, specifically PSEXEC, so that when Hostmonitor (our monitoring tool) detected space issues on a PC, it would run a command freeing up space by deleting the oldest studies from the eFilm workstation’s hard drive. So far this week, this seems to be working, and we have not yet had a slowdown. However, this solution is flawed, as we are not removing the images from the eFilm database, rather just the actual files on the hard drive. There are two consequences to this. Firstly, a user will still see the images listed in eFilm, and will be unable to open them. Secondly, and more important, the eFilm database will keep growing, and it has a fairly small threshold before it develops issues because of being too large.

Today I thought of perhaps a better method of dealing with this issue. Instead of deleting files off the PCs, I am going to add files, or specifically, a single very large file. How will adding files help with disk shortage issues you may ask?

I plan on letting eFilm’s Disk Manager do what it is supposed to do, and delete images. When I copy this large file over (after hours), eFilm will notice that the drive has passed its threshold of max disk usage, and will begin properly purging files until the predefined disk space becomes available. At which point, I will simply have this large file delete itself, and presto, lots of free space for the next business day.

This should be put into action by the weekend, and I will post the results.

Bookmark to:
         

This had started a while back at our busiest clinic. It was infrequent, so I did not look into it further. It then started happening at another clinic. In this second case, the problem seems linked in some way to a GE Voluson ultrasound unit. This GE device will constantly send “empty” requests to Conquest. When the GE united is powered off, these requests stop, and things speed up again. Because of this other aspect, I ruled out that these two problems were related.

Just recently, two other clinics have had the slowdown happen. That began getting me worried, it seemed like we had a growing problem. Worst of all, at the first two clinics, it was occurring much more frequently, going so far as happening each day for a short period.

As luck would have it, I was downloading a large file one afternoon, and noticed that the reply times to one of our clinics got terrible during this download. Sure enough, I got a call from said clinic that images were slow to arrive from the modalities. This at least narrowed down the problem some. It did not seem like a problem on the clinic side, but more to do with the fact that each clinic auto-forwards all images to a backup server at our central site. It would seem that something was happening because of these backup transfers that was causing adverse effects on Conquest.

Then yesterday, I decided to start turning off these auto forwards, to see if the problem goes away as a result. While doing this work, I noticed that our backup server had numerous stuck tasks revolving around data transfers. That gives me more to look into, and if turning off the forwarding fixes the problem, I will try to narrow it down to a performance issue on the backup server. I still wonder about the network causing some issues as well. We use a wireless provider, and it could be that as the day gets busy, traffic gets affected, and perhaps Conquest is not able to handle the delayed or lost packets.

Nothing is fixed yet, but at least I have some information that will let me work on isolating the issue. Nothing worse then people saying “its broken” but having no idea how to fix it!

Bookmark to:
         

After much investigation, we chose to use 5U AIC server chassis as a basis for a Windows based storage system, with the ability to hold 48 hard drives. We looked at NAS units and fibre channel storage systems, but both got prohibitively expensive once we moved beyond the 5TB storage mark. Actually, NAS got expensive as we stored more, fibre channel was just expensive period. The AIC units (we got two, for redundancy) will allow us to add space via inexpensive SATA drives, up to 22.5TB as currently configured with 500GB drives. We do not need that much space quite yet, but when we do, it is available to us. Also, we reasoned that the money we saved going with these units now, compared to a fibre channel solution, could perhaps pay for a fair chunk of a FC solution in a few years if we require the speed and versatility it would provide.

With the hardware in place, I had to devise a way of duplicating the data from each of our 8 clinics onto these storage boxes. If all we were after was a long term backup of the DICOM files themselves, it would have been one thing, but we also wanted to use this backup as a means of consolidating our files, and allowing lookups against them. After all, each local clinic would be purging data, and still wanted quick access to those purged patients.

I looked at Conquest’s data mirroring feature (MIRRORDevices), but it was not really what we were after. It was more of a data redundancy feature, not geared towards long term storage, our local drive system would still be a limiting factor. Conquest also had the NightlyMoveTarget feature, but again, this only partly met our requirements. This would allow us to grow beyond the local storage system limitations, but would still require redundancy, and would not allow the consolidation of online data that we wanted.

It was decided to simply set up a Conquest server on the AIC box, and have each clinic forward images to it. For sake of ease of management, this was altered somewhat, and we ran multiple Conquest server instances, one for each clinic. This way I could keep data separate, which aids in some troubleshooting. Also, it allowed me to compare image counts directly, so if the numbers matched on both the original and backup server, everything was duplicated. Had we gone with a single server, there would be no easy way to do a count and know that ClinicA was fully duplicated on the backup server.

The game plan was that once studies were purged at each clinic, they would be able to click on the backup server in eFilm to request needed studies. But as we had created multiple backup servers, this would be a pain for users. Plus, it would require them to know which clinic a study was performed at. At about this time, a new version of Conquest was released, with the VirtualServerFor feature. With this, we set up one additional server instance on the backup server, which was a virtual server for the other 7 servers. This way, a user only had to select this one server, and they would get all images from any clinic with no time limitation. From a user perspective, this has been a success. They love this ability, even if it is slower then pulling images from the local server (we are still stuck with slow WAN VPN links).

At first, this method seemed fine. However, I found myself spending an increasing amount of time at the end of each month verifying that images from each clinic server were on the corresponding backup Conquest instance. And if they were not, then identifying which were missing and copying them over manually. My process I was following was:
– On each clinic server, and each backup server instance, from the Query / Move tab of Conquest, I would do a IMAGE query level search for the month that was ending (200610* for example). I would then wait for it to do the count.
– When a backup server and clinic server did not match, I would then run the FIND LOCAL MISSING PATIENTS command for the month, from the backup server instance of a clinic, with the DICOM SYSTEM being the appropriate clinic. After some time, this would return a result. Then I would have to tell it to copy those images over, which again took time.
– Repeat!

Considering that I had 7 clinics to worry about, this was just too time intensive. I had to do it on each clinic server (7), then on the main backup server (7 more times), and finally on the backup backup server (yet another 7 times). Repeating the step a minimum of 21 times was just too much. There had to be a better way.

Not being familiar with SQL, I decided now might be the time to dabble in it. After getting up to speed, and with much trial and error, I devised a solution I am quite proud of. What I was after was a quicker way of doing this, one that was as automated as possible. This is what I came up with:

– A batch file process that would, using a SQL script, do an image count for a specified period, and log it to a file.

– A SQL script that would take input from the batch file (server, date range) and run the count, logging to a file.

– A second batch file process that would, using the DGATE.exe -g command line option, grab any missing images automatically.

Once I had the framework in place, I utilized our systems monitoring software, Hostmonitor to run the script to do the image counts. It is also used to compare the resulting log files, and if needed, starts the process to copy missing images over. As an aside, I highly recommend Hostmonitor. It is not the most graphical of tools, but it is extremely flexible and adaptable. The longer I use it, the more I realize I can be done with it. Best of all, it is very affordable. Perhaps I will discuss it more in a future post.

The result should be a nearly hands off solution. I just got done the final tweaking this past weekend, so it is still early, but the first couple of days with it show promise. If there is interest, I can certainly share the batch files, where most of the magic happens. Some of the features of the batch files include:
– Parsing the date into variables.
– Doing math to determine end of month automatically.
– Parsing the SQL output file to strip out excess data and read the numeric result as a variable to be manipulated.

Bookmark to:
         

Steps to take when Conquest logs:

***Error saving to SQL:

 Turn on Debug Log (more information) on the Conquest console.

 Next time the event occurs (within 5 minutes usually) you may get a message similar to:

***Failed SQLExecDirect : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, SamplesPer, PhotoMetri, Rows, Colums, BitsStored,ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES (‘1.2.840.113619.2.116.4835844.1159511528.0.9207.4′, ‘1.2.840.10008.5.1.4.1.1.6.1′, ‘0001′, ‘20060929′, ‘123331′, ‘1′, ‘MONOCHROME2′, ‘480′, ‘640′, ‘8′, ‘ORIGINAL\PRIMARY\GYNECOLOGY\0001\GEMSSINGLEFRAME\GEMSMGCOUNT1′, ‘999999999′, ‘1.2.840.113619.2.116.4835844.1159511528.0.9214′, 1159887872, ‘999999999\1.2.840.113619.2.116.4835844.1159511528.0.9213\1.2.840.113619.2.116.4835844.1159511528.0.9214\1.2.840.113619.2.116.4835844.1159511528.0.9207.4.v2′, ‘MAG0′)

03/10/2006 9:04:48 AM [CDPACSBU1] ***Error: 2627: 23000: [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY constraint

‘PK__DICOMImages__0425A276′. Cannot insert duplicate key in object ‘dbo.DICOMImages’.

03/10/2006 9:04:48 AM [CDPACSBU1] ***Unable to DB.Add()

03/10/2006 9:04:48 AM [CDPACSBU1] ***SQL: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES (‘1.2.840.113619.2.116.4835844.1159511528.0.9207.4′,

‘1.2.840.10008.5.1.4.1.1.6.1′, ‘0001′, ‘20060929′, ‘123331′, ‘1′, ‘MONOCHROME2′, ‘480′, ‘640′, ‘8′, ‘ORIGINAL\PRIMARY\GYNECOLOGY\0001\GEMSSINGLEFRAME\GEMSMGCOUNT1′, ‘999999999′, ‘1.2.840.113619.2.116.4835844.1159511528.0.9214′, 1159887872, ‘999999999\1.2.840.113619.2.116.4835844.1159511528.0.9213\1.2.840.113619.2.116.4835844.1159511528.0.9214\1.2.840.113619.2.116.4835844.1159511528.0.9207.4.v2′, ‘MAG0′)

03/10/2006 9:04:48 AM [CDPACSBU1] ***Error: 2627: 23000: [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY constraint ‘PK__DICOMImages__0425A276′. Cannot insert duplicate key in object ‘dbo.DICOMImages’.

03/10/2006 9:04:48 AM [CDPACSBU1] ***Error saving to SQL: 999999999\1.2.840.113619.2.116.4835844.1159511528.0.9213\1.2.840.113619.2.116.4835844.1159511528.0.9214\1.2.840.113619.2.116.4835844.1159511528.0.9207.4.v2

This means that the receiving Conquest already has an entry for this file in its DATABASE. The important line is: “Cannot insert duplicate key in object

‘dbo.DICOMImages’”. There may other versions of this message, which may be similar or vastly different. The following steps are only to be used as a guide.

To see the files in question, goto the path indicated by “999999999\1.2.840.113619.2.116.4835844.1159511528.0.9213\1.2.840.113619.2.116.4835844.1159511528.0.9214\1.2.840.113619.2.116.4835844.1159511528.0.9207.4.v2″, (without including the file name).

Copy into the clipboard the “SOPInstanc” number, which is identified by the line:

***SQL: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES (‘1.2.840.113619.2.116.4835844.1159511528.0.9207.4′,’1.2.840.10008.5.1.4.1.1.6.1′

This is telling you that SOPInstanc is the first value, SOPClassUI is the second, etc. The values follow next, in our case we want

“1.2.840.113619.2.116.4835844.1159511528.0.9207.4″

On the receiving system (where the error message occured), open Microsoft SQL Server Management Studio Express (or equivelent tool).

Navigate to the DATABASE in question, and the click on New Query.

Type the following, replacing NNN with the SOPINSTANC # that you copied previously.

SELECT     DICOMIMAGES.*

FROM         DICOMIMAGES

WHERE SOPINSTANC = ‘NNN’

Then press EXECUTE

In the results pane, you should get one entry. One of the columns will be OBJECTFILE. This is the file that the receiving Conquest system has that it thinks is identical to the file it is refusing to receive. Right click on it and COPY.

Open the folder containing the file in the previous step (may help to PASTE the path from your previous COPY).

Copy this file into another location where you can work on it without risking any data loss.

If this file is compressed it must be uncompressed.  To uncompress the file with Conquest run the following command from inside the Conquest directory:

dgate -NDC:\location of file\filename.EXT

You can now use a program like DicomWorks to view this file and perhaps the dicom tags of the file.

If the file you are looking at is the same as the file that is being sent to Conquest, you may be able to simply remove the file from the receiving Conquest system, which will allow the new file to be written. 

C:\pacs>dgate –deleteimagefile:c:\pacs\data\not-needed-file.ext

If the file needs to be kept, a new SOPInstanc tag needs to be entered using DicomWorks that is unique and does not already exists on the server. This should be done on all images from the study in question.

Copy all image files from the study into a temporary working folder. Tell Conquest to delete the study.

Dgate –deletestudy:studyuid

To get a unique tag, send a test study from a modality, open it in DicomWorks to get the SOPINSTNC string, record the string, and then delete the test study.  Now enter the SOPINSTNC string into the study in question and drag and drop the files onto Conquest.

Bookmark to:
         

I enabled debug logging in Conquest (a VERY handy troubleshooting feature). However, nothing was showing up when the Philips would try to send the 3D image. Nothing. Which struck me as very odd, usually some sort of message comes up indicating Conquest started communication. That led me nowhere.

Back on the Philips, I started going through configuration screens. Inside the PACS server setup screens, I found some 3D related check boxes, that were not enabled. Enabling these did not fix the problem. I then looked for the DICOM file type/compression settings.

The setting was for RGB, Uncompressed ILE. ILE stands for Implicit Little Endian. I also noticed a blurb saying all 3D are sent as RGB, Uncompressed ELE (Explicit Little Endian).

I got thinking, perhaps Conquest was having issues with ELE. To test, I changed the regular setting to ELE, and took a picture. Sure enough, it just sat in the queue and did not get to Conquest PACS. So now I knew the problem, but how to fix it? A quick search on Google provided no help. Sadly, Conquest help is extremely hard to find online (that is why you are here!).

Next I searched the Conquest documentation. I quickly found that Explicit Little Endian is an option in the DGATESOP.LST file, and it is disabled by default. I opened the file, removed the # prefixing the ELE line, saved, and restarted Conquest. Sure enough, images started arriving. Thus far, there have been no negative consequences from enabling that function.

I am by no means a PACS guru, I know what I know based on what I need to know to do the job. I am sure some of you understand the definitions and differences between ELE and ILE. Feel free to share in the comments! However, like all my posts, I hope this helps one other person in some way.

Bookmark to: