These are selected entries I have copied over from my old PACSMATT blog:


Happy International PACS Administrator Appreciation Day!  Let me take this opportunity to wish my fellow PACS administrators everywhere a hearty congratulations on this newly founded day of appreciation.  As a reminder of all you do, I'd like to take this opportunity to reprint Aunt Minnie's definition of a PACS Administrator:

PACS System Administrator:

noun, Part magician, part juggler, part technical support analyst, and part bartender/psychoanalyst, the PACS Administrator performs the impossible job of keeping all members of his or her company satisfied by making sure that everything works. This usually includes things that are completely outside the PACS Administrator's control like facility PCs, telephones, photocopiers, fax machines, heating, air conditioning, and even paper shortages in the supply cabinet. If the PACS touches it or if a PACS component even sits near an unrelated device, it is the PACS Administrator’s responsibility.

     Here's a neat trick I found for deleting images in Emageon PACS.  We all face the problem of fixing exams in PACS and with the new QC tools Emageon has introduced in 5.30+, the process has become amazingly easy to split series, move images between exams, rename descriptions, etc.  It's especially convenient because these exam modifications flow to the other storage locations in your PACS (AV, FIC, LTA).   However, deleting images has continued to be troublesome because you have to delete the image from the viewer (Advanced Visualization, aka, AV), local storage (FIC) and any long term archives (LTA's) your site uses.  Multiple methods must be used to access each of these repositories to delete one exam's images.  I can understand the reasoning for this - it would be very dangerous if someone could delete an exam or patient in AV and have that action repeated on all other storage locations, but what a pain it is, right!  There must be a better - ah, but there is!  Use a recycle bin.  I hear you, "But Emageon hasn't given us that feature in AV yet".   They don't have to - it's actually already there.  You just have to make one yourself.  Here is how:

  1. Create a dummy exam on your CR/DR (or whatever modality is convenient).   Name the user "Recycle, Bin", give it a dummy patient ID & accession number, and send it to PACS.
  2. Once it is in AV, QC edit the exam and change the description to something like "Deleted Images".
  3. Create a new Public exam list that will hold exams that need to be repaired.  I named mine "Fix".
  4. Drag your "Recycle, Bin" patient into your Fix folder and leave it there.
  5. When you need to delete an image in a study, drag that exam into the Fix folder.  (Note: Teach your staff to drag studies that need to be repaired into this common fix folder so that you can find them easier.)
  6. Go to the Fix folder and you should see your Recycle, Bin exam and the exam you need to delete an image out of.
  7. Click the plus sign next to the exam you need to remove an image from so that you can see all the images inside the exam.  (Note: if you need to remove one or more images from a series, use the QC split series function to split the image(s) you want to remove out of the ones you want to keep and then give the images to remove a unique series number so it's easy to identify from the ones you're keeping.)
  8. Click on the image(s) you want to remove so they are highlighted in the worklist, then press the CTRL key and click the Recycle, Bin exam.  You should now have two items selected: the image to be deleted and the Recycle, Bin exam.
  9. Now use the QC Move Series function to move the images you want to delete to the Recycle, Bin exam.
  10. Confirm your selection by clicking OK and you're done!  Emageon's QC function will move the images out of that patient's exam and into the Recycle, Bin exam (and it will move it in all the other locations it exists.

     The best part of this is that you can easily undo what you have deleted and there is an inherent audit trail via the QC Activity Log feature.  Depending on how often you do this, just remember to do a final delete on the images in the Recycle, Bin exam every so often and you'll be in good shape!



     No April Fool's joke from me, just some insightful knowledge from Emageon's own John Hyatt.  John recently helped our site tweak our Prefetch rules and he sent me an excellent description of how prefetching works in Emageon PACS.  With his permission, I thought I would share it with you:

     The bodypart rule will compare the requested procedure description in the HL7 order with the various synonym lists, find a matching synonym group, and then query the proxy (configurable, proxy is the default) for any stored study having a study description that matches the search terms, “arm” for the “extremity, upper” synonym for example. The date ranges a prior remains viable and the maximum number of priors to pull are all configurable as are the prefetch destinations.

The modality rule will query the proxy for priors matching certain date criteria and having a modality code stored in the DB that matches the modality code sent in the order. For example, an order containing the modality code DX will prefetch xrays with a stored modality code of DX. It will not retrieve any xrays that have a different modality type (CR for example).

The default number of priors to retrieve for any rule is 3. That can be modified, but I would not suggest more than about 5 or 6 at most. Also, in the event that you have multiple rules active, say one rule that pulls 3 by bodypart and one that pulls 3 by modality, there’s no guarantee that you will prefetch 6 priors. The reason for that is that some priors might be relevant to both rules. If they are, the prefetch work for the two gets consolidated so that we don’t prefetch the same prior twice. So if you’re doing 3 bodypart and 3 modality, a patient has 10 priors, 3 match one rule, 3 match the other rule and one of those 3 each found matches both rules, you prefetch 5 priors; the one they had in common is only pulled once.

The default rules created during install are, as far as I know, 3 by bodypart (with default synonym list), 3 by modality, and 3 unconstrained (first 3 priors found regardless of modality or bodypart)… The decision on the number of priors each pulls is really up to you but again, I’d say no more than about 9 total regardless of which rules you use; the more you try to make it do the more the prefetcher will slow down.


 I uploaded DicomSend, a utility for sending DICOM image files to PACS (or any DICOM send destination).  It's really just a GUI front end for STORESCU.EXE from the OFFIS DCM Toolkit (  DicomSend recursively searches a folder of your choice and tries to send anything it finds.  Non-DICOM files will fail of course, so only point it to folders full of appropriate images.  A log file records all the information about the attempted send.  Try it out and let me know if you have any suggestions.  You could use this to push CDs into PACS as well.  I plan to add features to it so you can modify the exam demographics before you send the study, but that's not in there yet.

    Wow!  Wow, wow, wow!!!  I can't believe what I just stumbled upon thanks to something Brandon Smith from Foundation Radiology Group sent me.  Brandon used the Emageon macros to write an integration for TeraRecon AquariusNET Server.  He told me it would be fine to share it, so here you go.  Thanks Brandon!
     We happen to use Vitrea at our facility, not TeraRecon, but the coolest thing I discovered is in step #5 of Brandon's instructions.  Brandon's command line arguments in his macro simply had the text StudyInstanceUID & SeriesInstanceUID listed.  Bonk!  No way!  No way!  It can't be that simple.  Emageon couldn't have thought to write in support to insert known DICOM tags in the command line by simply referencing the same descriptors used in the labels!  No way!  So, I wrote up a simple script to echo back whatever command line arguments were specified and added a macro for it.  I specified SeriesDescription for my first test, opened a viewport and ran the macro.  Guess what?  It echoed back the text "SeriesDescription".  My heart sank.  I knew it couldn't be that simple.  What was I thinking?  But wait, labels put "{ }" around the descriptor.  So, I edited the macro to use {SeriesDescription} as the command line argument, ran the macro and.... nothing.  Man, that stinks.  Wait, I had opened a lame CR study that didn't have series descriptions, what was I thinking?  Different study, different series (with description), ran the macro and (insert halleluiah chorus) it echoed back the series description name!  Holy DICOM tags batman!  I switched it to SeriesInstanceUID and tried it again and it echoed back the lengthy SIUID!  How sweet is that!  Brandon used this info to launch TeraRecon focused on a the study that was open in PACS.  I can't wait to start using this!  Brandon,  you rock!  Thanks for the info and the instructions for the TeraRecon integration!

Happy Birthday Emily!   On this special occasion I am releasing a cool little tool I wrote yesterday called ScreenRead.  ScreenRead lets you mark a portion of the screen that you want to steal the text from.  It then does OCR on that area and copies the text to the clipboard.  I use this in AV to grab accession numbers and Patient ID numbers that I would normally have to memorize and manually type in somewhere else.  It's also useful for grabbing error messages.  Try it out!

I found this interesting.  Ever wonder where the terms big-endian and little-endian came from?  As described here by Diethard Ohrt:  
"Big-endian and little-endian derive from Jonathan Swift's Gulliver's Travels in which the Big Endians were a political faction that broke their eggs at the large end ("the primitive way") and rebelled against the Lilliputian King who required his subjects (the Little Endians) to break their eggs at the small end."

I'm back in Birmingham for the 2007 Emageon User Group meeting.  I'm typing this out on a new rubber folding keyboard hooked up to my Sony UX180 microPC.  It works pretty good, but forgive any typos I'm still getting used to it.  I'm almost done with the new PACSMatt forum. It will be a good sounding board for anyone to offer suggestions, bug alerts,  troubleshooting, etc.  I will be speaking on Tuesday about PRDR, the DICOM Dump Comparison Tool, how to make & integrate macros, what is coming up in the future of PACSMatt and other stuff only interesting to PACS Administrators.  I will start publishing the new stuff I'll be talking about tonight.  So, first up, the DICOM Dump Comparison Tool.  Use it to compare the dumps of two separate series to help build rules, hanging protocols, compare CR to DR modalities, etc.  It's pretty self explanatory, download it, unzip it, run it and it will give you instructions.  Look for the icon for it in the system tray.  The three buttons in the corner of the results window don't work yet (they were for saving dump info and settings exclusions).

Hi again - Want to export a list of your Emageon users to a tab delimited format ready for importing into Excel?  Try the EmageonUserList.  Download it and save it somewhere (like your desktop).  Make sure you have your Emageon Worklist window open (you can minimize it), but no open exams.  Then run EmageonUserList and it will grab your user list and reformat it into a tab delimited file saved to the same location as the EmageonUserList program.