簡単な回答: ソフトウェアが医療目的（診断、予防、モニタリング、予測、予後、治療）を持つ場合、EU医療機器規則（MDR、2017/745）の下では医療機器とみなされ、リスククラスが割り当てられます：I、IIa、IIb、またはIII。これは主に附属書VIIIの規則11によって決定されます。クラスによって、自己認証（クラスIのみ）が可能か、通知機関が必要か、臨床評価の深さ、市販後監視の実施方法が決まります。これとは別に、技術標準IEC 62304はソフトウェアに安全性クラスを割り当てます：A（傷害の可能性なし）、B（軽度の傷害の可能性あり）、またはC（死亡または重度の傷害の可能性あり）。これはライフサイクルに必要な文書作成、設計、テストのレベルを決定します。これら2つの分類は関連していますが独立しており、どちらもソフトウェアが引き起こしうる危害に基づいて決定され、その複雑さによるものではありません。
ステップ1：そもそもデバイスか？
EUのMDR（医療機器規則）において、ソフトウェアは、診断、予防、モニタリング、予測、予後、または治療（第2条(1)項）を目的とする場合に医療機器とみなされます。データを保存、アーカイブ、通信、表示、または検索するだけのソフトウェアは医療機器ではありません。しかし、診断または治療の決定を支援するために医療情報を生成または変更するソフトウェアは、MDCG 2019-11によると医療機器とみなされます。
MDRの定義（第2条(1)）は、その目的によります。データを保存、アーカイブ、通信、表示、または簡単な検索を行うソフトウェアはデバイスではありません（MDCG 2019-11でこれらが挙げられています）。診断や治療の決定を支援するために医療情報を作成または変更するソフトウェアはデバイスです。検査値とその検査機関の基準範囲を示す記録はデバイスではありません。ユーザーにその値が病状を示していると伝えたり、投与量を推奨したりするソフトウェアはデバイスです。詳細については、ヘルスアプリは医療機器か？の適格性判断ステップを参照してください。
ステップ2：MDRリスククラス、規則11
MDRの規則11は、誤った決定が引き起こす可能性のある危害に基づいて医療機器ソフトウェアのクラスを分類します。診断または治療上の決定のための情報を提供するソフトウェアは、デフォルトでクラスIIa、そのような決定が重度の悪化または手術を引き起こす可能性がある場合はクラスIIb、そしてそれらが死亡または不可逆的な悪化を引き起こす可能性がある場合はクラスIIIとなります。モニタリングソフトウェアはクラスIIa、バイタルパラメータの場合はクラスIIbです。
| ソフトウェアの目的… | MDRクラス |
|---|---|
| 診断または治療目的の決定に使用される情報を提供する（デフォルト） | IIa |
| …そのような決定が死亡または健康の不可逆的な悪化を引き起こす可能性がある場合 | III |
| …そのような決定が健康の深刻な悪化または外科的処置を引き起こす可能性がある場合 | IIb |
| 生理学的プロセスを監視する（デフォルト） | IIa |
| …患者に即時の危険をもたらす可能性のある生理学的バイタルパラメータを監視する場合 | IIb |
| その他（デバイスであるソフトウェアで上記以外） | I |
規則11により、以前はクラスIだった多くのソフトウェアがIIa以上に引き上げられ、MDRがデジタルヘルスにとって大きな変化と捉えられた主な理由となっています。MDCG 2019-11とIMDRFのリスクフレームワーク（情報の重要度 × 医療状況の状態）は、境界ケースの配置に役立ちます。ハードウェアデバイスを駆動または影響を与えるソフトウェアは、そのデバイスのクラスを引き継ぎます（施行規則の規則3.3）。
クラス別の結果: クラスIは技術ファイルと登録により自己宣言され、通知機関は不要です（Im、Is、Irを除く）。IIaは品質システムと技術文書のサンプルに対する通知機関の評価が必要です。IIbはより詳細な文書審査とともに同様です。IIIは完全な技術文書レビューと、関連する場合は専門家パネルとの協議が必要です。すべてのクラスで、品質マネジメントシステム、クラスに応じた臨床評価、規制遵守責任者、UDI、EUDAMEDへの登録、市販後監視と警戒活動が必要です。
ステップ3：IEC 62304ソフトウェア安全性クラス
IEC 62304のソフトウェア安全性クラスは、外部リスク管理の後で、医療機器ソフトウェアが貢献しうる最悪の危害に基づいて評価します。危害がない場合はクラスA、軽傷の可能性がある場合はクラスB、死亡または重傷の可能性がある場合はクラスCとなります。このクラスによって、ソフトウェアライフサイクルに必要とされる設計、検証、および文書化のレベルが決まります。
IEC 62304（2006年、2015年改訂）は、医療機器ソフトウェアライフサイクルプロセスに関する調和規格です。その安全性クラスは、ソフトウェア外部のリスク管理策を考慮した後で、ソフトウェアが寄与しうる最悪の危険な状況から導き出されます。
| クラス | 危険な状況は…につながる可能性がある | ライフサイクルに必要なこと |
|---|---|---|
| A | 健康への傷害または損害なし | ソフトウェア開発計画、要件、リリース；問題解決；構成管理 |
| B | 軽度の傷害 | A：加えて、アーキテクチャ設計、統合とシステムテストの検証、文書化された単体テストの検証 |
| C | 死亡または重度の傷害 | B：加えて、各単体に対する詳細設計、追加のアーキテクチャ分離、より厳格な検証 |
クラスはソフトウェアシステムごとに割り当てられ、分解後にソフトウェア項目ごとに割り当てることができるため、リスクの高い部分のみがクラスCの厳格さを持ちます。この標準では、そのために必要な分離に関する議論が説明されています。ISO 14971（リスク管理）は分類に影響を与え、IEC 82304-1は一般的なプラットフォーム（電話、クラウド）で実行されるヘルスソフトウェアの製品レベル要件を追加します。
両者の相互作用
MDRのリスククラスとIEC 62304の安全性クラスは独立しています。MDRのクラス（IからIII）は、規制ルートと認証機関の関与を決定し、IEC 62304のクラス（AからC）は、エンジニアリングプロセスの厳格さを決定します。クラスIIaのアプリでも、誤った出力が引き起こす可能性のある危害によっては、62304クラスBまたはCになることがあります。
MDRクラスは規制ルートに関するものであり、IEC 62304クラスはエンジニアリングプロセスに関するものです。規則11に基づくクラスIIaアプリは、IEC 62304クラスB（誤った情報がケアの遅延につながる可能性があり、軽度）またはクラスC（誤った投与量提案が致命的になる可能性がある場合）になる可能性があります。クラスIデバイスは通常62304クラスAですが、必ずしもそうではありません。通知機関は、技術ファイルにその正当化とともに62304クラス、そのレベルでのライフサイクル文書、およびリスク管理ファイルへのリンクを示すことを期待しています。サイバーセキュリティ（MDCG 2019-16、IEC 81001-5-1）も併せて評価されます。
実例
SaMD（医療機器としてのソフトウェア）の実例：症状を記録、表示、共有する症状追跡アプリは医療機器ではありません。しかし、検証済みのスケールで症状を採点し、ユーザーに受診のタイミングを伝える機能を追加すると、それは医療機器となります。MDR規則11ではデフォルトでクラスIIa、IEC 62304ではクラスB、心臓関連の用途ではクラスCとなります。
ユーザーが症状を記録し、傾向を表示し、医師と共有できる症状追跡アプリ：デバイスではありません（保存、表示、通信）。同じアプリに、記録された症状を検証済みの尺度で採点し、スコアが受診を勧めることを示す機能が追加された場合：デバイスとなり、規則11のデフォルトであるクラスIIa（診断決定に使用される情報。誤った「受診不要」は治療の遅延につながる可能性があり、深刻ですが、通常は不可逆的ではないため、対象となる病状によってIIbまたはIIIにならない限りIIbまたはIIIではありません）。IEC 62304：誤った安心感はケアの遅延につながる可能性があり、病状によっては軽度から深刻になるため、クラスB、心臓関連のユースケースではCになる可能性があります。ルート：ISO 13485 QMS、通知機関、尺度の臨床評価、ユーザビリティエンジニアリング（IEC 62366-1）、市販後監視。
米国、簡潔に
米国では、FDAが意図された用途に基づいてソフトウェアを医療機器として規制しており、クラスI、II、IIIがあり、510(k)、De Novo、PMAの承認経路があります。21世紀治療法（21st Century Cures Act）は、管理ソフトウェア、一般的なウェルネス製品、電子健康記録、および特定の臨床意思決定支援を医療機器のステータスから除外しています。FDAはIEC 62304をコンセンサス標準として認識しています。
FDAは、クラスI、II、IIIおよび510(k)、De Novo、PMAのパスウェイとともに、同じ意図された使用ロジックの下でソフトウェアを医療機器として規制しています。21世紀治療法（セクション3060）は、いくつかのカテゴリをデバイスステータスから除外しました：管理ソフトウェア、一般的なウェルネス、電子健康記録、および臨床医が推奨の根拠を独立してレビューできる臨床意思決定支援（FDAの2022年CDSガイダンスはこれを狭く解釈しています）。FDAはIEC 62304をコンセンサス標準として認識しており、2023年以降、「サイバーデバイス」にサイバーセキュリティ文書を要求しています。ISO 13485は、2026年に米国の品質システム規制（QMSR）の基礎となりました。
Anpherosにて
Anpheros Dailyは保存、表示、共有を行います。採点、解釈、推奨は行わず、その意図された目的もそれを明記しています。したがって、規則11または治療法除外の下では医療機器ではなく、チームはデバイスルートなしでISO 27001スタイルのセキュリティと文書化されたソフトウェアプラクティスを適用しています。もし医療目的の機能が追加された場合、リリース前に規則11の下で分類され、IEC 62304の下で開発されます。健康の透明性を参照してください。
このページは、製品およびエンジニアリングチーム向けの規制について説明しています。これは法的助言ではありません。情報源の下にリンクされているテキストが権威であり、あなたのデータ保護責任者、通知機関、または顧問があなたのケースを決定します。最終レビュー：2026年10月。
関連ページ
情報源
- 規則 (EU) 2017/745 (MDR)、附属書VIII、EUR-Lex
- MDCG 2019-11: ソフトウェアの適格性と分類
- IEC 62304:2006+AMD1:2015、医療機器ソフトウェアライフサイクルプロセス
- IEC 82304-1:2016、ヘルスソフトウェア製品安全性
- FDA: 臨床意思決定支援ソフトウェアガイダンス (2022)
- FDA: 医療機器としてのソフトウェア
よくある質問
ソフトウェアはMDRの下でクラスIになり得ますか？
はい、しかし稀です。診断または治療の決定に情報を提供したり、生理学的プロセスを監視したりしない、医療目的のソフトウェアのみです。デバイスとみなされるほとんどのアプリはIIaに分類されます。
クラスIIaデバイスは臨床試験が必要ですか？
臨床評価が必要です。これは文献、同等性、パフォーマンスデータに依存する場合があります。既存の証拠が不十分な場合は臨床調査が必要です。診断パフォーマンスを主張するソフトウェアは通常、独自のパフォーマンススタディが必要です。
IEC 62304は必須ですか？
これは調和規格であるため、それに従うことはMDRのソフトウェア要件（附属書I、17）への適合性の推定となります。別のアプローチを使用することもできますが、その場合は同等性を証明する必要があります。これは実際には誰も行いません。
AI機能についてはどうですか？
同じ規則が適用され、さらにEU AI Actが適用されます。通知機関の評価を受けたデバイスは、附属書Iの下で高リスクAIシステムとみなされ、データ、ログ記録、透明性、人間による監視に関する要件がMDRとともに評価されます。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →