2016-12-07

IEC 62304 実践ガイドブック概説(4)-サプライヤにこそ必要なIEC 62304-

本題にはいる前に,DeNA が運営するインターネットサイト WELQ(ウェルク)がちまたで話題になっていることを取り上げようと思う。

WELQは,サイトで化粧品や健康食品について,効果・効能が保証されているかのような記事を掲載していた。

WELQは,インターネット上の他のサイトに書かれた記事を引用していた上に追加・修正まで加えてしまっていたのだそうだ。医師が書いた元の記事に,シロウトのライターが文章を書き加えて,その医師の名前のままで記事を出していたりしたらしい。テレビで記事を引用された医師が「自分が書いていないことが書き加えられて引用されている」と怒っていた。

人によっては,大量の記事の追加・修正は,人間のライターではなく,AIソフトウェアにやらせていたのではないかと疑う人もいる。

【Yahoo! Newsから引用 「DeNA「ウェルク」都が聴取…誇大広告の疑い」】
IT大手ディー・エヌ・エー(DeNA)が運営し、記事が不正確だったなどとして公開中止とされたインターネットサイト「WELQ(ウェルク)」について、東京都が医薬品医療機器法(旧薬事法)違反(誇大記述・広告)の疑いがあるとして、調査を始めたことがわかった。 
 5日に同社の担当者から聴取した。 
 都が問題視しているのは、同サイトで、特定の化粧品や健康食品について、効能や効果が保証されているかのような記事が掲載され、商品の購入ページに移動できる仕組みになっていた点。都は誇大な広告とみなせる記事が多く、記事の作成経緯などを調べる必要があると判断した。
【引用終わり】

WELQで問題問題視されているのは,大量の記事の引用で構成されていたというモラルの問題よりも,化粧品や健康食品について,効果や効能が保証されているかのような記事を書いたことが,医薬品医療機器法(旧薬事法)に抵触する可能性があるという点だ。

医薬品医療機器法(旧薬事法)では健康や医療について届け出をせず効果・効能を触れ回ると法律違反になる。医薬品医療機器法は,一見,薬事申請をする人達が守らなければならない法律のように思われるかもしれないが,実はそうではなく,薬事申請をしない製品の広告にも縛りをかけていることを一般の企業は知っておく必要がある。

医薬品は医療機器の製造業者は,医薬品医療機器法が広告規制をしていることを良く知っているので,薬事申請していない効果,効能について吹聴するようなことはしない。

医薬品医療機器法(旧薬事法)の広告規制を知らずに,たまに間違いを侵すのは,医薬品医療機器法(旧薬事法)に接する機会がない一般の企業だったりする。

このことは,薬事申請をしていないヘルスアプリついても同じことが言える。薬事申請をしていないヘルスアプリが,「○○を診断できる」とか「○○の疑いを発見できる」とか「○○の改善に効果がある」といった宣伝をすると医薬品医療機器法違反になる可能性がある。○○に病名を入れるとアウトになる可能性が高い。例えば○○に睡眠時無呼吸症候群と入れるとアウトの可能性が高く,病気とはいえないいびきとするとセーフの可能性が高い。解析アルゴリズムが同じであっても,病気を診断できるとか,病気の改善に効果があることを,薬事申請していない製品が広告することを医薬品医療機器法は禁じている。

医師の資格を持った先生に監修してもらったとしてもダメだ。ヘルスアプリとしての効果・効能をはっきりうたいたいのならば,医療機器プログラムとして薬事申請するしかない。その際,「診断できる」というならば,既存の承認製品との同等性を主張するか,独自の臨床評価が必要になる。

人の健康に関連する商品の広告は,病気や健康に不安を持つ人にとって本当ならすがりたい情報になる。だから,その効果・効能に根拠の裏付けがないと国民に不利益をもたらすので国は規制をするのだ。

だから医療機器に搭載されるソフトウェアやそのものが医療機器となるソフトウェア製品に対しても,その安全性を示すための根拠を求める。そのライフサイクルプロセスに関する要求が IEC 62304 だ。

医療機器の製造業者の多くはソフトウェアの一部または全部を外部の協力会社(=サプライヤ)に開発委託しているだろう。

つきあいの長いサプライヤならば,そのソフトウェアが現場でどんな使われ方をしているのか知っているかもしれない。しかし,サプライヤのソフトウェアエンジニアには医療現場をよく知らない者もいるだろう。

だから,医療機器のソフトウェアは,使われる場面を知っている者がバリデーションしなければならない。

ちなみに,2016年10月に IEC 82304-1 ヘルスソフトウェア-第1部:製品安全に関する一般要求事項 という規格が国際規格として公開された。(アイイーシーハチニイサンゼロヨンダッシュワンと呼ぶ)

IEC 82304-1 のプロセスは左図にようになっていて,ソフトウェアライフサイクルプロセスについては IEC 62304 を抱え込むようになっている。

IEC 82304-1 のスコープであるヘルスソフトウェアは

HEALTH SOFTWARE
software intended to be used specifically for managing, maintaining or improving health of individual persons, or the delivery of care.

(参考訳)個人の健康を管理,維持若しくは改善するために又は医療を提供するために使用することを意図するソフトウェア。

となっていて,非常に範囲が広い。汎用ITプラットフォーム上で動作するソフトウェアという条件が付いているが,規制対象の医療機器ソフトウェアだけでなく,規制対象外のヘルスアプリも対象となる。

IEC 82304-1 の附属書A には下記のようなソフトウェアが In Scope の例として示されている。

In Scope の例(規制対象と規制対象外含む)
  • 健康用途のソフトウェア製品
  • 特別なセンサや検出器を使わない機器で動作するモバイルアプリ
  • 検査情報ソフトウェア
  • 放射線科情報ソフトウェア
  • フィットネスセンターの個人用ソフトウェア
  • 受胎調節ソフトウェア
  • コンピュータ支援診断ソフトウェア
  • 医療画像解析ソフトウェア
  • 個人の診断,治療及び健康管理を目的とする臨床診断支援ソフトウェア
  • 電子カルテシステムを含む,電子健康記録システム
  • 病院情報システム
規制対象外のヘルスソフトウェアが IEC 82304-1 に適合しなければいけない縛りはないが,それも世の中が IEC 82304-1 をどのように認知するかによっては,ヘルスアプリメーカにとって強い努力目標となるかもしれない。

なお,単独の医療機器ソフトウェアは,いずれ,この IEC 82304-1 への適合を証明することが要求されるようになる。IEC 82304-1 はソフトウェアライフサイクルプロセスについて IEC 62304 を引用しているので,ここでも IEC 62304 要求を実施する必要がある。

IEC 82304-1 では IEC 62304 には含まれていないバリデーションの詳細な要求が書かれている。

さて,サプライヤは医療機器製造業者からソフトウェア開発の一部のプロセスを委託されているだけだから,IEC 62304 の要求内容を知らなくてもいいのかといえばそうではない。

バリデーションは医療機器製造業者がやらないといけないとしても,IEC 62304 の多くのプロセスがサプライヤに委託されているのならば,サプライヤも IEC 62304 の要求内容を理解していなければ,最終的に規制当局に規格要求を満たしていることが説明できない。

EUでは,MDD(医療機器指令)がMDR(医療機器規制)に格上げされつつある。MDRになると,NB(Notified Body)と呼ばれる第三者認証機関は,非通知審査(Unannounced Audits)を実施することになっている。

非通知審査の対象は医療機器製造業者だけでなく,ソフトウェアのサプライヤも対象になる可能性がある。

ようするに抜き打ちで医療機器製造業者のソフトウェアサプライヤが監査される可能性があるのだ。最初のうちは,ソフトウェアを審査できる人もそうはいないだろうが,審査サイドの規格教育が進んでくれば,あちこちでソフトウェアサプライヤが審査されるようになるかもしれない。

医療機器ソフトウェアをはじめて薬事申請しようと考えている新規参入企業も同じだ。IEC 82304-1 の要求内容を理解しておく必要もあるし,IEC 62304 は自分達はもちろん,サプライヤにも教育しておかないといつ来るかわからない審査や査察に耐えられない。

P.S.

今,Amazon で IEC 62304 実践ガイドブックの なか見!検索 で,ガイドブックの付録のかなりの部分が見られるようになっている(自分だけか?) FDAやCFDAの医療機器ソフトウェアに対する規制要件の内容を見ることができる。