データセット・変数・オブザベーションの概念を理解しよう。
他言語でなんとなく学習している人は、テーブルやデータフレームというもので置き換えて認識しよう。
検査のデータを利用するのに、こういうテーブルを用いて管理・整理する。
- 大きなひとかたまりの枠を一般的にはテーブルと呼称する。
- 薄い緑色のところの下に続くのを一般的にはフィールドと呼称する。
- 薄い青色のところは一般的にはあまり呼称されないが、こちらの下方向をレコードと呼称する。
表でいうところの表がテーブル、列がフィールド、行がレコードである。
ただし、表とは違い、列の意味と行の意味は異なる。
列の方法の指定は、原則としてフィールドの名前でアクセスする。
行の方向の指定は、原則として単に順序をもってアクセスするだけ、必要があれば行番号でアクセスする。
しかし、基本的にデータを取り出す際には、行の単位で取り出す。
で、今までは、SAS特有の用語を使っていなかったが、以下のように用語を読み替えて貰えばいい。
| テーブル | データセット |
| フィールド | 変数 |
| レコード | オブザベーション |
ちなみに、レコード単位のデータを、通常のプログラム言語のオブジェクトとマッピングするのをORMという。ただ、SASの場合にはORMをイメージする事は少ないと思う。オブジェクトで考えると以下のような感じ。全て上と下は１：多の関係である。
治験ではデータをなぜ加工しなければいけないのか。
治験で入力する単位で生成されるデータと、最終的なデータに求められるものの、ギャップを埋める為である。
RCTの場合、治験の入力時点では、どの薬剤を投与されたかのデータはなく、別にある割付テーブルを用いて被験者事に実薬かプラセボかが後で分かる事がある。
また、現場で採血したものの、ラボで溶血が認められた時にはそのデータは考慮が必要になる。
生データは、個人別であるし、実際に検査を行った日時等を記載するのだが、人によって治験が始められる日が異なる事もあり、また投与開始日からの相対日数を用いての分析を行う為、生データから比較とか統計とか出来る相対的なデータに加工する事が必要になる。
テーブルの正規化を考えよう
SDTMやADaMはあんまり正規は関係がないのだが、データ間の関係性を考える事は大事である。
例えば、臨床検査の検査項目に関する変数はSDTMではLBTEST/LBTESTCDの2つがある。もうひとつ、臨床検査項目を大きく区別するのにLBCATを利用する事も多いだろう。
その際に、臨床検査のTerminologyから引っ張ってくる訳だが、LBTESTが決まればLBTESTCDは自動的に決まる（逆もまた真）構造がある。簡単に言えば、冗長な変数がある。
LBTESTが決まれば、SIに変換した場合の単位も決まってくる。
という事で、LB関連のまとめテーブル（臨床検査基準値表）を予め作っておくと変換しやすくなる。
ここはちょっと愚痴だが、こういう事を考えるのが設計なのだが、今SDTMとかADaMの設計ではなぜか個々でマッピングしたり変換の方法を考えたりするのが設計と思われがちである。
各ドメインのリレーションシップを記述していない設計とか設計書としては問題があるのだが。。。。。。慣習によって省かれている事が多い。多いんだが、実のところその関係性、結構分かってない人多いんだよな。
プログラムはパターンの記述でしかない事を理解しよう。
ついつい検証方法をダブルプログラミングに頼ってしまっている現状がある為、個々人のバリエーションを維持しつつ品質を担保しようと考えがちなのだが、まず、この発想や思考パターンはかなり製薬独特な文化であり、本来はパターンも抑えた上で、結果が正しくなるかをテストしてプログラムの品質を担保する。
結果が正しい事が一番大事である。
正しい結果を産むプログラムの書き方が様々な人で書いた時でも一致する事は結構望ましい状態であったりもする。
また、ダブルプログラミングの結果が一致する事が、プログラムの完成につながらないという事も考えてほしい。
今、加工プログラムを一データセットにつき一本で書く事が標準的になってしまっているのだが、それは本来正しいあり方ではない事にも留意してほしい。
正しい動作を担保されたライブラリを再利用しつつ実装しないと、品質は個人の力量頼みになってしまう。
そういう意味では、今のSASプログラムの作りだと、単体テストすらマトモに実装するのが難しい、ってのはまああるんだが。。。。。。
テストデータ生成ツールくらいはあらまほしき事かな。
