PARCA has offered certification for PACS System Administrators (SAs) since early 2005, resulting in hundreds of professionals being certified under its program. When certification activity began, there was the expectation that at some point in time, formal certification might become a requirement to be a PACS SA. It appears as though Texas may become the first state that will make PACS SA certification a legal requirement. The state senate has a bill pending (SB 1193) requiring certification for anyone who services or supports medical devices.
PACS is defined by the FDA as a Class II medical device and would therefore be covered by the legislation. This is the intent of the proposed law, as stated in the bill:
Class II and class III medical devices, such as infusion pumps, replacement heart valves, and implanted cerebella stimulators are used in hospitals and ambulatory surgery centers throughout the state. Currently, there are no certification requirements for individuals who repair and calibrate these devices. Given the critical nature of certain medical devices, patient safety may be compromised when these devices are serviced or repaired by unqualified individuals. While most facilities hire only certified biomedical technicians, there are individuals who represent themselves as capable of servicing these devices who have not received the proper training. C.S.S.B. 1193 amends current law relating to the maintenance and service of certain medical devices in health care facilities and provides a criminal penalty.
As is typical, law makers grasp the impact of hardware failures (infusion pumps, etc.) on patient care, yet do not seem to comprehend the impact of software failures and/or lack of maintenance. Software issues could result in an image to be unavailable for diagnosis, displayed on an un-calibrated monitor, or presented in an improper manner impacting diagnosis; essentially all the issues that a certified PACS SA has been trained to mitigate. However, although not called out specifically in the proposed legislation, the FDA has defined PACS as a medical device and it would be covered as such under the bill. Also of note is that non-compliance with the proposed law, if enacted, would be a criminal act.
What would be the impact on the PACS SA profession? If you have not looked into certification, this might be the right time to do it, particularly if you live in Texas. If this bill passes, I would not be surprised if other states follow suit. Be aware that it will take time to study and prepare for PACS SA certification: most professionals take about 3-9 months to study for certification. Of course, this timeframe can be compressed by taking some of the classes offered by institutions such as OTech.
The bill has not yet passed, but seems to have the support of a majority of legislators. If you work in Texas on Class 2 medical devices, now is the time to write or call your state senator to see where they stand on this legislation.
Friday, May 1, 2009
Is VNA in your DNA?
The more I read about Vendor Neutral Archive (VNA) solutions the more I become convinced that there is mass confusion about the subject. It is almost as bad as the "meaningful use" definitions that are going to decide whether or not an EMR will qualify for future certification.
I believe there is an opportunity for the IHE to deliver clear definitions of VNA actor and transaction behaviors. In addition, the interface between a VNA image database and archive needs to be clearly defined.
Also, despite several attempts, a VNA standard for internal archiving format has yet to be determined. This means that several vendors store data in a proprietary format, which is the antithesis of vendor neutral.
Here's some of my key requirements for a VNA:
I believe there is an opportunity for the IHE to deliver clear definitions of VNA actor and transaction behaviors. In addition, the interface between a VNA image database and archive needs to be clearly defined.
Also, despite several attempts, a VNA standard for internal archiving format has yet to be determined. This means that several vendors store data in a proprietary format, which is the antithesis of vendor neutral.
Here's some of my key requirements for a VNA:
- It must be patient-centric. This means that all the information about a particular patient should be available, not just data from radiology, or cardiology, or whatever.
- It should be truly multimedia, covering not only images but waveforms, reports, structured reports with measurements, voice files, and MPEG's for the video captures from endoscopes and laparoscopes.
- There should be no place for proprietary data formats.
- Synchronization between multiple institutions should be possible using IHE standards for patient queries, and the reconciliation of multiple patient ID’s is a critical part of this.
Digital Modality Integration, Part 3 of 3
Part three 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.
What are some of the DICOM tools a PACS system administrator (SA) should have deployed in their network? One of the most important DICOM tools is a monitoring tool. A monitoring tool, what I call the "heartbeat" application, should be the centerpiece in your PACS. Basically, every minute or couple of minutes, the program sends and receives a DICOM verification to every DICOM application entity (AE) on your network. If the system—or a part of it—goes down, this application alerts the PACS administrator so they can take remedial action.
Another tool that is very useful is an active test tool. An active test tool is an application that typically participates in the DICOM communication and takes the place of a modality. Because it simulates a modality, one can use it to uncover—through the application's logging and monitoring capabilities—potential problems before they occur.
Another tool that a PACS SA should have on hand is sniffer. This is a device that can listen in on to all the communication that goes between one device and another. Sniffers allow one to filter communications by IP address or by protocol, such as TCP or DICOM.
If you have ever looked at a sniffer’s output, you have seen there is a lot of communication going on among the different devices on a network. For PACS troubleshooting purposes, you generally don’t need to sniff or capture all that information. Most likely, you are going to be primarily interested in the DICOM protocol activity on the network.
There are two widely available open-source sniffer products available on the Internet: Wireshark and DVTK. You can get the Wireshark product at https:/www.wireshark.org and DVTK can be downloaded from https:/www.dvtk.org. Either of these applications, when connected to a switch, will allow you to capture all communications among devices and a PACS.
Typical sniffer output allows you to look at three main communication elements: the raw hexadecimal bit data, the protocol associated to it and its communication from point to point. If there are any issues, problems or questions about device connection a sniffer is the tool to use to uncover any errors. The nice thing about sniffers is that they are totally non-intrusive, which means that they don’t participate in the communication. This tool is also very useful in cases of intermittent errors or problems.
Five things to remember
What are some of the DICOM tools a PACS system administrator (SA) should have deployed in their network? One of the most important DICOM tools is a monitoring tool. A monitoring tool, what I call the "heartbeat" application, should be the centerpiece in your PACS. Basically, every minute or couple of minutes, the program sends and receives a DICOM verification to every DICOM application entity (AE) on your network. If the system—or a part of it—goes down, this application alerts the PACS administrator so they can take remedial action.
Another tool that is very useful is an active test tool. An active test tool is an application that typically participates in the DICOM communication and takes the place of a modality. Because it simulates a modality, one can use it to uncover—through the application's logging and monitoring capabilities—potential problems before they occur.
Another tool that a PACS SA should have on hand is sniffer. This is a device that can listen in on to all the communication that goes between one device and another. Sniffers allow one to filter communications by IP address or by protocol, such as TCP or DICOM.
If you have ever looked at a sniffer’s output, you have seen there is a lot of communication going on among the different devices on a network. For PACS troubleshooting purposes, you generally don’t need to sniff or capture all that information. Most likely, you are going to be primarily interested in the DICOM protocol activity on the network.
There are two widely available open-source sniffer products available on the Internet: Wireshark and DVTK. You can get the Wireshark product at https:/www.wireshark.org and DVTK can be downloaded from https:/www.dvtk.org. Either of these applications, when connected to a switch, will allow you to capture all communications among devices and a PACS.
Typical sniffer output allows you to look at three main communication elements: the raw hexadecimal bit data, the protocol associated to it and its communication from point to point. If there are any issues, problems or questions about device connection a sniffer is the tool to use to uncover any errors. The nice thing about sniffers is that they are totally non-intrusive, which means that they don’t participate in the communication. This tool is also very useful in cases of intermittent errors or problems.
Five things to remember
- Don’t schedule any new installations on Fridays. When you connect the device, it will always take you a couple of days to configure it properly. Even if it takes one day you want to have some buffer space, because if it doesn’t work you may not have access to the proper support personnel over the weekend.
- Don’t let your service engineer go until every function and feature of the new device has been tested and validated. Use a sign off sheet and make sure that everything is checked off--including the proper functioning of hanging protocols. Make sure that all the proper software is installed on the device, including any applications needed for monitoring and virus protection.
- Do your homework up front. Review conformance statements and get involved with modality integration. You cannot expect that the biomedical or clinical engineering staff will take care of this. You must validate that the device will function properly with your PACS prior to its installation in the production environment.
- Make sure you have the proper tools. You cannot rely on the service engineers to have them. Make sure you have a sniffer available so that if any problems arise, especially after the service engineer has left, you can do your own investigation and troubleshooting.
- Make sure you have a test environment. You want to have a test archive as well as testing tools and a test viewer. These are all free, open-source, public-domain tools you can download and use. Get familiar with these tools prior to an installation. If you encounter a problem during deployment, you will need to have mastery of these tools.
Subscribe to:
Posts (Atom)