Stream: questionnaire
Topic: Encrypting specific answers
Grahame Grieve (Feb 18 2022 at 00:43):
Another question relating the questionnaires from an implementer: Would it be possible to make a particular answer (or a few) secure such that they can only be read by a narrow intended audience, perhaps those that the patient gives an access token to (by various methods).
This means that a questionnaire could have a confidential section that the patient has confidence will only be read by their actual treating physician, not by anyone involved in the workflow
Richard Stanley (Feb 18 2022 at 02:10):
Would that (and hashing/salting) make sense as FHIRPath functions?
John Manning (Feb 18 2022 at 02:36):
@Grahame Grieve, this is a workflow that @Grey Faulkenberry are actively considering on a project. In one of our Questionnaires, the first question asks how (or if) this can be shared. Based on the answer choice, we are tentatively planning to add security labels to the questionnaire as a whole...though individual security tags was another option we had considered.
@Richard Stanley I believe the means by which the security label would be applied (or whatever is applied to the individual question...) is being scripted via a FHIRPath function. That's our plan at least
Grahame Grieve (Feb 18 2022 at 11:23):
well, there's two parts of this - what's the instruction on the questionnaire response, and the other is, how do you ensure by secrets that people cannot ignore the instruction
John Manning (Feb 18 2022 at 13:21):
Agreed.
Lloyd McKenzie (Feb 18 2022 at 15:14):
No capability defined right now. Presumably we could define an extension that would allow the question to be flagged and define an extension for the answer to contain the 'encrypted' content. Is it sufficient to hide the answers, or do we need to hide the fact that certain questions were answered at all or how many answers were provided?
Lloyd McKenzie (Feb 18 2022 at 15:15):
Also, we'd need some expertise on how to perform the encryption of very short elements distributed throughout a form in a 'secure' manner.
Lloyd McKenzie (Feb 18 2022 at 15:16):
An alternative is to not encrypt anything, but instead have extensions that flag certain answers as sensitive - which would then cause the generic "data filtering" capabilities of the server to be enforced based on who queries the data.
Lloyd McKenzie (Feb 18 2022 at 15:16):
(That's a technically simpler solution, provided that the patient trusts the server to control access - which is what we do everywhere else.)
Josh Mandel (Feb 18 2022 at 15:21):
I understand this question is coming up in the context of questionnaires, but do we think this is a unique set of requirements related to questionnaires as opposed to other aspects of the health record?
Josh Mandel (Feb 18 2022 at 15:26):
In other words, end to end encryption and granular element level access controls seem like helpful capabilities regardless of what FHIR resource you might be using to share information.
In a closed ecosystem where you are just submitting the data to one organization and trusting them to manage it correctly internally (giving the right views to the right internal users), standardizing the implementation don't matter much because the patient can't really audit or verify what's happening on the inside and they have to trust the recipient to do the right thing.
In more open architectures where data are being communicated across multiple boundaries and the originator has a good understanding of the identities and roles of end users in the target system, this analysis changes.
Grahame Grieve (Feb 18 2022 at 21:42):
well, my analysis before this has been that end-to-end crypto is something that happens in the infrastructure, outside the resources, and not something we need to be particularly concerned with. E.g. the entire resource is secure, or not. Or an entire CDA document is token protected. The Australian national system can be used that way, and we've got experience with the design decisions and trade-offs involved.
What's different about this case is that some of the content of the resource needs protection, but other parts of the resource need to be not protected. We haven't - to my knowledge - encountered this before. Questionnaire isn't unique in this regard, but it does feel more likely to be the subject of this question due the opportunity for semantic range of the content in a QR. Also, unlike other resources, where the access controls are likely to be baked into the system, with Q/QR, the access controls would have to be based on metadata in the Q/QR
Grahame Grieve (Feb 18 2022 at 21:43):
the case in question is mental health referrals, btw.
Josh Mandel (Feb 18 2022 at 21:56):
But is it an open ecosystem where the client filling out the questionnaire is going to be submitting it to one of many different provider systems, and knows the end-user public keys for all of the clinicians who might need to read the data? This is a very unusual context in my experience.
Lloyd McKenzie (Feb 18 2022 at 22:14):
My question about whether the encryption needs to be only the answers, or whether the fact there were answers (and how many answers there were) was sensitive. In either case, the encrypted extension and removal of the answers is going to play havoc with validation.
Elliot Silver (Feb 18 2022 at 22:29):
Perhaps modular Questionnaires could result in modular QuestionnaireResponses, and the high confidentiality response would have different security labels applied than the lower confidentiality response.
Elliot Silver (Feb 18 2022 at 22:31):
Or the entire response is given high-confidentiality, but the derived Observations, etc. are given varying confidentiality.
Josh Mandel (Feb 18 2022 at 22:32):
Yeah, the potential solution space here is vast. It's worth writing down assumptions about UX, information flow, and pre-coordination of trust relationships before solving this.
Josh Mandel (Feb 18 2022 at 22:32):
Maybe a mini-workshop on this topic.
Last updated: Apr 12 2022 at 19:14 UTC
