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

Danny van Leeuwen danny at health-hats.com
Sat Mar 25 19:33:03 UTC 2017


I agree as well

On Sat, Mar 25, 2017 at 2:30 PM John Moehrke <johnmoehrke at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
-- 
Danny van Leeuwen
Danny at health-Hats.com
617-304-4681
Blog: www.health-hats.com
Twitter: @healthhats
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170325/cda8a8cd/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/cda8a8cd/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/cda8a8cd/attachment.jpg>


More information about the Openid-specs-heart mailing list