As a frequent flyer with more than 2 million miles in my account, I often find myself sitting alongside fellow road warriors. On my past two trips, I was seated beside EHR consultants that were implementing systems in different parts of the U.S. They shared that the demand for EHRs was so great that they were struggling to manage the workload.
Conversations such as this with fellow IT professionals lead me to believe that institutions are finally biting the bullet and getting onto the EHR bandwagon. In addition, I've heard that more facilities are adding cross-enterprise interconnectivity requirements to their RFP's, mostly in the form of support for the cross-enterprise document sharing (XDS) profile for their PACS and EHR systems. As reported in last month's column, industry has embraced this effort with more than 50 percent of the participants at the 2010 IHE Connectathon testing their compliance with the profile.
One big question remains: Are we ready? Do all physicians have the proper infrastructure to access EHR's and PHR’s? Do they have the training to use these systems? Are they aware of the scope of what is required for a successful implementation? Are their systems properly configured for archiving and backup? Lastly, is security in place to safeguard patient data?
As EHRs proliferate, so does the risk for misuse and unauthorized access. I would be the last person to argue that this should be a reason to slow down the roll-out of these systems; however, I would be the first to argue that we have an enormous basic IT and EHR training requirement that has to be met.
The other big question is whether or not the systems being installed have the proper interfaces to communicate with one another? It is fine for them to be CCHIT compliant, so we have some idea about the provided functionality; however, what about certifying them against an interconnectivity and interoperability specification? If we don't insist on this basic requirement, we'll only end up with more systems that don’t talk with one another, something we want to avoid.
For example, we have two major healthcare providers in the Dallas metropolitan area, both of which are implementing their own EHR. Not surprisingly, if I go the ER in the hospital immediately to the north of where I live they won’t be able to access the information from the hospital on the south side of my town. An interoperability requirement is desperately needed.
How will the next few years develop in regard to EMR/EHR implementations? I predict a many new issues will arise, there will be some spectacular failures, and a lot of money will be spent unnecessarily due to inadequate training and a lack of standard requirements. There will be a lot of consultants very busy for many years to come, and I'm sure I’ll be hearing some interesting stories while I'm up in the air.
Monday, March 1, 2010
Top Ten PACS Connectivity Issues, Part 1 of 2
Part one of a two-part mini-series on troubleshooting PACS interoperability and connectivity issues.
When teaching our PACS/DICOM classes, I always take note of the most common interoperability issues brought up by our students. When I visit a healthcare facility, I do the same thing. I like to know what issues are happening on the street, so I can share the challenges and solutions with our students—and with the readers of our newsletter. For professionals who are upgrading their PACS, it is important to be able to recognize interoperability issues and take appropriate action.
PACS components are not plug-and-play. System additions such as a new modality or a software upgrade often create problems which can cause disruptions, decrease functionality, or possibly even impact patient care. Many of these issues could have been avoided or minimized by a more thorough validation by vendors, or by rigorous acceptance testing and verification by hospitals.
The following are five of the top ten PACS connectivity and interoperability issues that I've compiled:
1.) Network Issues
A well defined and managed network infrastructure is essential.
Dynamic IP addressing is fine as long as the router does not re-assign these addresses to another machine (which is common when a router is re-booted or replaced). Another problem that seems to occur frequently is the incorrect setting of the switch—generally when a switch is set to half duplex or mismatches the device setting, especially when auto-negotiating is configured. Switch issues result in major performance issues and can only be made visible when using a network sniffer.
The use of NetScan-type utilities to detect IP addressing issues is an essential tool to diagnose these problems.
2.) DICOM Header Issues
The DICOM image header is generated through mapping RIS data, generation by a modality, and manual input by a user. Any of these sources can potentially generate incorrect or invalid data in the image header. Unfortunately, problems are not always immediately detected.
For example, an incorrectly identified study might be archived in the PACS and get "lost", only to appear when the data is migrated, which could be years later. A header with an Institution ID exceeding the maximum field length might be stored by vendor “A” and then rejected by vendor “B” as an invalid image when it is migrated.
Keeping tight tabs on this data and validating images using appropriate tools is important.
3.) Hanging Protocol Issues
Hanging protocols not working is almost always related to incorrect header information or the wrong interpretation of header information.
A common mismatch is related to the way CR and DR systems organize their images into series. Some create a new series for each view (for example, a PA and LAT chest), while some group them together in a single series.
Another frequent issue occurs when some modalities automatically modify series and study descriptions and do not take the values from the Worklist, which causes a description mismatch with hanging protocol configurations at the view station.
Sometimes, additional QA steps are required, in addition to technologist training on the vagaries of different vendors' systems.
4.) CD Import Issues
These problems almost always can be traced back to non-compliance with the DICOM standard or the corresponding IHE profile.
Problems that have been reported most frequently are the absence of DICOM image files because a vendor is providing only a proprietary format, a missing directory file, mismatch of the meta-file header with the actual data content, and incorrect transfer syntaxes such as compression, among others.
In many cases, one can convert the images to an acceptable format that can be imported using additional tools; however, in some cases it is impossible to read the proprietary information, which often leads to a repeat exam.
5.) SOP Class Support
Modalities are eager to support new functionality, represented by the use of new SOP Classes as they contain more information and allow for better viewing and processing. The most common mismatches are due to non-support of the PACS for the enhanced CT and MRI SOP Classes and Structured Reports, such as generated by CAD devices and ultrasound units for measurements. In most cases, a modality can be “defeatured” to fall back to an older SOP Class, or alternate encoding (for example, burning the CAD marks into a secondary capture). In some cases, one will be stuck with the proprietary information (such as in MR spectroscopy).
Look for the remaining five of the top ten PACS connectivity and interoperability issues in next month's newsletter. In the meantime, please email me with your comments and suggestions, or your top ten list, so it can be shared with others.
Lastly, a note regarding the use of appropriate tools for troubleshooting: I am convinced that all the top ten PACS connectivity and interoperability issues can be uncovered with the right tools and utilities. If you are not that familiar with these tools and utilities, I strongly recommend you get familiar with them. You should download the open-sourceWireshark sniffer, get familiar with modality simulators such as OT-DICE, and use appropriate monitoring tools, such as OT-Heartbeat. If your schedule does not permit the time for self-study, or you prefer a more structured learning environment, consider a comprehensive training class that will provide you with hands-on training on how to use these tools to troubleshoot and tune your PACS.
Our mini-series on PACS Connectivity will conclude in the April newsletter with issues 6-10. For further information about PACS troubleshooting, please visit us at www.otechimg.com.
When teaching our PACS/DICOM classes, I always take note of the most common interoperability issues brought up by our students. When I visit a healthcare facility, I do the same thing. I like to know what issues are happening on the street, so I can share the challenges and solutions with our students—and with the readers of our newsletter. For professionals who are upgrading their PACS, it is important to be able to recognize interoperability issues and take appropriate action.
PACS components are not plug-and-play. System additions such as a new modality or a software upgrade often create problems which can cause disruptions, decrease functionality, or possibly even impact patient care. Many of these issues could have been avoided or minimized by a more thorough validation by vendors, or by rigorous acceptance testing and verification by hospitals.
The following are five of the top ten PACS connectivity and interoperability issues that I've compiled:
1.) Network Issues
A well defined and managed network infrastructure is essential.
Dynamic IP addressing is fine as long as the router does not re-assign these addresses to another machine (which is common when a router is re-booted or replaced). Another problem that seems to occur frequently is the incorrect setting of the switch—generally when a switch is set to half duplex or mismatches the device setting, especially when auto-negotiating is configured. Switch issues result in major performance issues and can only be made visible when using a network sniffer.
The use of NetScan-type utilities to detect IP addressing issues is an essential tool to diagnose these problems.
2.) DICOM Header Issues
The DICOM image header is generated through mapping RIS data, generation by a modality, and manual input by a user. Any of these sources can potentially generate incorrect or invalid data in the image header. Unfortunately, problems are not always immediately detected.
For example, an incorrectly identified study might be archived in the PACS and get "lost", only to appear when the data is migrated, which could be years later. A header with an Institution ID exceeding the maximum field length might be stored by vendor “A” and then rejected by vendor “B” as an invalid image when it is migrated.
Keeping tight tabs on this data and validating images using appropriate tools is important.
3.) Hanging Protocol Issues
Hanging protocols not working is almost always related to incorrect header information or the wrong interpretation of header information.
A common mismatch is related to the way CR and DR systems organize their images into series. Some create a new series for each view (for example, a PA and LAT chest), while some group them together in a single series.
Another frequent issue occurs when some modalities automatically modify series and study descriptions and do not take the values from the Worklist, which causes a description mismatch with hanging protocol configurations at the view station.
Sometimes, additional QA steps are required, in addition to technologist training on the vagaries of different vendors' systems.
4.) CD Import Issues
These problems almost always can be traced back to non-compliance with the DICOM standard or the corresponding IHE profile.
Problems that have been reported most frequently are the absence of DICOM image files because a vendor is providing only a proprietary format, a missing directory file, mismatch of the meta-file header with the actual data content, and incorrect transfer syntaxes such as compression, among others.
In many cases, one can convert the images to an acceptable format that can be imported using additional tools; however, in some cases it is impossible to read the proprietary information, which often leads to a repeat exam.
5.) SOP Class Support
Modalities are eager to support new functionality, represented by the use of new SOP Classes as they contain more information and allow for better viewing and processing. The most common mismatches are due to non-support of the PACS for the enhanced CT and MRI SOP Classes and Structured Reports, such as generated by CAD devices and ultrasound units for measurements. In most cases, a modality can be “defeatured” to fall back to an older SOP Class, or alternate encoding (for example, burning the CAD marks into a secondary capture). In some cases, one will be stuck with the proprietary information (such as in MR spectroscopy).
Look for the remaining five of the top ten PACS connectivity and interoperability issues in next month's newsletter. In the meantime, please email me with your comments and suggestions, or your top ten list, so it can be shared with others.
Lastly, a note regarding the use of appropriate tools for troubleshooting: I am convinced that all the top ten PACS connectivity and interoperability issues can be uncovered with the right tools and utilities. If you are not that familiar with these tools and utilities, I strongly recommend you get familiar with them. You should download the open-sourceWireshark sniffer, get familiar with modality simulators such as OT-DICE, and use appropriate monitoring tools, such as OT-Heartbeat. If your schedule does not permit the time for self-study, or you prefer a more structured learning environment, consider a comprehensive training class that will provide you with hands-on training on how to use these tools to troubleshoot and tune your PACS.
Our mini-series on PACS Connectivity will conclude in the April newsletter with issues 6-10. For further information about PACS troubleshooting, please visit us at www.otechimg.com.
Subscribe to:
Posts (Atom)