[gpc-informatics] #202: Deploy Data Builder at each GPC site
#202: Deploy Data Builder at each GPC site ---+-- Reporter: dconnolly | Owner: dconnolly Type: task | Status: new Priority: major | Milestone: bc-survey-cohort-def Component: data-sharing | Keywords: breast-cancer-cohort Blocked By:| Blocking: ---+-- The Nov 25 **Work Plan 1-revised 25 Nov 2014.docx** attached to #167 includes: c. The Participant Honest Brokers will submit the requested information in the agreed-upon format to the GPC Honest Broker. ''The status of that document isn't entirely clear, but planning conservatively...'' This implies deploying the data builder (#87) at all participating sites. -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/202 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
Re: [gpc-informatics] #202: Deploy Data Builder at each GPC site
#202: Deploy Data Builder at each GPC site --+--- Reporter: dconnolly | Owner: lv Type: task | Status: assigned Priority: major | Milestone: bc-survey-cohort-def Component: data-sharing | Resolution: Keywords: breast-cancer-cohort | Blocked By: Blocking:| --+--- Changes (by dconnolly): * owner: dconnolly = lv * status: new = assigned Comment: Laurel, In tomorrow's teleconference, please poll sites for their guestimate of when they can have the data builder deployed for use in the breast cancer survey. -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/202#comment:1 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
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 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
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.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.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 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.
Re: [gpc-informatics] #167: Breast Cancer Cohort Selection Criteria
Let's discuss. We intend to have sites apply very minimal selection criteria, return a fair number of variables, and apply exclusions centrally after quality checking. I will review the timeline later today (on a flight now and need to switch to airplane mode). Sent from my iPhone On Dec 8, 2014, at 10:26 AM, GPC Informatics d...@madmode.com wrote: #167: Breast Cancer Cohort Selection Criteria +-- Reporter: bchrischilles | Owner: tmcmahon Type: task| Status: assigned Priority: major | Milestone: bc-survey- Component: data-stds | cohort-def Keywords: breast-cancer-cohort, data-quality | Resolution: Blocking: | Blocked By: +-- Changes (by dconnolly): * cc: bzschoche (added) Comment: Betsy, Tamara, I just discovered the Nov 25 work plan attachment. That's significantly different from my understanding as of comment:3 when we targeted having informatics support for the survey ready by Nov 15. Having all the sites send data to the GPC honest broker for QA implies deploying the data builder at all sites (#202). As a rough estimate, I expect that would take 2 to 3 months; i.e. the sites could send their data in perhaps February or March. Does that time frame work for you? -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/167#comment:18 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
