先日投稿しましたデータマネジメント入門②で、エディットチェックの作成に触れたのですが、「そういえば紙媒体のときはもちろんなかったな～」と思いましたので、備忘の意味も込めて一筆…
言うまでもなく、エディットチェックやオートクエリというものは、EDCシステムが可能にしたものです。それまでは紙媒体での運用がメインであり、紙媒体の症例報告書を記入後スポンサーに送り、スポンサー側でデータを入力していました。データは入力完了後、確認され、矛盾がある場合には修正をされ、必要に応じて実施医療機関に出向いて再確認…という流れです。一時、EDCの前身にあたるRDE（リモート・データ・エントリー）というものも普及しました。RDEは、ノートパソコン（当時は本体重量２～４㎏だったのでノートと呼べるかどうかは疑問ですが）等の端末に専用のソフトウエアをインストールすることで動作します。当然、インターネットが広く普及する前の時代では、それこそ専用線を引いたり、フロッピーに一時保存してそれをスポンサーに回収してもらったり、専用のパソコンを各実施医療機関に配布したり、と大変でした。当然、同時に何本もの試験が走っていると、医療機関のスタッフも何台ものパソコンを管理することになり、各システムの仕様も大きく異なる等決して良いことばかりではなかったそうです。結果的には、データ入力の負担がスポンサー側から実施医療機関側に移行しただけで、「なんだか最先端なことやってるぞ！」というワクワク感はあったのでしょうけれども、医薬品開発全体の労力節減に寄与したとは言い難いものだったのではないでしょうか。
Promasys 3.1のクライアントも当時はフロッピーでの配布でした。
インターネットの普及とともに、EDCも自然と使われるようになったわけですが、私が仕事をはじめた2003年当初は、業界最大手のスポンサーさんも三枚複写の症例報告書を持ち込んでいました。紙媒体の症例報告書には、各項目の記入方法を細部に至るまで解説した「記入の手引き」というものが付いていました。数字の書き方まで、見本が入っているという徹底ぶりでした。EDCを利用すればエディットチェックやオートクエリを駆使することで代替できそうです。本来なら目視で確認しなければいけない項目間の矛盾も、EDCなら矛盾をデータ入力担当者に知らせるアラートを組み込めます。考えることは皆同じなのか、少し時間が経つと一斉にEDCシステムでオートクエリがじゃんじゃん仕込まれるようになります。過剰なほどに…。桁数等の単純入力ミスがあると、自動的にクエリが発行され、入力ミスの修正、クエリへの回答と、長いウェブページの読み込み時間も挟むので一つの単純ミスで修正に1～5分取られるという状態。修正にそれほど時間を取られること自体、今では信じられないですが、インターネットが普及した当時でもページ全体を再読み込みするしか方法が無かったことが、根本にあった原因です。
現在のエディットチェックは、AJAXというプログラミング手法により、ページ全体の再読み込みを必要としなくなり、入力した項目に対してのみ赤文字等でエディットチェック内容を表示するような仕組みになっています。フォームをSAVEする前にデータ入力担当者の画面にアラートが表示されるため、そもそもオートクエリの発行自体を抑制できます。エディットチェックを駆使することで、クエリの発行を80%も削減できた、という報告もあります。また、上でも触れたように、記入の手引き（入力の手引き）についても、画面上で「入力のヒント」が表示できるなどのこともあり必要性が薄くなってきています。項目間の矛盾についても、男性と選択したら妊娠検査の項目がフォームから消失するまたはグレーアウトされて入力不可になる等、そもそも矛盾を起きさせないための設定も可能になっています。
便利である反面、つかいどころには注意が必要です。エディットチェックは、設定にも動作の確認にも時間が必要です。下手すると、データベース構築の所要時間と同じくらいの時間があっという間に過ぎていきます。また、大量の、複雑に絡み合ったエディットチェックを設定すればするほど、修正が必要な場合に大変な作業を強いられます。リソースが限られている臨床研究や自ら治験での「あるある」が、想定していない例外が起きたため、どうやっても解消できないエディットチェックを作ってしまった、というものです。最後に、エディットチェックを大量に組むと、データ入力担当者側がそのうちアラートに気を配らなくなり、エディットチェックを放置してしまうことが起こり得ます。何事もほどほどに、と言うことだと思われます。
コメント