Stream: implementers
Topic: Accessing de-identified patient data
Farhan Ahmad (Jan 23 2018 at 04:55):
Hi,
Our product (HealthDecision) can function with de-identified information, but the EHR-specific custom-integration needed for this approach can be quite burdensome for the institutional IT teams. So, we have worked on our FHIR-based implementation only to learn that institutions now put up a lot of resistance because of the PHI access; even with proper HIPAA/processes in place. Our team feels that addressing this can speed up our sales cycles significantly, but we also don't want to eliminate the ease that EHR-supported FHIR-based implementations bring.
I have seen some conversations around de-identified patient information on here, but I couldn't conclude the current state. Has anyone else here run into a similar situation? If so, how did you address it? Is there any standards-based/recommended approach to dealing with our situation where we would like to access FHIR-resources with only the de-identified data items?
We have been envisioning a possible open-source application that can be hosted by the institutions within their networks which does this, but we are hoping not to reinvent the wheel if one already exists. We see that products like Mulesoft support FHIR, so we are also wondering if maybe a middleware tool like that might be a good route.
Thank you in advance for any insights!
Lloyd McKenzie (Jan 23 2018 at 05:05):
@John Moehrke can best explain the current state, but the gist is that "standardized" de-identification isn't possible because de-identification is too much tied into the nuances of the specific types of data, how it's captured, how much of it is exposed and how it's used. As well, de-identification is a question of risk reduction, not risk elimination and it's difficult to standardize the tolerance of risk too.
Vassil Peytchev (Jan 23 2018 at 05:24):
As far as general approaches to de-identification go, there is the IHE cookbook. How and whether it may have been applied to FHIR, I don't know. http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Handbook_De-Identification_Rev1.1_2014-06-06.pdf
Grahame Grieve (Jan 23 2018 at 15:49):
there's no canned answer - no one has particularly proposed an area where it would be applicable. I have added a deidentity=true parameter to the bulk data access API on test.fhir.org, but there are many many issues with it, some of which are FHIR bulk data API specific, and others that are explored in the IHE handbook.
Grahame Grieve (Jan 23 2018 at 15:50):
at the policy level, have you read TEFCA?
Lloyd McKenzie (Jan 23 2018 at 16:00):
Is there a link or non-abbreviated name for "TEFCA"? :)
Grahame Grieve (Jan 23 2018 at 16:02):
https://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf - US policy thing about sharing health care information
John Moehrke (Jan 23 2018 at 18:30):
The best approach is to get authorized access to full fidelity, thus no de-identification. But if that can't be achieved, the the 'process' of determining a de-identification scheme is the next step. De-Identification is a process used to lower the risk to privacy/security/identity. This, as Vassil points to the IHE handbook, is a multi-step process to determine what elements MUST stay, and what MUST be eliminated. Mostly you end up with a bunch of grey, that is elements that need to be kept but where some manipulation can happen. There is a section in the FHIR Spec that covers this http://build.fhir.org/secpriv-module.html#deId
John Moehrke (Jan 23 2018 at 18:31):
I have mused on my blog about a de-identification service https://healthcaresecprivacy.blogspot.com/2017/09/fhir-and-bulk-de-identification.html
Farhan Ahmad (Jan 25 2018 at 02:50):
Thank you very much for all the insights!
I had not heard of TEFCA and did a quick read of the linked doc about it. It sounds interesting and I will read through it more to see what it specifically prescribes. Maybe that will give us and the CIOs enough to continue with the standard SMART/FHIR route.
Last updated: Apr 12 2022 at 19:14 UTC
