PACS troubleshooting tips and tricks series (part5): DICOM communication errors.

In the last blog posts in this series I talked about network, addressing issues and incompatible file

types as well as transfer syntaxes. This post deals with errors that might occur doing the actual DICOM information transfer, i.e. after the DICOM connection (Association) has been successfully established.

When an Association is accepted by the server (SCP), which is indicated by the “Associate_Accept” transaction, the DICOM client (SCU) will issue the DICOM command, which is determined by the negotiated SOP Class. For example, imagine that a device proposes to exchange CT images and it is “OK-ed” by the SCP, the SCU will issue the C_Store command with the CT image file. The receiver will interpret the command, then discard that, and take the file and likely archive it in the case of a C_Store. It could also update a database so it can find it and/or reply to a DICOM query about its location.

If the SCP is a transient device such as a DICOM router, it will pass it on to its destination. Each DICOM command is returned with a corresponding Response, for example, a C-Store Request will result in a C_Store Response, the same applies for queries, moves, etc. The response has a status code associated with the transaction; hopefully it will be “success,” which is identified with the code “0000.” In case there is an error, the status code will contain the appropriate error code other than  “0000.” These codes are standardized by the DICOM standard, i.e. there are codes defined for the most frequent errors and warnings. 

Here are some of the common errors that you might see:

·        Resource issues - Imagine that you are sending a set of images to a destination with limited resources, such as a workstation with limited disk space. In the case that the destination cannot receive any more data files, it will indicate that in the status code A700, meaning “out of resources.” To resolve this issue, one would either go to the destination to free up more resources or send the information to another destination. The reason this error occurs is that one does not know in advance how many files are going to be sent, as there is no indication in the Association negotiation to say how many images are to be transferred. The resource issue does not have to be related to the required archive space, it could also be space for additional tables in the database or other resource restrictions.

·        Processing errors - The receiver reports errors when processing the information; for example, it might need to update several database tables upon receipt and archiving, and might have a problem as the images cannot be uniquely identified due to duplicate or missing identifiers. Not every receiving system implements the same set of criteria determining this error condition, some of them will actually accept the information and report “success” while quarantining the data file and flagging it as “Unverified” or “Broken.” This is done so that a physician might still be able to view them and could report on them, while awaiting resolution of let’s say the complete patient’s name and/or other demographic information. We’ll spend another post on the most common issues causing the Unverified status.

·        Warnings - A server might also give back a “warning,” its status code typically will start with a hex “B,” an example would be a print server sending back a warning that the number of sheets is getting low in a supply magazine. Another example could be a server telling a SCU that it modified or “coerced” one or more data elements in the header, as needed to make it unique or based on a patient update or merge. Most applications ignore these messages.

·        Pending - A “pending” status return message is not an error condition, but an indication to the client that the server is processing the request and will send more replies. This is common for a query response that has multiple matches. This non-successful completion is part of a normal behavior.

How would a client behave when it receives an error? Each device could have a different reaction, some might just continue with what they are doing and log the error, some might stop and notify the user, and some might retry for a configurable number of times with configurable intervals. If a device is following the DICOM standard guidelines, it should specify its behavior in its conformance statement under the section “SOP Specific conformance” for that particular SOP Class. Therefore, check that resource, noting almost all of the DICOM conformance statements can be found on-line. Make sure though that when you look at these conformance statements, that you have the right software version matching your device.

These types of errors are somewhat unpredictable and typically are caused by data information errors or inconsistency, unlike the errors that are caused by file type or transfer syntax errors. As mentioned earlier, it is possible that a server still acknowledges the information transfer to be successful, even if there is an issue to allow a physician to access the incomplete data, such as is common in the case of emergency where the patient cannot be identified at time of patient registration. These most common causes for these so called “Unverified” studies is going to be discussed in our next post.

For additional resources on this topic, you can use “www.otpedia.com,” which has a definition of the most common DICOM terms, or the DICOM textbook which is available either as a printed text or e-book, or, attend our on-line or face-to-face training seminars on PACS/DICOM.

PACS troubleshooting tips and tricks series (part4): Transfer Syntax support errors.

The last three blog posts in this series I talked about network, addressing issues and incompatible file

types. This post deals with incompatible Transfer Syntaxes (compression etc.) that could be proposed by a DICOM device initiating a DICOM connection.

In the last post I explained that a device proposes a list of items called a Presentation Context, which includes the file type (Abstract Syntax or SOP Class in DICOM terms) to be exchanged and the proposed encoding or Transfer Syntax of these files. These transfer syntaxes are a different representation of the data, the information content is still the same. Think about it as sending a file either in its original size, or, send it as a “zipped” file, in either case, the content is identical.

There are three parameters that can change in the Transfer Syntax:

1)     The byte order,

2)     Whether or not the data exchange includes the data type (or Value Representation) for each data element, and

3)     Whether the data is compressed.

When a particular transfer syntax is not supported by the device it will typically give back and error with the text “Transfer Syntax” not supported or the more generic message “Presentation Context” not supported.

·        Byte order issues - The byte order can be either Little Endian (LE), or Big Endian (BE), which defines whether the data is encoded for each word with its least significant byte first (LE) or most significant byte first (BE). As an analogy, some languages are written and read from right to left (Arabic, Hebrew), instead of left to right, it is a matter of knowing how to read the data (otherwise the data would be reversed). BE is usually associated with a UNIX based operating system using a Motorola CPU architecture, which means that you’ll see them only in relatively old images as most devices are now based on Intel/Windows architecture. 

Almost all PACS systems will support both LE and BE because they need to support these old formats, you’ll rarely see a BE modality. However, due to its limited support, I strongly suggest that you configure a system to ONLY support LE to prevent compatibility issues. I have seen a systems that claim to support BE, but do not display them correctly. Note that LE is the default transfer syntax, meaning that every system is supposed to be supporting LE.

·        Value Representation (VR) support issues - Each data element in the DICOM header can either specify for each individual element in its data type (Explicit VR) or leave it out (Implicit VR), which leaves it up to the software to support a data dictionary to determine its data type. Despite the fact that the Implicit VR is the default Transfer Syntax, I strongly suggest setting all of your devices to only send and/or accept the Explicit VR. The reason being that when archiving DICOM files on a CD, the Explicit VR is the required encoding, therefore you’ll reduce the chance that someone might just copy that file to a CD without doing the Implicit to Explicit VR conversion. In addition, many vendors include private data elements in the DICOM header and by requiring explicit VR, you will at least know the data type of those data elements, so you could potentially manage and interpret them.

·        Compression issues - Compression support has become important as new image files and studies are starting to get very large (notably the mammo breast tomosynthesis) thus taxing the communication and storage infrastructure. There are many compression versions defined in the DICOM standard, last time I counted there were 35!  In practice, most PACS systems might support only a handful, e.g. about 5-10. The JPEG for still images and MPEG for video are the most popular, and lately the JPEG2000 (Wavelet) compression is supported as well. If your PACS has not been upgraded lately, it might not support Wavelet, which will cause a rejection when a device wants to use the wavelet encoding for information exchange. This could be a problem as some of the senders might not be able to decompress the data upon request. Some devices support a proprietary compression which obviously only will be supported by devices from the same vendor. Note that compressed images are not allowed on the most popular CD format, which sometimes creates issues if this rule is not followed. When a lossy compression syntax is used (lossy means non-reversible instead of the lossless compression which is reversible), the creator of this file is required to change its Unique Identifier (UID), i.e. another copy if the image, which sometimes causes issues as some systems are confused about supporting two versions of the same object, i.e. the original and the lossy compressed. The creator of the lossy compressed image is also required to upgrade the header with a “compression flag” preventing the image from being lossy compressed again in the future as this will create major image artifacts.

Transfer syntax issues together with file type issues are the major causes  that a connection cannot be established. The good news is that it should be a consistent error, i.e. unless there is a software upgrade, or the user selects another object and/or transfer syntax, it should keep on working when its initial installation is successful. Detection of these issues can be done by looking at the log files at the sender and/or destination, or, if there is limited access to those files, using a DICOM sniffer such as Wireshark. It is important to recognize if a connection fails due to the initial negotiation of the file type and transfer syntax, or if it is during the actual data exchange, which we are going to discuss in the next post.

Additional resources regarding this topic can be found in the DICOM textbook, and additional skills to troubleshoot these issues can be learned in our DICOM/PACS training classes, either on-line or face-to-face.

PACS troubleshooting tips and tricks series (part2): Addressing.

In my last blog, I discussed network and transmission issues, in this write-up I’ll discuss “addressing” issues. A DICOM device needs to be configured with three addresses:

1.   The network (IP address)
2.  The port number
3.  The Application level address aka AE-Title

As an analogy, think about the IP-address as a “street address,” the port number as the apartment number (let’s say 38A), and the AE-title the tenant, which can be multiple if the apartment is shared by several occupants.

Imagine that a system cannot communicate; the causes could be due to:

Use "ping" to check network availability

• IP issues - this can be caused by incorrect VLAN configuration, router DHCP settings, wireless issues, VPN problems, firewalls or as simple as having the incorrect IP address of your destination. Remember that DICOM was defined in the early 1990’s when no-one thought we would run out of IP addresses, so it relies on fixed IP addresses and cannot handle the dynamic addresses typically issued by DHCP. (Actually there is an option in DICOM that allows it but it is rarely implemented). Testing if you can reach your destination is simple, you use the command to get to the DOS screen and use the ping command with the appropriate IP destination (see illustration 1). To find the IP address of your destination you can use the “ipconfig” command for windows or “ifconfig” for Unix at your destination computer. Wireless connections are challenging, as many devices now are becoming wireless, such as portable ultrasounds, portable x-ray units, and the digital acquisition plates for digital radiography.
• The challenges with wireless are:

1. The communication has to be encrypted (remember the metadata in the DICOM files that are transferred contain patient information)
2.  The IP address has to be fixed, which could be a challenge when moving between different floors and connecting to a different wireless router
3. There are still immature wireless applications out there, i.e. unstable connections at the devices themselves. Note that the fact that a device communicates today does not mean that it works tomorrow, as there could be a new router installed with incorrect IP settings by your IT department.

·        Port issues - the “well-known” DICOM port is 104, however some devices don’t allow you to allocate this port in this low number range and therefore, a relatively newly “approved” DICOM port is 11112. It is strongly encouraged to always use this officially assigned port (as defined by IANA) when you configure your system. There could be multiple DICOM applications listening to the same port, I had this happen to me after I installed a DICOM viewer on my laptop, which was listening to 104 in the background and grabbing my images instead of the archive I wanted to send to it, which took me an hour or so to figure out. The “netstat” command will show you information about your network, with some of the options including the port numbers and processes that are attached.

Use Verification to check DICOM
AE availability

·        AE-Title (AET) issues - Some systems use the computer host name as an AE-Title, which is poor practice as a single host could have multiple AE-Titles. Some systems have a fixed AE-Title which is even worse, as they should be configurable. It is recommended to have a local “standard” about AE-title assignments, for example, include the hospital abbreviation, location and modality such as BAYL_DT_OUTP_CT1 being CT number 1 in the outpatient department at Baylor Medical Center in Dallas downtown. A good practice is to use capital letters only for the AET to eliminate any case sensitivity issues. Remember, there can be multiple AE-Title’s listening to the same port at the same IP, for example, a PACS system might have different AE-T’s for the archive, database, and workflow provider. Duplicate AE-Titles on the same network will create problems, especially when retrieving information, as the AE-Title is part of the retrieval command.
Most PACS systems will need to add the initiating device to be added to its configuration file for image retrievals, which would explain the fact that you can sometimes list the studies on a workstation but that the subsequent retrieval will fail. Some of the PACS systems allow you to configure it in a “promiscuous” mode meaning that it will listen to any device accessing it at the correct IP and port, also something that is bad practice and should be discouraged. Testing if the DICOM application is running and is able to reply to an initiating device is done by executing a DICOM Verification, aka “DICOM-ping” or “echo” command. Some of the applications allow you to execute this from the application, sometimes you have to find it at a service or other menu, see illustration for a sample.

PACS addressing issues are relatively easy to troubleshoot, if you use ping and DICOM Verification, you should be able to solve 95% of the issues. Sometimes you might find that ping does not make it through because of very strict IT policies and subsequent router settings, and some rogue DICOM implementations might have trouble supporting Verification (which is a requirement for any device that is a DICOM listener). 

If you are new to DICOM O(or like to learn more about its fundamentals) you might want to check out the DICOM textbook, or sign up for our on-line or face-to-face DICOM training classes which have quite a bit of hands-on exercises.

Last but not least, look for more upcoming “troubleshooting tips” which will be on DICOM file support issues.

PACS troubleshooting tips and tricks series (part3): DICOM file type support errors.

In the last two blog posts in this series I talked about network and addressing issues. Assuming we
are able to connect to another device, the next step is trying to exchange certain information between the two devices using the DICOM protocol. Here is where things can go wrong as well.

Before we discuss details, let’s go over the DICOM protocol steps that include the handshake. There are two separate levels of communication, the first one being the connection management, which can be considered the “session” layer of a protocol, whereby a connection is properly established and released. Establishing the connection includes an agreement of what information will be exchanged and how it is being encoded. The negotiation of the information exchange is a simple “proposed” and either “accepted” or “rejected” step. We’ll discuss the handshake about the filetype to be exchanged first.

There are three terms that are important in this context: the “Presentation Context” which is the set of parameters being proposed by the client device which includes the type of information to be exchanged, such as “CT Images,” a “Dose Report,” an image “Presentation State,” and many others. The second term to know is the “Abstract Syntax” that identifies the information to be exchanged, and the third term is the “SOP Class” identifying the requested service, such as “Store these CT images.” Incompatibility issues are typically reported by the device as “Presentation Context,” “Abstract Syntax,” or “SOP Class” not supported.

These are some commonly encountered issues:

·        The image type that is proposed by the client is not supported. The error that might come back

Example of "Abstract Syntax" not supported log using
Modality Simulator (OT-DICE)

and you’ll see in the log file can be either “Presentation Context,” “Abstract Syntax,” or “SOP Class” not supported. This happens most frequently if a device supports a relatively new image type such as the Breast Tomosynthesis Mammography image, or an Enhanced (multiframe) CT or MR, or some of the specialties that were recently added such as for ophthalmology, digital pathology and others. To diagnose this, you can look at the log files at the sender. If you don’t have access to these log files, you can use a sender-simulator that will allow you to see exactly what is happening. For the simulator, you can use various tools, I mostly use the DVTK toolset, which includes a simulator or OT-DICE (see illustration of the “Abstract Syntax not supported”). The Wireshark DICOM sniffer is also a great diagnostic tool to identify such problems. A solution to this issue is an upgrade of the software of your device, which might be a major undertaking and expensive, using a “fallback” image type which is configurable at the modality such as using the “traditional CT” instead of the “enhanced CT” SOP Class. Some archives allow a configuration change to support a new SOP Class with the understanding that they can be archived but maybe not properly display at the PACS workstation.

·        A non-image file type is not supported by the server (PACS, Workstation). You’ll see the same errors as listed for the file types, but they refer to a non-image file such as a Dose Report, a CAD Structured report for mammography or chest, a Presentation State containing image manipulation and display information, ultrasound measurements, a DICOM encapsulated PDF, and many others. These objects are typically meant to be sent with the images in the same study, and it is likely that the images will make it to its destination, but not the corresponding non-image files, so you probably will get a  “DICOM error.” You’ll use the same tools to diagnose and/or simulate this as for the image type issue.

·        A private image or non-image file is being proposed. Vendors frequently create private or proprietary file types. This is common for some CR vendors, ultrasound, and others. If the images are sent to a PACS from the same vendor, the PACS will most likely support and display them, but subsequent viewers very likely will not. Imagine that a private file is sent from Vendor A modality to a Vendor A PACS successfully, if forwarded to an enterprise archive from Vendor B, it might fail to connect. The same tools apply, to diagnose and simulate

·        A non-appropriate SOP Class is used as an interim solution. Some vendors create a different modality and corresponding image format, e.g. CT instead of mammography, a screen-save (Secondary Capture) instead of an ultrasound, or other SOP Class that was not intended to cover a specific modality. There is not much you can do about this except for upgrading your PACS as soon as you can, and at that time try to convert these anomalies back to the original, intended file type.

·        CD’s are inoperable. Instead of trying to exchange these different file types over a network and being rejected by the intended receiver, you also may experience exactly the same problem when trying to read images from a DICOM CD. After diagnosing the issue, the problem might be harder to solve because you might need to contact the creator of the CD, which is likely not local, to resolve the issue.

Filetype issues are sometimes a little bit hard to diagnose as you might not always be able to or be allowed to use the tools mentioned. You could change that of course, I know of one vendor who installs a modality simulator (OT-DICE) and Wireshark on each of its modalities, just in case you might need them.

The next in this series will be on Transfer Syntax (such as compression) incompatibility issues. 

Additional information can be found in the DICOM textbook, or you can sign up for our on-line or face-to-face PACS and/or DICOM training classes.

PACS troubleshooting tips and tricks series (part1): Network transmission.

Over many years of PACS consulting and training thousands of healthcare IT professionals, I think I have heard just about every issue they experience. This series lists the most common issues, how to diagnose them and what tools to use to resolve them.

Network transmission - The PACS components (workstations, archive, database, worklist manager, routers, VNA) talk among themselves and the digital acquisition modalities use the DICOM protocol to exchange images and related information. The DICOM protocol uses the TCP/IP communication protocol for a reliable information exchange. Reliable implies that it automatically adds a check digit, or cyclic redundancy check (CRC) to each packet transmitted, which is used to make sure that packets are delivered without any data loss or corruption.

The software will automatically retransmit a packet, in case it is corrupted, up to a certain number of times. The transmission and acknowledgement of these packets is asynchronous, which means that there could be several packets in the pipeline before an acknowledgement is expected. In many cases, the sender might be faster than the receiver, which means that the buffer at the receiver can get full, and the “window” of the sender is down to “0” for sending additional packets. This is part of the “sliding window” part of the TCP/IP protocol.

Issues related to network transmission include slow network performance, image transfers and subsequent retrievals taking a long time, and TCP/IP network time-out messages.

The causes could be:

·        Poor network components - In one particular case the wall connectors were sub-par (they purchased them from the now defunct Radio Shack store) causing a lot of retransmissions. After replacing them with high quality components, the problem was solved.

·        Slow network segments - A teleradiology system in Alaska was dealing with a lot of time-outs, not realizing that the link between the main hub in the village back to Anchorage uses a satellite connection with a considerable delay. We had to adjust the TCP/IP sliding window size at the network which solved the issue.

·        Someone “hogging” the network - At a small clinic with a limited WAN capacity, I found that the medical records department was streaming video using pretty much all of the bandwidth, causing a considerable delay for images to get through. Better IT policies took care of this. Note that a virus or malware can have the same effect.

·        Duplex settings - I also have seen issues with the duplex auto-negotiation, but unless if you have very old devices (and they are still around), these seem to be pretty much gone. This will manifest itself with very slow transmission and can easily be resolved with changing the setting at the router.

·        Application software issues - Even though it is technically speaking not a network issue, application software also could contribute to transmission performance issues. I have seen cases where a PACS application would literally take seconds (sometimes up to 10 or 20 seconds) to respond to a DICOM command. Note that DICOM implementations almost all are implemented in a “synchronous” mode, meaning that a sender will wait for a reply on a DICOM command before it will follow up with, for example, sending the next image in a series. Therefore, a delay in responding to a DICOM transaction will directly impact the transmission performance.

How to troubleshoot these types of issues?
Looking at log files will help, TCP/IP errors will typically be listed, however, a much better tool is the Wireshark network sniffer with a DICOM “plug-in,” which means that it will list the DICOM protocol sequences, so you can easily see how much time it takes between, for example, sending a DICOM command and its reply. In illustration 1 you can see the time it took for a simple DICOM “Echo”, i.e. 0.147517 seconds.

Network issues are somewhat tricky to troubleshoot, but with tools such as Wireshark the problem will become obvious. Note that if your IT department does not allow you to connect to Wireshark, they almost certainly have their own sniffers running at their routers and you can request the .cap file, which is a standard format for capture files, which you can upload it into your Wireshark and look at the DICOM commands.

For additional resources, see the “how to use Wireshark video,” the DICOM textbook (also in ebook version), or attend our PACS SA training class where we spend a lot of time troubleshooting and learning the details about using Wireshark.

Look for the next “troubleshooting tip” in this series on Addressing.

PACS System Administrator: only for “geeky” Techs?

When talking with an administrator about the best qualifications for people to support the PACS

systems in radiology, he told me that he had his best experience with hiring “geeky” techs, meaning RT’s that have a knack for computers. I tend to agree with him. It would be hard to teach someone with only an IT background the ins and outs of image quality, how to map procedure codes and series descriptions to hanging protocols, and deal with issues in workflow.

At the same time, a “geeky” tech who is not afraid of computers, can take additional training and learn quickly and get the required skills to get by. As a matter of fact, in our PACS training, students with an RT background have been the largest group represented. There has been a lot of discussion on whether a PACS system administrator (SA) should have a clinical or IT background, and the consensus seems to be that either one can do a good job, with each bringing specific expertise to the table. I would argue that the best approach is to have a team with different skills, assuming you can afford more than one PACS SA to start with.

Regardless of the background, for those professionals considering a career change, here is what a “typical” PACS SA does on a day-to-day basis:

·     Data Integrity (“fix-ups”)

Data integrity refers to the information that is typically stored in the so-called “image header.” When the information is correct, an image properly shows the corresponding patient demographics on the viewing system and allows for unambiguous storage and retrieval. When this fails to happen, and one or more elements are missing - usually some part of the patient information, it results in what most users refer to as a “broken” or “unverified” study.  A broken study is when an image or set of images is not properly identified. Broken studies must be resolved or placed in a temporary folder or holding area. It is the SA’s job to implement a process to handle broken studies, and manage problems associated with them. In many institutions, this activity is done by the technologists as it is often caused by them incorrectly entering or matching studies, so the PACS SA typically only deals with complicated cases.

·     Project Management

Comprehensive coordination of a new PACS or upgrade installation is a big undertaking. Understanding the workflow directly impacts successful project management. Creating a map of information flow, and thoroughly understanding the interaction, as well as information storage and retrieval will help define system placement, configuration, routing, testing, and maintenance. Mapping should commence with collecting the patient information, going through the examination process, and ending with image viewing, storage, and diagnostic report generation.

Post-installation management includes software upgrades, adding new modalities, workstations, interfaces, or users to the system. Successful management of these jobs involves anticipating cause and effect relationships. For example, if a software upgrade is scheduled at noon on Sunday, will all users be trained on the new features within an acceptable timeframe?

·     Training

Training is important for the smooth daily operations and management of a PACS system. SA’s will work with vendors to train users on new releases and upgrades, as well as develop materials and curricula for the staff. They will create “cheat-sheets” to replace often bulky and unreadable manuals or on-line help. A vendor will typically “train a trainer,” which is most cases the PACS SA.

·     Support

Support follows training. Hardware and software issues, operator questions and errors, system bugs or failures, and emergency situations all require hands-on, immediate support. The SA must be available “on-call” in the event of a support need. Most support activities fall under the job description category of system maintenance; be prepared to have to be available 24/7 and get compensated for it.

·     Managing Software and Hardware Configurations

Documenting and physically mapping the system prevents potential compatibility issues whenever making a change to the system i.e. adding a new CT or upgrading ultrasound software.  Recording new installations and upgrades of software releases goes hand-in-hand with this process. It’s important to know which devices run with which software for future upgrade purposes. Lastly, hardware configuration, and changes should be documented as well.

·     Configuration Control Board

The PACS system typically interfaces with a Radiology Information System (RIS), Voice Recognition System (VR), the Electronic Health Record system (EMR) and acquisition modalities. As such, it is important that the people managing these systems and devices communicate regularly. These groups of people make up a “configuration control board,” and are responsible for planning events that will collectively affect their system(s), or device(s). They discuss the potential impact of any new addition or change to their system (or device), and how it may result in a functionality issue with another system (or device).

·     Preventive Maintenance

Preventive maintenance drastically reduces problems and issues with the PACS system. Several components comprise preventive maintenance and can be managed with a simple checklist. Monitoring image quality among modalities, workstations, and printers; checking unresolved study queues; making sure the network is up and running; and checking critical processes such as the database, are functions commonly found on a preventive maintenance checklist.

·     General System Maintenance

This task can be described as cataloguing users, and assigning them appropriate security access. It goes hand-in-hand with the Health Insurance Portability and Accountability Act (HIPAA), which deals with patient privacy and security. Hospital employees are provided with varying degrees of access based upon their authorization level, which depends on the role in the healthcare process.

·     Modality Acceptance Testing

This activity is performed with every new piece of equipment that is added to the system. The best way to execute acceptance testing is to maintain a “shadow system” that reflects the same characteristics as the main PACS system and is basically a “mini” or test PACS. Having a fully duplicated system with reduced storage capability is critical.

·     Image Quality

Proper acquisition of an image is the first step in achieving good image quality. The skill level of an RT, whether they over- or under-expose a patient, impacts how the image appears. The patient, unbeknownst to them, also affects image quality.  Movement during an exam can contribute to “fuzziness” of an image. It is critical to be able to identify whether a “noisy” image represents a bone, tissue or organ with disease, or whether it is due to a quality issue. In this specific example, a noisy image could very well be caused by under-exposing a patient, or an image processing error. When troubleshooting an image quality issue, a PACS SA must consider all of these factors.

·     Image communication

Digital images can be transferred from a hospital to a doctor’s home or from a clinic to the main hospital using compression. Common types of compression include lossy, in which the image may lose some of it’s detail, and lossless which maintains the integrity of the image. Managing image quality through this process is important, and if a problem occurs, it needs to be determined whether it lies with the compression, or the image acquisition. The ability to determine the root of the problem is essential for a PACS SA.

·     Manage Off-line storage

Short-, mid- and long-term storage solutions, e.g. to archive images that are a few months old for immediate access, or for up to more than e.g. seven years old for access within minutes, are an essential part of the PACS system. In case an institution decides to have certain studies off-line, or in the cloud, the SA typically “mounts” the specific media on a reader or makes sure the images can be fetched from the remote storage depending on whether the images have to be used as comparison for a new study.

The challenging work of a PACS System Administrator has numerous and varied tasks. A PACS SA is often someone with interdisciplinary skills, the ability to multi-task, be a forward thinker, and handle crisis management well. It requires clinical, technical, training and people skills, and can be a fun and challenging job for those who are up to it.

Do I need to File a 510(k) for my PACS?

Over the past several months many of our clients have asked us questions about whether their future products need a 510(k). Initially, PACS devices were generally treated as accessories to the imaging modalities with which they were used. For example, medical image digitizers, image viewing workstation or medical image printer were considered by FDA to be accessories to stationary x-ray, MRI or CT systems. However, with the significant expansion in the functionality of medical image management products, FDA realized that the identification of many of these products as accessories to specific radiological imaging modalities was no longer appropriate.

This realization led FDA to publish the “Guidance for the Submission of Pre-market Notifications for Medical Image Management Devices” in July 2000. This guidance is applicable to medical devices that provide functions related to the management of medical images after acquisition, of which PACS (as defined by the FDA), is only one of five classifications. By the way, the guidance does not address image-processing devices that utilize artificial intelligence (AI) or other techniques to identify abnormalities in medical images or assist in diagnosis. AI is currently being addressed under the FDA Guidance; Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data - Premarket Notification [510(k)] Submissions Document issued on: July 3, 2012.(more on that in a later blog post).

The “Classifications for Medical Image Management Devices” are;

1)     Medical Image Storage Device (892.2010) - is a device that provides electronic storage and retrieval functions for medical images. Examples include devices employing magnetic and optical discs, magnetic tape, and digital memory. This device type is Class I and exempt from 510(k) requirements. 

2)     Medical Image Communications Device (892.2020) - is a device that provides electronic transfer of medical image data between medical devices. It may include physical communications medium, modems, interfaces, and communications protocols. This device is also Class I and exempt from 510(k) requirements.

3)     Medical Image Digitizer (892.2030) - is a device intended to convert an analog medical image into a digital format. Examples include systems employing video frame grabbers, and scanners that use lasers or charge-coupled devices. This is a Class II device and a 510(k) must be submitted to FDA.

4)     Medical Image Hardcopy Device (892.2040) - produces a visible printed record of a medical image and associated identification information. Examples include multiformat cameras and laser printers. These are Class II devices and a 510(k) must be submitted to FDA.

5)     Picture Archiving and Communications System (892.2050) - provide one or more capabilities relating to the acceptance, transfer, display, storage, and digital processing of medical images. Its hardware components may include workstations, digitizers, communications devices, computers, video monitors, magnetic, optical disk, or other digital data storage devices, and hardcopy devices. Software components may provide functions for performing operations related to image manipulation, enhancement, compression, or quantification. This is a Class II device and a 510(k) must be submitted to FDA.

Classifications 892.2010 and 892.2020 are intended to include all medical image management devices whose principal functions are communications or storage. Classification 892.2050 is intended to cover devices that have not been included in the other Medical Image Management device classifications (i.e. 892.2010-2040).

The confusion regarding the applicability of 892.2050 has occurred because the term "PACS" has commonly been used by industry to refer to all types of medical image management devices. However, the FDA classification in 892.2050 is not intended to include products whose principal function is only medical image communications and/or storage. These devices are classified Class I under 892.2010 and 892.2020.

In many cases it is not clear cut if a device should be classified as a Medical Image Communications Device, a Medical Image Storage Device, or as a Picture Archiving and Communications System. In these cases, the classification is determined by reviewing the additional functions performed by the product. Simple manipulations that do not alter the image data, such as window and level, pan and zoom, and image annotation are considered to be within the scope of the communications and storage functions and no 510(k) is required. A typical image viewing workstation falls within this classification. However, image-processing functions, which are intended to alter the image data (e.g. filtering, multiplanar reconstruction, and 3D reconstruction), are considered to be outside the scope of the storage and communications functions and fall into the PACS classification where a 510(k) must be submitted.  Also, complex quantitative functions (e.g. measurements, arterial stenosis evaluation, ventricular volume calculations, and calcium scoring) are not considered to be communications and storage functions and these types of functions are treated as PACS, requiring a 510(k).

Hopefully, I have reduced some of the confusion but if you have any questions or need assistance for product classification and/or FDA clearance, don’t hesitate to contact us.

Also, there is a comprehensive white paper available with more details, references, and which provides a decision chart for you to decide on what action to take.

The author of this article is Carl Alletto, OTech Senior regulatory consultant. OTech filed more than 100 PACS related 510(k)'s for both US and international based companies, see list here.

PACS System Administrator: only for “geeky” Techs?

When talking with an administrator about the best qualifications for people to support the PACS

systems in radiology, he told me that he had his best experience with hiring “geeky” techs, meaning RT’s that have a knack for computers. I tend to agree with him. It would be hard to teach someone with only an IT background the ins and outs of image quality, how to map procedure codes and series descriptions to hanging protocols, and deal with issues in workflow.

At the same time, a “geeky” tech who is not afraid of computers, can take additional training and learn quickly and get the required skills to get by. As a matter of fact, in our PACS training, students with an RT background have been the largest group represented. There has been a lot of discussion on whether a PACS system administrator (SA) should have a clinical or IT background, and the consensus seems to be that either one can do a good job, with each bringing specific expertise to the table. I would argue that the best approach is to have a team with different skills, assuming you can afford more than one PACS SA to start with.

Regardless of the background, for those professionals considering a career change, here is what a “typical” PACS SA does on a day-to-day basis:

·     Data Integrity (“fix-ups”)

Data integrity refers to the information that is typically stored in the so-called “image header.” When the information is correct, an image properly shows the corresponding patient demographics on the viewing system and allows for unambiguous storage and retrieval. When this fails to happen, and one or more elements are missing - usually some part of the patient information, it results in what most users refer to as a “broken” or “unverified” study.  A broken study is when an image or set of images is not properly identified. Broken studies must be resolved or placed in a temporary folder or holding area. It is the SA’s job to implement a process to handle broken studies, and manage problems associated with them. In many institutions, this activity is done by the technologists as it is often caused by them incorrectly entering or matching studies, so the PACS SA typically only deals with complicated cases.

·     Project Management

Comprehensive coordination of a new PACS or upgrade installation is a big undertaking. Understanding the workflow directly impacts successful project management. Creating a map of information flow, and thoroughly understanding the interaction, as well as information storage and retrieval will help define system placement, configuration, routing, testing, and maintenance. Mapping should commence with collecting the patient information, going through the examination process, and ending with image viewing, storage, and diagnostic report generation.

Post-installation management includes software upgrades, adding new modalities, workstations, interfaces, or users to the system. Successful management of these jobs involves anticipating cause and effect relationships. For example, if a software upgrade is scheduled at noon on Sunday, will all users be trained on the new features within an acceptable timeframe?

·     Training

Training is important for the smooth daily operations and management of a PACS system. SA’s will work with vendors to train users on new releases and upgrades, as well as develop materials and curricula for the staff. They will create “cheat-sheets” to replace often bulky and unreadable manuals or on-line help. A vendor will typically “train a trainer,” which is most cases the PACS SA.

·     Support

Support follows training. Hardware and software issues, operator questions and errors, system bugs or failures, and emergency situations all require hands-on, immediate support. The SA must be available “on-call” in the event of a support need. Most support activities fall under the job description category of system maintenance; be prepared to have to be available 24/7 and get compensated for it.

·     Managing Software and Hardware Configurations

Documenting and physically mapping the system prevents potential compatibility issues whenever making a change to the system i.e. adding a new CT or upgrading ultrasound software.  Recording new installations and upgrades of software releases goes hand-in-hand with this process. It’s important to know which devices run with which software for future upgrade purposes. Lastly, hardware configuration, and changes should be documented as well.

·     Configuration Control Board

The PACS system typically interfaces with a Radiology Information System (RIS), Voice Recognition System (VR), the Electronic Health Record system (EMR) and acquisition modalities. As such, it is important that the people managing these systems and devices communicate regularly. These groups of people make up a “configuration control board,” and are responsible for planning events that will collectively affect their system(s), or device(s). They discuss the potential impact of any new addition or change to their system (or device), and how it may result in a functionality issue with another system (or device).

·     Preventive Maintenance

Preventive maintenance drastically reduces problems and issues with the PACS system. Several components comprise preventive maintenance and can be managed with a simple checklist. Monitoring image quality among modalities, workstations, and printers; checking unresolved study queues; making sure the network is up and running; and checking critical processes such as the database, are functions commonly found on a preventive maintenance checklist.

·     General System Maintenance

This task can be described as cataloguing users, and assigning them appropriate security access. It goes hand-in-hand with the Health Insurance Portability and Accountability Act (HIPAA), which deals with patient privacy and security. Hospital employees are provided with varying degrees of access based upon their authorization level, which depends on the role in the healthcare process.

·     Modality Acceptance Testing

This activity is performed with every new piece of equipment that is added to the system. The best way to execute acceptance testing is to maintain a “shadow system” that reflects the same characteristics as the main PACS system and is basically a “mini” or test PACS. Having a fully duplicated system with reduced storage capability is critical.

·     Image Quality

Proper acquisition of an image is the first step in achieving good image quality. The skill level of an RT, whether they over- or under-expose a patient, impacts how the image appears. The patient, unbeknownst to them, also affects image quality.  Movement during an exam can contribute to “fuzziness” of an image. It is critical to be able to identify whether a “noisy” image represents a bone, tissue or organ with disease, or whether it is due to a quality issue. In this specific example, a noisy image could very well be caused by under-exposing a patient, or an image processing error. When troubleshooting an image quality issue, a PACS SA must consider all of these factors.

·     Image communication

Digital images can be transferred from a hospital to a doctor’s home or from a clinic to the main hospital using compression. Common types of compression include lossy, in which the image may lose some of it’s detail, and lossless which maintains the integrity of the image. Managing image quality through this process is important, and if a problem occurs, it needs to be determined whether it lies with the compression, or the image acquisition. The ability to determine the root of the problem is essential for a PACS SA.

·     Manage Off-line storage

Short-, mid- and long-term storage solutions, e.g. to archive images that are a few months old for immediate access, or for up to more than e.g. seven years old for access within minutes, are an essential part of the PACS system. In case an institution decides to have certain studies off-line, or in the cloud, the SA typically “mounts” the specific media on a reader or makes sure the images can be fetched from the remote storage depending on whether the images have to be used as comparison for a new study.

The challenging work of a PACS System Administrator has numerous and varied tasks. A PACS SA is often someone with interdisciplinary skills, the ability to multi-task, be a forward thinker, and handle crisis management well. It requires clinical, technical, training and people skills, and can be a fun and challenging job for those who are up to it.