3. 用語の定義
本ガイドラインの中では、用語を以下の意味で用いる。
3.1.
プログラム（program）
電子計算機に対する指令であって、一の結果を得ることができるように組み合わされたもの
（出典：医薬品医療機器等法第２条第２項[2]）
3.2.
ソフトウェア (software)
計算機の処理に関わる情報で、ハードウェア（物理的な機械、装置）に対比して用いる広い概念を指す用語。場合によってはデータ、文書等も含む
注記 本ガイドラインでは、ハードウェアに対比される広い概念の情報を指す場合のみソフトウェアとして、その他の場合はプログラムの用語を用いることとした。
3.3.
医療機器プログラム (Software as Medical Device, SaMD) 医薬品医療機器等法上の医療機器に該当するプログラム
注記 1 英語では Software as a Medical Device (SaMD)と称されることから、医療機器ソフトウェアと称されることもある。
注記2 「医療機器プログラム」は、プログラム単体として流通する製品を、「プログラム医療機器」は上記に加え、プログラムを記録した記録媒体も含むものを指している[12]。
3.4.
行動変容を促すプログラム( SaMD in medical and healthcare fields to promote behavior change)
健康又は医療の目的のため、個々のユーザに応じて情報提供を行うことでそのユーザの行動の変容を促すことを意図するプログラム
注記 1 令和 4 年 6 月 9 日付薬生機審発 0609 第 1 号, 次世代医療機器評価指標の公表について 別紙 2 行動変容を伴う医療機器プログラムに関する評価指標[15]では、「医師の指導の下で使用され、個々の患者等に応じて情報提供することで患者等の行動変容を促す医療機器プログラム」を対象としているが、本開発ガイドラインではより広い使用範囲を対象としている。
3.5.
機能モジュール (functional module)
医療機器又はヘルスケア機器（非医療機器）に該当する機能を持つ、独立して流通可能な単位
3.6.
（医療機器）機能モジュールアプローチ (functional module approach)
プログラムを機能モジュール単位で提供することで、医薬品医療機器等法の規制の要件を満たすべき部分をそのモジュールに限定しつつ、ユーザから見て一体として動作するシステムの開発・実装方法
3.7.
医療従事者(certified medical professional)
本ガイドラインで対象とする製品の使用を患者等に指導するなど、専門的な教育を受けて知識や技能を持ち、医療に携わる人
例 医師、歯科医師、看護師
3.8.
標榜 (labeling)
（医薬品や医療機器の分野で）対象とする製品の特長や効果・効能等を主張したり表明したりすること
注記 1 医療機器としての使用目的又は効果を標榜できるプログラムは、医薬品医療機器等法の製造販売承認又は製造販売認証を受けたプログラムのみとなる。
注記 2 一般的には「主義・主張などをはっきりと掲げ示すこと（デジタル大辞泉）」という意味を持つ。
＜補足＞
本ガイドラインが対象とする製品に関連する用語として「介入」、「エビデンス」がある。これらの用語は、様々な意味合いで用いられることから、読者により解釈が異なる可能性がある。製品開発や製品説明等の際にこれらの用語を用いる際は、どのような意味合いを持つのかの検討、確認が必要となる。以下に、「介入」、「エビデンス」の定義の一例を示す。
介入
研究目的で、人の健康に関する様々な事象に影響を与える要因（健康の保持増進につながる行動及び医療における傷病の予防、診断又は治療のための投薬、検査等を含む。）の有無又は程度を制御する行為（通常の診療を超える医療行為であって、研究目的で実施するものを含む。）をいう。（出典：人を対象とする生命科学・医学系研究に関する倫理指針 （令和 4 年 3 月 10 日一部改正））エビデンス
1. 証拠。証言 2. 医学で、臨床結果などの科学的根拠。その治療法がよいとされる証拠
（出典：デジタル大辞泉）
4. 開発の留意事項
4.1. 留意事項の構成
事業戦略上明確にすべき事項と設計開発する上で留意すべき事項について、製品概要と目標の設定、目標に対する現状の入力、現状を目標に近づける働きかけ、その他に分けて示す。行動変容する上で、目標を設定し、現状が目標に近づくように働きかけるのが一般的なプロセスであるため、それぞれに分けて留意事項を示した。
4.2. 製品概要
製品概要の目的
製品を開発する上で、どのような背景でどのような目的で、誰を対象にして、どのように使用されるのかを明確にする必要がある。これらを明確にする際に整理すべき情報を以下に例示する。
背景
対象とする製品の開発着手に至った背景や特徴を含め整理する。
【一例】
- 食事療法を促進・継続するためのプログラム
生活習慣病を有する患者が、自分の状態や食事量などを記録し、記録した情報から患者個人に最適化された食事内容を提示することで、適切な食事療法を継続的に行う。
- 睡眠障害治療のための日常生活管理プログラム
不眠症の患者において睡眠に関わる生活習慣および睡眠状態を記録し、その情報に基づき、独自のアルゴリズムで作成されるアドバイスによる生活習慣の改善を行い、不眠症状の緩和を行う。
- 心臓リハビリテーション用プログラム
適切な強度の運動負荷は心血管疾患患者において疾病の改善、QOL 向上、再入院予防につながることから、心血管疾患患者において運動内容、心拍数・血圧を記録し、その情報から適切な運動内容を独自に生成し提示する。
使用目的・用途
前述の背景から、対象とする製品がどのような目的で、どのような用途を提供するのかを整理する。
【一例】
- 高脂血症の治療の一環として体重の減少を支援する。
- 高度肥満症患者の治療の一環として、体重の減少あるいは維持により、重症化を予防する。
- 患者の毎日の血圧などの情報を記録し、患者の収縮期血圧の平均値の変動を医療機関にて確認できるようにする。また、予め設定した値よりも高い数値が測定された際は、アラートが出る。
- 高度肥満症患者の治療の一環として、運動プログラムや食事メニューの候補を提示する。
- 心臓リハビリテーションのために、運動をしている際の心拍数や血圧を測定・表示し、
運動強度を計算する。
ユーザと使用状況
誰がどのように使用するのか、使用する人の属性や、使用状況を把握する。製品のユーザを検討する際の項目を以下に例示する。なお、本ガイドラインでは、行動変容を起こす主体者がユーザである事例を多く挙げているが、必ずしもそのように限定するものではない。例えば、子どもの受診勧奨のために保護者にメッセージを表示したり、家族の健康的な食生活や運動習慣のために、食事のレシピや運動メニューを提案するなどの間接的なアプローチによる行動変容のあり方も考えられる。
【検討すべき項目】
- 医師からの指導や推奨なしに、個人が自発的に使用するものか。個人が使用するものの場合は、特定の疾患等の有無を対象としているのか。
- 医療機関やサービス事業者での使用か。その場合は製品を使用するのは誰か。例えば、医療従事者、サービス提供者、患者、健常者、等。
- 医師の監督下での使用か。医師の指示や指導に基づくものか。
行動変容の機序
行動変容を起こす仕組みについて明確にする。どのような対象者に対して、プログラムがどのような働きかけを行い、行動変容を期待するのか、明らかにする。以下に例示する。
【一例】
- 肥満症の患者に対して、日々の体重と運動量を記録し、体重と運動量に応じた食事指導をすることにより、適切なカロリー量の食事を摂るようする。
- 禁煙治療中の患者に対して、患者から入力されたデータに基づき、独自のアルゴリズム
で生成した行動のアドバイスを示すことで、ニコチンに対する心理的依存を緩和する。
開発する製品と、既存の治療法及び診療ガイドライン等の関係
開発する製品が、既存の治療法や診療ガイドライン、既存の製品（類似医療機器）に対して、どのような部分が一致し、どのような部分が異なるのかなど、製品の位置付けについて整理を行う。現状の医療に対して、当該製品が何を解決できるのか、項目毎に差分を示すことで整理が可能である。
（※以下に示すのは、比較を行う為の例であり、適切さを示すものではない）
表省略
4.3. 目標の設定
目標とサブ目標
ユーザが製品を使用する際に、製品の目的を達成するための目標を定める場合がある。この目標には、ユーザが製品の使用により目指すべき目標と目標に至るまでのモチベーション維持や進捗確認としてのサブ目標に分けて考えることができる（図２）。サブ目標への分割は、想定される使用期間などで目標を按分する場合や、開発者のノウハウに基づき独自に設定する場合など、様々な方法がある。
目的を達成するための目標やサブ目標の設定については、製品の特性や開発者の考え方によるため、必須というわけではない。仮に目標やサブ目標を設定する場合は、開発着手時点では、目的と目標、サブ目標の間には少なくとも何らかの関連性が、例えば先行研究などを参考に、見込まれることが重要である。なぜならば、医療機器として最終的に承認取得を考えた場合、サブ目標が達成されれば目標達成に近づき、目標が達成されれば目的が達成されることを、科学的な機序に基づいて、高い蓋然性をもって示すことが求められるからである。
図2表１省略
目標の設定と根拠
目標の設定方法には、プログラムにより固定提示する方法、選択式やレンジを示してユーザが入力する方法、項目だけ示してユーザが入力する方法などがある。
プログラムにより提示する目標や選択肢は、意図する目的に対して妥当性のある条件や根拠に基づき決定する。決定に用いた基準や条件、資料などは、整理・明示できるようにしておくと、医療機器としての承認申請時や上市後に、使用目的や効果の合理性を示すための根拠として、あるいは製品のユーザに対する説明資料等としても役立つだろう。
目標を定める際の根拠や条件は、ユーザや開発製品が独自に設定する場合や、広く周知されているガイドライン等から引用されるものがある。
なお、目的に対する目標や目標に対するサブ目標は、目標等の達成に効果があるとみられる量や内容が示されるものであるが、効果は対象とする分野でそれぞれ異なり、中にはその量が増えた、減ったではなく、維持ができたという効果の出し方もある(例えば、体重)。
また、行動変容を促すプログラムに限った話ではないが、一般的に、医薬品や医療機器で効果があったという場合は、一定数の母集団において、当該医薬品や医療機器を使用した群で、それを使用しなかった群に比べて統計学的に効き目が見られたということを指している。そのため、サブ目標が達成されれば目標の達成に近づき、目標が達成されれば目的が達成されることが科学的に関連付けられていて、かつ、一定の母集団内で統計学的に示されたとしても、個々人のレベルで見た場合には、そのようにならない事例も存在する可能性がある。言い換えれば、一定の母集団内では統計学的に効果があった場合でも、その母集団の中の個々人で見れば効果があった人もなかった人もいる。そのため、製品の効果の標榜や広告宣伝においては留意が必要である。
なお、医療機器の広告においては、具体的な効果や安全性を示して、それが確実であることを保証するような表現はできない（平成 29 年 9 月 29 日付薬生監麻発 0929 第 5 号「医薬品等適正広告基準の解説及び留意事項等について」) [16]。医療機器ではない場合において
も、消費者保護の観点から、当該効果等を期待させるような虚偽誇大表示や著しく優良であると誤認させる表示は禁止されている（不当景品類及び不当表示防止法）(4.6.1 効果の標榜、広告規制についても参照のこと)。
【根拠や条件の例】
- 既存論文等や公知のガイドライン等から引用する場合
学会等の診療ガイドラインで示された数値
一般的な集団（年齢、性別等）の代表値(個別のユーザの数値に関して言及するものではなく、集合体内での平均化された数値)：健康な 50 代男性の血圧は平均●● mmHg など。
- ユーザの状況に基づき医師等が目標値を提示する場合
- 独自のアルゴリズムやノウハウを用いる場合ユーザの入力情報や臨床データ等を基に独自のアルゴリズムで目標値を推奨・設定する。
なお、医療機器としての承認取得を考えた場合、独自のアルゴリズム等の内容について、機械学習などを用いた場合にはブラックボックス化する部分があることは避けられず、全てを明らかにするのが不可能な場合もある。しかし、推奨・設定された目標値が妥当であることについては、何らかの科学的な根拠に基づいて明らかにすることが求められるであろう事から、検証のための根拠資料の準備が必要であろう。逆に、検証のための材料がないアルゴリズムである場合、その妥当性の説明は困難にならざるを得ないと考えられる。
目標の指標
目標の指標の種類として、定性と定量がある。同じ目標でも、定量的に示すのか、定性的に示すのか、目標をどの程度細かく分けるのか、その粒度など、様々な提示の仕方がある。
1) 目標の指標
入力されたデータもあれば、入力値を元に演算した結果もある。
表２：目標の指標の例
表省略
2) 目標の分割の方法、サブ目標への分割の考え方
目標を分割し、より実行しやすいレベルに落とし込んでいくことが考えられる。段階的な目標を定める例として、以下がある。
目標設定
- 減量の数値目標の具体化
メタボリックシンドローム改善の場合、6 か月で体重の 3～5%減量することで効果が期待できること、いったん体重を減量した後は、その維持が大切であることを説明する。また、その後の効果の継続のためには、初期の体重減少の実感が大事である。
- 自己決定の促し
日々の生活の中で実行でき、また継続できるよう、より具体的な目標を設定できるよう促す。
対象者が考え、自己表現できる時間を大切にする。
- 行動化への意識付け
目標達成に対する自信を確認し、達成のために障害となる場合を想定した対処法を対象者と共に考える。
設定した目標を見やすい場所に明示しておく等、行動化への意識付けを促す。
設定した目標を家族や仲間に宣言することを促す。
セルフモニタリングの意味と効用を説明する。
- 社会資源・媒体等の紹介
具体的な支援媒体、記録表、歩数計等を紹介し、可能であれば提供する。
健康増進施設や地域のスポーツクラブ、教室等のプログラムを紹介する。
地域の散歩コース等を消費エネルギーが分かるように距離・アップダウンを含めて提示する。
地域の教室や自主グループ等を紹介する。
地域の中で栄養表示やヘルシーメニューを提供している飲食店等が分かるような情報があれば提供する。
表：危険因子と生活習慣改善の方法（優先度が高い順に◎→〇→△）
表省略
3) 目標の決定・粒度の例
2)で示した標準的な健診・保健指導プログラム等では、基本的な考え方や優先順位は示されるものの、詳細な個人ごとの目標ブレイクダウンについて記載されているわけではない。
目標設定時の留意事項として、国立保健医療科学院で実施された研修[18]では、自己決定による設定、数値化、2～3 つに絞る、セルフモニタリングに関する項目を 1 つは入れる、「実現可能な」目標にさせる等が示されており、継続させるための工夫として、「段階的に行動目標を設定」「短期的に確認できる」等も併せて示されている。
これら原則を踏まえた目標分解の仕方として、下記のようなものが考えられる。
「○ヶ月で×～△％減量する」
→ カロリーの収支をマイナスにする
→ カロリー摂取を減らすための目標
→ 食べる時の調理方法や食品の変更
→ 間食や一回当たりの食事量削減
→ カロリー消費を増やすための目標
→ 日常行動で運動量を増やすものに変更（階段使用等）
→ 短時間で実施可能な活動目標の提示
このように目標を分割する方法は、ユーザのアドヒアランスを高めるための工夫のひとつとしても用いられる。アドヒアランスを高める工夫については「4.6.2 アドヒアランスを高める工夫」を参照いただきたい。
4.4. 目標に対するユーザ情報の入力
入力の種類
ユーザによる入力手段の種類には、以下のようなものがある。各々の特性と使用上の留意点についてまとめる。
表３：入力手段の類型
表省略
入力情報の信頼性・妥当性
情報の入力は、開発者が提示している条件の下で計測・入力されていることを前提とした場合でも、必ずしも正しい情報が入力されているとは限らない。入力情報の信頼性や誤差による出力情報等に与える影響が製品の使用目的に照らし合わせた時に妥当な範囲になるか、医療機器としてのリスクマネジメントに係る規格に沿って評価することも必要である。また、入力の方法についても、開発者が提示若しくは想定していない使い方、意図的に異なる使い
方をするユーザもいる可能性があることも考慮する。このような使い方について、
JIS T 62366-1（医療機器−第 1 部：ユーザビリティ エンジニアリングの医療機器への適用）では、「アブノーマルユース（異常使用）」という表現を使っている。
【入力情報の信頼性が損なわれる例】
- 歩いた時間を入力する際に、ユーザが間違って値を一桁多く入れてしまった。
- 血圧を測っていないのにも関わらず、ユーザが測定値として勝手な数値を入力した。
- センサが少しずれていて、正しく測定されていないデータが入力された。
- 外部に保管されているデータに誤った数値が入力されてしまっていた。
【入力情報の妥当性の考え方の例】
- 医療機器を用いて測定をしており、入力情報の品質は当該医療機器において一定の担保がされているとみなしている。
- 多少の誤差はあるが、対象となるプログラムで意図する使用範囲において、その誤差は大きく影響を受けるものではないので問題ない。仮に大きく逸脱してきた場合は、その値を除外するようにしている。
- 使用する機器やセンサを当該製品のメーカーが示した仕様、測定条件の下で使用されて
いることを確認している。 情報入力を行う者の特性
JIS T 14971:2020 細分箇条 5.2 では「製造業者は，合理的に予見可能な誤使用についても文書化する。」とされており、誤使用に関連する危害のリスクを評価し、必要な場合には対策を取る必要がある。誤使用を特定して最小限にすることで使用に関連するリスクを低減するための設計開発プロセスをユーザビリティエンジニアリングプロセスといい、JIS T 62366-1 に解説されている。この規格は海外では既に強制規格となっている。我が国においても医療機器のユーザビリティの評価に利用可能であり、今後強制規格となる（令和 4 年 9 月 30 日付薬生機審発 0930 第 1 号薬生監麻発 0930 第 1 号, 医療機器のユーザビリティエンジニアリングに係る要求事項に関する日本産業規格の改正の取扱いについて[19]）。
ユーザがどんな誤使用をする可能性があるかを予想するため、ユーザ特性を評価する必要がある。ここでユーザ特性とはユーザの持っている知識、受けてきた訓練、身体に関する特性、認知・知覚に関する特性を包括的に含んでいる。行動変容を促すプログラムでは、その対象となるユーザ自身が情報入力を行う場合が多いと考えられる。本人以外の場合も、家族などの専門的知識を持たない者が入力する場合がある。そのような場合、入力者が専門的知識や専門的訓練を受けていることは想定できない。また高齢者や若年者が入力を行う場合にはそれぞれの特性が入力情報の信頼性・妥当性に影響を及ぼす可能性がある。
国際規格 IEC 60601-1-11 （基礎安全及び基本性能に関する一般要求事項－副通則：ホームヘルスケア環境で使用する医用電気機器及び医用電気システムに対する要求事項）では、専門性を有さない操作者の特性を詳しく論じており参考になる。
4.5. プログラムによる働きかけ
プログラムによる働きかけを実現するための手段
プログラムによる働きかけ対象となるユーザ群を考慮し、合理性のある根拠や条件に基づ
き、意図する目的や目標等を達成するためにどのような働きかけを行うのかを決定する。
対象となるユーザに応じた働きかけ
ユーザの状態により、プログラムによる働きかけの効果やリスク等は異なるため、当該製品のユーザを想定できる範囲で絞りこむ。
【絞り込みの例】
- 製品の使用が効果を生み出すことが期待されるユーザ群の例
運動療法を目的としたアプリの場合：糖尿病治療のために減量を行う人、BMI35 以上で睡眠時無呼吸症候群を合併している人、等 禁煙治療を補助するアプリの場合：従来の禁煙治療では十分な効果が見られなかった人
- ユーザの特性によって働きかけの効果の違いが想定される例
ヘビースモーカーとライトスモーカーとのどちらを対象とするか(両者ではニコチンへの依存や心理的依存の度合いや、禁煙の維持に効果的な行動パターンが異なることが予想され、より高い効果を得るためには、異なるアルゴリズムが必要となる可能性がある。)。
働きかけの種類
プログラムによる働きかけを実現するための手段には、具体的な目標内容や行動を示すものと情報を提供するものとがある。また、働きかけの内容は、学会等のガイドラインなど公知の情報を用いるものもあれば、独自に設定するものもある。その際は、その内容や働きかけの度合い、頻度、密度なども合わせて検討する必要がある。
【プログラムによる働きかけの例】
情報提供（一般的に認知された情報が記載された書物等の情報）
〇〇学会のガイドラインで示された栄養メニューを提示。
- デバイスを介した働きかけ
スマートウォッチから入力された心拍数等の情報に基づき、予めインプットされているアルゴリズムにより算出されたランニングのペース(対象患者の運動療法として最適な運動負荷に調整する)をスマートウォッチのバイブレータ機能を用いてユーザに伝える（なお、一般のデバイスを出力の刺激装置として使う場合には、その振動刺激が、ユーザに対して有害な事象をもたらす可能性を検討する必要がある。）。
入力された情報に基づきアプリが予めインプットされているアルゴリズムに基づき、直接、何らかの指標や助言等を伝える。
示された目標の運動量を達成するまで、アラームが鳴り止まないため、運動をせざるを得ない。
- 予め同意を取った対象に情報を提供し、フィードバックを得る。
医療機関等にユーザの入力情報等を送信し、その情報を基づき医師等の専門職群がサジェスチョン・アドバイスする内容を伝える。 ※上記の例は働きかけの形態の事例を示したのみであり、これらの働きかけを行うプログラムが医療機器に該当する/しないに関しては個別の判断が必要である。
4.6. その他
効果の標榜と広告規制
医薬品や医療機器の分野では対象とする製品の特長や効果・効能等を主張したり表明したりすることを標榜という。医療機器としての使用目的又は効果を標榜できるプログラムは医薬品医療機器等法の製造販売承認又は製造販売認証を受けたプログラムのみとなる。同法では、広告内容が適正を欠いた場合には、国民の保健衛生上、大きな影響を与えるおそれがあるとして、その表記内容を規制している。また、医療機器ではない場合でも、不当景品類及び不当表示防止法（景品表示法）では、一般消費者に対して著しく優良であると誤認させる表示を禁止している。医療・健康分野における行動変容を促すプログラムでは、医療従事者等以外の専門的知識を持たない人がユーザとなることも想定されるため、簡明かつ正確な情報提供が重要である。
厚生労働省では医療機器の広告規制に関係する法令や通知等をホームページ上でまとめており[20-22]、業界団体でも医療機器の広告についてガイド集等[23,24]を出しており、参考になる。なお、医療機器の広告規制に関する相談は都道府県薬務主管課で受け付けている。
【医薬品医療機器等法の広告規制に関連する文書（抜粋）】
医薬品等適正広告基準
2 医薬品等適正広告基準(以下、「本基準」という。)の運用にあたって留意すべき事項は次のとおりである。
（中略）
(2)本基準の運用にあたっては、医薬関係者を対象とする広告と一般人を対象とする広告、医薬品広告、医療機器広告、化粧品広告等、それぞれの広告の性格の違いを勘案し、画一的な取扱いを避けるよう配慮する。
事務連絡「医療機器プログラムの取扱いに関する Q&A について」（平成 26 年 11 月 25 日）[6]
Q14 一般医療機器に相当するプログラムは、どこまで使用目的又は効果、性能等を標榜することができるのか。
A14 医療機器であると誤認させるような製品が流通することは、保健衛生上の観点から好ましくない。
① 有体物として一般医療機器が存在する医療機器と同等のプログラムは、当該有体物と同等の性能等を、
② 有体物の一般医療機器が存在しないものについては、個別の判断により、一般医療機器相当の性能等を、医療機器であるという誤解の生じない範囲でのみ標榜することができるが、併せて医療機器でないことを明記すること。
アドヒアランスを高めるための工夫
アドヒアランスとは、患者が積極的に治療方針の決定に参加し、その決定に従って治療を受けることを意味する。行動変容を促すプログラムにおいて、ユーザの満足度や継続的な使用を促す工夫として、ユーザのアドヒアランスを高めるための機能を追加する場合もある。その機能の例を以下に示す。
なおこれらの工夫がすべての疾患、患者の状態等でアドヒアランスを高めるとは限らず、また逆にアドヒアランスを下げうる可能性もある。そのため対象とする医療機器プログラム開発に応じて適切な設計を行う必要がある。
【アドヒアランスを高めるための工夫の例】
- マイルストーンとなるサブ目標をたくさん設けて、達成感を積み上げる
- メッセージの内容、ユーザーインターフェース、キャラクターや表現方法による工夫
- ポイントや金銭的なインセンティブ
- 継続的に使用することで、何らかのグレードが上がる仕組み
- コミュニティなどによるピアサポート
- コミュニティの中で、だれが一番早く目標を達成するかゲーム形式にするただし、この場合は誰かが目標を達成した場合にそれ以外のユーザのモチベーションが下がる場合がある。そのような場合でもモチベーションを維持する工夫が必要になる。 リスクマネジメント
医療機器の開発において、リスクマネジメントの実施は必須要求となっている。プログラムという無体物においても、医療機器の規格に添ったリスクマネジメントが必要である。製造販売業者等は、当該システムの不適切な動作等により生じる可能性のある危険性を、合理的に実行可能な限り除去又は低減できるよう、適切な手段が講じなければならないとされ、基本要件基準への適合については、JIS T 14971 （ISO 14971）に基づき実施されたリスクマネジメントの内容を説明することとされている。開発者は、開発する製品の使用目的や特質を明確化し、その範囲下で危害を引き起こす可能性となる原因（「ハザード」：危害の潜在的な源）を特定し、特定したハザードごとにどのような危険状態があるかを考え、リスクの程度を推定する。「危険状態」とは、人がハザードにさらされる状況のことを指す。ハザードがあるからといって危害が発生するわけではなく、危害の原因となるハザードがあって、そのハザードに人が接触する状況がないと危害は発生しない。そのため、開発者は、ハザードだけでなく、どのような危険状態が考えられるかも考慮し、リスクの大きさを見積もる必要がある。リスクの推定後、推定したリスクが許容できないと判断される場合は、その都度、リスク低減のための対策（リスクコントロール）を行い、より受け入れ可能なものへとしていく必要がある。こうした「リスク分析」「リスク評価」「リスクコントロール」「全体的な残留リスクの評価」といった一連がリスクマネジメント活動として求められている。
さらに、JIS T 14971（ISO 14971）では、「リスクマネジメントのレビュー」や「製造及び製造後の活動」も要求事項として挙げられている。開発において、常にリスクマネジメントの見直しをするとともに、開発段階のみならず製造後（市販後）も以前に認識されていなかったハザード又は危険状態はないか、危険状態によって推定されるリスクが受容し続けられているかどうかの情報を収集し、リスクマネジメントにフィードバックすることが重要である。
リスクマネジメントに関連する規格等を以下に示す。なお、下記の規格は参考情報として提示しているのみであり、これらの規格への適合が必ずしも求められるわけではない。
表４：リスクマネジメントに関連する規格等
表省略
取得する個人情報の範囲と保護
個人情報保護法では、取得する情報の利用目的と範囲を特定し、ユーザの同意を得ることが示されており、開発製品の使用目的から逸脱するデータを取得する場合には、その理由を明示する。
個人情報の保護に関する法律（令和 4 年 4 月 1 日施行 （令和三年法律第三十七号による改正））
（利用目的の特定）
第 17 条 個人情報取扱事業者は、個人情報を取り扱うに当たっては、その利用の目的
（以下「利用目的」という。）をできる限り特定しなければならない。
（利用目的による制限）
第 18 条 個人情報取扱事業者は、あらかじめ本人の同意を得ないで、前条の規定により特定された利用目的の達成に必要な範囲を超えて、個人情報を取り扱ってはならない。
サイバーセキュリティに対する考慮
開発製品の入力、保存、処理のプロセスに対し、外部からの攻撃を受ける可能性があることを考慮する。製造販売業者は、サイバーセキュリティについても最新の技術に基づくリスクマネジメントを実施する必要がある。サイバーセキュリティについては、例えば、規格であれば、リスクマネジメント規格の ISO14971（JIS T 14971）では、2019 年の改定より、セキュリティリスクをリスクマネジメントの対象として扱えるようになった。さらに、医療用ソフトウェアのサイバーセキュリティに関連する IEC80001 の規格群の開発も進められているなど、常に現在進行形で検討が進んでおり、最新の状況を確認することが望ましい。
政府を中心にサイバーセキュリティ対応や関連情報をホームページで公表しており、これらのホームページより最新情報を入手できる。サイバーセキュリティに関するガイドラインや医療機器のセキュリティに関するガイドラインも発行されており、これらについても最新の状況を確認することが必要である。サイバーセキュリティに関連するホームページや関連するガイドラインや規格等を以下に示す(なお、ガイドラインや規格は参考情報として提示しているのみであり、これらへの適合が必ずしも求められるわけではない。)。表５：サイバーセキュリティに関連するホームページ
発行元 URL
内閣官房内閣セキュリティセンター https://www.nisc.go.jp/
総務省のサイバーセキュリティタスクフォース https://www.soumu.go.jp/main_sosiki/kenkyu
/cybersecurity_taskforce/index.html
（独法）情報処理推進機構 https://www.ipa.go.jp/index.html
表６：サイバーセキュリティに関連するガイドライン等
表省略
表７：サイバーセキュリティに関連する主な規格
表省略
5. 複数機能プログラムと機能モジュールアプローチ
5.1. 本章について
行動変容を促すプログラムにあっては、医薬品医療機器等法上の扱いが異なる複数の機能が混在することが予想される。特に、医療機器に該当する機能と該当しない機能が混在するプログラムの場合について考慮が必要である。
一般的に、プログラムを医療機器として開発し、規制対応し、流通させ、品質管理することは、工数が増加するため非医療機器として事業展開するよりも高いコストを要する。医療機器に該当しない機能を非医療機器として扱うことができれば合理的であろうと考えられる。
本章ではこのようなプログラムのアーキテクチャとして、医薬品医療機器等法上の医療機器に該当する機能を「モジュール」単位で開発・流通させる手法につきその検討から実装までの設計・開発段階にて考慮すべき事項を整理する。
なお、本章ではハードウェアを含まないソフトウェア部分のモジュール化に限定して述べる。
5.2. 背景
事業者の事業戦略上の制約
セルフケア WG 注5）による事例調査等で、事業者が医療機器への該当・非該当でそれぞれ別のプログラム、サービスを提供している傾向、事業者が医療機器該非の境界を超えないように行動している傾向が見られた。その理由として、
- ビジネスモデルの違い（保険診療に組み込むかなど）
- 法規制対応（製造販売承認の要件、品質管理、標榜に関する医薬品医療機器等法規制）
が指摘された（2020/12/17 資料 7）。また、医療機器該当の機能が一つでも存在する場合、プログラム全体が医療機器該当として規制及び承認（認証）申請の対象となる懸念が指摘されていた。
注 5）令和 2 年度「第 3 回セルフケアを支える機器・ソフトウェア（プログラム）に関する検討委員会[1]」
プログラムの医療機器該当性の最小単位
「プログラムの医療機器該当性に関するガイドライン」[12]の発出前のパブリックコメントでは、プログラムの医療機器該当性の最小単位についても質疑が交わされている。
Q4：（中略）「複数の機能を有するプログラムの医療機器該当性の判断に当たっては、少なくとも 1 つの機能が医療機器プログラムの定義を満たす場合、全体として医療機器としての規制を受けることになる。」について、ここでいう全体とは何を指す
のか。例えば、プログラムの形態をとるプラットフォーム(例:通話アプリ)において、ミニアプリとして医療機器となりうるアプリをプラットフォーム上で提供する場合、プラットフォーム全体が医療機器となるという理解をすればよいか？それともミニアプリのみが医療機器となるのか。
A4：プログラムが医療機器として規制対象となる範囲は流通単位で判断され、プラットフォームとミニアプリが不可分であり、それぞれ単独流通できない場合は一体として規制対象となる。
＜補足：ミニアプリとは？＞
上記の「ミニアプリ」のより具体的な一例としては、「Apple の心電図アプリケーション」及び「Apple の不規則な心拍の通知プログラム」が挙げられる。この２つの医療機器プログラムは利用可能な iOS 及び watchOS のバージョンが制限され、OS 付属のプログラムとの連携が必要なものの、一般的なアプリケーションプログラムと同様にインストール操作を経て利用可能となる*。具体的には、
- OS を iOS 14.4 及び watchOS 7.3 以降の新しい OS にアップデートする。
- iPhone の「ヘルスケア」App の画面案内に従い、設定する。iPhone とペアリングして、生年月日を入力する。
とされている。
* 令和 3 年 1 月 27 日付薬生機審発 0127 第 7 号・薬生安発 0127 第 4 号, 「家庭用心電計プログラム」及び「家庭用心拍数モニタプログラム」の適正使用について
＜補足：プラットフォームとは＞
Q４では「プログラムの形態をとるプラットフォーム(例:通話アプリ)」と述べられている。一般的に、医療機器プログラムに関する文書で「プラットフォーム」は、汎用コンピュータとされている*。ここにはスマートフォン、ウェアラブルデバイス等も含まれる。また、ハードウェア、ソフトウェアの両方を含んでいる。プラットフォームのソフトウェアとしてはオペレーティングシステム(OS)、ライブラリ、アプリケーションプログラム等が含まれる。
「画像ワークステーション」の中には個別の画像処理を行う別の医療機器プログラムに対するプラットフォームとして機能するものもある。
* 平成 26 年 11 月 25 日付事務連絡, 医療機器プログラムの取り扱いに関する Q&A について
5.3. 機能モジュールの実装
機能モジュールの定義の導出
ここまで示した通り、医療機器プログラムをモジュール化する場合は、「プラットフォームと機能モジュールが分割可能であること」が要件の一つである。ここには、「分割しても品質の維持と管理及び安全対策が可能であること」が含まれると考えられる。すなわち、機能モジュールの実装上の最小単位は、
- 独立して流通可能で、
- かつ製造販売業者による品質管理及び安全対策が可能な単位
と考えられる。ここでは、機能モジュールが具備すべき要素を、他の要素との境界（インターフェース）との関係性に着目して分解することで、機能モジュールの最小単位を規定するための方法を述べる。
プログラムを構成する機能要素と、医療機器プログラムとして品質管理すべき部分
医療・健康分野のプログラムが具備すべき機能要素は、
1) 入力機能：ユーザの操作又は外部機器（ソフトウエアを含む、以下同じ）からの信号を受け取る要素。入力のユーザーインターフェース(U/I)又はプラットフォームからの信号
（データ or 情報）接続のためのインターフェース(I/O)からなる。
2) 処理機能：その機能モジュールの医療・健康上の機能に関する処理を司る要素。
3) 出力機能：ユーザへの情報表示又は外部機器に信号を受け渡す要素。
に区分できる（図３）。
入力機能及び出力機能の例としては、
- 入力 U/I、例えばキーボード入力、マウスからの入力
- 出力 U/I、例えば文字ディスプレイへの出力
- 外部機器、例えばインターネット、データベースから／への入出力
がある。なお、ネットワーク機能、記憶領域（データベース、ハードディスク等）、センサ類などプラットフォームに備わっている個々の要素についても機能モジュール部分から見ると外部からの入力出力機能と捉えることができる。そのため、本章ではこれらを省略している。
一般的には、入出力 U/I や外部機器とのインターフェースはプラットフォームが提供する機能である。医療・健康分野のプログラムはプラットフォーム側の提供する機能を、プログラム側の入出力 I/O ソフトウェアを通して呼び出すことで情報をやり取りする。
よって、プログラム側の入出力 I/O の機能は、プラットフォームの機能を呼び出すことと、入出力される情報の検証となる。後者の例としては
- U/I から得た入力値の範囲、フォーマット等のチェックと修正
- 複数の入出力の競合状態(race condition)、不整合への対応
- 出力値の検証、出力先の要求に合わせたフォーマッティング
- 入力信号の欠落、ノイズの混入の検出と対応
- データベースから得たデータの真正性、完全性の確認
図３，４省略
機能モジュールアプローチが有効なのは、プログラムの中に複数の医療・健康に関する機能が存在する場合である。複数の機能モジュールが直列繋ぎ又は並列繋ぎされる場合（図５）には、I/O ソフトウェアの機能の一部をモジュールの外に出して共用することが可能な場合があり、コスト削減できる可能性がある。これが機能モジュールアプローチの重要なメリットである。
図５：機能モジュールの直列・並列繋ぎの一例。A→B→C は直列、B/B1/B2 は並列。
図省略
この例で、B はこのプログラムに必須の機能、B1 と B2 はオプション的な機能とする。B1 を医療機器プログラムに該当し、B2 を医療機器プログラムに該当しない機能モジュールとする場合、B, B1, B2 の I/O 部分の機能のうち共通化できる部分を A と C の部分に置くことができれば、より合理的な品質管理ができると考えられる。
機能モジュールに含めるべき I/O ソフトウェアの機能の決定原則
製造販売業者は、機能モジュールの I/O ソフトウェアの機能の個々につき、どの機能を当該機能モジュールに含めるべきか、どの機能をモジュール外の機能に委ねること（機能の委任）が可能であるかを、機能の内容、品質管理の要否に基づいて検討する。
例えば、データベースから得たデータの真正性の確認の検討にあたっては、次の原則に基づいて検討する（図６）。
① 機能モジュールの処理機能は医療機器プログラムに該当するか。この場合、当該機能モジュールは医療機器として品質管理する必要がある。
この判断は、「プログラムの医療機器該当性に関するガイドライン」[12]等に基づいて行う。
② I/O に接続される外部機器は、入出力の授受に関して医療機器プログラムとしての品質管理を要求しているか。その場合、当該機能モジュールの対応する I/O ソフトウェアは、医療機器プログラムとしての品質管理が必要であるか。
この判断を行うための一般的な指針は存在しない。各企業の品質管理ポリシーに基づいて判断する。
③ I/O ソフトウェアの機能の個々について、モジュール外部の I/O の機能を委任し、かつその品質管理の水準を受け入れることができるか。モジュール外部の I/O の品質管理の水準が受け入れ可能か否かは、企業の品質管理ポリシーに基づいて判断する。
④ ①と②のいずれか及び③に該当する場合、I/O のその機能はモジュール外の I/O に委任できるが、医療機器としての品質管理又はこれに準じる水準のものが望ましい。
⑤ ③に該当するが、①と②のいずれにも該当しない場合も、モジュール外部の I/O の機能に委任できる。
⑥ ③に該当しない場合は、当該機能モジュールの中にその I/O の機能を含める必要がある。
図６：機能モジュールに含めるべき I/O ソフトウェアの機能の決定
図省略
上記③においてモジュール外部の I/O の機能に委任し、その品質管理の水準が受け入れ可能であるか否かを左右するファクターとして、次の事項が参考になる。
- モジュール外の I/O の開発及び品質管理を自社で行なっているか。すなわち、判断のための情報が入手可能であるか。
- モジュール外の I/O の規格等について公開されていて、機能委任及び品質管理水準の受け入れが可能かを判断できるか。
- モジュール外の I/O の不具合や誤使用が当該機能モジュールに及ぼす悪影響の程度と蓋
然性が判断できるか。
機能モジュールの例
機能モジュールに入出力 I/O ソフトウェアを含まない例
メインの医療機器プログラムに追加する医療機器モジュールにおいては、メインのプログラム側の医療機器として品質管理された I/O ソフトウェアを利用することで、追加モジュール側のソフトウェアを削減又は省略できる可能性がある（図７）。
図７：機能モジュールに入出力 I/O ソフトウェアを含まない例
図省略
機能モジュールに医療機器品質管理された入出力 I/O ソフトウェアを含む例
メインの健康プログラム（非医療機器）に追加する医療機器モジュールにおいては、より厳格なエラーチェックを行うといった医療機器として品質管理された I/O ソフトウェアをモジュール側に含めるか、検討が必要な場合がある（図８）。
図８：機能モジュールに医療機器として品質管理された入出力
I/O ソフトウェアを含む例
図省略
ただし、メインのプログラム側の I/O ソフトウェアを自社開発していて実質的に医療機器品質を担保している場合等、追加モジュール側の I/O ソフトウェアを省略できる場合もありうる（図９）。
図９：機能モジュールに医療機器として品質管理された入出力 I/O ソフトウェアを含まない
図省略
例。メインのプログラム側の I/O ソフトウェアにて実質的に医療機器品質を担保している場合。
5.4. 機能モジュールアプローチの実施例
例示する実施例について
2021 年時点で実用されている機能モジュールアプローチを例示する。
サーバ側アプリケーションによるモジュールの実装
サーバ側で動作するモジュールの機能を、スマートフォン等のユーザーデバイス上で動作する実行可能形式（いわゆるアプリ）上で組み合わせて提供する実装形態。
サーバ側では、最近ではクラウド上での演算（クラウドコンピューティング）の利用が拡大している。クラウドコンピューティングでは、用意されている多数のソフトウェア部品を組み合わせて用いるのが一般的である。クラウド事業者が規格化した API を利用した医療機器に該当するソフトウェア部品を第三者が多数開発しており、米国等海外ではこれらが利用されている。
【例】 Amazon Web Services（Amazon Web Service,Inc.）
ローカル側では、Web ブラウザ上で動作する Web アプリケーションとする実装、独自のアプリがサーバ側アプリケーションと連携する実装がある。
【例】 Join （アルム／慈恵医大）
販売名「汎用画像診断装置用プログラム Join」（一般的名称：汎用画像診断装置ワークステーション用プログラム、 クラスⅡ、認証番号: 227AOBZX00007Z00、製造販売業者：株式会社アルム）は、機能モジュールアプローチに類似する構造となっている（図１０）。基本機能として
- コミュニケーション機能（チャット、画像投稿、ビデオ通話）：非医療機器
- DICOM ビューワ：医療機器
- PACS 連携：非医療機器
を持ち、一種のクラウドプラットフォームとなる。発展機能として、
- Join AI Connect：EIRL Brain Aneurysm 等と連携して、解析レポートを提示する。
を提供しており、Join の中に医療機器該当、非該当の機能がそれぞれ存在するほか、他のサービスへのインターフェースとなっている。
図１０：Join システム概要図
図省略
出典：医療関係者間コミュニケーションアプリ Join 説明資料
プラグインによるモジュールの実装と提供
ユーザが「プラグイン」をダウンロードすることで機能が組み込まれて使用可能になる提供形態。プラグインが実際に何であるかは、実装による。実行可能形式、DLL、スクリプトなどの実装が代表的である。具体的事例としては、スマートスピーカーに追加される機能を実現するモジュールなどが考えられる。
プロセス間通信による実装
OS の提供する、Inter-process communication (IPC)機能によって必要な情報をアプリ間で通信する方法。アプリ間の結合の強度は、やり取りする情報の種類、頻度に左右される。
【例】 iOS の「ヘルスケア」アプリと他のアプリの間の通信
iPhone の iOS では、各社の活動量計、体重計等のアプリと iOS 付属の「ヘルスケア」アプリの間で計測値を共有する OS 機能 HealthKit が IPC として提供されている。
5.5. 本章のまとめ：機能モジュールアプローチで期待される事項
機能モジュールアプローチの意義と課題、機能モジュールによらない開発アプローチの課題をまとめる。
機能モジュールアプローチで期待される事項
- 医療機器承認・認証を要する部分を限定できることから、事業上の自由度が高くなる。
- 機能モジュール単位の製造販売承認・認証。
- 機能モジュール単位の不具合対策。
- 機能モジュールの集合による「メタ医療機器機能」。ただし、複数の機能モジュールの組み合わせにより実現される新たな機能については、製造販売承認(認証)事項一部変更申請や新規の承認(認証)申請が必要となる可能性がある。
機能モジュールアプローチで予想される課題
- 医療事業と非医療事業のビジネスモデル構造の相違は、このアプローチでは解決しない。
- U/I を持つモジュールを組み合わせる場合、操作方法の一貫性を確保しないとユーザを混乱させる可能性がある。特に異なる事業者のプログラムを組み合わせる場合、この問題は重要である。
- モジュールの相互運用性に関する標準規格が存在することが望ましい。例えば、クラウド等で用いられている API ベースの標準規格が考えられる。IT 機器の場合は進歩が急速であるため、国際規格、フォーラム規格よりもデファクト規格の方が優勢である。 |