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

[Justin Richer]

Current text is:

The resource type indicates the kind of FHIR resource and consequently the kind of information available at it, based on FHIR resource type designation for the Patient compartment as found on http://www.hl7.org/fhir/compartmentdefinition-patient.html.

This document specifically lists the following common resources from FHIR version STU3 (http://hl7.org/fhir/stu3/compartmentdefinition-patient.html):

This is intended to indicate that any FHIR resource type (in the patient compartment) can be used.

 — Justin

> On Apr 25, 2017, at 2:39 PM, Nancy Lush <nlush at lgisoftware.com> wrote:
> 
> 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 <mailto:jricher at mit.edu>] 
> Sent: Monday, April 24, 2017 3:50 PM
> To: Nancy Lush <nlush at lgisoftware.com <mailto:nlush at lgisoftware.com>>
> Cc: openid-specs-heart at lists.openid.net <mailto: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.readrecords. 
>  
> 
> 
>>  
>> 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          
>> nancy.lush at lgisoftware.com <mailto:nancy.lush at lgisoftware.com>
>> Lush Group, Inc
>> Office: (401) 423-9111
>> 28 Narragansett Ave
>> PO Box 651
>> www.lgisoftware.com <http://www.lgisoftware.com/>
>> Cell:(401) 965-9347
>> Jamestown, RI 02835
>>  
>> <image001.gif>
>>  
>>  
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net <mailto: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/ed34766a/attachment.html>