[Openid-specs-heart] "Scope" of sharing and purpose of use

Aaron Seib aaron.seib at nate-trust.org
Mon Dec 14 23:15:14 UTC 2015


    
Is any payer the same as any other payer?  Surely this is not always true but we can say the majority are similar.  
I think it is appropriate to leave research for later as the clinical and financial considerations may be modified versions of many use cases.  All fall under the umbrella of Analysis in the sense of figuring out what works at a population level and calculating acceptable performance ranges.  
The question is what payment info does a doc need to do good by his patients? Does he have access to it and can he talk accurately about the cost to the consumer to help her make a decision that is right for her.


Aaron Seib at CaptBlueButton
(O) 301-540-9549(M) 301-326-6843
"The trick to earning trust is to avoid all tricks.  Including tricks on yourself."


-------- Original message --------
From: "Glen Marshall [SRS]" <gfm at securityrs.com> 
Date: 2015/12/14  4:57 PM  (GMT-05:00) 
To: Aaron Seib <aaron.seib at nate-trust.org>, openid-specs-heart at lists.openid.net 
Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use 


    Aaron,

    

    I have not problem adding "payer", which would include all of the
    revenue-cycle actors who author and share data with each other on
    behalf of a payee -- provider or health consumer.  Outside of   
    electronic access control's scope they may have legal, contractual, 
    or policy-based restrictions on authorship and sharing.  Some, but
    not all, of those restrictions may be automated as access controls. 
    For analysis sake, any payer is the same as any other payer.  This
    includes things like primary and secondary insurance who coordinate
    benefits, and intermediate billing/collection services that some
    providers use.  

    

    I like simplicity.  The distinctions created by various sorts of
    laws, regulations, contracts, etc. are out of scope for payers
    relative to the HEART discussions.  

    

    FWIW, I left the research leg out for now.  I think it could be a
    policy-defined special case within provider.  But the access to a
    single consumer versus bulk access to multiple health consumers may
    be a differentiator.  Same/same for payers who reimburse for a
    patient population rather than single health consumers.  

    

    
      Glen F. Marshall

        Consultant

        Security Risk Solutions, Inc.

        698 Fishermans Bend

        Mount Pleasant, SC 29464

        Tel: (610) 644-2452

        Mobile: (610) 613-3084

        gfm at securityrs.com

        www.SecurityRiskSolutions.com
    
    On 12/14/15 16:33, Aaron Seib wrote:

    
    
          
That would be amazing.
The only add I think is important to consider is adding an actor called Payer.  More and more the lines that differentiate a.Payer from a Provider and a Payer from a Consumer.have.blurred but if we can work in that third leg there may be more evident ways to incorporate business cases as part of the analysis.
I am not alone in thinking we'd be further along with clinical interop if we hadn't artificially segregated administration Dara for some reason about a decade ago.


Aaron Seib at CaptBlueButton
(O) 301-540-9549(M) 301-326-6843
"The trick to earning trust is to avoid all tricks.  Including tricks on yourself."


-------- Original message --------
From: "Glen Marshall [SRS]" <gfm at securityrs.com> 
Date: 2015/12/14  4:04 PM  (GMT-05:00) 
To: openid-specs-heart at lists.openid.net 
Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use 


    Somehow this thread has confused me.  It may be only a temporary
    lapse, but I'd like to re-wrap my head around some actors and the
    sort of access rights they have:

    
      Providers - Am I correct in saying this category includes
      
        Health institutions - hospitals, ambulatory clinics, skilled
          nursing facilities, physical rehab, substance abuse rehab,
          long-term care, etc. 

        
        Professional practitioners, e.g., physicians, PAs, NPs, RNs,
          LPNs, dentists, podiatrists, chiropractors, licensed massage
          therapists, non-Western medicine modalities
        Employees and business associates of the above, authorized
          to act on their behalf in role- or contract-limited ways.
      
      Health consumers
      
        Patients
        Authorized representatives of patients - relatives or others
          who have been granted authorities of various sorts.    

        
      
    
    

    For simplicity's sake, I would like to assume that the providers
    category has the general ability to author and share health data
    with each other on behalf of multiple health consumers.  Outside of
    electronic access control's scope they may have legal, contractual,
    or policy-based restrictions on authorship and sharing.  Some, but
    not all, of those restrictions may be automated as access controls. 
    For analysis sake, any provider is the same as any other provider.

    

    Also for simplicity's sake, I would like to assume that health
    consumers have the general equal ability to author and share data
    with providers on behalf of a single patient.  Outside of electronic
    access control's scope they may have legal, contractual, or
    policy-based restrictions on authorship and sharing.  Some, but not
    all, of those restrictions may be automated as access controls.  For
    analysis sake, any health consumer is the same as any other health
    consumer.

    

    Simplicity includes not trying to automate all restrictions.  It
    also means we can overlook most granularities within the actor types
    unless law or regulation requires a differentiation, e.g., as in
    psychiatric notes or substance-abuse treatment.

    

    For the providers, I'd like to assume that their dominant
    requirement for data access is treatment, payment, or operation with
    a guarantee of high availability and integrity.

    

    For the health consumers, I assume that their dominant requirement
    is providers having and using adequate knowledge of their health. 
    Their secondary requirement is confidentiality.

    

    Privacy is a policy-level concept that is supported by security
    controls - technical, administrative, physical, and environmental.

    

    Can we publish a map fir the above vocabulary to the terminology
    used by cross-industry concepts under discussion?    

    

    
      Glen F. Marshall

        Consultant

        Security Risk Solutions, Inc.

        698 Fishermans Bend

        Mount Pleasant, SC 29464

        Tel: (610) 644-2452

        Mobile: (610) 613-3084

        gfm at securityrs.com

        www.SecurityRiskSolutions.com
    
    On 12/14/15 12:10, Aaron Seib wrote:

    
    
      
      
      
      <!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:932512138;
	mso-list-type:hybrid;
	mso-list-template-ids:-2062537032 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"\(%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:1.5in;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:2.0in;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:2.5in;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:3.0in;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:3.5in;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:4.0in;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:4.5in;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:5.0in;
	text-indent:-9.0pt;}
@list l1
	{mso-list-id:1833597363;
	mso-list-type:hybrid;
	mso-list-template-ids:-1192981228 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-text:"\(%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l1:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l1:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
      
        Getting
            closer to understanding…
         
        
          Aaron
              Seib, CEO
          @CaptBlueButton
              
           (o)
              301-540-2311
          (m)
              301-326-6843
          
        
         
        
          
            From:
                Justin Richer [mailto:jricher at mit.edu] 

                Sent: Monday, December 14, 2015 11:23 AM

                To: Aaron Seib

                Cc: Adrian Gropper;
                openid-specs-heart at lists.openid.net

                Subject: Re: [Openid-specs-heart] "Scope" of
                sharing and purpose of use
          
        
         
        “Permission Type” is really a whole lot
          simpler than people are making it out to be. 
        
           
        
        
           
        
        
          “patient” means “get me a single specific
            record for a single specific person”. When there is no other
            indicator (the “aud” parameter) this is the record for the
            currently logged in person. This is going to be a common
            enough use case, and it’s the default OAuth case, that
            optimizing for this makes sense. 
        
        
           
        
        
          “user” means “get me all of the records
            that I have access to”. There is no record indicator here in
            the query because it’s basically a get-all-the-stuff type of
            request. What matches might be a single record. It might be
            many records. It might be aggregate data. But it’s not a
            query for a specific record when this permission type is
            used.
        
        
           
        
        
          Both of these can be in cases where Alice
            has user-to-user delegated access (her little sister Joanne has
              granted her access to her records at Regional Hospital
              where they both had their babies) to her family
            members. For the “patient” scope with no “aud” parameter,
            the token is good for Alice’s record. For the “patient”
            scope with an “aud” parameter, the token is good for the
            record indicated by that aud parameter. But just that one
            specific record! Using this token to get other records will
            fail. For the “user” scope it’s a request for all records
            Alice has access to. She can’t specify which one, since
            that’s not what this kind of scope is for.
           
          I
              think that is clear.  I think where the consternation
              comes from is when the User isn’t a consumer but a list of
              people who have claimed TPO access rights to a set of
              records (patients).  Is the Heart Profile silent on that. 
              This is where the policy gets confounded if each of the
              patients doesn’t have the chance to first “recognize” that
              the person who claims to have a Tx relationship with them
              is in fact a doc that they believe they have a treatment
              relationship with.  This is the fly in the ointment that
              has Serpico buzzing and I think rightly so.  Not that we
              have to address the issue that he described as Discovery
              for the HEART work to make progress and sense – it just
              needs to be clearly isolated.
           
          The
              bottom line is there are creative trial lawyers who will
              ascert that a breach occurred is some Provider was claimed
              to have had a Treatment relationship with someone when in
              fact they didn’t.  Perhaps Permission Type is too simple
              if it can’t address this concern.  That or make it easy
              enough for us to demarcate the breadth of where it comes
              into play and put it in a parking lot for a future need.
           
          This
              is a real case we had at the state level.  Male Doc is
              working in a practice.  He has access to the EMR that
              every other doc in his practice has access to so could see
              the data of all the patients that went there.  Turns out
              the Husband of the woman he is committing adultery with
              was a patient of another doc at the practice.  This guy is
              a father and has two kids.  Husband and Wife split up. 
              Doc and woman get married and want to get custody of the
              kids.  Doc looks at ex-husbands medical records and finds
              some sensitive information that the new couples lawyers
              use to argue that the dad isn’t a fit parent.  Fortunately
              – the father’s lawyer figures it out and puts the keibash
              on using that breached data and the Judge makes his
              custody decision sans the sensitive health information
              that shouldn’t be available (and later in another court
              room the doc gets convicted of a HIPAA violation).
           
          The
              concern that we are all twisting around seems to be the
              lack of distinction about the permission types.  Maybe
              there is a way to clarify it using another construct that
              I haven’t come up with.  Is this kind of concern addressed
              somewhere else?
        
        
           
        
        
           
        
        
           — Justin
        
        
           
        
        
           
          
            
              
                On Dec 13, 2015, at 11:10 PM, Aaron
                  Seib <aaron.seib at nate-trust.org>
                  wrote:
              
               
              
                
                  
                    I
                          still don’t think I am 100% on what Discovery
                          means in this context.
                  
                  
                     
                  
                  
                    Here
                        is the def you provided:
                  
                  
                     
                  
                  Discovery
                    means: the user(1) doesn't know who will
                    be on the list. That puts a lot of responsibility on
                    the RS to do the right thing(2).
                    In HIEs for example, they insist the user is a
                    practicing physician because they want to reduce
                    their liability if someone's name pops up on a list
                    that the user should not have seen.
                  
                     
                  
                  (1)  Who
                      is the user?  I am still looking to the
                        Permission Type
                      to see if I can get that set of terms to line up
                      in my head.  Patient was a permission type which
                      in the health domain correlates to the patient who
                      is the subject of the PHI that the Resource Server
                      may be disclosing.  The assumption being that we
                      can match the identity of the person who is using
                      a client application to connect to the resource
                      server  (owned by the institution that operates
                      the Resource Server – in the API TF scope the
                      typical example being a EMR used by the caregiver
                      that the patient has had treatment) with the
                      Medical Record Number (MRN) or equivalent in the
                      Resource Servers enterprise context (I don’t see
                      any reason why we can’t say that an HIE with an
                      MPI might be able to simplify this by correlating
                      the MPI values to the person who is using the
                      client app to access data about themselves across
                      Resource Servers that have data about that person
                      “Patient”).
                  (2)  Do
                      the Right Thing - 
                  
                     
                  
                  
                    Sorry
                        for all the verbiage – I want to get my meager
                        understanding spelt out so it can be corrected. 
                        This may not be fruitful but it occurs to me
                        that something that isn’t apparent that is
                        becoming more apparent to me as I wrestle with
                        this is that the idea of User may be better
                        understood as a set of several or more
                        sub-categories.
                  
                  user
                  The scope is for a bulk set of records (I
                        am assuming that it is implied here that set of
                        records is meant to convey data for more than
                        one person – the notion of a record is not clear
                        to me here I must admit)  or for aggregate
                      data not representing a single patient (is
                        this meant to be a distinction or a reiteration
                        of the bulk set of records?  What is the
                        difference?), based on what is available to
                        the current user (here is where the turn
                        of phrase seems to be slipping.  I am still
                        struggling with the some notion being conveyed
                        here. 
                   
                  The question that comes to mind is if we
                      look at the set of records being made available
                      ‘to the current user’ is that person’s record one
                      of those found in the set of records?  There seem
                      to be a couple of distinctions that are probably
                      implied but might help to make explicit.  At a
                      minimum there are two cases that come to mind:
                  (1)  The case where the ‘Current User’ may
                      have a record in the set being returned and any
                      other person’s record being disclosed is permitted
                      because that other person granted the User
                      permission.
                  (2)  The case where the ‘Current User’ does
                      not have a record in the current set and is
                      accessing them as a result of capacity being
                      vested in them by the Record owner, because of
                      their professional role.
                   
                  I am not sure if there is a more precise
                      way to look at it but it would seem to be that the
                      root difference has something to do with how the
                      User got the permission.  It may not be evident I
                      am seeing the difference being based on how the
                      user got the permission.  In case (1) I think of
                      the person as a family care giver who has access
                      to other ‘family’ members records because they
                      granted that to him\her to have access and it is
                      not in the role of providing treatment as
                      traditionally defined by HIPAA.  In the (2) case I
                      see it being derived based on the fact that the
                      person is in a Treatment role as defined by HIPAA
                      and the Record Owner (i.e., the Hospital et al)
                      gives them permission to access certain records.
                   
                  I think the key to unraveling this not
                      is to differentiate between users who are not
                      acting in a professional capacity from those that
                      are as the applicable authorization to disclose is
                      derived from two separate authorities.  In Case
                      (1) the User is getting permission to access those
                      other records because the patients whom the
                      records are about gave him\her permision as they
                      may given their right to share with whomever they
                      please while under case (2) they are getting
                      permission as an aspect of their professional
                      requirements as warranted by the resource owner.
                   
                  Not sure if this is half baked or not
                      but there if there is a fly in the ointment it
                      seems to me that it has to do with what John
                      referred to as purpose of use earlier on.  Assume
                      that the User in case 2 has a purpose of use to be
                      treatment and I think it is easier to digest.  The
                      word to use for the Consumer’s purpose of use
                      alludes me right now.  
                   
                  I think the unifying issue is that the
                      user’s purpose of use must be the same for all the
                      records being retrieved.  
                   
                  I think that is the issue with Discovery
                      that is hard to get a grasp on.  
                   
                  If an HIE is granting permission to a
                      Requesting party (why do we use the word User
                      rather then requeting party here?) for a set of
                      records it should only be for one or the other
                      purpose of use and the purpose of use must match
                      the part being played for the transaction being
                      responded to by the RS as known to the RO.  
                  
                     
                  
                  
                    Aaron
                        Seib
                  
                  
                    NATE,
                        CEO
                  
                  
                    @CaptBlueButton
                  
                  
                    (o)
                        301-540-2311
                  
                  
                    (m)
                        301-326-6843
                  
                  
                     
                  
                  
                     
                  
                  
                    From:
                        agropper at gmail.com
                        [mailto:agropper at gmail.com]
                        On Behalf Of Adrian Gropper

                        Sent: Friday, December 11, 2015 5:29 PM

                        To: Aaron Seib

                        Cc: openid-specs-heart at lists.openid.net

                        Subject: Re: [Openid-specs-heart] "Scope"
                        of sharing and purpose of use
                  
                  
                     
                  
                  
                    
                      
                        Hi Aaron, Thanks
                          for highlighting the important issue of
                          discovery.

                          

                          Discovery means: the user doesn't know who
                          will be on the list. That puts a lot of
                          responsibility on the RS to do the right
                          thing. In HIEs for example, they insist the
                          user is a practicing physician because they
                          want to reduce their liability if someone's
                          name pops up on a list that the user should
                          not have seen.

                          

                          I meant RO (resource owner), It makes no sense
                          for the RS to send a notice to themselves.
                      
                      Yes,
                        RqP is the Requesting Party which is the party
                        that controls the Client that is accessing the
                        AS and the RS. The RqP might be the patient
                        subject (the RO) themselves using an app or PHR
                        but that case would be handled by OAuth. (We
                        call that the Alice-to-Alice case). UMA is
                        interesting because it allows the RqP user to be
                        someone other than Alice therefore enabling true
                        health information exchange. This is what makes
                        HEART so useful and our HEART Profiles so
                        important.
                    
                    
                      Adrian
                    
                  
                  
                    
                       
                    
                    
                      
                        On Fri, Dec 11, 2015 at
                          4:53 PM, Aaron Seib <aaron.seib at nate-trust.org>
                          wrote:
                      
                      
                        
                          Hi
                              – I meant to ask you last week.  When you
                              say Discovery in the first bullet I am not
                              sure I know what you mean.  Can you expand
                              on that for me?  I think I get everything
                              except that below.
                           
                          I
                              don’t know why we are trying to be so
                              cryptic on the work group.  This is
                              unfortunate.  
                           
                          You
                              use RO below and I think it might be a
                              typo but have to confirm.  Is it meant to
                              have been something else?
                           
                          What
                              is RqP an abbreviation of? Requesting
                              Party?
                           
                          From:
                              Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net]
                              On Behalf Of Adrian Gropper

                              Sent: Friday, December 11, 2015
                              3:37 PM

                              To: Moehrke, John (GE Healthcare)

                              Cc: openid-specs-heart at lists.openid.net

                              Subject: Re: [Openid-specs-heart]
                              "Scope" of sharing and purpose of use
                           
                          
                            
                              Let
                                me attempt at mediation :-)
                            
                            
                              -
                                We're talking about resources that have
                                a single subject (the patient) Resources
                                with more than one subject, such as a
                                patient list are a completely different
                                matter because
                                  they involve discovery (I don’t get
                                  this?  Discovery of what?  The
                                  identity of each person in the list?).
                                The special case of a mom with 2 kids
                                can simply, if inelegantly, be handled
                                by polling for each of the subjects.
                                There's no discovery involved.
                            
                            
                              -
                                The major difference between OAuth and
                                UMA is that in UMA the resource is under
                                the control of a separate legal entity.
                                Therefore, when a client (and the
                                client's user) shows up to request the
                                resource, the client may present claims
                                or attributes to either or both the
                                resource server (RS) and/or the
                                authorization server (AS). To say this
                                another way: In UMA there's some kind of
                                legal agreement between the resource
                                server and the authorization server. In
                                OAuth there is none because they are the
                                same.
                            
                            
                              -
                                The sharing of control between the RS
                                and the AS is subject to institutional,
                                local, and federal controls. All of the
                                situations that John listed boil down to
                                "good faith" and "notice" to the RO
                                when the resource server acts on the
                                instructions of the AS based on the
                                actual attributes of the client (C) by client
                                    attributes do you mean attributes of
                                    MSHV or of the User of MSHV, Aaron
                                    Seib? and the client's
                                user (RqP –
                                  this is Aaron Seib, right?  What does
                                  RqP stand for?).
                            
                            
                              Adrian
                            
                          
                          
                            
                              
                                 
                                
                                  On
                                    Fri, Dec 11, 2015 at 3:01 PM,
                                    Moehrke, John (GE Healthcare) <John.Moehrke at med.ge.com>
                                    wrote:
                                  
                                    
                                      Hi
                                          Eve,
                                       
                                      It
                                          is clear that there is a
                                          communications problem between
                                          those that  are comfortable in
                                          the language of speaking about
                                          OAuth/UMA, and those that are
                                          comfortable in the language of
                                          speaking about Healthcare
                                          Access Control needs.  I can
                                          read every word you have said,
                                          but I have no idea what you
                                          said.
                                       
                                      I
                                          think one of our problems is
                                          that we keep skipping from
                                          use-cases where the “user” is
                                          the “patient” trying to access
                                          their own data; and use-cases
                                          where the “user” is a
                                          clinician trying to help the
                                          “patient”. There are many MORE
                                          use-cases including parents,
                                          children, guardians. There are
                                          many MORE use-cases around
                                          researchers, public-health,
                                          billing, payers. And there are
                                          a huge variety of all of
                                          these. There are authorization
                                          mechanisms that stem from
                                          direct authorization by the
                                          patient, to indirect because
                                          of context, and the ultimate
                                          for healthcare ‘because their
                                          life is in jeopardy and I am a
                                          licensed clinician that can
                                          save their life’. Followed by
                                          many medical-ethical traps
                                          like having a personal
                                          discussion about a
                                          particularly tragic test
                                          result before the lab fact is
                                          directly exposed.
                                       
                                      We
                                          need to solve all of these,
                                          however to solve any one would
                                          be helpful.
                                       
                                      John
                                       
                                      From:
                                          Eve Maler [mailto:eve.maler at forgerock.com]
                                          

                                          Sent: Friday, December
                                          11, 2015 11:43 AM

                                          To: Moehrke, John (GE
                                          Healthcare)

                                          Cc: openid-specs-heart at lists.openid.net

                                          Subject: "Scope" of
                                          sharing and purpose of use
                                      
                                        
                                           
                                          
                                            Hi
                                              John-- (I changed the
                                              subject line and deleted
                                              older parts of the
                                              thread.)
                                            
                                               
                                            
                                            
                                              When
                                                you say "scope" here, I
                                                suspect you mean "scope"
                                                of the sharing use case,
                                                rather than something
                                                like an OAuth or UMA
                                                scope, so I'm just
                                                checking. So a
                                                "single-patient scope"
                                                means that the only
                                                human we're paying
                                                attention to in the use
                                                case is the patient, and
                                                "any application with
                                                users that are
                                                authorized to multiple
                                                patients" seems to mean
                                                a use case that involves
                                                party-to-party sharing,
                                                with multiple humans
                                                involved. However, you
                                                follow the latter with
                                                "would need to get
                                                multiple scopes", so I'm
                                                not sure. Note that
                                                "getting multiple
                                                scopes" as a technical
                                                construct doesn't have
                                                anything to do with
                                                sharing with an
                                                autonomous third party.
                                            
                                            
                                               
                                            
                                            
                                              FWIW,
                                                here is how I think, at
                                                a high level, about configuring
                                                  the delegation of
                                                  rights to access
                                                  resources. It's
                                                all about parts of
                                                  speech.
                                            
                                            
                                               
                                            
                                            
                                              OAuth
                                                lets a user (patient) do
                                                this configuration at
                                                run time while using a
                                                client app, by opting in
                                                to the authorization
                                                server's issuance of an
                                                access token to that
                                                app. By contrast, UMA
                                                lets a user (patient) do
                                                this configuration
                                                anytime, generally by
                                                instructing the
                                                authorization server to
                                                check whether some
                                                combination of the
                                                client app and the
                                                requesting party using
                                                the app meet various
                                                requirements (policy).
                                                So OAuth is kind of an
                                                attenuated version of
                                                UMA wrt the constraints
                                                on delegation of access
                                                rights.
                                            
                                            
                                               
                                            
                                            
                                              system    
                                                       subject        
                                                   verb            
                                                  object              
                                                   adjective
                                            
                                            
                                              OAuth      
                                                           client ID    
                                                          OAuth scopes  
                                                         (implicitly
                                                  some endpoints)  n/a
                                            
                                            
                                                         
                                                           (and always
                                                  Alice)
                                            
                                            
                                              UMA        
                                                           claims-based
                                                  eg Bob,  UMA scopes
                                                  over...    UMA
                                                  resource sets        
                                                     claims-based e.g.
                                                  TPO,
                                            
                                            
                                                         
                                                           client
                                                  ID/type, etc.        
                                                                       
                                                                       
                                                  time limitations, etc.
                                            
                                            
                                               
                                            
                                            
                                              It's
                                                possible to conflate
                                                purpose-of-use into the
                                                UMA scopes system, but
                                                it's as awkward as
                                                conflating (ordinarily
                                                implicit) resource sets
                                                into the OAuth scopes
                                                system (resource1.read,
                                                resource1.write, etc.),
                                                which is why OAuth has
                                                invented the audience
                                                parameter to try and
                                                solve the problem of a
                                                single authorization
                                                server protecting
                                                several APIs. This is
                                                why I suggest using a
                                                claims-based system
                                                above.
                                            
                                            
                                              
                                                
                                                  
                                                    
                                                      
                                                        
                                                          Eve
                                                          Maler

                                                          ForgeRock
                                                          Office of the
                                                          CTO | VP
                                                          Innovation
                                                          & Emerging
                                                          Technology

                                                          Cell +1 425.345.6756 |
                                                          Skype: xmlgrrl
                                                          | Twitter:
                                                          @xmlgrrl

                                                          Join our ForgeRock.org OpenUMA community!
                                                        
                                                      
                                                    
                                                  
                                                
                                              
                                               
                                              
                                                On
                                                  Mon, Dec 7, 2015 at
                                                  2:00 PM, Moehrke, John
                                                  (GE Healthcare) <John.Moehrke at med.ge.com>
                                                  wrote:
                                                
                                                  
                                                    The
                                                        discussion on
                                                        the call today
                                                        was too hard to
                                                        break into. Even
                                                        for a big mouth
                                                        like me.
                                                     
                                                    I
                                                        am okay with
                                                        limiting our
                                                        next couple of
                                                        profiles to
                                                        single patient
                                                        scopes. As much
                                                        of the email
                                                        discussion has
                                                        pointed out
                                                        patient
                                                        controlled
                                                        access is our
                                                        primary scope,
                                                        and logically
                                                        (if not 
                                                        technically)
                                                        this  is easy to
                                                        understand with
                                                        scopes that are
                                                        single patient.
                                                      
                                                     
                                                    Yes
                                                        this means that
                                                        any application
                                                        with users that
                                                        are authorized
                                                        to multiple
                                                        patients would
                                                        need to get
                                                        multiple scopes;
                                                        so be it. For
                                                        now…  For
                                                        Enterprise use,
                                                        this is
                                                        troubling; but
                                                        for most uses
                                                        that happen from
                                                        outside of an
                                                        enterprise or
                                                        between
                                                        enterprises this
                                                        limitation is
                                                        not
                                                        unreasonable.
                                                        The most common
                                                        APIs in
                                                        healthcare for
                                                        this are already
                                                        patient centric.
                                                        So it is not a
                                                        big problem.
                                                     
                                                    The
                                                        user experience
                                                        does not need to
                                                        be impacted by
                                                        this profiled
                                                        limitation
                                                     
                                                    The
                                                        future does not
                                                        need to be
                                                        impacted by this
                                                        profiled
                                                        limitation.
                                                     
                                                    Which
                                                        means that one
                                                        viewpoint for
                                                        scope can be the
                                                        identity of the
                                                        patient that one
                                                        is asking for
                                                        access to. This
                                                        is not the only
                                                        scope we will
                                                        ever support;
                                                        but is one
                                                        method that
                                                        would satisfy
                                                        some use-cases
                                                        today.
                                                     
                                                    Another
                                                        view on scope,
                                                        that I have been
                                                        involved with in
                                                        other groups, is
                                                        to use a
                                                        high-level
                                                        vocabulary that
                                                        is used often in
                                                        the Access
                                                        Control policy –
                                                        PurposeOfUse.
                                                        This vocabulary
                                                        is items like:
                                                        Treatment,
                                                        Payment,
                                                        Research,
                                                        Emergency, etc…
                                                     
                                                    To
                                                        go deeper than
                                                        these two
                                                        vectors through
                                                        scopes in a
                                                        general purpose
                                                        healthcare
                                                        access control
                                                        infrastructure
                                                        is futile.
                                                    Next
                                                        level deeper in
                                                        scopes would
                                                        come from
                                                        workflow centric
                                                        implementation
                                                        guides. That is
                                                        a specification
                                                        that is defining
                                                        a workflow,
                                                        could define a
                                                        scope(s) for
                                                        that workflow.
                                                     
                                                    John
                                                     
                                                  
                                                
                                                _______________________________________________

                                                  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
                                
                                

                                  

                                  

                                  -- 
                                
                                  
                                    
                                      
                                        
                                          
                                            
                                               
                                              
                                                Adrian
                                                  Gropper MD

                                                  

                                                  PROTECT
                                                    YOUR FUTURE -
                                                    RESTORE Health
                                                    Privacy!

                                                    HELP us fight for
                                                    the right to control
                                                    personal health
                                                    data.

                                                    DONATE: http://patientprivacyrights.org/donate-2/
                                                  
                                              
                                            
                                          
                                        
                                      
                                    
                                  
                                
                              
                            
                          
                          
                            
                          No
                            virus found in this message.

                            Checked by AVG - www.avg.com

                            Version: 2016.0.7294 / Virus Database:
                            4483/11158 - Release Date: 12/11/15
                        
                      
                    
                    
                      

                        

                        

                        -- 
                    
                    
                      
                        
                          
                            
                              
                                
                                  
                                     
                                  
                                  
                                    
                                      Adrian
                                        Gropper MD

                                        

                                        PROTECT
                                          YOUR FUTURE - RESTORE Health
                                          Privacy!

                                          HELP us fight for the right to
                                          control personal health data.

                                          DONATE: http://patientprivacyrights.org/donate-2/
                                        
                                    
                                  
                                
                              
                            
                          
                        
                      
                    
                  
                
                _______________________________________________

                  Openid-specs-heart mailing list

                  Openid-specs-heart at lists.openid.net

                  http://lists.openid.net/mailman/listinfo/openid-specs-heart
              
            
          
           
        
        
          
        No
          virus found in this message.

          Checked by AVG - www.avg.com

          Version: 2016.0.7294 / Virus Database: 4483/11177 - Release
          Date: 12/14/15
      
      

      
      

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

    
    

  
      

      
      

      
      That would be amazing.
      

      
      The only add I think is important to consider is adding an
        actor called Payer.  More and more the lines that differentiate
        a.Payer from a Provider and a Payer from a Consumer.have.blurred
        but if we can work in that third leg there may be more evident
        ways to incorporate business cases as part of the analysis.
      

      
      I am not alone in thinking we'd be further along with
        clinical interop if we hadn't artificially segregated
        administration Dara for some reason about a decade ago.
      

      
      

      
      

      
      Aaron
          Seib
        @CaptBlueButton

          
          (O)
              301-540-9549
          (M)
              301-326-6843
          

            
          "The
              trick to earning trust is to avoid all tricks.  Including
              tricks on yourself."
          

          
        
      
      

      

      -------- Original message --------

      From: "Glen Marshall [SRS]" <gfm at securityrs.com> 

      Date: 2015/12/14 4:04 PM (GMT-05:00) 

      To: openid-specs-heart at lists.openid.net 

      Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose
      of use 

      

      Somehow this thread has confused me.  It may be only a temporary
      lapse, but I'd like to re-wrap my head around some actors and the
      sort of access rights they have:

      
        Providers - Am I correct in saying this category includes
        
          Health institutions - hospitals, ambulatory clinics,
            skilled nursing facilities, physical rehab, substance abuse
            rehab, long-term care, etc. 

          
          Professional practitioners, e.g., physicians, PAs, NPs,
            RNs, LPNs, dentists, podiatrists, chiropractors, licensed
            massage therapists, non-Western medicine modalities
          Employees and business associates of the above, authorized
            to act on their behalf in role- or contract-limited ways.
        
        Health consumers
        
          Patients
          Authorized representatives of patients - relatives or
            others who have been granted authorities of various sorts. 
              

          
        
      
      

      For simplicity's sake, I would like to assume that the providers
      category has the general ability to author and share health data
      with each other on behalf of multiple health consumers.  Outside
      of electronic access control's scope they may have legal,
      contractual, or policy-based restrictions on authorship and
      sharing.  Some, but not all, of those restrictions may be
      automated as access controls.  For analysis sake, any provider is
      the same as any other provider.

      

      Also for simplicity's sake, I would like to assume that health
      consumers have the general equal ability to author and share data
      with providers on behalf of a single patient.  Outside of
      electronic access control's scope they may have legal,
      contractual, or policy-based restrictions on authorship and
      sharing.  Some, but not all, of those restrictions may be
      automated as access controls.  For analysis sake, any health
      consumer is the same as any other health consumer.

      

      Simplicity includes not trying to automate all restrictions.  It
      also means we can overlook most granularities within the actor
      types unless law or regulation requires a differentiation, e.g.,
      as in psychiatric notes or substance-abuse treatment.

      

      For the providers, I'd like to assume that their dominant
      requirement for data access is treatment, payment, or operation
      with a guarantee of high availability and integrity.

      

      For the health consumers, I assume that their dominant requirement
      is providers having and using adequate knowledge of their health. 
      Their secondary requirement is confidentiality.

      

      Privacy is a policy-level concept that is supported by security
      controls - technical, administrative, physical, and environmental.

      

      Can we publish a map fir the above vocabulary to the terminology
      used by cross-industry concepts under discussion?    

      

      
        Glen F. Marshall

          Consultant

          Security Risk Solutions, Inc.

          698 Fishermans Bend

          Mount Pleasant, SC 29464

          Tel: (610) 644-2452

          Mobile: (610) 613-3084

          gfm at securityrs.com

          www.SecurityRiskSolutions.com
      
      On 12/14/15 12:10, Aaron Seib wrote:

      
      
        
        
        <!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:932512138;
	mso-list-type:hybrid;
	mso-list-template-ids:-2062537032 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"\(%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:1.5in;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:2.0in;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:2.5in;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:3.0in;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:3.5in;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:4.0in;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:4.5in;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:5.0in;
	text-indent:-9.0pt;}
@list l1
	{mso-list-id:1833597363;
	mso-list-type:hybrid;
	mso-list-template-ids:-1192981228 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-text:"\(%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l1:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l1:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
        
          Getting

              closer to understanding…
           
          
            Aaron

                Seib, CEO
            @CaptBlueButton

                
             (o)

                301-540-2311
            (m)

                301-326-6843
            
          
           
          
            
              From:
                  Justin Richer [mailto:jricher at mit.edu]
                  

                  Sent: Monday, December 14, 2015 11:23 AM

                  To: Aaron Seib

                  Cc: Adrian Gropper; openid-specs-heart at lists.openid.net

                  Subject: Re: [Openid-specs-heart] "Scope" of
                  sharing and purpose of use
            
          
           
          “Permission Type” is really a whole lot
            simpler than people are making it out to be. 
          
             
          
          
             
          
          
            “patient” means “get me a single
              specific record for a single specific person”. When there
              is no other indicator (the “aud” parameter) this is the
              record for the currently logged in person. This is going
              to be a common enough use case, and it’s the default OAuth
              case, that optimizing for this makes sense. 
          
          
             
          
          
            “user” means “get me all of the records
              that I have access to”. There is no record indicator here
              in the query because it’s basically a get-all-the-stuff
              type of request. What matches might be a single record. It
              might be many records. It might be aggregate data. But
              it’s not a query for a specific record when this
              permission type is used.
          
          
             
          
          
            Both of these can be in cases where
              Alice has user-to-user delegated access (her little sister Joanne has
                granted her access to her records at Regional Hospital
                where they both had their babies) to her family
              members. For the “patient” scope with no “aud” parameter,
              the token is good for Alice’s record. For the “patient”
              scope with an “aud” parameter, the token is good for the
              record indicated by that aud parameter. But just that one
              specific record! Using this token to get other records
              will fail. For the “user” scope it’s a request for all
              records Alice has access to. She can’t specify which one,
              since that’s not what this kind of scope is for.
             
            I
                think that is clear.  I think where the consternation
                comes from is when the User isn’t a consumer but a list
                of people who have claimed TPO access rights to a set of
                records (patients).  Is the Heart Profile silent on
                that.  This is where the policy gets confounded if each
                of the patients doesn’t have the chance to first
                “recognize” that the person who claims to have a Tx
                relationship with them is in fact a doc that they
                believe they have a treatment relationship with.  This
                is the fly in the ointment that has Serpico buzzing and
                I think rightly so.  Not that we have to address the
                issue that he described as Discovery for the HEART work
                to make progress and sense – it just needs to be clearly
                isolated.
             
            The

                bottom line is there are creative trial lawyers who will
                ascert that a breach occurred is some Provider was
                claimed to have had a Treatment relationship with
                someone when in fact they didn’t.  Perhaps Permission
                Type is too simple if it can’t address this concern. 
                That or make it easy enough for us to demarcate the
                breadth of where it comes into play and put it in a
                parking lot for a future need.
             
            This

                is a real case we had at the state level.  Male Doc is
                working in a practice.  He has access to the EMR that
                every other doc in his practice has access to so could
                see the data of all the patients that went there.  Turns
                out the Husband of the woman he is committing adultery
                with was a patient of another doc at the practice.  This
                guy is a father and has two kids.  Husband and Wife
                split up.  Doc and woman get married and want to get
                custody of the kids.  Doc looks at ex-husbands medical
                records and finds some sensitive information that the
                new couples lawyers use to argue that the dad isn’t a
                fit parent.  Fortunately – the father’s lawyer figures
                it out and puts the keibash on using that breached data
                and the Judge makes his custody decision sans the
                sensitive health information that shouldn’t be available
                (and later in another court room the doc gets convicted
                of a HIPAA violation).
             
            The

                concern that we are all twisting around seems to be the
                lack of distinction about the permission types.  Maybe
                there is a way to clarify it using another construct
                that I haven’t come up with.  Is this kind of concern
                addressed somewhere else?
          
          
             
          
          
             
          
          
             — Justin
          
          
             
          
          
             
            
              
                
                  On Dec 13, 2015, at 11:10 PM,
                    Aaron Seib <aaron.seib at nate-trust.org>

                    wrote:
                
                 
                
                  
                    
                      I
                            still don’t think I am 100% on what
                            Discovery means in this context.
                    
                    
                       
                    
                    
                      Here

                          is the def you provided:
                    
                    
                       
                    
                    Discovery

                      means: the user(1) doesn't know who
                      will be on the list. That puts a lot of
                      responsibility on the RS to do the right thing(2).
                      In HIEs for example, they insist the user is a
                      practicing physician because they want to reduce
                      their liability if someone's name pops up on a
                      list that the user should not have seen.
                    
                       
                    
                    (1) 
                        Who

                        is the user?  I am still looking to the
                          Permission Type
                        to see if I can get that set of terms to line up
                        in my head.  Patient was a permission type which
                        in the health domain correlates to the patient
                        who is the subject of the PHI that the Resource
                        Server may be disclosing.  The assumption being
                        that we can match the identity of the person who
                        is using a client application to connect to the
                        resource server  (owned by the institution that
                        operates the Resource Server – in the API TF
                        scope the typical example being a EMR used by
                        the caregiver that the patient has had
                        treatment) with the Medical Record Number (MRN)
                        or equivalent in the Resource Servers enterprise
                        context (I don’t see any reason why we can’t say
                        that an HIE with an MPI might be able to
                        simplify this by correlating the MPI values to
                        the person who is using the client app to access
                        data about themselves across Resource Servers
                        that have data about that person “Patient”).
                    (2) 
                        Do

                        the Right Thing - 
                    
                       
                    
                    
                      Sorry

                          for all the verbiage – I want to get my meager
                          understanding spelt out so it can be
                          corrected.  This may not be fruitful but it
                          occurs to me that something that isn’t
                          apparent that is becoming more apparent to me
                          as I wrestle with this is that the idea of
                          User may be better understood as a set of
                          several or more sub-categories.
                    
                    user
                    The scope is for a bulk set of records
                        (I am assuming that it is implied here that
                          set of records is meant to convey data for
                          more than one person – the notion of a record
                          is not clear to me here I must admit)  or
                        for aggregate data not representing a single
                        patient (is this meant to be a distinction
                          or a reiteration of the bulk set of records? 
                          What is the difference?), based on what is
                        available to the current user (here
                          is where the turn of phrase seems to be
                          slipping.  I am still struggling with the some
                          notion being conveyed here. 
                     
                    The question that comes to mind is if
                        we look at the set of records being made
                        available ‘to the current user’ is that person’s
                        record one of those found in the set of
                        records?  There seem to be a couple of
                        distinctions that are probably implied but might
                        help to make explicit.  At a minimum there are
                        two cases that come to mind:
                    (1) 
                        The case where the ‘Current User’ may
                        have a record in the set being returned and any
                        other person’s record being disclosed is
                        permitted because that other person granted the
                        User permission.
                    (2) 
                        The case where the ‘Current User’ does
                        not have a record in the current set and is
                        accessing them as a result of capacity being
                        vested in them by the Record owner, because of
                        their professional role.
                     
                    I am not sure if there is a more
                        precise way to look at it but it would seem to
                        be that the root difference has something to do
                        with how the User got the permission.  It may
                        not be evident I am seeing the difference being
                        based on how the user got the permission.  In
                        case (1) I think of the person as a family care
                        giver who has access to other ‘family’ members
                        records because they granted that to him\her to
                        have access and it is not in the role of
                        providing treatment as traditionally defined by
                        HIPAA.  In the (2) case I see it being derived
                        based on the fact that the person is in a
                        Treatment role as defined by HIPAA and the
                        Record Owner (i.e., the Hospital et al) gives
                        them permission to access certain records.
                     
                    I think the key to unraveling this not
                        is to differentiate between users who are not
                        acting in a professional capacity from those
                        that are as the applicable authorization to
                        disclose is derived from two separate
                        authorities.  In Case (1) the User is getting
                        permission to access those other records because
                        the patients whom the records are about gave
                        him\her permision as they may given their right
                        to share with whomever they please while under
                        case (2) they are getting permission as an
                        aspect of their professional requirements as
                        warranted by the resource owner.
                     
                    Not sure if this is half baked or not
                        but there if there is a fly in the ointment it
                        seems to me that it has to do with what John
                        referred to as purpose of use earlier on. 
                        Assume that the User in case 2 has a purpose of
                        use to be treatment and I think it is easier to
                        digest.  The word to use for the Consumer’s
                        purpose of use alludes me right now.  
                     
                    I think the unifying issue is that the
                        user’s purpose of use must be the same for all
                        the records being retrieved.  
                     
                    I think that is the issue with
                        Discovery that is hard to get a grasp on.  
                     
                    If an HIE is granting permission to a
                        Requesting party (why do we use the word User
                        rather then requeting party here?) for a set of
                        records it should only be for one or the other
                        purpose of use and the purpose of use must match
                        the part being played for the transaction being
                        responded to by the RS as known to the RO.  
                    
                       
                    
                    
                      Aaron

                          Seib
                    
                    
                      NATE,
                          CEO
                    
                    
                      @CaptBlueButton
                    
                    
                      (o)

                          301-540-2311
                    
                    
                      (m)

                          301-326-6843
                    
                    
                       
                    
                    
                       
                    
                    
                      From:
                          agropper at gmail.com
                          [mailto:agropper at gmail.com]
                          On Behalf Of Adrian Gropper

                          Sent: Friday, December 11, 2015 5:29 PM

                          To: Aaron Seib

                          Cc: openid-specs-heart at lists.openid.net

                          Subject: Re: [Openid-specs-heart]
                          "Scope" of sharing and purpose of use
                    
                    
                       
                    
                    
                      
                        
                          Hi Aaron,
                            Thanks for highlighting the important issue
                            of discovery.

                            

                            Discovery means: the user doesn't know who
                            will be on the list. That puts a lot of
                            responsibility on the RS to do the right
                            thing. In HIEs for example, they insist the
                            user is a practicing physician because they
                            want to reduce their liability if someone's
                            name pops up on a list that the user should
                            not have seen.

                            

                            I meant RO (resource owner), It makes no
                            sense for the RS to send a notice to
                            themselves.
                        
                        Yes, RqP is the
                          Requesting Party which is the party that
                          controls the Client that is accessing the AS
                          and the RS. The RqP might be the patient
                          subject (the RO) themselves using an app or
                          PHR but that case would be handled by OAuth.
                          (We call that the Alice-to-Alice case). UMA is
                          interesting because it allows the RqP user to
                          be someone other than Alice therefore enabling
                          true health information exchange. This is what
                          makes HEART so useful and our HEART Profiles
                          so important.
                      
                      
                        Adrian
                      
                    
                    
                      
                         
                      
                      
                        
                          On Fri, Dec 11, 2015 at
                            4:53 PM, Aaron Seib <aaron.seib at nate-trust.org>

                            wrote:
                        
                        
                          
                            Hi

                                – I meant to ask you last week.  When
                                you say Discovery in the first bullet I
                                am not sure I know what you mean.  Can
                                you expand on that for me?  I think I
                                get everything except that below.
                             
                            I
                                don’t know why we are trying to be so
                                cryptic on the work group.  This is
                                unfortunate.  
                             
                            You

                                use RO below and I think it might be a
                                typo but have to confirm.  Is it meant
                                to have been something else?
                             
                            What

                                is RqP an abbreviation of? Requesting
                                Party?
                             
                            From:
                                Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net]
                                On Behalf Of Adrian Gropper

                                Sent: Friday, December 11, 2015
                                3:37 PM

                                To: Moehrke, John (GE Healthcare)

                                Cc: openid-specs-heart at lists.openid.net

                                Subject: Re: [Openid-specs-heart]
                                "Scope" of sharing and purpose of use
                             
                            
                              
                                Let

                                  me attempt at mediation :-)
                              
                              
                                -
                                  We're talking about resources that
                                  have a single subject (the patient)
                                  Resources with more than one subject,
                                  such as a patient list are a
                                  completely different matter because
                                    they involve discovery (I don’t get
                                    this?  Discovery of what?  The
                                    identity of each person in the
                                    list?). The special case of a
                                  mom with 2 kids can simply, if
                                  inelegantly, be handled by polling for
                                  each of the subjects. There's no
                                  discovery involved.
                              
                              
                                -
                                  The major difference between OAuth and
                                  UMA is that in UMA the resource is
                                  under the control of a separate legal
                                  entity. Therefore, when a client (and
                                  the client's user) shows up to request
                                  the resource, the client may present
                                  claims or attributes to either or both
                                  the resource server (RS) and/or the
                                  authorization server (AS). To say this
                                  another way: In UMA there's some kind
                                  of legal agreement between the
                                  resource server and the authorization
                                  server. In OAuth there is none because
                                  they are the same.
                              
                              
                                -
                                  The sharing of control between the RS
                                  and the AS is subject to
                                  institutional, local, and federal
                                  controls. All of the situations that
                                  John listed boil down to "good faith"
                                  and "notice" to the RO
                                  when the resource server acts on the
                                  instructions of the AS based on the
                                  actual attributes of the client (C) by client
                                      attributes do you mean attributes
                                      of MSHV or of the User of MSHV,
                                      Aaron Seib? and the
                                  client's user (RqP – this is
                                    Aaron Seib, right?  What does RqP
                                    stand for?).
                              
                              
                                Adrian
                              
                            
                            
                              
                                
                                   
                                  
                                    On

                                      Fri, Dec 11, 2015 at 3:01 PM,
                                      Moehrke, John (GE Healthcare) <John.Moehrke at med.ge.com>
                                      wrote:
                                    
                                      
                                        Hi

                                            Eve,
                                         
                                        It

                                            is clear that there is a
                                            communications problem
                                            between those that  are
                                            comfortable in the language
                                            of speaking about OAuth/UMA,
                                            and those that are
                                            comfortable in the language
                                            of speaking about Healthcare
                                            Access Control needs.  I can
                                            read every word you have
                                            said, but I have no idea
                                            what you said.
                                         
                                        I
                                            think one of our problems is
                                            that we keep skipping from
                                            use-cases where the “user”
                                            is the “patient” trying to
                                            access their own data; and
                                            use-cases where the “user”
                                            is a clinician trying to
                                            help the “patient”. There
                                            are many MORE use-cases
                                            including parents, children,
                                            guardians. There are many
                                            MORE use-cases around
                                            researchers, public-health,
                                            billing, payers. And there
                                            are a huge variety of all of
                                            these. There are
                                            authorization mechanisms
                                            that stem from direct
                                            authorization by the
                                            patient, to indirect because
                                            of context, and the ultimate
                                            for healthcare ‘because
                                            their life is in jeopardy
                                            and I am a licensed
                                            clinician that can save
                                            their life’. Followed by
                                            many medical-ethical traps
                                            like having a personal
                                            discussion about a
                                            particularly tragic test
                                            result before the lab fact
                                            is directly exposed.
                                         
                                        We

                                            need to solve all of these,
                                            however to solve any one
                                            would be helpful.
                                         
                                        John
                                         
                                        From:
                                            Eve Maler [mailto:eve.maler at forgerock.com] 

                                            Sent: Friday,
                                            December 11, 2015 11:43 AM

                                            To: Moehrke, John (GE
                                            Healthcare)

                                            Cc: openid-specs-heart at lists.openid.net

                                            Subject: "Scope" of
                                            sharing and purpose of use
                                        
                                          
                                             
                                            
                                              Hi

                                                John-- (I changed the
                                                subject line and deleted
                                                older parts of the
                                                thread.)
                                              
                                                 
                                              
                                              
                                                When

                                                  you say "scope" here,
                                                  I suspect you mean
                                                  "scope" of the sharing
                                                  use case, rather than
                                                  something like an
                                                  OAuth or UMA scope, so
                                                  I'm just checking. So
                                                  a "single-patient
                                                  scope" means that the
                                                  only human we're
                                                  paying attention to in
                                                  the use case is the
                                                  patient, and "any
                                                  application with users
                                                  that are authorized to
                                                  multiple patients"
                                                  seems to mean a use
                                                  case that involves
                                                  party-to-party
                                                  sharing, with multiple
                                                  humans involved.
                                                  However, you follow
                                                  the latter with "would
                                                  need to get multiple
                                                  scopes", so I'm not
                                                  sure. Note that
                                                  "getting multiple
                                                  scopes" as a technical
                                                  construct doesn't have
                                                  anything to do with
                                                  sharing with an
                                                  autonomous third
                                                  party.
                                              
                                              
                                                 
                                              
                                              
                                                FWIW,

                                                  here is how I think,
                                                  at a high level, about
                                                  configuring the
                                                    delegation of rights
                                                    to access resources.
                                                  It's all about parts
                                                    of speech.
                                              
                                              
                                                 
                                              
                                              
                                                OAuth

                                                  lets a user (patient)
                                                  do this configuration
                                                  at run time while
                                                  using a client app, by
                                                  opting in to the
                                                  authorization server's
                                                  issuance of an access
                                                  token to that app. By
                                                  contrast, UMA lets a
                                                  user (patient) do this
                                                  configuration anytime,
                                                  generally by
                                                  instructing the
                                                  authorization server
                                                  to check whether some
                                                  combination of the
                                                  client app and the
                                                  requesting party using
                                                  the app meet various
                                                  requirements (policy).
                                                  So OAuth is kind of an
                                                  attenuated version of
                                                  UMA wrt the
                                                  constraints on
                                                  delegation of access
                                                  rights.
                                              
                                              
                                                 
                                              
                                              
                                                system  
                                                           subject      
                                                       verb            
                                                    object              
                                                     adjective
                                              
                                              
                                                OAuth    
                                                               client ID
                                                                OAuth
                                                    scopes        
                                                     (implicitly some
                                                    endpoints)  n/a
                                              
                                              
                                                         
                                                               (and
                                                    always Alice)
                                              
                                              
                                                UMA      
                                                             
                                                     claims-based eg
                                                    Bob,  UMA scopes
                                                    over...    UMA
                                                    resource sets      
                                                         claims-based
                                                    e.g. TPO,
                                              
                                              
                                                         
                                                               client
                                                    ID/type, etc.      
                                                                       
                                                                       
                                                          time
                                                    limitations, etc.
                                              
                                              
                                                 
                                              
                                              
                                                It's

                                                  possible to conflate
                                                  purpose-of-use into
                                                  the UMA scopes system,
                                                  but it's as awkward as
                                                  conflating (ordinarily
                                                  implicit) resource
                                                  sets into the OAuth
                                                  scopes system
                                                  (resource1.read,
                                                  resource1.write,
                                                  etc.), which is why
                                                  OAuth has invented the
                                                  audience parameter to
                                                  try and solve the
                                                  problem of a single
                                                  authorization server
                                                  protecting several
                                                  APIs. This is why I
                                                  suggest using a
                                                  claims-based system
                                                  above.
                                              
                                              
                                                
                                                  
                                                    
                                                      
                                                        
                                                          
                                                          Eve

                                                          Maler

                                                          ForgeRock
                                                          Office of the
                                                          CTO | VP
                                                          Innovation
                                                          & Emerging
                                                          Technology

                                                          Cell +1 425.345.6756 |
                                                          Skype: xmlgrrl
                                                          | Twitter:
                                                          @xmlgrrl

                                                          Join our ForgeRock.org OpenUMA community!
                                                          
                                                        
                                                      
                                                    
                                                  
                                                
                                                 
                                                
                                                  On

                                                    Mon, Dec 7, 2015 at
                                                    2:00 PM, Moehrke,
                                                    John (GE Healthcare)
                                                    <John.Moehrke at med.ge.com>

                                                    wrote:
                                                  
                                                    
                                                      The

                                                          discussion on
                                                          the call today
                                                          was too hard
                                                          to break into.
                                                          Even for a big
                                                          mouth like me.
                                                       
                                                      I
                                                          am okay with
                                                          limiting our
                                                          next couple of
                                                          profiles to
                                                          single patient
                                                          scopes. As
                                                          much of the
                                                          email
                                                          discussion has
                                                          pointed out
                                                          patient
                                                          controlled
                                                          access is our
                                                          primary scope,
                                                          and logically
                                                          (if not 
                                                          technically)
                                                          this  is easy
                                                          to understand
                                                          with scopes
                                                          that are
                                                          single
                                                          patient. 
                                                       
                                                      Yes

                                                          this means
                                                          that any
                                                          application
                                                          with users
                                                          that are
                                                          authorized to
                                                          multiple
                                                          patients would
                                                          need to get
                                                          multiple
                                                          scopes; so be
                                                          it. For now… 
                                                          For Enterprise
                                                          use, this is
                                                          troubling; but
                                                          for most uses
                                                          that happen
                                                          from outside
                                                          of an
                                                          enterprise or
                                                          between
                                                          enterprises
                                                          this
                                                          limitation is
                                                          not
                                                          unreasonable.
                                                          The most
                                                          common APIs in
                                                          healthcare for
                                                          this are
                                                          already
                                                          patient
                                                          centric. So it
                                                          is not a big
                                                          problem.
                                                       
                                                      The

                                                          user
                                                          experience
                                                          does not need
                                                          to be impacted
                                                          by this
                                                          profiled
                                                          limitation
                                                       
                                                      The

                                                          future does
                                                          not need to be
                                                          impacted by
                                                          this profiled
                                                          limitation.
                                                       
                                                      Which

                                                          means that one
                                                          viewpoint for
                                                          scope can be
                                                          the identity
                                                          of the patient
                                                          that one is
                                                          asking for
                                                          access to.
                                                          This is not
                                                          the only scope
                                                          we will ever
                                                          support; but
                                                          is one method
                                                          that would
                                                          satisfy some
                                                          use-cases
                                                          today.
                                                       
                                                      Another

                                                          view on scope,
                                                          that I have
                                                          been involved
                                                          with in other
                                                          groups, is to
                                                          use a
                                                          high-level
                                                          vocabulary
                                                          that is used
                                                          often in the
                                                          Access Control
                                                          policy –
                                                          PurposeOfUse.
                                                          This
                                                          vocabulary is
                                                          items like:
                                                          Treatment,
                                                          Payment,
                                                          Research,
                                                          Emergency,
                                                          etc…
                                                       
                                                      To

                                                          go deeper than
                                                          these two
                                                          vectors
                                                          through scopes
                                                          in a general
                                                          purpose
                                                          healthcare
                                                          access control
                                                          infrastructure
                                                          is futile.
                                                      Next

                                                          level deeper
                                                          in scopes
                                                          would come
                                                          from workflow
                                                          centric
                                                          implementation
                                                          guides. That
                                                          is a
                                                          specification
                                                          that is
                                                          defining a
                                                          workflow,
                                                          could define a
                                                          scope(s) for
                                                          that workflow.
                                                       
                                                      John
                                                       
                                                    
                                                  
                                                  _______________________________________________

                                                    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
                                  
                                  

                                    

                                    

                                    -- 
                                  
                                    
                                      
                                        
                                          
                                            
                                              
                                                 
                                                
                                                  Adrian

                                                    Gropper MD

                                                    

                                                    PROTECT

                                                      YOUR FUTURE -
                                                      RESTORE Health
                                                      Privacy!

                                                      HELP us fight for
                                                      the right to
                                                      control personal
                                                      health data.

                                                      DONATE: http://patientprivacyrights.org/donate-2/
                                                    
                                                
                                              
                                            
                                          
                                        
                                      
                                    
                                  
                                
                              
                            
                            
                              
                            No

                              virus found in this message.

                              Checked by AVG - www.avg.com

                              Version: 2016.0.7294 / Virus Database:
                              4483/11158 - Release Date: 12/11/15
                          
                        
                      
                      
                        

                          

                          

                          -- 
                      
                      
                        
                          
                            
                              
                                
                                  
                                    
                                       
                                    
                                    
                                      
                                        Adrian
                                          Gropper MD

                                          

                                          PROTECT

                                            YOUR FUTURE - RESTORE Health
                                            Privacy!

                                            HELP us fight for the right
                                            to control personal health
                                            data.

                                            DONATE: http://patientprivacyrights.org/donate-2/
                                          
                                      
                                    
                                  
                                
                              
                            
                          
                        
                      
                    
                  
                  _______________________________________________

                    Openid-specs-heart mailing list

                    Openid-specs-heart at lists.openid.net

                    http://lists.openid.net/mailman/listinfo/openid-specs-heart
                
              
            
             
          
          
            
          No

            virus found in this message.

            Checked by AVG - www.avg.com

            Version: 2016.0.7294 / Virus Database: 4483/11177 - Release
            Date: 12/14/15
        
        

        
        

        _______________________________________________
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/20151214/ce5d33f7/attachment-0001.html>


More information about the Openid-specs-heart mailing list