2017-07-26

医機連から公開されたIEC 62304適用に関する質疑応答集(Q&A)

医機連(一般社団法人日本医療機器産業連合会)が2017年5月17日に厚労省から発出された『医療機器審査管理課長通知:医療機器の基本要件基準第12条第2項の適用について』の運用に関する留意点について,質疑応答集(Q&A)を公開した。

ようするに,IEC 62304(JIS T 2304)への適用に関する通知が5月17日に厚労省から出たが,その通知だけではよく分からない点があるので,業界の総意として質疑応答集(Q&A)を公開したということである。

医療機器審査管理課長通知:医療機器の基本要件基準第12条第2項の適用について』では,2017年11月25日から適用される医療機器の基本要件基準(平成17 年厚生労働省告示第122 号)の第12 条第2項の規定(プログラムを用いた医療機器に対する配慮)に適合するためには,基本的に JIS T 2304(IEC 62304)に適合することや,薬事申請時に JIS T 2304 への適合性を説明する資料の記載事例などが説明されている。

医機連から公開された 質疑応答集(Q&A)は,この厚労省通知だけでは,実運用上不明な点をクリアにするために作成された。

医機連(一般社団法人日本医療機器産業連合会)は保健・医療用の用具、機器、器材、用品等の開発、生産、流通に携わる事業者団体の参加のもと、1984(昭和59)年2月に設立された,医療機器系の業界団体の元締めである。

今回発行された質疑応答集(Q&A)は,医機連の法制委員会配下の医療機器プログラム対応WGで策定したものだ。

機能安全規格である IEC 61508 や IEC 26262 と IEC 62304(医療機器ソフトウェアーソフトウェアライフサイクルプロセス) の違いは,IEC 62304 は各国の医療機器規制に付随する基準の適合確認のために使用される点である。

そのため,企業から見れば,その規格に適合(当該規格への適合が絶対条件ではないが・・・)していないと商品を売れなくなるかもしれないため,規格の運用についても詳細なルールが必要だ。

2017年5月17日に発出された厚労省通知だけでは,その詳細な運用ルールが分からないところがあるので,通知の行間を埋める質疑応答集(Q&A)が必要となる。

例えば,IEC 62304(JIS T 2304)は IEC版では2006年版と2012年版があり,JIS では 2014年版と2017年版がある。初版と追補版の二種類が存在する。医療機器の基本要件基準第12条第2項では,「最新の技術に基づいたライフサイクルプロセス」への適用を求めているため,新しい方の規格の方に適合する必要がありそうだが,旧規格からの移行期間はあるはずだ。前述の厚労省通知には規格の版については何も書いていない。しかし,初版の移行期限はいつかがはっきりしないと運用ができない。

そこで,今回,質疑応答集(Q&A)で,移行期限は 2022 年 2 月 28 日までの移行を推奨とするという見解が示された。

また,本ブログでも取り上げた『汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない』についても,医機連の見解が下記のように示された。
Q02:医療機器に搭載する OTS(off-the-shelf、市販されている既製の)ソフトウェアについても、第 12 条第 2 項への適合を示す必要がありますか。
A02:基本要件基準第 12 条第 2 項は、プログラムを用いた医療機器に対する要求事項を規定したものであり OTS 等を含むプログラム全体として JIS T 2304 への適合を示すことが求められます。なお、医療機器を構成する個々のプログラムの構成要素(製造販売業者の開発品や OTS など)を個別に適合を確認することは求めていません。
これにより,医療機器が搭載するOTS(off-the-shelf、市販されている既製の)ソフトウェアに対して IEC 62304 の個別の適合は求めていないことがはっきりした。

なぜ,OTS(off-the-shelf、市販されている既製の)ソフトウェアが単独で IEC 62304 に適合することが規格の趣旨を逸脱している(規格が本質的に何を目指しているのかを理解していない)のかについては,『汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない』を読んでいただきたい。

IEC 61508 や IEC 26262 は各国の法規制の要件にはなっていないと思う。そのせいかもしれないが,これらの機能安全規格は OTSの開発プロセスに対する規格の適合を推奨している。

規格が規制に使われる場合,できているかいないかが,法に適合しているかどうかの判断材料になることがある。よって,規格の適合が努力目標では済まない場合もあるし,製造業者の法的な責務となるケースがある。

IEC 62304 の場合,医療機器製造販売業者に対する責務という側面があり,OTSソフトウェア供給者はその責務を直接負うことができないため,OTSソフトウェアの単独認証が意味がないという面もある。業界の構造やサプライチェーンのしくみが根本的に違うから,そういった相違が生まれるのかもしれない。

ちなみに,医薬品,食品,医療機器,化粧品などの分野でレギュレトリーサイエンスという分野の科学が検討されつつある。(レギュレトリーサイエンス学会のサイト

レギュレトリーサイエンスとは
レギュラトリーサイエンスとは我々の身の回りの物質や現象について、その成因や機構、量的と質的な実態、および有効性や有害性の影響をより的確に知るための方法を編み出し、その成果を用いてそれぞれの有効性と安全性を予測・評価し、行政を通じて国民の健康に資する科学です。
言わば規制の有効性や規制がもたらす安全性を科学しようという取り組みだ。医療や食品だけに有効な科学ではないだろうから,他の業界にも広がっていくのかもしれない。

いずれにせよ,医療機器ドメインでは医機連から質疑応答集(Q&A)が発行されたことで,今後は IEC 62304 への適合を単独で示すOTSソフトウェアは出てこないだろうと思う。

2017-07-22

組込み機器のサイバーセキュリティどこまでやればいいか考える際の3つの視点

組込み機器のサイバーセキュリティ,どこまでやればいいのか判断するのが難しい。

商品の価値という目で見れば,多くの組込み機器に取ってサイバーセキュリティは潜在的価値(=ユーザーにとって当たり前に出来ていて欲しいこと)なので,できればコストをかけずに達成したい。

一方で,悪意を持ったハッカーは何をやってくるのか分からないと考えると,最悪のケースが次々を浮かんできて,どこまでサイバーセキュリティの対策をやればいいのか見当が付かない。

組込み機器のサイバーセキュリティはどこまでやればいいのかは,1つの視点だけで考えていたら答えがでないような気がする。

そこで,「1. 危害の大きさ」「2. 悪用の可能性」「3. 製品のライフサイクル」の3つの視点で,どこまでやればいいのか,最低限のハードルはどこかを考えてみる

1. 悪用による危害の視点

マルウェアや悪意を持ったハッカーの攻撃で,機器が受ける危害の大きさを考えてみる。サイバー攻撃による危害は情報セキュリティの3要素であるCIA(Confidentiality:機密性,Integrity:完全性,Availability:可用性)の侵害で考えるとよいのではないかと思う。

例えば,可用性の侵害とは,機器が使えなくなるとどんな困ったことになるかを考える。重要な機器ほど動かなくなると大変だ。例えば,ペースメーカーや人工呼吸器などの生命維持装置の可用性が侵害されたら,患者の死につながる。でも,個人のPCが感染して使えなくなっても人は死なない。その人の仕事ができなくなるだけだ。ただ,事務所中のPCが感染すると事務所の仕事が止まるので,危害は大きくなる。できるのかどうかは別にして使えなくされたらどんな影響があるのかを考えるのが可用性の侵害だ。

完全性の侵害とは,機器内部の情報が改ざんされるとどんな困ったことになるかを考える。重要な情報,例えば,検査装置の診断結果が「治療が必要」だったのが「正常」に改ざんされると,必要な治療が行われなくなる。事務に使っているPCで送ったメールの内容が変えられてしまったら,業務に支障がでるかもしれない。以前,PCを遠隔操作されて,本人の意思とは無関係に脅迫メールを送ったとして誤認逮捕された事件があった。改ざんや成りすましによる影響を考えるのが,完全性の侵害だ。

機密性の侵害とは,機器が扱う情報が外部に流失してしまうと,どんな困ったことになるのか考える。企業にとっては,情報の流失は信用の低下を招くので,機密性の侵害を重要視する製品もあるだろう。例えば,企業内で使用するネットワークプリンタなどだ。個人情報を扱わないなど機器が保持する情報がそれほど重要でなく,流失してもさほど大きな危害には至らない機器もあるかもしらない。機密性の侵害を,可能性や完全性の侵害よりも低いと考える考え方もあるが,情報が漏洩してしまったときの企業の社会的評価の低下を重要視する場合もある。

このように,悪用の可能性をひとまず考えずに,悪用されてしまったとして,機器のCIAの侵害を評価すると,起きてしまったときの影響の大きさを推察することができる。影響が大きければ大きいほど,確実な対策が求められる。もしも,CIAの侵害が起こらないことを証明できれば,サイバーセキュリティの対策は終わりにできる。

CIAの侵害が起こらないと言い切れないのであれば,「悪用の可能性」を考慮しなければいけない。

2. 悪用の可能性の視点

悪用の可能性では,まず,侵入の経路を分析する。IoTというとネットワークに接続されることが前提なので,侵入経路はあるのだが,ネットワーク接続やポータブルメディアのインタフェースを持たない組込み機器もあるので,そういった機器は悪用の可能性が極めて低い。(ROMを引っ剥がすといった可能性もあるのでゼロとは言えないが)

よって,侵入経路がない,または侵入経路を施設のゲートウェイが抑えているといった場合は,悪用の可能性が低くなるので,ハードルを下げられるかもしれない。しかし,サイバーセキュリティの場合,悪意を持ったハッカーが攻撃の意思を持っていると,可能性が低くてもチャレンジしてくる可能性があるため,悪用可能性が低いから対策しなくていいとはなかなか言い切れない。

例えば,汎用OSで既知の脆弱性がある場合,その脆弱性のパッチを当てていなければ,悪用される可能性は高いし,使っていない TCP/IP のポートが開いていればこれまた悪用の可能性は高まる。悪用の可能性を低くできるならば,コストが許す限り低くした方がよい。

なお,機器の外部環境に条件を付けることで,悪用の可能性を低くすることができる。例えば,施設内のネットワークとインターネットとの間にゲートウェイを設置してもらい,ゲートウェイで不審な通信をカットしてもらうようなケースだ。このような場合,機器のセイバーセキュリティのための環境条件が守られていないと,悪用の可能性が上がってしまうことをユーザーにアピールする必要がある。

また,ネットワーク接続があっても,RTOSを使い,プログラムがリードオンリーの領域でしか動かないならば,これまた悪用の可能性は下がる。ネットワーク経由でプログラムを書き換える機能を持たない,動的メモリ上でタスクが動かないなら,その機器が踏み台になる可能性はあっても,機器自体が発症する可能性はない。

ちなみに,ホワイトリスト式のアンチウイルスソフトウェアを搭載する行為もそれに似ていて,ホワイトリストに載っているアプリやサービス以外は動かないという設定にしておけば,マルウェアが機器上で発症することができなくなる。

脆弱性が多い機器は,悪用の可能性が高く,悪用の可能性が高い機器は,それだけ対策もたくさん取らなければならない。汎用性の高いOSを使っている機器は,結果として悪用可能性も高くなってしまう。

3. 製品のライフサイクルの視点

製品を市場に出す前と出した後の視点で考える。市販後に用意にソフトウェアをアップデートできるならば,市販前の対策はそれほどやらなくてもいいかもしれない。OTS(商用で即利用可能なソフトウェア製品)を使っている場合は,既知の脆弱性,未知の脆弱性があるので市販前も市販後もどっちも対応が必要になるかもしれない。

Windows や Linux には多くの脆弱性が見つかるので,市販前に分かっているぶんはパッチの適用が必要だし,市販後に発覚した場合は,パッチを当てる必要があるかどうか判断して実行する。

パッチが当てやすくなっていたとしても,全部やる必要があるかないかは,1の危害の重大度と2の悪用の可能性で評価するしかない。

脆弱性が見つかりにくいマイナーなOSを使っていれば,市販後の対応もほとんどなくなる可能性はある。

セキュリティインシデントが起こってしまった後に対応すれば済む場合は,市販前にはコストのかかる対策は行わずに,市販後に対応について準備をしておけばいいかもしれない。セキュリティインシデントが起こってしまうと取り返しが付かないような製品には,市販前の対策を十分にとって,悪用の可能性を低くしておかなければいけない。

「1. 危害の重大度の視点」「2. 悪用の可能性の視点」「3. 製品のライフサイクルの視点」の3つは,それぞれ関係性があってややこしいが,まずは,他の視点こ考慮せずに,それぞれの視点で組込み製品のサイバーセキュリティを評価してみて,その上で,どの対策をするとどこの影響を抑えることができるのかを考えてみたらどうだろうか。

2017-07-18

組込み機器の情報セキュリティは何のため?

組込み機器の情報セキュリティの対応に対するモチベーションがなかなか上がらない。誰のために何のためにやっているんだろうと自問自答し,さらに,どこまでやればいいのか見当が付かないためやる気が起こらない。

そもそも,悪意を持ったハッカーなんかが居なければ,セキュリティ対策なんてしなくてよかったのではないか。5月に世界中で蔓延したランサムウェアのWannaCry は米国家安全保障局(NSA)から流出した Windows の脆弱性 EternalBlue を使ったものと言われている。 EternalBlue は流出するまで,諜報機関により米国の監視活動に利用されていたらしい。アメリカは脆弱性の元を作っておきながら,米国に機器を売る者に対しては情報セキュリティのハードルを世界最高の水準に上げている。本当に迷惑な話だ。

こんなことだから情報セキュリティの取り組みにはやる気が起きない。しようがないので,次のように考えようと思う。

昔々,善良な村人しかいない平和な村がありました。泥棒もいないので,村人は玄関に鍵などかける必要がありませんでした。あるとき,村外れの山から金の鉱脈が見つかり,一攫千金を狙った者が隣村からたくさん移住してきました。村はだんだん物騒になり,物取りや傷害事件が起きるようになりました。村人は玄関に鍵を書けざるを得なくなりましたとさ。

ネットワークを使うこともなかった,善良な村人(組込み機器開発者)は,機器同士がネットワークでつながる時代になり,開けっぱなしだった玄関に鍵を付けなければいけなくなったという訳だ。誰のせいかと言えば,悪いのは泥棒だが,そういう時代なのだからしようがないとしかいいようがない。

問題は鍵を付けるコストは誰が負担するのかという点だが,それは結局エンドユーザーが負担することになる。だから,エンドユーザーの期待に応えながら,コストが上がりすぎないようにしなければいけない。

情報セキュリティの問題は,どこまでやればいいのかという判断基準が難しい。

商品の価値について考えるとき,左図のように顕在的価値と潜在的価値に分けて考えるようにしている。

顕在的価値は商品カタログの目立つところに書かれる機能や性能で,潜在的価値は「当たり前に出来ている」と期待されていることで安全や安心を担っている部分となる。

情報セキュリティの価値は,潜在的価値の方だろう。潜在的価値について,多くのユーザーは商品購入の時にあまり意識していないが,一度でも痛い目にあったりすると,潜在的価値を重視するようになる。

ブランドの価値は,この潜在的価値の積み重ねがものを言ったりする。また,社会問題になるようなインシデントが起きると,この潜在的価値はたちまちクローズアップされて,商品価値の中で重要視されるようになる。

だから,この潜在的価値を高めるためのソリューションを提供できる会社は,WannaCry のような社会的インシデントが発生するとここぞとばかりに活気づく。

情報セキュリティ対策にモチベーションが上がらないもう一つの理由は,これだ。インシデントが発生すると儲かる商売って,弱みにつけ込んでいるような気がして何か釈然としない。(ちなみに,機能安全をきっかけに儲けようとする会社も同じ穴のむじなだと思うけど。)

でも,最近はしようがないのかなあ,と諦めている。なぜなら,お客さんが製品に対して情報セキュリティの確保を求めるようになってきたからだ。

エンドユーザーが情報セキュリティの価値を認めて,対応がされていない製品は買わないと言ってきたら,それはやらないわけにはいかないし,そういうお客さんが増えてきたら,逆にその部分の潜在的価値をアピールすることもできるようになる。

ただし,無限にコストを上げることはできないので,費用や工数と効果の折り合いをどこかで付けなければならない。

その折り合いのさじ加減は,業務ドメインや,その製品の意図する使用によっても変わってくるので,一般化はなかなかできないと思っている。例えば,機器の可用性の侵害を重視するFA,可用性と完全性の侵害が患者危害につながる可能性のある医療機器,機密性の侵害による信用の低下につながるデータセンターなどさまざまな機器,業務ドメインがある。

情報セキュリティのCIA(Confidentiality:機密性,Integrity:完全性,Availability:可用性)の優先順位は機器の特性や使用目的,扱うデータの種別によって変わるので,情報セキュリティ対策の優先度も変わるし,どの機器にも効く魔法の杖はないと思う。
 IoT という大きなくくりでは,費用と効果の折り合いは付けられないということだ。また,その折り合いは,その会社の製品のセキュリティに対するポリシーにも影響を受ける。というか,折り合いを付けるためには,ポリシーを定めないとなかなかうまくいかないということだ。

だから,製品の情報セキュリティは今後は,企業のブランド価値にようなものになっていくのだろう。製品のセキュリティに対するポリシーを持ち,ホワイトペーパーを出せるような企業は,企業の潜在的価値として情報セキュリティを捉えていて,そこに価値があり,ブランド力を高めることに貢献すると考えているのだと思う。

顧客が価値があると考えるのなら,情報セキュリティにもモチベーションを持って取り組まないといけないということか。

2017-07-09

なぜ,バリデーションが必要なのか?

2017年6月19日に GHS(一般社団法人ヘルスソフトウェア推進協議会)が IEC 82304-1(ヘルスソフトウェア—第1部:製品安全に関する一般要求事項)の解説セミナーを開催した。

GHSがヘルスソフトウェア国際規格の解説セミナーを開催(innavi net 記事)

このIEC 82304-1 解説セミナーの中で,「ヘルスソフトウェア製品のバリデーション」の講演があり,改めて,バリデーションって何?,バリデーションは何のためにやるのか?を考えてみた。

Validation(バリデーション)は日本語では「妥当性確認」と訳され,ISO 9000 (JIS Q 9000:2015)では次のように定義されている。

3.8.13 妥当性確認(validation)

 客観的証拠(3.8.3)を提示することによって,特定の意図された用途又は適用に関する要求事項(3.6.4)が満たされていることを確認すること。

  • 注記 1  妥当性確認のために必要な客観的証拠は,試験(3.11.8)の結果,又は別法による計算の実施若しくは文書(3.8.5)のレビューのような他の形の確定(3.11.1)の結果である。
  • 注記 2  “妥当性確認済み”という言葉は,妥当性確認が済んでいる状態を示すために用いられる。
  • 注記 3  妥当性確認のための使用条件は,実環境の場合も,模擬の場合もある。
一方,バリデーションと混同しがちな概念でベリフィケーション(検証)の定義はこうだ。

3.8.12 検証(verification)

 客観的証拠(3.8.3)を提示することによって,規定要求事項(3.6.4)が満たされていることを確認すること。
  • 注記 1  検証のために必要な客観的証拠は,検査(3.11.7)の結果,又は別法による計算の実施若しくは文書(3.8.5)のレビューのような他の形の確定(3.11.1)の結果であることがある。
  • 注記 2  検証のために行われる活動は,適格性プロセス(3.4.1)と呼ばれることがある。
  • 注記 3  “検証済み”という言葉は,検証が済んでいる状態を示すために用いられる。
バリデーション(妥当性確認)とベリフィケーション(検証)の2つの定義を比較してみる。

 英語 日本語  先頭  中間  末尾 
 Validation  妥当性確認 客観的証拠(3.8.3)を提示することによって 特定の意図された用途又は適用に関する要求事項(3.6.4)が 満たされていることを確認すること。
 Verification  検証 客観的証拠(3.8.3)を提示することによって 規定要求事項(3.6.4)が 満たされていることを確認すること。

3.8.3 客観的証拠(objective evidence)
 あるものの存在又は真実を裏付けるデータ(3.8.1)。

3.6.4 要求事項(requirement)
 明示されている,通常暗黙のうちに了解されている又は義務として要求されている,ニーズ又は期待。


結果,バリデーション(妥当性確認)とベリフィケーション(検証)を比較すると,その違いは,中間の「特定の意図された用途又は適用に関する」と「規程」の部分だけだということが分かる。

これでは,Validation(妥当性確認)とVerification(検証)の違いが分からないという技術者がいても不思議ではない。

Validation(妥当性確認)とVerification(検証)の違いを 1981年に Barry W . Boehm が "Software Engineering Economics, Prentice-Hall" で次のように説明し,多くの人が引用しているのでそれを見てみよう。

 英語 日本語  英文の説明 日本語の解釈 
 Validation  妥当性確認 Are we building 
the right product?
正しい製品(成果物)を開発しているか?
(顧客要求を満たす製品を作っているか?)
 Verification  検証Are we building 
the product right?
正しく製品(成果物)を開発しているか?
(仕様通りに作っているか?)

英語では,同じ単語で語順を変えることで上手いこと説明しているのだが,日本人にはなかなか解釈が難しいかもしれない。

バリデーションは正しい製品(成果物)を開発しているのか?(顧客要求を満たす製品を作っているのか?)と問うていて,ベリフィケーションは,正しく製品(成果物)を開発しているか?(仕様通りに作っているのか?)を問うているという解釈だ。

それでもValidation(妥当性確認)とVerification(検証)の違いがよく分からないという人は,なぜ,Validation(妥当性確認)とVerification(検証)を分けないといけないのかという視点で考えてみるとよい。

ソフトウェア製品の場合,Validation(妥当性確認)とVerification(検証)は分けて考えた方がよいのだ。なぜなら,仕様通りに開発したのに,顧客要求を満たす製品になっていないというケースがよくあるからだ。

<仕様通りに開発したのに,顧客要求を満たす製品にならない要因の例>
  • 仕様書が完璧でないため,システムの使用環境やユーザーニーズをよく知らない設計者(ソフトウェアの場合プログラマー)が,不足仕様の行間を自分の判断で埋めてしまった。
  • 2次,3次下請けと設計作業が分配されたため,要求仕様が伝言ゲームで誤って伝わった。
  • 顧客の要求が正しく要求仕様に反映されておらず,誤りや曖昧さのある要求仕様から設計仕様が作られた。
  • 顧客要求事項の範囲(上限,下限)が分析されておらず,要求事項として示されていなかったため,設計者が自分の感覚で範囲を決めてしまったが,実際は要求とずれていた。
  • 設計者(プログラマー)が検証仕様を作成したため,パスするテストケースしか想定しなかった。よって検証は全部合格だが,漏れがあり妥当性確認は合格しない。
  • 顧客Aの要求を満たすように作ったが,顧客Bや顧客Cはその仕様を望んでなかった。
  • 設計仕様に漏れや反映されていない要求仕様があったり,要求仕様を勘違いして設計仕様を作ったりしていた。
  • 汎用的に作られた市販ソフトウェア(OTS)が,当該製品の要求実現にマッチしていなかったのにその問題に気付かず置き去りにされた。
これらの例から分かるように,大規模ソフトウェア開発のように,開発作業を分業し,階層化すると,下位層に行けば行くほど,顧客要求がよく分からない状態で作業(プログラミング)を行うことになる。顧客要求が分からなくても,問題なく作業ができているなら,それはアーキテクチャ設計がよいからかもしれない。IN と OUT が明確な,汎用性の高いソフトウェアアイテムを多くして,ドメインに依存したソフトウェアアイテムを少なく,凝集されることができれば,多くの汎用性の高いソフトウェアアイテムの単体テストは容易になる。

しかし,そんなよいアーキテクチャ設計のソフトウェアシステムや,要求仕様を正確に反映している完璧な仕様書なんて滅多にないから,プログラマーが曖昧な仕様書の行間を読んでプログラムを書くことなど日常茶飯事だろう。クライアントからすると過去の製品の仕様や,製品の使用環境を知っていて,より正確に行間を読んでくれるプログラマーが「よく出来る人」という評価になる。

人に依存した開発をやっている組織ほど,仕様書の精度が低い。仕様書の精度が低いのにいい仕事ができているのは,Validation(妥当性確認)とVerification(検証)を同時に意識しながら,作業ができる技術者がいるからだと思う。

小さいプロジェクトで,職人的開発をしているチームほど,Validation(妥当性確認)とVerification(検証)の区別が付かない,必要性を感じない場合が多い。なぜなら,Validation(妥当性確認)とVerification(検証)を区別しなくても,上記のような問題が発生しないからだ。

別な言い方をすれば,その人は,Validation(妥当性確認)で必要なことが頭に入っている状態でプログラムを作っていて,Verification(検証)しているときに,一緒にValidation(妥当性確認)もしてしまっているのだ。老練な技術者は「ここだけは抑えておこう」「ここに何かあったら大変だ」という製品の要所を把握していて,常に要所に影響がないかアンテナを張っている。その要所である「ここ」が,基本機能や基本性能を実現している部分であり,クリティカルシステムならリスクコントロール手段となり,バリデーション項目になる。

アーキテクチャの良さが要所を守っているというケースもある。基本機能や基本性能を実現しているソフトウェアアイテムと付帯機能を実現しているソフトウェアアイテムの凝集度が良く,結合度が弱いアーキテクチャが実現できている場合,付帯機能部分の追加や修正に失敗しても,基本機能や基本性能に影響を与えない,もしくは要所を触ることができないようになっていれば,要所を守ることができる。

さて,「技術者は現場を知らなければダメだ!」と上司や先輩から言われたと思う。これは別な見方をすれば,「Validation(妥当性確認)できるエンジニアになれ!」ということで,Validation(妥当性確認)とVerification(検証)が同時にできる人材は,開発効率が高く,効率的にクレームが出ない製品を作れる技術者なので,「技術者は現場を知らなければダメだ!」はそういったエンジニアになれという意味なのだ。

また,顧客に対して頻繁に使い勝手を確認するような開発スタイル(アジャイルプロセス等)を取るという行為は,Validation(妥当性確認)とVerification(検証)を同時に実施して,開発効率を高めていると言える。ちなみに,クリティカルシステムで,このスタイルを推奨しない。なぜなら,ユーザーにValidation(妥当性確認)を求める方法では,通常の使用環境ではおきにくい危険状態に対するリスクコントロール手段に,ソフトウェアの修正が悪影響を与えているかどうかの確認が漏れる危険性があるからだ。クリティカルシステムでは,バリデーション項目を抽出して,テストがしにくくても1つ1つ確認する必要がある。

Validation(妥当性確認)を行うには,当該製品分野に対する深い知識が必要でその製品の「ユーザニーズの理解」「意図する使用(Intended Use)の理解」「市場要求との整合性の判断ができるスキル」が出来る人材が必要となる。

ちなみに,製品に搭載するソフトウェアの規模はどんどん大きくなっているので,プロジェクトメンバー全員が「Validation(妥当性確認)できるエンジニア」になるのは不可能だ。

だから,Validation(妥当性確認)とVerification(検証)は分けないといけないのだ。

IEC 82304-1 では,箇条 6 ヘルスソフトウェア製品のバリデーション で,6.1 バリデーション計画, 6.2 バリデーションの実施, 6.3 バリデーション報告 が要求となっていて,計画の要求の中には,「e)バリデーションを行う要員に必要な資格要件を特定する。教育訓練が必要な場合は,バリデーションを始める前に完了しておく。」や「f)バリデーションチームの,設計チームに対する適切な独立性レベルを定める。」などの要求も含まれている。

バリデーションを行う要員の必要な資格要件というのは,特定が難しそうだが,対象となるシステムの使用者が特定の資格を持っていたり,特定のワークフローで仕事をしているような場合,バリデーション要因としてそれらの知識の必要性を判断する。

ある意味,これまで経験則やキャリアの長さで判断していた「バリデーション要員のスキル」を見える化して,漏れのないバリデーションをするルールを策定したと言えるだろう。

また,バリデーション計画を立てるためには,製品要求事項を抽出しないといけないのだが,これが出来ない人が多い。

Use requirement(製品要求事項)と Specification (仕様)の区別が付かないのだ。Use requirement(製品要求事項)は「使用の必要条件」という意味なので,それがないと製品が成り立たない,製品の基本機能,基本性能の元となる要件だ。

それが何なのか答えられない技術者が多い。その理由を考えると,日本の製品は既存製品に対する改良,改善,追加を繰り返す製品開発が多く,遙か昔に作成したUse requirements(製品要求事項)を忘れてしまった,または,最初に作ったUse requirements(製品要求事項)も実は,他社の同等製品からコピーしたものだったということなのではないだろうか。

だから,技術者は,最近追加した機能や性能,あるいは,不具合で修正した仕様には詳しいものの,製品に搭載されている基本機能や基本性能が何かをズバリ答えられない。

逆に言えば,多くの製品開発は,基本機能や基本性能はすでに枯れてしまっていて,おまけの機能を追加することで成り立っているので,Use requirements(製品要求事項)が何かを知らなくても後継製品ができてしまうということだ。

これは2つの面で問題がある。1つは,付加機能を付け足した製品しか作れないのでイノベーションが起こらない(市場を拡大できる製品が生まれない)ということと,2つ目は,付け足した機能が,基本機能や基本性能に悪影響を及ぼす危険性があるということだ。

ソフトウェアの場合,ソフトウェアの構造(アーキテクチャ)が悪いと,付け足した機能が基本機能や基本性能に悪影響を及ぼす危険性が高くなる。要するにスパゲッティのようなプログラムに機能を追加すると,さらに絡まりが強くなって,また,システムのどこが要所かを理解しないエンジニアが意図せず大事な機能や性能を実現している部分を傷を付けてしまう可能性がある。

だから,ソフトウェアの構造が悪いシステムほど,バリデーションが重要になる。Use requirements(製品要求事項)の項目を1つ1つ確認することで,その製品の必要条件が満たされているかどうか,製品の基本となる可用性や完全性が侵害されていないかを確認するからだ。

別な見方をすれば,細かい付帯機能すべてを確認できなくても,バリデーションによって製品の基本機能や基本性能には問題がないことを確認できるということだ。(将来,小さい設計変更はあっても,リコールに至るような大きな問題を押さえ込める確率が高まる)

製品やソフトウェアの規模が大きくなればなるほど,Validation(妥当性確認)とVerification(検証)は明確に区別することが重要で,かつ,これからのソフトウェア開発においては,Use requirements(製品要求事項)の抽出を含むバリデーション計画・実施・報告 が重要な要素となるということがお分かりいただけたかと思う。

P.S.

ISO 26262 では,Validation Plan の立案は明示的に要求していないように思う。(もし,間違っていたら教えて欲しい) その理由は,これまで自動車はUse requirements(製品要求事項)が「走る」「曲がる」「止まる」とように変わらない=普遍だったからではないだろうか。でも,電気自動車や自動運転ができるようになると,Use requirements(製品要求事項)が変わったり,多様化して,付け足した付加機能が基本機能を脅かしたりする危険が出てくるのではないか。自動車のソフトウェアもValidationを重視した方が良くないか。(サプライヤは Validation Plan 書けなかったりして)

2017-04-23

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

ソフトウェアの変更容易性は最大のメリットだが,最大のデメリットでもある。信頼性の高いソフトウェアを苦労して作り上げても,たった一行の変更で,とんでもないバグを作り込んでしまうことができる。

仕上げたソフトウェアに対してシステムテストをどれだけ繰り返してもなかなか不具合は収束しないし,非常に分かりにくい問題が残ったまま出荷されることもある。

だからこそ,ソフトウェアの品質を高めるためにソフトウェアの開発プロセス,保守プロセスを管理する方法が研究され,実践されてきた。近代のソフトウェア品質論の歴史はソフトウェア開発プロセス研究の歴史といっても過言ではないだろう。

しかし,クリティカルなシステムにとっては次のことが成り立つ。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

もしも,明確な危害を防ぐリスクコントロール対策が講じられるのならば,そのリスクコントロール対策を確実にすることを優先した方がよい。

極端なことを言えば,ソフトウェア開発プロセスが十分でなくても,リスクコントロール対策が確実であれば安全な場合はある。ハードウェアによるリスクコンロールが確実に効いていて,ソフトウェアの不具合があっても安全が確保されることはある。

例えば,ソフトウェアが何らかの出力エネルギーを制御していても,過大なエネルギーの出力のみを防げば危害に至らないのであれば,ハードウェアのリミッタがリスクコンロール手段になりうる。

ところが,問題がエネルギーが過大かどうかではなく,出力の信号波形がだったりするとハードウェアのリスクコンロールでは難しい。電気メスの出力を凝固のパルスにしたつもりが切開のパルスになってしまうようなケースだ。

この場合こそ危害に結び付かないためのソフトウェアによる安全設計を行い,その設計が有効になっていることを確かにするためのプロセス管理を行う必要があるのだ。

ここで強調しておきたいのは,ソフトウェア品質を高めるのにプロセスアプローチは有効だが,製品やシステムの使用に対する安全を確保するために優先すべきはリスクコントロールであるということだ。

それを逆転して考えては絶対にダメだ。「ソフトウェアの開発プロセスがキチンと管理されていれば,システムは安全だ。」などと考えるのは愚の骨頂だ。

ちなみに IEC 62304(医療機器ソフトウェアーソフトウェアライフサイクルプロセス)は,プロセスアプローチとリスクベースアプローチの組合せだから,単純なプロセス管理ではない。

何が違うかと言えば,プロセス管理をする前にリスク分析を行い,危害に至らないようなリスクコントロールを行い,主にリスクがコントロールされていることを管理するアプローチとなっている。

だから,極端な話,ソフトウェア開発プロセスが規格要求通りにできていなくても,想定した危害がリスクコントロール手段で対策できていれば,規格の本質的な趣旨としてはよいと言える。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

なのはそのためだ。そのことを忘れで,規格に適合することばかり考えていると,本末転倒のことが起こる。IEC 62304 に適合しているのに,危害が発生してリコールになってしまうとか,意図する使用が確定しておらずどんなリスクが想定されるのか分からないままOTS(汎用の市販ソフトウェア)の開発プロセスが IEC 62304 に適合していると言ったりする。

ソフトウェア開発プロセスを生業としている人々は,いったいなんのためにソフトウェア開発プロセスを管理しているのか,その活動が開発者やエンドユーザーにどんな価値を生み出しているのかを考えてみるとよいと思う。

IEC 62304 は一般のソフトウェア開発で行われている ソフトウェア開発プロセス管理 とは別に,ソフトウェアリスクマネジメントプロセス を持っている。これは,危害の一因となりうるソフトウェアアイテムやリスクコントロールに関わるソフトウェアのプロセス管理(要求定義,検証,トレーサビリティ,変更管理)を実施することだ。

リスク低減に関するソフトウェアのプロセス管理があることが,一般的なソフトウェア開発プロセスと異なる。更に言えば,IEC 62304 はソフトウェアプロジェクト管理の際に,重要視される予算管理や日程管理の要求がない。

医療機器ソフトウェアやヘルスソフトウェアのソフトウェアプロセス管理の第一目的はリスク低減なのだ。

それを理解しておかないと,ソフトウェア開発のプロセスを管理するという手段が目的になってしまう。

それって,医療機器ソフトウェアの世界の話だけじゃないんじゃないかと思う。ソフトウェア開発プロセスの管理能力の向上が,開発者やエンドユーザーにとってどんな価値を生み出すのかなぜなぜ分析してみるとよいのではないだろうか。


P.S.

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

をレビューワ-が意識するかしないかでソフトウェアレビューの内容も変わってくる。意識していれば,危害が発生しないか,発生しないためのリスクコントロールがキチンと管理されているかに重点が置かれるが,意識していないと,プロセス要求の一つ一つに適合しているかどうか重箱の隅をつつくことになる。

対象となるソフトウェアやソフトウェアが搭載されるシステムがどのように使われるのかをよく知らない,知りたいと思わないレビューワ-ほど,重箱の隅をつつくことに一生懸命になり,指摘が多くなればなるほど,自分が規格に詳しいことに対して鼻高々になるようだ。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

を理解しているレビューワ-はどうしたら危害を防げるのか,リスクコントロールが効いている状態を保てるのかを開発者と一緒になって考えるし,プロセス管理の甘さがどうして危害につながる可能性があるのかを指摘し,説明することができる。

2017-04-15

「ブレーキを踏むのを我慢してください」で自動車運転死傷行為処罰法違反

2016年11月に自動ブレーキ機能を備えた日産自動車の試乗車が前方の信号待ちをしていた車に衝突し,30歳代の夫婦に軽傷を負わせ,運転手が自動車運転死傷行為処罰法違反(過失運転致傷)容疑で千葉地検に書類送検された。

「ブレーキ我慢を」と指示…自動運転車で追突(YOMIURI ONLINEより)

状況としては,試乗車に同乗した自動車販売会社の社員が自動ブレーキ機能を体験させるために「ブレーキを踏むのを我慢してください」と指示し,当時,暗くて雨が降っている状況で前方の車を検知できず衝突してしまったらしい。ちなみに,試乗車の運転手に誤った指示をした日産自動車販売店の営業社員(28)と店長(46)も業務上過失傷害容疑で書類送検された。

この事件は,今後来るであろう自動運転社会において発生する事故の責任問題を予見させる。

今回のケースでは,現在の法律(自動車運転死傷行為処罰法)において運転手の過失が問われた。

では,自動ブレーキが当たり前になってきた昨今,自動ブレーキ機能を信頼してたユーザーがブレーキを踏むのが遅れたために,衝突事故を起こした場合も運転手サイドに100%の過失が問われるのだろうか。それとも,自動ブレーキを搭載している自動車メーカーにも製造物責任が問われるのだろうか。

医療機器の世界では,リスクマネジメントの事例でこれと同じような問題を考える。

ポイントはユーザーの行為が誤用なのか正常使用なのかの判断だ。製造業者が意図する使用(Intended Use)の通りにユーザーが使用したのであれば,正常使用だし,そうでなければ誤用というのが基本だ。

ISO 14971(医療機器−リスクマネジメントの医療機器への適用)では合理的に予見可能な誤使用(Reasonably Foreseeable Misuse)に対するリスクコントロールは製造業者側が講じることになっている。

しかし,合理的に予見可能かどうかの判断は,メーカーサイドの見解とユーザーサイドの見解では異なる。

一般的に,メーカーが異常使用と考えていても,ユーザーはあり得る使用と考える部分がある。このギャップは人間工学設計で埋めていくことになるが,基準が曖昧であると製造者側の主張が通るようになり,現実には危ないケースも出てくるため,近年,患者や使用者のリスク低減を目的にユーザビリティの規格が規制に使われるようになってきた。(IEC 62366-1, Medical devices - Part 1: Application of usability engineering to medical devices, 医療機器-第1部:医療機器へのユーザビリティエンジニアリングの適用)

ユーザビリティエンジニアリングを適用するにしても,機器の使用に関して,製造業者側が 意図する使用(Intended Use)をキチンと定義していなければ,合理的に予見可能な誤使用かどうかの判断はできない。

冒頭の例でいれば,自動車メーカーは自動ブレーキについて意図する使用(Intended Use)をどう定義しているのかということだ。

おそらく,自動車メーカーは自動ブレーキを運転手がブレーキを踏むという行為に対して遅れや誤使用(例えばブレーキの代わりにアクセルを踏むなど)があった場合の補助,サポート機能と定義していると思う。

そうであれば,冒頭の例は,ブレーキを踏めば踏めたのに踏まなかったので基本的には誤使用となる。ただし,合理的に予見可能な誤使用であれば,製造業者側にも責任が生じる可能性がある。合理的に予見可能かどうかは,ユーザーサイドが「いざというときに自動ブレーキが動作するのは当たり前」と考えているかどうかにもかかってくる。

「当たり前に動作するはず」の機能が動作せずに事故になったなら,ユーザーはその事故の責任は製造業者側にあると考える。雨天などの状況では「動作しないことがある」のであれば,雨天でも自動ブレーキが動くはずと考えて自動ブレーキに頼ることは,合理的に予見可能な誤用となる。この場合,製造業者はこの合理的に予見可能な誤用に対して,リスクコントロール手段を講じなければいけない。

取扱説明書に「自動ブレーキは雨天では動作しないことがあります」という注意文を掲載することは,リスクコントロール手段にはならないと考えた方が良い。なぜなら,ユーザーはそんな注意文は読み飛ばしてしまい,記憶に留めることはないからだ。

よって,リスクコントロール手段としては,例えば,ワイパーを動かしているときは,「自動ブレーキが効かないかもしれないランプ」を点灯させるなどして,運転手に自動ブレーキを頼れないことを分からせるようなことをする。

このようなリスク分析を行うには,自動ブレーキの意図する使用を製造業者側できっちり定義できていないとうまくいかない。ユーザーの行為が誤用なのか,正常使用なのかよく分からなくなってしまうからだ。意図する使用がはっきりしていないと,警告文や注意文を作っていても,それが製造業者の保身のためなのか,本当に危ないからやめさせないといけないのか訳がわからなくなってくる。

意図する使用(Intended Use)を曖昧にしておいて,取扱説明書には山ほど禁忌禁止事項が書いておくという方法は,実際にはユーザーがその禁忌禁止事項を守っておらず,その状況を製造業者が黙認していると判断されると裁判で負けることもある。

製造業者側の言い訳を注意文で主張しておいて,実際にはリスクに対するリスクコントロールを行っていない状況では,製造業者サイドの責任は回避できないこともある。

実際,機器の開発者が,製造物責任を逃れるために,過剰に禁忌禁止や注意を取扱説明書に書いておきながら,セールス部門がそれらを十分に理解せずに,本来はやってはいけないことをユーザーにアピールしてしまうということはある。

セールスは他社より優れいてる機能や性能をアピールして売り上げを上げたい訳だから,それも無理はないように思えるが,それが「安全」に関係する機能や性能である場合は,特に慎重になる必要があるし,「安全」を宣伝するのは,後でしっぺ返しが来る。

製品を売りたいがために開発者側が「やってはいけない」としていることについて「取扱説明書にはダメって書いてありますが,他のお客さんはやってますよ」などとセールスに言わせてはダメだ。

今回の試乗車の自動ブレーキが動作せずに衝突してしまったのもその例の一つだろう。

リスクマネジメント的に言えば,やってはいけないことがあるのであれば,それはユーザーにキチンと伝えなければいけないし,実際にユーザーがそのリスクを認識している状態になっていなければ意味がない。

今国会で成立した民法の改正でも,消費者側の権利が見直され,契約において消費者に一方的な不利な条項は無効となった。

自動ブレーキは自動車各社ともCMで盛んに宣伝しているが,その結果,消費者に自動ブレーキはいざというときに動作し,危険を回避できるという認識が,一般常識となったら,いくら取扱説明書で免責を書いても,製造業者側の責任は問われるであろう。

自動車メーカーが自動ブレーキを宣伝した後,一瞬,免責事項を出しているが,あれは消費者が内容を認識して,理解していなければ意味がない。

ちなみに,自動ブレーキの動作不良による事故が多発するようになると,今度は国が基準を作って認可をすることになるかもしれないが,その場合,認可をした国にも責任が生まれる。

認可したのに自動ブレーキが動作せずに事故が起こったら,認可した側の責任が問われる可能性もあるのだ。

安全を売り物にするな」という記事が以前書いたが,そうすると自分自身にしっぺ返しがくるからだ。安全は,当たり前にできていることが基本で静かに粛々と実装した方がよい。

2017-03-12

汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない

汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない。その根拠を JIS T 2304:2017 の箇条7 で説明したいと思う。

そもそも,IEC 62304 は医療機器製品のライフサイクルプロセスに適用し,医療機器のソフトウェアに起因する危害(特に患者に対する危害)を医療機器のライフサイクルプロセスを管理することで低減することを目的に作られている。

ライフサイクルプロセス規格といっても,医療機器製品の Intended Use(意図する使用)や使用目的,使用環境が定まっていることを前提にしている。

また,箇条3 によって,医療機器リスクマネジメント規格である ISO 14971 が引用規格になっており,対象となる医療機器のリスク分析が必須となっている。

したがって,何の医療機器に使うのか特定されていない汎用のソフトウェア製品では,どんな医療機器に搭載されるのかが定まっていないため,危害を想定することができない。

その点を頭に入れながら,IEC 62304 の箇条7 を見ていく。

7 ソフトウェアリスクマネジメントプロセス
7.1 危険状態を引き起こすソフトウェアの分析
7.1.1 危険状態の一因となるソフトウェアアイテムの特定
 製造業者は,JIS T 14971に規定した医療機器のリスク分析を行い,危険状態及び危険状態を引き起こす可能性のあるソフトウェアアイテムを特定する(4.2参照)。(クラスB,C)

注記 危険状態は,ソフトウェアの故障が直接の原因となる場合,又はソフトウェアに実装したリスクコントロール手段の故障が原因となる場合が考えられる。

→医療機器の Intended Use(意図する使用)や使用環境,医療機器の基本機能,基本性能が定まれば,リスク分析を行うことができ,想定される危害や危険状態を想定することができる。そして,危険状態を引き起こす可能性のあるソフトウェアの障害や,その障害の原因となるソフトウェアアイテムが特定できる。

7.1.2 危険状態の一因となるソフトウェアアイテムの潜在的原因の特定
 製造業者は,7.1.1で特定した危険状態の一因となるソフトウェアアイテムの,潜在的原因を特定する。

→医療機器のリスク分析がないと,危険状態の一因が特定できない。そのため,危険状態の一因となるソフトウェアアイテムが特定できない。汎用で重要なソフトウェアなのでソフトウェアアイテムすべてが危険状態の一因となりますとか,潜在的要因はあらゆることを考えていますといったスタンスをとろうとするなら,それは規格の前提条件である「完璧なソフトウェアなどあるはずがない。したがって,その医療機器の使用において想定される危害とリスクを重要度の高いところから優先的に低減する」という概念が理解されていないことになる。

製造業者は,必要に応じて,次に挙げるような潜在的原因を検討する。(クラスB,C)

a) 誤った又は不完全な機能仕様
b) 特定したソフトウェアアイテムの,機能におけるソフトウェア不具合
c) SOUPに起因する,故障又は予期せぬ結果
d) 予測できないソフトウェア動作を引き起こす可能性のある,ハードウェアの故障又は他のソフトウェアの欠陥
e) 合理的に予見可能な誤使用

7.1.3 公開されたSOUP異常リストの評価
 SOUPに起因する故障又は予期せぬ結果が,危険状態の一因となるソフトウェアアイテムの潜在的原因になっている場合,製造業者は,当該医療機器に使用しているSOUPアイテムのバージョンに関係する,SOUPアイテムの供給者が公開している異常リストを最低限度として評価し,既知の異常のいずれかによって,危険状態の原因となる可能性がある一連の事象が生じるかを判断する。(クラスB,C)

7.1.4 潜在的原因の文書化
 製造業者は,危険状態の一因となるソフトウェアアイテムの潜在的原因を,リスクマネジメントファイルに文書化する(JIS T 14971参照)。(クラスB,C)

→リスクマネジメントファイルは医療機器製造業者が作成するものであるから,汎用のソフトウェア製品の製造業者が「潜在的原因の文書化」をしても意味がない。

7.2 リスクコントロール手段
7.2.1 リスクコントロール手段の選択
 製造業者は,リスクマネジメントファイルに文書化した,ソフトウェアアイテムが危険状態の一因となるケースのそれぞれについて,JIS T 14971に従ってリスクコントロール手段を選択し,文書化する。(クラスB,C)

注記 リスクコントロール手段は,ハードウェア,ソフトウェア,動作環境又は取扱説明書において実施できる。

→医療機器と Intended Use(意図する使用)を特定しなければ,危害や危険状態を推定できないため,リスクコントロールしようがない。医療機器によっては,障害が発生したときに,すぐに停止した方がよい場合もあれば,停止せずに最低限の機能で機器を動かし続けなければいけない場合もある。例えば,リスクコントロール手段として,メモリ保護があるとか,エラーが発生したときにリセットがかかるといった一見,何にでも有効そうなリスクコントロール手段は,搭載する機器の Intended Use によってはリスク低減に有効ではないこともある。


7.2.2 ソフトウェアに実装するリスクコントロール手段
 リスクコントロール手段をソフトウェアアイテムの機能の一部として実装する場合,製造業者は,次の事項を実施する。(クラスB,C)

a) リスクコントロール手段をソフトウェア要求事項に含める。
b) リスクコントロール手段の実施に寄与する各ソフトウェアアイテムに対して,そのリスクコントロール手段によってコントロールしているリスクに基づいて,ソフトウェア安全クラスの分類を行う(4.3 a)参照)。
c) 箇条5に従ってソフトウェアアイテムを開発する。

注記 この要求事項は,JIS T 14971のリスクコントロールの要求事項を詳細にしたものである。

7.3 リスクコントロール手段の検証
7.3.1 リスクコントロール手段の実施の検証
 7.2で文書化したリスクコントロール手段を全て実施していることを検証し,その検証結果を文書化する。製造業者は,リスクコントロール手段をレビューし,それによって新たな危険状態に至ることがないか判断する。(クラスB,C)

7.3.3 トレーサビリティの文書化
 製造業者は,次のソフトウェアに関連するハザードのトレーサビリティについて,適宜文書化する。
(クラスB,C)

a) 危険状態からソフトウェアアイテムまで
b) ソフトウェアアイテムから特定のソフトウェアの原因まで
c) ソフトウェアの原因からリスクコントロール手段まで
d) リスクコントロール手段からリスクコントロール手段の検証まで
注記 JIS T 14971参照。

7.4 ソフトウェア変更のリスクマネジメント
7.4.1 医療機器ソフトウェアの安全性に関わる変更の分析
 製造業者は,医療機器ソフトウェア(SOUPを含む。)の変更内容を分析して,次を確認する。(クラスA,B,C)

a) 危険状態の一因となる潜在的原因が新たに生じていないか。
b) 新たなソフトウェアリスクコントロール手段が必要でないか。

7.4.2 ソフトウェア変更が既存のリスクコントロール手段に与える影響の分析
 製造業者は,ソフトウェアの変更(SOUPの変更を含む。)を分析して,ソフトウェアの修正が既存のリスクコントロール手段の妨げとなる危険性がないかを確定する。(クラスB,C)

7.4.3 分析に基づくリスクマネジメントアクティビティの実行
 製造業者は,これらの分析に基づき,7.1,7.2及び7.3で定義した当該リスクマネジメントアクティビティを実行する。(クラスB,C)

→汎用のソフトウェア製品の製造業者は,医療機器の Intended Use を知らないので,ソフトウェアの変更がどのような危険状態の一因となるのか想定ができない。

このように,IEC 62304 の箇条7 を見れば,汎用のソフトウェア製品の開発プロセスに IEC 62304 が適合できない(適合する意味がない)ことが分かる。

2017-03-01

JIS T 2304:2017 医療機器ソフトウェアーソフトウェアライフサイクルプロセス が発行されました

本日,2017年3月1日 官報にて,JIS T 2304 医療機器ソフトウェア-ソフトウェアライフサイクルプロセス が制定された旨公示されました。

本規格は IEC 62304 Ed. 1.1 (IEC 62304:2006 + Amd.1:2015)の JIS版となります。

JIS T 2304 は 2012年に Ed.1 が発行れており,今回の版は Ed.1 の修正版となります。Ed.1 から Ed.1.1 への移行期間については,規格自体には記載がありません。(IEC 62304 Amd1 には記載があり,3年以内の移行を推奨しています。)

閲覧だけならば,Ed.1.1 は日本工業標準調査会ホームページ(http://www.jisc.go.jp)で見られるようです。

2017年11月24日に 医療機器の基本要件基準 第12条 第2項 の経過措置期限が切れるため,ソフトウェアを搭載する医療機器は,いよいよ JIS T 2304 の適合を示すリミットが近づいてきました。

それを見越して,2016年9月に IEC 62304 Ed.1.1(JIS T 2304 Ed.1.1)に対応した IEC 62304 実践ガイドブック を JEITA 医療用ソフトウェア専門委員会から出したのですが,出版元のじほうの話では,残り100部を切ってきて,各書店に回りづらくなってきているようです。

まだ,増版は決まっていないので,まだ,入手していない方はお早めにお買い求めください。


----------
官報   第 6968 号 平成29年3月1日水曜日
(本  紙)

 日本工業標準調査会の調査審議を経て、平成29年3月1日に下記の日本工業規格を制定及び改正したので、工業標準化法(昭和24年法律第185号)第16条の規定に基づき公示する。

                            平成 29 年3月1日

厚生労働大臣 塩崎 恭久 
経済産業大臣 世耕 弘成 

                   記

1.制定された日本工業規格

JIS T 62083 医用電気機器-放射線治療計画システムの安全要求事項  

2.改正された日本工業規格

JIS T 0601-1医用電気機器-第1部:基礎安全及び基本性能に関する一般要求事項 
 
JIS T 2304 医療機器ソフトウェア-ソフトウェアライフサイクルプロセス 

JIS Z 4951 医用電気機器-第2-33部:磁気共鳴画像診断装置の基礎安全及び基本性能に関する個別要求事項 

  (内容省略)
備考 内容は、日本工業標準調査会ホームページ(http://www.jisc.go.jp)において閲覧に供する。
また、経済産業省産業技術環境局基準認証政策課、各経済産業局及び沖縄総合事務局経済産業部並びに厚生労働省医薬・生活衛生局医療機器審査管理課においても閲覧に供する。

 日本工業標準調査会の調査審議を経て、平成29年3月1日に下記の日本工業規格を廃止したので、工業標準化法(昭和24年法律第185号)第16条の規定に基づき公示する。

 平成 29 年3月1日

2017-02-01

「医療機器ソフトウェアの最新技術動向セミナー」が2月24日に東京で開催されます

昨年に引き続き,JEITA 医療用ソフトウェア専門委員会 にて,2月24日に 「医療機器ソフトウェアの最新技術動向セミナー」を開催します。

医療機器ソフトウェアに関するリリースされたばかりのヘルスソフトウェアの製品安全規格 IEC-82304-1や,最近話題のサイバーセキュリティが医療機器ドメインではどのように捉えられているかについても説明もあります。

医療機器関係の会社には工業会経由で本セミナーの紹介があったと思いますが,医療機器業界に新規参入を考えている方には知らない方もいると思いますので,本ブログでお知らせしておきます。

受講を希望される方は,JEITAのWEBサイト(こちら)から申し込んでください。

よろしくお願いいたします。


医療機器ソフトウェアの最新技術動向セミナー
“セキュリティ・リスクマネジメント・ライフサイクルプロセス,
その理解と適用について”

開催のご案内
日時:2017年2月24日(金)10:00~16:00
会場:渋谷区文化総合センター大和田 さくらホール
主催:一般社団法人電子情報技術産業協会(JEITA)/ヘルスケアインダストリ事業委員会
企画・運営:医療用ソフトウェア専門委員会

開催にあたって
 医療機器ソフトウェアを取り巻く環境は、急速に変化しつつあります。日本においても平成26年11月に医薬品医療機器法が施行され、医療機器ソフトウェアが「プログラム」として法規制の対象になりました。平成29年11月まで経過措置となっている最新の技術に基づく開発ライフサイクルの適用時期あと1年に迫ってきており、対応の準備が急がれています。
 最新の技術に基づく開発ライフサイクルの適用として参照されるIEC 62304:2006(医療機器ソフトウェア-ソフトウェアライフサイクルプロセス)は追補版が2015年に発行され、JIS化も進められています。これにより医療機器製造業者は追補版で導入されたレガシーソフトウェアの概念を取り入れた開発プロセスの修正等が必要となる場合があります。IEC 62304 の他にも、ヘルスソフトウェアの製品安全の規格となるIEC 82304-1が2016年10月に正式発行され、さらにIEC 80001-1 シリーズ(医療機器を組込んだITネットワークへのリスクマネジメントの適用)の策定作業も順次進められおり、新たな対応が求められつつあります。また、医療機器の世界でもサイバーセキュリティへの対応が昨年以上にクローズアップされ、AAMI TIR 57(医療機器情報セキュリティリスクマネジメントの原則)も2016年7月に公開されました。
 このような医療機器ソフトウェアの環境変化を踏まえて、この度、医療機器ソフトウェアの関する国際規格を中心とした最新技術動向をお伝えするセミナーを開催する運びとなりました。今回は、より実践的な内容とし、IEC 62304 実践的アプローチや医療機器に必要なサイバーセキュリティ対策、さらに医療機器ソフトウェアのリスクマネジメントについても解説します。さらに医療機器ソフトウェアの検証としてベリフィケーションとバリデーションの理解と考え方についても解説致します。
 医療機器に係わる企業の経営者、設計開発、海外法規・薬事、品質保証、安全管理、標準化、規格適合試験等の業務に従事される方はもちろんのこと、医療情報ベンダー、医療機器分野に新規参入する方々にも有益なセミナーになると考えております。
 皆様のご参加をお待ちしております。

開催概要
【日時】 2017年2月24日(金) 10:00~16:00 (受付開始 9:30~)
【会場】 渋谷区文化総合センター大和田 さくらホール
 (公式WEB  http://www.shibu-cul.jp/)
 渋谷区桜丘町23番21号[Google地図]
【定員】 500名
参加費
JEITA会員:7,560円、非会員:10,800円(テキスト代・消費税込)

申込締切日
2017年2月17日(金)

プログラム

09:30-10:00受付
10:00-10:10開会挨拶
10:10-10:55医療機器ソフトウェアを取り巻く規制の背景と標準化の動向
-IEC62304, IEC82304-1, IEC80001シリーズ-
10:55-11:40医療機器へのソフトウェアライフサイクルプロセスの適用
-IEC 62304 実践的アプローチ-
11:40-12:40昼食
12:40-13:20ヘルスソフトウェアの製品安全規格
-IEC 82304-1の理解-
13:20-14:05医療機器に必要なサイバーセキュリティ対応
-国内外その考え方,動向について
 厚労省ガイダンスの考え方とその対応について-
14:05-14:20休憩
14:20-15:05医療機器ソフトウェアのリスクマネジメント
-ISO14971,AAMI TIR 57の理解とその適用-
15:05-15:45医療機器ソフトウェアの検証
-ベリフィケーションとバリデーションその理解と考え方-
15:45-16:00閉会挨拶