統計解析の言語
Python、Rがとは言われるが、あまり大勢は変わらず。この辺り、実は統計解析→メディカルライティングとの絡みが発生するのであればもう少し進展があるかもしれない。
SDTMとADaMなんかの話を少し。
業界として、もう少しデータの標準形を整備する形で進んでほしいのだが、多分その頃には死んでるだろうなあ・・・・・・
dataset-JSONは面白い試みだと思うが、
JSON自体は規格化されているがJSONのメタ定義に関しては実はあんまり使われていないのと、
JSONは一部のレコード取り出してもぱっとプログラムの中の配列とかに出来るというのが強みなのであって、シングルプロセスで扱う事の多い統計に関しては別に特に強みが生かされない、また例えば一症例単位でデータを持ち出すとかの構造を作るならEDCのAPIとかでとか思うが、基本的にそういうメタの設計にはなっていないのもある。
なんかこう、ゆるくデータをやり取りするのに向いているものなんで。
そして、まあテーブルの設計として考えても、Timing VariableにNullを許容するような設計（TPTとかそんな感じ）がとにかく邪魔だし、ナチュラルキーに設定されるようなフィールドは複数あって組み合わせとかも複雑「だから」サロゲートキーをシステムでは使うという所があんまり考慮されていないし、そもそもサロゲートキーもバンバン放り込み過ぎていてややこしい。
変に縦積みするせいで、レコード単位、カテゴリ単位で、使うキーが変わったりするのもある。
そもそも変数のプレフィックスサフィックスで意味を表す、というのが、すごくSAS縛りっぽいというか、現代的ではないのでそろそろ拡張しようよ（だからと言って変数にスペース入れたり記号入れたりするのは駄目だし、DATATIMEをDTMとかで表現するのはいいんだが、8は小さすぎる）という気が。
データ加工ももう少しなんとかしたいなー（技術動向ではないけど）
少なくとも加工ロジックの最後で文字変数数値変数で同じようなものがある場合にはまとめて展開とかの設定にはしたいし、その際に加工で使う変数の縛りとかしたいなー、となるとコーディング規約になってくるんだけど、それでもないなあと。
ダブルプログラミングで検証、というのは聞こえはいいけど、それだからってフリーテキストが如く書き手に委ねるのではなく、むしろテンプレで済むところはテンプレで済むような構造にはしたい。
しかし、その辺り考えると、どうしても中間テーブルの設計とかになってくるんだよなあ。誰も今やってないんだけど。
出来うる限り、ハッシュオブジェクト使うような、何らかの関数のように使える仕様とかを考えるのがいいのかもしれん。とにかく今のマッピング定義書は、各変数ごとに関数を呼んで設定するかのような作りなんで、多少パフォーマンスが犠牲になってもそのように実装出来た方がいいんだよな。
そこまでパターン化するとなると、今のマッピング定義書のロジックフリー記載の部分を、別途枠設けて、「fx(A,B)」→「ロジックのテキストを貼り付ける」みたいな事を出来るようにするのが先なんだろうか。うーん。
