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" <[email protected]>
To: Dan Connolly <[email protected]>
Cc: Bernard Black <[email protected]>,
"<[email protected]>" <[email protected]>
Subject: Re: [gpc-informatics] #551: next-D labs for cohort selection:
fasting glucose, HbA1c
Message-ID:
<cadevuy6gxhn009napqyucrnjukds1zodzpw6fwyovrk7cy9...@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
[email protected]
http://listserv.kumc.edu/mailman/listinfo/gpc-dev
