Phillip, at your organization, is identified data built based on real time data (data mart built at the time of the identified data request)? Or is the identified data loaded synchronously with the de-identified data each time the ETL process occurs for each i2b2 load?
It would seem that in many use cases, your request could make the data more accurate from a data quality point of view. Many organizations I've worked with in the past (as Epic customers) often merged patients on a daily or weekly basis because the source system gets duplicates or for other reasons, or a fix is put in place to fix data integrity or patient safety issue. This use case alone gives a nice indication of the best approach to querying the cohort to get identified information. Unless of course you've designed your master patient index such that this use case will still result in correct identifiable cohorts. Billing data (this gets into the procedures discussion) is another example of data that updated for past data. And this data has to be stale for the revenue cycle to work correctly, and can often be changed for up to 6 months or more in the past. Diagnosis can often change (even in the clinical system) if addendums occur in the source system. That data again would be stale and changed downstream, and may affect a cohort if it's identified. This may be a little early for these conversations, but I'd be curious what others are doing for the identification process (re-identification as Phillip calls it). We have been playing with a couple methodologies here at UW, but have not finalized anything yet. Both approaches have their pros and cons. -Keith From: [email protected] [mailto:[email protected]] On Behalf Of Phillip Reeder Sent: Tuesday, March 04, 2014 1:12 PM To: Dan Connolly; [email protected] Subject: Re: [Gpc-dev] GPC De-Identification Plan I would think that the GPC Policy/Plan should be that the De-Identified data, stay de-identified and we would not re-identify the patients from a de-identified cohort. Instead of re-identifying, we would actually re-run the same query that generates the de-identified cohort, using the identified data to survey/enroll them in a trial. Technically, if we did want to re-identify patients, we could keep the patient_mapping table around and use that to do so, but that could defeat the purpose of having a HIPAA Safe Harbor data set. Phillip From: Dan Connolly <[email protected]<mailto:[email protected]>> Date: Tuesday, March 4, 2014 1:02 PM To: Phillip Reeder <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: GPC De-Identification Plan The plan we submit is required to cover re-identification, too. For example, once a cohort is identified, I think we're supposed to be able to survey them or enroll them in a trial. That part can be written by somebody else if you prefer. -- Dan ________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Phillip Reeder [[email protected]<mailto:[email protected]>] Sent: Tuesday, March 04, 2014 12:57 PM To: Greater Plains Collaborative Software Development Subject: [Gpc-dev] GPC De-Identification Plan Attached is a draft de-identification plan. It's meant to be an overview of how we will be de-identifying our data. I expect that there will be a second document which will include the technical implementation of de-identification, once everyone is in agreement with general plan. The technical plan would include details like where and how we generate/store the date offset during ETL, how we populate the various ID mapping tables, etc. Phillip ________________________________ UT Southwestern Medical Center The future of medicine, today.
_______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
