JMPは、大規模なデータセットを評価する際に強力なツールとなります。このケーススタディでは、一連の計測機器の故障の根本原因を特定するための調査が開始されました。JMPを使用することで、チームは項目の妥当性判断、傾向分析、データの可視化を行うことができました。その結果、調査は解決され、根本原因が特定されました。
このプレゼンテーションには、調査に関する情報と、Graph Builder の 96 ウェル マップ機能と計測機器に関する知識を組み合わせて根本原因を特定する方法の簡単なデモンストレーションが含まれています。
皆さん、こんにちは。ホリー・オクスリーです。Exact Sciences社のアプリケーションサイエンティスト兼マネージャーを務めています。本日は、JMPを使って根本原因を特定した調査事例をご紹介いたします。
私たちのチームの業務の多くにおいて、調査は大きな部分を占めています。その中で、調査は未完成のパズルのようなものだと認識しています。つまり、調査は複数の構成要素から構成されているということです。
複雑さは様々です。小さな要素と大きな要素の両方に着目する必要があります。通常、各要素をグループ化して関連付けることで、追加情報を導き出すことができます。また、発見可能なパターンが見られることも少なくありません。ほとんどの場合、ある程度の実験が必要になります。最終的に、この作品はデータアート作品となります。
この特定のシナリオでは、これらのパズルのピースがどのように組み合わさるか、そして JMP がどのように何が起こっているかを理解し、問題の本当の根本原因を突き止めるのに役立ったかについて説明します。
まず、構成部品と複雑さの度合いがそれぞれ異なります。これはパズルのピースの数に例えることができます。調査のためのデータは、研究所内の様々な情報源から収集されており、試薬データ、機器データ、環境データ、オペレーターの観察データ、傾向データなどが含まれます。
これらのデータセットや調査自体の複雑さも様々です。私のチームでは、1回の実行という小規模なものから、200列を超える500万行以上のデータまで、JMPを使用して結果出力を行っています。JMPのインポートは、単一ファイルのインポートから、データベースに直接接続された完全なSQLクエリファイルまで、多岐にわたります。
このケーススタディは比較的小規模ですが、無効なサンプルレートが増加したケースです。小さな要素と大きな要素を見ると、形状の異なるピースがあることがわかります。
小さな要素には、特定の日付範囲、実行データ、試薬情報などが含まれます。大きな要素には、サイト比較、複数のラボで実行している場合、組織内または現在の調査で発生している他の問題に関する知識、履歴傾向などが含まれます。これは私たちにとって非常に重要です。私たちは大量のデータを持っており、この履歴傾向は非常に重要です。そして、機器と全体的なサンプルへの影響です。
JMPを使ったデータ分析には、複数ファイルのインポート、分布、集計表、Y軸とX軸の適合表、変動チャート、グラフビルダー、再コーディング、日時の変更、数式の作成などが含まれますが、これらに限定されるものではありません。また、作業とデータ分析を可能な限り効率的に行うため、可能な限りスクリプトも活用しています。
このケースでは、検査室からエスカレーションを受けました。検査の最初の数ステップでサンプルの品質が不十分であることが検出されたため、無効な結果を返すサンプルが増加しているという問題です。私たちは、このパズルの要素をグループ化または関連付けることで、調査に役立つ追加情報をどのように導き出せるかを理解し、判断します。
その調査を行うにあたり、制御データ、較正データ、計測データなどさまざまなデータをグループ化し、それらの特定のデータのいずれも現在の問題の原因ではないという結論に達しました。
これらの品が除外されると、他の調査で確認した消耗品に関する問題の急増など、他の潜在的な関連性を評価することが可能になり、ロットを遡って使用場所を把握するなどの作業を開始できるようになりました。
計器のメンテナンス イベントでは、最初のメンテナンス イベントの完了後すぐに同じ計器に別の問題が発生する可能性が排除されませんでした。そのため、計器が一因となる可能性はあるものの、根本的な原因である可能性は低いと判断できました。
キャリブレーションとコントロール、不合格データ、試薬不合格情報といった細かい要素を評価したところ、データの傾向分析では、1回の検査で無効率の増加は見られませんでした。むしろ、単一サンプルレベルでの増加が見られました。
試薬情報により、1 つのサイトで使用されていた特定の試薬には変更がなく、異なる試薬セットを使用していた 2 つのサイトで問題が発生していることがわかりました。
その段階に達すると、計器類の除外方法に明確なパターンが現れ始めました。この問題により、多くの計器類が時折使用停止状態になっていたにもかかわらず、修理が進められており、修理前と比べて性能が向上した状態では稼働を再開していないことが分かりました。
これをきっかけに、パターンをさらに詳しく調べることにしました。JMPのグラフビルダーとマップシェイプ機能を使うことで、無効なサンプルが発生している場所を視覚的に確認することができました。この小さな画像では、96ウェルプレートの各ウェルに赤と青の点があるのがわかります。
少しパターンがあるのがわかります。赤い点は有効なサンプル、青い点は無効なサンプルです。プレートの右側では、赤い点よりも青い点が明らかに多くなっています。また、青い点は特定の列に沿って少しずれています。行だけでなく、列も同様です。その後、私のチームは、次に無効なサンプルが大量に発生した場合はすぐに報告するよう依頼しました。
計測機器に関する知識とこのデータパターンを組み合わせることで、消耗品ロットの傾向を把握することができました。これは、当時進行中の別の調査に基づいて、既にロットの遡及調査を開始していたためです。もちろん、ある程度の実験は必ず必要です。
このケースでは、調査チーム側から提供された材料では問題を再現できなかったため、実験室で問題を再現するために1つの機器が選択されました。私たちは研究室に赴き、彼らの材料を使用しました。
問題の断続的な性質は、疑問のあった消耗品のうち約20個で再現できました。実験の結果、問題の消耗品を計装に取り付けた際に、明確かつ視覚的に特定可能な原因が示されました。その後、トラブルシューティング中にこれらのプレートで実行したデータによって、その原因が確認できました。
これらすべての作業が完了した後、私たちは、ディープウェルプレートが、私たちが目撃していた無効率の上昇の真の原因であったことを最終的に突き止めることができました。その後、メーカーは、この調査の一環として入手・保管していたプレートが、実際にはサプライヤーが定義した仕様許容範囲外であったことを確認しました。このプレートが、私たちの研究パートナーの手に渡った結果、機器へのプレートの不適切な播種につながり、サンプルの密集が観察され、無効な結果につながったのです。
もちろん、シンプルさの芸術は全体として複雑さのパズルであり、まさにこの非常に特殊な状況で私たちが目にしたことです。この調査にはJMPを使用しましたので、私たちが見たもの、そしてこのツールをどのように活用できるかをどのように判断したかについて、いくつかヒントを共有したいと思います。JMPコミュニティには複数のマップタイプがあります。独自のレイアウトを作成することもできます。独自のレイアウトを作成する方法については、こちらの投稿をご覧ください。
2つ目の投稿は、実はこの調査に使用したウェルフォーマットです。Plate96Welsl-Name.jmpファイルで、下記の関連リンクからご覧いただけます。
スライドショーはこれで終わりです。実際のデモンストレーションで使うものを簡単に紹介します。実際にこの分析を行った際に、どのようにこれを使用したかを説明します。これは、地図を使ってこの判定を行うために使用したサンプルデータセットです。
プレートID、ウェル番号、そしてウェルという特定の列、そしてサンプルステータスとセットアップシリアル番号があることがわかります。セットアップシリアル番号は機器自体に関連付けられています。サンプルステータスは、結果が有効か無効かを明確に示しています。
次にウェルとウェル番号ですが、ソフトウェアの設定上、使用したいマップ機能を使用するにはウェル用の新しい列を作成する必要がありました。その際に、96ウェルプレートの順序をラベル付けし、このウェル列にA1からH12までの番号を入力しました。これは実際のマップで使用するために必要な番号です。
それで… すみません。この特定の列に移動して情報を作成したら、列情報に移動できます。私の具体的なモデリングは「文字」で、この例では「名目値」ですが、「列プロパティ」のドロップダウンに移動すると、「マップロール」があります。「マップロール」を選択してください。
ここでは、形状、名前、用途、または形状、名前、定義のオプションがあります。今回は形状、名前、用途を選択し、取得したいファイルを指定します。ちょっと待ってください。96ウェルプレートです。次に、このマップシェイプを適用したい列として、「Well」という名前で定義します。「OK」をクリックします。
次にグラフビルダーに移動し、先ほど図形に設定した新しい列をマップ図形にドラッグします。これで96ウェルのレイアウトができたことがわかります。さらに、この特定の分析では、サンプルステータスをカラーに、シリアル番号またはセットアップシリアル番号をページにドラッグしました。これで、この特定のシリアル番号から取得した実行回数ごとに、有効または無効な結果の異なる集団が表示されています。
そこから、実行ごとに見たいと思いました。ローカルデータフィルターを適用し、サンプルのセットアップ、というかステータスを含め、本当に見たい2つの項目を選択しました。
次に、マップ自体の中で、「マップ シェイプ」に移動してポイントに変更しました。これにより、機器で複数回実行した場合に、その特定のテーブルに表される代表的なデータをすべて確認できるようになりました。
上の図は1回の実行結果で、無効なパターンが確認できます。2つ目の例では、無効なパターンが異なり、こちらも複数回実行されています。これは、問題があることが分かっていた事前テストと事後テストの例です。メンテナンス前にテストを行い、メンテナンス後に再テストを行いました。
個体群の移動はそれほど大きくないことがわかります。多少の動きはありましたが、どちらのシナリオもプレートの設置方法について2つの点を示しています。このシナリオでは、プレートが機器上に設置されていたため、プレート消耗品の右側が実際に傾いてしまい、この特定のエラーが発生したと考えられます。
次に、2 番目の例、メンテナンス前とメンテナンス後を比較すると、実際には変化は見られませんが、プレートの配置が非常に重要であったことが引き続き示されており、メンテナンス イベント後も同じ種類の領域でこれらのウェルが再現されていることがわかります。
この問題の根本原因を実際に確認し、その消耗品に原因があることが判明した後、サプライヤーに連絡して話し合う機会が生まれました。そして、サプライヤーからは、前のスライドで示した寸法が仕様外であるという情報が返ってきました。私の説明は以上です。Graph Builder をご利用いただき、ありがとうございました。お役に立てれば幸いです。
