[Openid-specs-heart] Draft HEART meeting notes 2015-06-01
agropper at healthurl.com
Tue Jun 2 13:40:46 UTC 2015
Apologies for missing the beginning of an excellent discussion. I was in a
Datapalooza HDC Policy Committee meeting.
Sarah's description, with Justin's amendment, is exquisite in its clarity
and will be very helpful in our design. There is something that I hope we
can repphrase for further clarity. These have to do with Authorization
Servers and the FHIR Identifier.
The system will have many resource servers, many clients, many IDPs, and
many federations, but there's only one Alice. To keep all of these system
components honest and substitutable, Alice has to be able to specify her
own authorization server. Whether the system as a whole ends up with only a
handful of authorization servers or, as many authorization servers as there
are patients, is not something we need to bake into HEART. This
person-centric perspective is essential to making HEART work across HIPAA
and non-HIPAA, wearables, IoT, clinical, and research applications. Each of
these service providers will have their own policies and practices in and
out of healthcare. They may or may not choose to participate in the same
federations. But there will still be only one Alice.
On Tuesday, June 2, 2015, Justin Richer <jricher at mit.edu> wrote:
> An important discussion point missed in the notes below:
> If Alice wants to move information between her PHR and PCP in either
> direction, this just changes the roles that each party plays. The PHR can
> be a client of the PCP's protected resource, or the PCP can be a client of
> the PHR's protected resource, or both. It's important that the protocols
> we're working on be able to work in either or both directions like this.
> -- Justin
> On 6/1/2015 11:19 PM, Sarah Squire wrote:
> Debbie Bucci
> Dustin Gage
> Edmund Jay
> Greg K
> Jim Kragh
> Justin Richer
> Rachel Houseman
> Mark Russell
> Sarah Squire
> Thompson Boyd
> Tom Sullivan
> William Kinsley
> Nat Sakimura
> Adrian Gropper
> The patient should be given a FHIR API endpoint whether they ask for it or
> not. They can choose to authorize various things to use the API, but they
> shouldn’t have to ask for it.
> The opt-in/opt-out choice comes when Alice chooses whether or not to
> authorize a client.
> Alice can move information between her PHR and PCP portal, or request that
> information be synced automatically as it is added. The details of how that
> two-way sync could be accomplished has yet to be fleshed out.
> Alice’s authorization servers will have white lists, black lists, and gray
> lists, which will determine the policy by which the authorization server
> agrees to register a client. Trust frameworks can provide a default policy.
> Alice can express her own policy preferences at run-time.
> Alice’s FHIR identifier within all systems would be a unique URI. Ideally,
> this would be discovered automatically, but Alice should be able to paste
> it in manually in the case where discovery fails.
> Alice can choose whether to do a one-time import of her information at
> registration, or to authorize an ongoing sync that allows new information
> to be imported every time it is added. The information that is imported
> into a client may or may not be used to update existing information. The
> client can also give Alice the option to refresh the cache that is being
> used by the client.
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-heart