データモデル|【医療統計学・統計解析】
データモデル
臨床試験データにおいて項目群の関係やデータ構造に関する概念を表現するものは「データモデル」と呼ばれる.
そして,このデータモデルとはデータをどのようにしてコンピュータに保存するかという理論的なアイデアとなるものである.
コンピュータ上で大量のデータを蓄積するためにはデータベースと呼ばれるアプリケーションを使用することが効率的であり,現在ではリレーショナルデータベースと呼ばれる形態のデータペースを利用することが主流を占めている.
一般的にリレーショナルデータベースでは,データの無駄な重複を避けて複数のテーブルに分割して格納するように設計されており,複数のテーブルを一定のルールで結びつけておくことにより,ユーザーは個別のテーブルに分かれてデータが格納されていることを認識する必要がないようになっている.
このようなテーブル間の結合ルールもデータモデルの重要な部分である.
このため,データモデルを明確にしておくことが臨床試験データをコンピュータで効率的に取り扱う上で重要な意味を持つ.
たとえば,データモデルが明確になってさえいれば,データを参照したいという人に対してデータウェアハウスのようなアプローチを含めて気軽にデータにアクセスしてもらう方法を準備することも容易である.
あるいは,データモデルが共通であれば,実際に使用している臨床試験データ管理システムが異なったとしても,割と容易にデータ交換を実現することができるようになる.
そして,臨床試験データの種類に応じた処理が必要になるため,そのためにはどのようにデータを取り扱うかということをデータモデルとして考えておくことが必要である.
実際には,コンピュータ上でデータベースを使用するか否かにかかわらず,データモデルを意識しておくことは臨床試験データを取り扱う上で大切なことである.
データの種類
臨床試験データには様々な種類がある.
たとえば,患者の性別,年齢,疾患名というような背景情報,投薬の記録というような治療方法に関する情報,臨床検査データ,症状の変化というような有効性や安全性の評価に関する情報など多岐にわたる.
これらの臨床試験データを分類する方法は,目的に応じて様々に考えることができる.
たとえば,集計や解析などの目的で臨床試験データをコンピュータに入力することを考えた場合には,データの構造によりデータベースの設計が異なってくる.
このデータ構造を考えておくことは,データモデルの概念を適用する上で極めて重要な意味を持つ.
そこで,ここでは臨床試験データについてデータ構造から考えてみる.
Singleタイプのデータは比較的単純な構造であり,患者ごとのデータを区別するキーとなる項目(IDキー)が同一データベーステーブル中で重複を許さないユニークなものとなる.
一般に症例番号がIDキーでありユニークなものとなっている.
つまり,一行ごとのデータは症例番号だけで区別することができるということである。
ただし,患者の背景情報の中でも,既往症や合併症などのように一症例で1件のデータだけを持つとは限らない項目もある.
たとえば,既往症のデータについては,ある患者では「胃潰瘍」と「肺炎」の2件,別の患者では「小児喘息」,「A型肝炎」と「中耳炎」の3件が記載されているというように最高件数を予め規定しておくことは難しい.
このような場合の対処方法としては,データの利用目的に応じて,予め入力ルールとして5件より多くの既往症が記載されていた場合の対応手順を定めた上で,入力件数は最高5件までと決めてしまい,入力フィールドは既往症1から既往症5までの5個に限定するものとしてSingleタイプとして設定しておく方法と,後に述べるEventタイプとして設定することにより何件でもデータを入力できるようにしておく方法が考えられる.
VisitタイプのデータはIDキーに加えて日付をキーとして同一項目の繰り返しを持つという構造であり,キーとなる日付が同一IDキーを持つデータの中で日付は重複を許さないユニークなものとなる.
症例番号はIDキーで同じ症例番号のデータ中で観察日がユニークなものとなっている.
すなわち,一症例のデータの中で重複する観察日は存在しないようになっている.
このため,一行ごとのデータは,症例番号と観察日の組み合わせで区別することができる.
さらに,データ処理の方法によっては,このVisitタイプはVisit-Itemタイプと呼ぶべき構造に展開しておく方が便利なことがある.
このVisit-Itemタイプにおいては,症例番号と観察日がIDキーで観察項目が同じ症例番号と観察日の組み合わせのデータ中でユニークなものとなっている.
すなわち,一症例のある観察日のデータの中で重複する観察項目は存在しないようになっている.
このため,一行ごとのデータは,症例番号,観察日と観察項目の組み合わせで区別することができる.
構造を見れば想像がつくと思うが,データ入力を考えた場合にはVisitタイプの方がシンプルな構造であり,ほとんどの症例報告書でも縦と横は入れ替わっていることはあるものの,類似のレイアウトを使用しているはずである.
一方, VisitタイプからVisit-Itemタイプへの展開は,非常に簡単なプログラムで行うことができる.
Visit-Itemタイプが適するデータ処理の方法というのは,たとえば,症例ごとの臨床検査値の推移グラフを書くような場合である.
具体的にSASにより臨床検査値の推移グラフを書くためのプログラムを考えてみると, Visitタイプの場合には次に示すプログラム1のようになる.
これに対してVisit-Itemタイプの場合には,プログラム2のようになり,BYステートメントによる繰り返しを利用することができる.
一見するとプログラム1とプログラム2は似たようなものに思えるかもしれないが,プログラム1では全ての観察項目の変数名をきちんと記述する必要があること,および観察項目が変更された場合にはプログラム中の変数名も適切に変更・追加・削除などを行わなければならない.
つまり,臨床試験データの構造が変化した時には必ずプログラムも変更しなければならないということになる.
これに対してプログラム2では観察項目が変更されたとしてもデータ構造は不変であるためプログラムの変更は一切不要である.
当然,プログラムのバリデーションの観点からはプログラムの変更が不要である方が望ましいことであり, Visit-Itemタイプを利用することに価値がある.
EventタイプのデータはIDキーに加えて観察内容といったイベントをキーとして同一項目の繰り返しを持つという構造であり,ユニークキーの持ち方は以下に示した2通りの方法が考えられる.
このどちらが適切なデータ構造であるかは,集計・解析などの方針により異なるものであり,絶対的にどちらが正しいというようなものではない.
ケース1
キーとなる観察項目が同一IDキーを持つデータの中では重複を許さないものとする.
症例番号がIDキーで有害事象が同じ症例番号のデータ中で重複を許さないユニークなものとする場合である.
すなわち,一症例のデータの中で重複する有害事象は存在しないようになっている.
このため,一行ごとのデータは,症例番号と有害事象で区別することができる.
ただし,現実的にはある患者で同じ有害事象が臨床試験の実施中に複数回,発現することも充分に起こり得る.
このため,このケースを採用する際には,複数回発現した有害事象の取り扱いを予め規定しておく必要がある.
ケース2
キーとなる観察項目は同一IDキーを持つデータの中で重複を許すものとする.
症例番号がIDキーで有害事象が同じ症例番号のデータ中で重複を許したものとする場合である.
すなわち,一症例のデータの中で有害事象が重複して存在できるようになっている.
これにより,ある患者で同じ有害事象が臨床試験の実施中に複数回,発現した場合にも対応することができるようになっている.
そして,発現日が症例番号と有害事象の組み合わせのデータ中で重複を許さないユニークなものとなっている.
つまり,ある症例中の同じ有害事象であっても発現囗で区別できるように,重複する発現日は存在しない.
このため,一行ごとのデータは,症例番号,有害事象と発現日で区別することができる.
このほかに臨床試験データを分類する方法としては,患者の背景,臨床検査値,有害事象というような内容によるもの,あるいは臨床試験開始前,投薬中,投薬終了後観察期間,最終判定時などといった時期によるものなどが考えられる.
関連記事