Yes, KUMC's data shows artifacts from date shifting. It was approved in this 
form.

What was approved for research was our locked CDM from Apr 7; that's what we 
use to service popmednet queries.

We're adding labs and meds and such, but that's in separate storage. I expect 
to learn how this new CDM build gets used for research in the Obesity 
Demonstration Projects: Wave 1 Data Characterization Query Description meeting 
Aug 12 
(ticket:510#comment:5<https://informatics.gpcnetwork.org/trac/Project/ticket/510#comment:5>).


The corresponding section of KUMC's C4UK_DCDREP is:

We would like to understand more about your processes for refreshing your 
DataMart and creating a locked/static version of each DataMart refresh. Can you 
please describe your processes for us? When you refresh your DataMart, do you 
perform a complete update or a partial update (e.g. updating new or changed 
information)?       We start from scratch every month; no incremental updates. 
We have a monthly ETL process to go from Epic etc. into i2b2. On demand, we use 
the SCILHS i2p-transform approach (roughly) to go from i2b2 to CDM. details are 
in ​https://github.com/kumc-bmi/i2p-transform . We have a ​cdm_freeze job that 
makes a compressed offline backup.
Given the time necessary to refresh your data, what is the latest data that 
will be available in the DataMart relative to the date of query receipt? For 
example, if we send you a DC query on July 1, what is the date of the latest 
information you expect to be captured in the DataMart?    Supposing a query 
arrives July 1, the latest data from source systems would be from about May 31. 
That data would be collected from clinical partners, run through our ETL 
process, and released to the HERON customer base in mid June. So far we build 
our CDM datamart on demand, but we could run it every month as part of our ETL 
process, making the latency 2 to 6 weeks. To date, we have only reported 
results from our de-identified (and hence date-shifted) CDM. So the event on 
May 30 would be shifted back up to 365 days. We have the technical capacity to 
build a CDM with real dates, but we have not used it to send results as 
regulatory aspects are unclear.


For reference/redundancy:


9dec55490dc2e063a7ef17bd0ac8eaf5  
/home/jenkins/oracle_export//cdmv3_CONDITION_20160407_160654.dmp
7283c370b7cd5f407c2c5bfd2e2f2032  
/home/jenkins/oracle_export//cdmv3_DEATH_20160407_160654.dmp
6bc82d1670b5a2be4dbedcea6b8d6299  
/home/jenkins/oracle_export//cdmv3_DEATH_CAUSE_20160407_160654.dmp
7a3bbd3e44eff86b32ef41183c4635ab  
/home/jenkins/oracle_export//cdmv3_DEMOGRAPHIC_20160407_160654.dmp
1a9bd5ec9a1a58dfe2eb6395051f5e50  
/home/jenkins/oracle_export//cdmv3_DIAGNOSIS_20160407_160654.dmp
f374dcb1d1f089330a12f3ec49f71513  
/home/jenkins/oracle_export//cdmv3_DISPENSING_20160407_160654.dmp
b773582aad45a3370e39959d2ab5b14f  
/home/jenkins/oracle_export//cdmv3_ENCOUNTER_20160407_160654.dmp
08256fac496087b9802f9d6a928a027b  
/home/jenkins/oracle_export//cdmv3_ENROLLMENT_20160407_160654.dmp
aa33dbd9662d250065da75ce1a98d212  
/home/jenkins/oracle_export//cdmv3_HARVEST_20160407_160654.dmp
f97a4592704f53aaf0ae36d296ec9fbd  
/home/jenkins/oracle_export//cdmv3_LAB_RESULT_CM_20160407_160654.dmp
bc9347f39d70239b0e76c44bad706642  
/home/jenkins/oracle_export//cdmv3_PCORNET_TRIAL_20160407_160654.dmp
a633952123b4faff7d3e53252ced4785  
/home/jenkins/oracle_export//cdmv3_PRESCRIBING_20160407_160654.dmp
835d62f656e669ee8eec1d0f8fd8c363  
/home/jenkins/oracle_export//cdmv3_PROCEDURES_20160407_160654.dmp
20452f2ead3af1f4124b1589fe86a4aa  
/home/jenkins/oracle_export//cdmv3_PRO_CM_20160407_160654.dmp
95f5df676e2ba29b58cd394b54956f61  
/home/jenkins/oracle_export//cdmv3_VITAL_20160407_160654.dmp



--
Dan

________________________________
From: Phillip Reeder [[email protected]]
Sent: Monday, August 01, 2016 1:46 PM
To: Dan Connolly; <[email protected]>
Subject: Re: gpc-dev 2 Aug agenda and meeting notes

We received feedback/questions from PCORI.  I have some questions for everyone 
regarding how refreshes/archiving should be done for it.

Here are the questions from PCORI:
1)We would like to understand more about your processes for refreshing your 
DataMart and creating a locked/static version of each DataMart refresh. Can you 
please describe your processes for us?  When you refresh your DataMart, do you 
perform a complete update or a partial update (e.g. updating new or changed 
information)?
2)Given the time necessary to refresh your data, what is the latest data that 
will be available in the DataMart relative to the date of query receipt? For 
example, if we send you a DC query on July 1, what is the date of the latest 
information you expect to be captured in the DataMart?

For UTSW,  I currently have the data in Oracle and we can do a complete update 
every month when we update our i2b2.  But, when we do so, it will wipe out and 
re-load all of the data.  What are others doing to create a “locked/static” 
version?  We’re also still creating our CDM from the de-identified, date 
shifted version of i2b2.  Are other GPC sites doing the same?  Or have you 
eliminated date shifting on the CDM?  I could fairly easily use our pre-shifted 
version of i2b2 but want to be consistent with other sites with regards to the 
process.  I’m also wondering if the date shifting may be causing our vitals 
data to look like it’s spiking around 1 year ago. I haven’t created a non-date 
shifted version to compare to through.

Thanks,
Phillip



From: 
<[email protected]<redir.aspx?REF=tZCoKgWqVilUbQ5noDP8WO4xzAKsNHEZlp6JWJssJJNtzn1NPLrTCAFtYWlsdG86Z3BjLWRldi1ib3VuY2VzQGxpc3RzZXJ2Lmt1bWMuZWR1>>
 on behalf of Dan Connolly 
<[email protected]<redir.aspx?REF=gjzjv8PystS7y70uVkkDpxY_AwQ7l5cIhzDNDWcLV-9tzn1NPLrTCAFtYWlsdG86ZGNvbm5vbGx5QGt1bWMuZWR1>>
Date: Monday, August 1, 2016 at 1:32 PM
To: 
"<[email protected]<redir.aspx?REF=0YnNj8O0cDaD9rrjiFK-T9g3JWT66M8BsfsN_MmUFKhtzn1NPLrTCAFtYWlsdG86Z3BjLWRldkBsaXN0c2Vydi5rdW1jLmVkdQ..>>"
 
<[email protected]<redir.aspx?REF=0YnNj8O0cDaD9rrjiFK-T9g3JWT66M8BsfsN_MmUFKhtzn1NPLrTCAFtYWlsdG86Z3BjLWRldkBsaXN0c2Vydi5rdW1jLmVkdQ..>>
Subject: gpc-dev 2 Aug agenda and meeting notes

What else for tomorrow?

  *   gpc-dev 2 Aug shared 
notes<redir.aspx?REF=OX4hYyehSAhNotMER9tOAXUmR3bDInaK3cT3ogRoscltzn1NPLrTCAFodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9kLzFkSElRTVZSV1I4eTZCcFhvWDNCUEQ4ZkdYTDAxaHc5bnJqVlNyYjc2RExBL2VkaXQ.>;
 scribe: MU

________________________________


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

     *   ​Meeting ID and access code: 
817-393-381<redir.aspx?REF=wysTjPuiqo-n103TKPl6I-7b1dTnvxj18S8eQXxYTe1tzn1NPLrTCAFodHRwczovL2dsb2JhbC5nb3RvbWVldGluZy5jb20vbWVldGluZy9qb2luLzgxNzM5MzM4MQ..>;
 call +1 (571) 317-3131

     *   roll: all 
12DevTeams<redir.aspx?REF=W3H0AWlJNwQXJQDoubc2T6kTC9rI-j8s5bOLJR5srFVtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC93aWtpL0RldlRlYW1z>
 represented? KUMC, CMH, UIOWA, WISC, MCW, MCRF, UMN, UNMC, UTHSCSA, UTSW, MU, 
IU
Reminder - put institution after your name in GoToMeeting preferences

        *   today's scribe: MU

     *   comments on the agenda? on last week’s notes 
(#12<redir.aspx?REF=RBaa-839AkQq54kR7-RxYqvGkPcP1fbwRjP4QxLgSY9tzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvMTI.>)?
Recent tickets 
opened/closed<redir.aspx?REF=widhbfV1rwBCKcdKK2ujtqlbQnTElIep0ZrbVgwiyKdtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aW1lbGluZQ..>
 - FYI

        *   ...

        *   #520 (DataBuilder limited to one terms / concepts table) 
created<redir.aspx?REF=ImF_6wff0eWyJyh46oQQFdYpQOZ2tBpLQZG6LKEYqNJtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNTIw>
 minor

        *   #409 (submit year 1 sustainability plan (milestone 2.7.1)) 
closed<redir.aspx?REF=rkwj-S7JOt3Fhj31VTgZB7xiqkBXKrS9_C1awQyphtFtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNDA5I2NvbW1lbnQ6Ng..>

     *   Next Meeting: 9 Aug - scribe?
Note LRU 
schedule<redir.aspx?REF=udlwrHKHfJD9CpBRjjzc-u1xhDFJGfa6CzCyDjyBiXZtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvMTIjY29tbWVudDo5Mg..>,
 which nominates MCW, MCRF, …

  2.  Feasibility Query: National Diabetes Amputation Prevention    Study    
(NDAMPS)<redir.aspx?REF=m8vh6rky8kbAeCCJtPc1lVaRr2CBXavD78K58ltyQ7dtzn1NPLrTCAFodHRwOi8vbGlzdHNlcnYua3VtYy5lZHUvcGlwZXJtYWlsL2dwYy1kZXYvMjAxNnEzLzAwMzA2NS5odG1s>
  Mei Liu: “Some learning points from the experience: …”

  3.  Milestone:tapir-trial-1
<redir.aspx?REF=ttpiy-8DgnpJL3kEQctGy-oK98zOKjLlQ3HdQ34vKQFtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC9taWxlc3RvbmUvdGFwaXItdHJpYWwtMQ..>#521<redir.aspx?REF=RfNc50045Mf0tDySj73hHbZOJtoIAUpYpZJho8mXH0Ftzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNTIx>identify
 providers in TAPIR 
trial<redir.aspx?REF=RfNc50045Mf0tDySj73hHbZOJtoIAUpYpZJho8mXH0Ftzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNTIx>:
  “KUMC is going first; MCW and UTSW to follow.”

  4.  Next-d geocoding
#508<redir.aspx?REF=-vKsGap-dUyMzx6s54ZkWP-4Uc1dnWCGcbL1Yw_veXRtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNTA4>Handling
 small geographic areas in geocoded data for 
Next-D<redir.aspx?REF=-vKsGap-dUyMzx6s54ZkWP-4Uc1dnWCGcbL1Yw_veXRtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNTA4>
 closed fixed:
“... using a non-derived/randomly generated id for the Geo-ID to link up the 
tables would satisfy safe harbor ...”

  5.  
#402<redir.aspx?REF=1QOMNIgylRB_xks3RstWWT8lhAGXAJ1cuon0lhys-RZtzn1NPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNDAy>
 enhanced data resource from GPC Cohort Characterization study with CMS data: 
“the [RESDac] project was approved”

     *   
CompleteData<redir.aspx?REF=aKEviSvlMZedPtQ8nauwz6wEL7FujiD_8_BAwjjLbTfOL4BNPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC93aWtpL0NvbXBsZXRlRGF0YQ..>
 -> GROUSE

  6.  
#459<redir.aspx?REF=_h9VTjk2k7pNQXBjisd2iIJn06tE5E4u926LSwA5chXOL4BNPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNDU5>How
 to add GPC sites to SNOW SHRINE network?
<redir.aspx?REF=_h9VTjk2k7pNQXBjisd2iIJn06tE5E4u926LSwA5chXOL4BNPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvNDU5>“In
 discussion of the health systems payor demonstration project, Russ learned 
that SCILHS is willing to host a SHRINE network for PCORNet.”

  7.  
Milestone:bc-dx-px<redir.aspx?REF=HSr_2W70a7QFsD3T9yqxgyc0tkuYL73HHtEIJIJgbIzOL4BNPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC9taWxlc3RvbmUvYmMtZHgtcHg.>
 - #448 done! Yay!
How many hours of effort did it take? I have estimates from MCW, UMN.
I'd appreciate estimates from UIOWA, MCRF, WISC, UNMC, UTSW.

  8.  Milestone:cohort-char-bc-db
<redir.aspx?REF=C-3aDF5_gT8DCDdUioKnIygWPncT6n7vfzqqQ7w-WRLOL4BNPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC9taWxlc3RvbmUvY29ob3J0LWNoYXItYmMtZGI.>#358<redir.aspx?REF=VBIdH9LLrS0i4hadlh6S-NXifw98krqlCCp8zoRI46_OL4BNPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvMzU4>NAACCR
 ETL: update all [8 participating] sites to include summary of treatment 
etc.<redir.aspx?REF=VBIdH9LLrS0i4hadlh6S-NXifw98krqlCCp8zoRI46_OL4BNPLrTCAFodHRwczovL2luZm9ybWF0aWNzLmdwY25ldHdvcmsub3JnL3RyYWMvUHJvamVjdC90aWNrZXQvMzU4>

     *   Participating sites

        *   KUMC - ETL done locally; need to update babel

        *   UIOWA

        *   WISC

        *   MCW

        *   MCRF

        *   UMN

        *   UNMC

        *   UTSW - full marks!

     *   Other sites

        *   CMH

        *   IU

        *   MU

        *   UTHSCSA

________________________________

--
Dan


________________________________

UT Southwestern


Medical Center



The future of medicine, today.

_______________________________________________
Gpc-dev mailing list
[email protected]
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

Reply via email to