mcpField
Q
quality-documentation-manager

quality-documentation-manager

github.com/borgheiドキュメント1.0k136 回インストール6 日前に更新
リポジトリ

quality-documentation-manager について

ISO 13485準拠の品質マネジメントシステムにおける文書管理を設計・運用するスキルです。文書のライフサイクル、採番、レビュー、承認、変更管理、21 CFR Part 11の管理策を扱い、メタデータ検証スクリプトも備えています。

主な機能

  1. 01文書ライフサイクルと管理フロー
  2. 02採番と改訂規則
  3. 03レビューと承認ルート
  4. 04変更分類と影響確認
  5. 0521 CFR Part 11管理策のガイダンス
  6. 06文書メタデータ検証ツール

活用シーン

  1. 01ISO 13485文書管理プロセスの構築
  2. 02文書番号と承認ルートの策定
  3. 03変更評価と改訂履歴の管理
  4. 04文書メタデータと署名の検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/borghei/claude-skills --skill quality-documentation-manager

インストール後、Claude Code で/quality-documentation-managerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
21cfr11-compliance-guide.md
document-control-procedures.md
scripts/
document_validator.py

詳細

品質文書管理者

ISO 13485 準拠の品質マネジメントシステムにおける文書管理システムの設計と管理。番号付け規則、承認ワークフロー、変更管理、電子記録への適合を含みます。


目次


最初に確認すること

文書管理を設定したり、文書を検証したりする前に、以下の入力情報を確定してください。情報が不足している、または曖昧で、結果に影響する場合は確認してください。影響しない場合は、妥当な既定値を使用し、使用した値を明示してください。

  • 文書の種類: QM、SOP、WI、TF、SPEC、または PLN(必要なレビュー担当者、承認者、番号付けを決定します)。
  • 規制範囲: ISO 13485 のみ、または 21 CFR Part 11 の電子記録(監査証跡および電子署名の管理が必要かどうかを決定します)。
  • 変更区分: 管理上、軽微、重大、または緊急(承認経路と影響評価を決定します)。

リスト全体ではなく、この依頼で特に重要な 2、3 項目について確認してください。ユーザーがすぐに結果を求めている場合は、結果を提示し、冒頭に前提条件を明記してください。

文書管理ワークフロー

作成から廃止まで、文書管理を実施します。

  1. 番号付け手順に従って文書番号を割り当てる
  2. 管理対象テンプレートを使用して文書を作成する
  3. 必要なレビュー担当者にレビューを依頼する
  4. レビューコメントに対応し、回答を文書化する
  5. 必要な承認署名を取得する
  6. 発効日を割り当て、配布する
  7. 文書マスターリストを更新する
  8. 検証: 文書が使用場所で参照できること、旧版が撤去されていること
文書のライフサイクル段階
段階定義必要な対応
草案作成中または改訂中作成者が編集中。使用不可
レビューレビューのため回覧中レビュー担当者がフィードバックを提供
承認済みすべての署名を取得済みトレーニング/配布の準備完了
発効トレーニング完了、リリース済み使用可能
置換済み新しい改訂版に置き換え済み現行版としての使用を停止
廃止適用対象外保存期間スケジュールに従って保管
文書の種類と接頭辞
接頭辞文書の種類一般的な内容
QM品質マニュアルQMS の概要、適用範囲、方針
SOP標準作業手順書プロセスレベルの手順
WI作業指示書タスクレベルの手順を段階的に記載
TFテンプレート/フォーム管理対象フォーム
SPEC仕様書製品/プロセスの仕様
PLN計画書品質/プロジェクト計画
文書の種類ごとの必須レビュー担当者
文書の種類必須レビュー担当者必須承認者
SOPプロセスオーナー、QAQA マネージャー、プロセスオーナー
WIエリアスーパーバイザー、QAエリアマネージャー
SPECエンジニアリング、QAエンジニアリングマネージャー、QA
TFプロセスオーナーQA
設計文書設計チーム、QA設計管理責任者

文書番号付けシステム

識別と検索のため、一貫性のある文書番号を割り当てます。

番号付け形式

標準形式:PREFIX-CATEGORY-SEQUENCE[-REVISION]

Example: SOP-02-001-A

SOP = Document type (Standard Operating Procedure)
02  = Category code (Document Control)
001 = Sequential number
A   = Revision indicator
カテゴリーコード
コード機能領域説明
01品質マネジメントQMS 手順、マネジメントレビュー
02文書管理この領域
03人事トレーニング、コンピテンシー
04設計・開発設計管理プロセス
05購買サプライヤー管理
06製造製造手順
07品質管理検査、試験
08CAPA是正・予防措置
09リスクマネジメントISO 14971 プロセス
10規制対応申請、コンプライアンス
番号付与ワークフロー
  1. 作成者が文書管理部門に文書番号を申請します
  2. 文書管理部門がカテゴリーの割り当てを確認します
  3. 文書管理部門が次に利用可能な連番を割り当てます
  4. 文書マスターリストに番号を記録します
  5. 作成者が割り当てられた番号を使用して文書を作成します
  6. 検証: 番号の形式が標準と一致していること、マスターリストに重複がないこと
改訂の指定
変更の種類改訂番号の増分例
メジャー改訂番号を増やすRev 01 → Rev 02
マイナー改訂サブ改訂番号を増やすRev 01 → Rev 01.1
管理上の変更変更なし、または文字の接尾辞Rev 01 → Rev 01a

番号付与に関する詳細なガイダンスについては、references/document-control-procedures.md を参照してください。


承認およびレビューのプロセス

文書をリリースする前に、必要なレビューと承認を受けてください。

レビューワークフロー
  1. 作成者が文書のドラフトを完成させます
  2. 作成者がルーティングフォームまたは DMS を通じてレビューを依頼します
  3. 文書の種類に基づいてレビュー担当者を割り当てます
  4. レビュー担当者がレビュー期間内(5~10 営業日)にコメントを提供します
  5. 作成者がコメントに対応し、回答を記録します
  6. 作成者が改訂した文書を再提出します
  7. 承認者が署名し、日付を記入します
  8. 検証: 必須のレビュー担当者全員がレビューを完了していること、すべてのコメントに文書化された処置を伴う対応がなされていること
コメントへの対応
処置必要な対応
受け入れコメントを記載どおりに反映します
変更して受け入れ変更を加えて反映し、理由を記録します
却下反映せず、根拠を記録します
保留今後の改訂で対応し、理由を記録します
承認マトリックス
Document Level 1 (Policy/QM): CEO or delegate + QA Manager
Document Level 2 (SOP): Department Manager + QA Manager
Document Level 3 (WI/TF): Area Supervisor + QA Representative
署名要件
項目要件
氏名署名者の活字体で記載した氏名
署名手書きまたは電子署名
日付署名を行った日付
役割署名者の機能/役割

変更管理プロセス

レビューと承認を通じて、文書の変更を体系的に管理します。

変更管理ワークフロー
  1. 文書の変更が必要な理由を特定します
  2. 変更申請フォームに理由を記入します
  3. 文書管理部門が変更番号を割り当て、申請を記録します
  4. 影響評価のため、レビュー担当者に回付します
  5. 変更区分に基づいて承認を取得します
  6. 作成者が承認された変更を実施します
  7. 改訂番号と変更履歴を更新します
  8. 検証: 変更内容が承認された範囲と一致していること、変更履歴が完全であること
変更区分
区分定義承認レベル例
管理上の変更内容への影響なし文書管理部門誤字、書式
軽微限定的な内容変更プロセスオーナー+QA明確化
重大内容への大きな変更全レビューサイクル新しい要件
緊急安全性/コンプライアンス上の緊急対応迅速な対応+事後レビュー安全上の問題
影響評価チェックリスト
影響領域評価に関する質問
トレーニング変更に伴い再トレーニングが必要ですか?
機器変更は機器またはシステムに影響しますか?
バリデーション変更に伴い再バリデーションが必要ですか?
規制変更は規制当局への提出書類に影響しますか?
その他の文書更新が必要な関連文書はどれですか?
記録影響を受ける記録は何ですか?
変更履歴の文書化

各文書には変更履歴を含める必要があります。

| Revision | Date | Description | Author | Approver |
|----------|------|-------------|--------|----------|
| 01 | 2023-01-15 | Initial release | J. Smith | M. Jones |
| 02 | 2024-03-01 | Updated workflow | J. Smith | M. Jones |

21 CFR Part 11 への準拠

FDA 準拠のために、電子記録および電子署名の管理を実装します。

Part 11 の適用範囲
適用対象適用対象外
FDA 規制で要求される記録紙の記録
FDA に提出する記録規制対象外の社内文書
必須記録に対する電子署名一般的なメールでのやり取り
電子記録の管理
  1. 正確性と信頼性についてシステムを検証します
  2. すべての変更について安全な監査証跡を実装します
  3. システムへのアクセスを許可された個人に制限します
  4. 人が読み取れる形式で正確なコピーを生成します
  5. 保存期間全体を通じて記録を保護します
  6. 検証: 監査証跡に、すべての変更について誰が、何を、いつ行ったかを記録します
監査証跡の要件
要件実装
安全であることユーザーが変更できない
コンピューターによる生成システムが自動的に作成する
タイムスタンプ付き各操作の日付と時刻
元の値変更前の値を保持する
ユーザーの識別情報各変更を行った人物
電子署名の要件
要件実装
個人に固有であること個人間で共有しない
2つ以上の要素最低限、ユーザー ID とパスワード
署名の表示氏名、日時、意味を表示する
記録に紐付けられていること切り離しやコピーができない
署名の表示

すべての電子署名には、以下を表示する必要があります。

要素例
印字氏名John Smith
日付と時刻2024-03-15 14:32:05 EST
意味リリースを承認
システム管理チェックリスト

アクセス制御:

  • 各個人に固有のユーザー ID を割り当てる
  • パスワードの複雑さを強制する
  • 認証失敗後にアカウントをロックする
  • 非アクティブ状態が続いた後にセッションをタイムアウトさせる

監査証跡:

  • すべての記録の作成を記録する
  • すべての変更について変更前と変更後の値を記録する
  • ユーザーの識別情報を記録する
  • すべての記録に日付と時刻のタイムスタンプを付与する

セキュリティ:

  • ロールベースのアクセス制御
  • 保存時および転送時のデータ暗号化
  • 定期的なバックアップと復旧テスト

詳細な準拠要件については、references/21cfr11-compliance-guide.md を参照してください。


参考ドキュメント

文書管理手順

references/document-control-procedures.md の内容:

  • 文書番号体系と形式
  • 文書のライフサイクル段階と移行
  • 審査および承認ワークフローの詳細
  • 分類基準を含む変更管理プロセス
  • 配布方法とアクセス制御方法
  • 記録の保存期間と廃棄手順
  • 文書マスターリストの要件
21 CFR Part 11 準拠ガイド

references/21cfr11-compliance-guide.md の内容:

  • Part 11 の適用範囲と適用対象
  • 電子記録の要件(§11.10)
  • 電子署名の要件(§11.50、11.100、11.200)
  • システム管理仕様
  • 検証のアプローチと文書化
  • 準拠チェックリストとギャップ評価テンプレート
  • FDA による一般的な指摘事項とその予防

ツール

文書バリデーター
# Validate document metadata
python scripts/document_validator.py --doc document.json

# Interactive validation mode
python scripts/document_validator.py --interactive

# JSON output for integration
python scripts/document_validator.py --doc document.json --output json

# Generate sample document JSON
python scripts/document_validator.py --sample > sample_doc.json

以下を検証します:

  • 文書番号規則への準拠
  • タイトルとステータスの要件
  • 日付の検証(発効日、レビュー期限)
  • 文書の種類ごとの承認要件
  • 変更履歴の完全性
  • 21 CFR Part 11 の管理(監査証跡、署名)
文書入力例
{
  "number": "SOP-02-001",
  "title": "Document Control Procedure",
  "doc_type": "SOP",
  "revision": "03",
  "status": "Effective",
  "effective_date": "2024-01-15",
  "review_date": "2025-01-15",
  "author": "J. Smith",
  "approver": "M. Jones",
  "change_history": [
    {"revision": "01", "date": "2022-01-01", "description": "Initial release"},
    {"revision": "02", "date": "2023-01-15", "description": "Updated workflow"},
    {"revision": "03", "date": "2024-01-15", "description": "Added e-signature requirements"}
  ],
  "has_audit_trail": true,
  "has_electronic_signature": true,
  "signature_components": 2
}

文書管理指標

文書管理システムのパフォーマンスを追跡します。

主要業績評価指標
指標目標計算方法
文書サイクル時間<30 日草案から発効までの平均日数
レビュー完了率>95%期限内に完了したレビュー数 / レビュー総数
変更要求のバックログ<10月末時点の未完了変更要求数
レビュー期限超過率<5%レビュー期限を過ぎた文書数 / 発効済み文書総数
監査指摘率監査あたり <2 件内部監査での文書管理に関する指摘件数
定期レビューのスケジュール
文書の種類レビュー頻度
方針3年ごと
SOP2年ごと
WI2年ごと
仕様書必要に応じて、または製品変更時
フォーム/テンプレート3年ごと

規制要件

ISO 13485:2016 Clause 4.2
サブ条項要件
4.2.1品質マネジメントシステムの文書化
4.2.2品質マニュアル
4.2.3医療機器ファイル(技術文書)
4.2.4文書管理
4.2.5記録管理
FDA 21 CFR 820
セクション要件
820.40文書管理
820.180記録に関する一般要件
820.181機器マスターレコード
820.184機器履歴記録
820.186品質システム記録
よくある監査指摘事項
指摘事項防止策
廃止文書が使用されている配布管理を実施する
承認署名がないリリース前のワークフローを徹底する
変更履歴が不完全改訂のたびに履歴を更新することを必須にする
定期レビューのスケジュールがないレビューカレンダーを作成し、遵守を徹底する
監査証跡が不十分Part 11への準拠についてDMSを検証する

トラブルシューティング

問題考えられる原因解決方法
文書バリデーターが「invalid numbering format」と報告する文書番号がPREFIX-CATEGORY-SEQUENCEのパターンに一致しない番号がSOP-02-001の形式(種類のプレフィックス、2桁のカテゴリーコード、3桁の連番)に従っていることを確認してください。プレフィックスが認識済みの文書タイプ(QM、SOP、WI、TF、SPEC、PLN)と一致していることを確認してください。
署名があるにもかかわらず、承認者がいないという検証エラーが出る入力JSONのapproverフィールドがnullまたは空であるapproverフィールドに承認権限者の名前を入力してください。SOPでは、プロセスオーナーとQAマネージャーの両方が必要です。
現行文書のレビュー日の検証に失敗するreview_dateが過去の日付である次回予定されているレビューを反映するよう、レビュー日を更新してください。レビュー日を過ぎた文書は、定期レビューと再承認の対象としてフラグを設定してください。
変更履歴が不完全と判定されるすべての改訂がchange_history配列に記録されていない改訂番号、日付、説明、作成者を含む変更履歴の記録を、改訂のたびに追加する必要があります。履歴の抜けを補ってください。
eDMSを使用しているにもかかわらず、Part 11の管理項目にフラグが設定されるhas_audit_trailまたはhas_electronic_signatureがfalseに設定されている両方をtrueに設定し、signature_componentsが2以上であることを確認してください(Part 11で最低限必要なユーザーIDとパスワード)。eDMSがコンピューターで生成され、タイムスタンプ付きの監査証跡を作成することを確認してください。
対話モードですべての検証ルールが表示されないテーブル出力に対して端末の幅が狭すぎる端末ウィンドウを広げるか、表示幅の影響を受けない構造化出力を得るために--output jsonを使用してください。
廃止文書が「Effective」として表示され続ける改訂サイクル中にステータスフィールドが更新されていない新しい改訂版をリリースする際は、旧改訂版のステータスを「Superseded」に更新し、使用場所から確実に取り除いてください。旧改訂版に対してバリデーターを実行し、確認してください。

成功基準

  • 文書番号付与システムが適用され、文書マスターリスト内の重複番号がゼロで、フォーマット準拠率が100%であること
  • 文書サイクルタイム(草案から発効まで)が、すべての文書タイプで平均30営業日未満であること
  • レビュー完了率が95%を超えること(期限内に完了したレビュー数 ÷ 開始されたレビューの合計数)
  • 定期レビューの期限超過率が、いかなる時点でも有効な全文書の5%未満であること
  • すべての電子記録について21 CFR Part 11への準拠が検証されていること:監査証跡には変更ごとに誰が/何を/いつ変更したかが記録され、電子署名には氏名の印字、日時、署名の意味が含まれていること
  • すべての文書変更が、文書化された影響評価を伴う分類ワークフロー(管理上/軽微/重大/緊急)を通じて処理されること
  • 直近の認証審査またはサーベイランス審査において、文書管理に関する外部審査指摘がゼロであること

対象範囲と制限事項

対象範囲:

  • 文書番号規則の設計と検証
  • 文書ライフサイクル管理(草案から廃止まで)
  • レビューおよび承認ワークフローの適用
  • 分類および影響評価を含む変更管理プロセス
  • 21 CFR Part 11の電子記録および電子署名への準拠検証
  • 定期レビューのスケジュール管理
  • 文書マスターリストの維持管理

対象範囲外:

  • eDMSソフトウェアの選定、導入、またはバリデーション(このツールはメタデータを検証しますが、DMSプラットフォーム自体は検証しません)
  • EU Annex 11のコンピューター化システムバリデーション(Part 11を補完しますが、別の評価アプローチが必要です)
  • 技術ファイル/設計履歴ファイルの内容作成(技術文書には regulatory-affairs-head を使用してください)
  • 記録保存スケジュールの作成(このツールは日付を検証しますが、規制上の保存期間は決定しません)
  • 物理文書の配布またはアーカイブに関するロジスティクス
  • トレーニング記録の管理(このツールはトレーニング関連文書を検証しますが、トレーニングプログラムは管理しません)

統合ポイント

スキル統合
quality-manager-qms-iso13485文書管理(4.2.3項)と記録管理(4.2.4項)はQMSの中核プロセスです。このバリデーターはISO 13485の文書化要件を適用します
qms-audit-expert4.2項に関する内部監査で文書管理の有効性を検証します。監査指摘は文書プロセスの改善につながります
quality-manager-qmr文書管理指標(サイクルタイム、期限超過レビュー、バックログ)は、QMSパフォーマンス指標としてマネジメントレビューに報告されます
fda-consultant-specialistFDA QMSR(2026年2月発効)はISO 13485の4.2項を参照により組み込んでいます。Part 11への準拠は、電子記録に関する別個のFDA要件として引き続き適用されます
capa-officerCAPAの措置では、文書の改訂が必要になることがよくあります。変更管理プロセスでは、CAPAに起因する文書変更を追跡します

ツールリファレンス

document_validator.py

文書メタデータ、番号規則、および規制上の管理要件を検証します。

フラグ必須説明
--docはい(または --interactive または --sample)番号、タイトル、タイプ、改訂、ステータス、日付、承認者、変更履歴、およびPart 11フィールドを含む文書メタデータJSONファイルへのパス
--interactiveいいえ文書の入力をガイドする対話型検証モードを起動します
--outputいいえ出力形式:重大度別の指摘を含む構造化出力には json を指定します。人が読みやすいテキストの場合は省略します
--sampleいいえサンプル文書JSONテンプレートを生成します(> sample_doc.json でファイルにパイプできます)

コメント