[Openid-specs-heart] Dissecting the Release of information form

[Adrian Gropper]

+1 Nancy.

It's not necessarily HEART's job to define or standardize any particular
subset of FHIR resources. Although it could help the user experience,
subsetting is going to be highly subjective, context, and
jurisdiction-specific. It's also a lagging project that will always be
obsolete as various standards, especially FHIR, evolve to define other
resources.

The SPM What I want from HEART in no way suggests that patients expect
control over any particular subset of what's available. Also, as Privacy on
FHIR began to show, the utility of HEART will be much, much broader than
clipboard.

Therefore, I suggest that we treat subsetting of the FHIR standard as a
"value added" option by every resource server. This would allow service
providers to compete on the quality of user experience in privacy just like
they compete for user experience in many other ways.

HEART should make it easy for every resource server to define subsets of
resources without constraint as long as they publish their particular sets
for OAuth clients and requesting parties to discover prior to approaching a
particular authorization server for authorization. If a resource server
does not publish any particular subsets, then clients can only use FHIR
itself to request scope of access.

Adrian


On Tuesday, July 19, 2016, Nancy Lush <nlush at lgisoftware.com
<javascript:_e(%7B%7D,'cvml','nlush at lgisoftware.com');>> wrote:

> I was only peripherally aware of virtual clipboard prior to yesterday’s
> meeting.  From my reading last night virtual clipboard seems to focus on a
> subset of resources.  I would hope that HEART would be supporting at least
> the FHIR resource sets that have been implemented and already in production
> for some servers.
>
>
>
> I thought the next step was to expand the use cases, incorporating our
> thoughts on consent using the confidentiality codes.  I suspect issues will
> arise from that exercise without complicating it in advance.
>
>
>
> -Nancy
>
>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Debbie Bucci
> *Sent:* Tuesday, July 19, 2016 7:11 AM
> *To:* Sarah Squire <sarah at engageidentity.com>
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Dissecting the Release of information
> form
>
>
>
> Well... when thinking about the virtual clipboard vs real world .. I am
> usually presented with at least 3 or 4 documents ... the laundry list info
> insurance meds allergies etc. Consent for treatment, Privacy Notice and if
> referred with no info in hand the release of information.
>
> Seems to me that rpt is essentially an authorization for release.
>
> Adrian asked that we consider roi as part of the discussion....I think he
> may be right.
>
> Eves doc was broad and I thought the next step was to drill down to
> soecifics.  If we have agreed a virtual clipboard resource set makes sense
> that needs to be added.
>
> Specifically from the ROI - John Moerke mentioned date range of treatment
> - that's one and this form opts in  sensitive info.... so I think ... the
> CFR 42 part 2 stuff ( +genomics) may need a specific scope for
> authorization to release.
>
> Auditing needs to peripherally be considered as well imo
>
> On Jul 19, 2016 6:56 AM, "Sarah Squire" <sarah at engageidentity.com> wrote:
>
> Hi all,
>
>
>
> This is the use case that Eve has been hashing out on the call for a few
> weeks now:
> https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR
>
>
>
> Is there anything specifically added by the NYP form that has not already
> been covered?
>
>
>
> Sarah
>
>
> Sarah Squire
>
> Engage Identity
>
> http://engageidentity.com
>
>
>
> On Tue, Jul 19, 2016 at 5:43 AM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
> Debbie,
>
> In case it's not on the HEART servers, I've put a copy of the NYP
> Authorization Form here:
> https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf
>
>
>
> Mapping the NYP Authorization Form to actual UMA protocol is way above my
> pay grade. Here's as far as I get (inline):
>
>
> In the case of Alice authorizing  Dr. Bob:
>
>
>
>
>
>    - Alice is the Resource Owner *[Yes. Notice that we have to handle the
>    case where Alice has a Representative sign for her as at the bottom of the
>    form]*
>
>
>    - The requested resource set  - is the protected resource. *[Someone
>    else needs to propose the mapping to standards]*
>
>
>    - The resource set would need to have date range.
>       - Form indicates that release of sensitive information is
>       explicitly OPT-IN so a confidentiality code of V (very sensitive) would not
>       release HIV-AIDS/Mental Health/Genetics/Substance Abuse unless explicitly
>       asked for (as a scope?).
>
>
>    - Can the Authorization server sign the RPT(ROI) on behalf of Alice?*
>    [Yes. That's the whole point of UMA and HEART as far as I can tell.]*
>    - Probably good hygiene to recommend that claims re: Bob's medical
>    affiliation be recorded as part of the audit or consent receipt if unable
>    to include as part of RPT process. *[Maybe but it seems peripheral.]*
>
> It's important to note that this form is labeled by NYP as an
> "authorization" and represents UMA Phase 2 where Dr. Bob is on the scene.
> Whoever proposes a mapping to standards needs to also deal with UMA Phase 1
> where Alice or her representative tells NYP the address of her UMA
> Authorization Server. This happens before Bob is on the scene and is what I
> would call "consent".
>
> For the purpose of HEART, could we call UMA Phase 1 consent and UMA Phase
> 2 authorization?
>
>
>
> Adrian
>
>
>
>
> _______________________________________________
> 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/20160719/385e55d6/attachment.html>