Our architecture is such that each clinic runs its own Conquest server. This server is nothing more then a powerful PC with mirrored 500GB drives. It was determined that it would be more cost effective to use inexpensive servers on site with limited storage, and to invest in large storage systems at our central HQ.

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: