データの信頼性を追跡するための新しいデータ要素により、Oracle Clinical One Analyticsのパフォーマンスが向上

Oracle Clinical One Analyticsのパフォーマンスが大幅に向上し、すべての試験データの需要を処理できるようになりました。さらに、Oracle Clinical One Platformとのデータの一貫性を検証するための新しいデータセットが導入されました。

このリリースの主な改善点は、自動化されたデータ再処理により、データ処理を試験レベルで増分させることです。これにより、小規模またはより複雑な調査を実施しているかどうかに関わらず、すべてのお客様とその特定のニーズに合わせてスケーラブルなデータ処理モデルを構築できるようになりました。より効率的なデータ・レプリケーション・モデルを使用することで、Oracle Clinical One Analyticsデータセット内のデータが以前よりも頻繁にリフレッシュされるようになりました。

Oracle Clinical One Analyticsの新しいデータセット

データが適切にリフレッシュされることを示す証拠を提供するために、DHメトリックと呼ばれる新しいデータ・セットを使用して、Oracle Clinical One Analyticsで試験のデータの最新バージョンを確認できるようになりました。
  • DHメトリック・データセットはOracle Clinical One Analyticsで使用でき、それにアクセスするための新しい権限は必要ありません。アプリケーションでデータセットを表示および操作する権限がすでにある場合は、この新しいデータセットも表示できます。
  • この新しいデータセットは、ダッシュボードを構成する際に使用して、試験のデータを効率的にビジュアル化し、データの正確性を高めることができます。
  • DHメトリック・データセットには、「Study」および「Metrics」というフォルダが含まれます。試験フォルダには、試験の詳細に関連する標準データ要素が含まれていますが、「メトリック」フォルダには、Oracle Clinical One Platformとのデータの一貫性を確認するために使用できる新しいデータ要素があります。最新の試験データを参照していることをテストするために使用できる最も重要な指標は次のとおりです。
    • HEARTBEAT_CONSOLIDATION_TSは、発生した最新の試験データ・リフレッシュの日時を示します。
    • IS_DATA_CONSISTENTは、「はい」または「いいえ」のラベルを示します。「はい」ラベルは、最新の試験データのリフレッシュが発生した時期(HEARTBEAT_CONSOLIDATION_TS)に従って、Oracle Clinical One Analyticsデータが現在Oracle Clinical One Platformと一致していることを検証します。
  • このフォルダにリストされている他のデータ要素をHEARTBEAT_CONSOLIDATION_TSおよびIS_DATA_CONSISTENTデータ要素とともに使用して、試験のデータが分析アプリケーションに適切に反映されていることをさらに確認できます。たとえば、C1_INVENTORIES_MAX_VER_STARTなどのデータ要素を使用すると、Oracle Clinical One PlatformおよびDH_INVENTORIES_MAX_VER_STARTから最後にプルされた試験の在庫データを含む最新バージョンの表を表示して、最後にリフレッシュされたものからOracle Clinical One Analyticsに同じ在庫関連データを表示できます。

    ノート:

    メトリック・フォルダ内のC1で始まるすべてのデータ要素は、Oracle Clinical One Platformのデータ表に関連しています。メトリック・フォルダ内のDHで始まるすべてのデータ要素は、Oracle Clinical One Analyticsのデータ表に対応します。

これらの新しいデータ要素のすべての定義、およびリリース評価環境(RAE)のアップグレードの完了後のアナリティクス・ユーザー・ガイドの新しいDHメトリック・データセットの詳細な説明を表示できます。

その他の機能強化

これらの機能強化および再アーキテクチャの詳細は、Oracleの窓口にお問い合せください。

現在、新しいデータ処理モデルの結果として、他の機能拡張が見られる場合があります。例については、次を参照してください:
  • 試験に盲検ランダム化番号がある場合、盲検キット・データセット・データセットおよび盲検サブジェクト・イベント・データ・セット・データセットには、RAND_NUMBERデータ要素の「盲検」ラベルが0ではなく表示されます。これは、ブラインドされた無作為化番号の以前のリリースに必要な変更であり、新しいアナリティクス・アーキテクチャが実装されると、評価環境(AE)および本番環境で使用できるようになります。新しいブラインド無作為化番号機能の詳細は、ブラインド・サブジェクト無作為化番号を参照してください。
  • 「件名フォーム・データセット」では、実行時にフォームのステータスが計算されるようになりました。このアップグレードの後、フォームのステータスが初めて計算されるときに、フォームのステータス変更に対して作成された監査レコードは、履歴レコードではなく、現在のタイムスタンプを持つCREATED operation_typeを示します。

    今後、フォームのステータスが変更されるたびに、監査レコードは変更済operation_typeを示し、タイムスタンプはフォームのステータスが変更された時間を正確に反映します。

  • 「サブジェクト・フォーム」データセットでは、完全にクリアされたフォームのレコードが保持され、正しく表示されるようになり、サブジェクトに対して存在したすべてのフォームを追跡できるようになりました。クリアされたフォームのレコードは、「新規」または「オプション」のステータスで表示されます。
    完了したフォームで一部のデータがクリアされるとはかぎりませんが、そのステータスは次のように表示されます。
    • フォームのステータスが最初に計算されると、このアップグレード後、そのステータスはIN_PROGRESSとして表示されます。
    • 先に進むと、完了したフォームのデータがクリアされるたびに、そのステータスはINCOMPLETE (期待される動作)として更新されます。
  • また、サブジェクト・フォーム・データセットでは、フォーム・ステータス変更の監査レコードについて、実行時にフォーム・ステータスが計算されるため、ユーザー名が「システム」として表示されるようになりました。ユーザーがフォームの最後の項目を入力すると、フォームのステータスが「進行中」から「完了」に更新され、そのユーザー名とタイムスタンプは引き続き項目変更のために保存されます。「件名フォーム・アイテム」データセットでは、「件名フォーム」データセットのフォーム・ステータス変更レコードの場合、アクションを実行するユーザーのユーザー名は「システム」として表示されます。
  • 「盲検症例イベント」データセットおよび「盲検解除症例イベント」データセットの予定ビジット日が、すべてのレコードに対して適切に表示されるようになりました。以前は、予測ビジット日に関連するデータは現在のレコードに対してのみ移入され、監査レコードには移入されませんでした。また、これらのフィールドには、時間値ではなく日付値のみが表示されるようになりました。
  • また、盲検症例イベント・データセットおよび盲検解除症例イベント・データセットでは、欠落しているビジット・レコードについて次のフィールドが適切に移入されるようになりましたが、以前は開始済ビジットに対してのみ移入されていました:
    • VERSION_START
    • VERSION_END
    • OPERATION_TYPE
    • USER_ID
    • USER_WID
    • USER_NAME
    • OBJECT_VERSION_NUMBER
    • SOFTWARE_VERSION_NUMBER
    • 理由
    • コメント
  • 盲検解除された症例イベント・データセットの盲検解除日は、単純な日付フィールドではなくタイムスタンプになりました。これにより、2025-01-02 15:08:20.000000000などの適切なタイムスタンプ値が表示されます。
  • 「盲検症例イベント」データセットで、症例に対して追加または削除された動的ビジットのレコードを表示できるようになりました。これらのレコードでは、EVENT_TYPEがそれぞれVisit_ShowまたはVisit_Hideとして表示されます。
  • 「スタディ・デザイン・データセット」で、ALLOW_ADDITIONAL_ROWSデータ要素に「はい」および「いいえ」の値のみが表示されるようになりました。この値が以前に「Null」として移入されていた場合、これは「No」として表示されます。

親トピック: レポート、アーカイブおよび分析