Russ, Is this something the PIs have discussed and vetted? Jim
James R. Campbell MD [email protected] Office: 402-559-7505 Secretary: 402-559-7299 Pager: 402-888-1230 > On May 21, 2015, at 9:28 PM, "Borromeo, Charles" <[email protected]> wrote: > > Hi Jim, > The 2 data marts per site comment was directly from Leslie and Jeff. I > have heard them discuss it before and I assumed they discussed it with > all the CDRNs. I agree that there is nothing explicit in the CDM specs > referencing the 2 data mart deployment and that is troubling. > > You may want to ask them directly about the 2 data mart approach. Perhaps > they have not communicated this suggestion as thoroughly as they thought. > I don’t like the 2 data mart approach since PopMedNet does not permit > queries across the data marts. > > Chuck > >> On 5/21/15, 4:34 PM, "Campbell, James R" <[email protected]> wrote: >> >> Charles >> This comment about two datamarts per site is something brand new to me. >> There is certainly nothing explicit in CDM specs that imply such a >> requirement. >> From our i2b2 native reference datasets, we have SQL queries that prepare >> the data in CDM table format although the jump from CDM V2 to V3 is going >> to be troublesome, as I indicated to Russ >> Jim >> >> James R. Campbell MD >> [email protected] >> Office 402-559-7505 >> Secretary 402-559-7299 >> Fax 402-559-8396 >> Pager 402-888-1230 >> >> -----Original Message----- >> From: Borromeo, Charles [mailto:[email protected]] >> Sent: Thursday, May 21, 2015 9:00 AM >> To: Russ Waitman; Campbell, James R; [email protected]; McClay, >> James C >> Cc: Mandl, Kenneth ([email protected]); Shawn N. Murphy >> ([email protected]); Rachel Hess ([email protected]) >> Subject: Re: PCORI CDM V3 vote >> >> Hi Russ, >> We met with DSSNI on Monday. The PaTH CDRN shares your concerns about >> the non-EAV structure of the data model. Dr. Chris Chute (recently joined >> JHU) also thinks the CDM is very brittle. However, PaTH never dedicated >> time to developing a viable alternative to the CDM. It seemed like too >> big of a change to discuss given the CDM 3.0 approval date of May 2015. >> >> I did discuss a short-term flaw with Jeff, Leslie, Laura, and Rich Platt. >> In PaTH, I am developing some Python scripts to convert our i2b2 data >> into the CDM. According to DSSNI, the CDRNs should deploy 2 DataMarts: >> one with EMR data and one with Claims data. Deploying two DataMarts >> allows the CDRNs to avoid the issue of combining Claims Encounters with >> EMR Encounters. Leslie said some CDRNs are required to keep the Claims >> data separate from the EMR data thus necessitating 2 DataMarts. During >> the development process I found a flaw with the 2 DataMart approach. >> Basically, the Claims only DataMart would be missing data in several >> tables (see attached image) including: VITAL, CONDITION, PRO_CM, >> LAB_RESULT_CM, and PRESCRIBING. The data for these tables comes from the >> EMR, not claims. Therefore, the Claims Only DataMart would only be able >> to answer a subset of research questions. During the discussion, it >> appeared that Jeff Brown did not have a technical solution allowing him >> to query across the 2 DataMarts in a single query. Therefore, storing >> the data in one DataMart would answer more research questions. >> >> I suggested that DSSNI add some columns to the tables allowing the ETL >> process to describe the data provenance. The columns would include >> information about the type of encounter (inpatient vs outpatient) and >> datasource (claims vs EMR). Some of the tables (like PROCEDURES) already >> have these columns (ENC_TYPE and PX_TYPE). DSSNI would need to check the >> other tables to ensure this information. This approach effectively >> demotes the importance of the encounter and eliminates the need to >> combine encounters. There may be some other alternatives. >> >> Jeff said he would give this some consideration so we will see what >> happens. >> >> Chuck Borromeo >> >> From: Russ Waitman <[email protected]> >> Date: Thursday, May 21, 2015 at 9:20 AM >> To: "'Campbell, James R'" <[email protected]>, >> "[email protected]" <[email protected]>, "'McClay, James >> C ([email protected])'" <[email protected]> >> Cc: Charles Borromeo <[email protected]>, "Mandl, Kenneth >> ([email protected])" >> <[email protected]>, "Shawn N. Murphy >> ([email protected])" <[email protected]>, Rachel Hess >> <[email protected]> >> Subject: RE: PCORI CDM V3 vote >> >> >> Dear Jim and GPC Dev, >> Thanks for the good discussion Tuesday regarding the CDM 3 vote: >> >> https://docs.google.com/document/d/1ih4XGJVrTjIH7xOHAnQOqfqKvLl9ZxovS5PXgF >> O >> T7qo/edit >> <https://docs.google.com/document/d/1ih4XGJVrTjIH7xOHAnQOqfqKvLl9ZxovS5PXg >> F >> OT7qo/edit> >> >> Did we as the GPC or any other CDRNs ever propose alternatives or >> improved modifications to the CDM draft? >> >> If not, was it because >> >> - >> No opportunity >> - >> there was a sense it was futile >> - >> No interest >> >> >> Do we have written recommendations to improve CDM3 or specifically >> identify the flaws or most difficult to maintain sections? >> >> >> At a high level I view adding prescribing/ordered medications as good >> >> >> I am still concerned this non-EAV model or each domain is very expensive >> to augment and maintain >> >> >> It would be preferable to share extensible enhancements with the group as >> an alternative, >> >> Russ >> >> >> >> From: Campbell, James R [mailto:[email protected]] >> >> Sent: Monday, May 18, 2015 7:10 AM >> To: Russ Waitman >> Subject: RE: PCORI CDM V3 vote >> >> >> >> On Saturday PCORI preemptively cancelled the DSSNI call scheduled for >> today. There has been no organized discussion of CDM for a month now. >> They have moved the decision making >> to the PIs, apparently to limit debate and need for their response. It >> seems they have been missing every deadline they set for themselves and I >> am not sure what to expect. Are you saying they have not been discussing >> this within the PI steering group either? >> Jim >> ________________________________________ >> >> From: Russ Waitman [[email protected]] >> Sent: Monday, May 18, 2015 6:25 AM >> To: Campbell, James R >> Cc: Dan Connolly; McClay, James C >> Subject: Re: PCORI CDM V3 vote >> >> That secure transmission is the fault of the KUMC email system. No idea >> why it did that. >> >> >> >> I think we are all somewhat non-enthusiastic of the direction of the CDM. >> >> >> >> Do you have suggestions that would improve the next iteration? Any >> chance to bring those forward to Disney? >> >> >> >> Russ >> On May 17, 2015, at 10:23 AM, Campbell, James R <[email protected]> wrote: >> >> >> Russ, >> >> Thanks for sharing the CDM V3 document with me. Why the secure >> transmission? I thought this was public knowledge? >> >> >> >> Have they been discussing these changes in the CDM in the PI forum? >> Looking through the copy that you sent me I count over 35 data >> attributes ADDED since our input was tendered on V3. Many of those >> additions do nothing to improve data quality (like all the temporary >> primary identifier fields we will have to generateŠ..we need to be sure >> they are serious that we do not have to maintain IDs across refresh >> cycles) and will be a lot of work for GPC data managers. I can >> understand hat perhaps they will be useful for the central data warehouse >> managers and presume that is where the requirements originated. >> >> >> >> I assume that many networks are refusing to release non-obfuscated dates >> without full IRB and so I appreciate the rationale for the proliferation >> of HARVEST.Attributes but that table will have to be regenerated for >> each trial report assuming that we will have a mixture of IRB approved >> and non-approved trials. >> >> >> >> They are giving lip service to compliance with meaningful use >> standardization but are adding duplicate data identification requirements >> (PRO_CM.PRO_ITEM; LAB_RESULT.LAB_NAME are >> examples) that create overhead for our data managers and require mapping >> tables in addition to what our sites are doing for ONC compliance. >> >> >> >> I was suprized by the appearance of the table 2.5 ³Implementation >> Expectations² table of page 6. Are a lot of CDRNs not able to produce >> LAB, CONDITION, DEATH and PRESCRIBING datasets? Will these be the >> factors that separate the men from the boys in trial participation? I >> don¹t see how they can do the ADAPTABLE trial from EHR data harvest >> without some of these data sets. >> >> >> >> In short, this V3 document creates a lot of new requirements for our data >> managers, many with apparently arbitrary specs. If we can take table >> 2.5 literally, GPC should be able to meet CDM compliance in the next few >> months but I ask if the OPTIONAL tables will not be the mark of the truly >> successful CDRN and therefore required for our long term viability. >> >> >> >> Please provide your prospectives on this. What is the discussion among >> PIs? Is the snowball already hallway down the hill? >> >> Jim >> >> >> >> NEW or REVISED ELEMENTS IN CDM V3 >> >> DIAGNOSIS.DIAGNOSISID (Unique over time for all queries to site?? They >> say no and so I ask WHY?) >> >> PROCEDURE.PROCEDURESID >> >> VITAL.SMOKING >> >> VITAL.TOBACCO (CHANGED FROM V2; IT APPEARS THAT THEY HAVE CREATED >> DUPLICATE ENTRIES FOR SMOKING BEHAVIOR AND HAVE CHANGED V2 DEFINITIONS ON >> TOBACCO TYPE. THIS FLIES IN THE FACE OF WHAT WE ARE BEING REQUIRED TO >> REPORT FOR MEANINGFUL USE ) >> >> VITAL.TOBACCO_TYPE >> >> DISPENSING.DISPENSINGID >> >> DISPENSING.PRESCRIBINGID (QUESTIONABLE ADDITION! THOSE OF OUR SITES THAT >> CAN REPORT THIS WILL BE ACCEPTING SURESCRIPTS DATA THAT THEY HAVE NOT >> ORIGINATED) >> >> DISPENSING.NDC (SHOULD SPECIFICALLY DRAW FROM NLM RXNAV PUBLICATION) >> >> [LAB_RESULT.LAB_NAME CREATES BURDEN FOR MAPPING ALL TEST NAMES IN >> ADDITION TO LOINC SOTH NAME WHICH SHOULD BE QUITE ADEQUATE FOR RESEARCH >> PURPOSES] >> >> LAB_RESULT.NORM_MODIFIER_LO >> >> LAB_RESULT.NORM_MODIFIER_HI >> >> CONDITION.CONDITIONID >> >> PRO_CM.PRO_CMID >> >> PRO_CM.PRO_ITEM (REDUNDANT WITH LOINC CODE ?WHY?) >> >> PRESCRIBING.ORDER_TIME >> >> PRESCRIBING _FREQUENCY >> >> PRESCRIBING.RX_BASIS (NEW; THIS IS INCONSISTENT WITH GUIDANCE ON NATURE >> OF THE DISPENSING RECORD AND MAKES NO SENSE!) >> >> PCORNET_TRIAL.PARTICIPANTID >> >> PCORNET_TRIAL.TRIALSITEID >> >> HARVEST.BIRTH_DATE_MGMT >> >> HARVEST.ENR_START_DATE_MGMT >> >> HARVEST.ENR_END_DATE_MGMT >> >> HARVEST.ADMIT_DATE_MGMT >> >> HARVEST.DISCHARGE_DATE_MGMT >> >> HARVEST.PX_DATE_MGMT >> >> HARVEST.RX_ORDER_DATE_MGMT >> >> HARVEST.RX_START_DATE_MGMT >> >> HARVEST.RX_END_DATE_MGMT >> >> HARVEST .RESULT_DATE >> >> HARVEST .MEASURE_DATE >> >> HARVEST.ONSET_DATE_MGMT >> >> HARVEST.REPORT_DATE_MGMT >> >> HARVEST.RESOLVE_DATE_MGMT >> >> HARVEST.PRO_DATE_MGMT >> >> HARVEST.REFRESH_DEMOGRAPHIC_DATE >> >> HARVEST.REFRESH_PRESCRIBING_DATE >> >> HARVEST.REFRESHPCORNET_TRIAL_DATE >> >> HARVEST.REFRESH_DEATH_DATE >> >> HARVEST.REFRESH_DEATH_CAUSE_DATE >> >> >> >> 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. <v3_VOTE.docx> >> >> >> >> 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] >> >> http://www.kumc.edu/ea-mi/ >> >> http://informatics.kumc.edu <http://informatics.kumc.edu/> >> >> http://informatics.gpcnetwork.org a PCORNet collaborative >> >> >> >> >> >> >> >> >> > 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 [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
