Oops, wrong email thread.
From: Tony French <[email protected]<mailto:[email protected]>> Date: Tuesday, July 25, 2017 at 10:41 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Michael Prittie <[email protected]<mailto:[email protected]>>, "Stoddard, Alexander" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "Hood, Daniel Robert" <[email protected]<mailto:[email protected]>> Subject: Re: Question on CDMv3.1 Run Jim, I wanted to let you know that our DBA team has a draft document put together. They are reviewing it internally and I hope to have it to you this afternoon. Tony Tony French | Interim Assistant Director of Technical Services Center for Biomedical Informatics [cid:F95FB555-6904-4323-8693-3E9A3AB588C7] 1101 West Tenth Street Indianapolis, IN, 46202 Tel 317-274-9087 | Fax: 317-274-9305 Twitter: @Regenstrief | Facebook.com/regenstriefinstitute<http://facebook.com/regenstriefinstitute> www.regenstrief.org<http://www.regenstrief.org/> Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose. If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited. From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Wednesday, July 19, 2017 at 9:47 PM To: Michael Prittie <[email protected]<mailto:[email protected]>>, Tony French <[email protected]<mailto:[email protected]>>, "Stoddard, Alexander" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Question on CDMv3.1 Run At Nebraska we had to include a comparable constraint due to numeric overflow, primarily on some RNA copy counts on viral tests. We ended up witholding several hundred test results from our CDM tables while we employ conversion factors and unit changes on the associated tests. Jim ________________________________ From: Gpc-dev <[email protected]<mailto:[email protected]>> on behalf of Michael Prittie <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 19, 2017 4:19:54 PM To: French, Tony; Stoddard, Alexander; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: Question on CDMv3.1 Run Hi Tony, Here at KUMC I added the following to the i2p-transform PCORNetLabResultCM procedure¹s INSERT/SELECT WHERE clause: and (m.nval_num is null or m.nval_num<=9999999) -- exclude lengths that exceed the spec https://github.com/kumc-bmi/i2p-transform/blob/master/Oracle/PCORNetLoader_ ora.sql#L753 Best, Michael On 7/19/17, 4:16 PM, "French, Tony" <[email protected]<mailto:[email protected]>> wrote: >Related to this topic: OBSERVATION_FACT.NVAL_NUM is defined as >NUMBER(18,5). However, the CDM V3.1 LAB_RESULT_CM.RESULT_NUM is defined >as NUMBER(15,8). How have the sites handled this discrepancy? Or perhaps >the data has largely fit without any issues? > > >Thanks, >Tony > > >Tony French | Interim Assistant Director of Technical Services >Center for Biomedical Informatics >1101 West Tenth Street >Indianapolis, IN, 46202 >Tel 317-274-9087 | Fax: 317-274-9305 >Twitter: @Regenstrief | Facebook.com/regenstriefinstitute ><http://facebook.com/regenstriefinstitute> >www.regenstrief.org<http://www.regenstrief.org> <http://www.regenstrief.org/> > >Confidentiality Notice: The contents of this message and any files >transmitted with it may contain confidential and/or privileged information >and are intended solely for the use of the named addressee(s). >Additionally, the information contained herein may have been disclosed to >you from medical records with confidentiality protected by federal and >state laws. Federal regulations and State laws prohibit you from making >further disclosure of such information without the specific written >consent of the person to whom the information pertains or as otherwise >permitted by such regulations. A general authorization for the release of >medical or other information is not sufficient for this purpose. >If you have received this message in error, please notify the sender by >return e-mail and delete the original message. Any retention, disclosure, >copying, distribution or use of this information by anyone other than the >intended recipient is strictly prohibited. > > > > > > > >On 7/11/17, 11:34 AM, "Gpc-dev on behalf of Michael Prittie" ><[email protected]<mailto:[email protected]> >on behalf of [email protected]<mailto:[email protected]>> wrote: > >>I can verify that the RESULT_NUM data type conversion in >>data_step_view_prep.sas was the source of the data check exception being >>thrown in the EDC mentioned as Alex mentioned. I have updated the code, >>which is available at >>https://github.com/kumc-bmi/i2p-transform/blob/master/SAS/data_step_view_ >>p >>r >>ep.sas. If anyone else is using this code to generate data step views >>use >>the updated code to regenerate them. >> >>Best, >>Michael >> >>On 7/11/17, 9:36 AM, "Stoddard, Alexander" >><[email protected]<mailto:[email protected]>> wrote: >> >>> >>>MCW had the exact same problem with RESULT_NUM being seen by SAS as a >>>character field despite being numeric in our source RDMS table (Oracle). >>> >>>For us this was caused by the data_step_view_prep.sas code which >>>explicitly forces the RESULT_NUM field to character (which was how it >>>was >>>originally mis-specified in the first CDM3.0 design). Deleting that >>>explicit conversion from the data_step_view_prep.sas fixed the issue for >>>us. >>> >>>Best regards, >>>Alex Stoddard >>>Biomedical Informatics Software Engineer >>>CTSI >>> >>> >>>Date: Tue, 11 Jul 2017 13:52:42 +0000 >>>From: Michael Prittie >>><[email protected]<mailto:[email protected]><mailto:[email protected]>> >>>To: Steger Donald A >>><[email protected]<mailto:[email protected]><mailto:[email protected]>>, >>> >>>"[email protected]<mailto:[email protected]><mailto:[email protected]>" >>><[email protected]<mailto:[email protected]><mailto:[email protected]>> >>>Cc: Mish Thomas F >>><[email protected]<mailto:[email protected]><mailto:[email protected]>> >>>Subject: Re: Question on CDM v3.1 Run >>>Message-ID: >>><d58a4031.27e40%[email protected]<mailto:d58a4031.27e40%[email protected]><mailto:D58A4031.27E40%25mprittie@kumc. >>>e >>>d >>>u>> >>>Content-Type: text/plain; charset="us-ascii" >>> >>>Hi Don, >>>We are getting the same error here at KUMC. Are you using data step >>>views? I am currently testing whether a small change to our >>>data_step_view_prep.sas will fix this. >>> >>>Best, >>>Michael >>> >>>From: Gpc-dev >>><[email protected]<mailto:[email protected]><mailto:[email protected]. >>>e >>>d >>>u><mailto:[email protected]><mailto:gpc-dev-bounces@list >>>s >>>e >>>rv.kumc.edu%3e>> on behalf of Steger Donald A >>><[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:DSteger2@uwh >>>e >>>a >>>lth.org><mailto:[email protected]%3e>> >>>Date: Tuesday, July 11, 2017 at 7:41 AM >>>To: >>>"[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:gpc- >>>d >>>e >>>[email protected]<mailto:[email protected]>><mailto:[email protected]%3e>" >>><[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:gpc- >>>d >>>e >>>[email protected]<mailto:[email protected]>><mailto:[email protected]%3e>> >>>Cc: Mish Thomas F >>><[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected] >>>> >>>< >>>mailto:[email protected]%3e>> >>>Subject: Question on CDM v3.1 Run >>> >>>Hello: >>> >>>When running CDM 3.1, the EDC is reporting an error: Required Numeric >>>field is character: LAB_RESULT_CM RESULT_NUM >>> >>>However, LAB_RESULT_CM.RESULT_NUM is already defined as numeric(15,8) >>> >>>Is this a possible error in the EDC Report? How can we fix this error? >>> >>>Thanks, >>>Don >>> >>>Don Steger >>>Senior Data Management Developer >>>Enterprise Analytics (EA) >>>UWHealth >>>(608) 720-6612 >>>[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:dsteger2@uwhe >>>a >>>l >>>th.org> >>> >>> >> >>_______________________________________________ >>Gpc-dev mailing list >>[email protected]<mailto:[email protected]> >>http://listserv.kumc.edu/mailman/listinfo/gpc-dev > _______________________________________________ Gpc-dev mailing list [email protected]<mailto:[email protected]> http://listserv.kumc.edu/mailman/listinfo/gpc-dev The information in this e-mail may be privileged and confidential, intended only for the use of the addressee(s) above. Any unauthorized use or disclosure of this information is prohibited. If you have received this e-mail by mistake, please delete it and immediately contact the sender.
_______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
