eBMR/eDHR

エグゼクティブサマリー

デジタルバッチレコードが検査に不合格になる理由はただ一つ、圧力下では証拠として機能しないからです。検査官が簡単な質問をするまでは、記録は完全なように見えます。例えば、「この数字が正しいとどのように判断したのか教えてください」「誰が変更したのか」「リリース前に何が起こったのか」「どのロットが消費されたのか」「どの機器が使用されたのか」「どのような例外が発生したのか」「全履歴をどれくらい早く取得できるのか」といった質問です。もしこれらの質問に答えるためにスプレッドシートやメールの分析、あるいは物語の再構成が必要になるなら、バッチレコードはもはや記録ではなくなってしまいます。運用モデルは脆弱になり、それに応じて検査の範囲も拡大します。

このホワイトペーパーでは、電子バッチ製造記録および電子機器履歴記録（eBR/eBMR）と電子機器履歴記録（eDHR）のための、ベンダーに依存しない実用的なモデルについて説明します。このモデルは、検査官や監査官が実際にテストする制御面、すなわち、識別情報とロットの確実性、段階的な実行証拠、機器の適格性、管理された編集、例外管理、例外ごとのレビュー、監査証跡、署名の意味と拘束力、および完全で文脈に沿った記録の迅速な検索に焦点を当てています。

電子記録や電子署名が対象となる場合、検査の要件は、21 CFR Part 11およびデータインテグリティやALCOA+などの関連するデータインテグリティの概念を通じて議論されることがよくあります。この文書では、機能のクリック操作や「検証の劇場」に陥ることなく、 CSVやGAMP 5などのガイダンスを使用して重要なコントロールを検証する方法についても説明しています。

目標はシンプルです。検査員に渡すことができ、それ自体で機能し、一貫性があり、再構築が不可能で、すぐに取得できる電子バッチ レコードを作成することです。

抽象

電子バッチ製造記録（eBMR）と電子デバイス履歴記録（eDHR）は、検査条件下で信頼できる証拠を提供できるかどうかで評価されます。本稿では、デジタルバッチ記録の実用的な運用モデルを提案します。この運用モデルは、ID、ステータス、実行イベント、保護された記録という4つの要素からなる証拠言語を用いており、ハードゲートによる実行制御、管理された例外、例外によるレビュー、迅速な検索によってサポートされています。このモデルは、IDの逸脱、制御されていない編集、断片化された監査証跡、脆弱な統合境界、物語の再構成を必要とする記録といった、一般的な障害モードに対処します。

本稿では、検査官が記録の信頼性を検証する方法を模擬した検査演習も提供しています。具体的には、監査証跡の行動、署名の意味、ロット消費の証明、機器の適格性、例外の関連付け、そして文脈を考慮した完全な記録セットの取得などです。電子記録が利用される場合、このモデルは、Part 11およびALCOA+で一般的に議論されているリスクベースのCSVおよびデータ整合性の期待値と一致しています。

1) 範囲: eBMR/eDHRのエビデンスとして認められるもの

「デジタルバッチ記録」とは、PDFテンプレートから、完全に施行されたイベントドリブンの実行記録まで、あらゆるものを指します。検査官が重視するのは、組織が規制上の意思決定を裏付ける公式記録として何を扱っているかです。デジタル記録が処分、リリース、調査、あるいは顧客／規制当局への対応に使用される場合、それは証拠システムのように、つまり完全性、帰属可能性、一貫性、そして検索可能性を備えていなければなりません。

用語に関しては、多くの組織ではバッチ実行記録をeBR/eBMR（製造）、デバイス記録をeDHRと呼んでいます。根本的な要件は同じで、非公式な説明に頼らずに何が起こったのかを再構築することです。

2) 検査官が実際に検査するもの

検査官がまず「バッチ記録全体を読む」ことは稀です。彼らは重要な工程、計量・分配の入力、逸脱、調整、機器の使用、署名、あるいは出荷決定といった、ある特定の項目を選び、それを抜き出します。そして、記録が信頼できるものであることを証明する証拠を求めます。誰がいつそれを実行したのか、何が変更されたのか、どのような例外が発生したのか、そして何が禁止行為を阻止したのかといった点です。

この論文の残りの部分では、これらの調査に迅速かつ一貫して回答できるようにレコードを設計する方法について説明します。

3) 証拠モデル：アイデンティティ、ステータス、イベント、記録

デジタルバッチレコードは、制御を日常業務に反映できる少数の基本要素で表現できる場合に改善されます。ここで使用するモデルは意図的にシンプルです。ID （誰が／何を）、ステータス（許可されているか）、実行イベント（何が、いつ発生したか）、および保護されたレコード（改ざん防止の証拠）で構成されます。

電子記録が利用される場合、このモデルは、通常パート11で規定される期待事項や、 ALCOA+などのデータ整合性原則をサポートします。運用上のテストは変わりません。つまり、説明なしに記録を信頼できるかどうかです。

4) マスターレコード管理: MMR/DMR、レシピ、バージョン

バッチ記録は、「真の情報源」が不明確な場合に機能しなくなります。製造業では、これは通常、マスター製造記録（MMR）です。医療機器においては、これに相当するものは、多くの場合、デバイスマスター記録／仕様セット（サイトによって名称が異なります）です。検査官は、どのバージョンが実行されたか、何が変更されたか、誰が変更を承認したか、どのバッチが影響を受けたかを尋ねます。

防御可能なデジタルプログラムは、マスターレコードを管理対象として扱います。つまり、バージョン管理され、承認され、実行されたすべてのバッチにリンクされます。マスターパラメータが非公式に変動する場合（「シフト中に微調整する」など）、バッチレコードは管理された実行ではなく、単なるストーリーとなってしまいます。

5) 実行制御：ステップワイズワーク、ハードゲート、IPC

デジタルバッチレコードは「帳票」ではありません。作業の進行に合わせて証拠を作成する実行システムです。検査官は予防管理、つまりシステムが禁止行為をブロックし、必要なチェックを実施し、実際の一連のイベントを記録しているかどうかを検査します。「警告」は「ブロック」よりも弱く、ポリシーは強制よりも弱いのです。

工程内チェックは、事後的なレビューではなく実行中の管理を示すため、一般的な検査手法です。詳細については、工程内管理チェック（IPC）およびハードゲート方式の合否判定などの関連するゲート方式の概念を参照してください。

6) 材料と計量証明：ロット、スケール、収量

材料消費は、高頻度かつ時間的な制約があるため、バッチ記録が破綻するケースが多いです。検査官は、以下の点を証明できるかを審査します。(1) どのロットが使用されたか、(2) 使用時に適格であったか、(3) 記録された数量が信頼できるか、(4) 逸脱（重量過不足、代替品、ロット分割）がどのように処理されたか。

強力なプログラムは、ロット固有の消費量を強制し、計量イベントを後から入力するのではなく、実行証拠として記録します。計量器との統合が存在する場合は、それを証拠境界として扱い、それに応じて検証する必要があります。計量器との統合を参照してください。容器の識別情報と風袋が重要な場合は、風袋管理などの制御によって曖昧さを軽減できます。

歩留まりの正確性は、隠れた手直し、記録されていない不良品、または調整上の問題を明らかにするため、非常に重要です。確固たる基準には、構造化された歩留まりレビューと差異の可視化が含まれます。歩留まり差異の概念と調整に関する期待事項を参照してください。

7) 機器、校正、準備状況

機器の証拠とは、単に機械名を記載するだけではありません。検査官は、機器が使用時に適格であったかどうか、そして記録がそれを証明しているかどうかを確認したいと考えています。一般的な調査項目としては、校正状況、メンテナンス状況、清掃状況（該当する場合）、そしてオペレーターが適格でない資産の使用を阻止されていたかどうかなどが挙げられます。

優れたシステムでは、適格性をステータスロジックとして実装します。例えば、キャリブレーションは、ロックアウトロジックによるキャリブレーションなどのルールや、同様の制約を用いて強制できます。これは完璧を目指すものではなく、現実が逸脱を余儀なくした場合に、システムが禁止された実行をブロックするか、あるいは制御された例外を捕捉するかどうかが重要なのです。

8) 逸脱、例外、および制御された編集

例外がシステム外で処理されると、デジタルバッチ記録は機能しなくなります。検査官は逸脱がゼロであるとは考えていません。逸脱が可視化され、構造化され、影響を受ける記録要素にリンクされていることを期待しています。QMSに逸脱が存在するにもかかわらず、それが影響を与えるバッチステップやデータ要素にリンクできない場合、証拠は物語的なものになってしまいます。

例外処理には、トリアージ、割り当て、および実行イベントとの連携が含まれる必要があります。逸脱のトリアージと割り当て、およびより広範な品質イベント管理を参照してください。是正措置および予防措置の有効性も、成熟した検査でテストされます。CAPAの有効性チェックを参照してください。

管理された編集は、頻繁に問題提起の引き金となります。検査官は、修正によって元のエントリが保持され、監査証跡を通じて意味のある変更履歴が生成されること、そして必要に応じて変更理由が記録されることを求めています。サイレント上書き、規制対象エントリの削除、またはガバナンスのない特権編集は、構造的な弱点となります。

9) 例外審査とリリース決定

例外によるレビューは、完全な手動レビューではスケールしないため魅力的です。検査員は例外によるレビュー自体には反対しませんが、期待によるレビューには反対します。問題は、例外が明確に定義されているか、システムが確実に例外をフラグ付けしているか、そしてリリースの決定が「何も気づかなかった」ではなく証拠に基づいているかどうかです。

実用的な基準となるのは、例外によるバッチレビュー（BRBE）です。妥当なBRBEプログラムでは、例外とは何か、例外をどのように検出するか、誰が例外をレビューするか、リリース決定をどのように文書化して署名するかを定義します。リリースが検査結果に依存する場合は、LIMSの証拠とのリンクを明確にする必要があります（添付ファイルと統合境界に関する後述のセクションを参照）。

10) 監査証跡、電子署名、データ整合性の姿勢

デジタルバッチ記録は、記録が信頼できる場合にのみ検査に合格します。その信頼は、ID、アクセス制御、監査履歴、管理された編集、および保持規律によって構築されます。これらは、データ整合性やALCOA+などの原則の下でよく議論されます。電子記録と電子署名が紙に取って代わる場合、組織は通常、21 CFR Part 11を通じて期待事項を規定します。

検査官は、監査証跡の動作を実演によってテストします。保護された値を変更し、監査証跡エントリ（ユーザー、タイムスタンプ、該当する場合は古い値と新しい値、変更理由）を表示し、後でどのように取得するかを示し、密かに変更できないことを示します。監査証跡（GxP）を参照してください。また、電子署名が使用されている場合は、署名の意味と拘束力もテストします。署名の意味、署名者の認証方法、署名後にレコードが変更された場合に何が起こるかなどを確認します。

検証はリスクベースで、制御対象領域に焦点を当てるべきです。CSVの目的はすべての画面をテストすることではなく、危害や品質の低下を防ぐための制御、すなわち本人確認、ステータス管理、ゲートロジック、例外処理、監査証跡の動作、およびデータ保持制御をテストすることです。GAMP 5などのガイダンスは、リスクに応じた作業量の調整に役立ちます。

11) 添付資料および外部証拠: CoA、LIMS、ログ

バッチ記録は自己完結的であることは稀です。サプライヤーのCoA、ラボ結果、環境モニタリング、機器ログ、温度ログ、梱包照合など、外部証拠に依存しています。検査リスクは「添付書類の存在」ではなく、添付書類が適切に管理され、帰属可能で、リンクが張られており、文脈に応じて検索可能であるかどうかです。

よくある弱点の一つは、外部証拠が堅牢な連携なしにどこか別の場所（共有ドライブ、メール、LIMS）に保存されていることです。検査官から「放出を裏付ける検査結果を見せてください」と求められた場合、組織はバッチとの明確な連携を保ったまま、迅速に結果を提示する必要があります。連携がファイル名の付け方や手作業による検索に依存している場合、記録は脆弱なものになります。

12) 統合境界: ERP/LIMS/WMS の障害モード

統合はバッチの証拠を強化することも、弱めることもあります。検査員は境界でギャップを見つけることがよくあります。例えば、2つのシステム間でリリース状況が一致しない、ロットIDが異なる、タイムスタンプが一致しない、あるいは「記録」が明確な記録システムの定義がないまま複数のツールに分散しているなどです。このような状況が発生すると、組織は照合作業を強いられますが、照合作業は証拠にはなりません。

防御可能な統合体制では、データ要素ごとの所有権、イベント契約（「発行」、「消費」、「リリース」、「保留」の意味）、レイテンシー許容範囲、および現実との乖離が発生した場合の調整メカニズムを定義します。マスターデータの整合性は基本です。マスターデータの同期を参照してください。

倉庫内の移動が品質ステータスを回避できる場合、バッチの証拠が損なわれます。隔離/保留ステータスなどのステータス強制の概念は、単一のシステムだけでなく、オペレーションにおけるあらゆる移動面で一貫している必要があります。

13) 検査ドリル：社内で実行できる10のテスト

eBMR/eDHRが検査を通過するかどうかを確認する最も早い方法は、検査官が記録の信頼性をテストする方法を模倣した訓練を実施することです。各訓練は迅速に実行可能で、説明なしに証拠が単独で提示される必要があります。

14) 実装ロードマップ

失敗する最速の方法は、「紙のデジタル化」から始めることです。勝利への最速の方法は、現在証拠が破綻している箇所を特定し、最もリスクの高い逃亡を厳重に管理することから始めることです。検査の生存性をエンジニアリングのように扱いましょう。証拠モデルを定義し、ゲートを強制し、結果を測定し、複製によって拡張していくのです。

最後に

eBMR/eDHRのサバイバビリティは、単なるフォーマット作業ではありません。運用モデルです。IDが強制され、ステータスが現実のものとして扱われ、実行がイベントとして記録され、例外が統制され、例外ごとのレビューが測定可能で、記録は設計によって保護されています。これらの要素が整備されると、検査はより迅速かつ限定的になり、調査はより正確になり、バッチエビデンスは再構築不可能になります。

関連する定義については、本稿全体にリンクされている用語集ページ（eBR/eBMR、eDHR、バッチ製造記録（BMR）、MMR、BRBE、監査証跡、21 CFR Part 11、データ整合性、CSVなど）を参照してください。これらの参照は任意です。本稿の制御モデルは、意図的にベンダーに依存しないように設計されています。