▼▼▼▼▼▼▼▼
チャンネル登録はこちら

データモデル

臨床試験データにおいて項目群の関係やデータ構造に関する概念を表現するものは「データモデル」と呼ばれる．

そして，このデータモデルとはデータをどのようにしてコンピュータに保存するかという理論的なアイデアとなるものである．

コンピュータ上で大量のデータを蓄積するためにはデータベースと呼ばれるアプリケーションを使用することが効率的であり，現在ではリレーショナルデータベースと呼ばれる形態のデータペースを利用することが主流を占めている．

一般的にリレーショナルデータベースでは，データの無駄な重複を避けて複数のテーブルに分割して格納するように設計されており，複数のテーブルを一定のルールで結びつけておくことにより，ユーザーは個別のテーブルに分かれてデータが格納されていることを認識する必要がないようになっている．

このようなテーブル間の結合ルールもデータモデルの重要な部分である．

このため，データモデルを明確にしておくことが臨床試験データをコンピュータで効率的に取り扱う上で重要な意味を持つ．

たとえば，データモデルが明確になってさえいれば，データを参照したいという人に対してデータウェアハウスのようなアプローチを含めて気軽にデータにアクセスしてもらう方法を準備することも容易である．

あるいは，データモデルが共通であれば，実際に使用している臨床試験データ管理システムが異なったとしても，割と容易にデータ交換を実現することができるようになる．

そして，臨床試験データの種類に応じた処理が必要になるため，そのためにはどのようにデータを取り扱うかということをデータモデルとして考えておくことが必要である．

実際には，コンピュータ上でデータベースを使用するか否かにかかわらず，データモデルを意識しておくことは臨床試験データを取り扱う上で大切なことである．

データの種類

臨床試験データには様々な種類がある．

たとえば，患者の性別，年齢，疾患名というような背景情報，投薬の記録というような治療方法に関する情報，臨床検査データ，症状の変化というような有効性や安全性の評価に関する情報など多岐にわたる．

これらの臨床試験データを分類する方法は，目的に応じて様々に考えることができる．

たとえば，集計や解析などの目的で臨床試験データをコンピュータに入力することを考えた場合には，データの構造によりデータベースの設計が異なってくる．

このデータ構造を考えておくことは，データモデルの概念を適用する上で極めて重要な意味を持つ．

そこで，ここでは臨床試験データについてデータ構造から考えてみる.

Singleタイプのデータは比較的単純な構造であり，患者ごとのデータを区別するキーとなる項目（IDキー）が同一データベーステーブル中で重複を許さないユニークなものとなる．

一般に症例番号がIDキーでありユニークなものとなっている．

つまり，一行ごとのデータは症例番号だけで区別することができるということである。

ただし，患者の背景情報の中でも，既往症や合併症などのように一症例で１件のデータだけを持つとは限らない項目もある．

たとえば，既往症のデータについては，ある患者では「胃潰瘍」と「肺炎」の２件，別の患者では「小児喘息」，「Ａ型肝炎」と「中耳炎」の３件が記載されているというように最高件数を予め規定しておくことは難しい．

このような場合の対処方法としては，データの利用目的に応じて，予め入力ルールとして５件より多くの既往症が記載されていた場合の対応手順を定めた上で，入力件数は最高５件までと決めてしまい，入力フィールドは既往症１から既往症５までの５個に限定するものとしてSingleタイプとして設定しておく方法と，後に述べるEventタイプとして設定することにより何件でもデータを入力できるようにしておく方法が考えられる．
VisitタイプのデータはIDキーに加えて日付をキーとして同一項目の繰り返しを持つという構造であり，キーとなる日付が同一IDキーを持つデータの中で日付は重複を許さないユニークなものとなる．

症例番号はIDキーで同じ症例番号のデータ中で観察日がユニークなものとなっている．

すなわち，一症例のデータの中で重複する観察日は存在しないようになっている．

このため，一行ごとのデータは，症例番号と観察日の組み合わせで区別することができる．

さらに，データ処理の方法によっては，このVisitタイプはVisit-Itemタイプと呼ぶべき構造に展開しておく方が便利なことがある．

このVisit-Itemタイプにおいては，症例番号と観察日がIDキーで観察項目が同じ症例番号と観察日の組み合わせのデータ中でユニークなものとなっている．

すなわち，一症例のある観察日のデータの中で重複する観察項目は存在しないようになっている．

このため，一行ごとのデータは，症例番号，観察日と観察項目の組み合わせで区別することができる．

構造を見れば想像がつくと思うが，データ入力を考えた場合にはVisitタイプの方がシンプルな構造であり，ほとんどの症例報告書でも縦と横は入れ替わっていることはあるものの，類似のレイアウトを使用しているはずである．

一方, VisitタイプからVisit-Itemタイプへの展開は，非常に簡単なプログラムで行うことができる.

Visit-Itemタイプが適するデータ処理の方法というのは，たとえば，症例ごとの臨床検査値の推移グラフを書くような場合である．

具体的にSASにより臨床検査値の推移グラフを書くためのプログラムを考えてみると, Visitタイプの場合には次に示すプログラム１のようになる．

これに対してVisit-Itemタイプの場合には，プログラム２のようになり，BYステートメントによる繰り返しを利用することができる．

一見するとプログラム１とプログラム２は似たようなものに思えるかもしれないが，プログラム１では全ての観察項目の変数名をきちんと記述する必要があること，および観察項目が変更された場合にはプログラム中の変数名も適切に変更・追加・削除などを行わなければならない．

つまり，臨床試験データの構造が変化した時には必ずプログラムも変更しなければならないということになる．

これに対してプログラム２では観察項目が変更されたとしてもデータ構造は不変であるためプログラムの変更は一切不要である．

当然，プログラムのバリデーションの観点からはプログラムの変更が不要である方が望ましいことであり, Visit-Itemタイプを利用することに価値がある.

EventタイプのデータはIDキーに加えて観察内容といったイベントをキーとして同一項目の繰り返しを持つという構造であり，ユニークキーの持ち方は以下に示した２通りの方法が考えられる．

このどちらが適切なデータ構造であるかは，集計・解析などの方針により異なるものであり，絶対的にどちらが正しいというようなものではない．

ケース１

キーとなる観察項目が同一IDキーを持つデータの中では重複を許さないものとする．

症例番号がIDキーで有害事象が同じ症例番号のデータ中で重複を許さないユニークなものとする場合である．

すなわち，一症例のデータの中で重複する有害事象は存在しないようになっている．

このため，一行ごとのデータは，症例番号と有害事象で区別することができる．

ただし，現実的にはある患者で同じ有害事象が臨床試験の実施中に複数回，発現することも充分に起こり得る．

このため，このケースを採用する際には，複数回発現した有害事象の取り扱いを予め規定しておく必要がある．

ケース２

キーとなる観察項目は同一IDキーを持つデータの中で重複を許すものとする．

症例番号がIDキーで有害事象が同じ症例番号のデータ中で重複を許したものとする場合である．

すなわち，一症例のデータの中で有害事象が重複して存在できるようになっている．

これにより，ある患者で同じ有害事象が臨床試験の実施中に複数回，発現した場合にも対応することができるようになっている．

そして，発現日が症例番号と有害事象の組み合わせのデータ中で重複を許さないユニークなものとなっている．

つまり，ある症例中の同じ有害事象であっても発現囗で区別できるように，重複する発現日は存在しない．

このため，一行ごとのデータは，症例番号，有害事象と発現日で区別することができる．

このほかに臨床試験データを分類する方法としては，患者の背景，臨床検査値，有害事象というような内容によるもの，あるいは臨床試験開始前，投薬中，投薬終了後観察期間，最終判定時などといった時期によるものなどが考えられる．

臨床試験データの管理において「データモデル」という概念は極めて重要であり、これはデータをどのようにコンピュータに保存し、効率的に活用するかを体系的に定めるものです。データモデルは臨床試験データの項目間の関係性やデータ構造を定義し、それを基にデータベースを設計・運用する際の基礎となります。特に、現在の臨床試験データ管理ではリレーショナルデータベースが主流であり、これを利用することでデータの重複を最小限に抑えつつ、複数のテーブル間でのデータの整合性や関係性を保つことが可能になります。リレーショナルデータベースは、データを複数のテーブルに分割して格納し、それらを一定の結合ルールに従って関連付ける構造を持ちます。このため、ユーザーは個々のテーブル構造を意識することなく、必要なデータにアクセスできるという利便性があります。例えば、臨床試験データを構造的に整理することで、研究者や解析者がデータウェアハウスを通じて容易に情報にアクセスできるようになり、効率的なデータ管理が実現します。このようなデータモデルの適用は、臨床試験データの解析や活用の際に重要な役割を果たし、特に異なるデータ管理システム間でのデータ交換を容易にする点でも大きな意義を持ちます。臨床試験データには患者の背景情報（性別、年齢、疾患名など）、治療情報（投薬記録など）、臨床検査データ、有効性評価や安全性評価に関連する情報など、多様なデータが含まれます。これらのデータを効率的に蓄積・活用するためには、データの特性や利用目的に応じたデータ構造を設計する必要があります。例えば、データの種類によっては「Singleタイプ」と呼ばれる単純な構造が適している場合もあれば、「Visitタイプ」や「Eventタイプ」のような繰り返し構造を考慮する必要がある場合もあります。Singleタイプでは、各患者のデータを一意に識別するIDキーがテーブル内でユニークであり、背景情報や単一のエピソードに関連するデータを扱う際に適しています。一方、VisitタイプはIDキーに加えて観察日をキーとする構造であり、定期的な観察データや時系列データを記録する場合に利用されます。このタイプでは、症例番号と観察日の組み合わせで各行のデータを区別することができ、観察項目が変更されてもデータ構造自体は安定しているため、プログラムの修正を最小限に抑えることが可能です。さらに、Visitタイプを拡張した「Visit-Itemタイプ」では、観察項目ごとにデータを分割し、症例番号、観察日、観察項目の組み合わせで各行をユニークに識別します。これにより、特定の観察項目に関するデータ解析や可視化（例えば臨床検査値の推移グラフ作成）が容易になります。また、EventタイプはIDキーに加えて観察内容や発生イベントをキーとする構造であり、有害事象や特定の出来事に関連するデータを扱う場合に適しています。このタイプには、同一イベントが複数回発生する可能性を考慮したデータ構造が求められ、発現日やイベントの特性に基づいてデータを区別する設計が重要です。例えば、ある患者で同じ有害事象が複数回発生する場合、症例番号、有害事象、発現日を組み合わせたユニークキーを持たせることで、データの重複や矛盾を防ぎつつ、詳細な解析を可能にします。さらに、臨床試験データの分類方法として、データの内容（背景情報、臨床検査値、有害事象など）や時期（試験開始前、投薬中、観察期間、最終判定時など）に基づく方法があります。これらの分類は、解析目的や利用状況に応じて柔軟に適用されるべきであり、データモデルの設計に大きな影響を与えます。例えば、背景情報に関しては、患者ごとのユニークなデータが中心となるためSingleタイプが適している一方で、観察データや有害事象に関してはVisitタイプやEventタイプが適用されるケースが一般的です。このようにデータモデルを適切に適用することで、臨床試験データの管理と解析が効率的かつ効果的に行えるようになります。また、データモデルが統一されていれば、異なる研究施設や国際的な共同研究においてもデータの互換性が保たれ、分析の一貫性や信頼性が向上します。さらに、データ構造が明確であることで、研究者や解析者がデータの内容を容易に理解でき、解析結果の解釈や報告においても一貫性が保たれます。このようにデータモデルは、臨床試験データの効率的な蓄積、管理、解析を支える基盤として不可欠な要素であり、その適切な設計と運用が臨床試験の成功に直結します。