[Openid-specs-heart] HEART profiling for sensitive data

Sat Mar 25 19:12:18 UTC 2017

Thanks John – and to build on your statement about the service getting “…sensitive topics from a Healthcare organization, or might get them from the Patient; possibly both.”

I would add that experience has shown that adoption by Provider Organizations without an Authoritative list of what is sensitive in relation to a specific regulatory set of conditions (think of a HIPAA transaction for Treatment Purposes) has been hard to engender.  My perception is that the law has given no agency the authority to constrain liability (protect the Provider Organization that subscribes to a list of codes representing sensitive topics when that list is defective either sharing too much or sharing too little) for the Provider Organizations that use sanctioned LOVs and basically anything that has been published to date is “use at your own risk”.

That said – if we can figure out how to properly capture and persist the sensitivity tags of the consumer my perception is that the discloser who does so is not liable.  Of course this relies on the consumer being able to tag things themselves and have the literacy to do so without inadvertent consequences (their failing to recognize that a Prescription they didn’t mark as sensitive essentially tells literate users that they have a specific condition that the consumer didn’t want to disclose).  

I am not advocating that LOVs that help people set their preferences don’t have value.  I am asserting that such lists alone are insufficient and for their intended purpose.

Aaron  

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: John Moehrke [mailto:johnmoehrke at gmail.com] 
Sent: Saturday, March 25, 2017 2:31 PM
To: Aaron Seib
Cc: Nancy Lush; HEART List
Subject: Re: [Openid-specs-heart] HEART profiling for sensitive data

I agree with Aaron. However the problem is far bigger. The 'vectors' that are necessary to segment data for various purpose-of-use, and various roles; are many. That is to say sensitivity is not the only vector that is necessary. See https://healthcaresecprivacy.blogspot.com/2016/08/vectors-through-consent-to-control-big.html 

·        Data Identity - unique identifier of the data

·        Folder Identity this data sits within

·        When was the data created

·        When was the data last updated

·        Who authored the data

·        Who verified the data

·        Where was the data authored

·        Availability, has the data been replaced or refuted

·        What kind of treating facility authored the data

·        What kind of care practice setting authored the data

·        Predecessor data that was used in the authoring of this data (e.g. Order)

·        Successor data that was created based on this data (e.g. Discharge Summary)

·        Relationships to other data (e.g. folder identifier)

·        Type of data object

·        Type of clinical content implied by the data (e.g. Pregnant, Cancer, Addict)

·        etc

I will note that the struggle to automatically determine what data might be sensitive from what data might be normal healthdata is the topic of a 'service' in a specification from HL7. That is to note that regardless of the technical details, one really needs a service to carry out that labeling task in an automated way. That service might get the list of sensitive topics from a Healthcare organization, or might get them from the Patient; possibly both. This isolates the labeling from the Access Control decision and enforcement. -- Look for HL7 Security Labeling Service

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 Sat, Mar 25, 2017 at 10:33 AM, Aaron Seib <aaron.seib at nate-trust.org> wrote:

Nancy

At the end of the day I am of the opinion that relying on a coding scheme to identify what falls into a sensitive “category” and what doesn’t ends up being arbitrary and often dangerously imprecise.  

There is no way to apriori tag what any one consumer considers sensitive and what is considered sensitive by one consumer is not to another.  

In short – I am worried that if there isn’t a way for the consumer to mark what they are comfortable being shared any mechanism to make it “easy” for a data-holder to share with a third party while “respecting” the preferences of the consumer is insufficient and represents a legacy perspective.  

When we enable the consumer to tag their own data and constrain what is shared by the 3rd parties that disclose data “on their behalf” we don’t fall into the trap of trying to create one size fits all LOVs that are inaccurate and only reflect the requirements of a regulatory requirement established decades in the past.

We have to figure out how to enable the consumer to define what they want segmented if we are attempting to be respectful of the consumer’s preference.  We all know that these preferences change over time and the consumer should be able to update them.  

I believe data segmenation without the consumer’s ‘corrections’ leaves too many inaccuracies that inevitably result in disclosures not consistent with the individuals preferences.  

We can certainly create categories as an aid to building a consumer specific segmentation rules set but relying on pre-defined code sets to indicate what is sensitive (driven by legacy policies) will miss the mark.

Aaron

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311 <tel:(301)%20540-2311> 

(m) 301-326-6843 <tel:(301)%20326-6843> 

 <http://nate-trust.org> 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Nancy Lush
Sent: Friday, March 24, 2017 5:05 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] HEART profiling for sensitive data

Hello all,

Attached is a document which includes background and suggestions for profiling sensitive data.  Comments welcome. 

Thanks, and have a great weekend.

-Nancy

Nancy Lush          

nancy.lush at lgisoftware.com

Lush Group, Inc

Office: (401) 423-9111 <tel:(401)%20423-9111> 

28 Narragansett Ave

PO Box 651

www.lgisoftware.com 

Cell:(401) 965-9347 <tel:(401)%20965-9347> 

Jamestown, RI 02835

LGI_logo_small

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170325/2b440c9b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170325/2b440c9b/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170325/2b440c9b/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 3006 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170325/2b440c9b/attachment-0001.gif>