Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Medium
-
FHIR Core (FHIR)
-
STU3
-
Security
-
Provenance
-
-
Elliot Silver / Alexander Mense : 2-0-0
-
Clarification
-
Non-substantive
-
R5
Description
Describe (somewhere?) the use of Provenance as a tracking of De-Identification, with the purpose of enabling appropriate Re-Identification. This is a use of Provenance to hold a cross-reference between identifiable data and de-identified data. This functionality is a recognized method to de-identifiy when re-identification is desired. The use of Provenance is a 'standards' based method where most methods are custom tables (usually a spreadsheet managed only by Privacy Office). Thus the use of Provenance must be carefully protected.
Where a source Resource is De-Identified, which creates a new Resource containing the modified source Resource (E.g. Patient[1] -> Patient[2], with a Provenance.target=Patient[2], Provenance.entity=Patient[1], and Provenance describes the act of de-identification.
Accessibility to these three are likely different.
1. Patient[2] – is the de-identified object that is readable by a larger audience, mostly the research project it was created for
2. Provenance – is the linkage. This might be accessible by the research audience only with expicit reason (like a safety concern). Mostly the Provenance would not be accessible to the research audience. The Provenance might not be available to the audeince in the source domain. Provenance might be available to the Patient asking for who the data has gone to and why.
3.Patient[1] – is the source and thus would still be available on source side.
Alternative: Use of Double linkage of Provenance->Provenance to assure further isolation of risk. Or the Provenance.entity may be only defined with an opaque identifier
Note Provenance.agent might describe for whom the data was identified
Provenance.policy might point at the de-identification rules used