Nate, Maybe I'm not fully understanding. Are you saying that not all of your medications map directly to an SCDF/SBDF? If so that makes sense - at KU we park them directly under the appropriate SCDF/SBDF parent using the "isa" relationship in RxNorm (rxnorm.rxnrel table). I think that's what Phillip was pointing out previously in this thread.
You said "We definitely agree that the ontology there isn't totally ideal because it fluctuates in terms of what level the terminal RxNorm codes". I think that everything in Babel under the "GPC: Medications" is either an SCDF, SBDF, or VA class from NDF-RT. I just exported all the RXAUIs and joined with RxNorm to double check. Maybe I'm missing something - if so, could you give me a specific path from Babel where that isn't the case? For reference, at KU we use epic_med_mapping.sql<https://informatics.kumc.edu/work/browser/heron_load/epic_med_mapping.sql> * Line 134: map the local medication id to an RXCUI<https://informatics.kumc.edu/work/browser/heron_load/epic_med_mapping.sql#L134> (union of mappings based on GCN and NDC from Epic to RxCUIs) * Line 242: map the medications to an SCDF/SBDF using the "isa" relationship<https://informatics.kumc.edu/work/browser/heron_load/epic_med_mapping.sql#L242> In the Tamoxifen Oral Solution example mentioned before, we get paths like this at KU: \i2b2\Medications\RXAUI:3257528\RXAUI:3257533\RXAUI:1640942\ Tamoxifen Oral Solution \i2b2\Medications\RXAUI:3257528\RXAUI:3257533\RXAUI:1640942\MEDICATION_ID:xxxx\ TAMOXIFEN 10 MG/5 ML PO SOLN \i2b2\Medications\RXAUI:3257528\RXAUI:3257533\RXAUI:1640942\MEDICATION_ID:xxxx\ SOLTAMOX 10 MG/5 ML PO SOLN \i2b2\Medications\RXAUI:3257528\RXAUI:3257533\RXAUI:1640942\MEDICATION_ID:xxxx\ SOLTAMOX PO \i2b2\Medications\RXAUI:3257528\RXAUI:3257533\RXAUI:1640942\MEDICATION_ID:xxxx\ TAMOXIFEN PO The RxAUIs are in this case are SCDFs (from RxNorm) or NDFRT classes. select sab, tty from rxnorm.rxnconso where rxaui in (3257528,3257533,1640942); I'm not arguing for or against adding the ingredient level in there like Phillip proposed - at this point I'm just trying to understand what things aren't SCDFs/SBDFs. Regards, Nathan From: [email protected] [mailto:[email protected]] On Behalf Of Apathy,Nate Sent: Thursday, April 02, 2015 3:29 PM To: Phillip Reeder; Dan Connolly; Russ Waitman Cc: [email protected] Subject: RE: Medication Mapping Issue (standardization measurement framework, milestone:data-quality3) To answer Dan's question below, they are not all SCDFs. Here's the breakdown that we found when attempting to implement. INGREDIENT 34 TMSY 629 BRAND NAME 3 CODED DRUG FORM 4945 SY 6 DRUG FORM 1 CODED BRAND FORM 345 Nate Apathy Solution Manager: i2b2 | [email protected]<mailto:[email protected]> | 816.201.2785 From: Phillip Reeder [mailto:[email protected]] Sent: Thursday, April 02, 2015 2:47 PM To: Dan Connolly; Apathy,Nate; Russ Waitman Cc: [email protected]<mailto:[email protected]>; Meyer,Aaron Subject: Re: Medication Mapping Issue (standardization measurement framework, milestone:data-quality3) If we really want to reconsider the design, I'd propose adding in the ingredient level to the hierarchy, making it for example: ANTINEOPLASTICS\ ANTINEOPLASTIC HORMONES\Tamoxifen\Tamoxifen Oral Solution ANTINEOPLASTICS\ ANTINEOPLASTIC HORMONES\Tamoxifen\Tamoxifen Oral Tablet Basically it groups the SCDFs by ingredient so that the user can easily grab all "Tamoxifen" medications. And for UTSW, with medications that are simply "Tamoxifen Oral" without the tablet/solution/dosage, I can map them to the ingredient level, instead of at the SCDF level. And it would be inline with how the NCATS/ACT project has their terminology created. This would probably be a more disruptive of a change in the terminology than simply adding the SCD level, but it does make for a more useful hierarchy. Phillip From: Dan Connolly <[email protected]<mailto:[email protected]>> Date: Thursday, April 2, 2015 at 2:34 PM To: "Apathy,Nate" <[email protected]<mailto:[email protected]>>, Phillip Reeder <[email protected]<mailto:[email protected]>>, Russ Waitman <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Meyer,Aaron" <[email protected]<mailto:[email protected]>> Subject: RE: Medication Mapping Issue (standardization measurement framework, milestone:data-quality3) Phillip has made a reasonable case for re-considering the design; email is sufficient to "put this to the group". I'm mulling it over, and I trust others are too. Like you, I'm particularly interested to hear from UTHSCSA. Hmm... while it's true that queries for terms for SCDFs will match facts associated with more specific terms, it doesn't work the other way around. But I suppose that's a general issue and not one specific to meds. I don't understand "it fluctuates in terms of what level the terminal RxNorm codes are". They're all SCDFs, no? -- Dan ________________________________ From: Apathy,Nate [[email protected]<mailto:[email protected]>] Sent: Thursday, April 02, 2015 1:46 PM To: Phillip Reeder; Dan Connolly; Russ Waitman Cc: [email protected]<mailto:[email protected]>; Meyer,Aaron Subject: RE: Medication Mapping Issue (standardization measurement framework, milestone:data-quality3) Hi Phillip, Aaron has been working on this over the last several weeks for us to map local NDC codes to the current GPC ontology that was agreed upon in ticket 78<https://urldefense.proofpoint.com/v2/url?u=https-3A__informatics.gpcnetwork.org_trac_Project_ticket_78&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=zkJgk19tyAj3kB9PB1ogI6XX_nayrgGpUnOvDTiD4M8&s=auCu8FcSCZ-Hspu_XTvxw1eNffah9X_EzT7Hp0DagY4&e=>. We definitely agree that the ontology there isn't totally ideal because it fluctuates in terms of what level the terminal RxNorm codes are. But while more difficult to implement than anticipated, it is possible to be used for the GPC purposes, and has been adopted at UTHSCSA. We should probably put this up to the group to determine if we want to change the hierarchy at this late stage and re-open that ticket. @Dan, I won't be on the next GPC-Dev call as I'll be traveling, but is this worth tentatively adding to the April 14 agenda? Nate Apathy Solution Manager: i2b2 | [email protected]<mailto:[email protected]> | 816.201.2785 From: Phillip Reeder [mailto:[email protected]] Sent: Wednesday, April 01, 2015 10:58 AM To: Dan Connolly; Apathy,Nate; Russ Waitman Cc: [email protected]<mailto:[email protected]> Subject: Re: Medication Mapping Issue (standardization measurement framework, milestone:data-quality3) Nate, The GPC terminology looks to be at the Semantic Dose Form level, but my rxnorm mapping (I'm guessing like yours) is to a more granular level so simply joining the two will not work. For example, the GPC terminology has "Tamoxifen Oral Tablet", but my meds map to "Tamoxifen 20MG Oral Tablet". I've re-built the GPC terminology with the SCD level included. It should be path compliant with what is on babel right now assuming we used the same RxNorm version to generate the terminology. Can you try a medication terminology built with this and let me know if it works for you? Then we can look at adopting this updated terminology as the GPC standard. with va_classes as ( select con1.str parent_name, con1.rxcui parent_rxcui, con1.rxaui parent_rxaui, rel.rel, con2.str child_name, con2.rxcui child_rxcui, con2.rxaui child_rxaui from rxnrel rel join rxnconso con1 on con1.rxaui=rel.rxaui1 join rxnconso con2 on con2.rxaui=rel.rxaui2 join rxnsat sat2 on sat2.code = con2.scui where rel.sab = 'NDFRT' and rel.rel = 'CHD' and sat2.atv = 'VA Class' union all -- Make "Drug Products by VA Class" (RxAUI = 3149154) the top of the hierarchy select null parent_name, null parent_rxcui, null parent_rxaui, 'CHD' rel, con.str child_name, con.rxcui child_rxcui, con.rxaui child_rxaui from rxnconso con where con.rxaui = 3149154 ), scdf_sbdf as ( select con1.str sdf_name, con1.rxcui sdf_rxcui, con1.rxaui sdf_rxaui, con1.sab sdf_sab, con2.str isa_name, con2.rxcui isa_rxcui, con2.rxaui isa_rxaui, con2.sab isa_sab /* None of the concepts marked as SCDF are direct children of any of the VA classes. So, utilze the 'isa' relationship. */ from rxnrel rel join rxnconso con1 on con1.rxcui=rel.rxcui1 join rxnconso con2 on con2.rxcui=rel.rxcui2 where rel.rela = 'isa' and (con1.tty = 'SCDF' or con1.tty = 'SBDF') ), sdf_children as ( select distinct --Lots of things match the 'isa' criteria - just need the distinct SCDF/SBDF va.child_name va_name, va.child_rxcui va_rxcui, va.child_rxaui va_rxaui, rel.rel, sdf.sdf_name, sdf.sdf_rxcui, sdf.sdf_rxaui--, sdf.sdf_sab from rxnrel rel join va_classes va on va.child_rxaui=rel.rxaui1 join scdf_sbdf sdf on sdf.isa_rxaui = rel.rxaui2 and rel.rel = 'CHD' -- where sdf.sdf_sab = 'RXNORM' --Note, all SCDF/SBDF that join on rxaui are from RXNORM ), scd_children as ( select distinct --Lots of things match the 'isa' criteria - just need the distinct SCDF/SBDF sdf.sdf_name, sdf.sdf_rxcui, sdf.sdf_rxaui, rel.rel, sdf.isa_name, sdf.isa_rxcui, sdf.isa_rxaui--, sdf.sdf_sab from rxnrel rel join scdf_sbdf sdf on sdf.isa_rxaui = rel.rxaui2 and rel.rel = 'CHD' -- where sdf.sdf_sab = 'RXNORM' --Note, all SCDF/SBDF that join on rxaui are from RXNORM ), paths as ( select level as lvl, -- Use the name as the path rather than rxaui: SYS_CONNECT_BY_PATH(child_name, '\') || '\' as concept_path '\GPC\Medications' || SYS_CONNECT_BY_PATH('RXAUI:' || child_rxaui, '\') || '\' as concept_path, va_sdf.* from ( select * from va_classes va union all select * from sdf_children sdf union all select * from scd_children ) va_sdf start with parent_rxaui is null connect by prior child_rxaui = parent_rxaui ) select lvl c_hlevel, concept_path c_fullname, child_name as c_name, 'N' c_synonym_cd, 'FA' c_visualattributes, null c_totalnum, 'RXCUI:' || child_rxcui c_basecode, null c_metadataxml, 'concept_cd' c_facttablecolumn, 'concept_dimension' c_tablename, 'concept_path' c_columnname, 'T' c_columndatatype, 'LIKE' c_operator, concept_path c_dimcode, null c_comment, null c_tooltip, '@' m_applied_path, sysdate as update_date, sysdate as download_date, sysdate as import_date, 'RxNORM' as sourcesystem_cd, null valuetype_cd, null m_exclusion_cd, null c_path, null c_symbol from paths ; Phillip From: Dan Connolly <[email protected]<mailto:[email protected]>> Date: Friday, March 20, 2015 at 3:19 PM To: "Apathy,Nate" <[email protected]<mailto:[email protected]>>, Russ Waitman <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: Medication Mapping Issue (standardization measurement framework, milestone:data-quality3) Nate, Thanks for sharing these numbers on terms matched and volume/facts matched. This is exactly the sort of data that we originally proposed to collect: * GPC Interoperable Standardization Measurement Framework<https://urldefense.proofpoint.com/v2/url?u=https-3A__informatics.gpcnetwork.org_trac_Project_wiki_DataStandardization-23data-2Dstds-2Dframework&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=wubsSERrJf1aQvL9YlfCAGIk7LtlxVAsV8PDsAMg_R8&s=IBdfgzP98ONILj427Fl8Zwr1uWuq9d6ibSfCFxsB4To&e=> I just created a spreadsheet and put those numbers in it: * GPC Terminology Alignment Progress<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spreadsheets_d_1ywbW9rusve8sptB9RVESnpGwRUnwSJ9q-5FtBakhE8INo_edit-3Fusp-3Dsharing&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=wubsSERrJf1aQvL9YlfCAGIk7LtlxVAsV8PDsAMg_R8&s=5bhDSv1wNha0LkYwaTmtBr2HFNc_hd8eeDIch_q3zI0&e=> Bonus points to anyone else who shares similar sorts of data. Tom, Jim, I hope the QA queries will produce this sort of data. I'm interested to know if you think that's feasible in this March go-round. -- Dan ________________________________ From:[email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Apathy,Nate [[email protected]<mailto:[email protected]>] Sent: Wednesday, February 18, 2015 2:37 PM To: Russ Waitman Cc: [email protected]<mailto:[email protected]> Subject: RE: Medication Mapping Issue Hi all, We've been exploring a similar issue with medication mapping to the central RxCUI ontology proposed by KUMC. Though we're not an Epic site, we are in the middle of transitioning from NDC to RxCUI/RxNORM as our primary medication terminology in order to align with GPC. We've done several mappings using different versions of mapping content from NDC to RxCUI, and our closest match (to the ontology) merits about 2,300 matches with the RxCUI ontology out on Babel, which contains about 5,500 RxCUI codes. We have 11,000 unique RxCUI codes from our mappings using the USNLM mapping content, so we're not getting a good amount of those represented with the current GPC RxCUI ontology. The real kicker is that those 2,300 matches only represent about 1.5% of the total volume of medication data that we have, so while it is about half of the ontology, it's significantly less representative of the total amount of potential data that could be represented if all of our codes were matched in the ontology. We're wondering if the ontology is at a specific level of granularity that we haven't accommodated in our mappings, which is making our terms misalign with the precise codes used in the GPC RxCUI ontology. Any help would be greatly appreciated! Thanks for raising this question, Phillip! Nate Apathy Solution Manager: i2b2, Cerner Research From:[email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Russ Waitman Sent: Wednesday, February 18, 2015 1:29 PM To: Bonnie Westra Cc: [email protected]<mailto:[email protected]> Subject: Re: Medication Mapping Issue Somewhat similar to Nathan's experience incorporating the MedEx NLP work for meds here in KC to RxNorm that is documented in the HERON code and informatics.kumc.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__informatics.kumc.edu&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=2jqKMv3zAo-ZqlOBIJLdpdOLG2dk18Skla3R7OgVwbk&s=v3FTqCdPhYkkqSG4CFEcQsNtcSW6nZzPOQc85wngH6M&e=> wiki Russ On Feb 18, 2015, at 12:46 PM, Bonnie Westra <[email protected]<mailto:[email protected]>> wrote: Using the NLM app for mapping medication data to RxNorm, we developed a set of rules when there was no NDC or Medispan code available for mapping. The bottom line is that when there is missing data, we ended up with a more generic RxNorm codes. When we had sufficient details, we were able to map to a more specific code. Bonnie Bonnie L. Westra, PhD, RN, FAAN, FACMI Associate Professor, University of Minnesota, School of Nursing & Institute for Health Informatics Director, Center for Nursing Informatics Location - WDH 6-155 P - 612-625-4470, Fax - 612-625-7091 email - [email protected]<mailto:[email protected]> Mail - WDH 5-140, 308 Harvard St SE, Minneapolis, MN 55455 On Wed, Feb 18, 2015 at 12:18 PM, Phillip Reeder <[email protected]<mailto:[email protected]>> wrote: We have medications in our clarity_medication table that are not as specific as the GPC Medication hierarchy. For example, we have a medication called "ZOLOFT ORAL" This has multiple GCNs associated with it for the 25MG, 50MG, and 100MG versions, and the oral concentrate version. And the current medication mapping code adds the medications under all of the versions. I'm guessing we have this issue because we have been running Epic at UTSW for 10+ years. Do any other GPC epic sites have a similar issue? Thanks, Phillip ________________________________ UT Southwestern Medical Center The future of medicine, today. _______________________________________________ Gpc-dev mailing list [email protected]<mailto:[email protected]> http://listserv.kumc.edu/mailman/listinfo/gpc-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__listserv.kumc.edu_mailman_listinfo_gpc-2Ddev&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=2jqKMv3zAo-ZqlOBIJLdpdOLG2dk18Skla3R7OgVwbk&s=blNlbU7aArThx2XxUD4_7_HaW1t7h1GUZX5IMb5gCBc&e=> _______________________________________________ Gpc-dev mailing list [email protected]<mailto:[email protected]> http://listserv.kumc.edu/mailman/listinfo/gpc-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__listserv.kumc.edu_mailman_listinfo_gpc-2Ddev&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=wubsSERrJf1aQvL9YlfCAGIk7LtlxVAsV8PDsAMg_R8&s=Cd667NhRtrP7JvMFEnFUBgtqgBC1CrPe62u90b3eJIw&e=> Russ Waitman, PhD Director of Medical Informatics Assistant Vice Chancellor for Enterprise Analytics Associate Professor, Department of Internal Medicine University of Kansas Medical Center, Kansas City, Kansas 913-945-7087 (office) [email protected]<mailto:[email protected]> http://www.kumc.edu/ea-mi/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kumc.edu_ea-2Dmi_&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=2jqKMv3zAo-ZqlOBIJLdpdOLG2dk18Skla3R7OgVwbk&s=6F1vBcsFLOmO_hJSinifDBbV_clqMjiRw8cf44Y6tlg&e=> http://informatics.kumc.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__informatics.kumc.edu_&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=2jqKMv3zAo-ZqlOBIJLdpdOLG2dk18Skla3R7OgVwbk&s=LyksC3QUoEO-qPbhm4cLUX3WhBmxbAmhs77nkMANDMY&e=> http://informatics.gpcnetwork.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__informatics.gpcnetwork.org&d=AwMF-g&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=uOh5Q3hepVRzk8WwKUjG80B3swu7bu8ArEfLHUfXY1U&m=2jqKMv3zAo-ZqlOBIJLdpdOLG2dk18Skla3R7OgVwbk&s=Odo0Aju_St3JhdDkLmnsVxqMIF6wIR8gCI6Sd0swnek&e=> - a PCORNet collaborative CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
_______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
