First proton therapy overdose reported

Rinecker Proton Therapy Center (RPTC), Munich, Germany

Overdose reported to patient treated last summer.

Press reports indicate the prostate cancer patient after 15 daily treatments mistakenly received a daily dose of 63Gy instead of 3Gy!

The patient has severe problems (blood in the urine) and cannot sit

Incident was blamed on “human error” and two employees were fired.

Additional software installed to prevent this problem from happening again.

http://sdradiotherapy.com/uploads/Patient_Safety_and__Radiation_Accidents_revised_Mar_2013.pdf

The Munich's problem was the only of such kind of human error that I have heard till now.

@ Mushtaq Ahmad  The publication on the the first proton therapy overdose [and many other incidents] is impressive and very recognizable.

In nuclear medicine we mainly perform diagnosis and in most of europe and certainly in The Netherlands we typically use lower doses of radiopharmaceuticals than in for example the United States. But the remarks about the chain of errors is so recognizable. And especially when a comercial party and software is involved, it is really difficult to have them admit and change software stupidities.

Once things are 'FDA approved' or otherwise officially endorsed, companies often [I have seen this several times] first start with denial because of fear for claims, for litigation. This response causes delays, sometimes serius delays in solving the rootcause [in equipment of software]. Because diagnostic nuclear medicine is not "as lethal"as radiotherapy, the leverage we have to enforce companies to fix issues is less.

What is needed is a culture AND legislation AND culture which also offers commercial entities the benefit of blameless reporting [and fixing] provided the commercial entities involved are forthcoming and fast in their response [notifying other users immediately and fixing issues really rapidly]. In other words: a fast and responsible response is rewarded with protection against litigation. If this approach is adopted, one more thing must be resolved: society as a whole must accept paying the damages [but certainly not if there was no early and forthcoming response]. This can be arranged in most western countries through legislation details on the coverage of mandatory medical insurance.

One can expect "less victims" on average [through earlier notification and solving the errors] , so society should not see this as a cost to the tax-payer, but simply as a direct consequence of imlpementing "blame-free" resolving of such issues all throught the entire chain.

I can describe 2 historic examples, where errors in the software were not fixed and a lot of extra effort in other steps had to be taken, to prevent serious mishaps. In this forum I will not mention names of companies involved, as currently no safe public reporting system exists and commercial parties DO INFLUENCE government bodies when financial issues arise.

The follow 2 examples touch on radiotherapy and both can result in very serious errors.

Example -1- In the 'early days' of PET [not PET/CT we had to manually fuse PET reconstructions with diagnostic CT's. In those days the quality of these images was so poor that the issue of brown fat activation was not recognised.

The viewing software showed 3 dimensional coordinates when browsing through the axial, coronal and sagital series of images.

This information was displayed in a redundant manner: In the GUI both 3 coordinates [slice numbers] were shown and on the images of the individual slices for each projection the slice number was also shown.

In those days it was convenient to communicate "hot spots" of FDG uptake using coordinates, as the PET images showed little anatomical detail.

To our surprise, the software seemingly randomly occasionally did not synchronise the slice numbers on the slices with the displayed 3D-coordinate, leaving us to guess which was correct.

As radiotherapy decisions were based on this communication, it is fully conceivable that radiotherapy fields were adjusted based on false information.

At some point we learned about the fenomenum of brown fat activation [thanks to improved cameras and the availability of PET/CT's]. In this early phase it is conceivable that wrong coordinates have resulted in irradiation of activated brown fat or not extending a radiation therapy field to include certain nodes, as a result of the problems with the reporting of the coordinates.

I have inspected the code, to find out that at least two software teams had been working on it and that both teams kept the details of the 3D-cursor coordinates in separate variables. So the most likely cause was that one or the other team did not aways update the pointer that was used by the other team.

Once I discovered the problem and could reproduce it, it took 48 hours to diagnose it. Then I handed down all my findings to the company and asked for swift action.  It took the company 9 months to fix it. The initial 4 months a lot of communication was spent on discussiing the seriousness. Experts [no named doctors] said that the problem was not serious enough and [despite potential consequences for radiotherapy decisions] conceiled threaths about litigation were given if I would go public. At one point I actually had to threaten them to go to the european authorities and formally request withdrawal of CE approval. [This is obviously the short version of the story].

Example 2

- doctors are kept away from the configuration of  a electronic medical filing system [EPD]  radiological information system [RIS] and a radiopharmacy management system [RMS] and lay people actually do the configuration .

When patients are referred to undergo radioiodine treatment, they are to be scheduled for an intake, a scan and the therapy. The request is stent from the EPD to the RIS. By phone the details of the appointments are to be worked out by a secretary. Despite the fact that the doctors many times explicitly and repeated demanded that therapy appointments would not automatically be scheduled in advance and that in case of a therapy no automatic request from the RIS to the RMS be sent for a therapeutic dose, the followin happened. No patient was harmed because the error was discovered at a later stage, but months have passed with the software companies staggering fixing these configuraiotn errors. There the safety attitude is non existant. "doctors are a nuisance and always asking for more than wat they pay for .... "

One order for treatment of a patient with Graves disease was scheduled by an inexperienced sectretary. She was not authorized so but did also schedule therapy and activated all [instead of only one therapy option] options. this resulted in 4 appointments for therapy on 3 different days involving 3 different doses. 4 requests for these doses were actually sent to the RMS.

Normally we manually screen automated requests for radiopharmaceuticals the day before these are actually required. Because of other problems we looked 'ahead' and noted that 4 doses for the same patient were requested. One dose was very high [for cancer patients who already underwent thyreoidectomy]. If this latter dose would have been given to the Graves patient, it would have been lethal unless total thyereoidectomy would have been performed within hours.

It takes a lot of effort to convince people that such medical 'administrative' software in the safety chain is a very serious risk and that software builders in this particular field of software engineering have to learn from the start that their code becomes part of a complex safety system and that the physicists and physicians AND NOT THE HOSPITAL ADMINISTRATION should be the guiding authorities.

These days we see many efforts to streamline healthcare to save money. What we see is that we are forced  into using administrative and logistic software that is by far not on par with the other software [from the viewpoint of safety].

At our site we have completely forbidden automatic scheduling or scheduling by a secretary of therapy plans.

We cannot disable automatic dose requestst from RIS to RMS, but instead have set these doses to 0.

My main recommendation is: keep administrative people out of the safety chain. Forbid that these gain authority over any part of the safety chain or are allowed to specify or configue such software.

Current ICT efforts to increase efficiency in healthcare delivery, when interfering with safety relevant software / tool-chains do pose a very serious risk to patients.

No accident has actually happend, no near miss has occurred.

 But the simple fact that in this example, the simple request for the intake of a patient resulted in multiple appointments for therapy and for automated ordering of multiple potentially lethal doses of radioiodine  from the radiopharmacy should be seen as a very serious warming.

All 3 vendors of the 3 software packages were really hard to motivate to fix their application [usually configuration].  ["we make a note, for the next release ....", "without a signature for the costs, we cannot accept this change .....", "next year in the user meeting, we will assign this issue a priority and depending upon the priority given, it may take 2 to 5 years .....".

In large segments of medical ICT industry there is a lot of window dressing but no actual safety culture. This is a serious problem [I know of more examples].

Note: patients with Graves disease can have a very high uptake [even over 90%]  of radioiodine in their thyroid gland. The effective half life of radioiodine in Graves equals the physical halve life. Cancer patients in The Netherlands sometimes get 7.4 GBq as a single dose.

So unless massive necrosis of the thyroid results in sufficiently fast release of the radioiodine in case of such massive overdose, a dose of 7.4 GBq is certain to result in a lethal dose to the bone marrow. [and yhis is a form of radiotherapy too]

Both examples have never been published yet and before doing so I do need serious advice, not only on the legal matters.

We talk about the safety chain in radiotherapy, but only rarely is the impact of the diagnostic traject included. In the first example I think it is obvious, but in the second example a small diagnostic traject  comes between intake and therapy.

Thank you.

There is a simular accident in 2011 at CAL in Nice reported by ASN

http://www.asn.fr/Controler/Actualites-du-controle/Avis-d-incidents-affectant-un-patient-en-radiotherapie/Erreur-de-fractionnement-dans-un-traitement-par-protontherapie