PACS Admin Job Descriptions & Competencies

Supporting a PACS system might require different skills, and, if the PACS system is of a suffiently large scale, different people having these skills. The overview below lists typical competencies of three categories of PACS support professionals, which also follows the certification as provided by PARCA.

PACS Associate

Scope of Position

The PACS Associate is responsible for the image and information integrity of the PACS. This individual also acts as a digital imaging activities liaison within the department and to other departments. The PACS Associate reports to the PACS System Analyst, Interface Analyst, or Manager.

Principal Duties and Responsibilities

·         Responsible for day-to-day PACS operations including image workflow, archiving, autorouting, prefetching, and other related activities.

·         Works closely with unit operations managers to ensure timely and complete capture of DICOM image data into the PACS as well as network transmission, RIS validation, and exception handling.

·         Investigates, identifies, and prepares proposals to solve problems within all applicable operational areas, working closely with unit operations managers and division heads and involving the next level of administration as needed.

·         Reviews feedback from end users, compiles and analyzes support data, and recommends procedural and educational changes as appropriate.

·         Works closely with radiology quality management personnel to identify future needs and to design efficient workflow processes.

·         Attends seminars and training sessions as appropriate.

·         Ensures all applicable department, hospital, and JCAHO guidelines are met.

·         Performs other functions as required and assigned.

Qualifications

• Associate’s or bachelor’s degree in related healthcare discipline or information systems discipline required.
•  Excellent written and oral communication skills required.
• Must be able to work effectively with diverse groups of people.
• Ability to work well under pressure and on concurrent multidisciplinary projects.
• Familiarity with specific radiology- and imaging-specific applications such as orthopedic templating, 3D reconstruction, and speech recognition.

PACS System Analyst

Scope of Position

The PACS System Analyst is responsible for the clinical aspects of image and information integrity of the PACS. Additionally, this individual will act as a liaison in digital imaging initiatives within the department and other departments. The PACS System Analyst reports to the senior IT manager or the radiology administrator, with accountability to both the clinical and IT departments.

Principal Duties and Responsibilities

·         Responsible for day-to-day PACS operations including image workflow, archiving, autorouting, prefetching, and other related activities.

·         Works closely with unit operations managers to ensure timely and complete capture of DICOM image data into the PACS as well as network transmission, RIS validation, and exception handling.

·         Investigates, identifies, and prepares proposals to solve specific operational problems within all applicable operational areas, working closely with unit operations managers and division heads as well as involving the next level of administration as appropriate.

·         Works closely with the senior IT manager to develop operating standards, policies, and procedures.

·         Reviews feedback from end users, compiles and analyzes support data, and recommends procedural and educational changes as appropriate.

·         Works closely with radiology quality management personnel to identify future needs and to design efficient workflow processes.

·         Primary person responsible for generating and maintaining workflow diagrams and analysis of PACS operations.

·         Responsible for budget preparation and monitoring of the operating budget.

·         Prepares reports for administration on all aspects of PACS operations as appropriate or directed.

·         Attends and participates in departmental/hospital meetings.

·         Attends seminars and training sessions to maintain appropriate level of professional competence.

·         Ensures all applicable department, hospital, and JCAHO guidelines are met.

·         Performs other functions as required and assigned.

Qualifications

• Four or more years of related experience in a clinical setting required.
• Bachelor's degree in related healthcare discipline or information systems discipline required.
•  Excellent written and oral communication skills required.
• Must be able to work effectively with diverse groups of people.
• Ability to work well under pressure and on concurrent multidisciplinary projects.
• Familiarity with specific radiology- and imaging-specific applications, such as orthopedic templating, 3D reconstruction, and speech recognition.

PACS Interface Analyst

Scope of Position

The PACS Interface Analyst is responsible for the technical aspects of image and information integrity of the PACS. Additionally, this individual will act as a liaison in digital imaging initiatives within the department and other departments. The PACS Interface Analyst reports to the senior IT manager or the radiology administrator, with accountability to both the clinical and IT departments.

Principal Duties and Responsibilities

·         Responsible for day-to-day PACS operations including image workflow, archiving, autorouting, prefetching, and other related activities.

·         Works closely with unit operations managers to ensure timely and complete capture of DICOM image data into the PACS as well as network transmission, RIS validation, and exception handling.

·         Investigates, identifies, and prepares proposals to solve specific problems within all applicable operational areas, working closely with unit operations managers and division heads as well as involving the next level of administration as appropriate.

·         Works closely with the senior IT manager to develop operating standards, policies, and procedures.

·         Reviews feedback from end users, compiles and analyzes support data, and recommends procedural and educational changes as appropriate.

·         Works closely with radiology quality management personnel to identify future needs and to design efficient workflow processes.

·         Primary person responsible for generating and maintaining technical diagrams and configuration drawings (including assigned AE titles and software versions).

·         Responsible for budget preparation and monitoring of the operating budget.

·         Works with the corporate director of medical imaging and the administrative director of radiology to identify present and future needs for equipment installation.

·         Oversees activities of vendors in all phases of installation and implementation of new systems.

·         Prepares reports for administration on all aspects of PACS operations as appropriate or directed.

·         Attends and participates in departmental/hospital meetings.

·         Attends seminars and training sessions to maintain appropriate level of professional competence.

·         Ensures all applicable department, hospital, and JCAHO guidelines are met.

·         Performs other functions as required and assigned.

Qualifications

•  Four or more years of related experience in a healthcare IT setting required.
•  Bachelor’s degree in related healthcare discipline or information systems discipline required. Master’s degree in related field preferred.
• Excellent written and oral communication skills required.
• Must be able to work effectively with diverse groups of people.
•  Ability to work well under pressure and on concurrent multidisciplinary projects.
• Proficiency in various OS and database systems.
• Familiarity with specific radiology- and imaging-specific applications such as orthopedic templating, 3D reconstruction, and speech recognition

How Would You Store 1 Billion Images?

The Mayo Clinic in Rochester, MN had 1.3 billion images in its enterprise archive as reported by Ken Persons during the SIIM conference in June. Each day approximately another million images are added. They have gone through 13 data migrations so far, and are doing another three right now covering 27 departments.

Even though 99 percent of hospitals today are not at this level of digitalization and image production, it makes sense to look at institutions like the Mayo Clinic to find out what they learned handling an archiving system on this scale, as the time will come, even if only 5 or 10 years from now, that many institutions will face similar challenges. Just wait until pathology begins to convert to digital archiving, as a typical department handling 30,000 procedures could easily create 100 Tbytes/year.

Managing this amount of data and number of migrations could only be feasible using a Vendor Neutral Archive or VNA. The folks at Mayo hate the term VNA as much as anyone else, that is why they talk about “enterprise archive” as there is no commonly agreed upon functionality for a VNA, even though I tried to define such functionality in this white paper (see link).

One of the major challenges Ken reported at that meeting is ensuring that a new PACS is made “aware” of the historical data in the enterprise archive so that priors are pre-fetched as needed. There are several options on how this can be accomplished, the first one being a “brute force” method, which requires all of the data to be pushed to the PACS to be re-archived, or the images from a specified number of months to be archived and re-indexed. This is clearly unacceptable and defeats the main purpose of having a VNA.

Another option is a one-time PACS database update with all of the available exam content. This is basically a migration of the database only, leaving the archived images in their enterprise location. A third option is to perform a query by the PACS of the enterprise archive to discover any studies that are relevant. The fourth, or “order driven” option is to pre-fetch as needed based on order information. Critical is the migration of the study description so that the relevant priors can be retrieved. If the performance of the retrieval is acceptable and if it is done in the background, I would guess that the “query method” is probably most preferable, followed by the “order driven” method.

One of the major discoveries the folks at the Mayo Clinic made is that there are a lots of pictures, i.e. conventional photographs made as well as videos for all kind of clinical purposes, ranging from documenting a certain gait of people who have trouble walking, to documenting skin lesions. The challenge is to archive all these clips and photos, which are typically stored on CD’s, DVD’s and archived on various computers and laptops, and should be part of the electronic health record as well. I would assume that if you walk around different departments in your institution, you too will find a lot of those types of images as well.

One of the observations I made when talking with the Mayo folks is the fact that they don’t use a commercial viewer to access the images in their enterprise archive. They have their own viewer and even though they benchmark this viewer every couple of years against available commercial viewers, it appears that they can’t buy what is needed to satisfy their physicians with regard to functionality. It is true that their viewer is not just a radiology imaging viewer, rather it is capable of displaying all of the various image types in their enterprise archive. I would argue that it does not take a lot of effort to create such a viewer. I would encourage vendors, however, to find out what is needed to satisfy the Mayo Clinic folks, not only would it result in a customer licensing tens of thousands of your viewers, but it would also provide the capabilities that very likely might be needed for every other customer whose imaging archives begin to grow on the scale of the Mayo Clinic.

In conclusion, it makes sense to find out how large institutions such as the Mayo Clinic are dealing with the exponential increases in image production and how they facilitate all the different specialties and departments in their enterprise archive in order to be prepared as your institution begins going through the same growth process.

How Dirty Is Your DICOM Data?

This looks like a nice image, but the metadata
could be totally incorrect or corrupted

If you would take a snapshot of any DICOM archive and check the image headers for correctness, I would argue that there are quite a few hidden problems that you might not know about.

Errors in a DICOM header can cause images to be incorrectly displayed, incorrectly added to the database, or being flatly rejected by the PACS. By DICOM errors, I don’t mean an incorrect Accession Number of patient name, or duplicate ID, but rather a violation of the rules defined in the DICOM standard for a particular field entry.

These errors are typically categorized as length errors (exceeding the maximum allowed length for a particular field), invalid characters, or a value that does not match the defined list of terms for a particular field. A typical example of a length error would be the value of the station name exceeding the maximum allowed 16 characters, an invalid character would be using a backslash “\” as part of a patient field (note that the “\” is defined as a control character in DICOM), and an example of an invalid term would be the value of “U,” for “Unknown” in a patient sex field.

How and where do these problems occur? There are several potential sources. One is user input errors. I remember that my developers once spent about a week figuring out why certain images were intermittently rejected. Eventually the source was traced to a user who sometimes by accident used disallowed control characters. A robust user interface will filter these out and/or warn the user that the entry is incorrect. However, when the data is generated as part of the order, which is entered by a data entry person and creates a HL7 message, it might not be noticed, as HL7 has a different set of allowable control characters than DICOM. A robust mapping from HL7 to DICOM should convert and/or filter out these incorrect characters.

This gets us to the second source of potential problems: incorrect mapping by an interface engine, modality worklist (MWL) provider, or broker. HL7 has different lists of defined terms, such as the case for “U” for sex, and different length specifications for the fields. A robust MWL provider should take care of most mapping errors.

Some modalities might create invalid headers as well. One such common problem is having a leading zero (0) in one of the segments of a Unique Identifier. Some UID generators do not always check for that, and these headers are typically rejected by the PACS.

Last but not least, one might have invalid images on a CD that need to be imported, which were created by some unknown modality. I had that issue when I tried to import and view images of my dog in my DICOM viewer, which were rejected as these images were missing a Patient ID.

To troubleshoot these problems, in many cases a visual inspection will do as the errors are relatively common and easy to spot. One can import the image into a DICOM viewer and use the DICOM header dump feature. When the problem is not that easy to see, one would use a DICOM validator, which tests the header against the DICOM specifications. A demonstration of the visual inspection and how to perform a validation can be seen here.

After diagnosing the problem, one can either fix the header and resubmit it to the PACS, assuming it is a one-time issue, or if it is recurring, one should go back to the source, for example the modality worklist provider, or modality manufacturer to get this fixed.

I strongly recommend running the image through the validator for every modality, especially prior to purchasing a new device. Remember that potential issues might not bite until later, as your current PACS might be more forgiving and not reject certain attributes in the header, but when the time comes to migrate the data, these problems might resurface and prevent proper viewing or even storage.

In conclusion, image header encoding problems due to incorrect DICOM encoding are easy to see and/or validate using open source tools. It is highly recommended to check your data.

Is your PACS ready for DICOM 4.0?

Despite the title of this article, DICOM does not have any version indicator; as a matter of fact, the DICOM standardization committee, looking back, regretted that they called the newly established version DICOM 3.0 to indicate its relationship with the preceding ACR-NEMA versions.

However, the DICOM standard is continuously expanded: as I always tell my DICOM students, the standard is never more than two months old, as that is the frequency with which the standardization committee approves and finalizes new additions. Why then call this 4.0? Well, to indicate that the current data format specifications look quite different than the original version, which was defined and became popular in the late 1990’s. As a matter of fact, a gradual and silent transition has taken place over the past 15 or so years.

The change began with the new DICOM DX SOP Class, which is meant to be used for not only digital X-ray (DR systems) but also for computed radiography (CR) systems. The main reason for this new SOP Class was the need for a stricter header definition and encoding of pertinent information to benefit the definition of hanging protocols. For example, body part and view are now encoded, so instead of “head” for body part, the SNOMED code T-D1100 would be used to identify the anatomic region, and instead of LAT view, it would specify the code of R-102CD. In addition, there was a need to exchange both unprocessed, raw data and viewable data that can be presented “as-is,” hence the creation of two different SOP Classes for digital X-ray modalities, “For Processing” and “For Presentation.” The For Processing images are typically used as an input for a CAD device as it is the raw, unfiltered full dataset. The For Presentation images produce the view used by the radiologist.

The next major change included the new definition of objects for MRI and CT, which are called “enhanced SOP Classes.” The major change was the definition of “dimensions”, which can be unlimited. This was needed because the traditional linear, simple hierarchy that existed in the standard, whereby a patient can have multiple studies, which can include multiple series of images, was insufficient to cover the many variances and changes in image acquisition. Every vendor has created many private attributes to describe these various acquisitions, which works great if these are displayed on the same vendor workstation, but becomes a problem when displayed on another vendor’s workstation.

 

In addition, in order to reduce overhead when sending thousands of images as single slices, each requiring an acknowledgement by the receiver, these objects are now grouped in a single multi-frame CT or MRI object. This new SOP Class structure, which allows for stricter encoding of all header parameters and the ability to define multiple dimensions, has become the de-facto basis for all new SOP Classes such as the new classes for new cardiology and fluoroscopy, ophthalmology, pathology, and the new mammography tomosynthesis studies.

Another major change was the creation of Structure Reports (SR), which was driven by the need for ultrasound devices to exchange measurements in a standard, coded manner, using well defined templates. Most of the common ultrasound procedures, especially for cardiology but also OB/GYN and others, now have a well defined template, which can be stored in the PACS as it follows the DICOM protocol, and is interpreted by reporting systems, eliminating a lot of duplication by radiologists. In addition, the SR are also very well suited for presenting key images in a standard manner. Other well supported applications are the use of SR for CAD, and, most recently, for dose reporting, which has become a major issue, especially in California, which is requiring this reporting.

Presentation states also have been slipped in as an enhancement, whereby radiologists can save their annotations and measurements from a workstation in a standard manner, instead of in private header attributes or database records. Many of the current PACS systems now support this feature, albeit some of them in a somewhat awkward and user-unfriendly manner, which hopefully will be taken care of in future release upgrades.

So, are you ready for all DICOM 4.0? Most likely not; except for some special applications such as cardiology, which is embracing SR big time, most radiology systems and reporting systems are still struggling with SR support. Enhanced CT and MR support is still very limited, keeping the status quo of having to use modality and vendor specific workstations for specialized processing. Dose SR are also still in their infancy. It is therefore critical to plan for these enhancements, especially as they will provide major efficiency improvements and better visualization capabilities.

One should also be aware that even if a vendor specifies support for these new extensions, support for these new objects at a workstation might lack serious functionality. Case in point is a vendor that supports the new enhanced CT but merely organizes the images in a single large stack instead of interpreting the rich header definition. Also remember that the only way vendors will be implementing these improvements is by user pressure and education.

DICOM configuration and Unique Addressing

Unique addressing is equally important
for electronic as well as physical  mail

A medical device that intends to exchange information over a network requires unique addressing at various levels for network cards, routers and applications in order to communicate. Unique addressing requires that there is only one address within a certain domain and therefore guarantees that any information routed to that destination will be delivered only to that unique address. It is no different than the street address used by postal mail. Interestingly enough, I discovered only a few years ago that several countries have no unique address, and homes are often identified with descriptions such as “3^rd house with the green door across from the Catholic church.” Obviously if this type of addressing does not keep up with new construction, the mail is often returned undelivered. This would not be acceptable for the delivery of patient images and related information.

Application level addressing for DICOM devices is done by assigning an Application Entity (AE) Title. The protocol to negotiate a DICOM association requires the declaration of a Calling and Called AE Title. The Calling AE Title identifies the association initiator, which is in almost all cases the Service Class User (SCU), and the Called AE Title identifies the destination, or in almost all cases the Service Class Provider (SCP). A device such as a modality will typically have multiple destinations, for example, a CT might be routed to a PACS, an image processing workstation, and one or more Teleradiology destinations to send the images to after hours.

The AE Titles are typically managed by a PACS administrator similar to IP address management, which is usually done by IT. Uniqueness is important, and some kind of “system” does make sense as well. As an example, when I visited Alaska, I found that AE Titles for each device are given a prefix using the town’s airport code (virtually every little town in Alaska has its own airstrip and therefore code). Others use site ID’s or abbreviated hospital names. A typical AE Title could be STJOE_CT01_ER. Remember that the length of AE Titles is 16 bits and case sensitive, i.e. STJOE is a different AE Title than StJoe. Some might argue that the Calling AE Title does not have to be unique as there is no SCP capability, however, I disagree on best practices grounds since many destinations check the calling AE Title and in cases where the Calling AE Title is not on the configuration list, the association request is refused. This is only the case if the system to be connected is what we call non-promiscuous, as promiscuous systems do not typically perform any checking of the calling AE Title.

Unique IP addressing is also critical. Unfortunately, the DICOM communication protocol does not facilitate dynamic IP addressing, which is sometimes an issue, especially when using mobile and/or portable devices. There is actually a DICOM protocol defined to allow for dynamic addressing as part of the so-called DICOM configuration management protocol, but that is rarely implemented.

The last time that I heard issues about using duplicate IP addresses was several years back and this no longer seems to be a big issue. One needs to be careful with re-imaging a computer configuration on different machines using the same image, especially when using virtual machine technologies, as the IP address might get re-imaged as well.

A network connection also requires a unique port number at the receiving device. There is some confusion about the port number to use for DICOM Associations as the most common or “well known” port number, 104, sometimes cannot be used due to restrictions by some operating systems. Vendors have been resourceful and used other, non-standard numbers such as 6001 and others. However, the best port number to use is 11112 as this is the Internet Assigned Numbers Authority (IANA) officially assigned port for DICOM applications. I have experienced issues in the past when there are multiple applications running on your computer, some of them automatically start with assigning port 104 to DICOM applications. In such cases, images being received might get “lost” as another application might be taking over control of that port. A port scanner may be useful in that case, which is available as a free tool on-line.

Configuring a modality with the AE Title(s), port number and IP address is relatively straight forward, a demo of an example using a modality simulator can be seen here.

In summary, one needs to make sure that AE Titles are unique; these are typically managed by a PACS administrator. The same requirement for uniqueness applies for IP addresses, and the recommended port number for DICOM connections is 11112.