[Openid-specs-heart] FHIR Client Registration is the existential issue for HEART

Aaron Seib aaron.seib at nate-trust.org
Sat Dec 17 00:28:54 UTC 2016


    
Agreed.  We have to do something - but it doesn't make sense to try to force it here.  A better venue will emerge.


Aaron Seib
The trick to establishing trust is to avoid all tricks.  Especially tricks on yourself.

-------- Original message --------
From: Adrian Gropper <agropper at healthurl.com> 
Date: 12/16/16  6:05 PM  (GMT-05:00) 
To: Justin Richer <jricher at mit.edu> 
Cc: Aaron Seib <aaron.seib at nate-trust.org>, Josh Mandel <jmandel at gmail.com>, Grahame Grieve <grahame at healthintersections.com.au>, openid-specs-heart at lists.openid.net 
Subject: Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART 

Yes, this is a problem for both HEART (what Justin is calling guidance, below) and for UMA as evidenced by the presentation / proposal the VA made to UMA yesterday.

I don't know what the solution is going to be, but it's clear that unless we do something the user experience around FHIR is going to be as random as it today around View / Download / Transmit. Has anyone actually tried Transmit?

Adrian

On Fri, Dec 16, 2016 at 5:52 PM, Justin Richer <jricher at mit.edu> wrote:

  
    
  
  
    
      If we don't provide a mechanism for
        resource servers to issue a warning and receive a click-through
        as part of HEART, then we will force patients to register
        clients manually through a patient portal the same way that you
        register a client to the Google OAuth API.
    
    I don't know where you're getting this narrative from. The user
      doesn't manually register clients in the real world, the client
      developer would.
    The user doesn't usually interact with the RS directly, so
      there's not really a good place for the RS to *tell* the user
      anything. And unless we want to get into divulging user
      information to the RS (which so far we're not) then mandating
      support of a back channel communication mechanism isn't possible.
      And if we do want to get there, there's a whole lot of privacy
      requirements we need to work through.

    
    We're still mandating the support of dynamic client registration
      for HEART (not mandatory to use). The best I believe we can do in
      HEART is have guidance for the AS (which is interacting with the
      user) to warn the user that a particular client might have been
      dynamically registered, or its software statement only made
      certain things available.
     -- Justin

    
    

    On 12/13/2016 1:36 PM, Adrian Gropper
      wrote:

    
    
      
      
        
          
            
              
                
                  The HEART charter is about patient-directed
                    exchange across FHIR APIs. There's no reason to
                    introduce trust federations into HEART, especially
                    since practical trust mechanisms don't yet exist. We
                    can imagine that Sequoia, or DirectTrust, or the FDA
                    will start issuing software statements for apps
                    someday but that's what makes trust federations a
                    parking lot issue today. 

                  
                  

                
                What we do know today is HIPAA and the API Task Force
                output. 

                

              
              If we don't provide a mechanism for resource servers to
              issue a warning and receive a click-through as part of
              HEART, then we will force patients to register clients
              manually through a patient portal the same way that you
              register a client to the Google OAuth API. The usability
              of that process is likely to doom HEART.

              

            
            What is the alternate proposal from Glen, Aaron, or anyone
            else:

            

            (1) Is HEART to assume software statements are going to be
            issued by someone and federated by all RSs so that HIPAA /
            API Task Force warnings are irrelevant?

            

          
          (2) Is HEART to assume that dynamic client registration occurs
          without a software statement?

          

          (3) ?

          

        
        Adrian

      
      

        On Tue, Dec 13, 2016 at 10:34 AM, Aaron
          Seib <aaron.seib at nate-trust.org>
          wrote:

          
            
              
                Regardless
                    – I think that Glen’s assertion that HEART’s plate
                    runneth over is a valid one and this specific aspect
                    is best tabled.
                 
                Are
                    you disagreeing with him or just stating you’re
                    policy position?
                 
                 
                Aaron
                    Seib, CEO
                @CaptBlueButton
                  
                 (o)
                    301-540-2311
                (m)
                    301-326-6843
                
                 
                From:
                    Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net]
                    On Behalf Of Adrian Gropper

                    Sent: Tuesday, December 13, 2016 10:06 AM

                    To: Glen Marshall [SRS]

                    Cc: Josh Mandel; Grahame Grieve; openid-specs-heart at lists.openid.net

                    Subject: Re: [Openid-specs-heart] FHIR Client
                    Registration is the existential issue for HEART
                
                  
                     
                    
                      
                        The experiment to
                          fragment the address space into trusted and
                          untrusted clients has been tried many times
                          starting with Markle Common Framework, NHIN,
                          state HIEs, and DirectTrust. There's a reason
                          the HEART charter says "build, run, or
                          outsource."
                      
                      
                        Patients and
                          physicians need a system where trust is rooted
                          in people, not institutions.
                      
                      
                        Adrian
                      
                    
                    
                       
                      
                        On Tue, Dec 13, 2016 at
                          8:52 AM, Glen Marshall [SRS] <gfm at securityrs.com>
                          wrote:
                        
                          
                            I prefer this be a
                                parking lot issue for HEART.  We have
                                enough on our plate to deliver a profile
                                for the core HEART functions.  The API
                                Task Force recommendations do not have
                                the force of current regulations.  I
                                expect a marketplace solution for them,
                                outside of HEART, should the
                                recommendations find their way into
                                regulations.
                             
                             
                            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
                             
                            From:
                                Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net]
                                On Behalf Of Adrian Gropper

                                Sent: Monday, December 12, 2016
                                20:03

                                To: openid-specs-heart at lists.openid.net;
                                Josh Mandel <jmandel at gmail.com>;
                                Justin P Richer <jricher at mit.edu>

                                Cc: Grahame Grieve <grahame at healthintersections.com.au>

                                Subject: [Openid-specs-heart]
                                FHIR Client Registration is the
                                existential issue for HEART
                            
                              
                                 
                                
                                  
                                    
                                      
                                        This
                                          summer's API Task Force had,
                                          arguably, only one major
                                          conclusion: 

                                          

                                          "A Resource Server can warn
                                            a patient if the RS believes
                                            that a client requesting
                                            patient-directed exchange is
                                            un-trusted AND the patient
                                            can choose to click-through
                                            that warning and grant
                                            access to the resource
                                            anyway." 
                                      
                                      The
                                        API Task Force acknowledged
                                        situations where an RS could
                                        still block a client but these
                                        are limited to denial of service
                                        attacks and other threats
                                        against the integrity of _other_
                                        patients' data on a system.
                                    
                                    There
                                      are efforts now underway to
                                      establish trust audits for FHIR
                                      clients which could be presented
                                      as part of a "software statement"
                                      in order to avoid the API Task
                                      Force warning.

                                      

                                      Regardless of whether these
                                      software statement efforts are
                                      successful and can be used to
                                      bypass the the API Task Force
                                      "warning", HEART has to deal with
                                      the API Task Force outcome and
                                      profile how a warning is issued
                                      when a patient-specified client
                                      does not come with a "trusted"
                                      software statement.
                                  
                                  
                                    As
                                      far as I can tell, the only way
                                      for HEART to enable the API Task
                                      Force conclusion is for us to
                                      specify a way for the RS to
                                      communicate the "warning" to the
                                      AS when a software statement is
                                      deemed inadequate by the RS AND to
                                      accept a "click-through" message
                                      back from the AS. 
                                  
                                  
                                    As an
                                      alternative, the RS could bypass
                                      the AS and send the warning
                                      directly to the resource owner and
                                      expect a direct reply by secure
                                      message or via the patient portal
                                      that was used to register the
                                      resource with the AS in the first
                                      place. This alternative does not
                                      involve either HEART or UMA and
                                      could be considered a parking lot
                                      issue.
                                  
                                  
                                     
                                  
                                  Adrian
                                  
                                    
                                      
                                        
                                          
                                            
                                               
                                              
                                                
                                                  
                                                    
                                                      
                                                        
                                                          
                                                          
                                                           
                                                          
                                                          
                                                        
                                                      
                                                    
                                                  
                                                
                                              
                                            
                                          
                                        
                                      
                                    
                                  
                                
                              
                            
                          
                        
                      
                      

                        

                        

                        -- 
                      
                        
                          
                            
                              
                                
                                  
                                     
                                    
                                      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/
                                      
                                    
                                  
                                
                              
                            
                          
                        
                      
                    
                  
                
              
            
          
        
        

        

        

        -- 

        
          
            
              
                
                  
                    

                      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

    
    

  




-- 

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/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/afa95437/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Unknown
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/afa95437/attachment-0001.jpe>


More information about the Openid-specs-heart mailing list