Wednesday, April 1, 2009

Digital Modality Integration, Part 2 of 3

Part two 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.
An important part of the configuration and preparation deals with making sure that the RIS or PACS broker, which provides the modality work list, is configured correctly. Imagine that you already have an MRI installed, but now you want to install a dental system. A dental system with a modality IO needs to be configured properly with regard to your modality work list. 

Now how does this work list work? The work list provides demographic information, such as patient name, ID, birth date, sex, ordering information--such as the type of study to be performed--and scheduling information. All this information in the modality work list has a source or input with the proper HL7 commands. 

So if you need to filter on room number, or modality type, that information needs to be available in the modality work list to allow filtering to be taking place, so there needs to be mapping. You will need to work with your IT department to ensure that the proper scheduling information, ordering information, and demographics can be filtered and can be provided as part of the work list for any new modality. 

Another important part of the preparation is to request a CD of all image types and order information for the modality from the vendor before the system is installed. 

Some modalities create key images. Key images are images that are identified as being a key to a particular series. The proper way of doing this is to create a separate DICOM object. The separate DICOM object has a little bit of text information and the pointer to the key images of a particular study. These objects should be tested, to ensure that they are supported by the PACS and properly identified. 

Other objects could be presentation state objects, which contain different presentations. In cardiology, and particularly for ultrasound, more and more units are going to create structured reports. A structured report can be looked at as a template for standard measurement information. DICOM structured reports are relatively common for some of the new high-end ultrasound units. You want to make sure that these are properly supported on your PACS. Can they be archived? Can they be retrieved? And can they be viewed? 

So assuming you get all these different image types, key images, presentation states, and structured reports on a CD, what do you do with the CD? Well the first step would be to validate them. You would run a validator tool, which is a commonly available open-source application, and run it against the CD, making sure that there are no issues. The next step would be to check your PACS with the CD to ensure that your hanging protocols are working properly. It is a critical part of the acceptance testing to get these CDs so you can do the testing before a vendor delivers their modality. 

The way to properly validate images is by using a tool called DVTK, DICOM validation tool kit. It's available in the public domain. This tool will make sure that every attribute; every data element that is supposed to be available in the header is indeed available and is present. If there are any violations or any potential issues, it will give either warnings or errors. This is an invaluable tool that allows one to prepare for any potential configuration issues. 

A second important component of the preparation will be to work with your network administrators that take care of the switches and the switch settings. You want to make sure that the device matches the setting at the switch. If you have one switch set at fixed half duplex and the other one is auto-negotiate or fixed full duplex, your performance will suffer. The virtual LAN (VLAN) configuration will also need to be adjusted to incorporate the new device and for service access to it. 

One needs to make sure that when the vendor dials in that only this particular device can be accessed. So the VLAN has to be appropriately configured for external access as well as for every device that internally needs to talk with it. In many cases there are security settings that will also need to be modified. 

Modality Validation
How do we validate a new modality? 

What you might want to do is use what we call simulators. It is not too hard to configure a database simulator. Many PACS have a test system or a test environment. This would be basically the same as the regular PACS environment, but with a test database. The test database could also connect to a test viewer. 

In addition, you may want to have a modality work list simulator that simulates particular orders. Only after the modality is properly tested against a test database, test modality work list provider and a test viewer, should you consider testing it in the production environment. 

Now let’s talk a little bit about transfer syntax. The DICOM protocol works as follows: a device proposes a series of what we call presentation contexts to another device. A presentation context can be looked upon as a shopping list. After there is a handshake from the other device about these presentation contexts, then the actual communications takes place. There are two components in the presentation context. 

The first component is what a device wants to communicate. We call that abstract syntax. The abstract syntax would specify what to do with a particular object, which is a combination of the service and the object itself. 

The presentation context would contain the abstract syntax, such as "I want to exchange CT images" or “I want to use the main modality work list.” So it is always a combination of the service, let’s say store or print, and the appropriate object, for example a CT. If there is any incompatibility at this point, we will not be able to make the connection. There will not be a handshake. 

What are some examples of where it might breakdown? Well imagine you have a new dental unit. The dental unit creates objects that are defined as IO, inter-oral object, inter-oral x-rays. As soon as the device starts to talk with the PACS, it will try to do a handshake and negotiate the IO SOP class. The PACS might not have that in its configuration list and so will not be able to complete the handshake. 

And this goes back to what I said before. You have to review the DICOM conformance statement of any new device being added onto a PACS in order to prevent these kinds of issues. So always look at the SOP class that has to be supported, because it’s part of the presentation context that is proposed by any device that wants to communicate. 

In addition, there could be multiple presentation contexts with the different IDs within a single association in a single connection. For example an ultrasound device might negotiate single frame as well as CINE multi frame ultrasounds in a single association. 

Now let’s go to the transfer syntax. The transfer syntax deals with the encoding of the information. This is the second component of the presentation context. 

What are some of the different transfer syntaxes? One of the most common is the regular transfer syntax, which would include uncompressed implicit VR, little Endian, or explicit VR little Endian. 

Some devices offer jpeg or wavelet compression. Most cardiology systems like to send their images in a lossless compressed format because the CINE loops that they require are really large. The same thing applies for ultrasound, which also creates CINE loops, so compressed data is very typical for some devices. 

There are also different transfer syntaxes with regards to different byte orders. Think of the byte order as if you would read a word, 16 bits, from left to right, like AB, or you would read from right to left so its BA. 

So either reading from left to right or right to left depends on the internal data representation of the data in the computers. There is the Intel and the Motorola Byte order, little Endian or big Endian. 

With transfer syntaxes, most of the time you see incompatibility with compression; for example, the device might receive compressed image and the PACS may need to forward it to a workstation that does not support compression. In most cases, you will want to configure your PACS to meet all the capabilities of the overall system. 

1 comment: