TICKETS DO NOT ALLOW CHANGES IN CC: I AM MAILING ALL GPC-DEV WITH MY POST BECAUSE AFTER THE LAST CALL I REVISED THE TICKET TO FOCUS ON THE ISSUES OF OVERLAP AND DATA COLLISION IN PREPARING AGGREGATE DATA IN RESPONSE TO POPMEDNET QUERIES. I ASK ALL RESPONDEES TO TICKET 17 TO COPY ALL GPCDEV MEMBERS Jim >>>>> PCORI CDM v1FINAL 2.6 “The CDM will contain some of the 18 elements that define PHI under HIPAA, including encounter dates and date of birth. However, these dates will remain under the control of the institutions that already maintain PHI. To maximize analytic flexibility and allow for all types of analyses, complete and exact dates should be included in the CDM. Distributed analytic programs will use the date fields for analysis, but will generate results that contain the minimum necessary information to address the question. The results returned to the requester will typically be aggregated and not include any PHI. Queries that generate results sets with PHI (eg, a person-level analysis under an IRB, with all necessary data agreements in place) will be clearly flagged as such and will only be distributed with the appropriate approvals clearly documented. As with all distributed queries, sites should review all results before release. The necessary “cross-walks” between the arbitrary identifiers included in the CDM and their originating data are not specified in the scope of the CDM, but are expected to be maintained by each data partner.
* PATID is a pseudoidentifier with a consistent crosswalk to the true identifier retained by the source site. For analytical data sets requiring patient-level data, only the pseudoidentifier is used to link across all information belonging to a patient. * The PATID pseudoidentifier should not be a true identifier. It is not appropriate to use Medical Record Identifiers (MRNs) for this purpose because MRN is a direct patient identifier. * Locally maintained “mapping tables” are tables necessary to implement so that each data partner has the ability to map arbitrary identifiers back to the originating data and patient. * These mapping tables are not part of the PCORnet DRN. Mapping tables for implementation of the CDM v1.0 should include (but are not limited to): * PATID crosswalk * PROVIDER crosswalk” Jim writes: PCORI CDM V1final requires reporting when IRB approved projects are deployed as consolidated datasets across GPC participant sites with record indexes of Patient, Encounter and Provider. Patient and provider crosswalks are to be maintained by the site. PHI authorized data reporting (case-based network aggregation) might create issues for dataset aggregation to PCORI. Case-based reporting requires that we consider issues of a) index collision (patient, provider, encounter) between sites leading to falsely inflated summary counts at PCORI and b) failure to identify index (patient or provider, it is probably reasonable not to consider encounter) identity between sites for these types of projects. Mitigation: a) Collision avoidance requires simply that a site-specific identifier be appended to indexes for all case-based network research project reporting. b) Identity detection for patient and provider will be more troublesome. As suggested by Alex, a universal identifier could be selected (social security for patient, NPI for provider), encrypted and used as the index for case-based research reporting. Marshfield, at least, suggests that overlap in provider and patient indexes within their institution may not be improbable. Between other GPC members the probably of data misreporting would vary but as participation in projects with other PCORI CDRNs becomes more common, the probability of error will escalate. Since the issue only arises with substantial probability in the event of case-based research participation, an argument could be made for handling on project-by-project basis. However, consistency of procedure and reduction of ‘one-off’ errors would suggest that procedures a) and b) be adopted as policy for GPC, understanding that not all sites can implement immediately but that implementation must happen before site participation in PHI authorized research projects. 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.
Ticket 17 text.docx
Description: Ticket 17 text.docx
_______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
