We were not using AD integration or SSO prior to moving to 7602 (from 7.5.x).

Initially, in the Domain Scan and Active Directory settings, I had entered our domain in the post 2000 format… ie domain.com. Turns out that doesn’t work. I had to switch back to our pre 2000 domain name.

I made the mistake the first time of filling the Computer Account with the name of the computer ServiceDesk was installed on. This replaced the actual computer account for that computer, causing issues. Use a new name that will never be used by any existing or new computer account.

When entering info into the Pass Through Authentication section, it would give warning/link messages, the first about computer account not being made, the second about setting the password. I checked and the computer account was made, so i ignored the errors. I shouldn’t have. I had to use the second link to set the password to match what I entered on the Pass Through Authentication page. Run this on the domain controller.

Restart the servicedesk service.

Ensure IE has the web address of your servicedesk server entered in as a site in the Local Intranet under Security.

If using firefox, type about:config in the URL box. Then search for:
network.automatic-ntlm-auth.trusted-uris
Double click and enter the web address(es) prefixed by http(s)://. If you have multiple URLs, separate them with a comma (,).

Completely exit/restart the web browser.

In our experience (and I did do reinstalls/tests several times), following the above steps worked reliably. Hope this helps.

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:
         

As we all get more and more busy, it is all too easy to forget about pending domain renewals. In many instances, the domain registrar for your domain will kindly email you a reminder to renew. However, what if the email address that the registrar has is out of date? Perhaps the original contact is no longer with your company, or, simply that the email address has changed. I find it essential to put domain expiry dates in my calendar, and to ensure a few other individuals at my company do the same.

How can you easily find out when your domain will expire? Try:
http://www.dnsstuff.com/tools/whois.ch?ip=google.com
Where you change google.com to your address.
This WHOIS search will show you what company you registered with, when your domain is up for renewal, as well as the contact information on file. Try to avoid having one person being the Admin and Tech contacts. Separating these to different staff helps guard against that one individual leaving and leaving your company without a contact.

Given the relatively small cost for domain renewals, especially compared to the impact of the domain going offline, it is recommended to renew the domain for the longest time period possible (currently 10 years). Furthermore, at the end of each year, try to remember to renew it yet again so that it remains valid for 10 years.

If you are unfortunate enough to have let the domain expire, what can you do? ICANN, the governing body of domains, has recommended a 30 day grace period, whereby participating registrars will allow you to easily renew your domain within the month it expires.
http://www.icann.org/bucharest/redemption-topic.htm
After this 30 day window (or right after expiry if your registrar is so inclined), the domain can be grabbed by anyone. You may be lucky enough to find it available, however, the trend these days if for someone to grab recently expired domains in the hope of making money. This can include hosting ads at your (former) website, as well as charging a fee to give the domain back to you.

Given the importance of keeping your domain properly renewed, it should be handled as any other business critical element. Multiple people should be made aware of the issue. The needed login and contact information for your registrar should be documented in a safe place. Periodic WHOIS checks of your domain are a wise idea, to ensure all information is correct and up to date. It only takes a few moments of your time to ensure you and your company have a trouble free domain experience.

Bookmark to:
         

Purchase an extra scanner interface card (Sealevel). This allowed us to leave the old PC as is, in case we needed to swap back to it for any reason. The card is fairly inexpensive ($200CDN), and this leaves us with a spare to use for the next upgrade, or in case a replacement is ever needed.

On the new PC, it is neccesary to use the same Calibration file as the old system. This file can be found in the Lunar Config directory, and has a .CAL extension. Simply copy the most recent .CAL file to the Config folder of the new Prodigy PC. Then you must enter SERVICE MODE to point Prodigy to this file. This can be found under User Options, in the Systems tab. Click on SERVICE, and then enter the password. For us it happened to be MADISON, though I am unsure if our reseller sets this, or GE. From this menu, you can also run a test to ensure everything is communicating properly.

TIP: Be sure to plug the table into the proper port on the PC. This sounds obvious, but one day I accidentally plugged it into the regular serial port, and it took me an hour of fiddling to realize my simple mistake.

I find it wise at this point to do a QA test with Prodigy, to confirm that all is functioning properly.

Our previous Prodigy configuration was set to Archive data to another HD in the PC. I think this was done when the main HD got full, and the solution was deemed to simply add in a second HD and archive to it. The issue I have found is I am unable to move the database file to the new machine (lunar.mdb), and have it work properly with those archived studies. My course of action was to consolidate all the data from the DATA and ARCHIVE directories into one directory on the new PC, and rebuild a new database from scratch. This works fine, except now I lose any manually imported data (of which there is thankfully little). Luckily, since we have paper records of it, it can always be entered again if needed.

Now that the new PC is on the network, I set it to back up the Prodigy data directory (and any other needed directory) to a server automatically each night.

All that is left is ensuring all the user options are set the same. I use a program called SnagIt to allow me to rapidly do screen captures of the various preference screens. That way I have a permanent and easy to understand record of these settings.

Hope this helps even just one person out there. I came into my first migration with no knowledge of Prodigy software. While these steps above may sound simple if you are familiar with Prodigy, they took some time to figure out the first time. Please leave any comments or suggestions.

Bookmark to: