The fabricated visit won't distinguish among multiple tumors found in one 
patient. If that case doesn't occur in your data set, very well. But otherwise, 
that's a significant problem.

The HERON ETL code uses a combination of (per-patient) accession number and 
sequence number to identify a tumor registry encounter:
 
341     create or replace view tumor_reg_visits as
342     select ne."Accession Number--Hosp" || '-' || ne."Sequence 
Number--Hospital"
343            as encounter_ide
344          , ne."Patient ID Number" as MRN
345     from naacr.extract ne
346     where ne."Accession Number--Hosp" is not null;

ref https://informatics.kumc.edu/work/browser/heron_load/naaccr_txform.sql#L341

p.s. Note Tamara, Betsy, myself, and others discussed this specific case of 
handling multiple tumors per patient Aug 29.
https://informatics.gpcnetwork.org/trac/Project/ticket/32#comment:27

p.p.s. I presume it's OK to bring this technical discussion back to the mailing 
lists (and, consequently, share it  publicly). It's important that we all learn 
together.

-- 
Dan

________________________________________
From: Tamara McMahon
Sent: Wednesday, January 07, 2015 4:39 PM
To: 'Bushee, Glenn'
Cc: Dan Connolly
Subject: RE: More info for the GPC BC Search

Glenn,

They want data for every element in the search when available.  The financial 
encounter is based on the encounter number attached to the tumor registry 
observance.  I believe this is the tumor number (copying Dan to verify).

Data update through 10/28/2014 is great.  It covers the desired BC date range.

-----Original Message-----
From: Bushee, Glenn [mailto:[email protected]]
Sent: Tuesday, January 06, 2015 2:46 PM
To: Tamara McMahon
Subject: Re: More info for the GPC BC Search

Tamara, the financial encounter constraint is a difficult one on our end.  
We've pulled data from 3 different NAACCR databases and used the fabricated 
visit (EPIC Zid preceded by 'fabricated_') for all of the entries.  So, this 
would mean that our query is currently taking any SEER Site: Breast, excluding 
any match to the Class of Case >= 30.  Note that this exclusion reduces our 
data set size by about a 150 patient count.

For the extracted data, is it that you just want the information associated 
with the SEER Site: Breast entry?

So, the next question is then, how are you determining a Financial Encounter 
from the underlying NAACCR data?

I hope that this all makes sense.

We received a one-time data dump that was through approximately 10/28/2014.  We 
are going to be working through a process to obtain incremental changes on 
either a monthly or quarterly basis, but this has not been finalized yet.

- Glenn

   Medical Informatics Senior Analyst
   CTSI – Clinical & Translational Science Institute
   [email protected]
   (414) 805-7239


From: Tamara McMahon <[email protected]<mailto:[email protected]>>
Date: Tuesday, January 6, 2015 at 2:16 PM
To: 
"'[email protected]<mailto:'[email protected]>'"
 
<[email protected]<mailto:[email protected]>>
Cc: "Chrischilles, Elizabeth A 
([email protected]<mailto:[email protected]>)" 
<[email protected]<mailto:[email protected]>>, "McDowell, Bradley 
D ([email protected]<mailto:[email protected]>)" 
<[email protected]<mailto:[email protected]>>, Theresa 
Shireman <[email protected]<mailto:[email protected]>>, Jianghua He 
<[email protected]<mailto:[email protected]>>
Subject: More info for the GPC BC Search

I would like to clarify a few items in the previous email regarding GPC Breast 
Cancer search. I’ve attached an updated screenshot highlighting items listed 
below.

1.       The first 3 groups should be limited to the same financial encounter.  
When I printed the query, the printout indicated treat independently which is 
incorrect.  Please refer to the correct query (attached).

2.       Group 2 excludes non-analytic class of case.  Analytic class of case 
is less than 30, so please exclude any class of case greater or equal to 30 to 
remove the non-analytics.  The query print I am attaching shows the 
non-analytic class of case codes available at KUMC.  You may see different 
numbers at your institution.  For example, KUMC is missing #35, #37 and #39.  
Your institutions may include these but miss some of those listed in the KUMC 
search. The important thing is to exclude any class of case coded greater than 
or equal to 30.

3.       I’ve added 0610 Class of Case to group 3, so the team can verify 
non-analytics were removed.

4.       I pulled the EMR data types into the 4th group since they cannot be 
linked via financial encounter at KUMC.

Please email me and let me know the date of your last data refresh and what 
kind of lag exists for your tumor registry.  Due to the close date range 
(identified 5/1/2013-5/1/2014) the BC team would like to verify the 
availability of this data.  At KUMC we refresh monthly with a lag of 6 months 
at the registrar, so our tumor registry is only available through 6/30/2014.

Reminder: please include a de-identified patient number in your data set.

Dan is working on ticket 
#205<https://informatics.gpcnetwork.org/trac/Project/ticket/205>: an interim 
data builder for this search.  I will send an update on how to pull/package the 
data from the search once I get an update from him.

Tamara McMahon
Clinical Informatics Coordinator
Division of Medical Informatics
University of Kansas Medical Center
913-945-7470
Request a training or consultation<https://redcap.kumc.edu/surveys/?s=qYxMmb>

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

Reply via email to