d, Alexander"
mailto:astodd...@mcw.edu>>,
"dsteg...@uwhealth.org<mailto:dsteg...@uwhealth.org>"
mailto:dsteg...@uwhealth.org>>,
"GPC-DEV@LISTSERV.KUMC.EDU<mailto:GPC-DEV@LISTSERV.KUMC.EDU>"
mailto:GPC-DEV@LISTSERV.KUMC.EDU>>
Cc: "Hood, Danie
quot;Stoddard,
Alexander" mailto:astodd...@mcw.edu>>,
"dsteg...@uwhealth.org<mailto:dsteg...@uwhealth.org>"
mailto:dsteg...@uwhealth.org>>,
"GPC-DEV@LISTSERV.KUMC.EDU<mailto:GPC-DEV@LISTSERV.KUMC.EDU>"
mailto:GPC-DEV@LISTSERV.KUMC.EDU>>
S
From: Gpc-dev on behalf of Michael Prittie
Sent: Wednesday, July 19, 2017 4:19:54 PM
To: French, Tony; Stoddard, Alexander; dsteg...@uwhealth.org;
gpc-dev@listserv.kumc.edu
Subject: Re: Question on CDMv3.1 Run
Hi Tony,
Here at KUMC I added the following to the i2p
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<=999) -- exclude lengths that
exceed the spec
https://github.com/kumc-bmi/i2p-transform/blob/master/Oracle/PCORNetLoader_
o
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 As
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
Alex,
Thanks for the response, that¹s exactly the fix I am currently testing.
If it works for us here at KUMC as well, I will update the code at
(https://github.com/kumc-bmi/i2p-transform/blob/result_num_fix/SAS/data_ste
p_view_prep.sas) and send another email confirming that the issue
originates i
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
m
