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

国際的なデータ交換

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

国際的な臨床試験データ交換は、ICH（国際会議）導入後ますます重要性を増しており、特にICH-E5ガイドラインに基づいたブリッジング試験の増加がその必要性を強調している。ブリッジング試験は、海外の臨床試験成績との類似性を検討し、その適用性を評価するために行われるが、その際、データ交換が鍵となる。海外データの受け入れにおいては、単に総括報告書レベルで利用することも可能だが、より詳細な情報を把握するためには臨床試験データそのものを共有する必要がある。また、多国間にわたる国際共同試験が増加する中で、データ共有は必須であり、無条件で臨床試験データを共有化する仕組みが求められている。現在、ClintrialやOracle Clinicalのような国際的なデータ共有機能を備えた臨床試験データ管理システムが存在しているが、リアルタイムでのデータ共有が果たして必要なのかについては議論の余地がある。リアルタイム共有を必要としない理由としては、データクリーニングが完了しデータ固定が行われた段階での交換で十分と考えられる点が挙げられる。また、進捗状況の管理のためであれば、夜間などに定期的なデータ交換を行うことで十分対応可能である。さらに、データ交換が必ずしもデータベースファイルを用いて行う必要はなく、リレーショナルデータベースで保存されたデータを解析用のSASデータセット形式で交換することでも問題ない。この場合、リアルタイムで共有すべきは臨床試験データそのものではなく、コード内容やメタデータなどの不整合を防ぐための情報である。不整合が発生すると、同じ項目が異なる名称で登録されるなど、標準化を損なう重大な問題につながる可能性があるため、これらを適切に管理する仕組みが不可欠である。データ交換を考慮したデータベース設計には大きく2つの方法がある。一つ目は、全てのデータをコード化して入力し、このコード表を国際的に共有する方法である。例えば、性別については「1」を男性、「2」を女性として定義し、これを国際間で統一する。この方法では、コメントなどのフリーテキスト情報の扱いやコード表の整合性確保が課題となる。特に、新しいコードを追加する際、日本国内で追加されたコードを迅速に英語版のコード表にも反映させる仕組みが必要である。さもなければ、同じコードが異なる内容を意味する事態を招きかねず、混乱を引き起こすリスクがある。二つ目の方法は、データベース内に日本語と英語の情報を併記して入力する方法である。この方法では、コード表の課題は解消されるが、翻訳の妥当性やデータ構造の複雑化が問題となる。日本語と英語を併記するデータベース構造には縦型と横型の2つの代表的な手段がある。縦型では、一つのテーブル内に日本語用フィールドと対応する英語用フィールドを設定する。この方法では、ユーザーが日本語と英語フィールドの対応を理解しておく必要があるが、テーブル・ルックアップ機能を活用することで簡易的な言語変換も可能である。システム側への負荷が少ない点が利点であるが、ユーザーが言語間の対応を理解する負担がある。一方、横型では日本語用テーブルと英語用テーブルを別々に設定し、それぞれの構造を同一にする。この方法では、日本語と英語の表示を簡単に切り替えられる一方で、コードページの切り替え機能や一時的な変数名変更といったシステム的要求が増えるデメリットがある。また、臨床試験データ交換の運用においては、これらのどちらが正しい方法かは一概には言えず、システム設計や利用目的に応じて選択されるべきである。ユーザーにとってはこれらの違いを意識する必要は必ずしもないかもしれないが、データベース管理者はこれらの仕組みを十分に理解し、適切に運用する責任がある。さらに、データ交換の効率性を向上させるためには、臨床試験データの標準化も重要であり、CDISC（臨床データ相互運用基準コンソーシアム）やHL7（ヘルスレベル7）などの国際標準の活用が進められている。これにより、データ交換の円滑化だけでなく、解析プロセス全体の効率化や品質向上が期待される。これらの取り組みは国際的な連携を深め、医薬品開発や臨床研究の迅速化に寄与するものであり、今後も重要な課題として位置づけられるべきである。