国際的なデータ交換

ICHの導入以降，国際間でのデータ交換の必要性が増えている．

これは，外国データの受け入れに関するICH-E5ガイドラインを基にしてブリッジング(Bridging)と呼ばれる臨床試験を実施することにより海外の臨床試験成績との類似性を検討するケースが増えているためである．

海外の臨床試験成績を使用する場合には，単に総括報告書レベルでの利用を行うことも不可能ではないだろうが，細かな内容を把握するためにはやはり臨床試験データそのものを共有化しておくべきである．

また，多国間に跨って国際的に一つの臨床試験を実施するようなケースもあり，このような場合には無条件で国際間での臨床試験データが共有化される必要がある．

そして，実際にClintrialやOracle Clinicalなどのように国際間での臨床試験データ共有機能を有している臨床試験データ管理システムが登場してきている．

しかしながら，臨床試験データそのものを考えた場合に，リアルタイムでのデータ共有が必要なのであろうか．

もちろん，データベースの構造などは国際間で共通化しておかなければならないことは言うまでもないが，クリーニング中の臨床試験データを用いて集計・解析を行うことは考えにくく，本質的にはデータクリーニングが完了してデータ固定が行われた段階でのデータ交換を行えば充分である．

もしも，臨床試験の進捗状況を管理することが必要なためにデータ交換を行うのだとしても，少なくとも夜間などに定期的なデータ交換を行うことで充分なはずである．

さらに，データ交換はデータベースファイルを用いて行わなければならないというものではなく，臨床試験データの保存はリレーショナルデータベースで行っていたとしてもデータ交換は解析に用いるSASデータセットで行うということでも何ら問題はないはずである．

実は，リアルタイムに共有されていなければならないのは，臨床試験データ管理システムで使用しているコードの内容などを含めたメタデータなのである．

これらは不整合が生じないように使用するサイトの間で適切に管理されていなければ，ちょっとしたタイミングのずれで別々のサイトが同じ項目を別の名前で登録してしまったというような標準化を崩す重大な問題が生じる可能性がある．

さて，臨床試験データの交換を考えてデータベース上への臨床試験データの入力を行う場合には，大きく分けて２つの方法がある．

まず最初の方法は，全てのデータをコード化して入力すると決め，このコード表を国際間で共有化するという方法である．

たとえば，性別に関しては「1」と「2」のコードを使うことを規定し，日本では「1」を男性，「2」を女性とし，米国では「1」をMale,「2」をFemaleとするということにしておけばよい．

ただし，この方法ではコメントなどのフリーテキストな情報をどのようにして扱うかということと，コード表の整合性をきちんと確保できるのかという課題がある．

コードの追加が必要になった場合に日本で追加したコードを速やかに英語でのコード表にも登録できるような仕組みを構築しておかないと，同じコードに英語では別の内容が定義されてしまっていたということになりかねず，混乱を招く危険性がある．

そして，もう一つの方法は，データベース中に日本語と英語の情報を文字情報として，両方とも入力してしまうという方法である．

この場合には，コード表のケースのような，コメントや整合性の問題は生じないが，技術的に複雑になる可能性がある．

さらに，この方法では日本語と英語の翻訳における妥当性と整合性を保証する問題が生じる．

このデータベース中に日本語と英語の両方を入力するためのデータベース構造としては，２つの代表的な手段が考えられる．

「縦型」とは一つのテーブル中に日本語用のフィールドとそれに対応する英語用フィールドを設定する方法である．

この方法では日本語と英語フィールドの対応はユーザーが充分に理解しておかなければならないが，テーブル・ルックアップなどの機能を利用して日本語から英語への変換も可能であり，システム側には特別な負荷というものはかからない．

日本人にとって性別のデータがMale, Femaleと英語で入力されていても理解に苦労するというようなことは考えにくいため，実際に日本語と英語の両方が保存されていなければ絶対に困るというような項目はそれほど多くない．

一方，「横型」とは日本語用のテーブルと英語用のテーブルを設定し，内部の項目は項目名などを含めて全く同じ構造を持たせる方法である．

この方法では，テーブルを切り替えることにより日本語と英語の表示を切り替えることが容易にできるなどの可能性があるものの，システム側にコードページの切り替え機能や日本語と英語を同時に表示したい場合にはどちらかのテーブルの変数名を一時的に変更するなどの対応が必要になるなどの新たな要求事項が発生する．

これらの方法のうち，どちらのアプローチが正しいということはないため，ユーザーがとくに意識する必要性はないかもしれないが，データベースアドミニストレーターは充分にこのあたりの仕掛けを理解しておかなければならない．