[Openid-specs-heart] FW: FW: Patient Consent

[Nancy Lush]

This is the summary John sent earlier that was very helpful to me.  (I don’t think everyone was copied.)

 

-Nancy

 

From: John Moehrke [mailto:johnmoehrke at gmail.com] 
Sent: Monday, July 11, 2016 2:30 PM
To: Nancy Lush <nlush at lgisoftware.com>
Cc: Eve Maler <eve.maler at forgerock.com>; Debbie Bucci <debbucci at gmail.com>
Subject: Re: FW: [Openid-specs-heart] Patient Consent

 

Hi,

 

I am not sure I understand the proposal? I am glad that the concern I brought up is being considered.  I thought you were going to suggest using securityLabels, or Date ranges; but I am not sure given the text written. From this, it seems he most easy for HEART to focus on is the Date Rang. This is a highly effective one because of how episodic healthcare tends to be.  It keeps HEART away from making clinical assessments. It might however expose  DateRange that might be sensitive..

 

In the FHIR consent work we are choosing a few vectors through the space that are the most useful with least complexity:

 

1. Named objects to include/exclude

2. Date range to include/exclude

 

Then we get into some more difficult ones.

3. Any data related to a medical code (e.g. LOINC, SNOMED CT, etc) include/exclude

4. Any data related to a specific object (e.g. Here is a lab-result, also exclude any other data that points at this lab-result) include/exclude

5. Any data tagged with a specific securityLabel (e.g. data marked as being HIV related) include/exclude

6. Any data tagged as a class of medical information (e.g. MedicalSummary, DischargeSummary, CarePlan) include/exclude

 

We do also have the 'use' vectors

7. Any request for a specific purpose (e.g. Treatment, Research) include/exclude

 

And individuals

8. If the user is X then allow/deny

9. Any data authored by a specific individual (e.g. exclude anything authored by BettyFordClinic) include/exclude

 

As you can see the FHIR Consent work is trying to attack this space with reasonable yet useful 'knobs' that the patient can control. Not sure where we will endup at the end of the month when this goes to HL7 Ballot, or where we end up after we resolve that ballot. Right now we are trying to be effective yet reasonable.

 

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 <mailto:JohnMoehrke at gmail.com> 
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160711/ec3fd4c7/attachment.html>