2021-07-07

医療機器プログラムの該当性のガイドラインが改訂され、非医療機器の範囲が広がった?(間違い)

 医療機器プログラムの該当性のガイドラインは 2021年3月31日に発行されたもので2014年に発行されたものから置き換わりました。(厚労省のページ

GHS(ヘルスソフトウェア推進協議会)にて、第3回ヘルスソフトウェアのリスク分析入門セミナー(オンライン)を 2021年8月23日に実施します。

このオンラインセミナーの「ヘルスソフトウェアー規制と規制対象外の境界の考え方」にて、今回改訂されたプログラム医療機器該当性のガイドラインについても解説します。


ヘルスソフトウェアのリスク分析入門オンラインセミナー プログラム

13:00~13:10 開講挨拶(スケジュール確認,連絡)

13:10~13:30 GHS と GHS 開発ガイドラインの紹介 

13:30~14:00 ヘルスソフトウェア-規制と規制対象外の境界の考え方

14:00~14:15 休憩

14:15~15:00 ヘルスソフトウェアの周辺に存在するリスク(健康リスク)

15:00~16:00 リスク分析の考え方とリスク分析演習(仮想ヘルスソフトウェアを想定して)

16:00~16:15 質疑応答

16:15~16:30 アンケート記入・提出

厚労省のページ(医療機器プログラムについて)では、対象のソフトウェアが医療機器に該当するかしないかを判定した事例も随時 Excel 表にて提示されています。

また、厚労省は医療機器プログラムの早期実現推進を目的として、医療機器プログラムに関する相談を「医療機器プログラム総合相談」として一元的に受け付ける窓口をPMDAに設置しました。

SaMD一元的相談窓口(医療機器プログラム総合相談)

一方で、これまで医療機器の該当性の相談を都道府県の担当窓口にて受けてきましたが、今後、プログラムの医療機器該当性の相談については、厚生労働省医薬・生活衛生局監視指導・麻薬対策課にて一元的に行うこととなったようです。

なお、医療機器に該当しないプログラムの広告相談につきましては、引き続き、都道府県にご相談とのことです。

医療機器プログラムの該当性のガイドライン が改定されたことで、非医療機器の範囲が拡大されたとミスリードして、下記のようなことを書いているサイトがありますが、これは間違いです。(厚労省確認ずみ)
厚労省が今年3月31日より施行したプログラム医療機器のガイドラインによると、このような健康管理のためのプログラムは非医療機器としてリリースが可能とのこと。

つまり非医療機器部分が拡大されたわけで、このガイドラインを活用すれば、非医療機器=薬事法の外でいろいろな仕掛を行うことが可能となります。

米国もそうですが、医療機器と非医療機器の境界にあるヘルスソフトウェア、ヘルスアプリはどんどんリリースされてきており、各国の規制当局もそのソフトウェアが医療費の削減に貢献されるのであれば歓迎したいというスタンスで、厚労省も効果・効能があって、医療機器にするなら支援しますよといっています。

一方で、医療機器と非医療機器の違いや、健康被害に至るようなリスクがあるのかないのかといったリスクマネジメントについて、よく分からないままソフトウェアをリリースし、商品を売りたいがために、効果・効能的なことを謳ってしまって、広告規制に引っかかるといったケースも増えてくると思います。

GHSのリスク分析入門セミナーでは、規制と規制対象外の違いや、どんなリスクが想定されるのか、また、リスク分析とはどのようにやるのかについて解説します。

セミナーの詳細については、GHSのこちらのページからご確認ください。


2021-03-23

人工呼吸器は不足したからといって簡単に作れるもんじゃない

他業種の医療機器製造業参入について(人工呼吸器そんなに簡単に作れるの?)』の記事をおよそ1年前に書いた。

時は流れて最近、人工呼吸器の使い方を 病院の臨床工学士の皆さんに説明する場に立ち会う機会があった。

自分は人工呼吸器はあまり詳しくないので、初めて聞く内容ばかりだったが、かなり専門性のある内容であることは分かった。

例えば、マスクが外れたことを検知したときにアラームを鳴らして、いったん酸素の供給を止めるが、マスクを付け直したことを検知したら自動的に再稼働するとか、使用前点検の記録を各病院のルーティーンに合わせてカスタマイズできるとか。

そういった専門的で臨床使用する場合の仕様が人工呼吸には必要なんだということが分かったので、『他業種の医療機器製造業参入について(人工呼吸器そんなに簡単に作れるの?)』の記事を書いた頃の、「人工呼吸器不足しているので作ってみました」的な記事はいったい何だったのかと思った次第だ。

たぶん、臨床の現場では、それは役に立たない代物であり、実際には 睡眠時無呼吸症候群の治療用のCPAPの代用品にできるかどうかくらいだったのだろうと思う。


医療機器ってそんなに簡単に参入できるもんじゃないよなということを再認識したとともの、医療機器を作るなら医療の現場をじっくり見て臨床的に何が行われているのかをちゃんと見ないとダメだと思った。

2020-07-07

組込みソフト開発とクラウドソフト開発の違い

30年近く組込みソフトウェア開発に携わってきたが、ここに来てクラウドソフトウェアサービスの開発に関わっている。

そこでだいぶ様子が違うことが分かってきた。今回はその違いについて書いてみたい。

IoT機器(組込みソフトウェア機器)を無線/有線ネットワークでクラウドに接続し、クラウドアプリケーションソフトウェアでサービスを提供するというスタイルが増えつつある。

かつて、組込みソフトウェアは出荷時のソフトウェア品質を担保するためウォーターフォール的な開発プロセスが取られてきたが、ソフトウェアの規模が増大するにつれて、組込みソフトウェアでも一部または全体にアジャイル的なプロセスが適用されるようになった。

一方で、クラウドアプケーションソフトウェアの開発はどうだろう。クラウドアプリケーションソフトウェアの開発は DevOps だと言われる。

DevOps については、『DevOpsとは何か? そのツールと組織文化、アジャイルとの違い』の解説がわかりやすい。
DevOpsとは「開発チーム(Development)と運用チーム(Operations)がお互いに協調し合うことで(図1参照)、開発・運用するソフトウェア/システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念である。
【引用おわり】

ようするに、開発しながら運用も行うという、組込みソフトウェアを長年やってきたエンジニアとしては、ちょっと衝撃的な開発スタイルだ。

これが実現可能となっているのは、クラウドサービス提供各社(Microsoft Azure や Amazon AWS等)のクラウドアプリケーションが、クラウド上での各種サービスアプリケーションの組み合わせで、目的を果たせるようになっているところにある。

最終的なUI部分の作り込みは必要だが、IoT機器との接続や、アーカイブ、二次処理、データからのトリガー、セキュリティ確保等々、すでにあるサービスの組み合わせでかなりことができる。

これらのサービスの組み合わせの開発もクラウド上で行うので、クラウドアプリの開発にはPCとインターネットがあれば、それだけでできてしまう。

ただ、クラウドアプリの開発には、各社がクラウドサービスで提供するサービス群を使いこなすためのノウハウ(多くはWEBに情報があるが、使いこなすには経験が必要)をもったエンジニアが必要であり、この主の知識・スキルはかつての組込みソフトエンジニアが持っている知識・スキルとは異なると感じている。

ちなみに、Microsoft は今後のもうけの種をIoT や PC に搭載する Windows OSの販売から、クラウドサービス(Azure)の使用料に大きく舵を切っている。今や、Microsoft Office も Microsoft 365 でクラウドサービスになりつつある。

Microsoft は IoTのOSは Windows にこだわっておらず、Linux でもよいと考えている。だから、最新のWindows 10には WSL(Windows Subsystem for Linux)を追加できるし、Linux から Azure への接続もまったく問題にしていない。

実際やってみてわかるのは、IoTからクラウドへの接続費用とクラウドサービスの使用料はそれなりにかかる。クラウドへの接続のセキュリティレベルを高くしようとすると、それだけ接続料は上がるし、クラウドサービスは使用するサービスの組み合わせでどんどん料金が上がっていく。

エンドユーザは、さまざまなクラウドサービスが無償で提供されている気分になっているが、実際にはかなりのコストがかかっていて、商品の代金やサブスクリプション費用にそのコストが上乗せされている。

商品の価格にクラウドサービスのコストを転嫁すると、商品を売り続けないとダメなので、各企業ともサブスクリプションでエンドユーザからお金をもらいたい。そのためには、Eコマースのサービスを導入する必要があり、その投資も馬鹿にならない。

また、一度、クラウドサービスをエンドユーザに提供し始めると、そう簡単にはやめられなくなる。クラウド業者をスイッチするこは理論的には可能だが、各種提供されるクラウドサービスのインタフェースがまったく同じではないので、実質的には難しい。

よって、クラウドサービス提供業者はクラウドサービスの利用企業を囲い込むことができる。クラウドサービスの提供にはかなりの費用がかかると思うが、それに見合った利益も確保できるので、おいしい商売だと感じる。

さて、DevOps の話にもどると、クラウドサービスでエンドユーザにどんな価値が提供できるのかは、実際やってみないとわからない部分が多い。

また、クラウドへアクセスする部分のUIは比較的簡単に変更可能であるため、ユーザの要望に応じて、運用しながら変更していくこともできる。

そこが、組込みソフトウェアの開発との大きな違いだと感じる。組込みソフトウェアの場合、ネット経由でシステムソフトウェアのアップデートがやりやすくなったとはいえ、リリース時のソフトウェア品質の担保は必須であり、変更にもかなり気を遣うし、検証や妥当性確認の工数も必要だ。

一方でクラウドアプリケーションの場合は、すでに完成されたサービスを組み合わせるため、個々のサービスの信頼性は確保されており、データの流れを変えていくようなイメージで変更ができる。

同じことを組込みソフトウェアで実現することも、ソフトウェアアーキテクチャ次第で可能ではあるが、最初のシステムアーキテクチャの構築が難しい。クラウドアプリケーションの場合は、すでにシステムアーキテクチャが用意されている状態で利用を始めるので、最初の苦労はない。

ちなみに、クラウドアプリケーションで提供される個々のサービスの完成度が高いからといって、試行錯誤的な開発をしていたのでは、エンドユーザの対する品質は担保できない。

アジャイルを単純な試行錯誤的な開発開発スタイルだと思っているエンジニアはさすがに少数になったと思うが、ひょっとして今でもそれなりの数いるのではないかと疑っている。

そういう方には、『アジャイル開発のプロジェクトマネジメントと品質マネジメント: 58のQ&Aで学ぶ』を読むことをお勧めする。

日立製作所でアジャイル開発の品質保証を実践してきた筆者らが、本当の意味での品質を担保したプロのアジャイル開発とは何かについてレクチャーしてくれている。

自分もまだ全部腹に落ちておらず勉強中だが、クラウドアプリケーション開発において実践しないといけないと思っている。

IoT(組込み)ソフトエンジニアとクラウドソフトエンジニア、この二種類のソフトウェアエンジニアが協力しないと、今どきのクラウドサービスが成り立たない。

この二種類のエンジニアは似て非なる者だと思うので、これらの開発をうまくコーディネイトできる人材が成功の鍵となるのではと思っている。

ソフトウェアとハードウェアのつなぎについても、両方の知識や経験をもった技術者(=組込みソフトエンジニア)の存在が重要だったが、IoT と クラウドについても両方の知識・スキルを持ったエンジニアがシステムの全体を俯瞰しながら、適宜最適となるようにソフトウェア開発プロセスを選択的に適用していく必要があるし、二つの文化の違いを理解した上で、それらを上手にマネジメントする必要がある。

明らかに10年前、20年前とは、ソフトウェアの開発スタイルが変わりつつある。クラウドサービスに関しては、クラウドアプリを開発できるエンジニアをどれだけ増やせるかがクラウドサービス提供者の売り上げアップの鍵となるため、クラウドサービスの技術を学ぶための教育コンテンツが驚くほど豊富にWEB上に存在する。それもすべて無償だ。

かつて組込みソフトエンジニアのための教育教材がないということで、SESSAMEが作られたのだが、クラウドエンジニアの教材は豊富に提供されている。このソフトウェアエンジニアのトレーニングという部分での進化もすさまじい。

ただ、勉強することが山ほどあって、分業しないとやってられないという現実はある。だからこそコーディネータの役割は重要だと感じる。

DevOpsを成功させるには、エンドユーザの対する価値と時代による価値の変化を敏感に感じ取るセンスも必要だし、価値をビジネスに結びつけるための戦略を考え、その戦略を実現するための技術が何であるかがわかるようでないとうまくいかない。

組込むソフトウェアとクラウドソフトウェア、新しい時代のソフトウェアエンジニア像について、今後も考えていきたい。