Guys, Order date is important for defining study sample and DM sample. specimen date is important for "adherence to Treatment" variable. If difference in dates is minor, we could uniformly switch to specimen date. But first we have to know what is available in each site and ( if both dates are available) how large is difference between dates?
Sent from my iPhone > On Jan 24, 2017, at 10:40 PM, Campbell, James R <campb...@unmc.edu> wrote: > > I agree with Phillip. Clinically, the date/time reported for a lab test is > always when the patient had blood drawn or gave the sample. THAT is when the > patient was 'tested'. Nebraska records all lab test observation_facts with > START_DATE as date/time specimen was taken. We record order time and result > reported time separately. > Jim > > James R. Campbell MD > campb...@unmc.edu > Office: 402-559-7505 > Secretary: 402-559-7299 > Pager: 402-888-1230 > > On Jan 24, 2017, at 6:07 PM, Al'ona Furmanchuk <furmanc...@icnanotox.org> > wrote: > >> Dan: It is important to be clear what each site use under "start_date". >> Especially for cases when ORDER_DATE is different from SPECIMEN_TAKEN_DATE. >> I appreciate, Dan if you could gather this info. >> It is important to be on the same terms when collecting data to the table 1. >> Phillip: I agree that having order, specimen and result dates is good >> practice. This is what we have here at NU as well. >> >> Alona. >> >> >>> On Tue, Jan 24, 2017 at 5:49 PM, Phillip Reeder >>> <phillip.ree...@utsouthwestern.edu> wrote: >>> I’d recommend using the SPECIMEN_TAKEN_DATE/TIME for the start_date of a >>> lab. I believe it is the more clinically correct time as the results of >>> labs can sometimes take days to return. We use the specimen time, followed >>> by the result time, I believe. >>> >>> For the PCORI CDM, I plan on putting all of the needed date/times, >>> (specimen, order, and result) into a small XML block in the >>> observation_blob column so that I can have all the times when I ETL the >>> data to the CDM schema. >>> >>> Phillip >>> >>> From: Gpc-dev <gpc-dev-boun...@listserv.kumc.edu> on behalf of Dan Connolly >>> <dconno...@kumc.edu> >>> Date: Tuesday, January 24, 2017 at 5:09 PM >>> To: Al'ona Furmanchuk <furmanc...@icnanotox.org>, >>> "<gpc-dev@listserv.kumc.edu>" <gpc-dev@listserv.kumc.edu> >>> Cc: Bernard Black <bbl...@northwestern.edu> >>> Subject: RE: [gpc-informatics] #551: next-D labs for cohort selection: >>> fasting glucose, HbA1c >>> >>> Reviewing the HERON ETL code, I see it does populate the i2b2 start_date >>> for labs from Epic's result_time, which looks more like RESULT_DATE. >>> >>> I see that our code to build the PCORNet LAB_RESULT_CM.LAB_ORDER_DATE >>> (PCORNetLoader_ora.sql#L1407) uses this start_date that came from >>> result_time, so we're fudging things a bit there. >>> >>> The HERON ETL code is used at KUMC and was the basis of work at UTHSCSA and >>> UNMC. If the difference between LAB_ORDER_DATE and RESULT_DATE is >>> significant for Next-D, I can find out how the other participating GPC >>> sites do start_date for labs. >>> >>> ref: >>> heron_load/epic_labs_transform.sql >>> >>> -- >>> Dan >>> >>> From: Al'ona Furmanchuk [furmanc...@icnanotox.org] >>> Sent: Tuesday, January 24, 2017 4:35 PM >>> To: <gpc-dev@listserv.kumc.edu> >>> Cc: Mei Liu; Dan Connolly; Taylor, Bradley; Bernard Black >>> Subject: Re: [gpc-informatics] #551: next-D labs for cohort selection: >>> fasting glucose, HbA1c >>> >>> Dan, >>> great job! >>> Meanwhile, could you please clarify actual meaning of "start_date" in i2b2? >>> Is it more like "LAB_OERDER_DATE" (when lab was ordered), "SPECIMEN_DATE" >>> (when specimen was taken), "RESULT_DATE" (when results became available)? >>> >>> >>> Alona. >>> >>>> On Tue, Jan 24, 2017 at 4:06 PM, GPC Informatics <d...@madmode.com> wrote: >>>> #551: next-D labs for cohort selection: fasting glucose, HbA1c >>>> --------------------------+----------------------- >>>> Reporter: afurmanchuk | Owner: meiliu >>>> Type: design-issue | Status: accepted >>>> Priority: major | Milestone: next-d >>>> Component: data-stds | Resolution: >>>> Keywords: | Blocked By: >>>> Blocking: 545 | >>>> --------------------------+----------------------- >>>> >>>> Comment (by dconnolly): >>>> >>>> Alona, Mei, >>>> >>>> I managed to prototype using i2b2 and LOINC codes: >>>> >>>> - 8f27bee get FG_Intial, RG_Initial from i2b2 star schema >>>> \\[https://github.com/dckc/nextd-study- >>>> support/blob/master/NextDvariableExtractionOracleTable1GPC.sql#L138-L221 >>>> NextDvariableExtractionOracleTable1GPC.sql lines 138-221] >>>> >>>> At KUMC, this results in ~500K rows in RG_Intial but 0 in FG_Intial: >>>> as I noted in comment:1, the LOINC code KU Hospital maps to (`Glucose >>>> SerPl-mCnc (2345-7)`) doesn't >>>> distinguish fasting from eating. >>>> >>>> Some changes were perhaps substantive, so I need you to evaluate the >>>> impact: >>>> - LAB_ORDER_DATE became start_date, >>>> which is more likely result date than order date >>>> - i2b2 start_date includes time >>>> >>>> Brad, I think this approach should work at other GPC sites. I'd appreciate >>>> if you'd (have George) take a look. >>>> >>>> -- >>>> Ticket URL: >>>> <http://informatics.gpcnetwork.org/trac/Project/ticket/551#comment:8> >>>> gpc-informatics <http://informatics.gpcnetwork.org/> >>>> Greater Plains Network - Informatics >>> >>> >>> >>> -- >>> Al’ona Furmanchuk, Ph.D. >>> Research Associate >>> >>> Center for Health Information Partnerships, >>> Northwestern University, Feinberg School of Medicine >>> 633 N. Saint Clair Street, 20th floor, >>> Chicago, IL 60611 >>> Web: http://furmanchuk.com/ >>> E-mail: alona.furmanc...@northwestern.edu >>> Phone: 312-503-34281 >>> >>> UT Southwestern >>> >>> Medical Center >>> >>> The future of medicine, today. >>> >> >> >> >> -- >> Al’ona Furmanchuk, Ph.D. >> Research Associate >> >> Center for Health Information Partnerships, >> Northwestern University, Feinberg School of Medicine >> 633 N. Saint Clair Street, 20th floor, >> Chicago, IL 60611 >> Web: http://furmanchuk.com/ >> E-mail: alona.furmanc...@northwestern.edu >> Phone: 312-503-34281 >> _______________________________________________ >> Gpc-dev mailing list >> Gpc-dev@listserv.kumc.edu >> 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 Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
