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

John Moehrke johnmoehrke at gmail.com
Sat Mar 25 22:38:41 UTC 2017


We standards geeks have tried to enable this. The best example is in FHIR
with a universal​ tag element available for this. Making that element
available for patients to adjust is a operational responsibility.

On Mar 25, 2017 2:12 PM, "Aaron Seib" <aaron.seib at nate-trust.org> wrote:

> 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 <(301)%20540-2311>
>
> (m) 301-326-6843 <(301)%20326-6843>
>
> <http://nate-trust.org>
>
>
>
> *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 <(920)%20564-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/0912f57a/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/0912f57a/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/0912f57a/attachment.jpg>
-------------- 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/0912f57a/attachment-0001.jpg>


More information about the Openid-specs-heart mailing list