The Third International PACS and Teleradiology Symposium held earlier this month in Singapore was a big success. It was clear that there is a great need for education and training in the Asia Pacific region as users are trying to implement digital imaging and vendors are working to support their efforts.
There are basically two markets for PACS in this area: the first caters to the middle and upper class in these regions as well as the support of medical tourism. This is a growing business in the region, where foreigners from the Middle East, China, and even as far as the U.S. travel to the area to have medical procedures performed. For example, a $40,000 hip replacement might cost less than $10,000 here. This market is very well served by the same products and manufacturers as you see in the U.S. and Europe.
The second market is the public sector, which needs affordable equipment, often capable of sending images to a referral or for second opinion. These types of systems are often served by local vendors as western vendors do not seem to be able or willing to address this market segment. An analogy can be drawn with the car manufacturing industry whereby it takes an Indian company such as TATA to come up with a $2,000 vehicle (the NANO) to address this segment.
The need for further education and support became clear to me through several comments and questions from the audience during a DICOM workshop. For example, one radiologist asked me whether a PACS should be able to support color images. He was told by his vendor (one of the big three) that his Doppler Ultrasound only could be displayed in grayscale on his million dollar PACS.
Another user asked me what the limitation was in data migration. Her vendor told her that when she migrated her data, it has to be "all or nothing," which meant that even though many of the images were past the legal retention time (five years, in this case), they have to be migrated.
Yet another user asked my advice about repeating HL7 orders being sent from their scheduling system which messes up their worklist. I told her to work with their IT department and look at the logs, to which she responded that her organization does not have an in-house IT department.
It rapidly became clear to me that many institutions are on their own when it comes to the support of advanced digital imaging systems. That was also probably the reason I had so many radiologists in the DICOM workshop, a group I rarely encounter when teaching in the U.S. or Europe. These medical professionals have to be a jack-of-all trades in their departments; and they want to make sure they understand the underlying technology so they can challenge their vendors when problem occur.
I was frankly surprised by the poor level of support that these customers receive, even though the major vendors have development centers in Bangalore, India, which could easily be used to support the region. I heard far too many stories of systems being down due to a lack of response and a slow escalation of problems to service centers in the U.S. and Europe.
How can we help to empower these users whose health IT goals are as aggressive as those of their colleagues in the rest of the world? Training, education and accompanying certification is an obvious first step. In addition, manufacturers need to educate their sales and service support staff, because the half-hearted solutions that they are currently offering do not help to create momentum for digital imaging solutions.
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.
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.
Subscribe to:
Posts (Atom)