何らかのEDCの導入を検討されている方から「データベース構築はどんな人がやれば良いの?」という相談を受けることがあります。現時点では各医局で紙媒体やエクセルで動かしていて、一からデータセンターを立ち上げるケースです。基本的には、バックグラウンドはあまり問われず、どちらかと言うと「何が出来て」「何がしたい」の方が大事だと感じています。実際にデータマネジメントをやられている方々は、医学系、看護系、薬学系、情報処理系とバックグラウンドは様々です。なんとなく、コミュニケーション能力がある程度備わっていると良いとは思いますが、これは何もデータマネジメントに限らず、新しいモノの導入を担当する人全てに望まれるスキルでしょうね。さて、今回は試験のデータマネジメントの準備段階についてです。EDCを使用しているケースです。
プロトコルからデータベース構造を作成
EDCを利用する場合、データベース化の準備を前もって行っておきます。簡単に言うと、いろんなデータを入れるのに適している空っぽの箱を準備します。プロトコルには、試験を実施してどのような情報を収集するかが書かれてあります。この情報をもとに、項目名、データ型、単位等、どういったデータをデータベースに入力するのかを確認していきます。こういった「データに関するデータ」を「メタデータ」と呼びます。検査項目や測定項目はプロトコルの通りに拾っていきますが、もちろん全ての情報がプロトコルで確認できるわけではないので、適宜病院の検査部門・利用する検査会社や国際規格・評価尺度を参照しながら作業をしていきます。また、プロトコル間で共通したメタデータとなるよう、過去に作成したものも参考にします。最終的には、データベースの構造定義書(データベースの仕様)が出来上がります。
構造定義書?
データベース構造を作成していく過程で必要なものとして「構造定義書」があります。基本的には前述のメタデータの一覧に各ビジットでの使用回数等の情報を付したものです。データベース構築のパターンとしては大きく二つあります:使用するEDCシステムにメタデータを直接入力する場合と、一旦別媒体で項目の一覧を作成してからEDCシステムに入力する場合です。いずれの場合においても、構造定義書は作成して保存しておくのが一般的にですので、前者の場合はシステムから構造定義書として代用可能なものが出力可能であることが大前提となります。後者は、利用するEDCに左右されず統一の構造定義書で運用をしたい場合に有用ですが、構造定義書がシステムから自動で出力できる前者のパターンと比較して、データベース構築の所要日数は長くなる傾向にあります。ただ、近年では同一の構造定義から任意のEDCのデータベースを作成できるソフトウエアもあるので、何がベストなのかは一概には言えません。
エディットチェック
EDCシステムの一番の強みは、入力したデータに対して様々なチェックを自動的にかけられることです。紙媒体の症例報告書では、目視で確認せざるを得なかったことも、EDCを利用すると明らかに間違っているデータを入力できない様にしたり、間違っている場合はアラートを表示したりできるようになります。システムによって、出来る・出来ないはさまざまですが、下記の様なものがあります:
- 数値データの桁数や入力可能範囲の上下限の設定
- 項目間での矛盾をアラートで指摘
- 入力内容に応じて他項目の入力可否設定やフォーム全体の表示・非表示
- 患者・被験者の登録施設に応じて基準値を変更
- 特定フォームの電子署名の有無に応じて次のビジットの入力可否設定
一般的にはこれらすべてを「エディットチェック」と称しますが、各EDCシステムでそれぞれ名称が異なる場合があるので注意が必要です。データベースの構造定義書と同様、エディットチェックについても仕様書を残しておく必要があります。ここまで作りこんでしまえば、いよいよ意図したように動くかのテストをします。
あれ…でも症例報告書はいつ作るの?
昨今のEDCは、ほぼ例外なくデータベース定義から自動的にデータ収集用のWebフォームを生成します。紙媒体の症例報告書も、ほとんどのシステムで丁寧にレイアウトされて印刷することが可能です。したがって、症例報告書の作成は基本的には不要です。構造定義書の通りにデータベースを構築する場合でも、構造定義書が構築したデータベースから作成される場合でも、ここは変わりません。昨今のEDCは(できるできないの差はありますが)可能な限り自動生成を行う様に設計されています。紙媒体で収集後にEDCに入力する運用の場合は、現場での使いやすさを考えて別途症例報告書を「自作」する場合もあります。
受け入れテスト
データベースの作成が終了したら、本番環境を準備する前に、まず意図したとおりにEDCが動いてくれるのかを確認します。具体的には、テスト環境を立ち上げて、実際に入力をしてみます。患者・被験者が正しく登録できるか、選択・除外基準が設定した通りに機能しているか、数値データに文字が入力できない様になっているか、エディットチェックは正しく動作しているか、等です。こういった一連の確認作業を「受け入れテスト」(User Acceptance Test)と呼びます。受け入れテストで問題が発覚した場合は、一旦構造定義に戻り、修正を施し、再度テスト環境を立ち上げて確認作業を行います。
受け入れテストの結果が問題なければ、いよいよ本番環境の立ち上げへと進みます。次回は本番環境前に準備しなければいけないことについてです。ご不明な点やご質問はコメント欄まで!
コメント