By Herman Oosterwijk, for AuntMinnie.com
Reprinted with permission
I have seen this as an expert witness in legal disputes that involve PACS networks. These cases range from vendor disputes (did the PACS work as promised?) to lawsuits brought by the relatives of patients who died supposedly because the PACS did not work.
One interesting case was of a patient in Arizona who died because he had a brain bleed due to trauma to the head; the bleed went unnoticed by a radiologist who claimed the PACS "did not work." Consequently, the blood-thinning medication the patient was prescribed had the wrong effect.
In another case, an elderly lady in Alabama in the intensive care unit (ICU) died because of incorrect tube placement, which was apparently missed on imaging. A man in Washington state committed suicide because his radiation treatment, which was supposed to be delivered to the throat, was delivered to his spine, causing him to become paraplegic.
And in another unusual case, a radiologist in Canada lost his job because his department chair looked at a CT scan showing that the radiologist had a brain tumor and judged him unfit for work.
There are also less dramatic cases. For example, in one, a hospital didn't want to pay for a PACS network it had installed, as the software supposedly did not meet its expectations; in another, a system, in fact, did not meet specifications, and the vendor had to remove the million-dollar PACS and give the money back.
In considering the legal liabilities of PACS, let's focus on these cases and see what one can do to prevent them.
1. Eliminate generic logins and ensure passwords are not shared.
The 80-year-old woman in the ICU in Alabama was on life support, and an x-ray was taken to make sure her nasogastric tube was in the proper position. Issues from incorrect tube placements are not uncommon; a report from the U.K. showed that of 1.7 million tubes supplied in 2013, there were 21 reported deaths and 79 cases of harm. This poor lady died, and her relatives sued the hospital.
When I looked at the audit trails in the PACS detailing hospital staff who had reviewed her case, they showed there were several views of this particular image; however, the users were all identified as "ICU doc," which made it impossible to point to the particular physician who missed the misplacement.
2. Keep your monitor calibration records.
This became critical in the case of the man who died because of the unnoticed brain bleed. When I looked at the head CT images, even with no medical background, it was clear to me that there were several dark regions in the study. The radiologist who reported on the study did not see the finding and claimed that the PACS workstation monitor was not working properly.
The monitor, however, had been checked for calibration just a few months prior to this event and also after the fact, and it did not show any deviation from its calibration, making the radiologist statement unbelievable. As an additional precaution, make sure your calibration records are not lost when you upgrade your PACS software, monitors, or monitor calibration management software.
3. Review your audit trails regularly and make sure you keep them, especially in between system or vendor upgrades.
The case in Canada where a radiologist lost his job because of his medical condition was revealed by others looking at his CT scans (as shown by the audit trails). The department manager claimed that she should be allowed to review all cases (including the ones of her employees) to maintain overall quality and check for correctness.
The radiologist in question, who was put on leave because of his medical condition, eventually died, but at that time he was declared fit to work by his specialist. I am not sure how this case turned out (most cases are settled confidentially), but regardless, the widow of the radiologist wanted to have "justice" and sued the department for several million dollars, as she felt that her late husband was treated incorrectly.
4. Always double check system performance and functionality -- for example, by a medical physicist (never, ever rely on a vendor).
The episode of incorrect radiation treatment that caused a man to commit suicide was caused by a DICOM interface issue between a treatment planning system and a treatment system (linear accelerator). The so-called iso-center was inverted, causing the treatment location to be negative instead of positive with regards to the center.
In this case, the planning system and treatment system were from different manufacturers, but they were supplied by the same vendor as a system integrator. Although these cases are typically settled confidentially, I can imagine that both the vendor and hospital shared the blame, as a medical physicist should have done a comprehensive verification using a phantom.
5. Don't rely on "standard" interfaces such as DICOM and HL7, but rather on IHE.
Another lesson learned from the radiation therapy incident is that DICOM and HL7 do not necessarily guarantee interoperability. The fact that a radiation treatment plan can be exchanged does not mean that it has the correct coordinates. A more reliable step toward interoperability would be to require compliance with Integrating the Healthcare Enterprise (IHE), which defines and tests end-to-end functionality.
6. Don't hesitate to work with the FDA.
If a patient is harmed because of a medical device or medical software malfunction, notify the U.S. Food and Drug Administration (FDA) immediately. It is interesting to read the classic case of the Therac-25 radiation therapy system produced by Atomic Energy of Canada (AECL). The system delivered massive overdoses of radiation in the 1980s because of concurrent programming errors. This event triggered a major regulatory push, resulting in the current FDA rules and monitoring program.
The FDA, if notified, will notify the vendor and make sure that corrective action is taken for all versions of software out there. This will prevent harm to others as well. The reporting applies to any issue that might potentially cause harm, including incorrect patient orientations or views or even patient mix-ups.
7. Write a detailed RFP for your PACS with measurable acceptance criteria.
A large multihospital organization on the West Coast purchased a PACS system, which after one year, even with several software upgrades, still had major functionality issues. What was interesting in this case is that the radiologists didn't think the system was that bad, as they were getting used to its functionality. But they didn't realize that the system's back end had several issues with regard to misidentification, inability to pull prior images, mismatching studies, etc.
The IT and radiology management team called me in to do a comprehensive audit over several days, going back to the requirements spelled out in the original request for proposal (RFP). It became clear that the majority of the requirements were not met. The vendor was forced to pull out the system and reimburse the organization.
8. Always conduct a detailed acceptance test when you have a new system.
This scenario was the opposite of the previous case. I was engaged to do a comprehensive audit at a site in South Carolina as a neutral party, but this time I was contracted by the vendor, as the hospital claimed that the system did not meet its requirements. The audit proved to be in favor of the vendor. This shows that you should make sure you have a detailed acceptance test. Most vendors will supply these, and if they do, make sure you review them.
9. Do your due diligence with a site visit prior to your PACS purchase.
A hospital in Arizona was struggling with its teleradiology PACS, as the system did not meet its expectations. Radiologists were reading from many different hospitals, some with and some without electronic orders, with reports to be faxed back in a timely manner in the case of emergency readings.
There were several problems with integration, and custom software was built to a certain degree until the vendor gave up and told the client that it could not afford to build additional functionality just for this site. The hospital subsequently sued the vendor and wanted its money back. The vendor's insurance company did not want to return multiple millions of dollars, so it pulled me in, together with my IT expert, to do some forensic work to look at all the software installed.
We found that the key issue was unclear specification of what the system was supposed to do (they just placed an order for a "PACS"). The hospital had sent two IT people for a site visit prior to the sale, who were not representative of the end users and did not ask the right questions. Again, I don't know how this was settled, but it was clear that there was no documentation of what the client really wanted; therefore, claiming that the system did not meet expectations seemed incorrect, as the client never told the vendor what was expected.
To summarize, there can be significant legal ramifications of PACS malfunctions, incorrect documentation and specifications, and illegitimate access of the information. Do your due diligence to prevent this and improve not only patient care but also your bottom line and overall satisfaction.
Herman Oosterwijk is a trainer/consultant on PACS, IHE, DICOM, HL7, and FHIR. He can be reached through his website, www.otechimg.com, where you can also find information about upcoming training and online education on these topics.
The comments and observations expressed are those of the author and do not necessarily reflect the opinions of AuntMinnie.com.
Amazing ways to reduce the legal exposure, this is very amazing and valuable information, thanks for sharing...
ReplyDeleteCopper Gluconate USP