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

John Moehrke johnmoehrke at gmail.com
Sat Mar 25 18:30:52 UTC 2017


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 <(301)%20540-2311>
>
> (m) 301-326-6843 <(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
>
> 28 Narragansett Ave
>
> PO Box 651
>
> www.lgisoftware.com
>
> Cell:(401) 965-9347
>
> Jamestown, RI 02835
>
>
>
> [image: 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/8f9d541c/attachment.html>
-------------- 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/8f9d541c/attachment.gif>
-------------- 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/8f9d541c/attachment.jpg>


More information about the Openid-specs-heart mailing list