かつて「ISO 26262 との向き合い方」という特集記事を書いていたが、今回はヘルスITについて書こうと思う。本来はこっちの方が自分のフィールドである。
さて、自分とFDA（米国食品医薬品局）との出会いは20年以上前の1990年頃に遡る。かつての担当製品の唯一のソフトウェアエンジニアだった自分は定期査察のために日本を訪れていたFDAの査察官に自作のOSをどのように検証したのかを説明していた。
その説明がまずかったというよりは、FDAが要求するQSRの要求を組織として十分に理解していなかったため（そのときFDAが要求していた設計管理に対する要求やソフトウェアバリデーションの一般原則などを十分に理解していなかった）、自組織はFDAからWarning Letter を受け取り、対象製品がUSへの出荷停止を食らった。
それから数年間、FDAの要求を日本語に翻訳しながら理解し、検証や妥当性確認の作業をやり直し約1年後に再査察を受けて、製品の出荷が再開された。
FDAの査察の洗礼を受けてから約20数年、時は流れて医療・ヘルスケアは訓練を積んだ特別な人達が扱う道具から、IT機器で個人個人の健康管理をする時代になろうとしている。
ITは今、医療の世界も席巻している。ITのおかげで医療機器は「危ないもの」「特別なもの」、医療機器に搭載するソフトウェアは何かあったら大変、素人がおいそれとは触れない、規制で厳しく縛られている特別なものという狭い範囲に押し込めることができなくなっている。
1980年代当時から、US FDA はフィールドで起こった医療機器や医療機器ソフトウェアにまつわる事故を調査し、その研究結果を規制に反映させて、事故の再発を防止するための取り組みをしていた。その取り組みは現在も続いており、医療機器ソフトウェアに関する事故防止の研究は世界一進んでいると思う。
FDAは世の中の流れに合わせて規制要件を柔軟に変化させる。ソフトウェアは試験方法だってこうすれば絶対安全というものはないし、合否判定基準だって決めるのが難しいのに、規制することなど不可能だと思うかもしれない。しかし、FDAは実際にソフトウェア絡みの事故が減らないとみると何とかして、事故を減らすための規制方法を考えてくる。
そのうまいやり方の一つがガイダンスによる実質的な規制だ。FDAは、規制すべき事柄が生じると、すばやくドラフトガイダンスを発行する。ちなみにFDAが発行するガイダンスはすべて無償で公開されている。買わなくてもいいということは、読まなければいけない者が読んでいないのは読み手側の怠慢ということになる。
ドラフトガイダンスは「ドラフト」だから、規制に使われないと思ったらそれは間違いで、裁判で有効性を主張することはできないかもしれないが、規制対象となっている場合は市販前の申請が必要であり、市販前の審査のときにドラフトガイダンスに適合しているかどうかは聞かれる。対応していないからといって審査を拒否することはできないが、ドラフトガイダンスでも必ず「要求を満たしているか」聞かれる。ドラフトレベルでも実質的には適合を要求しているといっていい。
そして、実際に運用をしてみて規制当局側として「使えそうだ」と判断したら、パブリックコメントを募った上で正式なガイダンスにする。それでも「ガイダンス」だから法的拘束力があるわけではない。
例えば、2002年版のソフトウェアバリデーションの一般原則
This document is intended to provide guidance. It represents the Agency's current thinking on this topic. It does not create or confer any rights for or on any person and does not operate to bind Food and Drug Administration (FDA) or the public. An alternative approach may be used if such approach satisfies the requirements of the applicable statutes and regulations.
本文書は、ガイダンスを提供することを意図している。この話題に関するFDAの現在の考えを表している。この文書は何人に対して、もしくは何人の上に何らかの権利を定めたり授けたりするものではなく、FDAや民衆を縛り付ける働きをするものではない。もし何らかの代替のアプローチが適用される法令や規則の要求事項を満たすものであるならば、それも使用可能であろう。この文言は常套句となっていて、ガイダンスの先頭に必ず□で囲って記載されている。この文言の意味は「このガイダンスは法的な規制や要求を満たすことで権利が生じるようなものではない」「法規制の要求を満たすことができるなら、ガイダンスに書かれていること以外の代替えアプローチを使うことも可能」ということだ。
しかし、そうは言うものの、市販前審査や査察ではガイダンスへの適合を聞いてくる。そこで代替えアプローチを主張するためには、ガイダンスの要求内容を熟知した上でディベートに勝つだけの力量が必要だ。大抵の場合、特に日本の組織はそのような気概はないので、ガイダンスに素直に従う。
こうやって、ガイダンスの冒頭で断りを入れておいて、実質的な要求内容を突きつけて、実質的に効果がありそうなら、ガイダンスをドラフトから正式なものにする。これがFDAの実践的規制アプローチなのだ。
この方法は一見「ずるい」ようにも見えるが、柔軟性があり、事故を減らすのに有効に働いていると思う。変化が早い世の中の動きに対しても素早く対応することができる。
例えば、今話題になっているのが モバイルメディカルアプリケーションガイダンス
このガイダンスは2011年7月21日にドラフトとして発行され、2013年9月25日に正式なガイダンスとなり、つい最近2015年2月9日に一部改訂された。
2014年1月31日のニューヨークタイムズの過去の記事によると、米食品医薬品局（FDA）の公開カレンダーに、オペレーション担当シニアバイスプレジデントのJeff Williams氏やソフトウェアテクノロジ担当バイスプレジデントのBudd Tribble氏を含むAppleの著名な幹部陣が2013年12月、FDAと会談し、会談の話題は「モバイル医療アプリケーション」だった、と公開カレンダーには書かれていたそうだ。
その会談の結果が、モバイルメディカルアプリケーションガイダンスの法規制しない側の分類に含まれたであろうことは容易に想像できる。
なぜ、このガイダンスが話題になっているか。それは、スマートフォンやタブレットに搭載される健康関連のソフトウェアすなわちヘルスソフトウェアが大量に市場に溢れてきて、中には法規制対象と言えるようなアプリもあり、大小様々な事故、インシデントが発生しており、野放しにしておくと健康被害に至る可能性が出てきており、FDAが規制（又は規制しないという表明）に乗り出したからである。
しかし、モバイルメディカルアプリケーションはさまざまな種類、用途、形態がある。規制するのは極めて難しいと思われていたので、FDAがどのようなアプローチを取るのか注目された。
その答えは、A：医療機器に該当しないモバイルアプリと B：医療機器の定義に適合するかもしれない規制しないでおくモバイルアプリと C：規制対象となるモバイルメディカルアプリ に分けるということだった。
これらの具体例は Appendix に掲載されている
Appendix A Examples of mobile apps that are NOT medical devices
Appendix B Examples of mobile apps for which FDA intends to exercise enforcement discretion
Appendix C Examples of mobile apps that are the focus of FDA’s regulatory oversight (mobile medical apps)
この意味は、「このモバイルアプリは医療機器の定義に該当するかもしれないが、FDAが取り締まりの執行を実行するかしないか決める権利を使って規制しない」ということである。
ようするに白と黒の間にグレーゾーンを設けて、グレーの存在を認めた上で、規制の対象から外したのだ。ただ、グレーゾーンに位置するアプリは、規制から外れているものの、執行裁量権を使って外されただけないので、市場で健康被害を起こしたら規制の執行は行われる。
危なそうなものはグレーゾーンに指定しておき、問題が起これば黒に分類するという上手いやり方と言える。
アメリカがモバイルアプリをガチガチに規制しないで段階的なアプローチを取っているのには、そうしなければいけない背景がある。
米国の医療IT推進の取り組みとTITECH法
この背景を知るにはJETRO/IPA の和田恭さんが書いたレポート「米国における医療分野の IT 導入に係る動向」が参考になる。オバマケアの取り組みの中に電子健康記録 EHR
整備を進め、医療分野の IT 化は進めようとしている。190億ドル規模の事業だ。
米国も日本と同様に医療関係費用が国民の負担となっており、高騰する費用から発生する無保険者の増大と医療費の抑制が課題となっている。
全医療費に対する政府負担割合は合計 50%に上っている。これを受けて、医療費用削減にむけたインセンティブを盛り込んだ医療保険改革が進められており、医療サービスの質の向上、重複検査や医療過誤の排除などを進め、医療費の削減に寄与するものとして、医療 IT の導入が位置づけ
られ、推進されている。
ここまでなら「日本も国として医療ITの導入・推進の旗振りができないのか」といった皮肉で終わるのだが、アメリカはこの政策が単なるスローガンではなく、本当に実現しようとしているところがすさまじく、日本は遙かにおよばないと思う。
ブッシュ政権は、2004 年 4 月、医療 IT の導入と促進を目的とした、「医療 IT イニシアティブ＇Health Information Technology Initiative（」を立ち上げた。同イニシアティブでは、①医療の質の向上、②医療コストの削減、③医療ミスの防止、④医療データの管理コストの削減などを目的に掲げ、「向こう 10 年以内＇2014 年まで（に、国民のほとんどが電子健康記録＇EHR（を持つと共に、各自が自身の EHR にアクセスできるようにする」ことを具体的な目標としている。
その後、オバマ政権でもこの目標は引き継がれ、米国再生・再投資法＇ARRA（のうち、医療 IT 関連部分が、「経済的および臨床的健全性のための医療情報技術に関する法律＇Health Information Technology for Economic and Clinical Health Act：HITECH 法（」であり、①医療 IT の促進、②医療 IT の実証、③インフラ等に対するグラントと融資の提供、④プライバシー保護を巡る取り組み、の 4 点に関する条文が盛り込まれている。
医療ITの導入は①医療の質の向上、②医療コストの削減、③医療ミスの防止、④医療データの管理コストの削減 が目的だから、規制する側も単純に危ないから規制すればよいというアプローチではすまなくなる。
安全でかつ上記の目的を満たすための医療ITの促進をしなけばならない。
こういうときにアメリカは、考え方=原則=Principal を示して、関係者が全員でその原則を共有し、その原則に沿って個々に行動する。
それが2014年4月に発行された34ページの FDASIA Health IT Report
具体的な方法論は書いていないが、目的を達成するための考え方、ソフトウェアの品質確保とリスク低減の両立について、システムで運用するITの中の医療用ソフトにおいて、効果を引き出しながら安全を確保するための方針が書かれている。
特集記事ではこのFDASIA Health IT Report の内容を紹介するとともに、そこに書かれていることは何を意味するのか、日本のヘルスソフトウェア産業にも役に立つのかどうかを考えていきたい。
そして、この特集記事は特の自動車ドメインの方達に読んでいただきたいと思っている。FDAをはじめ、医療機器ドメインでは、利用者のリスクを下げるためのアプローチを現実に発生する事故に向き合いながら進めてきた。
自分は、そのアプローチを今自動車ドメインで進めている機能安全のアプローチは考え方が異なると思っている。その違いは何なのか、ヘルスケアの領域のソフトウェアをどう取り扱おうとしているのかを FDASIA Health IT Report を読み解くことによって、一緒に考えていただきたい。
FDASIA Health IT Report
目次：Table of Contents
1. EXECUTIVE SUMMARY
2. BACKGROUND
2.1. Introduction
2.2. Overview of Agencies (FDA, ONC and FCC)
3. HEALTH IT: LIFECYCLE AND SOCIOTECHNICAL SYSTEM CONSIDERATIONS
3.1 Health IT Product
3.2 Sociotechnical
4. REPORT SCOPE AND FOCUS OF THE PROPOSED STRATEGY AND RECOMMENDATIONS FOR A RISK-BASED REGULATORY FRAMEWORK
4.1 Administrative Health IT Functionality
4.2 Health Management Health IT Functionality
4.3 Medical Device Health IT Functionality
5. PROPOSED STRATEGY AND RECOMMENDATIONS FOR A HEALTH MANAGEMENT
HEALTH IT FRAMEWORK
5.1 Promote the Use of Quality Management Principles
5.2 Identify, Develop and Adopt Standards and Best Practices
5.3 Leverage Conformity Assessment Tools
5.4 Create an Environment of Learning and Continual Improvement
6. ADDITIONAL CLARITY REGARDING CURRENT AGENCY FUNCTIONS.
7. MECHANISM FOR CONTINUED AGENCY INTERACTIONS
7.1 Tri-Agency Collaboration
7.2 Ongoing Stakeholder Engagement
8. SUMMARY AND CONCLUSIONS
0 件のコメント:
コメントを投稿