A team of Rotarians and I just came back from our annual trip to Nicaragua--where we build clinics, schools, and deliver medical supplies. The state of medical care in much of the developing world can be eye opening. In the rural area where we work, the local hospital has an X-ray unit which is 40 years old, and had a portable unit that belongs in a museum, rather than in a medical facility.
One might not realize how fortunate we are to have access to basic medical care. The World Health Organization estimates that two-third of the world's population does not have access to even rudimentary radiological services.
In the developing world, there is a need for about 80,000 X-ray units. One of the major stumbling blocks is the cost of film and processing chemistry, as the price of these supplies might be the equivalent of a day's wage (or more)--assuming that they can be transported to some of the more remote areas.
Digital technology, such as CR and DR, which has been widely available since the late 90’s, eliminates the need for film and chemicals; enables consultation through teleradiology; allows electronic archiving, retrieval, and image and patient management; and delivers immediate results that can be distributed directly to physician offices. In environments where film and chemicals are expensive, have a designated shelf life, and are in irregular supply, digital technology has obvious advantages.
In addition, where there are virtually no radiologists and physicians are scarce, remote consultation is greatly needed. Clinical management requires review of individual patient records and can be assisted remotely through telecommunication assets as well as service, administrative support, troubleshooting, education, and training. The nature of digital image technology and the related information associated with its use provides a wealth of information that can be evaluated and used to improve care management.
It seems an obvious solution that implementing digital health imaging technologies in the developing world can make a major impact. However, there are many aspects and support issues involved in implementing these technologies that are taken for granted in the developed world. Air conditioning for a server room (or in many clinics) is a luxury in much of the developing world. Clean, reliable power can be an issue, as well as Internet connectivity.
Helping people meet these challenges is a very rewarding and humbling experience. If you are interested in getting involved with any of these projects, do not hesitate to contact me.
Thursday, April 1, 2010
Top Ten PACS Connectivity Issues, Part 2 of 2
Part two of a two-part mini-series on troubleshooting PACS interoperability and connectivity issues.
This article is a continuation of last month's column, where I explored five of the ten most common PACS connectivity issues. 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. The following are the remaining five of the top ten most common PACS connectivity and interoperability issues that I've compiled:
6.) Transfer Syntax Support
In addition to missing SOP Class support (such as not supporting Structured Reports from an ultrasound or a new enhanced MRI object containing spectroscopy data), a PACS might not support the specific encoding from the modality (for example, transfer syntaxes such as wavelet compression). In addition, a PACS might mishandle a Big Endian encoding from an older modality, a JPEG, or may not support compression schemes such as Run Length Encoding (RLE). There are a number of installed PACS that do not (yet) support the MPEG files created by endoscopy and surgery exams. Upgrading your PACS or downgrading the modality is the only solution.
7.) Unique Identifiers (UIDs)
Some devices create illegal UIDs. Some UID creation algorithms will deliver empty values or subcomponents with leading zero's, which are invalid. Most PACS will either refuse these images or quarantine them. Some modalities issue a new UID when an image is resent, which requires someone to delete these duplicates in the PACS. Some modalities re-use a UID, which will also require the time of a PACS System Administrator to fix. There are no easy solutions for these problems, aside from holding your PACS vendor accountable for fixing their software.
8.) Modality Worklist (MWL)
A Worklist provided by a RIS, PACS or Broker should match the studies to be performed at a modality, no more and no less. Some MWL providers provide too much data (such as all of the exams for all the modalities, or all of the CR exams instead of only the ones for the ER), some provide not enough differentiation (only the bone-scans), and some provide not enough. Remedies for these issues are reconfiguring the MWL provider, adding an interface engine, or by changing the input data from the scheduling department.
9.) Burned-in Data
Many ultrasound units and frame-grabber interfaces have the unfortunate side-effect of capturing all the information on a screen, including the patient demographics. This can create major issues when the patient demographic is incorrect, which can happen when a technologist forgets to select a new patient or makes an incorrect selection. Many users put "X's" over the incorrect text. This creates a serious risk that a receiving application might not support these overlays, presentation states, or proprietary annotations. The only solution is to use “paintbrush” utilities.
10.) Loss of Annotations
Many PACS still utilize proprietary solutions to store annotations. When displayed on a PACS workstations from the same vendor they appear; however, when displayed on another vendor’s workstation (such as one used by a referring physician, a nighthawk service, or via a third-party Web server) they will not be displayed. The solution is to generate compatible overlays (some modalities and workstations have this option) or upgrade all of your devices to support the DICOM Softcopy Presentation State.
Most of these issues can be made visible or simulated using the appropriate tools for troubleshooting, such asWireshark, OT-DICE, OT-Heartbeat. If you'd like to learn more about PACS troubleshooting, please visit our new hubto view our Webcast on this topic.
This article is a continuation of last month's column, where I explored five of the ten most common PACS connectivity issues. 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. The following are the remaining five of the top ten most common PACS connectivity and interoperability issues that I've compiled:
6.) Transfer Syntax Support
In addition to missing SOP Class support (such as not supporting Structured Reports from an ultrasound or a new enhanced MRI object containing spectroscopy data), a PACS might not support the specific encoding from the modality (for example, transfer syntaxes such as wavelet compression). In addition, a PACS might mishandle a Big Endian encoding from an older modality, a JPEG, or may not support compression schemes such as Run Length Encoding (RLE). There are a number of installed PACS that do not (yet) support the MPEG files created by endoscopy and surgery exams. Upgrading your PACS or downgrading the modality is the only solution.
7.) Unique Identifiers (UIDs)
Some devices create illegal UIDs. Some UID creation algorithms will deliver empty values or subcomponents with leading zero's, which are invalid. Most PACS will either refuse these images or quarantine them. Some modalities issue a new UID when an image is resent, which requires someone to delete these duplicates in the PACS. Some modalities re-use a UID, which will also require the time of a PACS System Administrator to fix. There are no easy solutions for these problems, aside from holding your PACS vendor accountable for fixing their software.
8.) Modality Worklist (MWL)
A Worklist provided by a RIS, PACS or Broker should match the studies to be performed at a modality, no more and no less. Some MWL providers provide too much data (such as all of the exams for all the modalities, or all of the CR exams instead of only the ones for the ER), some provide not enough differentiation (only the bone-scans), and some provide not enough. Remedies for these issues are reconfiguring the MWL provider, adding an interface engine, or by changing the input data from the scheduling department.
9.) Burned-in Data
Many ultrasound units and frame-grabber interfaces have the unfortunate side-effect of capturing all the information on a screen, including the patient demographics. This can create major issues when the patient demographic is incorrect, which can happen when a technologist forgets to select a new patient or makes an incorrect selection. Many users put "X's" over the incorrect text. This creates a serious risk that a receiving application might not support these overlays, presentation states, or proprietary annotations. The only solution is to use “paintbrush” utilities.
10.) Loss of Annotations
Many PACS still utilize proprietary solutions to store annotations. When displayed on a PACS workstations from the same vendor they appear; however, when displayed on another vendor’s workstation (such as one used by a referring physician, a nighthawk service, or via a third-party Web server) they will not be displayed. The solution is to generate compatible overlays (some modalities and workstations have this option) or upgrade all of your devices to support the DICOM Softcopy Presentation State.
Most of these issues can be made visible or simulated using the appropriate tools for troubleshooting, such asWireshark, OT-DICE, OT-Heartbeat. If you'd like to learn more about PACS troubleshooting, please visit our new hubto view our Webcast on this topic.
Subscribe to:
Posts (Atom)