Tom, thanks. We've not yet started doing anything related to making it neutral
with regards to location of patient attributes. It's a tall order...I've taken
a look at the way the i2b2 service layer builds it's queries. It's fairly
complex object oriented code that will be hard to adapt to straight SQL I think.
I think we will approach the first round with some hard coded queries against
patient_dimension.
Dan:
This statement returns no results:
select v.VARIABLE_NAME ,count(distinct o.PATIENT_NUM) as RESULT
into #Q4_2015_GPC_QA_ACTIVE_TMP
FROM I2B2Data.Q4_2015_GPC_QA_VAL_LIST v
JOIN I2B2Data.CONCEPT_DIMENSION c on (c.CONCEPT_PATH like
v.CONCEPT_PATH_OR_CODE or c.CONCEPT_CD like v.CONCEPT_PATH_OR_CODE)
JOIN I2B2Data.OBSERVATION_FACT o on o.concept_cd = c.concept_cd
JOIN #Q4_2015_GPC_QA_ACTIVE_PATIENT p on p.patient_num = o.patient_num
where v.POPULATION = 'Active'
and v.QUERY_TYPE = 'COUNT PATIENT'
group by v.variable_name;
We of course do have patients in our database, but this query assumes the
information of interest is in observation_fact when it is in fact in
patient_dimension in our database.
Regarding the ontology mapping, what I got from the instructions was to map our
concept paths into the Q4_2015_GPC_QA_VAL_LIST file so it would return results.
Am I to understand that we should not be mapping our ontology paths to the
Q4_2015_GPC_QA_VAL_LIST, but instead alter our metadata in i2b2 to match that
which is in the base Q4_2015_GPC_QA_VAL_LIST file?
From: Thomas Mish [mailto:[email protected]]
Sent: Monday, February 15, 2016 12:17 PM
To: Dan Connolly; Green, Timothy A.; Mosa, Abu S.
Cc: McNeeley, Todd A.; <[email protected]>
Subject: RE: Gather 2015 4th quarterly QA results
I think that very early on in the GPC conversations we covered a lot of ground
in the fact vs patient dimension conversation. I know that here at Madison we
altered the way we organized our i2b2 data at the time to that we were more
like the rest of the GPC. I understand the angst over changing. I'd love to see
what you doing/have done to make the script more neutral on this issues. We'll
incorporate them as best as possible for next time to minimize the churn.
-TM
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Dan Connolly
Sent: Monday, February 15, 2016 11:50 AM
To: Green, Timothy A.
<[email protected]<mailto:[email protected]>>; Mosa, Abu
S. <[email protected]<mailto:[email protected]>>
Cc: McNeeley, Todd A.
<[email protected]<mailto:[email protected]>>;
<[email protected]<mailto:[email protected]>>
<[email protected]<mailto:[email protected]>>
Subject: RE: Gather 2015 4th quarterly QA results
To the extent that I did any of the writing of the QA scripts, I made no
assumption about fact table vs. patient dimension. All our ontology design
decisions regard paths. I haven't looked at all the code in detail, though. If
there is such an assumption, it should be straightforward to refer us to one or
more lines or statements that exhibit the assumption. Would you please give
such details? Or just run the script and give us one or more diagnostic
messages that show the assumption in action?
And as to "the relatively simple task of mapping..." that's the point of the QA
scripts: to measure progress on that mapping. If you run the scripts and get
some zeros, the script is still working correctly. It correctly shows that
you're not finished. (You're not alone. KUMC has plenty of work to do in this
area, for example.)
--
Dan
________________________________
From: Green, Timothy A. [[email protected]]
Sent: Monday, February 15, 2016 10:38 AM
To: Mosa, Abu S.; Dan Connolly
Cc: <[email protected]<mailto:[email protected]>>; McNeeley,
Todd A.
Subject: RE: Gather 2015 4th quarterly QA results
The patient demographics are stored in our i2b2 in the person dimension. The
QA scripts are written with the assumption that all data is stored in the fact
table. There is no provision for the script to leverage the ontology
architecture to determine the storage location of the various pieces of data.
I'm sure it was done that way to simplify the script, but it does ignore a
pretty major feature of i2b2: the ontology mapping functionality. This makes
it less portable to sites that have a different implementation of the ontology.
I don't characterize a difference in implementation a problem in the data
warehouse.
Keep in mind that MU had an i2b2 instance back in 2014, and the MU architecture
was established before joining the GPC. It would be work to either shift our
demographics storage (and additional storage capacity), or to rewrite the QA
scripts. We will opt to rewrite the QA scripts, but to do it in a portable way
(i.e. we could share our changes back to the GPC) will require some complexity
of coding to leverage the ontology framework in i2b2. We may have to opt for
hardcoding our version against the dimension table.
Aside from that, we still have the relatively simple task of mapping our
concept codes/paths to get the remainder (non-demographic part) of the script
to work correctly.
Tim
From: Mosa, Abu S.
Sent: Monday, February 15, 2016 10:20 AM
To: Dan Connolly
Cc: <[email protected]<mailto:[email protected]>>; Green,
Timothy A.; McNeeley, Todd A.
Subject: RE: Gather 2015 4th quarterly QA results
I would defer this to Tim and Todd to share their thoughts on this. Thanks.
--Mosa
From: Dan Connolly [mailto:[email protected]]
Sent: Monday, February 15, 2016 10:03 AM
To: Mosa, Abu S. <[email protected]<mailto:[email protected]>>
Cc: <[email protected]<mailto:[email protected]>>
<[email protected]<mailto:[email protected]>>
Subject: RE: Gather 2015 4th quarterly QA results
What are the symptoms when you try to run the QA scripts, Mosa? What
diagnostics do you get?
The premise of the QA scripts is that if they don't run, that's a problem with
your data warehouse. Perhaps there are actually problems with the scripts, but
if so, we need details on what those problems are. Also, we have a shared
source code repository in
gpc-qa-quarterly<https://bitbucket.org/gpcnetwork/gpc-qa-quarterly>. So if you
make changes, please strive to make them portable to other sites.
p.s. I presume it's OK to share this thread with gpc-dev, as it regards group
technical work.
--
Dan
________________________________
From: Mosa, Abu S. [[email protected]]
Sent: Friday, February 12, 2016 4:41 PM
To: Dan Connolly
Subject: Gather 2015 4th quarterly QA results
Hi Dan,
I talked with our technical team about generating the 2015 4th quarterly
report. They looked into the MSSQL code that you referred to me on BitBucket.
They advised that major re-writing effort is needed in order to localize the
scripts to be able to run on our i2b2 data model. They are currently focusing
on the Phase I implementation (specifically tumor registry data load) which
they target to complete by end of this month. So, a viable timeline for
generating the 2015 4th quarterly report for us would be Mid-march. Let me know
if you have any questions. If needed, we can discuss this during the next Dev
call.
Regards,
Abu Saleh Mohammad Mosa, PhD
Director, Research Informatics
Institute for Clinical and Translational Science
University of Missouri
_______________________________________________
Gpc-dev mailing list
[email protected]
http://listserv.kumc.edu/mailman/listinfo/gpc-dev
