リスク対応を考慮したヘルスソフトウエアの製品化リスク対応を考慮した...

リスク対応を考慮したヘルスソフトウエアの製品化

- GHS活動の展開 -

2018.01.22一般社団法人日本画像医療システム工業会（JIRA）

産業戦略室　専任部長　舟橋　毅

1

本日お話しする内容

• ヘルスケア関連機器の変遷と認可制度 • ヘルスケア分野で利用されるソフトウエア • 法規制対象外ヘルスソフトウエアに関する活動：GHS • GHS適合宣言のための手順 • ヘルスソフトウエアに関係する規格群 • ヘルスソフトウエア開発管理の現状 • GHSの活動のポイント整理

2


3

医療機器の構成の変遷

独自ハードウエア独自ハードウエア

＆アプリケーションソフトウエア

アプリケーションソフトウエア

医療機器の機能（価値）の源泉の変化

独自ハードウエア

機器制御用組み込みソフトウエア


制御用ソフトウエア


汎用PC/モバイル機器


資料引用元：一般社団法人ヘルスソフトウエア推進協議会

4

機器構成の変化に沿った認可制度の変化

機器（ハードウエア＆ソフトウエアを含む）

ソフトウエア（プログラム）単体が医療機器として規制の対象になった

従来同様の機器（箱モノ）

ソフトウエア単体

薬機法：2014.11.25


機器制御用組み込みソフトウエア


制御用ソフトウエア


汎用PC/モバイル機器



5

ヘルスケア分野で利用されるソフトウエア• 医療分野で利用されるソフトウエア製品の一例

薬機法の規制対象になっているソフトウエア製品の例

疾病の診断・治療・予防に関わる製品 •汎用画像診断装置 •ワークステーション用プログラム •放射線治療計画プログラム薬機法の規制対象ではないソフトウエア製品の例

情報の記録・管理、業務ワークフロー支援関係製品 •電子カルテ •医用画像管理システム •地域医療連携システム

薬機法の規制対象/非対象の違いとは？


6


7

ヘルスケア分野で利用されるソフトウエア• 医療関連ソフトウエア製品の概念的な区分（法規制の観点）

法規制の要/不要必要不要

汎用画像診断装置ワークステーション用プログラム放射線治療計画プログラム

etc

電子カルテ医用画像管理システム地域医療連携システム医療会計システム教育支援システム

etc


8

• 医療関連ソフトウエア製品の概念的な区分（法規制 + リスクの観点）

この領域に該当する製品はない

汎用画像診断装置ワークステーション用プログラム放射線治療計画プログラム etc

医療会計システム教育支援システム

etcこの領域に

該当する製品はない

必要不要法規制の要/不要

ヘルスケア上のリスク小さい

リスクの考慮

不要

大きい

電子カルテ医用画像管理システム地域医療連携システム

etcリスクの考慮

必要

ヘルスケア分野で利用されるソフトウエア


9

ヘルスケア上のリスクと法規制の関係

• 医療分野で利用されるソフトウエアの法規制とリスクの関係


ヘルスケア上のリスクがない


必要不要

法規制の要/不要

ヘルスケア上のリスク小さい

リスクの考慮

不要

大きい

薬機法の該当範囲

薬機法非該当だがヘルスケア上のリスクの予見と対応策が必要

この領域が今回のポイント！

リスクの考慮

必要


10

ヘルスケア上のリスクと法規制の関係

• 医療分野で利用されるソフトウエアの法規制とリスクの関係

ソフトウエア種別プラットホーム内容法規制対象

有無

ヘルスソフトウエア

医療機器または医療機器の一部のハードウェアで動作する

「医療機器ソフトウェア」のうち医療機器に組み込むことを目的として開発されたもの

法規制対象

汎用（非医療用）コンピューティングプラットフォームで動作する

A 「医療機器ソフトウェア」のうちそれ自体を医療機器として使用することを意図したもの

B「法規制対象外のヘルスソフトウェア」のうちリスクの考慮が必要なもの

法規制対象外

C「法規制対象外のヘルスソフトウェア」のうちリスク考慮の必要がないもの

では【リスク】とは何か？


11

ではリスクとは何か：まず言葉の定義

• 安全【Safety】に関係する用語の定義用語（日本語）用語（英語）定義

安全 Safety 受容できないリスクがないことリスク Risk 危害の発生確率×危害の重大さ

危害 Harm 人の受ける身体的傷害・健康的被害または財産もしくは環境の受ける害

ハザード Hazard 危害の潜在的な源

危険状態 Hazardous Situation 人・財産または環境が一つまたは複数のハザードに晒される状態

残留リスク Residual Risk 保護対策を施した後にも残るリスク

リスク分析 Risk Analysis 利用可能な情報を体系的に用いてハザードを特定しリスクを見積もること

リスク評価 Risk Evaluation リスク分析に基づき許容可能なリスクに到達したかどうかを判定する過程

リスクアセスメント Risk Assessment リスク分析およびリスク評価からなるすべてのプロセス

意図した使用目的 Intended Use 供給者が提供する情報に基づいた製品・プロセスまたはサービスの使用


12

ヘルスケア上のリスクとは何か？

• 法規制対象/非対象を区別する【リスク】とは何か？ • 安全【Safety】と危険性【Risk】は表裏一体。 • 「受容できないリスクがないこと」が安全【Safety】である。 • 絶対的な安全は定義できない。「安全」とは相対的な概念である。 • 「リスクが許容できるかどうか」も相対的な判断。「使用者の利便性」　　「目的適合性」「費用対効果」などの要因のバランスから決定される。

• 「リスク」は技術開発の進歩と関係している。技術開発のトレンドを　　　　把握して「リスクの許容可能性」を見直すことが必要。

• 「リスク」は危害の発生確率×危害の重大さで定義される。 • 安全【Safety】を実現するためには、安全【Safety】を考える対象物が　　　使われる場面【Intended Use】とその場面における危険性【Risk】を　　　把握することが必要。


13

安全（Safety）の実現

• 安全（Safety）を実現するためには…

• Intended Use（意図した使用目的）を　　決めなければならない。

•リスクを特定しなければならない。

14

Intended Useとは何か？（事例）• 安全【Safety】を実現するためには、安全【Safety を考える対象物が　　　使われる場面【Intended Use】とその場面における危険性【Risk】　（＝安全性【Safety】と表裏一体）を把握することが必要。

アイスキャンディ・バー

白樺材の薄い棒

小児用舌圧子（一般医療機器）

?さて使い途は？

（Intended Useは？）


15

Intended Useとは何か？（事例）• では小児用舌圧子のIntended Useとは何か？

• 診察される人の舌を移動させて、周辺臓器および組織の検査を容易にするために用いる。

• PMDA（医薬品医療機器総合機構）の医療機器基準データベースの一般的名称検索で調べてみると…

名称等舌圧子別表3-1004 , クラス I , コード：14066000 , GHTFルール：6 - ①

保守等特定保守：, 設置管理：, 修理区分：G9, QMS：, 設計管理：類別器15 舌圧子中分類挟器定義舌を移動させて、周辺臓器及び組織の検査を容易にするために用いる手術器具をいう。基準備考旧一般的名称：舌圧子　旧クラス分類：I


16

リスク分析（事例）• 小児用舌圧子のリスク分析をしてみると…

# ハザード（危害の潜在的な源）

予見できる一連の事象危険状態危害

設計・予防措置運用によるリスク低減策

安全に関する情報

1 ウイルスが付着したスティック

スティックを消毒しない

ウィルスが付着したスティックが小児の口に入る

小児がウイルス感染症に罹る

2大人用の

サイズの大きいスティック

大人用のスティックを小児にも使用する

大きなサイズのスティックを小児の口に入れる

小児の口の中を傷つける

3 小児が不安になるパッケージデザイン小児が怖がる小児が口を開けない

舌圧子を小児の口の中に入れることができないので診察できない

危害から遡上して検討すると考えやすい


17

リスク分析（事例）• 想定できるリスク低減策は…









滅菌された包装

2大人用の





小児に適したサイズ



小児にウケるパッケージデザイン

リスク低減策を連想する


18

リスク分析（事例）• リスク分析の結果の反映…（実際の製品での事例）

http://www.osakimedical.co.jp/medical/nursing_care/nsc002_005/

大人用よりも小さなサイズ

子供にウケる「かわいい」パッケージ

滅菌処理した梱包

19

リスク分析（事例）• 想定できるリスク低減策は…









滅菌された包装

包装や添付文書に滅菌済みと表記する

2大人用の





小児に適したサイズ

包装や添付文書に小児用サイズと表記する



小児にウケるパッケージデザイン

- - - - -

リスク低減策およびその明示方法を定義する


20

ヘルスソフトウエアのリスクへの配慮• 法規制対象外のソフトウエアであっても、ヘルスケアの現場での使用には　　　リスクが存在する。この医療分野に特有のリスクについての配慮・検討が必要。

• 公的な規制・規格はないため、業界が自主基準・自主ルールを制定し、　　　この運用の展開と適合宣言を取得した製品を拡大する活動を実施している。

• この活動が…

である。（2014年に一般社団法人ヘルスソフトウェア推進協議会を設立、開発ガイドラインVer.1.0.0を公開した。）


21


22

• GHSは医療機器産業に関わる3つの工業会がベースとなって、2014年に　　【一般社団法人ヘルスソフトウエア推進協議会】として設立された。

• 今後、増加が見込まれる法規制対象外で安全へのリスクの考慮が必要な　　ヘルスソフトウェアについて、利用者（患者・医療従事者）に優良な　　　　製品を提供するための取り組みを推進している。

GHS一般社団法人ヘルスソフトウエア推進協議会

関連学会・行政等

関連業界団体

GHSとは？（組織構成）

JIRA一般社団法人日本画像医療システム工業会

JAHIS一般社団法人保健医療福祉情報システム工業会

JEITA一般社団法人電子情報技術産業協会

その他の団体

運営会議

管理委員会

技術・教育委員会

普及委員会


23

GHSとは？（活動内容）• GHS開発ガイドラインの制定・更新→教育・普及活動の実施→適合製品の　公表・プロモーション等の行程を一貫して実施。

GHS開発ガイドラインおよび

適合性判定用リストの

制定と改訂

GHS開発ガイドラインの

教育・普及活動

GHS開発ガイドライン適合製品の公表プロモーション


24

GHS開発ガイドラインとは？• GHS開発ガイドライン：国際標準に準拠して開発・評価の手順を規定。

ISO 9001:2008 (JIS Q 9001:2008)

品質マネジメントシステム - 要求事項

ISO 14971:2007 (JIS T 14971:2012)

医療機器 - リスクマネジメントの医療機器への適用

IEC 82304-1:2016 （JIS T 82304-1:2017)

CD Health software - Part 1 General requirements for product safety

IEC 62304:2006 (JIS T 2304:2012)

医療機器ソフトウェアソフトウエアライフサイクルプロセス

品質マネジメント

開発ライフサイクル

リスクマネジメント

製品安全（バリデーション他）

JIS化手続き中

2016/10に正式発行済


25

GHS開発ガイドラインとは？• カテゴリー分類と推奨される要求事項・参考になる国際規格のリスト

カテゴリー推奨される要求事項参考になる国際規格

品質マネジメント設計開発プロセスISO 9001:2008 (JIS Q 9001:2008) 品質マネジメントシステム－要求事項


-リスク分析 -リスク評価 -リスクコントロール -残留リスク評価 -開発段階及び市販後情報注記の管理

ISO 14971:2007 (JIS T 14971:2012) 医療機器－リスクマネジメントの医療機器への適用

ヘルスソフトウエアの製品安全

-ユーザ要求分析および定義 -ソフトウエアバリデーション

-ソフトウエアの識別および関連文書作成IEC 82304-1:2016 (JIS T 82304:2017)

ソフトウエアライフサイクルプロセス

-ソフトウエア開発計画 -ソフトウエア要求分析

-ソフトウエア構成管理プロセス

IEC 62304:2006 (JIS T 2304:2012) 医療機器ソフトウェア－ソフトウエアライフサイクルプロセス

JIS策定手続き中


26

GHS開発ガイドラインとは？• ヘルスソフトウエア開発ガイドラインと適合宣言のレベル分け • 製品が内包するリスクの内容に応じて適合すべきレベルを3つ用意。

医療機器に要求される全ての項目（ISO 13485 等）

品質マネジメント

ヘルスソフトウェアの製品安全

ソフトウェアライフサイクルプロセス Level-3

リスクマネジメント Level-1

1

2項目

～

全項目

Level-2

医療機器医療機器に対する要求項目は

国・地域の規制内容により異なる

GHSマーク取得・適合宣言のLevel

ヘルスソフトウエア開発ガイドライン

要求事項


27

製品・市場状況に即した適合宣言• ヘルスソフトウエア開発ガイドラインへの適合 • 薬機法とは異なりヘルスソフトウエアガイドラインへの適合は自主宣言：法規制の対象ではない。 • トレンドは、非医療機器でも健康・医療分野で使用する製品はリスク　　分析・予防検討をしておくべき。 • リスク・マネジメントに基づく製品開発は製品および企業自身をProactiveに防衛できる活動。 • （とはいえ…）ヘルスケア分野へ新規参入した企業や非医療機器の製品　開発の経験しか有しない企業が、最初からフルセットのヘルスソフト　　ウエア開発ガイドラインに適合しようとするのは大変。

• GHSの適合宣言は3つのレベルを用意 • 製品の機能・利用する場面の変化、内包するリスクの内容を鑑みて、適合　　レベルを3つ用意。 • Level-1：リスク・マネジメントから始めて段階的に適合レベルを向上　できる。


28


29

適合宣言のための手順

• GHSは自主基準・自主ルールとして制定 • 制定された開発ガイドラインの運用とその適合確認の手順に沿った手続きを実施することで適合宣言が可能。

• チェックシートを用いて開発ガイドラインへの適合を確認 • GHSが提供するチェックシートを用いて、製品開発・評価プロセスが開発ガイドラインに適合していることを確認。

• 適合宣言の登録依頼とGHSマークの使用許諾 • GHS開発ガイドラインへの適合宣言の登録を依頼。 • 提出された関係書類の内容を確認し問題なければ、承認通知が発行される。• 並行してGHSロゴの使用許可とロゴデータ自体が提供される。 • GHSマーク付きの適合宣言書をGHS協議会に提出する。


30

適合宣言に関係する書面・活動

ガイドライントレーニング

GHS開発ガイドライン

テンプレート（各種様式）

ガイドライン適合報告書

リスクマネジメントチェックリスト：A

チェックリスト：B

チェックリスト：C

チェックリスト：D

GHS開発ガイドライン適合宣言書

Level-1,2,3

関係する書類

必要となる活動・文書

テンプレート記入ガイド

適合宣言実施ガイド

チェックリスト記入ガイド

(A) リスクマネジメント（必須） (B) 品質マネジメント (C) ヘルスソフトウエアの製品安全 (D) ソフトウエアライフサイクルプロセス Aは必須、B～Dは適宜選択


31

GHS開発ガイドラインY-$Z

�� -, cE)0�LKL -,LKM E)0�LKN �b:!`bG�

M )>b�4N F+12aG]e9%NKL �Bzvn{�tNKM ~olzvn{�tO y�oqxtijf8�F+aG]e9%

OKL �6OKM y�oqxtijf�)9%b�.�OKN qxtijfF+;*OKO qxtijf9%�H OKP qxtijf<; c�7

OKQ qxtijf=I cw~s�m|�OKR qxtijf~~�oOKS qxtijf#�/( c��/(P y�oqxtijfb@� c�)?��PKL �6

PKM y�oqxtijfb@�PKN �)?��Q y�oqxtijfb^db�A��QKL �6QKM y�oqxtijfb�A��

QKN w~s�m|�QKO y�oqxtijfaG]e�A��DQKP y�oqxtijfb�"TWWVXJTJkhu}h�b�3_\`C)TWWVXJUJ��p�xrg�b5[�`�'�&



32

適合を示すチェックリストガイドライン適合報告書

リスクマネジメントチェックリスト：A


33

適合宣言書の取得GHS開発ガイドライン適合宣言書

Level-1,2,3

チェックリスト：A

適合宣言フォーマット



34

ガイドライン適合 → 適合宣言までのフロー

GHS協議会事業者利用者



トレーニング開催

チェックリストテンプレート

適合宣言書フォーマット

チェックリスト（適合報告書）

適合宣言制度の理解

ガイドラインの理解

ガイドラインに準拠した開発

適合宣言書の発行

製品

適合宣言書


35

GHSマークの利用と適合宣言書の登録• GHSマーク • ヘルスソフトウエア製品がGHSに適合していることをアピールするマーク。 • 適合宣言書をGHS協議会に登録することにより使用許諾を取得できる。 • 登録の手続き

事業者 GHS協議会

① 適合宣言書 ② 登録申請書 ③ 適合報告書

事務所が内容を確認し問題なければ承認通知を発行

①～③の書類

登録番号

登録料

GHSマークの使用の手引きを添付

GHSマーク使用許可証 GHSマーク・データ

GHSマーク付き適合宣言書


36

GHSマーク利用基準

• GHSマークは対象製品に対して以下のような使い方が可能。 1)製品本体 2)製品のパッケージ 3)製品の表示画面 4)製品の取扱説明書 5)製品のカタログ・説明文書等 6)製品紹介のWEBサイト・プロモーション映像 7)製品の宣伝広告 8)その他のGHS評議会が許可した箇所

• 所定の位置に登録番号を必ず表示すること。 • 登録された製品についてのみ使用が可能。

G1400013

Horizontal type

G1400013

Vertical type

®

®


37

GHSマーク登録済み製品の状況• 登録済製品数：75（2017/11/01）

13

22345

8 8

14

16● 電子カルテ

● 画像情報管理システム

● ゲートウエイ

● 生体情報管理システム

● 放射線情報管理システム

● 地域医療情報システム

● 看護支援システム

● 眼科検査支援システム

● 健康管理システム

● その他


38

• ヘルスケア関連機器の変遷と認可制度 • ヘルスケア分野で利用されるソフトウエア • 法規制対象外ヘルスソフトウエアに関する活動：GHS • GHS適合宣言のための手順 • ヘルスソフトウエアに関係する規格群 • ヘルスソフトウエア開発管理の現状 • GHS活動に関する情報の提供

39

ガイドラインのベースとなる規格• 4つのカテゴリについて、夫々に国際規格を適用。 • IEC82304-1は2016年/10月に正式発行、現在JIS化作業中。

カテゴリー推奨される要求事項参考になる国際規格

品質マネジメント設計開発プロセスISO 9001:2008 (JIS Q 9001:2008) 品質マネジメントシステム－要求事項


-リスク分析 -リスク評価 -リスクコントロール -残留リスク評価 -開発段階及び市販後情報注記の管理

ISO 14971:2007 (JIS T 14971:2012) 医療機器－リスクマネジメントの医療機器への適用

ヘルスソフトウエアの製品安全

-ユーザ要求分析および定義 -ソフトウエアバリデーション -ソフトウエアの識別および関連文書作成

IEC 82304-1:2016 (JIS T 82304-1:2017)

ソフトウエアライフサイクルプロセス

-ソフトウエア開発計画 -ソフトウエア要求分析

-ソフトウエア構成管理プロセス

IEC 62304:2006 → IEC 62304 Am.1 Ed.1 (JIS T 2304:2017) 医療機器ソフトウェア－ソフトウエアライフサイクルプロセス

JIS策定手続き中


40

IEC82304とはどんな規格か？• 設計・開発・妥当性確認・据付・保守および廃棄を含むヘルス　ソフトウエア製品の全てのライフサイクルプロセスをカバー。

• 単体ソフトウエアがターゲット（特定のハードウエアの部分を　　構成するソフトウエアには適用しない。）

• 特定のハードウエアと組み合わせる医療機器ソフトウエアはIEC60601-1のスコープで製品安全を担保する。（単体ソフト　　ウエアを担保する製品安全規格はない。）

• 規格に包含される内容 • 【ヘルスソフトウエア】という領域を明確に定義している。 • 開発プロセスはIEC62304を引用。 • 妥当性確認（バリデーション）、製品ラベリングの要求事項を規定。 • 製品添付文書・据付・廃棄（データの廃棄を含む）の要求事項を規定。（IEC60601-1要求事項のソフトウエア製品を引用）


41

IEC 82304-1（JIS T 82304-1）の適用範囲

その他の健康用途に使用医療機器への使用

医療機器に組み込む

ソフトウエア

医療機器であるソフトウエア単独の製品

その他の健康用ソフトウエア単独の製品

(Standalone)IEC 82304-1

患者の診断・治療・モニタリングの支援、または補償・疾病・障害の軽減を意図することを含むヘルスユースのソフトウエア製品を対象としている。（Annex A）

その他の健康用ハードウエアに組み込む

ソフトウエア

専用ハードウエア

汎用

コンピューティング

プラットフォーム

IEC 62304 Ed.1の範囲

IEC 82304-1の範囲

(IEC 62A/ ISO 215 JWG7メンバー, Oliver P. Christ氏提供の図を一部改変) 42

IEC82304-1の要求事項概要-1

• リスクアセスメントの実施と文書化 • ヘルスソフトウエア製品の安全性に関連するハザードの識別とリスクの　評価。

• ISO14971に準拠できない独自のコンポーネントや非医療目的であるサブシステム、レガシーソフトウェアが構成に含まれる場合も考慮。

• ヘルスソフトウエア製品の使用要求の明確化と文書化 • ユーザプロファイルや使用環境の明示。 • プライバシーとセキュリティ要求（情報セキュリティ規格要求への流れ） • 保守要求（アップグレードに伴なうデータの完全性・ソフトウェア配布・データの破棄や転送）


43

IEC82304-1の要求事項概要-2

• 妥当性確認に対する要求事項 ❖ 意図する利用環境における使用要求を製品が満たす事の客観的証拠(Objective Evidence) を提示することを目的としている。 1) バリデーションプラン

• 使用要求に基づくバリデーション計画を作成する。

2) バリデーション実施

• バリデーション計画に基づいて、意図する使用環境でのバリデーションを実施する。

3) バリデーションレポート • インプットである使用要求とバリデーション結果のトレーサビリティ

• バリデーション実施条件とその結果

• 異常が発見された場合には問題解決プロセスの実施結果とともにリスト化

• バリデーション実施体制

• バリデーション結果のサマリー


44

IEC82304-1の要求事項概要-3• 製品の識別と付属文書 1) 使用説明書 • 製品の説明・安全性警告・インストール・起動と停止・取扱説明・廃棄（アンインストール）

2) 技術説明書 • 安全な運用・輸送・保管やソフトウエアをインストールし使用するために必要な技術的な情報

の提供

• ITネットワークで使用することを意図する場合に必要な情報の提供

• 市販後対応 1) ソフトウエア保守 • 保守の必要性に応じてヘルスソフトウエアを改修

2) 再バリデーション • ソフトウエア保守にともない再バリデーションを実施

3) 市販後情報伝達 • ユーザや責任組織への入手可能な修正版と情報の提供

4) 使用停止と廃棄 • 使用期限の終了とともに使用を停止し安全に製品を廃棄


45

T 82304の範囲内/範囲外のソフトウエア例範囲内範囲外

•健康用途のソフトウェア単独の製品 •特別なセンサ又は検出器注）を使わない機器で　動作するモバイルアプリケーション •検査情報ソフトウェア •放射線科情報ソフトウェア •フィットネスセンターの個人用ソフトウェア •受胎調節ソフトウェア •コンピュータ支援診断ソフトウェア •医用画像解析ソフトウェア •個人の診断，治療及び健康管理を目的とする　臨床診断支援ソフトウェア •フィードバック機能付き個人向けストレス緩和ソフトウェア •バリデーション療法の訓練計画ソフトウェア •アルツハイマー患者の活動刺激ソフトウェア •電子カルテシステムを含む、電子健康記録システム •病院情報システム •外部組織によって提供されるサービスとしてのヘルスソフトウェア

•実行可能でないソフトウェア。例えば、基準値の一覧など •個人の健康を扱わないソフトウェア •医事会計用ソフトウェア •病院の機器保守スケジュール管理ソフトウェア •疫学研究用ソフトウェア •看護師訓練用ソフトウェア •医療従事者の自己教育ソフトウェア •介護施設の電子日誌次の機器を制御するソフトウェア又はそのアップデートも適用範囲外である •JIS T 0601 規格群、JIS T 60601 規格群又は JIS T 80601 規格群の対象である医用電気機器又は医用電気システム •JIS C 1010 規格群の対象であるIVD 機器 •ISO14708規格群の対象である体内植込み機器

注）カメラ、マイク又はその他の、スマートフォン又はタブレットに一般的に用いられている機能は、特別なセンサ又は検出器とはみなさない。


46

JIS T 2304に規定するソフトウエアライフサイクルプロセス

T 82304-1で規定するヘルスソフトウエア製品のプロセス

ヘルスソフトウエア製品のプロセス

ユーザニーズユーザニーズへの適合市販後コミュニケーション

意図する使用の確立初期リスクアセスメントの実施

製品要求事項の確立バリデーション計画の確立

システム要求事項の確立

バリデーション報告書の作成

ヘルスソフトウエア製品のバリデーション

附属文書の作成

ヘルスソフトウエアの保守ヘルスソフトウエアの開発およびリリース

ソフトウエア保守および/または

市販後の活動の決定


47

IEC 62304 Ed.1.1（JIS T2304：2017）• IEC 62304 Am.1 Ed.1 IS発行（2015/06） • IEC 62304 Ed.1.1公開 • JIS改正：JIS T2304：2017（Ed.1.1ベース、2017/03官報公示） • 規制面での影響 • IEC 60601-1（JIS T 0601-1）【Ed.3.1】の14章の要求事項にて、IEC 62304（JIS T 2304）が参照される。

• 日本では、平成27年11月より新基本要件基準第12条2の「最新の技術に基づく開発のライフサイクル、リスクマネジメント並びに当該医療機器を適切に動作させるための確認及び検証の方法」としてJIS T 2304への適合性の確認がうたわれている。


48

• ソフトウエア安全クラスソフトウェアシステムのソフトウェア安全クラスを決める際には、・ソフトウェア故障の発生確率は【1】とする。・ソフトウェアシステムの外部にあるリスクコントロール手段　だけを考慮する。

IEC 62304 Ed.1.1（JIS T2304：2017）

クラスC（デフォルト）

ソフトウエアは危険状態の一因になるか？

ソフトウエアの外部にあるリスクコントロール手段の

有効性を評価する

ソフトウエアにより受容できない

リスクを生じるか？

どのような障害の可能性があるか？

クラスA

クラスB クラスC

死亡または重傷の可能性がある重傷の可能性はない

いいえ

いいえ

注記：ソフトウエアシステムの外部で実施するリスクコントロール手段は、ソフトウエアの故障が危害を起こす発生確率及び/又は危害の重大さを減少させることが　できる。注記：リスクコントロール手段を実装したソフトウェアシステムが故障することもあるし、この故障が危険状態の一因になるかもしれない。結果として起こる危害には、リスクコントロール手段が防ぐことを意図した危害を含むことがある。[7.2.2 b) 参照] 注記：外部のリスクコントロール手段は、ソフトウエアが危険状態の一因となる可能性を最小限に抑えるために、ハードウェア、独立したソフトウエアシステム、医療処置又は他の手段とすることができる。 7.2.1 リスクコントロール手段の選択注記：リスクコントロール手段は、ハードウエア、ソフトウエア、動作環境又は取扱　説明書において実施できる。


49

IEC 62304 Ed.1.1（JIS T2304：2017）

• ソフトウエア安全クラス • ハードウエアのリスクコントロール手段だけでなく、ソフトウエア外部のリスクコントロール手段でクラスダウンが可能になった。

• 組織がすべてのソフトウエアアイテムにクラスCを適用すると判断することは規格上は可能だが、少なくとも4.3c)の安全クラスの文書化は必要になる。

• 安全クラスの判定の際には、【ソフトウエア（システム）の外部にある　　リスクコントロール手段だけを考慮する】という限定付き。　　　　　　　　　（システム全体に適用するリスクマネジメントの論理とは異なる。）

• クラスAにクラスダウンできる場合は、ソフトウエアシステム外部のリスク　　　　コントロール手段によってリスクが受容可能になる場合だけである。

• あるソフトウエアアイテム、それ自身がリスクコントロール手段にかかわる機能を　実装している場合、そのソフトウエアアイテムをクラスAにすることはできない。


50

IEC 62304 Ed.1.1（JIS T2304：2017）• レガシーソフトウエアの適用 • 主に欧州からの要求（FDAはこの概念を認めていない） • 定義上は、【規格の現行版】以前に開発し、継続販売しているもの。規格が改訂されると、規格の差分について対象となる。

• Am.1が主に想定しているのは、62304:2006発行以前に開発され継続販売しており手を入れていないソフトウエアをそのまま規格適合させるケース。

医療機器ソフトウエア

医療機器IEC 62304:2006

開発

上市

販売以下の適合性を評価 • リスクマネジメントアクティビティ •ギャップ分析 •ギャップ解消アクティビティ • レガシーソフトウェアを使用する根拠

レガシーソフトウエアとして継続使用


51

IEC 62304 Ed.1.1（JIS T2304：2017）

• その他の変更項目（抜粋） • Class Aへの要求項目の追加 • ソフトウエアテストについて【Class A/B/C】へ要求を拡大 • 7.1.5, 7.3.2の削除 • ISO 14971の要求事項との整合性を確保（重複の解消） • 既知のソフトウエア欠陥の特定および回避（5.1.12） • Class B,Cへの要求事項 • 選択したプログラミング技術によって生じる可能性のある欠陥を分類する。 • これらの欠陥が受容できないリスクの一因にならないことを示す。 • IEC/TR 80001-1:2009 附属書B

ゼロ割、数値のオーバフロー/アンダーフロー、誤ったポインタ、誤った初期化、メモリリーク、スタックオーバフロー、無限ループ等

• 静的解析ツール等の使用だけでなく、その運用・適用の仕方およびコーディング規約の適用なども考慮する。


52

IEC 62304 Ed.2における適用範囲の拡大

その他の健康用途に使用医療機器への使用

患者の診断・治療・モニタリングの支援、または補償・疾病・障害の軽減を意図することを含むヘルスユースのソフトウエア製品を対象としている。（Annex A）

専用ハードウエア

（IEC 60601-1）

汎用

コンピューティング

プラットフォーム

（IEC 60950-1）


IEC 82304-1の範囲


医療機器に組み込む

ソフトウエア

医療機器であるソフトウエア単独の製品

その他の健康用ソフトウエア単独の製品

(Standalone)

その他の健康用ハードウエアに組み込む

ソフトウエア

IEC 82304-1

(IEC 62A/ ISO 215 JWG7メンバー, Oliver P. Christ氏提供の図を一部改変) 53

ヘルスソフトウエアおよびヘルスITシステムのコンポーネントモデルと規格の関係

製品コンセプトと要件定義

設計

開発

テスト・検証・文書化

製造・リリース

調達

（製造業者の法令遵守を含む）

インストール

カスタマイズ・設定

インテグレーション

データ移行・移動・妥当性確認

導入・ワークフローの最適化

トレーニング

運用と保守

廃止・廃棄

IT/IMの運営組織文化・役割・権限システム・ソフトウエアのライフサイクルプロセスリスク管理

品質管理ソフトウエアのライフサイクルを考慮した安全管理プロセス

ヒューマンファクタ、ユーザビリティと変更管理

プライバシとセキュリティ管理

設計 & 開発行程導入行程臨床使用行程

基本原則・概念・定義

製造業者の責務（IEC 62304,82304-1、他）

ヘルスサービス組織の責務（IEC 80001-1、リスクマネジメント）

Health Software Ad hoc Group Draft Report ‒ September 2014 Health Software and Health IT Safety Standards FUTURE STATE Architecture/Framework and Roadmap ‒ DRAFT Report より

54

IEC 62304 Ed.2 および IEC 80001-1 Ed.2における主な検討項目

• スコープの拡大 • 医療機器ソフトウエアからヘルスソフトウエアの領域まで拡大 • ヘルスソフトウエア領域の規格フレームワークの策定 • 製造業者とヘルスサービス組織の責任分担。 • IEC 62304/82304-1 と IEC 80001-1の住み分けと相互補完 • 非医療機器への適用とそれに関連する問題点の検討 • 汎用ソフトウエアライフサイクルプロセス（ISO12207等）との関係

• 非医療機器に要求される品質マネジメントの適切なレベル

• ソフトウエアリスクマネジメントの適用にかかわる諸々の問題


55



56

Standalone型ソフトウエア開発管理

• 医療機器製造業/製造販売業許可の取得

未取得46% 取得済

54%

医療機器製造業製造販売業許可の取得有無

http://www.meti.go.jp/committee/kenkyukai/shoujo/iryou_software/pdf/report_001_03.pdf57

Standalone型ソフトウエア開発管理• 品質マネジメントシステムの利用状況

未運用19%

運用検討中6%

運用中75%

自社独自10%

QRS（米国）9%

QMS（日本）25% ISO13485

21%

ISO900135%

自社独自21%

QMS（日本）4%

ISO134857%

ISO900168%

品質マネジメントシステムの運用

製造業/製販業取得業者

製造業/製販業未取得業者


Standalone型ソフトウエア開発管理• リスクマネジメントシステムの利用状況

未運用9%

運用検討中31% 運用中

60%

自社独自27%

国際標準3% ISO14971

70%

自社独自79%

国際標準7%ISO14971

14%

リスクマネジメントシステムの運用




Standalone型ソフトウエア開発管理• プロセスマネジメントシステムの利用状況

未運用41%

運用検討中10%

運用中49%

自社独自20%

CMMI10%

IEC122077%

ISO6230463%

自社独自82%

CMMI6%IEC62304

12%

プロセスマネジメントシステムの運用




医療関係ソフトウエアの開発・販売の課題

0

10

20

30

40

8

3229

353533

薬機法対象の範囲が不明確

事故発生時の責任が大きい

ユーザの誤使用による事故のリスクがある

開発コストが大きく

それに見合う利益が得られない

医療等に詳しい開発技術者が不足している

その他


• ヘルスケア関連機器の変遷と認可制度 • ヘルスケア分野で利用されるソフトウエア • 法規制対象外ヘルスソフトウエアに関する活動：GHS • GHS適合宣言のための手順 • ヘルスソフトウエアに関係する規格群 • ヘルスソフトウエア開発管理の現状 • GHSの活動のポイントを整理

62

GHSの活動のポイント• GHSの活動とは… • 法規制対象外のヘルスソフトウェアを対象に「GHSヘルスソフトウェア開発ガイドライン」を策定

• GHSヘルスソフトウエア開発ガイドラインの目的 GHSヘルスソフトウエア開発ガイドラインは、法規制対象外のヘルスソフトウエアの開発者や事業者、また、法規制対象外のヘルスソフトウエアの開発や事業に新規参入する者がこれを適用することによって、ヘルスソフトウエア利用者に安全な　ソフトウエアやサービスを提供できるようになることを目的としています。

• ガイドラインの改定と維持活動• ガイドラインの認知度を高める普及活動

63

GHSの活動のポイント• GHSの活動とは… • ガイドラインへの適合に関する自主ルールとして「GHS開発ガイドライン適合宣言実施ガイド」を策定・公表し、運用を実施

• ガイドラインに準拠した開発を実施 • チェックリストによる準拠性の確認 • 自己宣言としてのガイドライン適合の宣言「本製品は、利用者に対する安全性と品質を確保するために、ヘルスソフトウェア推進協議会のGHS開発ガイドラインに準拠して開発されています」

• 協議会への適合宣言書の登録• GHSマークの使用（宣言書、製品等）

64

適合宣言制度-1

• 適合宣言書による適合の宣言 • 協議会提供の書式を用いる • 事業者の自己責任での発行 • 3段階の適合レベルを設定 • リスクマネジメントは必須項目（全てのレベルにて必須） • 4つの要求事項に準じ対応することが可能（装置の機能向上や開発体制の整備状況に合わせてステップアップ）

• 適合宣言書の登録制度 • 協議会による内容の確認 • GHSマークの使用を許可（宣言書、製品等）

65

適合宣言制度-2• 対象製品の開発がガイドラインに準拠していることの自己宣言 • 製品の安全性や品質についての宣言ではない • 安全性や品質に留意して開発していることの宣言である • GHSマークは認証マークではない • 適合宣言書の内容を保証するのは事業者 • 登録申請の書類については協議会が細かく確認する

66

リスク対応を考慮した ヘルスソフトウエアの製品化リスク対応を考慮した...

Documents

リスク対応を考慮したヘルスソフトウエアの製品化リスク対応を考慮した...