Sunday, March 1, 2009

The Next Frontier of Digital Imaging

I recently had the privilege to listen to a presentation by members of the World Health Imaging Alliance (WHIA), a non-profit organization with a charter to deploy digital imaging technologies in developing countries. They noted that two-thirds of the world's population does not have access to basic radiology services, something those of us in the developed world often take for granted. 

The WHIA shared that the state of the radiology systems deployed in developing countries is deplorable—an estimated 30 percent of all radiology equipment there is not functioning. In addition, even if the equipment is properly maintained, there is often no money available to pay for the consumables (film and chemicals). The cost of these items is the equivalent—or more—of an average day’s pay, and there can be tremendous logistical hurdles to bring the supplies to remote areas. Imagine having to regularly transport film and chemistry to a remote village in a jungle, or over a steep mountain path in the Andes. 

The advantage of deploying digital imaging technologies in developing countries is obvious. A simple CR or low-cost DR system would be a great solution. Combine this with a battery-operated WHIS-RAD device—an X-ray unit with stepped mAs, kVp and fixed source-to-film distance specially created for developing countries—and it is possible to deploy a complete system, including a computer for QA and two diagnostic viewing stations, for less than $100,000 (U.S.). 

However, there are many challenges to the use of these systems in remote areas that involve logistics, training, maintenance and on-going support. That is why the WHIA, in cooperation with the Rotary International, has embarked on an exciting project to deploy a pair of pilot sites utilizing this technology configuration. The first one is being deployed in South Africa and the second one will be set up in Guatemala this summer. 

It will be interesting to track the progress of these projects. Often, solutions deployed in the developing world are modified for use in developed countries—proving that less can be more. Maybe it is time that we start simplifying and consider that more is not always better. There is a large market for simple devices and in many cases it requires starting from scratch. That is what Tata accomplished in India with its development of a $2,000 car. 

Who knows, the next generation CR or DR device may well be created in a country such as India. Perhaps it is time for the established medical device manufacturers to start developing simplified versions of their devices, too; or risk going down the same route as the U.S. auto industry. 

Digital Modality Integration, Part 1 of 3

Part one of a three-part series on digital modality integration. The information found in this article can be used as part of a preparation program for the American Board of Imaging Informatics (ABII) Imaging Informatics Professional Certification Program, which awards the Certified Imaging Informatics Professional (CIIP) designation.
What are the DICOM aspects of the modality integration? The first thing we need to consider is configuration. We also want to validate before we connect, as one of the major issues is often improper transfer syntaxes. Lastly, in part 3, we will talk about some of the tools that one can use to be properly prepared and if there is a problem, to try to troubleshoot those. 

This three-part series covers section B of the clinical engineering section of the CIIP test content outline and can be used to prepare for your CIIP certification. 

First, let's talk a little bit about background. One of the issues for a PACS administrator is that the modality integration is typically done by the vendor. A service engineer knocks on the door, shows up with the device, let’s say it’s an ultrasound, and wants to connect it to your PACS. 

In many cases, the biomedical engineering or clinical engineering department is the main contact because they typically take care of modality integration. The problem is that the PACS administrator is often involved after the fact—more than likely a week after the it has been sited and they have to integrate it, which potentially could cause some issues. 

Proper preparation, as well as acceptance testing, is the key to successful integration of digital modalities into your PACS. 

Find out when new modalities are going to be connected, because the ultimate responsibility for the data integrity and the proper functioning of the PACS is with the PACS administrator. 

So, given this background, how can we prepare? First of all we need to make sure that we have the proper addressing for the new system. Addressing means IP address, AE title, and port numbers for both the source and its destinations. 

IP addresses are typically issued by the IT department. Make sure that you have a fixed IP address. If you run DHCP or another directory service in your network, make sure you have a permanent lease on the address, so that you have a virtual permanent IP address. 

Configuring the correct AE title should not be underestimated. This is something that a PACS administrator needs to manage. If you don’t have a unique AE title you put yourself up for trouble, because some of the DICOM protocol, such as moving images from one to another location, rely on unique AE titles. 

Port numbers is another area that is kind of troublesome. Some of the older devices require fixed port numbers. There is a well-known port number, 104, which should not be used, if you can avoid it. The best thing is to use the new assigned port number, which is 11112. This is the officially approved port number for DICOM applications. So if you have flexibility in assigning the port numbers, tell your service engineers to use the 11112 number for the DICOM port assignments. 

Assuming we have the addressing taken care of, you want to make sure that you review conformance statement. Almost every vendor has their conformance statement online. It’s a little bit tricky though, because conformance statements coincide with a particular software version. I came across a case where a conformance statement was provided by a sales person and was not the proper version of the device that was going to be installed. Make sure that when you look at the conformance statement that is reflects the software version of the device that is going to be installed. 

There are sometimes significant differences between different versions of DICOM software implementations. For example, there could be support for different attributes in the header, different attributes in your work list, or even complete new SOP classes that were not provided before, such as modality performed procedure step (MPPS) or storage commitment (STC). You might want to review your conformance statement in order to find the proper configuration parameter. 

An often overlooked configuration parameter is protocol data unit (PDU) size. PDU is the application-level block size that is negotiated between a device that proposes the association and the device that accepts it. So, if you have a new ultrasound system that needs to be connected to the PACS, it might propose 10k block sizes at the application level. The PACS might offer 100k block sizes. It would be a shame to not configure the ultrasound PDU for 100k if your PACS allows it. 

Another important component would be the number of simultaneous associations. Imagine you have a workstation that is used as a QA station. It will probably only need to connect to 2 or 3 devices. However, it might be configured to accept 6 or 7 or 8 simultaneous associations, which would be wasting several associations that require buffer allocation, meaning memory space that would never be used. You want to be able to configure the number of simultaneous associations for any system in your PACS. 

You want to find out what SOP classes are supported. Some devices allow you to configure the proper SOP class. This becomes more important as more modalities come up with new, enhanced versions of the image SOP classes. One thing you might have run into with CR devices is SOP support for not only CR, but also DX. In many cases, this is configurable. New CT and MRI units also are coming out with an enhanced CT and MRI. In many cases this is configurable. 

You need to find out what storage SOP classes are supported and how to configure them based on the capabilities of the PACS and any other systems down line, such as a Web server. It does not do you any good if you have the enhanced CT storage SOP class viewable at your PACS workstation, but not viewable on your EMR system or through your Web viewer. You also want to find out are there any of the information management SOP classes supported, such as MPPS or STC. 

An important section of the conformance statement is also the support of the various attributes, particularly those in the image header. Find out how the hanging protocols are configured at your PACS workstation and what attributes it is looking for. Is it a series description? Is it the body part? Is it the patient orientation? 

All this information can be found in the DICOM header specification of your modalities. If there are any discrepancies, you can change the hanging protocol definitions or at least anticipate other issues.