大丈夫ですか？ あなたのヘルスソフトウェア
総務省は，65歳以上の高齢者人口の総人口に占める割合が27.7%になったことを敬老の日の9月18日に公表しました。景気の先行きが見通せない社会情勢の中，底堅く需要が見込まれる医療や個人の健康管理を目的としたシステムやサービスを経営の新機軸としようと考える企業が増加しています。スマートフォンアプリを入り口にして，IoTを活用しながらデータ集約して，ビッグデータを使って個人に有益な健康支援を行う，こんなビジネスを思い描く人も多いかもしれません。
しかし，このような個人の健康を管理したり，医療情報を扱ったりするソフトウェア（=ヘルスソフトウェア）に落とし穴はないのでしょうか。ヘルスソフトウェアにバグがあったら，速やかに修正プログラムを提供すればよいのでしょうか。医療や健康の分野は，そんなに簡単に新規参入できる業界なのでしょうか。また，ヘルスソフトウェアを開発，販売する中で，知っておかなければいけない法律や規制はあるのでしょうか。そういった疑問をクリアにするためには，ヘルスソフトウェアの開発者は，規制対象と規制対象外の境界がどこにあり，その違いは何なのかを事前に理解しておく必要があります。
個人の健康を管理，維持，改善するためのヘルスソフトウェアは，医療機器を規制する医薬品医療機器等法（医薬品，医療機器等の品質，有効性及び安全性の確保等に関する法律）の規制の対象ではないとされています。例えば，日常的な健康管理のために個人の健康状態を示す計測値を表示したり，個人記録管理用としてグラフ化したりするアプリケーションソフトウェアがその一例です。（ ※1 参照：厚生労働省通知「プログラムの医療機器への該当性に関する基本的な考え方について」）
ただし，厚生労働省の通知では，ヘルスソフトウェアが規制対象の医療機器に該当するかどうかは，次の2点を考慮しなければならないとあります。
[1] プログラム医療機器により得られた結果の重要性に鑑みて疾病の治療、診断等にどの程度寄与するのか。
[2] プログラム医療機器の機能の障害等が生じた場合において人の生命及び健康に影響を与えるおそれ（不具合があった場合のリスク）を含めた総合的なリスクの蓋然性がどの程度あるか。
これらの条件を分かりやすく言い換えれば，「①疾病の治療や診断に寄与するのかどうか」また，「②ソフトウェアに障害が生じた場合，健康に影響を与えるリスクがあるのかないのか」について考慮する必要があるということになります。
現在，規制対象ではないヘルスソフトウェアを製造販売している会社，または，これから新規にヘルスソフトウェアの開発を計画している企業は，自分達の製品に対して①についてどのようなスタンスを持っているか，また②についてどこまでリスク分析できているかを明確にしておく必要があります。
①②の条件を明確にしていなかったために，問題が起こってしまった例を見ていきましょう。
事例1：開発初期では疾病の治療や診断に寄与しないつもりであったが，販売プロモーションにおいて治療や診断の効果を強調してしまった例
開発初期では，医療機器としての規制対象ではないと考え，その製品は個人の健康を管理，維持が目的であり，医療機器に該当する治療や診断，予防は行わないとしてヘルスソフトウェアの開発をはじめたものの，開発を進めていくうちに「臨床的にも効果があるのではないか」，「診断はできないまでも疾病のおそれ」を提示してもいいのではないかと，当初の開発コンセプトが揺らぐケースがあるかもしれません。
ソフトウェア製品を多くのユーザーに買ってもらいたい企業のセールス担当は，ヘルスソフトウェア製品に少しでも効果や効能と言えるものがあるのならば，それをできるだけ大きく宣伝したいと考えます。その時，医療機器として認証等を取得していないヘルスソフトウェアについて疾病の治療や診断に対する効果効能を宣伝してしまうと，医薬品医療機器等法違反となってしまう可能性があり，ヘルスソフトウェアを使用した疾病の治療や診断により患者に健康危害を与える可能性があり ます。
ヘルスソフトウェアを開発する際には，その製品が「誰が，何を，いつ，どこで，なぜ，どのように使用するのか」を意図する使用(Intended Use)として定義し，意図する使用がヘルスソフトウェア製品のライフサイクルの中で変化していないかどうかを監視する必要があるのです。
事例2:規制対象外のヘルスソフトウェアでも，何らかのリスクがある例
一般的な電子カルテや処方のオーダリングシステムは現在，日本では医療機器としての規制対象にはなっていません。しかし，処方オーダリングシステムの画面から、処方する医薬品の名前、投与量（用法・用量）、投薬日数などを入力して確定し，その情報が薬局に電子的に送られて、この情報をもとに調剤が行われ，患者に投与されるという情報の流れの中で，情報の取扱や伝達に問題があった際，患者の健康被害に至る可能性があります。規制対象外のヘルスソフトウェアだからといって，何もリスクがないとは言い切れません。規制対象外のヘルスソフトウェアであっても，どんなリスクがあるのか，どんなリスクを想定して受容できるとしたのかといった，リスクマネジメントの根拠を残していくことが重要です。
また，開発当初にはリスク分析やリスクコントロール手段が執られていても，ソフトウェアシステムに機能の追加や変更を加えることによって，新たなリスクが生まれることもあります。健康情報や医療情報を扱うソフトウェアの開発，保守においてはリスクマネジメントを継続していなければ，新たなリスクに対応することができません。
規制対象外のヘルスソフトウェアであっても，お客様から挙がってくるソフトウェアシステムの障害情報の中に，ヒヤリ・ハットするような事象があると思います。それらのヒヤリ・ハットの事象はリスク分析や根本原因分析を行って，再発防止の対策をリスクマネジメントの一環として実施しておく必要があります。
事例3:個人の健康管理が目的のヘルスソフトウェアでもリスクがある例
自分自身でも日々の健康管理が求められる糖尿病患者の場合，医療機関で測定するヘモグロビンA1C（HbA1C）で，過去1～2ヶ月の血糖コントロール値を推し量ることができますが，日々の血糖値や食事，運動，インスリン投与との関連を継続的に記録した結果を管理できるヘルスソフトウェアであれば，その情報を医師が診たいと思うかもしれません。このような糖尿病患者の健康情報を継続的に記録するスマートフォンアプリは，患者が通院時に医師にそのデータを見せて，診断のインプット情報とすることをヘルスソフトウェアの開発企業が意図している場合もあるでしょう。この場合，ヘルスソフトウェアは医師が診断に使用することを意図した医療機器となります。そして，ヘルスソフトウェアに潜在的な不具合（例えば，記録した血糖値が実際よりも低く記録されるなど）があると，医師が誤った診断をするリスクがあるかもしれません。
近年，体にセンサを装着して間質液と呼ばれる体液のグルコース濃度を測定することで長時間にわたり患者の血糖値を推定する機器が発売されています。この機器では，患者の上腕部に貼り付けたセンサから近距離無線通信で測定値をリーダー端末に送信することができ，小型のリーダー端末により患者は測定値を確認できます。このリーダー端末は医療機器として承認を受けており，個人で使用する際には，「インスリンの投与量の変更は医師の指示に従う必要がある」という注意表記があります。
このように，医療情報を記録し，管理するヘルスソフトウェアであっても，その情報を診断や治療への寄与を意図するヘルスソフトウェアの場合は，医療機器としての規制の対象となり得ます。その意図する使用（Intended Use）により何らかのリスクを生じさせる可能性があるということです。一般的に効果効能とリスクは表裏一体の関係にあると考えられ，効果効能が高ければ高いほど，健康に対するリスクも大きい場合が多いと言えます。健康に関する効果効能がなければ，ヘルスソフトウェアに障害が起こったときの患者が被るリスクも低いかもしれませんが，そのソフトウェアの価値をユーザーに訴求する力も弱くなります。
ユーザーは自分や家族の健康に対して守らなければならないこと，改善しなければいけないことがあるとき，ヘルスソフトウェアがその目的に役立つと納得したときに，はじめてヘルスソフトウェアに価値を見いだすのではないでしょうか。
そして，ヘルスソフトウェアの開発者は，ヘルスソフトウェア製品の機能や性能を高める変更を継続的に行うことにより，ユーザーに対して高い価値を提供しようとします。しかし，そのとき，ヘルスソフトウェアの開発当初には想定していなかった意図する使用が，ソフトウェアの改変によって変化し，それに伴い新しいリスクが生じているかもしれません。
事例4：相互運用性の要求により，想定していなかった使われ方をする例
IoT(Internet of Things) が話題になり，多くの機器が相互に通信して新たな価値を生み出す社会が進みつつあります。医療機器やヘルスソフトウェアの世界でも，機器やシステムを単独で使用する方法から，機器やシステムをネットワークでつなぎ，それらから得られる情報によって，治療，診断，予防に対する新たな価値を探る動きがあります。これは医療機器や医療情報の相互運用性（Interoperability）と呼ばれ，通信規約等の標準化やそれによる望まない結果を抑制するための規制基準の制定が急がれています。
このような，医療機器や医療情報，ヘルスソフトウェアの相互運用（Interoperability）が進むにつれて，ネットワークでつながれた機器の情報が，機器やソフトウェアシステムの製造業者が意図していない使われ方をする可能性が出てきます。例えば，個々の医療機器や医療情報システムから集められた一人の患者の情報を1つの画面に集約して表示させたとします。これらの情報を診断に使おうとした場合，個々の情報を計測した実時間を調べて，計測時間を表示したり，時間のずれを調整したりする必要があるかもしれません。なぜなら，患者のバイタルサインは刻々と変化しており，時間軸に対して情報の整合性を取らないと正しい診断ができないからです。数十秒，数分の時間的なずれが，患者の安静時の場合には，あまり問題なかったとしても，手術中など患者の様態が急激に変化する場合は，大きなリスクになる可能性もあります。
医療情報における相互運用性（Interoperability）においても，その情報がどんな意図で使われるのかを想定して出力をしているのかを定義した 情報の意図する使用（Intended Use）の定義と，その意図通りに医療情報が使用されているかどうかを，相互運用の視点で監視し，どのようなリスクが存在するかをチェックするリスクマネジメントが必要になります。
意図する使用(Intended Use)の定義とリスクマネジメントの技術を身につける
事例1, 2, 3, 4 のいずれにおいても，変更しやすい，変更されやすいヘルスソフトウェアの意図する使用をきちんと定義し，その意図する使用に基づいて，製品のリスク分析及びリスクコントロール等のリスクマネジメントを行うことがヘルスソフトウェアの開発企業に求められます。これを実行する知識，技術，スキルは，一般的なソフトウェア信頼性の向上技術，管理技術とは異なる性質のものです。
ソフトウェアの信頼性が高ければ，不具合はなく，リスクは常に受容できるのか，そんなことは，ありません。ヘルスソフトウェアの設計，開発，管理においては，完全なソフトウェアは存在しない，バグを無くす努力はするものの何かしらのバグは残存しているかもしれず，潜在的にバグがあったとしても，健康被害につながらないようにするには，どのようなリスクがあるか分析・評価し，リスクコントロール策が必要かを特定し，そのリスクコントロール策を確実に実施することが求められます。
GHSヘルスソフトウェア推進協議会は，これらの知識，技術を習得するための第6回 リスクマネジメント・トレーニング講座を 2017年10月16日（月）に東京新橋のJAHISにて開催します。
本講座では，仮想のスマートフォンに搭載することを想定した糖尿病管理アプリの意図する使用（Intended Use）を定義した上で，意図する使用に基づいたリスク分析を各種専用シートを使いながら，のべ200分に渡るグループ演習を通じて，ヘルスソフトウェアのリスクマネジメントの知識，技術を習得していきます。
（※ 本講座では，過去3年間にのべ約100社、200名のソフトウェア技術者，品質保証担当，経営者等が受講し，GHSから修了証が発行されています。）
リスクマネジメント・トレーニング講座（第6回）
場 所 保健医療福祉情報システム工業会（JAHIS）
東京都港区新橋2-5-5 新橋2丁目MTビル 5階
参 加 費 27,000円／人（消費税込み）
定 員 40名
対 象 GHS開発ガイドライン Level-1 を目指す方。
リスク分析・リスク評価の技術を習得したい方。
本セミナは好評につき，募集を締め切りました。
参照
リスクマネジメント・トレーニング講座で使用される資料例
- ヘルスソフトウェア用特質の明確化シート
- ヘルスソフトウェア用リスク分析表
- ヘルスソフトウェア市販後事例分析書
- 各種リスク分析結果事例