Meeting Notes for 3/4/2014
1.
Convene, take roll, review records and plan next meeting
*
Meeting ID and access code:
686-845-717<https://mail.kumc.edu/owa/redir.aspx?C=wwTlCBySzU2MlCRJ-UMUajZ4RYqDCtEIYq_TFvA1uXCSc1zVsMgIcbN81drrZLF2tovKmZ3fqi4.&URL=https%3a%2f%2fglobal.gotomeeting.com%2fmeeting%2fjoin%2f686845717>
call +1 (267) 507-0008
*
Scribe: from MCW. Here's hoping we can use a google doc again.
*
roll: all 10
DevTeams<http://informatics.gpcnetwork.org/trac/Project/wiki/DevTeams>
represented? MCW, WISC, KUMC, UNMC, UMN, UTHSCSA, MCRF, UTSW, CMH (-IOWA)
*
RESOLVED: to accept minutes of February 13, 2014 at 12:05 PM as a true record,
with thanks to Tom Mish. missing from web archive. darn.
2.
Review of standardization principles and project plan from Hackathon
#10<http://informatics.gpcnetwork.org/trac/Project/ticket/10>
*
cf Data standardization notes and
workplan<http://www.mail-archive.com/[email protected]/msg00153.html>
Campbell, James R.
*
Q: Are the Data Quality Plans OK AS proposed ?
*
Objective 1.1 of Data Standardization Worklist. Just need to to have I2B2
Running.
*
sharing Ontology work products
*
Dan: we don’t require that the contributions to babel be publicly available
*
Nate: Cerner / CMH prefers that their Ontology files not be publically
available .
*
Right now someone has to log into Babel to see the ontology.
*
Q: Public / Private sharing of data discussion
*
PCORI central desktop for sharing ?
*
New repository for sharing ?
*
A: Group Approves trying PCORI central desktop approach.
*
Dan to share CSV files from babel with GPC via PCORI central desktop
*
Russ to contact John Steinmetz to set up accounts.
3.
Data quality: sharing authorization
#69<http://informatics.gpcnetwork.org/trac/Project/ticket/69>
*
Russ: Please share discussion results / documentation with the group as you
work thru the issues at your institution.
*
(who asked?) examples of quality metrics? getting approval is easier if I can
be more specific about what quality metrics look like
*
% duplicate MRNs
*
% missing dates of birth
*
% missing race info
*
data that gets lost from Epic to i2b2 in ETL
*
% lab tests without a LOINC code
*
Jim to draft a policy development document that will outline what we’re trying
to have each of the sites develop, including these examples
*
Aaron: hard to know what to look for until we start digging, so let’s not give
the idea that this list is exhaustive
*
several sites have discussions in progress; sounds like a few more weeks ‘till
they conclude. JRC: How long exactly?
*
Tom M.: I have to deal with a steering committee that meets only once a month
*
Jim: so 2 months? March 1 to May 1?
*
MCRF, UMN: yes
* <http://informatics.gpcnetwork.org/trac/Project/ticket/69>
4.
data quality design issue
#70<http://informatics.gpcnetwork.org/trac/Project/ticket/70>
5.
Agenda discussion for Quality Assurance subcommittee and project planning
*
Russ to convene meeting
6.
HackathonOne#Records<http://informatics.gpcnetwork.org/trac/Project/wiki/HackathonOne#Records>
review. no changes requested.
7.
#73<http://informatics.gpcnetwork.org/trac/Project/ticket/73> de-id plan
*
Reeder: yes, I’m starting to think about a document… in sum: HIPAA
de-identified data set. remove 18 identifiers; date shifting up to 365 days on
a per-patient basis; 3 digit zip codes except where there are less than 20K in
there… age 90 stuff…
*
Reeder: is the 365 day shifting technique “approved”? I know everybody’s doing
something like that
*
Dan: that’s my understanding; everybody’s doing something like that, but
there’s no officially approved approach
*
Reeder: might need a instance mapping table
*
Reeder: tval_char can be tricky. I’m inclined to avoid free-text
deidentification
*
JRC: age at which you made a diagnosis of breast cancer… I expect DOB won’t be
in our de-identified data set
*
Reeder: we’ll have the shifted DOB, so we can compute age at visit etc.
*
JRC: I’ve been looking at LOINC and [missed] for age
*
Bokov: is the concern that age > 90 reduces the set of patients to such a small
number that the risk of re-identification is unacceptable?
*
Dan/others: yes, presumably
*
Bokov: how about a per-visit random offset of +/- 7 days?
*
Russ: we can survey current approach; in HERON, we change birthdays of people
over 90.
*
DanC: we’re pretty far into the details; can we take this to email?
*
Reeder: I’ll send out something for review.
*
Nate: the programmatic changes to scramble is something we shouldn’t share
publicly
* Bokov: we needn’t rely on security by obscurity; the encryption
keys and random offsets provide the privacy
George Kowalski
Biomedical Informatics Software Engineer
Clinical & Translational Science Institute
Medical College of Wisconsin
9200 West Wisconsin Avenue, Suite L722A
Milwaukee, Wisconsin USA 53226
414.805.7318 (office) / [email protected]<mailto:[email protected]>
_______________________________________________
Gpc-dev mailing list
[email protected]
http://listserv.kumc.edu/mailman/listinfo/gpc-dev
