Friday, August 24, 2012

Creating a virtual RIS/PACS test environment


When troubleshooting, testing, and validating a connection between devices that use the DICOM and/or HL7 protocol, it is important to have access to both test transactions, test objects such as documents and images, and simulators. Each component can be replaced by a virtual simulator, including a test RIS, modality worklist provider, modality, archive, viewer and report generator, which have very detailed logging and sometimes even validation capabilities. I am convinced that with these simulators, combined with additional stand-alone validators, such as those used to validate a DICOM image header, and a sniffer to troubleshoot problems that are semi-random, you can identify any problem that might occur during system integration.

Most of these simulators are available in the public domain, and are relatively easy to install. Learning how to use them and practicing error scenarios is strongly recommended so you can resolve problems as they occur. Many healthcare IT and imaging professionals have learned to use these tools the hard way, i.e. on the job. An easier and more effective way is to take a training class as provided by OTech. Taking this class will not only speed up the learning process but also provide you with many test transactions, images, and scenarios and with all the tools that allow you to create the virtual test environment, which by itself is worth the price of attending the class. For more information, visit our the information at our website about this hands-on seminar. If a face-to-face class is not for you, you can always visit the otechinc youtube channel, which has several “tools and tricks of the trade” videos on how to use these tools as we would use them in our seminars. 

Thursday, August 23, 2012

Will the PACS SA profession be obsolete in 2015? PACS SA Career series Part 1

A PACS administrator is critical to support
healthcare imaging applications
There is no question that the traditional role of PACS System Administrators (SA) has changed over the past 15 years, and there is also no question that it will continue to evolve over the next 5 to 10 years. Instead of “going with the flow,” it might be wise as a PACS SA to actively anticipate the future for as far as possible, and work towards a preferable upwards career path. Remember that even though there are no formal statistics, it is generally assumed that each person has about seven different careers in their lifetimes, which means, assuming 42 years of employment that means one might be on the lookout for a change every six years.
There are plenty of opportunities for PACS SA’s as they have acquired unique multifunctional skills and experiences that are very valuable in managing and supporting healthcare imaging and IT systems. These range from internal career growth to managing multiple imaging departments or electronic records management, working as an independent consultant or for a major consulting firm. One can also transition to the vendor side in sales, project management or as a service and support professional.This series of articles will explore the trends and changes that have occurred over the past few decades with the PACS SA career, and explore each of these career tracks by interviewing established PACS SA’s in a given field. Although I have spoken with quite a few PACS administrators, as many of them have attended our PACS and DICOM, HL7 and IHE training classes, this is limited to an overview and will not try to present a comprehensive examination of all possible PACS careers. Nevertheless, I hope this series will l jump start ongoing regular interactions, not only during our live web-based interview sessions, the first being on September 4 (TIME 7:00 PM CST) on our first OTech Google+Hangoutbut also afterwards.  (Join OTech on Google+ and add us to your circles and tell us your interest while joining our “Hangouts” in order to receive an invitation for the upcoming applicable Hangouts.
PACS administrators are known by many different titles. Based on a survey, there appears to be a wide variation of job titles reported by those filling the role of a PACS or Imaging and Informatics professional. The most frequently reported job title (37%) is “PACS Administrator,” or “PACS System Administrator.” The next most frequently reported job title (11%) is “RIS/PACS administrator.” Only 11% of professionals have the word “imaging” in their job title.

Below is a list of the job titles reported in the survey:

Chief Tech/PACS Administrator
PACS - Clin. Eng.Syst. Integrator
Clinical Applications Analyst
PACS (System) Administrator
Computer Specialist / imaging
PACS Admin/ QM Tech
Digital Imaging Analyst
PACS Analyst
Director of Imaging and IT Infrastructure
PACS Coordinator
Director of Information Technology
PACS Manager
Enterprise System Administrator
PACS Technical Support Manager
Imaging Coordinator
PACS/Clinical Coordinator
Imaging Director and RIS/PACS
PACS/RIS/PowerScribe Admin.
Imaging Informatics Administrator
Radiology Systems Coordinator
Imaging Informatics Manager
Regional PACS Analyst
Imaging Supervisor
RIS/PACS Admin
Imaging Systems Administrator
RIS/PACS Coordinator
Information Systems Support Services
Sr. System Anal. for Im. Informatics
Manager of Radiology Information Systems
Telemedicine Administrator


Let’s first explore a little of the evolution of this career. I suggest breaking down the evolution in periods of 5 years:

  1. Early childhood (pre-2000)
The period from 1995-2000 marks the emergence of the PACS SA as a career as many departments began assigning dedicated resources to support the PACS. Many systems had a very experienced dedicated PACS service and support person, often fulltime or, if not, a part-time or contract person present at a site. The tools for fixing studies, reports, and performing any troubleshooting were crude and it took a lot of time and effort to support a PACS system. You had to know about DICOM as it often required looking at dump or log files and there was a high dependence on vendors for support.

  1. Teenage years (2000-2005)
This era was characterized by the commoditization of PACS. It required more tools to support them, many more vendors had to be trained and, unfortunately, their knowledge levels decreased. This was another reason for providers to upgrade the education of their SA’s. More educated and trained the support, however, greatly depended on in-house resources. Another advance during this period, in terms of defining the PACS SA career, was the creation of certification organizations, i.e. ABII and PARCA, in conjunction with efforts to create more or less formal job descriptions (see post for a sample). At the same time, HIPAA became a requirement during this period, which brought additional requirements and corresponding job duties and functions.

  1. Reaching maturity (2005-2010)
As PACS systems got more sophisticated and configurable, the need for easy-to-use tools for fixing studies, setting up hanging protocols, creating reports and looking at audit trails became a necessity and available. The careers of “PACS assistants” or “associates” were created. These are super-users who work as technologists but can fix studies, merge them, set up and change simple configurations. Also, tech savvy file room personal were being trained to import and export CD’s in a manner that would not jeopardize system integrity. PACS SA’s were able to work on project management, define and implement institution-wide PACS policies and procedures, including critical down time procedures and reliable back-ups.

  1. Middle age (2010-2015)
The PACS SA career is reaching a period past maturity. As of 2012, there are an estimated 2,000 certified PACS SA’s, about equally divided between the ABII CIIP and PARCA organization. As a matter of fact, it is time to re-evaluate the certification requirements and create growth beyond the basic certification in the form of an enterprise certification for those professionals that elect that particular growth path. Tools are now rather sophisticated for the support of PACS systems. Remote access allows SA’s to manage systems in multiple locations, and PACS issues are being expanded along with open source tools such as DICOM sniffers and validators that are readily available to troubleshoot even the most tricky problems (see for example on how to use a DICOM sniffer). PACS SA’s are getting very involved with migrating issues for new upgrades, PACS replacements, or VNA and/or cloud solutions for archiving the images, and they are educating themselves about Meaningful Use criteria to get on the EMR incentives bandwagon.

  1. Ready to retire? (post 2015)
I don’t believe that the PACS SA career will become obsolete, but rather it will grow into a role that includes more components of training, project management, planning and coordination. Images are going to be not only available within the enterprise but cross-enterprises through new protocols defined by IHE, which allows images to be exchanged between radiologists referring physicians, specialists, and in some cases, they might be managed by patients through their own Personal Health Records. Imagine the issues that came along with the exchange of images using CD’s, these issues will be multiplied exponentially when the number of images being exchanged increases more than tenfold, all electronically.  Bringing up the appropriate prior studies for a comparison is already a challenge within a single enterprise; imagine this enterprise becoming a regional health information exchange. I think you get the picture (no pun intended). I do believe that the trend of bringing the SA job under IT will continue, even if not from a functional standpoint, then at least from a hierarchical perspective.

In conclusion, I don’t think that the PACS SA career will become obsolete in the foreseeable future, but will continue to evolve. However, independent of the PACS SA career, you might want to explore other opportunities as will be outlined in future segments of  this series where we will explore the career paths on the provider side, consultant and vendor sides as well.


Thursday, August 16, 2012

Top 10 DICOM Modality Worklist Issues



A DICOM modality worklist is retrieved by an imaging modality such as a CT, MRI, ultrasound, digital X-ray unit, or other imaging modality from a modality worklist provider, which can reside in the PACS, RIS or a separate device, such as a broker. Configuring the worklist on both sides, i.e. at the modality and on the worklist provider side, can be somewhat tricky to make sure that all pertinent information is available on the worklist, and does not contain too much or too little information. The pertinent information means that only studies that are to be scheduled for this device appear on the list, and does not contain studies to be done on other modalities. The worklist information therefore should be filtered and configured on both ends. Many times, the only way to find out the behavior is by using a modality simulator to predict and/or troubleshoot any issues with the modality worklist as described below. A demo is available here.
Below are the most common issues and configuration challenges:
1.       Where do I get my worklist from? This used to be a “no-brainer” as almost all PACS systems included a so-called broker, which would listen to the HL7 order messages, build an internal database for the scheduled appointments, and provide a DICOM worklist on demand. However, over the past few years, most PACS and department information systems, notably the RIS and CIS systems, have implemented this functionality, which is often referred to as a “broker-less” PACS or RIS. Unfortunately, the robustness and flexibility of these implementations have suffered and the number of worklist issues has increased. With regard to the worklist source, most modalities only support a single worklist, which is fine in most cases, but what if an ultrasound is used (and scheduled) by both cardiology and radiology requiring two work lists to be queried? Where is surgery scheduled and do I need to get another broker for those procedures? Same question applies for endoscopy exams, dentistry, and all other specialties that require images to be sent to the PACS.
2.       How do I provide a wireless worklist? Many ER and ICU departments, where portable exams are performed, use devices that can retrieve the worklist via a wireless router. This raises issues surrounding the security and authentication needed to protect the information. In addition, several incompatibilities have been reported with wireless devices and the worklist provider. A good rule is to test the wireless capability in all places you think one might have to use with the device prior to accepting a new unit.
3.       Which patient ID and physician should one use? The HL7 order message, which is used as the source for the worklist, has several Patient ID fields; an internal, external, social security number, medical record number, and even a location for the master patient index. The worklist provider needs to select the correct field to be used as the unique patient identifier in the PACS as it only has one field to contain that information. Additional ID’s may possibly be mapped in the so-called “Other Patient ID” field in the DICOM worklist. A similar problem occurs with the referring physician as the HL7 can contain several locations for the physician, which should be configured as well to make sure the right physician ends up in the corresponding DICOM field.
4.       How is the location of the modality that is to perform the study determined? In some cases, the modality field in the worklist is not sufficient to determine the location, but, rather, the modality needs to filter by station name and/or AE -Title in the worklist. The challenge is to deduce this information from the order information. For example, a bone density scanner could have the same modality identification (CR) as all of the other digital X-ray units in the main department. Another example is the distinction between an open and closed MR based on certain procedure information. The worklist provider needs to fill in the correct location based on information derived from the order.
5.       How to convert the invalid DICOM field and length values? For example, a backslash “\” is a valid HL7 character but is a control character in DICOM, and some of the HL7 fields have a different maximum length than their DICOM counterparts. Some of the coded values are also different, as an example, if the sex of a patient was unknown, identified with a “U” in HL7, it has to be converted to a value of “O” in the DICOM worklist to be valid.
6.       How to map modality and procedures? The modality identifier, e.g. MR, US, CT and other abbreviations, are not part of the HL7 order. The worklist provider needs to maintain a list of procedures and map it to the applicable modality. The correct part of the procedure description has to be mapped as well. I have seen problems where, instead of the full procedure description, the mnemonic or abbreviation was filled into the DICOM worklist while the modality expected otherwise, which eventually resulted in breaking hanging protocols at a workstation.
7.       How to configure the refresh rate of the worklist? The best manner to use for a worklist at a modality is for the technologist to refresh the list just prior to getting the next patient. Some devices are configured to poll the worklist provider with a configurable interval, for example every minute. If every modality is configured to poll the worklist provider, some of them are known for getting bogged down and overloaded. Therefore, unless required from a worklist perspective, e.g. when the worklist retrieval performance is creating issues, it is recommended to configure the modality to NOT use polling.
8.       Does the modality use single value matching or a broad query? Single value matching is used to retrieve a worklist item using an exact matching key such as an Accession Number or Patient ID. The advantage is that the resulting match is in most cases one, or at most a few, reducing the risk for incorrect selection. A broad query is used, for example, to request a worklist for a modality such as MR for today. If possible, single value matching is preferred.
9.       How to remove items from the worklist? Most institutions require a manual “exam complete” transaction by a technologist either at the PACS or RIS, which causes the entry to be removed from the worklist. If a modality has Modality Performed Procedure Step (MPPS) configured, this would be automatically performed by the MPPS transaction.
10.   How are modality request keys configured? Some worklist providers reject a query if they receive a matching request of one or more keys that they do not support. Even though this is non-standard behavior, it can be easily resolved by configuring the modality (if possible) to query with only the keys that are supported by the provider.
In conclusion, a modality worklist is often tricky to configure for both the modality itself and the worklist provider. Using a simulator can be not only helpful, but in some cases, the only way to find out its specific behavior.

Tuesday, August 14, 2012

Tips from a road warrior (23): Document your parking spot.

DFW airport parking
can be challenging
I assume that I am not the only one who, coming back from a trip, has forgotten where I parked my car and found myself walking all the floors of a parking garage to spot it. I once actually had to hire a taxi to drive me around the different terminals at Dallas-Fort Worth (DFW), where there are 5 parking garages, to find it. I also have been known to forget my location in non-airport garages, especially when using a rental car, of which the brand and color I might have difficulty remembering.
To prevent it happening again, I currently use a well-proven system whereby I write down the parking spot on the envelope that contains all my travel information such as hotel confirmations, tickets, and contact information for the people I am supposed to meet. I stick with paper copy, unlike several of my colleagues who take a snapshot of the location indicator with their smart phone, which only works as long as your battery life holds out (as one of my colleagues found out).
The lesson learned from this experience is that documentation is a lifesaver, which applies not only to travels but also to the job of managing complex systems such as PACS systems. I have learned several examples where documentation has proven to be invaluable, especially in areas that you might not have thought of, some examples are listed below:
·         Calibration records: Most institutions calibrate their diagnostic monitors regularly, which should be the case for all of them. If not, then it is strongly recommended to keep track of the calibration information on a separate computer and make sure it is backed up. I know of at least one court case where a PACS administrator was required to pull records from a few years prior to show in court that the monitor a radiologist was using to perform a diagnosis was properly calibrated at the time of the diagnosis.
·         Hanging protocols and physician preferences: Imagine having to recreate all of these! Some of the software upgrades require them to be set up again. It is important to save and backup this information to avoid having to redo all of them again.
·         Addressing information: It may seem obvious, but I still meet PACS administrators occasionally who admit that they don’t manage AE titles properly. I have actually experienced port conflicts myself as I had several DICOM viewers installed, with some of them listening to port 104 as soon as the computer is started. Documentation is key. To change this at a modality is demonstrated here.
·         Locations of equipment and connectors, including type: People seem to move equipment to make space for another device and connect to another wall plug, which might or might not be live or may have a different setting. To find out if anything changes, it is important to document the current location and plug number.
·         Versions of modalities: Vendors like to upgrade their modality equipment, sometimes only notifying someone in biomed, and not the PACS team, which might impact the behavior and display of the images. It is important to document the software versions of all the modalities connected to the PACS to determine if anything has changed.
In conclusion, documentation is critical, especially for those areas you might not think of, to make sure you are not stuck or get lost as I used to when looking for my parking spot at the airport.