RE: CDM 6.0 review responses from MCW

[Susan Rea]

Thank you, Laura and Alex, for reviewing the changes.  I have a few comments on 
your comments, added inline below, marked with *SR*.  We put our local team 
together to answer their Survey a few weeks ago so had an earlier chance for 
input.

Thanks,
Susan Rea

-Original Message-
From: Gpc-dev  On Behalf Of Manuel, Laura S M
Sent: Friday, September 25, 2020 11:15 AM
To: Stoddard, Alexander ; gpc-dev@listserv.kumc.edu
Subject: RE: CDM 6.0 review responses from MCW

BE ALERT. External Sender. Be cautious.

Thanks Alex for diving into this first and stating things so eloquently.
I agree with everything Alex put and would add:

>If we move the records from VITAL to OBS_CLIN, we need to merge the
>valuesets for the provenance fields. If we do that, OBSCLIN_SOURCE would 
>contain OD (Order/EHR), RG (Registry/ancillary system) and HC (Healthcare 
>delivery setting).
>There is a fair amount of overlap between these terms.  We are proposing to 
>deprecate OD and RG and utilize HC instead (we will make the same change to 
>OBSGEN_SOURCE as well).
>Any concerns with this change?

Registries normally contain chart abstracted data which can be useful, but also 
adds an additional step for human error. I believe it would be useful to keep 
the distinction between potentially interpreted data and raw data from the EHR.

>Addition of Result_text
This value would likely be a free text field and this may allow PHI values to 
slip through. We would not recommend the addition of a free text field in a 
limited data set.

*SR* I agree we may have privacy issues populating free text, where we do find 
providers may use any convenient place to put a little note.  So, we would have 
to carefully curate whatever data were requested. It would be helpful if DRNOC 
would identify specific lab tests that are needed or anticipated and narrow the 
curation task to what may be useful lab data.  The "everything you got" 
strategy would really be difficult for sharing text results.  Also, I like 
Alex's comment about bloating the table and his solution.  /*SR*

>Addition of Raw Condition Text
This value is a free text field at one of our institutions and a value set at 
another. We could use the value set, but would not be able to add a free text 
string to a limited data set.

*SR* We have the patient reported reason for visit as free text and appears to 
be literal short version of what patient tells clerk when making appointment or 
what they or family told admitting clerk.  We also have coding specialists' 
Admitting Dx ICD code for hospital visits.  We would also be suspicious for PHI 
in this text.  Unsure of the value proposition for this versus intake nursing 
notes, if hospital or ED encounter. Patient may not be reliable reporter of 
symptoms if they are acutely ill at admission, or making an appointment for a 
sensitive problem. /*SR*

-Original Message-
From: Stoddard, Alexander 
Sent: Thursday, September 24, 2020 10:02 PM
To: gpc-dev@listserv.kumc.edu
Cc: Taylor, Bradley ; rwait...@kumc.edu; Manuel, Laura S M 

Subject: CDM 6.0 review responses from MCW

Hello GPC-DEV,

MCW agreed to review the CDM 6.0 spec during the dev call 2020-09-22. The 
replies to DRNOC, using an excel file template (available at 
https://urldefense.proofpoint.com/v2/url?u=https-3A__pcornet.imeetcentral.com_drnoc-2Dworkgroups_folder_WzIwLDEzMTI2ODA5XQ_=DwIFAw=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=ZgEr_8KiuJ9caTG5rYIXlYWcbHCYl2xRU1V7DOuK2Ok=3_hAUe-wl_W9YElfhi1wlFIpXD6IV9AyrIpsadNQMQY=
 ) , have been requested by end of day Friday 2020-09-25.

Below are a text version of the responses that I will be sending on behalf of 
MCW.


Main questions seeking feedback
-

>As the CDM has grown in size, the image included in the specification (Page 9) 
> conveys less and less information.
>Any concerns if it is deleted?
Not a concern, but a highlighted list of changed tables/new columns on a single 
page is useful

>Suggestions on what we might consider as a replacement?
A machine readable, diff-able and version controlled schema definition would be 
very useful. Potentially this would allow tool assisted SQL generation for the 
different RDMS, or even visualization generation. A candidate for such a schema 
definition format would be that used by sql-alchemy python package: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.sqlalchemy.org_en_13_core_metadata.html=DwIFAw=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=ZgEr_8KiuJ9caTG5rYIXlYWcbHCYl2xRU1V7DOuK2Ok=o_ogbev5sUlo1LGRfUUSH3IayPshWLSZQ5TjU2TyMfg=

>Any there any concerns about the strategy to deprecate VITAL and move the 
>records to OBS_CLIN?
 OBS_CLIN is a much better data model for vitals but transitioning distinct 
columns in the VITALs table to a s

RE: Follow up on the Data WG Meeting 7/17

[Susan Rea]

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  On Behalf Of Keith Marsolo
Sent: Wednesday, August 5, 2020 9:36 AM
To: Russ Waitman 
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 
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 mailto:dconno...@kumc.edu>>
Date: Monday, August 3, 2020 at 1:25 PM
To: Keith Marsolo mailto:keith.mars...@duke.edu>>
Cc: Mei Liu mailto:mei...@kumc.edu>>, Russ Waitman 
mailto:rwait...@kumc.edu>>, 
"GPC-DEV@LISTSERV.KUMC.EDU<mailto: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 mailto:keith.mars...@duke.edu>>
Sent: Monday, August 3, 2020 1:19 PM
To: Dan Connolly mailto:dconno...@kumc.edu>>
Cc: Mei Liu mailto:mei...@kumc.edu>>; Russ Waitman 
mailto:rwait...@kumc.edu>>; 
gpc-dev@listserv.kumc.edu<mailto: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 
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 w

RE: gpc-dev 21 July agenda and meeting notes

[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.org<mailto:susan@imail.org>801-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<mailto:gpc-dev@listserv.kumc.edu>
Subject: gpc-dev 21 July agenda and meeting notes

What else for tomorrow?

UTHSCSA is scheduled to scribe
ht

RE: trac #56: shareable synthetic test data sets: Epic clarity, i2b2, NAACCR, ...

[Susan Rea]

I found published posters from this meeting, but no other information besides 
the agenda.  Were any meeting papers / presentations preserved or available to 
the scientific / data community?   Thank you so much, Susan Rea

-Original Message-
From: Gpc-dev  On Behalf Of GPC Informatics
Sent: Tuesday, June 16, 2020 10:19 AM
Cc: bzscho...@kumc.edu; b...@uthscsa.edu; ngra...@kumc.edu; 
gpc-dev@listserv.kumc.edu
Subject: Re: trac #56: shareable synthetic test data sets: Epic clarity, i2b2, 
NAACCR, ...

WARNING: Stop. Think. Read. This is an external email.

#56: shareable synthetic test data sets: Epic clarity, i2b2, NAACCR, ...
--+---
 Reporter:  Dan Connolly  |   Owner:  Dan Connolly
 Type:  enhancement   |  Status:  assigned
 Priority:  minor |   Milestone:  morning-star
Component:  data-sharing  |  Resolution:
 Keywords:|  Blocked By:  388, 435
 Blocking:|   Sensitive:  1
--+---
Changes (by Dan Connolly):

 * sensitive:   => 1


Comment:

 > COVID-19 Synthetic Dataset – derived from SYNTHEA, also in a DOCKER  image
   -- 
https://urldefense.proofpoint.com/v2/url?u=https-3A__transmartfoundation.org_agenda-2Dmodified_=DwIFaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=8vr_BporUXRZvDVzBH3rfxkxD-1l5QZnPHYrZ66Sstw=Xs-VFqVsFrj_m9chrpiFLVkbr_ukgzKXoYXajH0Irz4=

--
Ticket URL: 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__informatics.gpcnetwork.org_trac_Project_ticket_56-23comment-3A38=DwIFaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=8vr_BporUXRZvDVzBH3rfxkxD-1l5QZnPHYrZ66Sstw=h1Ew7NDAhMAyc9FQYyazqq3dANz1SMz0SXJ8OJkWHxE=
 > gpc-informatics 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__informatics.gpcnetwork.org_trac_Project=DwIFaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=8vr_BporUXRZvDVzBH3rfxkxD-1l5QZnPHYrZ66Sstw=-HYMz7-KwWXWvyL-y020OAqV9AuR9obdxLivsumSCWk=
 > Greater Plains Collaborative
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

COVID CDM Data Element: Mechanical Ventilation

[Susan Rea]

For simplicity, I am pasting the guidance for "Use of mechanical ventilation 
(Y/N)" (OBS_GEN) here:

*   Binary flag to indicate whether the patient was on mechanical 
ventilation during the encounter. Expected primarily for EI and IP encounters, 
but may be present for ED or other encounters.  Partners may need to derive 
based on procedure codes or inpatient flowsheets.

*   Set OBSGEN_TYPE="PC_COVID", OBSGEN_CODE = 3000 and OBSGEN_SOURCE="DR"

*   If patient was on mechanical ventilation, set RESULT_TEXT="Y"; If it is 
known that the patient was NOT put on mechanical ventilation, set to "N".

Question:  Are you including invasive and non-invasive ventilation?  CPap, 
BiPap, and intubation / bedside ventilator?
If anyone has the Charge or CPT codes they are using, that would be really 
helpful.

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)




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

RE: COVID LOINCs being utilized at UofU

[Susan Rea]

These are the four Antigen test LOINC codes (2 of them map to same LOINC code) 
currently performed in our lab.  I have heard that Antibody test(s) were coming 
to our lab, but have not yet gotten notified.  Those will be interesting in the 
study data.


'94309-2'
'94500-6'
'94565-9'  (This one was not in the latest DRNOC 
COVID_CDM_Inclusion-2020-04-06.xlsx found at the same URL as below )





Also, sharing the mapping of result values since I looked for this for an hour 
or so and finally found it in the FAQ at this link 
https://pcornet.imeetcentral.com/pcornet20folderwziwldewodeymzc1xq/folder/WzIwLDEyNzY0MjQ5XQ/

Source value (or similar variation)
Temporary CDM mapping
Detected
RNA Detected
Antigen (Ag) Detected
Suspected Positive
Positive
Not Detected
Antibody (Ab) Not Detected
Antigen (Ag) Not Detected
RNA Not Detected
Negative
Indeterminate abnormal
Undetected
Pending
Do not load into CDM.
Wait until final result is available.
Invalid
Specimen unsatisfactory
Do not load into CDM at this time



Thanks,

Susan





-Original Message-
From: Gpc-dev  On Behalf Of Reid Holbrook
Sent: Tuesday, April 28, 2020 10:38 AM
To: gpc-dev@listserv.kumc.edu
Subject: COVID LOINCs being utilized at UofU



WARNING: Stop. Think. Read. This is an external email.





Here's a list of LOINCs being used to help identify COVID at the University of 
Utah:

'7993-9'

,'31208-2'

,'94531-1'

,'94500-6'

,'29908-1'

,'29910-7'

,'29909-9'

,'39528-5'

,'40982-1'

,'38917-1'

,'40988-8'

,'34487-9'



Thanks.

Reid



___

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=DwICAg=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=JG92RToxfNzZFEz8Ys4GE2E0EYd3gwXNC9MmtaGp-B0=6hUxSqUGtuuyrogAkfBD7xCtgO4hDNpyTvYAN1F32-U=

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

Intermountain LOINC codes for COVID-19 tests

[Susan Rea]

Hello,

There was a new test added today, so the three that our lab generates are:

HealthSentry Reportable Name
LOINC_CD
Description
SARS coronavirus 2 RNA [Interpretation] in Unspecified specimen Qualitative by 
NAA with probe detection
94309-2
SARS-CoV-2 by PCR (N1,N2,N3)
SARS coronavirus 2 RNA panel - Respiratory specimen by NAA with probe detection
94500-6
SARS CoV2 by PCR ARUP (Ref Lab)
SARS coronavirus 2 RNA [Presence] in Nasopharynx by NAA with non-probe detection
94565-9
SARS-CoV-2 by PCR (2a,2d,2e)

Our terminology team assigns the LOINC codes.

As stated on the call, we explored the various codes in the 
COVID_CDMandQuery.pptx that Russ sent to this list on Mar 23, 2020 10:50A (MT). 
 We found a small number of the ICD codes, possibly since it takes some lag 
time for coders to assign those after discharge.  We also have to figure out 
where Telehealth is storing virtual visits and coding, since ambulatory 
patients are encouraged to use the Connect Care app, at this time, if not 
emergency.  For the first version, we are relying on the positive cases 
determined by positive lab results - I think they also include Inconclusive 
until they are rerun - that are generated by another Infectious Diseases team 
at Intermountain for tracking COVID-19 cases.  Still validating how ICD codes 
or other annotations in the EMR can add cases that belong in the cohort.

Best wishes,
Susan
Susan Rea, Medical Informaticist
Data Administrator, PCORnet Intermountain
Enterprise Analytics
Intermountain Healthcare
susan@imail.org<mailto:susan@imail.org>801-694-6343 (cell)


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

FAQ on LOINC coding for COVID-19

[Susan Rea]

https://loinc.org/sars-coronavirus-2/?utm_source=2020-03-26+Coronavirus+Webinar_campaign=776284156c-EMAIL_CAMPAIGN_2020_03_19_09_40_medium=email_term=0_f9219fabb0-776284156c-455723097

best wishes,
Susan
Susan Rea, Medical Informaticist
Data Administrator, PCORnet Intermountain
Enterprise Analytics
Intermountain Healthcare
susan@imail.org<mailto:susan@imail.org>801-694-6343 (cell)
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

RE: gpc-dev 14 Jan agenda and meeting notes

[Susan Rea]

Sravani,

Thanks, mine finally ran, and Part B covered only 2018 so much faster.  I think 
I know one reason we get long run times on some queries and may be able to 
correct for that in future.  This set of queries was a profile of the data, 
from different perspective than Data Curation.

I looked at results of FD9096A and B, as we are drilling into our BMI and 
Smoking data reliability.   If there is interest, I found a few interesting 
things in the report versus changing some of the denominators and recalculating 
the % with Missing BMI or Smoking data. Could say or show on one of the DEV 
meetings, if there is interest.

Thanks,
Susan


From: Gpc-dev  On Behalf Of Sravani Chandaka
Sent: Tuesday, January 14, 2020 7:40 AM
To: Susan Rea ; Dan Connolly ; 
gpc-dev@listserv.kumc.edu
Subject: Re: gpc-dev 14 Jan agenda and meeting notes

Hi Susan,
I ran both these queries last week. They were due by January 10th for us. Part 
A ran ~8 hours and Part B ran ~6 hours.

Thanks
Sravani

From: Gpc-dev 
mailto:gpc-dev-boun...@listserv.kumc.edu>> 
on behalf of Susan Rea mailto:susan@imail.org>>
Sent: Monday, January 13, 2020 5:04 PM
To: Dan Connolly mailto:dconno...@kumc.edu>>; 
gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu> 
mailto:gpc-dev@listserv.kumc.edu>>
Subject: RE: gpc-dev 14 Jan agenda and meeting notes


Are others running the DRNOC query request duo, due Jan 21, 2020:

Distributed Jan 7, 2020

“PCORnet Descriptive query request, Part A (fd9096a_pmp_wp008) and Part B 
(fd9096b_pmp_wp008), using PCORnet Modular Program (PMP), Baseline Table, 
Vital, and Cohort Quality Assessment modules. These queries were requested by 
Chris Forrest and the PCORI Steering Committee to describe the network patient 
composition, utilization, medical encounters (diagnosis, prescribing, labs), 
comorbidities, anthropometrics, and health behaviors. “

I tried to get this off my SAS queue before running the data curation but first 
program has been running since Saturday!  Are others having long run times?  I 
may have to kill it off for data curation.  This looks like the next version of 
the query they sent previously, then retracted.



  Distributed 8/14/2019



“The Query Fulfillment and Analytics team is pleased to announce the release of 
the PCORI Table 1 Descriptives Query (pcori_pmp_wp003), using PCORnet Modular 
Program (PMP), Baseline and Vital table modules. This query was requested by 
PCORI Steering Committee led by the Table 1/Publication Work Group lead, Chris 
Forrest, to describe the network patient composition, utilization, medical 
encounters (diagnosis, prescribing, labs), comorbidities, anthropometrics, and 
health behaviors. “



Sent Aug 29, 2019

“  …   update regarding the PCORI Descriptives query (pcori_pmp_wp003).  We 
greatly appreciate your feedback regarding query execution and the run times 
seen at your DataMarts.  This feedback has helped us to identify steps of the 
program that required longer processing times.  Based on our investigation, we 
plan to revise the query to bypass some of these more time consuming steps with 
the aim of reducing the overall run time for this query.



While no further action is required from your DataMarts at this time, we hope 
that you might be willing to re-execute the new query package and to help us 
assess run time improvements using the new approach.  We would anticipate 
distribution of the updated query in the coming weeks.



All DataMarts will receive query credit for this query and the query will be 
cancelled via the query tool.  “



Hate to bring a problem forward from 2019, but this still seems problematic for 
me.  Also,  since running the first time, I have implemented the recommended 
SAS table indices.



Thank you,

Susan Rea







From: Gpc-dev 
mailto:gpc-dev-boun...@listserv.kumc.edu>> 
On Behalf Of Dan Connolly
Sent: Monday, January 13, 2020 8:17 AM
To: gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>
Subject: gpc-dev 14 Jan agenda and meeting notes



WARNING: Stop. Think. Read. This is an external email.

What else for tomorrow?



KUMC is scheduled to scribe

https://docs.google.com/document/d/1pcfwNwRdOsHUq5KHBtnaQqffD6Gn2RdTzUNJuzimAvI/edit#<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1pcfwNwRdOsHUq5KHBtnaQqffD6Gn2RdTzUNJuzimAvI_edit-23=DwMGaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=f-LKnHwlEMDGXTsST2AhVHAYJ-l2LWUO_AkvlQiXByo=UYrZ4cCItQEKem2MqhwN1RdpISgk-15jijZHsvzLdu8=>



agenda snapshot:

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

 *   11:00 a.m. Central Time.
​Meeting ID and access code: 
817-393-381<https://global.gotomeeting.com/meeting/join/817393381>; call +1 
(571) 317-3131
 *   Roll; Reminder - put site after your name in 
GoToMeeting<https://global.gotomeet

RE: gpc-dev 14 Jan agenda and meeting notes

[Susan Rea]

Are others running the DRNOC query request duo, due Jan 21, 2020:
Distributed Jan 7, 2020
“PCORnet Descriptive query request, Part A (fd9096a_pmp_wp008) and Part B 
(fd9096b_pmp_wp008), using PCORnet Modular Program (PMP), Baseline Table, 
Vital, and Cohort Quality Assessment modules. These queries were requested by 
Chris Forrest and the PCORI Steering Committee to describe the network patient 
composition, utilization, medical encounters (diagnosis, prescribing, labs), 
comorbidities, anthropometrics, and health behaviors. “
I tried to get this off my SAS queue before running the data curation but first 
program has been running since Saturday!  Are others having long run times?  I 
may have to kill it off for data curation.  This looks like the next version of 
the query they sent previously, then retracted.

  Distributed 8/14/2019

“The Query Fulfillment and Analytics team is pleased to announce the release of 
the PCORI Table 1 Descriptives Query (pcori_pmp_wp003), using PCORnet Modular 
Program (PMP), Baseline and Vital table modules. This query was requested by 
PCORI Steering Committee led by the Table 1/Publication Work Group lead, Chris 
Forrest, to describe the network patient composition, utilization, medical 
encounters (diagnosis, prescribing, labs), comorbidities, anthropometrics, and 
health behaviors. “

Sent Aug 29, 2019
“  …   update regarding the PCORI Descriptives query (pcori_pmp_wp003).  We 
greatly appreciate your feedback regarding query execution and the run times 
seen at your DataMarts.  This feedback has helped us to identify steps of the 
program that required longer processing times.  Based on our investigation, we 
plan to revise the query to bypass some of these more time consuming steps with 
the aim of reducing the overall run time for this query.

While no further action is required from your DataMarts at this time, we hope 
that you might be willing to re-execute the new query package and to help us 
assess run time improvements using the new approach.  We would anticipate 
distribution of the updated query in the coming weeks.

All DataMarts will receive query credit for this query and the query will be 
cancelled via the query tool.  “

Hate to bring a problem forward from 2019, but this still seems problematic for 
me.  Also,  since running the first time, I have implemented the recommended 
SAS table indices.

Thank you,
Susan Rea



From: Gpc-dev  On Behalf Of Dan Connolly
Sent: Monday, January 13, 2020 8:17 AM
To: gpc-dev@listserv.kumc.edu
Subject: gpc-dev 14 Jan agenda and meeting notes

WARNING: Stop. Think. Read. This is an external email.
What else for tomorrow?

KUMC is scheduled to scribe
https://docs.google.com/document/d/1pcfwNwRdOsHUq5KHBtnaQqffD6Gn2RdTzUNJuzimAvI/edit#<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1pcfwNwRdOsHUq5KHBtnaQqffD6Gn2RdTzUNJuzimAvI_edit-23=DwMGaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=f-LKnHwlEMDGXTsST2AhVHAYJ-l2LWUO_AkvlQiXByo=UYrZ4cCItQEKem2MqhwN1RdpISgk-15jijZHsvzLdu8=>

agenda snapshot:

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

 *   11:00 a.m. Central Time.
​Meeting ID and access code: 
817-393-381<https://global.gotomeeting.com/meeting/join/817393381>; call +1 
(571) 317-3131
 *   Roll; Reminder - put site after your name in 
GoToMeeting<https://global.gotomeeting.com/meeting/join/817393381> preferences
GPC 
DevTeams<https://urldefense.proofpoint.com/v2/url?u=https-3A__informatics.gpcnetwork.org_trac_Project_wiki_DevTeams=DwMGaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=f-LKnHwlEMDGXTsST2AhVHAYJ-l2LWUO_AkvlQiXByo=y8dG9NccNibR_HDE0mRheKv11JfiexnGjmGUkQQwz_k=>
 represented? KUMC, UIOWA, MCW, MCRI,  UNMC, UTHSCSA, UTSW, MU, IndianaU, Utah, 
Allina, Intermountain

*   Today's scribe: KUMC

 *   Comments on the agenda? (ref 
SoftwareDev#tracking<https://urldefense.proofpoint.com/v2/url?u=https-3A__informatics.gpcnetwork.org_trac_Project_wiki_SoftwareDev-23tracking=DwMGaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=f-LKnHwlEMDGXTsST2AhVHAYJ-l2LWUO_AkvlQiXByo=pJQFfBXmcWAUwk1-4dQFsZ5Gy8V6z1Z6lip0r5-GM1Y=>)
 On last week’s notes? 
(#12<https://urldefense.proofpoint.com/v2/url?u=https-3A__informatics.gpcnetwork.org_trac_Project_ticket_12=DwMGaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=f-LKnHwlEMDGXTsST2AhVHAYJ-l2LWUO_AkvlQiXByo=WEzi-1F8IrT6ENvESiOW5jBcii-b7BGEA0eSzZi1Wl0=>)
Recent tickets 
opened/closed<https://urldefense.proofpoint.com/v2/url?u=https-3A__informatics.gpcnetwork.org_trac_Project_timeline=DwMGaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=f-LK

DeathDataSharing and Ticket #688

[Susan Rea]

Thanks, GPC, for providing death dates and great instructions for how to use 
and who can use.

As we plan to implement the SS death dates at Intermountain, can some of you 
send estimates of the time it has taken for your programmer/analyst/dev team to 
implement this for the first time and then subsequently?  That would really 
help us plan and do it.

Thanks in advance and Happy Holidays,
Susan
Susan Rea, Medical Informaticist
Data Administrator, PCORnet Intermountain
Enterprise Analytics
Intermountain Healthcare
801-694-6343 (cell) / susan@imail.org

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

RE: [External] Re: Populating the CDM

[Susan Rea]

Intermountain:  we also post-process to remove orphan encounterid, domains 
known to have encounterid distinct from the patient visit encounterid. No 
patients are loaded to our Analytic Health Repository (AHR) that do not have 
minimum demographic information or a clinical event that indicates they have 
been seen medically  - mainly a Face to Face encounter.  I believe we remove 
people who may have been seen only as a donor.  The goal in our AHR, as I 
believe should be for CDM, is to include patients who have received care and 
have some record of that care.

Thanks, Susan

From: Gpc-dev  On Behalf Of Campbell, James R
Sent: Monday, October 7, 2019 12:06 PM
To: Gryzlak, Brian M ; gpc-dev@listserv.kumc.edu
Subject: Re: [External] Re: Populating the CDM

WARNING: Stop. Think. Read. This is an external email.
It is not required, but compliance with PCORnet data quality constraints was a 
lot easier once we took the steps on post-processing
Jim

From: Gryzlak, Brian M mailto:brian-gryz...@uiowa.edu>>
Sent: Monday, October 7, 2019 9:56 AM
To: Campbell, James R mailto:campb...@unmc.edu>>; 
gpc-dev@listserv.kumc.edu 
mailto:gpc-dev@listserv.kumc.edu>>
Subject: RE: [External] Re: Populating the CDM

Non-UNMC email

Thanks Jim - is that decision guided internally by UNMC or is it something 
PCORnet asks or requires?



From: Campbell, James R mailto:campb...@unmc.edu>>
Sent: Monday, October 7, 2019 10:55 AM
To: Gryzlak, Brian M mailto:brian-gryz...@uiowa.edu>>; 
gpc-dev@listserv.kumc.edu
Subject: [External] Re: Populating the CDM



In our final post-processing run, Nebraska removes all patients who have no 
data in LAB, PROCEDURES, MED_ADMIN, PRESCRIBING, DISPENSING, DIAGNOSIS, 
CONDITION ie clinical information.  ENCOUNTERS is not our primary concern.

Jim



From: Gpc-dev 
mailto:gpc-dev-boun...@listserv.kumc.edu>> 
on behalf of Gryzlak, Brian M 
mailto:brian-gryz...@uiowa.edu>>
Sent: Monday, October 7, 2019 9:30 AM
To: gpc-dev@listserv.kumc.edu 
mailto:gpc-dev@listserv.kumc.edu>>
Subject: Populating the CDM



Non-UNMC email

Hi everyone,



Do other sites include patients in their CDM if there is no corresponding 
record in the ENCOUNTERS table?  I believe UIOWA has done so in the past but 
wanted to check to see what others are doing/have done.



Thanks,

Brian



Brian M. Gryzlak, MSW, MA

Project Coordinator

S423 CPHB

319.335.8218

The University of Iowa

Iowa City, IA 52242

brian-gryz...@uiowa.edu



Health Effectiveness Research Center 
(HERCe)



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.

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.
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

RE: Data Quality Report - Cycle 6, Refresh 3 (July 2019)

[Susan Rea]

Addressing the "Low Cell Count" Exception in the Data Curation Cycle 6, Third 
Refresh Performance Report:

I began to see query requests from the DRNOC recently asking to not suppress 
data for small cell sizes, and did not know why this change.  When I responded 
to the Query Fulfillment team to say that we had local governance for 
suppressing small cell sizes, they said:

Thank you for your question.  The PMP program allows for you to update the 
masking parameter as required by your DM/CRN's governance.  The default is 0, 
or no masking, given the CRN contract language around masking of cell counts.

Can someone point out the GPC contract language and whether that might be 
included in our current DSA with GPC?  I need the provenance of this change in 
order to process downstream with our specific compliance team (Cybersecurity) 
for responding to de-identified data queries via PopMedNet.  I think this might 
fit into the conversations as we process the new PCORnet DSA V3.0

Meantime, we have to suppress small cell sizes per original PCORnet local 
compliance agreements.

Thanks so much,
Susan Rea
CDM Data Administrator
Intermountain Healthcare

From: Gpc-dev  On Behalf Of Hillary Sandoval
Sent: Monday, September 16, 2019 9:08 AM
To: GPC-DEV@LISTSERV.KUMC.EDU; 'Brittany Zschoche' 

Subject: Data Quality Report - Cycle 6, Refresh 3 (July 2019)

WARNING: Stop. Think. Read. This is an external email.
Hello everyone,

Please find attached the Data Quality report from PCORnet based on data 
curation responses for Cycle 6, refresh 3 (July 2019). This will be discussed 
on the Dev call tomorrow and there will be opportunity for questions, etc. so 
please review prior to the call.

Thank you,

Hillary Sandoval
Project Manager, Center for Medical Informatics and Enterprise Analytics
University of Kansas Medical Center
hsando...@kumc.edu<mailto:hsando...@kumc.edu>
913-588-7205

Request Help 
Here<https://urldefense.proofpoint.com/v2/url?u=https-3A__redcap.kumc.edu_surveys_-3Fs-3DqYxMmb=DwMFAg=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=dGkXWw2aHIWlVwdj90rOsXZgTx_ULsXd0uk1QPMSKlI=AWiNtutTiCWOscZ9i4DoNFhnHtPFq1c6KnnvrAcJNjQ=>
www.kumc.edu/ea-mi<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kumc.edu_ea-2Dmi=DwMFAg=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=dGkXWw2aHIWlVwdj90rOsXZgTx_ULsXd0uk1QPMSKlI=-_tiTQ-IqQ-nZeL8H-ZXtLw_gOxOWktquqplutcDJ1Y=>
www.gpcnetwork.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gpcnetwork.org_=DwMFAg=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=dGkXWw2aHIWlVwdj90rOsXZgTx_ULsXd0uk1QPMSKlI=JjJeg4wb_MAS95pWaakHOFZo6BtHoot_2ny8ksQLs7c=>

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

RE: PCORnet Descriptive Query & Supplemental Table [ACTION REQUIRED]

[Susan Rea]

Thank you, Russ, for clarifying the supplemental report request was cancelled 
as of Wednesday, Aug 28.

I confess I am grumpy as getting ready for vacation, and I stayed up late last 
night to prepare to get this done today, before I go.

However, Query Fulfillment (QF) has been steadily communicating with those of 
us responsible to execute queries, about this request “package”.  On Thursday, 
Aug 29, we received an email from QF that began, ”I am reaching out with an 
update regarding the PCORI Descriptives query (pcori_pmp_wp003).  We greatly 
appreciate your feedback regarding query execution and the run times seen at 
your DataMarts.  … “.  It continued to discuss issues with the SAS query they 
sent.  It said NOTHING about cancelling the Supplemental Report, while they 
have communicated a few times about the supplemental report separately, which 
had its own independent due date of Sept 9.  (Not to mention the mystery that 
the supplemental report included data that was available in our CDMs – all but 
the Census Region breakdowns that were based on zipcodes or state – and did not 
explain denominators well enough to compose a query.)

I won’t include Query Fulfillment or DRNOC on this email, since it appears you 
have been talking with them about this specific request.  I am hoping you agree 
and can express to them, in the spirit of constructive criticism, that they 
should communicate status and specifics of the data requests from sites with 
the sites directly as has been the operating protocol.  I suspect someone was 
in a hurry to get the results, but it looks like this is a good lesson to 
follow SOPs for best performance in this large network of data and the people 
that make that happen.

Thanks,
Susan
Susan Rea, Medical Informaticist
Data Administrator, PCORnet Intermountain
Enterprise Analytics
Intermountain Healthcare
801-507-9407 (office) / 801-694-6343 (cell)









From: Gpc-dev  On Behalf Of Russ Waitman
Sent: Tuesday, September 3, 2019 10:15 AM
To: GPC-DEV@LISTSERV.KUMC.EDU
Subject: FW: PCORnet Descriptive Query & Supplemental Table [ACTION REQUIRED]

WARNING: Stop. Think. Read. This is an external email.
Discussed on call today

From: Russ Waitman
Sent: Wednesday, August 28, 2019 12:41 PM
To: Taylor, Bradley (btay...@mcw.edu<mailto:btay...@mcw.edu>) 
mailto:btay...@mcw.edu>>; 
roush.steff...@marshfieldresearch.org<mailto:roush.steff...@marshfieldresearch.org>
Subject: RE: PCORnet Descriptive Query & Supplemental Table [ACTION REQUIRED]

Looks like we have a reprieve!  Thanks everyone for the feedback,

Russ

From: PCORnet Query Fulfillment mailto:q...@pcornet.org>>
Sent: Wednesday, August 28, 2019 12:18 PM
To: PCORnet DRN OC mailto:dr...@pcornet.org>>
Cc: PCORnet 2.0 PIs 
mailto:pcornet2.0...@pcornet.org>>; 2.0 DataMart 
Administrators 
<2.0datamartadministrat...@pcornet.org<mailto:2.0datamartadministrat...@pcornet.org>>;
 Darcy Louzao, Ph.D. mailto:darcy.lou...@duke.edu>>; 
Sturtevant,Jessica 
mailto:jessica_sturtev...@harvardpilgrim.org>>;
 Keith Marsolo mailto:keith.mars...@duke.edu>>; Kshema 
mailto:kshema_nagav...@harvardpilgrim.org>>;
 Forrest, Christopher B 
mailto:forre...@email.chop.edu>>; Maryan Zirkle 
mailto:mzir...@pcori.org>>
Subject: Re: PCORnet Descriptive Query & Supplemental Table [ACTION REQUIRED]

Dear PCORnet Colleagues,

I am reaching out with an update regarding the Supplemental Table Request.  We 
greatly appreciate your feedback and concerns regarding the Supplemental table 
.   Based on this feedback we feel it is no longer necessary for you to 
complete this table.

While no further action is required from your DataMart at this time, we 
appreciate your patience and continued collaboration.

Please do not hesitate to reach out with any questions.

Best,
Kshema Nagavedu - on behalf of the DRNOC QF Team


On Mon, Aug 26, 2019 at 4:53 PM PCORnet DRN OC 
mailto:dr...@pcornet.org>> wrote:
Hello PCORnet Colleagues,

Two follow-up items related to the PCORI Descriptive Query (pcori_pmp_wp003):


  1.  Recently the DRN OC team asked DataMarts to hold on submitting the 
supplemental table, a part of the PCORI Descriptive Query (pcori_pmp_wp003), so 
that we could address questions received from multiple network partners. The 
v03 attached supplemental table for this descriptive query has been revised to 
reflect responses to these questions and clarifications regarding the type of 
output to be returned to the DRN OC.  Please return the completed supplemental 
table to DRN OC (dr...@pcornet.org<mailto:dr...@pcornet.org>) by COB on 
September 9th, 2019.



  1.  As a number of DataMarts have noted that they are encountering very long 
program execution times, we ask that you contact DRN OC Query Fulfillment 
q...@pcornet.org<mailto:q...@pcornet.org> and we would be happy to help with 
troubleshooting and/or providing a modified query package 

RE: gpc-dev 23 Jul agenda and meeting notes: NAACCR_ID in LOINC

[Susan Rea]

It appears we can use the terms in LOINC / Relma without additional 
permissions.  See the attached email correspondence. Also we have the name of a 
content person for NAACCR at LOINC, but no NAACCR person was identified if 
there are new observations in V18.  The LOINC does not care much about the XML 
or whatever model is used to contain the observations.  I can look into the 
“Anwers”, if those exist in LOINC.

Thanks,
Susan

From: Gpc-dev  On Behalf Of Susan Rea
Sent: Monday, July 29, 2019 10:12 AM
To: gpc-dev@listserv.kumc.edu
Subject: RE: gpc-dev 23 Jul agenda and meeting notes: NAACCR_ID in LOINC

WARNING: Stop. Think. Read. This is an external email.
Dan,
I am not sure if this is still needed after the deep dive into NAACCR V18 on 
Jul 16 Dev mtng, but with help from our terminology team, I have extracted the 
LOINC code mappings to NAACCR Item #.  There were 481 LOINC codes in the Class 
‘TUMRRGT’ as described in section 4.4 Tumor registry of 
http://www.labdoc.it/osticket/documenti/LOINCManual.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.labdoc.it_osticket_documenti_LOINCManual.pdf=DwMGaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=y0ZeQWwYL5HPPHFzXzOI1bhdk4dSeihwhwHfkon5Vc8=2kqKTotFhxOJFIZqqtADFgunMonVYTj_aavmbTqY8eo=>
 .   We may need approval from LOINC to use and share this for GPC-DEV team 
work, so let me know and will inquire about any permissions needed.
Thanks, Susan Rea

From: Gpc-dev 
mailto:gpc-dev-boun...@listserv.kumc.edu>> 
On Behalf Of Dan Connolly
Sent: Monday, July 22, 2019 1:07 PM
To: gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>
Subject: gpc-dev 23 Jul agenda and meeting notes
…..


Re External RE gpc-dev 23 Jul agenda and meeting notes NAACCR_ID in LOINC.pdf
Description: Re External RE gpc-dev 23 Jul agenda and meeting notes NAACCR_ID in LOINC.pdf
___
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

RE: gpc-dev 23 Jul agenda and meeting notes: NAACCR_ID in LOINC

[Susan Rea]

Dan,
I am not sure if this is still needed after the deep dive into NAACCR V18 on 
Jul 16 Dev mtng, but with help from our terminology team, I have extracted the 
LOINC code mappings to NAACCR Item #.  There were 481 LOINC codes in the Class 
‘TUMRRGT’ as described in section 4.4 Tumor registry of 
http://www.labdoc.it/osticket/documenti/LOINCManual.pdf .   We may need 
approval from LOINC to use and share this for GPC-DEV team work, so let me know 
and will inquire about any permissions needed.
Thanks, Susan Rea

From: Gpc-dev  On Behalf Of Dan Connolly
Sent: Monday, July 22, 2019 1:07 PM
To: gpc-dev@listserv.kumc.edu
Subject: gpc-dev 23 Jul agenda and meeting notes
…..
___
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

RE: [gpc-informatics] #727: Finder file for Allina, Utah, Intermountain

[Susan Rea]

Song, to whom did you send this at Intermountain?  Just so we can track it  
  Thank you, Susan Rea

-Original Message-
From: GPC Informatics  
Sent: Monday, July 8, 2019 12:59 PM
To: rwait...@kumc.edu; xs...@kumc.edu; dconno...@kumc.edu; 
brian-gryz...@uiowa.edu; schand...@kumc.edu
Cc: mhaf...@kumc.edu; lpa...@kumc.edu; reid.holbr...@hsc.utah.edu; Susan Rea 
; narayana.mazum...@allina.com
Subject: Re: [gpc-informatics] #727: Finder file for Allina, Utah, Intermountain

WARNING: Stop. Think. Read. This is an external email.

#727: Finder file for Allina, Utah, Intermountain
--+---
 Reporter:  rwaitman  |   Owner:  xsong
 Type:  task  |  Status:  assigned
 Priority:  major |   Milestone:  grouse-refresh-2
Component:  data-sharing  |  Resolution:
 Keywords:  GROUSE|  Blocked By:
 Blocking:|
--+---

Comment (by xsong):

 I have sent out delegation logs to Allina and Intermountain to sign (Utah  
already received). Upon receiving the signed delegation log, we will  proceed 
with the IRB review.

--
Ticket URL: 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__informatics.gpcnetwork.org_trac_Project_ticket_727-23comment-3A15=DwICaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=U4-UUcUzI7N6bWU820sgH6zXY_NEuHxTFL8GIBK5n_s=xfYgBAmvguFbdx2zXLTyNiHipZ1tl0sMTOkXo80su78=>
gpc-informatics 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__informatics.gpcnetwork.org_=DwICaQ=II16XUCNF0uj2WHDMBdftpHZzyfqZU4E6o4J8m7Yfh-XF5deecOtjPXuMFvj1uWy=MwmdyHUR1MNPWZBi1oQ_Ksh4XI39nGu45nleZO875iA=U4-UUcUzI7N6bWU820sgH6zXY_NEuHxTFL8GIBK5n_s=lGHQn8pz4FKhLRI_aPvsau7W2MJBfzbwBcgJtIXFF5s=>
Greater Plains Network - Informatics
___
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

Babel Sample Queries

[Susan Rea]

A newbie question:  how do I go to the Babel Sample Queries to see the terms 
used?  I don't have I2B2 or other metadata layers at Intermountain.  I would 
like to see the expansion of query terms to codes as appears I may need to 
write SQL or SAS query to get the data.  The main thing to know are the value 
sets, that I suspect may be here:

   (Example for request #54 in DROC redcap:  IBT Data Feasibility - 
VanWormer - request description)

Location: Workplace / SHARED / VanWormer_IBT; there are two queries: 
Denominator and Numerator.

  *   Terms were selected from the GPC ontology, when possible.
  *   If terms were not present in the GPC ontology, the "KUMC" ontology was 
used.


Please add to the GPC-DEV meeting agenda if there is time, else help via email 
or phone call.  Thank you!

Susan
Susan Rea, Medical Informaticist
Enterprise Analytics
Intermountain Healthcare
801-597-9704 (office) / 801-694-6343 (cell)

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

RE: PCORI_PMP_WP001 report for PCORI final report submission

[Susan Rea]

Here are some scripts for import and export of SAS files. Maybe this can help 
Nebraska pull out a SAS table. Hope so.
Best wishes, Susan Rea


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

Cerner Millennium mappings to I2B2

[Susan Rea]

Is anyone involved or know who might be a contact for anyone at Cerner or a 
working group considering this?

Thank you.

Susan
Susan Rea, Medical Informaticist
Care Transformation
Intermountain Healthcare
801-597-9704 (office) / 801-694-6343 (cell)

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