[Openid-specs-heart] HEART Clinical Research UMA

[Justin Richer]

Aaron,

Within this working group we’ve got a method of marking certain items “core” vs. “peripheral”, which is to say that some things absolutely must be solved in a particular way (“Alice must log in”) vs. things that are used to string the narrative together (“Alice checks her email on her smartphone”). 

 — Justin

> On Jan 23, 2016, at 8:07 PM, Aaron Seib, NATE <aaron.seib at nate-trust.org> wrote:
> 
> What does peripheral mean?  For decoration purposes only?  Seems to introduce noise and take away from what you are trying to convey is my point. <>
>  
>  
> Aaron Seib, CEO
> @CaptBlueButton
>  (o) 301-540-2311
> (m) 301-326-6843
> <image001.jpg> <x-msg://125/nate-trust.org>
>  
> From: Glen Marshall [SRS] [mailto:gfm at securityrs.com] 
> Sent: Saturday, January 23, 2016 8:03 PM
> To: Aaron Seib, NATE; HEART List
> Subject: Re: [Openid-specs-heart] HEART Clinical Research UMA
>  
> Aaron,
> 
> In response to your comments on the use case narrative:
> All of the data including the genomic data?  It will be made available to whom?
> The use case is for clinical data collected and made available to the clinical researchers for the study.  The nature of the data, e.g., genomics and other clinical results, is peripheral.
> I don’t know that there is a way to pseudonymize Genomic data is the point I was trying to make.  It is a real issue – I was trying to suggest it is not peripheral as a result.  If it is peripheral I would remove the reference to gemonics all together.
> How will her genome be pseudonymized?
> The specific pseudonymization (and re-identification) algorithms are likely to be specific to the clinical research study, informed by the cited standards.     
> If they can access her PHR why do they need to access the EMR as well?   Isn't the point of HEART that she have a complete record of all of her data in the PHR.   What is in the EHR that is missing from the PHR?  Why?
> I have assumed the current state of data sharing among EHRs and PHRs.  It is peripheral to the use case.
> This is a transitional use case that will hopefully go away one day.  It may be necessary for now if there is data in the EHR that isn't transportable to the PHR but I would hope that the day will come when we aren't treating the Clinical Operations software as the only source that inputs to the researchers data warehouse can be populated.  I would argue that PHR's will have more complete data then the two EMRs as the EMRs will lack the PGHD that could more readily be gathered via the PHR in comparison to forcing it to fit into the EMR of the Oncologist.
> There are multiple EHRs in this use case and, while I'd like all EHRs and PHRs to be interoperable, they are not presently.  This is peripheral to the use case.
> Am I missing something important.  Why is the patient only able to get a summary of the data?
> This references reports of disclosures from the EHRs to the CDRN.  A disclosure report for each transmission to the CDRN is assumed, and that may reference multiple data sets in summary.  The actual content and frequency of reports is not standardized, and is influenced by policy outside of the use case.  This is peripheral to the use case.
> [In reference to pharma's offer of a continuing access agreement and profit-sharing.]  Has this ever happened?  Is there anyone (from Pharma) proposing that they will do this?
> That is my hypothetical resolution to the issue of subsequent re-use of Alice's data.  That might have been a more satisfying resolution to the Henrietta Lacks case.  The actual resolution is peripheral to the use case.
> Best,
> Glen
> 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 <mailto:gfm at securityrs.com>
> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
> On 1/23/16 18:39, Aaron Seib, NATE wrote:
>> Glen – I had a lot of questions that I captured as comments in the attached.
>>  
>>  
>>  
>> Aaron Seib, CEO
>> @CaptBlueButton
>>  (o) 301-540-2311
>> (m) 301-326-6843
>> <image001.jpg> <x-msg://125/nate-trust.org>
>>  
>> From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net <mailto:openid-specs-heart-bounces at lists.openid.net>] On Behalf Of Glen Marshall [SRS]
>> Sent: Saturday, January 23, 2016 12:58 PM
>> To: Sarah Squire
>> Cc: HEART List
>> Subject: Re: [Openid-specs-heart] HEART Clinical Research UMA
>>  
>> Gladly!  See attached PDF.
>> 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 <mailto:gfm at securityrs.com>
>> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>>  
>> 
>> On 1/23/16 12:53, Sarah Squire wrote:
>>> Hi Glen,
>>>  
>>> Your sharepoint link isn't working. Could you send a pdf to the list please?
>>>  
>>> Thanks,
>>>  
>>> Sarah
>>> 
>>> Sarah Squire
>>> Engage Identity
>>> http://engageidentity.com <http://engageidentity.com/>
>>>  
>>> On Fri, Jan 22, 2016 at 2:55 PM, Glen F. Marshall <glen.f.marshall at gmail.com <mailto:glen.f.marshall at gmail.com>> wrote:
>>> Team,
>>> 
>>> Here is a link <https://srsmail-my.sharepoint.com/personal/gfm_securityrs_com/_layouts/15/guestaccess.aspx?guestaccesstoken=2QxXSnxuijrIbiElNuU%2bCJIV0G6FBK5uWbdt0FvvVFg%3d&docid=2_1c5c33062f8ee4dbe9dbf61ba9524ca39> to a read-only shared copy of the updated Clinical Research (UMA) use case.  It now contains fleshed-out business prerequisites, sequence diagrams, and some minor corrections.
>>> 
>>> Please respond with your suggestions, corrections, etc.  But please do not alter the document itself, as the master Word copy and Visio graphics are all in my personal cloud storage.
>>> 
>>> Note I have not included the final sequence diagram -- review of disclosures and modification of UMA permissions -- as I'd like to discuss the proper UMA mechanisms and flow to accomplish the modifications.
>>> 
>>> Also note I have specifically made the AS a singular IRB-selected element within the use case.  All access control policies are determined by the IRB for ongoing access, with the patient consenting to them.  This also keeps HEART away from ongoing political, regulatory, and policy matters that are properly out of scope for our technical work.
>>> 
>>> Since I will be at the IHE Connectathon next week, I won't be on our schedule 1/25 call.  Looking forward to discussions on-list and in February meetings.
>>> 
>>> Best,
>>> Glen
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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>
>>>  
>>  
>  
> _______________________________________________
> 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/20160124/2dc2ba10/attachment.html>