JIS T 81001-5-1 5.8.2 b)について

質問
0
ecompliance
6月 19, 2025 08:56 AM 1 Answers 医療機器規制全般
Member Since Jan 2021
Subscribed Subscribe Not subscribe
Flag(0)

JIS T 81001-5-1

5.8.2 リリースの文書化
b) プロセスの厳密性及び適合性の文書化

 

上記に関して、
”製造業者は、「プロセスの厳密性及び適合性」に関する内容をリリースノート等へ文書化し、
責任部所又は操作者へ提供する”ことが要求されていると解釈しました。
しかし、付属書Eを拝見しても、「プロセスの厳密性及び適合性」に相当する記載内容が読み解けませんでした。

 

JIS T 81001-5-1 5.8.2 b) で具体的に要求されていることは何になりますでしょうか。
文書化するドキュメントの例と、文書化の内容に関する参考仕様をご教示いただけますでしょうか。

0 Subscribers
Submit Answer
1 Answers
Sort By:
Best Answer
0
ecompliance
6月 19, 2025
Flag(0)

JIS T 81001-5-1の箇条5.8.2 b) 「プロセスの厳密性および適合性の文書化。これは、適用範囲の特定(箇条4)、プロセスの調整(箇条5)および文書化の対象範囲についての情報(附属書E)を含む。」が要求する「プロセスの厳密性および適合性の文書化」は、以下の3つの要素を明確に文書化することです。

  1. 適用範囲の特定 - 何に対して、どこまでセキュリティ活動を適用したか
  2. プロセスの調整 - 既存のプロセスにどのようにセキュリティを統合したか
  3. 文書化の対象範囲 - 附属書Eに基づき、何を文書化したか

これらの文書化により、組織がセキュリティを開発プロセスに適切に組み込み、体系的に管理していることを実証できます。重要なのは、セキュリティを独立した活動としてではなく、既存の医療機器開発プロセスに統合された活動として文書化することです。

要求事項の解釈

この要求事項は、セキュリティ活動を既存の医療機器開発プロセスにどのように統合したかを文書化することを求めています。具体的には以下の3つの要素を含む必要があります:

1. 適用範囲の特定(箇条4)

  • どのソフトウェア/システムに対してJIS T 81001-5-1を適用したか
  • どの範囲でセキュリティ活動を実施したか
  • 適用除外がある場合はその根拠

2. プロセスの調整(箇条5)

  • 既存の開発プロセスにセキュリティ活動をどのように統合したか
  • QMS、リスクマネジメント、ソフトウェア開発プロセスとの調整方法
  • 組織体制や役割分担の調整

3. 文書化の対象範囲(附属書E)

  • 附属書Eのガイダンスに基づき、何を文書化したか
  • 作成した文書の一覧と概要

文書化の具体例

1. リリースノートへの記載例

【バージョン2.1.0 リリースノート】

■ プロセスの厳密性および適合性に関する情報

1. 適用範囲の特定(JIS T 81001-5-1 箇条4準拠)
   
   1.1 対象システム
   - システム名:○○医療情報管理システム
   - バージョン:2.1.0
   - コンポーネント:
     * Webアプリケーション(患者情報管理)
     * モバイルアプリケーション(医療従事者用)
     * データベースサーバー
     * API Gateway
   
   1.2 セキュリティ活動の適用範囲
   - 全体適用:
     * セキュリティリスク分析
     * セキュアコーディング規約
     * セキュリティテスト基本項目
   - 部分適用:
     * ペネトレーションテスト(外部接続機能のみ)
     * 暗号化実装(患者情報を扱う機能のみ)
   
   1.3 適用除外とその根拠
   - 除外項目:内部計算処理モジュール
   - 根拠:外部接続なし、患者情報を扱わない

2. プロセスの調整(JIS T 81001-5-1 箇条5準拠)
   
   2.1 既存プロセスとの統合
   - QMS(ISO 13485)との統合:
     * 設計管理プロセスにセキュリティ設計レビューを追加
     * 是正・予防処置(CAPA)にセキュリティインシデント対応を統合
   
   - リスクマネジメント(ISO 14971)との統合:
     * ハザード分析にセキュリティ脅威を追加
     * リスクコントロール手段にセキュリティ対策を含める
     * 残留リスク評価にセキュリティリスクを含める
   
   - ソフトウェア開発(JIS T 2304)との統合:
     * ソフトウェア開発計画にセキュリティ計画を統合
     * ソフトウェアアーキテクチャにセキュリティアーキテクチャを含める
     * 各検証フェーズにセキュリティテストを追加
   
   2.2 組織体制の調整
   - セキュリティ責任者の任命
   - 開発チームへのセキュリティ教育実施
   - セキュリティレビューボードの設置

3. 文書化の対象範囲(附属書E参照)
   
   3.1 作成した主要文書
   - セキュリティ管理計画書(SMS-001)
   - セキュリティ要求事項仕様書(SRS-001)
   - 脅威モデリング報告書(TMR-001)
   - セキュリティリスク分析書(SRA-001)
   - セキュリティテスト報告書(STR-001)
   - SBOM(Software Bill of Materials)(SBOM-001)
   
   3.2 既存文書への追記
   - ソフトウェア開発計画書:セキュリティ活動を追加
   - リスクマネジメントファイル:セキュリティリスクを追加
   - 検証計画書:セキュリティテスト項目を追加

2. プロセス調整報告書の構成例

プロセス調整報告書
文書番号:PSR-2024-001
作成日:2024年○月○日

1. エグゼクティブサマリー
   本報告書は、JIS T 81001-5-1の要求事項を既存の品質マネジメントシステムに
   統合した方法と、その実施結果を文書化したものである。

2. 適用範囲の決定プロセス
   
   2.1 対象システムの特定
   - システム構成の分析
   - セキュリティ境界の定義
   - インターフェースの識別
   
   2.2 リスクベースアプローチ
   - 初期リスク評価の実施
   - セキュリティ要求レベルの決定
   - 適用範囲の最適化

3. プロセス統合の詳細
   
   3.1 ライフサイクルプロセスへの統合
   
   【計画フェーズ】
   - 既存:ソフトウェア開発計画
   - 追加:セキュリティ管理計画
   - 統合方法:単一の統合開発計画として作成
   
   【要求分析フェーズ】
   - 既存:機能要求、性能要求
   - 追加:セキュリティ要求
   - 統合方法:要求事項マトリックスに統合
   
   【設計フェーズ】
   - 既存:アーキテクチャ設計
   - 追加:セキュリティアーキテクチャ、脅威モデリング
   - 統合方法:設計レビューで一括確認
   
   【実装フェーズ】
   - 既存:コーディング規約
   - 追加:セキュアコーディング規約
   - 統合方法:統一コーディング規約として整備
   
   【検証フェーズ】
   - 既存:機能テスト、性能テスト
   - 追加:セキュリティテスト
   - 統合方法:統合テスト計画で管理
   
   3.2 文書体系の統合
   - マスター文書リストの更新
   - 文書番号体系の拡張
   - 相互参照の確立

4. 実施結果の評価
   
   4.1 統合の効果
   - プロセスの重複排除
   - レビュー効率の向上
   - トレーサビリティの確保
   
   4.2 課題と対策
   - 識別された課題
   - 実施した対策
   - 継続的改善計画

5. 附属書
   - 統合プロセスフロー図
   - 文書相関図
   - 役割分担表(RACI)

3. 文書化対象範囲チェックリスト(附属書E準拠)

セキュリティ文書化チェックリスト
プロジェクト:○○医療情報管理システム
バージョン:2.1.0

【計画段階】
□ セキュリティ管理計画
  - 文書番号:SMS-001
  - 作成日:2024/○/○
  - 概要:プロジェクト全体のセキュリティ活動計画

□ セキュリティリスク管理計画
  - 文書番号:SRMP-001
  - 作成日:2024/○/○
  - 概要:セキュリティリスクの特定・評価・対策計画

【要求分析段階】
□ セキュリティ要求事項仕様
  - 文書番号:SRS-001
  - 作成日:2024/○/○
  - 概要:機能・非機能セキュリティ要求の定義

□ 脅威モデル
  - 文書番号:TM-001
  - 作成日:2024/○/○
  - 概要:システムに対する脅威の分析結果

【設計段階】
□ セキュリティアーキテクチャ設計
  - 文書番号:SAD-001
  - 作成日:2024/○/○
  - 概要:セキュリティ機能の設計詳細

□ セキュリティ設計仕様
  - 文書番号:SDS-001
  - 作成日:2024/○/○
  - 概要:セキュリティ実装の詳細設計

【実装段階】
□ セキュアコーディングガイドライン
  - 文書番号:SCG-001
  - 作成日:2024/○/○
  - 概要:開発者向けセキュアコーディング規則

□ コードレビュー記録
  - 文書番号:CRR-001~050
  - 作成日:2024/○/○~○/○
  - 概要:セキュリティ観点でのコードレビュー結果

【検証段階】
□ セキュリティテスト計画
  - 文書番号:STP-001
  - 作成日:2024/○/○
  - 概要:セキュリティテストの範囲と方法

□ セキュリティテスト報告
  - 文書番号:STR-001
  - 作成日:2024/○/○
  - 概要:テスト結果と残留リスク評価

□ ペネトレーションテスト報告
  - 文書番号:PTR-001
  - 作成日:2024/○/○
  - 概要:第三者によるセキュリティ評価結果

【保守段階】
□ SBOM(ソフトウェア部品表)
  - 文書番号:SBOM-001
  - 作成日:2024/○/○
  - 概要:使用コンポーネントと脆弱性情報

□ 脆弱性管理手順
  - 文書番号:VMP-001
  - 作成日:2024/○/○
  - 概要:脆弱性の監視・評価・対応手順

□ インシデント対応計画
  - 文書番号:IRP-001
  - 作成日:2024/○/○
  - 概要:セキュリティインシデント発生時の対応

トランジションヘルスソフトウェアへの対応

既存のヘルスソフトウェアに対してJIS T 81001-5-1を適用する場合:

トランジション計画書(例)

1. 現状評価(ギャップ分析)
   - 既存のセキュリティ対策の棚卸し
   - JIS T 81001-5-1要求事項とのギャップ特定
   - リスクベースの優先順位付け

2. 段階的適用計画
   フェーズ1(3ヶ月):
   - 重大な脆弱性への対応
   - 基本的なセキュリティ文書の整備
   
   フェーズ2(6ヶ月):
   - プロセスの統合
   - セキュリティテストの実施
   
   フェーズ3(12ヶ月):
   - 完全適合の達成
   - 継続的改善プロセスの確立

3. 文書化方針
   - 既存文書の活用と拡張
   - 新規作成が必要な文書の特定
   - 段階的な文書整備計画
Sign in to Reply
Replying as Submit

関連記事一覧