インスリン自動注入システム用アプリのバグ、意図せず10倍のインスリンを注入してしまう可能性 27
ストーリー by nagazou
バグ 部門より
バグ 部門より
headless 曰く、
国内では製品が提供されていないようだが、Insulet のインスリン自動注入システム「Omnipod Insulin Delivery System」用の Android アプリにバグがあり、意図しない大量のインスリンが注入される可能性があるそうだ (The Register の記事、 Insulet の米国向け安全情報、 英国向け安全情報)。
このバグはアプリのボーラス計算機で注入量として 1 未満の数値を入力する場合、小数点を最初に入力すると小数点が認識されないというもの。たとえば、「0.3」ユニットを指定しようとして「.3」のように入力すると、実際には「3」となり、意図した量の 10 倍が注入されることになる。そのため Insulet では、1 未満の数値を入力する場合に先頭の「0」を必ず入力することや、確認画面で最終的な数字をよく確認することを推奨している。ただし、このアプリ「Omnipod 5 App」は最新のバージョン 1.2.4 で問題が修正されており、米国向け安全情報にはアプリの更新情報も記載されている。
バージョン (スコア:4, おもしろおかしい)
> 最新のバージョン 1.2.4 で問題が修正されており
実は0.1.2.4なのではないか
Therac-25 過剰照射事故事故みたい (スコア:2)
Therac-25 放射線事故1983年(PDF) [meiji.ac.jp]
通常1回200radまでで600～700radが致死量といわれている。この事故では15000～20000rad照射で死亡したり高度障害が発生がのべ6件発生。
それでＦＤＡソフトウェアガイダンスやら、医療機器用ソフトウェアの開発と保守に関する安全規格「IEC 62304」の認証などでがんじがらめになっていく。
放射線医療用機器 (スコア:1)
開発している知り合いから開発段階のバグで照射時間が設定より長くなるのがあってなーという話を聞いて、人命やお金にからむプログラムには手を出したくないと思った。
ソフトウエアの欠陥による放射線治療機事故 (スコア:1)
運悪く室内ビデオ装置も故障 https://www.shippai.org/fkd/cf/CA0000496.html [shippai.org]
#しぼうはSPAM判定？
Re: (スコア:0)
Therac-25もありますね。
https://gigazine.net/news/20210217-therac-25-incident/ [gigazine.net]
Re: (スコア:0)
#4577786、 #4577790 は
同じものにみえる。
PDP-11アセンブラというのが時代を感じさせるなぁ・・・
いまはこういう機器は何で動いているのだろうか。WindowsでC#あたり???
人間工学 (スコア:1)
> 確認画面で最終的な数字をよく確認することを推奨している
これはあまり意味がない対策。
人は自分の入力は正しいと思っているから確認しても気づかない。
もっとグラフィックやサウンド等を利用して
間違いを検知しやすい表示にしないと効果がでない。
Re:人間工学 (スコア:2)
例えば0.1ずつ増減するボタンなら、十進の数値入力よりもボタンを減らせるし誤動作もしづらいのに。
Re: (スコア:0)
チャッタリングってのがあってだな...
で、+5とかしたい場合に連打する訳でだな...
Re: (スコア:0)
最大値ってのは人によって違うと思うからさ、それをやるには、
多分、通常設定と詳細設定に分けて、
・詳細設定では出力可能最大値を設定する
・通常設定では実際に出力する量を設定する
・通常設定で、出力可能最大値を超えてたら何らかのメッセージを出力する
ってな感じにしないといけない気がする。
自殺目的でインスリンの大量注射後の血糖値の状況 (スコア:1)
インスリンの過剰投与後の症状と対処方法
https://www.jstage.jst.go.jp/article/tonyobyo/58/9/58_675/_pdf/-char/ja [jst.go.jp]
― 675 ―
症例報告 Case Report
自殺企図でインスリンの大量注射後に持続血糖モニタリングにより血糖値の変動を観察しえた2 型糖尿病の 1 例
要約：症例は 46 歳，女性．32 歳よりうつ病で近医に通院中であった．35 歳より 2 型糖尿病で治療を開始された．
メトホルミン 500 mg!日およびインスリン（1 日 70 単位）による治療で HbA1c5.4 ％であった．
来院当日，自殺目的でリスプロ 2100 単位，グラルギン 900 単位を注射し，1時間後に救急搬送となった．
遷延性低血糖に対応するため入院とし，食事および経口と経静脈でブドウ糖の投与を行った．
来院時の血清インスリン濃度（IRI）が 31975μU/ml ，6 時間で 20903μU/ml ，9 時間で 9370μU/ml と低下，
注射後 141 時間でブドウ糖投与を要しなくなった．
持続血糖モニタリングでは血糖値の変化はブドウ糖投与による上昇と低下を繰り返し，急峻な鋸歯状波形を呈していた．
IRI の経過は低血糖からの回復時期を予測する目安となり，血糖降下作用が続く期間では頻回の血糖測定が必要であると考えられた．
Key words：インスリン過剰投与，持続血糖モニタリング，うつ病，自殺企図（糖尿病学用語集に掲載なし），
鋸歯状波形（糖尿病学用語集に掲載なし）
Re: (スコア:0)
死にたかっただろうにおそらく勝手に治療されモニタリングされ公開されるのは辛いだろうな。
あらかじめ (スコア:0)
リミッタも設定させればいいかもな。
そうすれば通常の三倍みたいな、あり得ない数字が独り歩きしないだろう
Re: (スコア:0)
いやホントに。誤入力のケースは考慮するべきだから、小数点が認識されないとかいう問題ではない。
Re: (スコア:0)
さすがにリミッターはあるのではないか。
定期的に決まった量を投与する他に、血糖値や摂取した炭水化物の量で計算するボーラス投与があるので、10倍程度ならあり得る入力値なのかもしれない。
例えばこの機器では最大が25ユニットになっているし、入力例でも10倍と間違って認識された3ユニットより遥かにデカイ値が入力されている。
https://mds.terumo.co.jp/common/img/user/pdf/guidebook_smart.pdf#page=26 [terumo.co.jp]
Re: (スコア:0)
リミットを .5 と設定するわけですね
影響範囲 (スコア:0)
一人の看護師さんがミスを犯しても、せいぜい二桁程度の被害者に留まるだろうが、
この手の医療機器に瑕疵があると、数千数万の被害者が生じうるな。
※ただしPHPを除く -- あるAdmin (スコア:0)
通常の１０倍だと？これだけで、意識がトブぞ...！
確認画面 (スコア:0)
確認画面で最終的な数字をよく確認することを推奨している
体内に注入する薬品の量を省略入力したり確認をしないユーザーもそれはそれでアレだな。
文字列の入力値を数値にするのなんて普通は組み込みの数値化関数を通すだけだけど、どうしたんだろうね。
Re: (スコア:0)
>体内に注入する薬品の量を省略入力したり確認をしないユーザーもそれはそれでアレだな。
ユーザー側とすれば、最近のプロポーショナルフォントだと、".3"とか書いてる場合は"."を見逃すんじゃないかなと思うよ。
実際に、ここの"コメントタイトル"の先頭に".3"って入れれば分かるけど、"."は殆ど見えないんだよね。
結果として、"見逃す=あると思い込む"から、ユーザは自分が入れた通りの入力になってると思い込んだんだと思うよ。
>文字列の入力値を数値にするのなんて普通は組み込みの数値化関数を通すだけだけど、どうしたんだろうね。
Windowsの場合で何だが、EditBoxを"数値のみ入力を受け付ける"設定にすると、
+/-とか小数点も入力できないから、"全ての文字を受け付ける"設定にして、1文字入力する毎
にどんな文字を入力したかを確認する...なんてことをしたことがある。
これの作り方で"数値が手前にないのに小数点を入力したら、小数点を無視する"
なんて作り方をしたら今回みたいなことになるんじゃないかなと思うよ。
Re: (スコア:0)
よくわかんないけど、確認画面に「.3」って出すの？それは流石にどうかと思うよ。
+/-とか小数点も入力できないから、"全ての文字を受け付ける"設定にして、1文字入力する毎
にどんな文字を入力したかを確認する...なんてことをしたことがある。
これの作り方で"数値が手前にないのに小数点を入力したら、小数点を無視する"
なんて作り方をしたら今回みたいなことになるんじゃないかなと思うよ。
やっぱりよくわかんないけど、それなら先に小数点が入力できなくてよかったねなんじゃないの？
Re: (スコア:0)
入力ミスで16進数として解釈可能な文字列やeやカンマが混入した場合に、組み込み関数が何食わぬ顔でとんでもない数値に変換したりしないといいですね
Re: (スコア:0)
(Excel: 呼ばれているかな?)
Re: (スコア:0)
開発としてはその方がまだマシだと思う。今回のように(?)変な自作をしてとんでもない数値に変換してしまうより。
# 仕様を把握して、普通のプログラムを書きましょう