[Openid-specs-heart] HEART Clinical Research UMA

Sun Jan 24 01:07:48 UTC 2016

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

cid:image001.jpg at 01D10761.5BE2FE00

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

cid:image001.jpg at 01D10761.5BE2FE00

From: Openid-specs-heart [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
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

On Fri, Jan 22, 2016 at 2:55 PM, Glen F. Marshall <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
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/20160123/13a6272c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160123/13a6272c/attachment.jpg>