Many institutions are about to upgrade or replace their PACS, and in many cases this will be done with a product from a different vendor. Many of these institutions are in for a rude awakening--the images and related information in their archives will have to be migrated to meet their new vendor's data formats. This process can be expensive; for the best case scenario, the cost will be as much as half a million dollars and will take months to accomplish.
This sad truth of data "portability" has created a burgeoning market in data migration, companies who are expert in the various image encodings and formatting. Some of the image related information such as overlays, measurements, key images, and notes may even have been stored in a proprietary manner in the image header or database and will be lost when migrating the data to the new archive. The worst case scenarios will cost more and take longer.
It is amazing that many vendors still “mess” with the data integrity of the information trusted to their archive. During our training class in Asia, I had one user tell me that his nuclear medicine images could not be processed after they were archived by the PACS and subsequently retrieved back at the modalities. Another user shared their frustration that a vendor’s workstation could not reformat CT images--also after they were archived and retrieved.
These types of problems are forcing users to come up with their own solutions to mitigate the issues caused by proprietary archive formats. Many believe that the best answer is the “vendor-neutral” archive.
The most common implementation is to use an archive solution, often from a different vendor, that interfaces with the PACS front-end using open standards. Initial attempts are somewhat encouraging; however, many have found that there is much more happening between a PACS archive and front-end (database-image manager and workflow manager) than they were aware was going on. Also, PACS vendors are somewhat hesitant to let go of that part of their system. But many institutions, especially those who want to share an archive between multiple institutions with different PACS products, are pushing for this type of solution.
I believe that the vendor-neutral archive is the right way to go. I expect that there will be some resistance from established PACS vendors to let others enter their turf, and there will be integration issues. However, PACS archives must be able to be easily replaced and be able to be upgraded separately from other PACS components. As such, the clear trend is toward commoditization of this PACS domain. Users must have management and control of their data, and they should not be expected to jump through data and dollar hoops to move this data each time a new PACS vendor is selected.
Saturday, August 1, 2009
DICOM Structured Reporting, Part 2 of 2
Part two of a two-part series on DICOM structured reporting. 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.
Perhaps the biggest issue for DICOM structured reporting is support—from the creation of the report at the modality to its display on the PACS workstation. I've gotten quite a few calls from users with concerns that their DICOM structured reports are not able to be communicated over their PACS.
The first step in addressing this issue is that the PACS must be able to accept different DICOM objects. A DICOM object, as you might know, is represented by an SOP class. So what we need to look for is support for SOP classes, so that the PACS archive can handle them.
The next issue is the support of the diagnostic workstations. When a workstation retrieves a structured report, say from an ultrasound modality, the report must be properly supported so that it can be properly displayed.
Last, but not least, the reporting software must also support DICOM structured reports. A voice recognition system has to be able to support structured report information so it can automatically populate the appropriate sections of the diagnostic report.
The DICOM conformance statement is what the system administrator will use to ascertain if their PACS vendor provides DICOM structured report support. The DICOM conformance statement typically has a table in the first or the second page that displays what SOP classes are supported by the PACS. Once you’ve determined whether or not the PACS supports DICOM structured reports, you will need to check the DICOM conformance statements for the diagnostic workstation and your reporting application.
The next component that you need to look for is details about the content of the structured report. In some cases, certain institutions have specific requirements of what needs to be in the structured report. Depending on what these requirements are, this will require that certain information must be in the image header.
So what do we need to look for? We need to look at the details of what is in the header, what is in the contents, and what information is in the structured report. First check the SOP class report. Second, check the contents in the templates in the structured report.
There are three different SOP classes when it comes to structured reports. The SOP classes are divided among basic, enhanced, and comprehensive text. Most modalities support the comprehensive-text SOP. The reason being is that the comprehensive-text SOP doesn’t have any limitations as to the information it can contain. So, with regards to the SOP classes, you need to make sure that you support exactly the same structured report type on each device.
When you look at a conformance statement of a DICOM structured report, after you make sure that the SOP classes match, the next thing you want to look for is the template identification. The templates are very important because they can be modified. A template is almost like a definition of a DICOM header within a structured format, but basically has the contents of the report.
You need to check these templates because some of the information you require in your practice might not be there. You can go to the DICOM conformance statement and find out what exactly is filled in.
DICOM structured reports are not rocket science. They are just like any DICOM objects and can be handled like DICOM images. Although they are currently used mostly by ultrasound systems, computer-aided detection (CAD) applications for digital mammography (and other modalities, such as CT) are using them, too.
The biggest challenge to more widespread adoption of DICOM structured reporting is the support of PACS products. Unfortunately, PACS archives and workstations are lagging in this regard, as are voice recognition systems.
In summary, you need to make sure to do two things: You need to look at the DICOM conformance statements for support for these SOP classes; and you want to make sure that the template information in these structured reports is appropriate and meets the requirements of your institution. In many cases the templates are configurable, so you can go back to your vendor and configure them accordingly.
Structured reports represent major improvement for capturing some of the data from some modalities that can help radiologists be more efficient and effective—and can reduce errors and improve the quality of patient care. You just need to make sure that you have properly prepared your imaging information infrastructure.
Perhaps the biggest issue for DICOM structured reporting is support—from the creation of the report at the modality to its display on the PACS workstation. I've gotten quite a few calls from users with concerns that their DICOM structured reports are not able to be communicated over their PACS.
The first step in addressing this issue is that the PACS must be able to accept different DICOM objects. A DICOM object, as you might know, is represented by an SOP class. So what we need to look for is support for SOP classes, so that the PACS archive can handle them.
The next issue is the support of the diagnostic workstations. When a workstation retrieves a structured report, say from an ultrasound modality, the report must be properly supported so that it can be properly displayed.
Last, but not least, the reporting software must also support DICOM structured reports. A voice recognition system has to be able to support structured report information so it can automatically populate the appropriate sections of the diagnostic report.
The DICOM conformance statement is what the system administrator will use to ascertain if their PACS vendor provides DICOM structured report support. The DICOM conformance statement typically has a table in the first or the second page that displays what SOP classes are supported by the PACS. Once you’ve determined whether or not the PACS supports DICOM structured reports, you will need to check the DICOM conformance statements for the diagnostic workstation and your reporting application.
The next component that you need to look for is details about the content of the structured report. In some cases, certain institutions have specific requirements of what needs to be in the structured report. Depending on what these requirements are, this will require that certain information must be in the image header.
So what do we need to look for? We need to look at the details of what is in the header, what is in the contents, and what information is in the structured report. First check the SOP class report. Second, check the contents in the templates in the structured report.
There are three different SOP classes when it comes to structured reports. The SOP classes are divided among basic, enhanced, and comprehensive text. Most modalities support the comprehensive-text SOP. The reason being is that the comprehensive-text SOP doesn’t have any limitations as to the information it can contain. So, with regards to the SOP classes, you need to make sure that you support exactly the same structured report type on each device.
When you look at a conformance statement of a DICOM structured report, after you make sure that the SOP classes match, the next thing you want to look for is the template identification. The templates are very important because they can be modified. A template is almost like a definition of a DICOM header within a structured format, but basically has the contents of the report.
You need to check these templates because some of the information you require in your practice might not be there. You can go to the DICOM conformance statement and find out what exactly is filled in.
DICOM structured reports are not rocket science. They are just like any DICOM objects and can be handled like DICOM images. Although they are currently used mostly by ultrasound systems, computer-aided detection (CAD) applications for digital mammography (and other modalities, such as CT) are using them, too.
The biggest challenge to more widespread adoption of DICOM structured reporting is the support of PACS products. Unfortunately, PACS archives and workstations are lagging in this regard, as are voice recognition systems.
In summary, you need to make sure to do two things: You need to look at the DICOM conformance statements for support for these SOP classes; and you want to make sure that the template information in these structured reports is appropriate and meets the requirements of your institution. In many cases the templates are configurable, so you can go back to your vendor and configure them accordingly.
Structured reports represent major improvement for capturing some of the data from some modalities that can help radiologists be more efficient and effective—and can reduce errors and improve the quality of patient care. You just need to make sure that you have properly prepared your imaging information infrastructure.
Subscribe to:
Posts (Atom)