[Openid-specs-heart] Patient Consent

[John Moehrke]

That kind of policy is very hard to make work. The reason is that the
expectation is that you really blind all HIV related data; yet it is almost
impossible to determine this. Especially when the user is a Clinician.
Clinicians are very smart 'inference engines'". They can use very weak
signal to determine something. This is indeed their job, to take the little
bit of information the get and come up with a diagnosis, and treatment
plan. Thus we find that they are very good at reverse inferring from the
data they got, and the blank space they didn't get, that the only possible
conclusion is that the patient is HIV Positive.  I use clinicians as an
extreme, but the same can be said for others that have the motivation and
ability (aka google).

What we have done in the Privacy on FHIR project, is to use a "Clinical
Decision Support" engine to temporary tag data that might be related to a
set of sensitive topics of interest, then use that temporary tag in access
control decisions and enforcement. This has the advantage of moving the
'clinical knowledge' outside of the access control engine; treating the CDS
as a PIP. However this is a very fragile system, and one that has some
medical-records-integrity concerns.

These are desirable rules, they are just not practical.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Mon, Jul 11, 2016 at 2:31 PM, Debbie Bucci <debbucci at gmail.com> wrote:

> So ... the RS  *should* have an idea of what medications aligns with  each
> diagnosis.   Wouldn't a patient request to not reveal /release HIV for some
> purpose of use info be enough info to provide to the RS to use (but note
> the RS may not comply due to various reasons  - but should record for audit
> purposes)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160711/7b539f9e/attachment.html>