RE: gpc-dev 21 July agenda and meeting notes

2020-07-20 Thread Susan Rea 
I would like to discuss on our Dev call.  I spent time as we approached this 
CDM refresh cycle to get a final answer for the documentation in Duke Redcap.  
Was our lapse (~78% complete on normal ranges) something we could remediate?  
We had a unique problem:  our central lab lost a section of historic normal 
range data when they upgraded software.  Our Data Curation report caught this, 
although no one else noticed.  Discussing with the lab, they could not restore 
it after time had passed and their data had changed.  Since these results had 
already been reported out a while back, so were historic lab results, no one 
else at Intermountain Healthcare has found this to be a problem.  Normal ranges 
may have been stored in up to 3 EMRs during the time this occurred.  We don’t 
have resources to try to put these normal ranges back into the CDM from the 
EMRs:  we load from the central lab.   Especially just to gain back 2% coverage 
on the Data Curation report: we think over time that gap will fill in and we 
will be back above 80%.  Our usual coverage of Lab Normal ranges for 
quantitative labs is ~95%.

So, I wonder what the consumers of lab data, investigators, need?  We sometimes 
use the Abnormal Flags to identify abnormal labs; as these don’t vary with the 
normal ranges used by the particular equipment or by age, sex or other 
variables.  The Abnormal Flag status was not lost in the problem described 
above for normal ranges.   Or sometimes the investigator will specify the 
ranges they consider interesting.  I cannot say that I have ever had to compare 
the lab results to the normal ranges and generate my own “high” or “low” 
determination for a study data set.

We have been asked to dump all of our lab data into the CDM.  It would make 
much more sense for either selective, highly used labs (as LOINC makes 
available) or add labs as the various clinical research teams define those that 
are important in their domains.  Wading through so many lab results in the CDM 
takes so much disk space, data transfer time from storage to local memory and 
makes our run times very long.   I like the characterization they have done for 
common labs across sites, and they did point out a few we were missing.  That 
is helpful.   It would be useful if DRNOC could articulate why it seems useful 
– or have they found it useful in practice – to ask for every site’s entire lab 
data holdings.

I believe DRNOC would need to justify why these Lab Normal tables in the CDM 
are needed.  For us, this is a lot of work, if even possible.  We are a 
hospital system across Utah.  Different labs in the system may have different 
ranges for the same LOINC.  We also use reference labs.  One must know that 
clinical labs calibrate whatever machines they are using and ranges may change 
upon calibration.  We have no process for keeping up with all changes:  this is 
what the LIMS does.

I think a more reasonable approach for research purposes, not for purposes of 
patient care where one might need to be exacting:  use standard normal ranges 
for each LOINC.  Does LOINC provide those?

Thanks,

Susan
Susan Rea, Medical Informaticist
Data Administrator, PCORnet Intermountain
Enterprise Analytics
Intermountain Healthcare
susan@imail.org801-694-6343 (cell)




From: Gpc-dev  On Behalf Of Mei Liu
Sent: Monday, July 20, 2020 8:16 AM
To: Dan Connolly ; gpc-dev@listserv.kumc.edu
Subject: RE: gpc-dev 21 July agenda and meeting notes

BE ALERT. External Sender. Be cautious.

Just to share with the GPC-dev group notes from the PCORnet Data WG meeting on 
July 17.

Discussion on data quality checks on labs

  *   Problem: lab completeness check requires >80% of labs reported with 
normal ranges, which many sites feel uncomfortable in assigning one if it does 
not come automatically from the EMR.
  *   Proposed easy solution: simplify the check by reporting whether a lab is 
a clinical vs statistical outlier (defined based on PCORnet population).
  *   Long-term fix (CDM 6.0): introduce a new CDM table to be called 
“reference range history” that would contain following elements for each lab:

o   Lab (LOINC)

o   Gender

o   Age (go/from)

o   Race

o   Normal range

o   Units

o   Effective dates
When reporting normal ranges of labs, indicate whether it is derived from the 
EMR or the reference range table.

Note that the long-term fix of adding a reference range history table will 
require extra work from the sites. The timeline for the work is not confirmed 
yet, but sites can start working on it.

Please let me know if you would like to discuss during the gpc-dev call.

Thanks,

Mei


From: Gpc-dev 
mailto:gpc-dev-boun...@listserv.kumc.edu>> 
On Behalf Of Dan Connolly
Sent: Monday, July 20, 2020 8:55 AM
To: gpc-dev@listserv.kumc.edu
Subject: gpc-dev 21 July agenda and meeting notes

What else for tomorrow?

UTHSCSA is scheduled to scribe

RE: gpc-dev 21 July agenda and meeting notes

2020-07-20 Thread Mei Liu 
Just to share with the GPC-dev group notes from the PCORnet Data WG meeting on 
July 17.

Discussion on data quality checks on labs

  *   Problem: lab completeness check requires >80% of labs reported with 
normal ranges, which many sites feel uncomfortable in assigning one if it does 
not come automatically from the EMR.
  *   Proposed easy solution: simplify the check by reporting whether a lab is 
a clinical vs statistical outlier (defined based on PCORnet population).
  *   Long-term fix (CDM 6.0): introduce a new CDM table to be called 
“reference range history” that would contain following elements for each lab:
 *   Lab (LOINC)
 *   Gender
 *   Age (go/from)
 *   Race
 *   Normal range
 *   Units
 *   Effective dates
When reporting normal ranges of labs, indicate whether it is derived from the 
EMR or the reference range table.

Note that the long-term fix of adding a reference range history table will 
require extra work from the sites. The timeline for the work is not confirmed 
yet, but sites can start working on it.

Please let me know if you would like to discuss during the gpc-dev call.

Thanks,

Mei


From: Gpc-dev  On Behalf Of Dan Connolly
Sent: Monday, July 20, 2020 8:55 AM
To: gpc-dev@listserv.kumc.edu
Subject: gpc-dev 21 July agenda and meeting notes

What else for tomorrow?

UTHSCSA is scheduled to scribe
https://docs.google.com/document/d/18NSOQU1dKCc6Hzv_-TpJQnNQ_TBo-zs5Af1AfXH051Y/edit


  1.  Convene, take roll, review records and plan the next meeting(s).

 *   11:00 a.m. Central Time.
​Meeting ID and access code: 
817-393-381; call +1 
(571) 317-3131
 *   Roll; Reminder - put site after your name in 
GoToMeeting preferences
GPC DevTeams 
represented? KUMC (chair), UIOWA, MCW, MCRI, UNMC, UTHSCSA (scribe), UTSW, MU, 
IndianaU, Utah, Allina, Intermountain, UTH
 *   Comments on the agenda? (ref 
SoftwareDev#tracking)
 On last week’s 
notes?
 (#12)
Recent tickets 
opened/closed - FYI 
(i.e. not intended for discussion)

*   None this week

 *   Next meeting(s): Jul 28; scribe: UTSW?, IU?

*   Note scribe 
rotation
 appendix
*   #759 
covid19 PCORNet 
datamarts 28 May 
“pause additional ETL development” until PCORI completes its review… Russ 
standing by for more info
*   Dan/KUMC to get more info about volume / quality issues where the 
line was divided (not immediately)
*   Marshfield will submit Bardet-Biedl Syndrome request through DROC

  1.  PCORnet CDM refresh with 
PPRL - due July 27

 *   C4UI r024 
Approved gold 
star!

  1.  
Milestone:tumor-reg-18
 aiming for Jul 10

 *   #749 
PCORNet style TUMOR 
table

*   Brian to update gpc-dev w.r.t. DROC request

 *   #739 HERON 
NAACCR ETL outdated by 
v18 
kumc-bmi/naaccr-tumor-data

*   DC to look into patient_mapping using item 2300 MRN

  1.  1228 covid query due July 21
PR: what’s expected, given May 28 “pause additional ETL development”?
Steph to ask DRNOC to clarify.
DC to confirm Russ is attending today’s PCORnet steering committee meeting and 
suggest that he seek clarification. Done: 1228 covid query due July 21? 
   Block, Jason 
Perry,M.D.


wash your hands 
...

--
Dan

___
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

gpc-dev 21 July agenda and meeting notes

2020-07-20 Thread Dan Connolly 
What else for tomorrow?

UTHSCSA is scheduled to scribe
https://docs.google.com/document/d/18NSOQU1dKCc6Hzv_-TpJQnNQ_TBo-zs5Af1AfXH051Y/edit


  1.  Convene, take roll, review records and plan the next meeting(s).

 *   11:00 a.m. Central Time.
​Meeting ID and access code: 
817-393-381; call +1 
(571) 317-3131

 *   Roll; Reminder - put site after your name in 
GoToMeeting preferences
GPC DevTeams 
represented? KUMC (chair), UIOWA, MCW, MCRI, UNMC, UTHSCSA (scribe), UTSW, MU, 
IndianaU, Utah, Allina, Intermountain, UTH

 *   Comments on the agenda? (ref 
SoftwareDev#tracking)
 On last week’s 
notes?
 (#12)
Recent tickets 
opened/closed - FYI 
(i.e. not intended for discussion)

*   None this week

 *   Next meeting(s): Jul 28; scribe: UTSW?, IU?

*   Note scribe 
rotation
 appendix

*   #759 
covid19 PCORNet 
datamarts 28 May 
“pause additional ETL development” until PCORI completes its review… Russ 
standing by for more info

*   Dan/KUMC to get more info about volume / quality issues where the 
line was divided (not immediately)

*   Marshfield will submit Bardet-Biedl Syndrome request through DROC

  2.  PCORnet CDM refresh with 
PPRL - due July 27

 *   C4UI r024 
Approved gold 
star!

  3.  
Milestone:tumor-reg-18
 aiming for Jul 10

 *   #749 
PCORNet style TUMOR 
table

*   Brian to update gpc-dev w.r.t. DROC request

 *   #739 HERON 
NAACCR ETL outdated by 
v18 
kumc-bmi/naaccr-tumor-data

*   DC to look into patient_mapping using item 2300 MRN

  4.  1228 covid query due July 21
PR: what’s expected, given May 28 “pause additional ETL development”?
Steph to ask DRNOC to clarify.
DC to confirm Russ is attending today’s PCORnet steering committee meeting and 
suggest that he seek clarification. Done: 1228 covid query due July 21? 
   Block, Jason 
Perry,M.D.


wash your hands 
...

--
Dan

___
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev