Name
Mail
URL
icon
99
Pass
*編集・削除用(任意:英数字4~8文字)
Subject
絵文字
画像添付
匿名

WHODRUG

0 2016/06/15 (Wed) 09:05:50
実際問題、現在WHODRUGのライセンスをもっていないメーカーは購入しないと申請できないのでしょうか?けっこう高額かと思うのですが、国から補助とかはないのでしょうか?
匿名 - Re:WHODRUG 2016/06/20 (Mon) 08:25:46
ぶっちゃけ、ほぼ無理ですね

とはいえ、必要なのは、「一般名」と「ATCコード(及び文字列)」です。「一般名」には著作権なし。「ATC」は利用無料( Application for ATC is free of charge. )
http://www.whocc.no/atc/application_for_atc_codes/
なので、不可能ではないと思います。

が、辞書を購入しないと、一般名―ATCのひも付けがチェックできません。
また、defineのexternal dictinaryに"WHODD"のバージョンを記載できません。

WHODDのユーザーライセンスは「利用者全員」(コーダーだけでなく、DM/解析等含む)なので、結構高額なのが悩みどころです。
匿名 - Re:WHODRUG 2016/06/21 (Tue) 20:41:07
なるほど~
ATCは利用無料だけど、defineで困る・・・かと言ってライセンスは利用者全員で高額。
どこかの誰かは得をしているんですね。
ありがとうございました!助かりました!
匿名

Pinnacle21の結果

0 2016/05/24 (Tue) 11:50:59
Pinnacle21を用いてTAドメインのvalidationを行いました。すると、
「EPOCH value not found in 'Epoch' extensible codelist」
というwarningが表示されました。Controlled Terminologyの"EPOCH"にない文言をTAドメインに格納しているのですが、このwarningは避けられないものなのでしょうか?
匿名 - Re:Pinnacle21の結果 2016/05/31 (Tue) 08:14:23
CT2002のことでしょうか。

こういう仕様みたいですね。
匿名 - Re:Pinnacle21の結果 2016/06/01 (Wed) 09:40:45
Pinnacle21のForumでも話題になっていますね。
https://www.pinnacle21.net/forum/ct2002-epoch-value-not-found-epoch-extensible-codelist
匿名 - Re:Pinnacle21の結果 2016/06/08 (Wed) 09:35:34
お二人ともご回答ありがとうございます。
こういう仕様であり、やはりみなさん気になっていたんですね。
ありがとうございました。
匿名

CTのシノニムについて

0 2016/05/24 (Tue) 17:37:45
赤血球を測定した場合、単位が10^4/uLとなることが多くありますが、この場合LBORRESUには何を格納しますか?
①10^4/uLを入れる? 2016/5/24現在CTへの追加が必要になります。
②10^10/Lを入れる? 10^4/uLが10^10/Lのシノニムとして記載されているので、CDISC submission valueである10^10/Lを用いる?

私は②にしようかと考えているのですが、コメントをお願いします。

また、②にした場合、10^4/uLを10^10/Lに変換した旨をSDRGやDefine中に記録として残す必要があるでしょうか? 
匿名 - Re:CTのシノニムについて 2016/05/31 (Tue) 08:26:44
CT(2016-03-25)のUNITには、
10^10/LのSynonym(s)として、10^4/uLが記載されています。
すなわち両者は等価になります。

この場合、Submission Valueである10^10/Lを格納するのが正解になります(つまり②)

でも、UNITはextensible=Yesなので、10^4/uLを自分で定義して使用しても、Pinnacleでは検出されないので、ルール違反ですが、①でも実害はないと思います
匿名

Trial Designのプログラミング

0 2016/05/18 (Wed) 15:29:22
Trial Design Modelのドメイン(TA,TE,TV,TI,TS,TD)については、プロトコルの内容をデータ化するイメージかと思いますが、ダブルプログラミングを行うべきなのでしょうか?
あひる - Re:Trial Designのプログラミング 2016/05/19 (Thu) 07:43:38
QC(Quality Control)の方法は、各社のポリシーと業務プロセスによりさまざまな方法が考えられ、その中から適切な方法を選択する。というのが教科書的な回答です。

で、TDMのプログラミングに関して言えば、一般的に、
・「TDMの内容を記載したファイル」(Excelなど)を「SASプログラムでXPTファイルに変換する」

 というプロセスが多いと思います。
 後者のプログラムは複数試験で同じものを使いまわすことが可能なので、初めにバリデーションを実施した際、バリデーション記録も使いまわせるようにしておけば、毎回ダブルプログラミングする必要はないと思います。

匿名 - Re:Trial Designのプログラミング 2016/05/19 (Thu) 13:51:39
ご回答ありがとうございます。
使い回しができるようにプロセスと記録を標準化しておけば、ダブルプログラミングは不要になりそうですね。
「各社のポリシーと業務プロセスによりさまざまな方法が考えられ、その中から適切な方法を選択する」
というのをベースに考えてみたいと思います。ありがとうございました。
0

CodelistとISOstandard

0 2016/04/28 (Thu) 16:19:34
Codelistに記載されたISO standardは,Define.xmlでどのように設定すればよいのでしょうか?
IG3.2では,DMドメインのCOUNTRYに,Codelist「COUNTRY」と「ISO 3166」が併記されていますが,Define XML v2.0 Specificationのサンプルxmlでは「ISO 3166」が格納されています。
同様のケースで,TSドメインの「TSVALNF」には「ISO 21090」を設定すべきでしょうか?
ご教示の程宜しくお願い致します。
匿名 - Re:CodelistとISOstandard 2016/05/02 (Mon) 13:20:23
ご指摘の通り、SDTMIG3.2のDM.COUNTRYでは「COUNTRY」と「ISO3166」が併記、TSでドメインは、「ISO3166」が利用され、define.xml v2.0もISO3166です。
TS.TSVALNFは「NULLFLAVOR」が設定されている一方、TS Example2は「ISO 21090」ですね。

以下はあくまで個人的意見ですが、TS.TSVALNFの「NULLFLAVOR」はNCI Terminologyに定義が無く、誤記なのだと思います。
また、実務的にも、ISO3166/ISO21090はdefine.xmlの「External DIctionaries」に記載すれば良く、個々の値を管理する必要が無くて楽。
ということで、「どちらかがだめ。」という決まりを見つけることはできませんでしたが、個人的にはISO表記を優先して使用しています。
0 - Re: CodelistとISOstandard 2016/05/11 (Wed) 13:04:03
ご回答ありがとうございます。やはり,どちらがダメとも,どちらにすべき,とも書かれていないんですね。
匿名

CTの更新手順

0 2016/04/13 (Wed) 16:05:25
標題の通り、Controlled Terminologyをスポンサー側で更新する際の作業手順を教えて頂けないでしょうか?(その際の注意点を教えてもらえるとさらにうれしいです)
匿名 - Re:CTの更新手順 2016/04/22 (Fri) 07:22:35
ご質問の意図が十分理解できていませんので、いくつかのパーターンについて記載させていただくと・・・

・CTそのものの変更(New Term Request)はNCIのホームページから可能です。
http://ncitermform.nci.nih.gov/?version=cdisc
なお、NCI謹製の変更管理ツールがgithubで公開中です
https://github.com/NCIEVS/nci-diff-cdisc

・すでに存在するデータセットのTerminologyを古いものから新しいものに更新する場合ですが、
① 古いTerminologyそのものが、新しいTerminologyに存在するか確認する(無ければ変更)
② 当時Extensibleで追加したものが、新しいCTで追加されていないか確認する
の2stepだと思います

・OpenCDISC(Pinnacle21)のCTを更新する場合ですが、
P21は独自のCT管理を行っているため、CTの更新は推奨されないと聞いたことがあります(CTにない、'NULL'を追加したりなど)

上記の中に、回答はございますでしょうか
匿名 - Re:CTの更新手順 2016/04/27 (Wed) 09:59:03
ご解答ありがとうございます。また、質問の意図がわかりずらく、申し訳ありませんでした。求めていたものは「すでに存在するデータセットのTerminologyを古いものから新しいものに更新する場合」でしたので、疑問が解消されました!ありがとうございました!
匿名

データセットのlengthについて

0 2016/04/06 (Wed) 10:10:01
Technical conformance guideの3.0がリリースされ、改めて読み返すと気になる点が出てきましたので皆様にご質問です。
3.3.3 Dataset Column Length
The allotted length for each column containing character (text) data should be set to the maximum length of the variable used across all datasets in the study.
とあります。across all datasetということでDOMAINやVISITといった複数のドメインで同名の変数については全ドメインから得られる最大長を各ドメインにセットしていますでしょうか。
例)LBでだけ、UNPLANNEDが存在するような場合、上記ルールに則るとLB以外のVISITのlengthが実データ以上となります。
この場合、P21で
SD1082:Variable length is too long for actual data:Warning
が現れます。WarningなのでSDRGに書いて終わりでも良いのですが、
文言がshouldであり、必須ではないこと、エラーは減らしたほうがよいという観点からいくと各ドメインごとに長さを定義するほうがいいような気もします。
皆様はどのように定義されていますでしょうか。
匿名 - Re:データセットのlengthについて 2016/04/07 (Thu) 15:57:43
うちの会社では、①全ドメインの全変数を最も大きなデータ長に変換する ②同じ名前の変数で、ドメイン間で定義が一致しているかチェックして統一する。の2段構えです。
(つまり、同名変数は同じ定義)

Pinnacle21でWarning(値によってはError)が出ますが、ドメイン間でlengthが違うと、ADaM作成時に縦結合(set)した際、文字切れする可能性があるため、長さを統一するほうが徳だと判断しています。


匿名

複数のOriginを持つ変数について

0 2016/03/03 (Thu) 13:57:27
LBTESTCDの収集元がCRFと外部データの2つあるような場合、
皆様Define.xmlのVariable levelのOriginにはどのように記載していますでしょうか。
Value levelに2つ分けて書くのはよいとして、
Variable levelに“CRF,eDT”と書くか、ブランクとするかで意見が分かれています。

SDTM IG 4.1.1.8 Origin Metadataより
When both derived and collected values are reported in a field, the value-level metadata origin will indicate at the test level if the value is “Derived” or “CRF” and the variable-level metadata origin will list all types for that variable separated by commas (e.g., “Derived, CRF”).

ただし、カンマ区切りで書くとPinnacle21でエラーが出ます。
OPENCDISCのフォーラムより
http://www.opencdisc.org/forum/dd0074-community-21
So in your case, I propose that you do NOT add a def:Origin at the LBTESTCD level ItemDef, but provide one for each ItemDef at the value level ItemDef (one for each test). After that, the error should disappear. If it does not, please let us know.
apofiz - Re:複数のOriginを持つ変数について 2016/03/04 (Fri) 13:53:07
SDTM IG 4.1.1.8 Origin Metadataはカンマ区切りで並べろ。
Define-XML 2.0 specification section 5.3.11.3は、"CRF", "Derived", "Assigned", "Protocol", "eDT", "Predecessor"でnon-extensibleだ。
ということで、両方を満たすのは困難ですね。

小職はカンマ区切りで書いて、SDRGで説明するようにしています。(DD073/DD074もPMDAルールではErrorであって、Reject ではないので)

でも、OpenCDISCのフォーラムのように、「空欄」というのもありかも。
匿名 - Re: 複数のOriginを持つ変数について 2016/03/22 (Tue) 20:06:45
私はVariable Level Metadataはブランクにして、Value Level Metadataで記載するのが現状は正解かな、と思っています。

以下に根拠とするURLを記載します。
http://www.cdisc.org/multiple-origins
http://www.opencdisc.org/forum/origin-metadata-records

上記URLの2行目のほうの最後の回答から察するに、この問題は既にDefine-XML dev teamにて検討されているかな、と思われます。
次のdefine specificationのバージョンでは、解決されるかもしれませんね。

>>apofizさん
「OpenCDISCのフォーラム」は、上記の2つめのURLのことでしょうか?
匿名 - Re: 複数のOriginを持つ変数について 2016/03/30 (Wed) 11:45:51
>私はVariable Level Metadataはブランクにして、Value Level Metadataで記載するのが現状は正解かな
→ 私も同意見です。

Variable Levelをカンマ区切りにしたいところなのですが、P21でErrorが出たと思いますので、Value Levelで複数のOriginがある場合には、Variable Levelはブランクが無難かな、と思います。

ちなみに、Variable Levelの情報はValue Levelに継承される、もしValue Levelで別の情報を設定している場合は、Variable Levelの情報はValue Levelの情報でオーバーライドされる、と思いますので(すみません。根拠はないです)
Value Levelで情報が与えられるメタデータに関しましては、一律、Variable LevelはブランクでもOKでは?と考えています。
(バリデータのErrorとの兼ね合いもありますが…)
匿名

併用薬の1日用量

0 2016/03/16 (Wed) 16:51:09
CMDOSTOTのデータ形式はNUMです。テキスト形式だった場合にどう対応したらよろしいでしょうか。CMDOSTOTTXTとかをSUPPに用意すべきでしょうか。

2015年の春頃?にCJUG_SDTMチームに参加している企業を対象に実施されたWHODD利用に関する調査(LiSAS)において、「併用薬情報として収集している項目」が調査されておりますが、1日投与量と1回投与量を合わせると全企業が用量に関する情報を収集していることになり、その半分以上が1日用量を収集しており、本件についてはかなり事例があるかと思います。 ご教授のほどよろしくお願いします。 なお、今後は1回用量を収集することにします。
匿名 - Re:併用薬の1日用量 2016/03/17 (Thu) 15:19:34
"テキスト形式"の内容によりますが、EDCの収集がテキスト形式でも数値化可能であれば、数値形式に変換してCMDOSTOTに格納、そうでなければSUPPCMでしょうか。(CMDOSTOTTXTは8文字オーバーなので短縮が必要です)

LiSASアンケートでは、「投与量を収集しているかどうか?」(Q2)という質問で、「どのように格納するのか」には踏みこんでいなかったと記憶しています。(関係者のかた、追加コメントがあればご指摘ください)。ちなみに弊社の定義書ではSUPPCMに格納すると規定しています
SI単位

SI単位変換

0 2016/02/26 (Fri) 08:03:26
PMDA提出のSI単位で、ASTなどのU(ユニット)は、何を用いるべきでしょうか。また、%は変換すべきでしょうか?
匿名 - Re:SI単位変換 2016/02/28 (Sun) 20:54:11
SI単位にもさまざまな種類がありますが、PMDAはいずれのSI単位を利用すべきかを公表していません。が、U(ユニット)及びIUはSI単位ではないことが確実です。
 私の会社を含め、周囲の会社の方に聞いてみたところ、kat/L (カタール)を選択される会社が多いようです。

%は、このBBSの別スレッドにも議論がありますが、最近は "Proportion of 1"が多いように思います。(American Medical Associationの推奨のため)

こんな単位、使いやすとは思えないのですが、誰か幸せになれるのでしょうか。
[ e:349][ e:442][ e:446][ e:454][ e:456][ e:786][ e:451][ s:472D][ s:472E][ s:4731]
[ e:731][ e:732][ s:4740][ s:4741][ e:51][ e:265][ e:266][ e:262][ s:4F4F][ s:453D]
[ s:4F34][ s:4532][ s:4F32][ e:45][ e:219][ s:4F62][ s:4540][ s:4763][ s:4766][ s:4767]
[ s:476A][ s:4769][ s:476B][ s:4768] [ s:476C][ s:476D][ s:4538][ s:504E][ s:473E][ s:473D]
[ s:4F2D][ s:512B][ s:5151][ s:4526][ s:4528][ s:452B][ s:4775][ s:453C][ s:453A][ s:453B]