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-dev<http://listserv.kumc.edu/pipermail/gpc-dev/> mailing list (sign up from here<http://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 MultiSiteDev<https://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.sql<https://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@deid<mailto: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.edu<mailto: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 rewritten<http://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 was the paths/full names are comprised of the RxNorm AUIs/local medication IDs (for example, \i2b2\Medications\RXAUI:3257490\RXAUI:3257495\MEDICATION_ID:129272\). As far as I know we plan to use the AUI-based paths as the GPC standard for medications (see also gpc-dev conference call notes for 2014.10.28<http://listserv.kumc.edu/pipermail/gpc-dev/attachments/20141028/554bffae/attachment-0001.pdf>). Before the rewrite the paths were a concatenation of the medication/NDF-RT names which got really long and messy. I think you'll also find that the new code is much easier to read and better documented (hopefully). For the newer code see epic_med_mapping.sql<https://informatics.kumc.edu/work/browser/heron_load/epic_med_mapping.sql> on the KUMC Informatics wiki. Or, update to a newer version of the KUMC ETL code from the GPC shared repository (see MultiSiteDev<https://informatics.gpcnetwork.org/trac/Project/wiki/MultiSiteDev>). The GPC tickets relevant to the medication mapping rewrite include #78<https://informatics.gpcnetwork.org/trac/Project/ticket/78>, #181<https://informatics.gpcnetwork.org/trac/Project/ticket/181>, and #152<https://informatics.gpcnetwork.org/trac/Project/ticket/152>. Regards, Nathan From: gpc-dev-boun...@listserv.kumc.edu<mailto:gpc-dev-boun...@listserv.kumc.edu> [mailto:gpc-dev-boun...@listserv.kumc.edu] On Behalf Of Munns, Michael B Sent: Tuesday, December 02, 2014 3:59 PM To: gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu> Subject: RxNorm metadata 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
