Bingo.  There is a lot to digest here.  Digesting.  http://hl7-fhir.github.io/consent.html. 


On Sun, Jul 17, 2016 at 4:20 PM, John Moehrke <johnmoehrke@gmail.com> wrote:
I hoped so, but waned to assure we were communicating.

I am actively working within a Healthcare standards organization (HL7) to develop a standard for capturing the details of a Privacy Consent.
  http://hl7-fhir.github.io/consent.html

I am co-chair of their security workgroup, and one of the leads on this effort.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke@gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Sun, Jul 17, 2016 at 3:03 PM, James Hazard <james.g.hazard@gmail.com> wrote:
John, 

Thanks.  I took a look at your blog posts and see there is a lot to this subject area. 

Yes, I understand that the type of record is orthogonal to its sensitivity.  A kind of information can be very sensitive in one circumstance and not sensitive at all in another.

I'm trying to tease apart the notion of things-that-might-be-confidential, operating on the assumption that the taxonomy must include nearly all kinds of records, conversations, observations and things.  

I'm approaching this from the perspective of agreements for non-disclosure, data transfer, services and the like, which can cover a broad range of subjects. To be really effective, they have to get to the same level of specificity as the underlying engagements with third-parties, including data subjects.

We (lawyers) tend to paint with broad brushes, e.g.: 

or 

The thought is that overly permissive and overly restrictive practices could be reduced by shared taxonomies, with a gain in legal certainty and ability to extend the benefit to the data subjects.

Eager for more. 

Jim
 


See my blog article 

On Sun, Jul 17, 2016 at 3:08 PM, John Moehrke <johnmoehrke@gmail.com> wrote:
Jim,

Be careful and aware that the way that Healthcare data are organized is by medical classification; and has very little to do with how sensitive the data are. Meaning the structure and organization is for the benefit of the healthcare treatment purpose, where few restrictions exist. This is why we have security-tags, so that we can analyze the content of an object looking for sensitive topics, from that discovery we tag the data. It is this tag that is used in access control and audit logging; not the type of data. For any object type it could be determined that the data are not sensitive, or are highly sensitive.

The other problem we have is that the data are about people, and those people have opinions on what they themselves consider sensitive.

In fact we (security and privacy experts in healthcare) tend to stay out of the business of 'determining' how sensitive data are. We prefer to leverage a service that does this for us. This service leverages all the power of "clinical decision support' -- think about IBM Watson class service. This service understands the current state of healthcare knowledge, and thus it can better determine that an object that has a medication is currently being prescribed for a condition that is currently considered sensitive.

See my blog article 
or

I do need to write a new article on this topic as I am getting much interest. I welcome the interest.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke@gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Sun, Jul 17, 2016 at 1:36 PM, James Hazard <james.g.hazard@gmail.com> wrote:
John,

Thanks very much.  ConfidentialityClassifications maps to what I (we lawyers?) think of as degree-of-care, access, disclosure.  From that I found massive list of kinds of records - http://hl7-fhir.github.io/valueset-doc-typecodes.html.  This is both i) just the kind of thing I need and ii) overwhelming.  A huge itemization, it reflects format and subject matter in a way that I presume corresponds well to how the people involved think about the records, rather than the kind of abstract categories that tend to get including in legal documents.

This is terrific. I'll play with the TypeCodes, and think about the ConfidentialityClassifications.

Eager for more such.  

Jim  

On Sun, Jul 17, 2016 at 2:11 PM, John Moehrke <johnmoehrke@gmail.com> wrote:
Hi James,

Here is the vocabulary in Healthcare. Some of it is well organized, most of it is (the sensitivity tags) are a bag of anything people have found useful as sensitivity topics.


The link is to the current specification for HL7 FHIR; a new effort to leverage general IT http RESTful concept. But the vocabulary is broadly used in historic protocols as well.


John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke@gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Sun, Jul 17, 2016 at 12:03 PM, James Hazard <james.g.hazard@gmail.com> wrote:
Very interested in following the discussion on the connections with IRM. 

Separately, can anyone point me to work on taxonomies of confidential information?  

Ideally, this taxonomy would be broad - for instance anything that might be specified in a non-disclosure agreement.  But domain-specific is also interesting, e.g. kinds of medical information, kinds of business info, kinds of know-how and tech, etc.  
I am working on a taxonomy for "included" or "excluded" confidential information under a templated NDA, and it would be nice to be more systematic in teasing out the different types than we lawyers usually are.  This taxonomy will intersect with the patient data taxonomy for a model consent.  

    

On Thu, Jul 14, 2016 at 12:25 PM, Thomas Hardjono <hardjono@mit.edu> wrote:

+1 .

Thorsten, could we have you describe some of this work at the BSC-DG call (next week, say).

/thomas/



________________________________________
From: dg-bsc-bounces@kantarainitiative.org [dg-bsc-bounces@kantarainitiative.org] on behalf of Scott Shorter [sshorter@kimbleassociates.com]
Sent: Thursday, July 14, 2016 11:51 AM
To: Eve Maler
Cc: Thorsten H. Niebuhr [WedaCon GmbH]; dg-bsc@kantarainitiative.org
Subject: Re: [DG-BSC] BSC and Identity Relationship Management

Hi all,

+1 to what Eve said.  I’ll feed the contents of the “potential links” column into the “potential use cases” hopper.

Thanks Thorsten!
-
Scott

Scott Shorter - Vice President, Security
sshorter@kimbleassociates.com<mailto:sshorter@kimbleassociates.com>

On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler@forgerock.com<mailto:eve.maler@forgerock.com>> wrote:

Hi Thorsten-- Apologies for a belated response to this. I've revised the subject line to be sure it catches people's attention.

This is a great analysis. I wonder if, as our use cases shape up, we could seek explicit input/review from your group, and also leverage the analysis in our final deliverable...


Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
ForgeRock Summits and UnSummits are coming to<http://summits.forgerock.com/> Sydney, London, and Paris!

On Tue, Jul 12, 2016 at 5:30 AM, Thorsten H. Niebuhr [WedaCon GmbH] <tniebuhr@wedacon.net<mailto:tniebuhr@wedacon.net>> wrote:
Hi @all

dont know if I manage to take part of the call.

Anyway: As already mentioned, I joined the DG because of the potential links between the BC/SC Topic and what we currently discuss in the WG-IRM (Identity Relationship Management). Here is a quick summary on the principles we are working on right now in that space and where BC/SC might play a role/ could help (from my pov).

For more on the IRM-WG, see <https://kantarainitiative.org/confluence/display/irm/Home> https://kantarainitiative.org/confluence/display/irm/Home

Principle       Description     Potential link into BC/SC       Link strength
Scalable        IRM aware systems must be able to scale into billions (internet of things)      BC/SC are not centralized       light
Actionable      A relationship must be able to 'do' something, or better: be able to transport the authorization to do something.       could use BC/SC data, but no real benefit here  light
Immutable       A relationship can be immutable (this thing was made by...)     This is definitly somehing where BC could help  medium
Contextual      A relationship must allow to be seen in a specific 'context' (time, place, predecessor, post...)

could use BC/SC data, but no real benefit here
        light

Transferable    A relationship can be transfered, permanently or temporary

This is definitly somehing where BC could help
        medium

Provable        relationships are provable, either by single, multi or third parties.   This is definitly somehing where BC could help  strong
Acknowledgable  a relationship between two or more must be able to be acknowledged (single ack, bi-directional,  majority,...)  This is definitly somehing where BC could help  strong
Revocable       A relationship can be revoked (linked to accknowledge), right to be forgotten   challenging. BC/CS could help on one side, but right to be forgotten is not among them....      medium
Constrainable   any relationship can be granted, revoked, build based on constraints (eg laws)  This is definitly somehing where BC could help  medium

cu later

Thorsten H. Niebuhr
tniebuhr@wedacon.net / tniebuhr@wedacon.de<mailto:tniebuhr@wedacon.net>

WedaCon Informationstechnologien GmbH
Office: +49 (251) 399 678-22<tel:%2B49%20%28251%29%20399%20678-22>
Fax: +49 (251) 399 678-50<tel:%2B49%20%28251%29%20399%20678-50>
Mobile: +49 (174) 991 257 4<tel:%2B49%20%28174%29%20991%20257%204>
Kroegerweg 29 D-48155 Muenster
http://www.wedacon.net<http://www.wedacon.net/>

Amtsgericht Muenster HRB 6115
USt.-ID: DE216758544
StNr.: 336/5775/1487
Geschaeftsfuehrender Gesellschafter: Thorsten H. Niebuhr




On 07.07.2016 17:27, Eve Maler wrote:
(end of message)

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756<tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
ForgeRock Summits and UnSummits are coming to<http://summits.forgerock.com/> Sydney, London, and Paris!



_______________________________________________
DG-BCC mailing list
DG-BCC@kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org>
http://kantarainitiative.org/mailman/listinfo/dg-BCc



_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org>
http://kantarainitiative.org/mailman/listinfo/dg-bsc
_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc



--
@commonaccord

_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc





--
@commonaccord




--
@commonaccord




--
@commonaccord