On Wed, Jan 25, 2017 at 2:19 PM, Mei Liu <mei...@kumc.edu> wrote:

> So far based on the site replies, Nebraska and UTSW are using
> specimen_date as the start_date and KUMC and MCW are using result_date. I
> suggest that we first figure out the variability of this information at
> each site (simple question) before asking them to calculate the max
> difference (more complicated).
>
>
Copied. Will do.


>
>
> If the max difference is calculated across all labs, the result won’t be
> representative for the labs required for Next-D, maybe even nonsensical due
> to work flow differences as Alex Stoddard mentioned. Based on my
> understanding, difference between lab order date and specimen taken date
> can be large in the outpatient setting because a patient may wait for quite
> a while before going to the lab. On the other hand, I suspect that the
> difference between specimen taken date and the result date won’t vary too
> much among patients because same facilities are used for result generation
> (if it takes 2 days to get a lab result, the same is likely to apply for
> all patients).
>
>
2 days is not problem.


>
>
> With this said, if all the participating GPC sites uses either specimen or
> result date as the start date, would it significantly affect the Next-D
> cohort selection and analysis if no change is made?
>
>
>

Currently, code is looking at the presence of two lab results of certain
king on different days separated less or equal two years apart. It compares
earlier date on this and other conditions, and picks the earliest out all
as Diabetes Mellitus onset date.  Analysis will be as accurate as record
dates. If delay in dates is 1-2 months, one could easily get DM cases
before 01-01-2014 counted as occurrences after expansion.



> --
>
> Mei
>
>
>
> *From:* Gpc-dev [mailto:gpc-dev-boun...@listserv.kumc.edu] *On Behalf Of 
> *Al'ona
> Furmanchuk
> *Sent:* Wednesday, January 25, 2017 1:00 PM
> *To:* Dan Connolly
> *Cc:* Bernard Black; gpc-dev@listserv.kumc.edu; Stoddard, Alexander
>
> *Subject:* Re: [gpc-informatics] #551: next-D labs for cohort selection
>
>
>
> When I asked for date difference I was asking about any lab type.
>
> Glucose labs are not in PCORNET model and have to be pull out from i2b2
> separately. For A1c(which is in PCORNET model)  I was assuming all sites
> have all 3 dates available.
>
> I was not aware situation is so bad. Lets discuss it in the next
> CAPRICORN/GPC meeting.
>
>
>
>
>
> On Wed, Jan 25, 2017 at 12:45 PM, Dan Connolly <dconno...@kumc.edu> wrote:
>
> I started looking at date differences... for similar reasons to the ones
> Alex gave, I thought a histogram was in order... I had assumed the specimen
> date and order date were in the same table as the result date. But I don't
> see them. I don't know where they are.
>
> My earlier 1 to 2 month estimate for revising HERON ETL was based on this
> assumption. I no longer have a clear design in my head, so multiply my
> estimate by 2x to 3x until I know more.
>
> --
> Dan
>
> ________________________________________
> From: Gpc-dev [gpc-dev-boun...@listserv.kumc.edu] on behalf of Stoddard,
> Alexander [astodd...@mcw.edu]
> Sent: Wednesday, January 25, 2017 11:41 AM
> To: gpc-dev@listserv.kumc.edu
> Subject: Re: [gpc-informatics] #551: next-D labs for cohort selection
>
> I’ll return the Excel spreadsheet survey with info for MCW outside of the
> dev list.
>
> MCW uses RESULT_DATE for the i2b2 “START_DATE” for lab facts.  START_DATE
> being a very poor name imposed by the i2b2 schema, it’s really just “some
> date” for a fact without any explicit context – hence the difference
> choices we will find between sites. It is also the “only date” that can be
> used to ask time relative questions of any given set of  facts in i2b2
> unless we start creating related concepts or being inventive with modifier
> codes. I know of no example of i2b2 modifier codes modifying the _date_ of
> a fact as opposed to the _value_. I think the schema would support it in
> principle but I have no idea if the client and generated queries would.
> This would also be a long term major ETL development task.
>
> We do have all three of order_date, specimen_date and result_date from our
> Epic source data. But specimen date is only partially available, we are at
> the mercy of manual data entry and data validation upstream of us in the
> system. That is, at least in part, why MCW made the expedient choice of
> making RESULT_DATE our anchor for lab facts, it was the “best” one that was
> consistently available in the large.
>
> Are the max difference questions for the different date types to be
> answered in the limited context of only to A1C values, or all lab results
> in our source system (or some broader subset)?
>
> I fear a simple max difference is going to be non-robust, uninformative,
> and look very bad (or even nonsensical) for us. Some work flows upstream
> (at least at MCW) for entering lab results into the EHR use manual data
> abstraction, and others use (at times broken) automated abstraction with
> poorly mapped date field semantics. There is going to be some percentage of
> completely bogus date values. To truly assess the lag between the different
> lab date semantics will probably take calculating percentiles of the
> differences for individual lab tests – this is obviously more effort and we
> will need guidance on how soon an answer is needed for it to be useful and
> if it is worth the effort and/or worth the wait.
>
> Thank you,
>
>  Alex Stoddard
> Biomedical Informatics Software Engineer
> CTSI
> Medical College of Wisconsin
>
>
>
> Date: Wed, 25 Jan 2017 08:29:17 -0600
>     From: "Al'ona Furmanchuk" <furmanc...@icnanotox.org>
>     To: Dan Connolly <dconno...@kumc.edu>
>     Cc: Bernard Black <bbl...@kellogg.northwestern.edu>,
>         "<gpc-dev@listserv.kumc.edu>" <gpc-dev@listserv.kumc.edu>
>     Subject: Re: [gpc-informatics] #551: next-D labs for cohort selection:
>         fasting glucose, HbA1c
>     Message-ID:
>         <CADEvUy6gXhN009NApqYucrnjUkds1zODzPW6fwyOVRk7cY964A@mail.
> gmail.com>
>     Content-Type: text/plain; charset="utf-8"
>
>     Before we go toward changes, lets just see if we need to. I would
>     appreciate if each site could fill up attached form and send back to
> me. I
>     filled some sites based on this discussion. Please, check and correct
> if I
>     got it wrong.
>     Alona.
>
>
>
> _______________________________________________
> Gpc-dev mailing list
> Gpc-dev@listserv.kumc.edu
> https://urldefense.proofpoint.com/v2/url?u=http-3A__
> listserv.kumc.edu_mailman_listinfo_gpc-2Ddev&d=CwIF-g&c=
> yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=-
> aRkmw3Ob1oZRrrYmR1wHysw9FWMRlmk_CMIVWKi32KhS_EbXW7cMBGcBAmqh95W&m=
> mAT174c22jd9Dp-j2U1wODN8ACYRPI5Th5s_WY-HWS8&s=B-0vV1or45x1npbgh4-
> mQuDtqI1g8PORJWvYsJkN9Ic&e=
>
>
>
>
> --
>
> Al’ona Furmanchuk, Ph.D.
> Research Associate
>
> Department of Electrical Engineering and Computer Science
> Northwestern University
> 2145 Sheridan Road, Tech L359
> Evanston, IL 60208
>
> Web: http://furmanchuk.com/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__furmanchuk.com_&d=CwMGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=-aRkmw3Ob1oZRrrYmR1wHysw9FWMRlmk_CMIVWKi32KhS_EbXW7cMBGcBAmqh95W&m=eO6Fes-0q-JJrUNyys4oo8I-flbn9GKPAvNdNcNhWaE&s=r836s15G0nkGQfDpS18GZ73X6MFzUwVvc5b0ooYMDrE&e=>
> E-mail: alona.furmanc...@northwestern.edu <furmanc...@icnanotox.org>
>
> Phone: 847-467-2299 <(847)%20467-2299>
>



-- 
Al’ona Furmanchuk, Ph.D.
Research Associate

Department of Electrical Engineering and Computer Science
Northwestern University
2145 Sheridan Road, Tech L359
Evanston, IL 60208
Web: http://furmanchuk.com/
E-mail: alona.furmanc...@northwestern.edu <furmanc...@icnanotox.org>
Phone: 847-467-2299
_______________________________________________
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

Reply via email to