Aggresiveなバリデーションの方法

カテゴリー: CDISCラボ

http://cdisc-end-to-end.blogspot.co.at/2015/08/sdtmsendadam-validation-how-it-should.html

ここで述べられているのは、Validatioの別のアプローチである。ここでの前提条件は次の通りである

・Define.XMLとデータセットの整合性は、SDTM IGへのAdhereanceを保証しない
・Define.XMLはデータセットよりアプリオリな存在と考えられる

この結果、次の順でバリデーションするアイデアが導かれる

・Define.XMLをSDTM IGに対してチェックする
・Define.XMLをデータセットに対してチェックする
・全体的なバリデーション

このアイデア自体は面白い。Define.XMLをプロセスの先頭で作成することは重要であると考えられているし、多くのWebinarでも推奨されている(つまり、現実的にはDefine.XMLの作成が後手に回るということである)。Define.XMLからバリデーションを始めることは理屈にかなっているだろう。


しかし、このアプローチを実施するためにはいくつかの障害があるように思われる。

・Define.XMLを先に作成するプロセス
一般的にDefine.XMLの情報量は多く、作成に手間がかかる。そのため、チェック開始が遅くなる恐れがある

・チェック内容
変数のLengthは指定されていないか、最大長にセットされているだろう。また、OpenCDISCでチェックをすると、データセットがないことによる不具合が報告されるかもしれない。OpenCDISCから得られるアウトプットは過大となりやすい。どのエラーがCriticalかを選別する必要があるだろう

・全体的なバリデーションとDefine.XML~データセット間のチェックはOpenCDISCで統合されている
エラー解決の順番を制御するのは現実的でないかもしれない。おそらく、エラーを整理し、根本的な問題から解決するだろう。


とはいえ、Define.XML時点でのバリデーションをかけることにより、いくつかの重要な問題点を早い段階で明らかにできるだろう。もしくは、データセットの殻を用いたバリデーションにも類似した効果があるかもしれない。

前ページ | | 次ページ











管理者にだけ表示を許可する
http://doubledealer989.blog74.fc2.com/tb.php/1862-28663c65