Hi Jim, I was on the DSSNI call this morning. I apologize for the confusion regarding the two data marts issue. On the call Jeff said this was a suggestion just made to PaTH. Quite honestly, DSSNI never told me this was a suggestion they made to PaTH exclusively. I was under the impression that they were suggesting this to all CDRNs.
Chuck On 5/21/15, 10: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/1ih4XGJVrTjIH7xOHAnQOqfqKvLl9ZxovS5PXg >>F >>O >>T7qo/edit >><https://docs.google.com/document/d/1ih4XGJVrTjIH7xOHAnQOqfqKvLl9ZxovS5PX >>g >>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 >> >> >> >> >> >> >> >> >> > _______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
