[Openid-specs-heart] Alice's health resource set

Adrian Gropper agropper at healthurl.com
Tue Aug 2 17:12:57 UTC 2016


Aaron, this is exactly the thing I'm trying to be clear about and
hopefully, we're making progress because I agree with you.

Instead of "all that data slogging around", I would frame your question as:
How much power do we want to delegate to the patient's authorization
server?

more inline...

On Tue, Aug 2, 2016 at 12:08 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> I think what you are saying here can be done but I am not sure I get why
> you’d want all that data slogging around every time someone asked for
> Immunizations.
>

No data is slogging around. If the Client only asks for immunizations, it
gets only Immunizations. If the Client asks for "everything I can get" it
might or might not get everything depending on Alice's policies.

What you seem to be asking is: How does Alice publish to all potential
clients the subsets of whatever the RS has available that she wants to
offer so that Clients can politely ask for just those subsets?

I agree with you that HEART or Patient Privacy Rights would be making
things better for Alice if we published profiles or specs of these kinds of
subsets and that HEART should support them as an option.

However, for interoperability's sake and for giving Alice the power of
delegation, I don't think we should be forcing any RS to offer any
particular subset any more than we can force them to offer FHIR, for that
matter.

Simply put, if Alice has a standard UMA AS, she can register and control
all of her patient-level resources with that AS either by registering the
resources one-by-one or by pointing to FHIR - if the RS says they are
HEART-compliant. If the RS does not want to delegate certain resources to
Alice's AS, that's a matter for the regulators and HIPAA, not HEART.

>
>
> I can sense that the data doesn’t have to be the minimum necessary from a
> privacy perspective if Alice owns the AS but it is entirely possible that
> she doesn’t, right?
>

Right. If Alice doesn't own the AS she may not trust the AS and so she
would be well advised to restrict resource registration. This is exactly
why Alice must be given a choice of "build, run, or outsource" so as to
introduce meaningful competition for Alice's trust.

You may be worried that passive-aggressive RS would force Alice to share
all of FHIR AND not give Alice a choice to own her AS. Indeed, this is
exactly what Direct is doing by not allowing Alice to have her own
public-private key pair and forcing her to either share through a
third-party acceptable to the RS or use insecure email.

By referencing all of FHIR in HEART, we enable honest delegation of control
to Alice's AS and it becomes useful for the full range of health
information exchange transactions. Subsets defined by HEART or NGOs are
fine as options.

>
>
> Also, from a performance perspective wasn’t there supposed to be some
> benefits of the RS being able to produce an accurate Resource Set and the
> FHIR Resources were to make it relatively easy for a requester to ask for
> what they want by using the Resource spec.
>

Agreed. If RSs are worried about performance, they should state those
limits for Alice or any other user of their API. Maybe they should charge
Alice's AS to take more than $1 of interoperability resources per day or
per week. The API Task Force was clear that the RS has the right to protect
itself against damage or denial-of-service attacks.

FHIR supports a Subscription and Notification feature that can dramatically
reduce the burden of Clients polling the RS to see if something has
changed. By supporting all of FHIR, this feature becomes available to HEART
as well.

Once again, I fully support data minimization but that should not be done
as a compromise for the ability of Alice to delegate control to an Agent
she trusts.


>
>
> I am no longer a performance analyst but it seems like it would
> potentially be sacrificing some of the potential benefits of FHIR by taking
> an approach of get everything and have the AS sort it out.  Right?
>

The AS doesn't "get everything" it gets the right to control everything.

Adrian



>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Adrian Gropper
> *Sent:* Tuesday, August 02, 2016 10:15 AM
> *To:* Debbie Bucci
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Alice's health resource set
>
>
>
> corrected
> I intentionally avoided introducing the term Resource Set because I want
> to understand what purpose it might serve.
>
> For example,
>
>
>    - assume an RS registers the 39 scopes in Debbie's 9:21 post, and both
>    the RS and the AS are aware of the FHIR spec at
>    http://www.hl7.org/fhir/
>    - Alice sets a policy at her AS that anyone that cannot provide a
>    claim as a licensed physician can only see Immunizations and Patient from
>    this particular RS.
>    - Now let's say Bob and his Client show up and Alice's policies and
>    Bob doesn't claim to be an MD to the AS
>    - Can Alice AS issue an RPT to Bob's Client for just Immunizations and
>    Patient without there ever being a concept of Resource Set discussed or
>    defined?
>
> Adrian
>
>
>
> On Tue, Aug 2, 2016 at 10:13 AM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
> I intentionally avoided introducing the term Resource Set because I want
> to understand what purpose it might serve.
>
> For example,
>
>    - assume an RS registers the 39 scopes in Debbie's 9:21 post, and both
>    the RS and the AS are aware of the FHIR spec at
>    http://www.hl7.org/fhir/
>    - Alice sets a policy at her AS that anyone that cannot provide a
>    claim as a licensed physician can only see Immunizations from this
>    particular RS.
>    - Now let's say Bob and his Client show up and Alice's policies and
>    Bob doesn't claim to be an MD to the AS
>    - Can Alice AS issue an RPT to Bob's Client for just Immunizations and
>    Patient without there ever being a concept of Resource Set discussed or
>    defined?
>
> Adrian
>
>
>
> On Tue, Aug 2, 2016 at 10:01 AM, Debbie Bucci <debbucci at gmail.com> wrote:
>
> accidently hit send too  soon ...
>
>
>
> In addition to Immunizations
>
>
>
> patient/ Patient .read
>
> patient/ Patient .write
>
> patient/ Patient .*
>
> patient/ Immunization.read
>
> patient / Immunization .write
>
> patient / Immunization .*
>
>
>
>
>
>  I was going to suggest a smaller patient intake resource set as well
> containing
>
>
>
> patient/ Patient .read
>
> patient/ Patient .write
>
> patient/ Patient .*
>
> patient/ Immunization.read
>
> patient / Immunization .write
>
> patient / Immunization .*
>
> patient / Medication Dispense .read
>
> patient / Medication Dispense.write
>
> patient/ Medication Dispense .*
>
> patient/ Medication Statement .read
>
> patient / Medication Statement .write
>
> patient /Medication Statement .*
>
> patient/ Allergy Intolerance .read
>
> patient /Allergy Intolerance .write
>
> patient / Allergy Intolerance .*
>
> patient/ FamilyMemberHistory .read
>
> patient / FamilyMemberHistory .write
>
> patient / FamilyMemberHistory .*
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
> --
>
>
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
>
>
>
> --
>
>
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>



-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160802/6d95916d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3198 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160802/6d95916d/attachment.jpg>


More information about the Openid-specs-heart mailing list