2019-10-20に投稿した『ソフトウェア系国際規格の認証の現状について』の記事に対して2020-02-10にコメントをもらっていて、確認＆承認を忘れており、昨日気が付いて承認をしました。2ヶ月以上放置してしまい申し訳ありません。
改めて、コメントの内容をここで紹介し、回答も書きたいと思います。
ーーーーコメント ーーーー
匿名 さんのコメント...
いつも有益な記事をありがとうございます。
汎用ソフトウェアが医療ソフトウェア規格の認証を受けることは意味が無いということは、ソフトウェアを含む医療機器開発には、汎用OSはもちろん、コンパイラが提供するライブラリも使用できないということですね？
リアルいタイムOSはもちろん、Linuxのような巨大なOS相当も、意図する使用を考慮してフルスクラッチが必要であるということですね？もしくは、LinuxクラスのOSは使用してはいけないということですね？
C言語ならいざ知らず、C++やJava 等の言語のメカニズムに相当する部位も汎用ソフトウェアと言えますから、それも使えないということですね？
ーーーーコメントに対する回答 ーーーー
さて、「汎用ソフトウェアが医療ソフトウェア規格の認証を受けることは意味が無いということは、ソフトウェアを含む医療機器開発には、汎用OSはもちろん、コンパイラが提供するライブラリも使用できないということですね？」のご質問に回答します。
汎用ソフトウェア(OTS: Off The Shelf Software）は OTS として検証・評価を行います。IEC 62304 はリスクベースアプローチを採っているため、何に使うのかが定まっていない状態で、リスクベースアプローチのプロセス規格を適用することは意味がないと言っているのであり、医療機器にOTSを使用できないとは一言も言っていません。
米 FDA は 医療機器に使用するOTSに対するガイダンスを発行しており、このガイダンスでは「そのOTSを医療機器に使用したときの懸念レベルを定めて、ハザード分析すること」を医療機器の製造業者に求めています。また、OTSの検証・評価も必要です。これもリスクベースアプローチです。
これについても勘違いしているOTSベンダーが多いのですが、OTSベンダーができるのはOTSの検証(=Verification）の部分であり、OTSが医療機器に使われたときの懸念レベルの推定やハザード分析は、医療機器製造業者が行います。正確には、その OTSを何に使うのか知っている医療機器製造業者しか、懸念レベルの推定やハザード分析はできないということです。
もちろん、Windows や Linux を医療機器に使用することもできますが、それらOTSを医療機器に使用したときのリスクの分析（OTSに障害が起きたときの患者への危害の重大さや発生確率の分析と評価）がもとめらます。
記事の中でも説明したつもりですが、機能安全のアプローチである認証が取れたOTSを使用することを求めるという考え方と、意図する使用（=Intended Use）を明確にした上で、リスクベースアプローチでOTSを使用するという考え方は、元のコンセプトが異なるということです。
リスクベースアプローチの考え方であっても、OTSが使えないということはありません。OTSがどんな用途の医療機器に使用するのかを分析した上で、必要な検証、評価を求めています。
また、コンパイラは 医療機器に組み込まれるソフトウェアではないものの、製品の品質に影響を与えるQMSソフトウェアであることから、そのリスクレベルに応じてバリデーションを求められます。(ISO 13495:2016 より）
さらに、近年の医療機器規制の中のサイバーセキュリティ要求により、汎用ソフトウェアの脆弱性の監視とパッチ対応は医療機器製造業者に対する義務となりつつあります。
いずれにせよ、汎用OSやコンパイラが医療機器に使えないということは一切ありません。
2020-04-21
2020-04-18
他業種の医療機器製造業参入について（人工呼吸器そんなに簡単に作れるの？）
それを受けて、自動車やその他の産業から、急遽医療機器の製造を支援したり、医療機器そのものを作りますといった発表も散見される。『ホンダが新型コロナ軽症者の搬送車両を開発、陰圧状態の後部座席で飛沫感染防ぐ』の記事中で、トヨタ自動車の豊田章男社長は、次のように述べている。
人工呼吸器の生産に対しては「人命に直結するモノづくりは簡単ではない」（自工会 会長の豊田章男氏）とし、直接生産は行わない姿勢だ。それはその通りなのだが、なぜ「人命に直結するモノづくりは簡単ではない」について解説したいと思う。
医療機器は規制が厳しいので、実際にどのような規制要件があるのかを書いてみる。非常時なんだから、一次的に規制は緩和してもいいのではないかという意見もあると思うが、まずは、現状どんな規制があるのかを書く。
法規制
電気を使用する医療機器では IEC 60601-1 医用電気機器―第１部：基礎安全及び基本性能に関する一般要求事項 の規格に適合しなければならない。
この規格は各種個別規格や副通則もあるので、医療機器の種別によって適合しなければならない規格は複数存在する。
※医療機器には基本要件基準が定められており、IEC 60601-1 は基本要件基準への適合を示すための規格の一つ。
ソフトウェアの要件としては IEC 62304(JIS T 2304）もある。さらに、医療機器を製造するには ISO 13485（ISO 9001 の医療機器版）の認定も必要だ。
どれ一つとってもハードルは高く、そのハードルの高さが、異業種からの医療機器業界への新規参入を阻んでいる。
なぜ、そんなに規制が厳しいのか？
第六十六条 何人も、医薬品、医薬部外品、化粧品、医療機器又は再生医療等製品の名称、製造方法、効能、効果又は性能に関して、明示的であると暗示的であるとを問わず、虚偽又は誇大な記事を広告し、記述し、又は流布してはならない。効果効能が明確でないのに、「癌が治る」とか「症状が軽減する」などと公告すると、一般市民が惑わされ害があるので規制されている。病気や健康は人々にとって強い関心事であるため、虚偽又は誇大な記事を規制しないとだまされる人が増えて社会が混乱する。
医療機器についても同じで、効能、効果、性能が臨床的に立証されていない機器は売れないし宣伝もできない。
規制がないと、製造業者が表明している機器の機能や性能が実際には十分でなかったり、リスクコントロールがないため事故が起こったりしてしまう。一般的な機器ならユーザがメーカにクレームを言えば済むかもしれないが、医療現場では取り返しがつかないような事態になるかもしれない。だから、医療機器は規制されている。
ベネフィット・リスク分析
医療機器も同様で、リスクはあるがベネフィットが上回るため、ある条件下では使用すべきということが多々ある。
生命維持装置や治療器には大抵リスクがあるので、どんなリスクがあり、それらのリスクを低減してリスクが受容できている状態にしておく必要がある。
そのときに、リスクはあるがベネフィットが上回るので条件付きで使用させるというケースも出てくる。
医療機器は、この潜在的価値の部分が脆弱だと、人の死に直結してしまう可能性がある。生命維持装置や治療器が期待通りに動かなければ、患者が死亡したり重傷を負ったりするかもしれない。
よって、この潜在的価値の部分を担保するために、さまざまな規制があると言えるし、規制当局は取り締まりをすることで、国民の安全を確保している。
緊急時にそんなこと言ってられない
だから、米FDA（食品医薬品局）は、COVID-19 に関連して、規制を緩和するガイダンスを次々に出してる。例えば、これやこれ。こちらのサイトでCOVID-19をキーワードに検索すると27件ものガイダンスがヒットする。
米国は、FDAにかなりの権限があり、規制に対する裁量権が認められているので、ガイダンスによって規制を緩和することができるようだ。
1か0（医療機器か、そうでないか）を判定しないといけない。
よって、現実的には、日本では薬機法を改訂しないかぎり、従来の規制を一次的に緩和することは難しい。
特に、現実問題、医療機器の製造業・販売業の業の認定がない企業に、一次的ではあっても医療機器を製造したり、販売させることはできないだろう。
米国も同じだが、審査の工程を簡素化したり、短縮したりすることはできるようだ。
現実的には何が問題になるのか
コロナ最前線で戦う医療現場にTeslaが約束の｢人工呼吸器｣を送ったという記事があった。
ところが、この機器は、睡眠時無呼吸症候群の治療機機器であるCPAPの機器だったようだ。価格は800ドルで、侵襲型の人工呼吸器（約5万ドル）とは異なる。
機能としては、CPAPも人工呼吸器も酸素を送り込むので似ているが、意図する使用/意図する目的（Intended Use）が異なる。
臨床的に目的が異なるものを緊急で転用するならその違いを理解している人が機器を扱わないと事故が起こる危険があるし、人間は必ずミスをする（ヒューマンエラーはなくならない）ので、臨時の使い方を多くの人がするようになると気をつけないといけないことを怠って事故が起こる確率も徐々に上がっていくだろう。
それも含めて緊急事態だからベネフィット・リスクを考えて、臨時的な使い方を許容するという選択肢もあるかもしれない。
どちらを優先させるべきか悩ましいが、前提として臨床的に有効性のない機器を投入することは間違いだと言えるし、患者が死や重傷に至るようなリスクに対してリスクコントロールがされており、リスクが受容できているという確認（＝バリデーション）は必ず必要だ。
特に、医療機器の開発にあたっては、臨床的な知識や医療現場での機器の使われ方、治療や診断の実際について、開発者が十分に理解していることが重要だ。
今、集中治療学会は、新型コロナウイルス感染症（COVID-19）の対応に関連して、人工呼吸教育ビデオや、新型コロナウイルス肺炎患者に使用する人工呼吸器等の取り扱いについて（Ver.2.0）などの情報を公開している。
これを見るだけでも人工呼吸器は取り扱いに注意が必要で、十分なメインテナンスが必要な機器であることがわかる。
「人工呼吸器の部品を3Dプリンタで作りました」などのニュースを見ると、作った部品は滅菌できるのかとか、つなぎ目から空気の漏れは起こらないのか、薬液耐性は大丈夫かとかといった疑問が沸く。
人工呼吸器を本気で作ろうと考えている設計者は、まずは、臨床的な知識、治療の実際について理解してから、自分達が持っている技術がどの部分に活かせるのかを考える必要があると思う。
総合的な感想
例えば、IEC 62304 はプロセス規格なので、この規格への適合と機器の安全は一体一ではない。機器としてのリスクを分析しており、リスクが受容できていることの確認はしている。でも、この規格の一つ一つの要求について、本当に必要か？という要求もないわけではない。
再発防止策の積み重ねは40年以上続いているのでハードルはどんどん高くなっており、医療機器ドメインへの新規参入はかなり難しくなっている。
でもハードルを下げれば、事故は増えるだろう。だからこそ、リスクの高い機器についてはハードルを上げざるを得ず、リスクの低い機器やヘルスソフトウェアのハードルは下げて上げるのが現実的であり、米FDAはそういうアプローチを採っている。
では、人工呼吸器はどうか。生命維持装置なのでリスクが高い機器であることは間違いない。人工呼吸器が足らない状況にみんなが協力して打開しようとすることはとても良いことだが、よかれと思った取った行動が逆の結果を招くかもしれないのが、医療機器の怖さでもある。
意図通りに動作すれば社会に貢献でき、高い満足感も得られるが、その裏側には大きな責任（＝リスク回避の責任）もあるということだ。
この危機的な状況にあっても、安易に実験的な機器を現場に投入するよりは、現存する機器の増産の可能性を探ることが現実的なような気がする。
日本の自動車業界が医療機器製造業者に製造に関する支援を表明しているのはそういう理屈なのだろう。
2020-04-09
Raspberry Pi3を使ったリアル波形描画(10) アーキテクチャの設計思想について(2)
今回は、このシステムの重要な要素(=商品価値=コアコンピタンスとなりうる部分）の説明をする。
アイテム構成にうち、他社に真似できない商品価値となる部分（コアコンピタンス）のソフトウェアを再利用可能な資産にすることができれば、商品の価値となるソフトウェアアイテムをベースに派生製品を作ることができる。それらの商品群は個々の商品の競合力が高く、かつ、商品群としても強く、さらに、効率よく派生開発が可能となる。
コア資産部分がUIやI/Fに依存していなければ、コア資産をベースにさまざまなI/FやUIを持った派生製品を作ることができる。汎用I/Fや、UIは時代とともにどんどん代わっていくので、それらに対応していき、コア資産の実力をじっくりと高めていけば、商品群は競争力を高いまま維持することができるはずだ。
コア資産が他社の追随を許さない性能を持っている、または特許で知財が保護されていれば、競合しても勝つことができるし、仮に営業力で負けても、長いこと使っていればユーザのその性能の差に気が付き、戻ってくるだろう。
先の一番下のレイヤーがデータソースレイヤーで心電図の入力部、真ん中がドメインレイヤーで、デジタルフィルタや心拍数計測部、一番上がプレゼンテーションレイヤーで結果を表示する部分です。
今回は、重要な不整脈の解析などは入れていませんが、それがあればドメインレイヤーに含まれ、解析性能が良ければコアコンピタンスになります。
ちなみに、デジタルフィルターやQRS検出の部分も、それなりにノウハウがあるはずなので、コアコンピタンスになります。
EcgAcLineNoiseFilter クラスは、心電図に重畳する50Hzや60Hzの電源ノイズを除去するフィルターで、EcgDriftFreeFilter クラスは、呼吸やその他の基線変動要因を取り除き、心電図を見やすくし、心拍数計測の精度を高めるために必要なアイテムです。
EcgHighCutFilter はアナログフィルターで取り除いてもなお、残っている40Hzより高域のノイズ成分を取り除くフィルターとなります。QrsDetectorTypeTest1 クラスは、心電図のQRSを検出するためのクラスで、このシステムの中ではもっとも複雑性が高く、システムの性能に寄与するアイテムです。TypeTest1としているのは、QRS検出のソフトウェアは試行錯誤しながら精度を高めていくことが多く、1回で完成することはなく、いろいろな試行を繰り返すことになるからです。
このクラス図では、派生クラスにしていませんが、インタフェースを共通にしておいて派生させていろいろなタイプを作って差し替えながら、性能を検証していくのがよいと思います。
また、デジタルフィルタについても、一度固まってしまえば変更することはあまりないと思いますが、こちらもベースクラスから派生させておいて、後々差し替えられるようにするのもよいと思います。
実際、デジタルフィルタは C言語で数行で表現できてしまうケースもあるため、技術者研修ではわざわざクラスに分けたり、派生させたりしないことが多いようですが、商品としてまた、コアコンピタンスとしてデジタルフィルタを位置づけるのであれば、ソフトウェア資産として独立させて、再利用することに意味があります。
そのソフトウェアシステムのうち、競争力を生み出すコア資産が何か、そのコア資産が再利用しやすくできているか、そこができているかどうかが、競争力の高い商品でかつ、効率のよい開発ができるかどうかの分岐点になります。
詳しくは、『リアルタイムOSから出発して 組込みソフトエンジニアを極める[改装版]』の第三章をお読みください。
登録:
投稿 (Atom)