[Openid-specs-heart] Review of HEART FHIR resources on oAuth 2.0

Nancy Lush nlush at lgisoftware.com
Tue Apr 25 18:39:00 UTC 2017


Hi Justin,

 

My list isn’t exhaustive either, but is a better minimum.  

 

We could also add a statement indicating that HEART is intended to work with all FHIR resource types with a link to the most recent FHIR resource index.  (Can anyone think of a case where we might want to exclude a resource type?)

 

Comments for Section 7 are inline.

 

Thanks,

Nancy

 

From: Justin Richer [mailto:jricher at mit.edu] 
Sent: Monday, April 24, 2017 3:50 PM
To: Nancy Lush <nlush at lgisoftware.com>
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Review of HEART FHIR resources on oAuth 2.0

 

Nancy, thanks for the great comments. Responses inline.

 

On Apr 24, 2017, at 11:32 AM, Nancy Lush <nlush at lgisoftware.com <mailto:nlush at lgisoftware.com> > wrote:

 

FHIR resources on oAuth 2.0

1.       In section 2.0, is there a reason why the following resources are omitted?       

*	AllergyIntolerance
*	Condition
*	Immunization

    I would think the above would be included in a minimum.  I would also prefer to see the following two:

*         CarePlan

*         Device

 

The list that’s there is based on what was implemented in the SMART on FHIR project at the time of the first draft. It’s not meant to be exhaustive but if there’s a better list that people would consider a minimum example, then by all means let’s add them. 





 

2.       Section 7

a.       If a system supports security codes, the underlying assumption is that a given security code transcends resource types.  I would think that if an ETH scope is specified, it should be applied to all resource types, unless specifically indicated for only one resource type.

 

This is the intent: the sensitivity and confidentiality codes are meant to be cross cutting. The current text is intended to indicate just that:

 

For example, if an access token contains patient/Observation.*, patient/MedicationOrder.read, and ETH, then the ETH scope MAY be applied by the RS to both the patient/Observation.* or patient/MedicationOrder.read records. 

 

Do you have suggested text that would make this clearer?

   … the ETH scope SHOULD be applied by the RS to both the patient/Observation.* AND patient/MedicationOrder.read records. 

 





 

3.       Otherwise, this looks good.  We have added some level of use-case context that should be helpful to implementers.

 

 

Thanks again, and any additional edits are welcomed!

 

 — Justin





Thanks much,

Nancy

 

 


 

 


Nancy Lush          

 <mailto:nancy.lush at lgisoftware.com> nancy.lush at lgisoftware.com


Lush Group, Inc

Office: (401) 423-9111


28 Narragansett Ave

PO Box 651

 <http://www.lgisoftware.com/> www.lgisoftware.com

Cell:(401) 965-9347


Jamestown, RI 02835

	
	

 


<image001.gif>

		
		
		
		
		
		
		
		
		
		
	

 

 

_______________________________________________
Openid-specs-heart mailing list
 <mailto:Openid-specs-heart at lists.openid.net> Openid-specs-heart at lists.openid.net
 <http://lists.openid.net/mailman/listinfo/openid-specs-heart> 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/20170425/071143db/attachment.html>


More information about the Openid-specs-heart mailing list