RE: GPC 2nd quarter QA design looks nice!

2015-07-23 Thread Munns, Michael B
Let us know how it goes, I have had to rewrite a couple of queries, one that 
took 17 min to update 3 rows, one due to our differences. I am now having 
another that will not return.

Has anyone else had issues on an Oracle DB?

Michael Munns
Database Analyst
402-559-3821

From: gpc-dev-boun...@listserv.kumc.edu 
[mailto:gpc-dev-boun...@listserv.kumc.edu] On Behalf Of Nathan Graham
Sent: Thursday, July 23, 2015 10:47 AM
To: GPC-DEV@LISTSERV.KUMC.EDU; Thomas Mish; James Van Schyndle 
(jvanschyn...@wisc.edu)
Subject: GPC 2nd quarter QA design looks nice!

Tom/James,

I've just started working on running the GPC Q2 quality queries here at KUMC 
and wanted to say that the design looks pretty slick!  I really like having the 
concept paths, codes, etc. split out into their own xlsx/csv file that loads 
nicely into REDCap to begin with.  I think that'll make it a lot easier to port 
to various sites.

Now, on to actually gathering results...

Refs:

* WISC BitBucket: 
gpc-2015-q2-qa-fileshttps://bitbucket.org/jvanschyndle/gpc-2015-q2-qa-files

* My fork on BitBucket: 
gpc-2015-q2-qa-fileshttps://bitbucket.org/njgraham/gpc-2015-q2-qa-files

Regards,

Nathan

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.
___
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev


RE: GPC-Dev Agenda 4-21

2015-04-21 Thread Munns, Michael B
UNMC 6.4.4

Michael Munns
Database Analyst
402-559-3821

From: gpc-dev-boun...@listserv.kumc.edu 
[mailto:gpc-dev-boun...@listserv.kumc.edu] On Behalf Of Bos, Angela
Sent: Monday, April 20, 2015 5:44 PM
To: Dan Connolly; Apathy, Nate; gpc-dev@listserv.kumc.edu
Subject: RE: GPC-Dev Agenda 4-21

Sorry for the late request, but could we add the following topic for the 
obesity survey:

What version of Redcap are you running? How soon could your site potentially 
achieve 6.1.x?

We would like to use Redcap “access code” functionality introduced in 6.1.0. 
Used in conjunction with participant lists, it allows a user to enter a general 
survey URL, then requires them to enter a non-case-sensitive 9-character access 
code to go to their unique survey link.

-Angela | UTHSCSA


From: 
gpc-dev-boun...@listserv.kumc.edumailto:gpc-dev-boun...@listserv.kumc.edu 
[mailto:gpc-dev-boun...@listserv.kumc.edu] On Behalf Of Dan Connolly
Sent: Monday, April 20, 2015 3:30 PM
To: Apathy,Nate; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu
Subject: RE: GPC-Dev Agenda 4-21

Thanks for getting the ball rolling, Nate. I went over our business and made 
some adjustments.

Note in particular that I dropped items where I couldn't find an update shared 
with the group.  Reminder: if anyone wants something on the agenda, please send 
mail or update a ticket before 10am Monday. You can, of course, ask to have 
something added when we review the agenda at the beginning of the call, but 
things work better if materials are available in advance.


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

a.​Meeting ID and access code: 
817-393-381https://global.gotomeeting.com/meeting/join/817393381; call +1 
(571) 317-3131

b.roll: all 10 
DevTeamshttps://informatics.gpcnetwork.org/trac/Project/wiki/DevTeams 
represented?

  i.KUMC, CMH, UIOWA, WISC, MCW, 
MCRF, UMN, UNMC, UTHSCSA, UTSW, (MU), (IU)

ii.Reminder - put institution after 
your name on the GoToMeeting (preferences)

c.meeting notes 
(#12https://informatics.gpcnetwork.org/trac/Project/ticket/12): previous 
notes OK? today's scribe: Nate A (Cerner/CMH) comments on the agenda? chair 
dropped items where no update was available as of ~T-24hrs

  i.recent tickets opened/closed 
FYI:

1.#165:https://informatics.gpcnetwork.org/trac/Project/ticket/165 
PopMedNet @ UTSW - closed

2.#270http://informatics.gpcnetwork.org/trac/Project/ticket/270 - Port Q1 
QA query to Oracle opened

3.note also recent ticket comments 
reporthttps://informatics.gpcnetwork.org/trac/Project/report/13

d.Next Meeting April 28th: scribe?

2.#78 Shared GPC RxNORM/NDFRT medications 
ontologyhttps://informatics.gpcnetwork.org/trac/Project/ticket/78 re-opened; 
also #236https://informatics.gpcnetwork.org/trac/Project/ticket/236

a.Nate sent list of non-SCDF 
codeshttp://listserv.kumc.edu/pipermail/gpc-dev/2015q2/001525.html to group

1.#158 Usable LOINC Labs - March 27 
commenthttps://informatics.gpcnetwork.org/trac/Project/ticket/158#comment:28 
proposes that  Jan 19 
detailshttps://informatics.gpcnetwork.org/trac/Project/ticket/158#comment:20 
suffice

a.KUMC’s experience is positive so far, though we haven’t released

b.is what’s on babel consistent with Jan 19 details?

1.
milestone:data-quality3https://informatics.gpcnetwork.org/trac/Project/milestone/data-quality3

a.#270 (Port Q1 QA query to Oracle) 
closedhttps://informatics.gpcnetwork.org/trac/Project/ticket/270#comment:2

1.milestone:bc-survey-cohort-def 
(depgraphhttps://informatics.gpcnetwork.org/trac/Project/depgraph/ticket/227):

a.#271https://informatics.gpcnetwork.org/trac/Project/ticket/271 IRB-wait

b.#264https://informatics.gpcnetwork.org/trac/Project/ticket/264 confirm 
governance and workflow: ~7 sites responded

1.Milestone: 
obesity-survey-defhttps://informatics.gpcnetwork.org/trac/Project/milestone/obesity-survey-def

a.#252 test results from 
wischttps://informatics.gpcnetwork.org/trac/Project/ticket/252#comment:5

1.
milestone:cohort-char1https://informatics.gpcnetwork.org/trac/Project/milestone/cohort-char1

a.#258https://informatics.gpcnetwork.org/trac/Project/ticket/258 
volunteer to take a whack at breast cancer treatment from NAACCR?

1.#242https://informatics.gpcnetwork.org/trac/Project/ticket/242 - Nate 
A. asks Apr 16 “where can we find the necessary attachments and code to attempt 
this? ...”

  1.  milestone:data-domains3 currently has no due date; is that OK? are there 
any customers waiting?


--
Dan

From: 
gpc-dev-boun...@listserv.kumc.edumailto:gpc-dev-boun...@listserv.kumc.edu 
[gpc-dev-boun...@listserv.kumc.edu] on behalf of Apathy,Nate 
[nate.apa...@cerner.com]
Sent: Monday, April 20, 2015 9:50 AM
To: 

RE: [gpc-informatics] #232: Q1 2015 QA exercise

2015-04-02 Thread Munns, Michael B
In the create script for the obesity active patients 
(Q1_2015_GPC_OBESITY_ACTIVE_PATIENTS) the where condition for the BMI part it 
has ” concept_path = '\GPC\Vital Signs\LOINC:39156-5\' “

We do not have the GPC metadata installed. We do have BMI under PCORI that does 
have facts.

Can that be used instead?

Should we download and install GPC metadata?

Michael Munns
Database Analyst
402-559-3821

From: gpc-dev-boun...@listserv.kumc.edu 
[mailto:gpc-dev-boun...@listserv.kumc.edu] On Behalf Of Tom Mish
Sent: Thursday, April 02, 2015 8:15 AM
To: gpc-dev@listserv.kumc.edu; dconno...@kumc.edu
Cc: badaga...@kumc.edu; jsteinm...@kumc.edu
Subject: Re: [gpc-informatics] #232: Q1 2015 QA exercise

A new version of the query was updated.

  *   Jim moved the comments/version history section to a separate document
  *   The changes in this are to the output (variable names and ordering)  
produced to make it easier to import into redcap.

-TM

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.
___
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev


RE: RxNorm metadata

2015-01-16 Thread Munns, Michael B
I am getting closer, the KU and the UTSW metadata on Bable both have modifiers, 
the GPC does not. I what do I need to do to end up with KUMC style modifiers?

Michael Munns
Database Analyst
402-559-3821

From: Nathan Graham [mailto:ngra...@kumc.edu]
Sent: Monday, December 08, 2014 10:45 AM
To: Munns, Michael B; gpc-dev@listserv.kumc.edu
Subject: RE: RxNorm metadata

We used the exclude modifiers table to remove the modifiers from things that 
didn't really need them like NO HOME MEDICATIONS, EMPTY CONTAINER, PLASTIC 
BAG, MISCELLANEOUS MEDICAL SUPPLY MISC, etc.  These are things we put 
directly under the top level Medications folder as we didn't know where else 
to put them.  Maybe it could be argued that some of these don't have much 
research value - I don't know.  But, many of these concepts had lots of 
patient/fact counts so we didn't want to just exclude them.  At least the NO 
HOME MEDICATIONS item was specifically discussed and deemed worth 
addinghttps://informatics.kumc.edu/work/ticket/1775.

Our (KUMC) general approach is bring in everything - that way, we can all can 
see what we have available.  If/when we find that things can be improved (based 
on user feedback, etc) we can do that later.

From: 
gpc-dev-boun...@listserv.kumc.edumailto:gpc-dev-boun...@listserv.kumc.edu 
[mailto:gpc-dev-boun...@listserv.kumc.edu] On Behalf Of Munns, Michael B
Sent: Monday, December 08, 2014 10:30 AM
To: gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu
Subject: FW: RxNorm metadata

We can put them on the mailing list.
We did end up creating an empty table for the manual curation, also a empty 
table for the exclude modifiers.

Michael Munns
Database Analyst
402-559-3821

From: Nathan Graham [mailto:ngra...@kumc.edu]
Sent: Monday, December 08, 2014 10:18 AM
To: Munns, Michael B
Subject: RE: RxNorm metadata

Michael,

I'd really like to keep these conversations on the 
gpc-devhttp://listserv.kumc.edu/pipermail/gpc-dev/ mailing list (sign up from 
 herehttp://listserv.kumc.edu/mailman/listinfo/gpc-dev).  If you have 
questions I think others will too.  And, I think we all benefit from as much 
collaboration as we can have.  Could we move future questions there?

I think what you want is an empty table right now.  The manual curation table 
is what it says - a place for you to manually specify parents for medications 
that we didn't link from Epic to RxNorm.  The documentation could probably be 
better - from the comment at the top of the file:

Notes about manual curation:
med_map_manual_curation is a table that maps a clarity medication ID to a parent
concept.  It is designed to be used for medications that we couldn't map to 
RxNORM
directly from information in Clarity (via GCN, NDC, etc). This parent could be a
VA class or an SCDF/SBDF.

The table has the following columns:
CLARITY_MEDICATION_ID - the id of the med without direct linkage to RxNORM
CLARITY_NAME (not used for mapping - just for eyeballing)
FACTS (not used for mapping - just for eyeballing)
PATIENTS (not used for mapping - just for eyeballing)
VA_NAME (not used for mapping - just for eyeballing)
VA_RXAUI - If we didn't map to an SDF AUI (below), the fall back on this one 
for VA class.
SDF_RXAUI - Map here if not null, otherwise fall back on the VA_RXAUI (above)
SDF_NAME (not used for mapping - just for eyeballing)

I know I've probably made KU-specific assumptions in the code that make porting 
difficult.  So, if you have improvements, suggestions, etc I'd be very happy to 
look at patches.  Or, if you start using the Elephant repository (see 
MultiSiteDevhttps://informatics.gpcnetwork.org/trac/Project/wiki/MultiSiteDev)
 you could commit directly to a branch and we could work together to merge your 
changes into default as appropriate.

Thanks.

Regards,

Nathan


From: Munns, Michael B [mailto:mike.mu...@unmc.edu]
Sent: Thursday, December 04, 2014 4:18 PM
To: Nathan Graham
Subject: RE: RxNorm metadata
Importance: High

I have more questions about this rxnorm_terms table.

On line 274 there is a create the I am running as an insert, that contains a 
union for the manual curation. If I am following all of this correct, and I am 
not sure that I am,  some of this may be that it's the first time we've ran and 
the rxnorm_terms is empty.

To start though there is a view mapped_meds , that uses rxnorm_terms. Then the 
view unmapped_meds is built off of mapped_meds. The unmapped_meds view is used 
in a query to create the med_map_manual_curation.csv which is used to
Populate the med_map_manual_curation table.

The union in the create @274 calls the med_map_manual_curation table , which 
does not exist. The join is where its med id is not null. So I could remove 
that section of the code or put an empty table out there.

Any downside to an empty table or skipping that union you are aware of? Am I 
missing something?



Michael Munns
Database Analyst
402-559-3821

From: Munns, Michael B
Sent: Thursday, December 04, 2014 1:41 PM
To: 'Nathan

FW: RxNorm metadata

2014-12-08 Thread Munns, Michael B
We can put them on the mailing list.
We did end up creating an empty table for the manual curation, also a empty 
table for the exclude modifiers.

Michael Munns
Database Analyst
402-559-3821

From: Nathan Graham [mailto:ngra...@kumc.edu]
Sent: Monday, December 08, 2014 10:18 AM
To: Munns, Michael B
Subject: RE: RxNorm metadata

Michael,

I'd really like to keep these conversations on the 
gpc-devhttp://listserv.kumc.edu/pipermail/gpc-dev/ mailing list (sign up from 
 herehttp://listserv.kumc.edu/mailman/listinfo/gpc-dev).  If you have 
questions I think others will too.  And, I think we all benefit from as much 
collaboration as we can have.  Could we move future questions there?

I think what you want is an empty table right now.  The manual curation table 
is what it says - a place for you to manually specify parents for medications 
that we didn't link from Epic to RxNorm.  The documentation could probably be 
better - from the comment at the top of the file:

Notes about manual curation:
med_map_manual_curation is a table that maps a clarity medication ID to a parent
concept.  It is designed to be used for medications that we couldn't map to 
RxNORM
directly from information in Clarity (via GCN, NDC, etc). This parent could be a
VA class or an SCDF/SBDF.

The table has the following columns:
CLARITY_MEDICATION_ID - the id of the med without direct linkage to RxNORM
CLARITY_NAME (not used for mapping - just for eyeballing)
FACTS (not used for mapping - just for eyeballing)
PATIENTS (not used for mapping - just for eyeballing)
VA_NAME (not used for mapping - just for eyeballing)
VA_RXAUI - If we didn't map to an SDF AUI (below), the fall back on this one 
for VA class.
SDF_RXAUI - Map here if not null, otherwise fall back on the VA_RXAUI (above)
SDF_NAME (not used for mapping - just for eyeballing)

I know I've probably made KU-specific assumptions in the code that make porting 
difficult.  So, if you have improvements, suggestions, etc I'd be very happy to 
look at patches.  Or, if you start using the Elephant repository (see 
MultiSiteDevhttps://informatics.gpcnetwork.org/trac/Project/wiki/MultiSiteDev)
 you could commit directly to a branch and we could work together to merge your 
changes into default as appropriate.

Thanks.

Regards,

Nathan


From: Munns, Michael B [mailto:mike.mu...@unmc.edu]
Sent: Thursday, December 04, 2014 4:18 PM
To: Nathan Graham
Subject: RE: RxNorm metadata
Importance: High

I have more questions about this rxnorm_terms table.

On line 274 there is a create the I am running as an insert, that contains a 
union for the manual curation. If I am following all of this correct, and I am 
not sure that I am,  some of this may be that it's the first time we've ran and 
the rxnorm_terms is empty.

To start though there is a view mapped_meds , that uses rxnorm_terms. Then the 
view unmapped_meds is built off of mapped_meds. The unmapped_meds view is used 
in a query to create the med_map_manual_curation.csv which is used to
Populate the med_map_manual_curation table.

The union in the create @274 calls the med_map_manual_curation table , which 
does not exist. The join is where its med id is not null. So I could remove 
that section of the code or put an empty table out there.

Any downside to an empty table or skipping that union you are aware of? Am I 
missing something?



Michael Munns
Database Analyst
402-559-3821

From: Munns, Michael B
Sent: Thursday, December 04, 2014 1:41 PM
To: 'Nathan Graham'
Subject: RE: RxNorm metadata

Nathan, I found it there and created the view.

There may be more questions coming though.

Michael Munns
Database Analyst
402-559-3821

From: Nathan Graham [mailto:ngra...@kumc.edu]
Sent: Thursday, December 04, 2014 11:04 AM
To: Munns, Michael B
Subject: RE: RxNorm metadata

Michael,

Normal_concept is created in 
metadata_init.sqlhttps://informatics.kumc.edu/work/browser/heron_load/metadata_init.sql.
  I think it's just a shortcut since nearly all of our concepts have exactly 
the same values for those fields.

--
Nathan

From: Munns, Michael B [mailto:mike.mu...@unmc.edu]
Sent: Wednesday, December 03, 2014 3:16 PM
To: Nathan Graham
Subject: RE: RxNorm metadata
Importance: High

Thanks Nathan.

Do you know where the creation for 
BlueHeronMetadata.normal_concept@deidmailto:BlueHeronMetadata.normal_concept@deid
 code is? We have deid and blueheronmetadata but not the normal_concept table

Michael Munns
Database Analyst
402-559-3821

From: Nathan Graham [mailto:ngra...@kumc.edu]
Sent: Tuesday, December 02, 2014 6:39 PM
To: Munns, Michael B; 
gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu
Subject: RE: RxNorm metadata

Michael,

I think you're looking at obsolete code (well, obsolete with respect to the 
current KUMC ETL code anyway).  The medication mapping code was recently 
rewrittenhttp://listserv.kumc.edu/pipermail/gpc-dev/2014q4/000655.html and 
the part you asked about was removed.

The main design change implemented during the rewrite

RxNorm metadata

2014-12-02 Thread Munns, Michael B
I am working on the RxNorm metadata using the KU epic_med_mapping.sql script.

In there is the creation of a table rxnorm.clarity_name_to_rxcui_medex and then 
a second table is created off of that. I don't see where the
rxnorm.clarity_name_to_rxcui_medex gets populated from. There is a link a medex 
tool in the script. What am I missing?

Michael Munns
Database Analyst
402-559-3821


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.
___
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev