SnowflakeでGxP対応システムを構築する

注：本記事は(2022年4月6日)に公開された(Building GxP Compatible Systems with Snowflake)を翻訳して公開したものです。

製薬会社や医療機器会社で20年以上の経験を持つ品質管理の専門家として、比喩として寒気がしてどこかへ逃げてしまいたくなる場面があります。それは、ライフサイエンス組織の人間（たいていはIT）から「新しいシステムを実装するのですが、検証が必要かもしれないです」と言われる時です。もっとひどいのは、これを「素晴らしいシステムを実装したんですけど」と、過去形で言われる時です。この時ばかりは比喩ではなく本当にどこかへ逃げたくなります。

以前、HPLC（高速液体クロマトグラフィー）データの管理に使用していたラボ情報管理システム（LIMS）の検証を同僚に頼まれたことがありました。馴染みのない方のために説明すると、これらは両方とも信じられないほど自在に構成できるものであり複雑どころではない代物です。2週間後に稼働開始予定だと聞いた時は、笑うしかありませんでした。まさか、冗談だろう、と思ったのですが、彼はまったくの本気でした。

当初のリアクションはさておき、私の好奇心は掻き立てられました。どのシステムなのか？使用目的は何か？ベンダーは承認、認定済みか？テストはしたか？どれくらいしたか？新規システムなのか、既存の置き換えなのか？21 CFR Part 1に準拠しているか？生産用か研究用か？使用目的は？わかっています、これは質問済みでしたね。でも何度も確認する必要があるのです。

これらすべての質問に対する答えがGxPコンプライアンスの取り組みの土台となり、範囲の定義に役立ちます。ベンダーが承認、認定されているなら、システムの製造元や販売元が最小限の品質基準を満たしていることが示されます。実施されたテストの回数は、特定の規制要件を満たすための追加の労力の軽減につながります。

使用目的

個人的には、使用目的は検証における最も重要な側面だと思っています。使用目的によってやるべきことすべてが決まり、さらに重要なのは、それによってやらないことも決まります。システムまたはアプリケーションがどのように使用されるかによって、リスクの度合い、必要なテストの量（あるいはレベル）が決まり、もちろんドキュメントからトレーニングまでのすべてがこれに左右されます。

10年ほど前から、使用目的とリスクベースの意思決定に重点が置かれるようになってきています。システムで提供するすべての機能をテストする必要はなくなり、システムの使用目的の範囲内の機能にのみ注力します。電子品質管理システム（QMS）を例に挙げると、システムに是正措置・予防措置（CAPA）のみを実装する場合は、他の品質イベント、ドキュメント管理、サプライヤー資格、監査などをテストする理由はありません。

現在のSaaSモデルとSnowflakeのデータクラウドでは、現在の規制要件に準拠するためのシステムを構築するうえで、使用目的を理解することは不可欠です。Snowflakeによるアプリケーションを開発しているか？システムをSnowflakeに接続しているか？どのような種類のデータを保存しているか？データはどのように使用されるのか？これらの質問やその他の質問への回答に応じて、検証済みの準拠した環境の作成するためのアプローチと範囲は変わってきます。

つまるところコンプライアンスとは、患者の安全性、製品の品質、データの整合性に対するリスクと影響を軽減または排除するために、客観的な証拠を使用して管理を示すことです。これは、医薬品や医療機器などの物理的な製品だけでなく、それらの製品がどのように製造されたかを記録するソフトウェアシステムにも当てはまります。患者のケアにおける診断とデータアナリティクスの役割も、ますます重要になってきています。

ベンダーの資格認定

業界にかかわらず、サプライヤーが商品やサービスを確実に提供できるようにすることは重要です。すべての消費者は、購入するサービスが事前定義された要件を満たしていることを確認できるべきです。現状に甘んじてはいけません。FDAが規制する業界では、ベストプラクティスだけでなく、ベンダーの資格が必須要件になっています。

許容される品質レベルの決定は各組織に委ねられていますが、これらのスタンダードは特定のポリシーとプロセスのドキュメント、サードパーティの認証または証明、または特定のセキュリティスタンダードで構成されます。この評価には、ベンチマーク監査、アンケート、オンサイト監査、またはリモート監査など複数の方法があります。

コンピューターシステムの検証

コンピューター化されたシステムまたはアプリケーションが意図したとおりに機能することをテスト、検証するプロセスは多面的であり、慎重に計画する必要があります。

計画は、事前定義された検証要件、それらの要件を満たすためのテスト、使用目的を満たすかどうかを示す結果を導くためのロードマップとなります。計画には、データ移行（必要な場合）やトレーニングなど、本番環境の使用を開始するために必要な追加のアクティビティの特定も含まれます。

Snowflakeをどのように使用しているかを、コンプライアンスチームが理解できるよう支援することが極めて重要です。データの取り込み方法は？既存のシステム/プラットフォーム/アプリケーションからデータを移行するか？データはスプレッドシートにあるか？システムにSnowflakeは搭載されているか？それとも、今回が新規の実装か？これらの各シナリオでは、検証作業に極めて具体的な要件があり、まったく異なる規制要件を伴うこともあります。

21 CFR Part 11

Snowflakeを使用して電子形式のレコードを管理（作成、変更、保守、アーカイブ、取得、送信など）するお客様は、政府機関の規制で定められたレコード要件に基づいて、21 CFR Part 11電子記録、電子署名内の該当する要件に準拠しなければなりません。お客様は、Snowflakeの使用目的がこの範囲内にあるかどうかを確認する必要があります。

Snowflakeには、お客様が21 CFR Part 11要件への準拠を示すのに役立つ機能がいくつか用意されています。具体的には、クローズドシステムの制御とアクセス制御、監査ログ、レコードの保持に関するものです。Snowflakeは、お客様のデータへのアクセスがお客様によってのみ運用、管理されるクローズドシステムです。Snowflakeは、データ暗号化、MFA、キーペアの認証とローテーション、SSO、役割ベースのアクセス制御などにおいて業界トップの機能を提供しており、アカウントとユーザー、さらにSnowflakeに保存するすべてのデータに最高レベルのセキュリティを確保します。

Snowflakeサービスをサポートするシステムとインフラストラクチャにアクセスする担当者の場合、各ユーザーに一意のユーザー名とパスワードが必要になります。Snowflakeサービスでは、ユーザーごとに、アカウントがログインしてからログアウトするまでのすべてのアクティビティをログに記録します。このアクティビティは、SnowflakeデータベースのACCOUNT_USAGEスキーマとREADER_ACCOUNT_USAGEスキーマにあります。これらのビューにより、オブジェクトのメタデータと使用履歴データのクエリが可能になります。ACCOUNT_USAGEビューとREADER_ACCOUNT_USAGEビューのリストは、それぞれこことここで確認できます。

特に指定がない限り、これらのビューに含まれるデータの保持期間は1年です。監査証跡要件への準拠を示すため、お客様はシステムログを環境に取り込む（複製する）ことによって、監査履歴を保持できます。お客様は自分のデータとそれにアクセスできる人物を完全に制御できます。レコード保持ポリシーは、お客様が使用目的とニーズに基づいて特定する必要があります。

コンピューター化されたシステム検証の規制順守を確認する際は、いくつかの要素と考慮事項があります。あくまでも個人的な意見にはなりますが、使用目的の特定が最重要事項の1つであることは間違いありません。とはいえ、組織のコンプライアンスの取り組みが成功するのは、計画、ベンダー認定、検証テスト、他のアクティビティのホストといった他の要素と調和が取れている場合に限られるという点を覚えておくことが大切です。Snowflakeを始めれば、コンプライアンスの取り組みを支援する基盤を得ることができます。