|Using "hot" tools such as DVTK makes you |
look like these Italians using a Ferrari
One of the major challenges as a PACS administrator is the resolution of “finger-pointing” i.e. being able to locate exactly which device or software is “at fault” causing the problem at hand. Let’s look at a typical scenario. You arrive at your hospital in the morning to find the MRI images from the PACS are suddenly being displayed upside down, inverted, backward, missing certain key parameters, or whatever. Upon investigation you find that a remote upgrade of the MRI software was installed overnight, however, the MRI service engineer swears that the upgrade should not have any impact on the images displayed on the PACS, while the PACS vendor finger-points to the MRI vendor. So, you are stuck in the middle having to resolve the issue.
There are a couple of lessons learned:
-Always stay informed about any changes to your systems that are to take place. These can look very insignificant but anything that has to do with modalities, the RIS, network, and obviously the PACS itself can have unexpected impacts on your systems.
-Try to schedule mandatory changes in the middle of the week. Towards the end of the week, you’ll never be able to get the needed resources back into the office if there are issues.
-A good practice is to allocate one day every month for all routine updates, e.g. make the second Sunday of the month “change Sunday.” All resources are then scheduled to be available and time for testing the updates is allotted.
-Have a detailed policy for any updates that includes a checklist and sign-off, which require checking that images are properly displayed/handled and processed following changes made. A service engineer making any changes should not be allowed to leave the facility until the PACS SA has reviewed, tested and signed off on the changes made.
-No change should be allowed unless there is a rollback plan with the capability of reverting to the pre-change status, if needed, for whatever reason. In one of the facilities I worked with, the reason for the rollback was lack of training. The users demanded the software release be rolled back as no one was able to figure out how to use the new features.
Now back to locating the issue. There are a couple of tools that can assist you with identifying the issue. The first one we discussed earlier on this blog with a corresponding video shows how to validate image headers. However, an image header could pass validation and still cause an issue. Another neat tool to assist you in determining what has changed after an update has been implemented is the so-called “compare” tool. This tool is also available as a free, open-source application as part of the DVTK toolkit family and allows you to set up a filter to ignore all the attributes that are different for each image (patient information, date, etc.) and will show exactly what has changed. A demo is available as well. (see link)
As I mention often in our DICOM training classes, there is no DICOM Police that you can call upon, and therefore you often have to be self-policing to locate issues and resolve finger-pointing between different vendors. Using the appropriate tools for header validation and comparing changes will go a long way to allowing you to do this.