Hello Keith, Russ and anyone interested: I thought I sent this weeks ago, but must have sent it to a black hole! So, sorry this is a lagging response.
I had done some digging into our lab normal ranges data, and the following is a good brief example of the issues with a static normal ranges table: These were the normal ranges reported in our EMR for LOINC 74774-1 Glucose:MCnc:Pt:Ser/Plas/Bld:Qn during one month Jan, 2017: NL Rng 201701 count 40.00 - 96.00 112 46-96 1801 60.00 - 99.00 4 60-100 2 60-108 1950 60.00 - 108.00 4 60-115 6342 60.00 - 115.00 4 64-112 2 64-128 1 65-99 92395 65.00 - 99.00 764 70-99 16 70-100 1 70-105 1 70-110 14 74-100 7 74-106 2 total 103422 There are many explanations for the variation. I have worked with lab normal ranges data in different settings and contexts, and it is very difficult to reconstruct how a lab analyzer, usually, reported out the normal ranges with a result. (Serum glucose may have its own unique quality complications, with “fasting” or not. Some previous work with Mayo Clinic showed that the “fasting” glucose test order code was not always used when patient fasting and vice versa. But the lab may know, based on a comment or notation in the order.) I looked at an alternative method to characterize whether results were in the normal ranges, that we have used in multi-center research and Intermountain decision support. We find that the Abnormal Flags that come with the results (and usually the normal ranges) are very consistent. In the gap in normal ranges that we experienced, due to a software version upgrade data loss event, the Abnormal flags were intact in the source Lab and consequently, the CDM, data. This shows the correspondence of Abnormal Flags to logic that determines if Result_Num is within the given normal ranges: Lab Results 2018 with EQ Result_Modifier, Norm_Modfier_Low and Norm_Modifier_High ABN_IND Result_Num < Norm_Range _Low Result_Num > Norm_Range _High Count AH 0 0 17 AH 0 1 4216343 AL 0 0 6 AL 1 0 3448286 null 1 0 8 null 0 0 24633566 null 0 1 63 Is there any interest to characterize more lab results data to see how well the ABN_IND performs to fill gaps where there are not normal ranges? Thank you, Susan Susan Rea, Medical Informaticist Data Administrator, PCORnet Intermountain Enterprise Analytics Intermountain Healthcare susan....@imail.org<mailto:susan....@imail.org> 801-694-6343 (cell) From: Gpc-dev <gpc-dev-boun...@listserv.kumc.edu> On Behalf Of Keith Marsolo Sent: Wednesday, August 5, 2020 9:36 AM To: Russ Waitman <rwait...@kumc.edu> Cc: gpc-dev@listserv.kumc.edu Subject: Re: Follow up on the Data WG Meeting 7/17 BE ALERT. External Sender. Be cautious. Good question. In that case, we’d ideally have entries for each organization along with a way to identify which records pertain to a given organization within the CDM. Keith On Aug 3, 2020, at 4:39 PM, Russ Waitman <rwait...@kumc.edu<mailto:rwait...@kumc.edu>> wrote: Thanks Keith, I am a bit removed if we have a CDM that integrates data from multiple hospitals (Intermountain), one could have multiple organizations with multiple references in that table? Russ From: Dan Connolly <dconno...@kumc.edu<mailto:dconno...@kumc.edu>> Date: Monday, August 3, 2020 at 1:25 PM To: Keith Marsolo <keith.mars...@duke.edu<mailto:keith.mars...@duke.edu>> Cc: Mei Liu <mei...@kumc.edu<mailto:mei...@kumc.edu>>, Russ Waitman <rwait...@kumc.edu<mailto:rwait...@kumc.edu>>, "GPC-DEV@LISTSERV.KUMC.EDU<mailto:GPC-DEV@LISTSERV.KUMC.EDU>" <gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>> Subject: Re: Follow up on the Data WG Meeting 7/17 Ah. OK. I understand now. ________________________________ From: Keith Marsolo <keith.mars...@duke.edu<mailto:keith.mars...@duke.edu>> Sent: Monday, August 3, 2020 1:19 PM To: Dan Connolly <dconno...@kumc.edu<mailto:dconno...@kumc.edu>> Cc: Mei Liu <mei...@kumc.edu<mailto:mei...@kumc.edu>>; Russ Waitman <rwait...@kumc.edu<mailto:rwait...@kumc.edu>>; gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu> <gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>> Subject: Re: Follow up on the Data WG Meeting 7/17 Hi Dan. The purpose of the lookup table is to handle those results where the range is not part of the record itself. Many clinical labs maintain a table or catalog of ranges. The idea would be to have the lookup table capture that information. But we wouldn’t go the other direction. We wouldn’t try to reverse engineer the range based on what’s stored within the individual records. If a record has a range and a unit, that’s sufficient. Thanks. Keith On Aug 3, 2020, at 2:09 PM, Dan Connolly <dconno...@kumc.edu<mailto:dconno...@kumc.edu>> wrote: Hi Kieth and company, I think the concern here is that at a site like Intermountain, there are N lab systems, and building one normal range metadata table to rule them all is somewhere between a large engineering project and an open research project. Given that we already have LAB_RESULT_CM.NORM_RANGE_LOW and LAB_RESULT_CM.NORM_RANGE_HIGH for the the widespread practice where normal ranges come out of the lab systems with each result, why is it essential to build a table with some compressed version of those data? -- Dan ________________________________ From: Gpc-dev <gpc-dev-boun...@listserv.kumc.edu<mailto:gpc-dev-boun...@listserv.kumc.edu>> on behalf of Mei Liu <mei...@kumc.edu<mailto:mei...@kumc.edu>> Sent: Monday, August 3, 2020 9:01 AM To: Russ Waitman <rwait...@kumc.edu<mailto:rwait...@kumc.edu>>; gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu> <gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>> Subject: FW: Follow up on the Data WG Meeting 7/17 Please see the following email for DRONC’s response regarding our concerns and questions with the CDM lab normal range table. Thanks, Mei From: Keith Marsolo <keith.mars...@duke.edu<mailto:keith.mars...@duke.edu>> Sent: Thursday, July 30, 2020 12:10 PM To: Mei Liu <mei...@kumc.edu<mailto:mei...@kumc.edu>> Subject: Re: Follow up on the Data WG Meeting 7/17 Importance: High Hi Mei. We ask for all labs for a couple of reasons. The first is that it allows us to get a sense of the “universe” of lab data across the PCORnet, and allows us to track the network’s improvement in mapping labs to LOINC. The second reason is that we get requests from outside investigators / sponsors about potential projects that require lab data. Through the data curation results, we can determine which sites have records using LOINC codes, and having all labs allows us to look at the RAW_NAME to determine if the records are potentially available and just not mapped. Going forward, we’ve been working with the NLM on queries to better assess the quality of lab data mappings, which will be more effective if applied to all labs. For the 2nd question, it’s really about normal ranges and units. We can’t really query lab data without units, because while we could potentially guess at the unit, we’d have to trust that the LOINC code is correct, and we still discover instances where labs have incorrect LOINC codes. With normal ranges, we haven’t done a ton of work with them yet because we’re still relatively new at querying labs, but they can be very helpful in assigning thresholds or cut points. Many vary by age/race/gender, so understanding that site-level variation is helpful during analysis. Hope that helps. Let me know if there are other questions. Keith On Jul 27, 2020, at 10:54 AM, Mei Liu <mei...@kumc.edu<mailto:mei...@kumc.edu>> wrote: Hi Keith, After the Data WG meeting on 7/17, GPC sites had an internal discussion on the feasibility of creating a reference range look-up table for labs. Our major concern is that it may not be feasible for sites like Intermountain Health and IU/Regenstrief in our network to create such table because they have numerous hospitals that use different lab facilities resulting in inconsistent lab normal ranges. Intermountain had a unique case where their central lab lost a section of historic normal range data when they upgraded software, resulting in 78% complete on normal ranges whereas their usual coverage of Lab Normal ranges for quantitative labs is ~95%. So, that gap will fill in and completeness should be back above 80% over time. GPC sites would like the DRNOC to clarify the following two questions: 1. Since we have been asked to dump all lab data into CDM, it would be useful if the 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. 2. Why are these Lab Normal tables in the CDM needed? Thank you! Mei ------------------------------------------------- Mei Liu, PhD Associate Professor Department of Internal Medicine Division of Medical Informatics University of Kansas Medical Center Office: 913-945-6446 Fax: 913-588-4880 NOTICE: This e-mail is for the sole use of the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, you are prohibited from reviewing, using, disclosing or distributing this e-mail or its contents. If you have received this e-mail in error, please contact the sender by reply e-mail and destroy all copies of this e-mail and its contents.
_______________________________________________ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
