[Openid-specs-heart] HEART Clinical Research UMA
Glen Marshall [SRS]
gfm at securityrs.com
Sun Jan 24 02:13:30 UTC 2016
Aaron,
As is typical for use cases, peripheral items in the problem statement
narrative add 'color' to make the scenario life-like. The technical
solutions later in the use case do not depend on them.
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 20:07, Aaron Seib, NATE 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
>
> cid:image001.jpg at 01D10761.5BE2FE00 <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?
> o 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?
> o 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?
> o 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.
> o 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?
> o 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?
> o 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
>
> cid:image001.jpg at 01D10761.5BE2FE00 <nate-trust.org>
>
> *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 <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
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160123/01a45acf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160123/01a45acf/attachment-0001.jpe>
More information about the Openid-specs-heart
mailing list