Hi, A number of fields in CDM 3.1 changed in precision. Our engineer had this to say about that:
PCORI CDM 3.1 Issues:
We had a couple issues that may be related as follows:
* Are they running the data_step_view_prep.sas first? Probably yes… If
yes, then just after the data_step_view_prep.sas completed and before any other
sas jobs, open each data set and review the data in each field. Data errors
will become apparent before running the rest of the sas jobs. Since PCORI
changed the field lengths of some table fields there may be some SAS code that
still assumes the old size of the table fields and therefore will truncate the
data as is comes through the SAS views created by the data_step_view_prep.sas
code. For LAB_RESULTS_CM table look in the data_step_view_prep.sas for this
table section and make the following change:
Result_num = input(result_num,best8.); and change this to
Result_num = input(result_num,best32.8);
And then re-run the data_step_view_prep.sas and review all the
tables and fields values in SAS. In the SAS code anywhere where PCORI changed
the field lengths potentially has this error.
I’ve attached our data_step_view_prep.sas file for reference.
* The other issue to keep in mind relates to SAS Libraries.
Data_step_view_prep.sas defines a libname called oracdata. Make sure in later
SAS steps that you are not accidently re-defining this library in some other
sas code. You need to use the sas views created in data_step_view_prep.sas for
the rest of the sas code in later steps.
Hope this helps.
From: Verhagen, Laurel A
<verhagen.lau...@marshfieldresearch.org<mailto:verhagen.lau...@marshfieldresearch.org>>
Sent: Friday, September 1, 2017 8:09 AM
To: Phillip Reeder;
gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>; Debbie Yoshihara
Subject: RE: PCORI CDM Lab Issue
I’d love to hear what UW is doing, as they are at 100% for lab ranges. Debbie,
can you help?
We were also dinged for this, but the problem may be different. The SCILHS ETL
included normal ranges for selected labs. We may not have pulled the most
recent version of i2p? The version we ran was limited to the shorter list of
labs, not the newer direction to include all data. Our labs are stored with a
local coding system that can be linked to LOINC. The challenge is that we have
multiple local codes, with different ranges, for a single LOINC. Still looking
into this…
Thanks,
Laurel
From: Gpc-dev [mailto:gpc-dev-boun...@listserv.kumc.edu] On Behalf Of Phillip
Reeder
Sent: Thursday, August 31, 2017 4:07 PM
To: gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>
Subject: PCORI CDM Lab Issue
Our CDM report showed us failing the check 3.10 for "LAB_NAME is a common
measure* or LAB_LOINC is not null and RESULT_NUM is not null and
NORM_MODIFIER_LOW, NORM_RANGE_LOW, NORM_MODIFIER_HIGH, and NORM_RANGE_HIGH are
all populated per CDM specifications.**”
The difference between 3.09 and 3.10 seems to be the normal ranges, but we do
have normal ranges in our data as we used the i2p code to generate the lab
results. Did anyone else have an issue like this with their last EDC report?
Does anyone understand the SAS code well enough to help me figure out why this
check was failing for us?
Thanks,
Phillip
________________________________
UT Southwestern
Medical Center
The future of medicine, today.
________________________________
The contents of this message may contain private, protected and/or privileged
information. If you received this message in error, you should destroy the
e-mail message and any attachments or copies, and you are prohibited from
retaining, distributing, disclosing or using any information contained within.
Please contact the sender and advise of the erroneous delivery by return e-mail
or telephone. Thank you for your cooperation.
data_step_view_prep.sas
Description: data_step_view_prep.sas
_______________________________________________ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
