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

Wed Aug 3 13:34:45 UTC 2016

Aaron,

I think you are accurately describing HIPAA and that should allow us to
re-center this thread on the core subject of Alice's resources.

The key point for this thread is that HEART needs to enable
patient-directed exchange for the full set of FHIR resources with other
subsets as options. The reasons for this include the fact that some
providers will choose to differentiate themselves by giving the patient a
voice in sharing for Treatment, Payment, and Operations even though HIPAA
does not force them to do so.

The other important aspect of HIPAA that has not been discussed yet is that
when a HIPAA Covered Entity (e.g. typical EHR) has an electronic means for
sharing data available, it MUST offer that method to the patient as well.
This means that if FHIR is used for sharing data under TPO, regardless of
what the NPP say or don't say, Alice has a HIPAA right to request her data
on FHIR.

Here's my summary of the discussion AND HIPAA as far as HEART is concerned:

a) All resources available as FHIR resources MUST also be provided for
registration with a HEART resource server even if the RS decides to bypass
the AS or override the AS authorization.
   a1) The HIPAA CE can choose to notify the patient as to whether they
bypass or override in the NPP but it makes only a slight difference.

b) HIPAA has a data minimization requirement for some transactions that
don't strictly require patient authorization so HEART MAY want to consider
how data minimization would be handled using scopes in the cases where an
RS is using a HEART AS for all sharing.
   b1) In theory, a HIPAA CE could register two paths to the patient's
resources with two separate HEART ASs. One AS would bypass the
patient-specified AS for Clients that were not subject to patient
authorization. The other AS would be specified by the patient. Maybe this
is the kind of thing Justin has in mind when he talks of an RS buying an AS
from a separate vendor.

c) Any resource server, HIPAA covered or not, MAY choose to register sets
of resources in order to improve the user experience at the AS. These
resources may or may not all be specified by FHIR. These bundling and
definition of these resource sets may be done by HEART or by standards
organizations like the HL7 DAF. (Debbie says that HEART must use only
accepted standards so it seems to me that HEART getting into the resource
bundling business is a bit of a slippery slope.)

A MUST and two MAYs. Can we move on to discussing scopes in this context
now?

Adrian

On Wed, Aug 3, 2016 at 7:48 AM, Aaron Seib, NATE <aaron.seib at nate-trust.org>
wrote:

> Regardless of how it makes me feel – my question earlier is how do we
> actually address it.
>
>
>
> I think the NPP is one way for providers to convey that they will or won’t
> acknowledge what your Privacy Preferences are – indicated via a AS.
>
>
>
> Does anyone disagree with that?
>
>
>
> There are providers that will argue that they have an ethical
> responsibility to share with other doctors that may treat you.
>
>
>
> My question comes down to – is a provider obligated to share for Treatment
> purposes or is it just that they are permitted to despite a patient like
> Adrian’s preferences.
>
>
>
> Anyone have an authoritative answer?
>
>
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> [image: cid:image001.jpg at 01D10761.5BE2FE00] <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 2, 2016 5:27 PM
> *To:* Maxwell, Jeremy (OS/OCPO)
> *Cc:* openid-specs-heart at lists.openid.net
>
> *Subject:* Re: [Openid-specs-heart] Alice's health resource set
>
>
>
> If an organization wants to be nice to their patients and also reduce the
> scope of data breaches they would notify patients when their data was
> shared the way my bank and Apple do when they use my data in a third-party
> context. We can hope that FHIR and HEART become so much standard practice
> that every respectful organization adopts the Society for Participatory
> Medicine motto: "Nothing about me without me."
>
> The "consent for TPO" you seem to be describing however is just another
> contract of adhesion that gives no meaningful choice to the patient at all.
> I, for one, am insulted when presented by such a thing and I've never met
> any patient that appreciates it.
>
> Adrian
>
>
>
>
>
> On Tue, Aug 2, 2016 at 5:12 PM, Maxwell, Jeremy (OS/OCPO) <
> Jeremy.Maxwell at hhs.gov> wrote:
>
> Not sure I follow.  HIPAA does not require consent for TPO—it is a
> permitted use.  An organization may still choose to collect consent for
> TPO, either because of their own organizational policy or because another
> law requires it.  But this is not “HIPAA TPO consent.”  In ONC parlance, we
> call this “basic choice for TPO” in both our Interoperability Roadmap as
> well as our Patient Choice Technical Project.  Of course others may call
> this by a different term, but calling it a “HIPAA TPO consent” is imprecise
> and can perpetuate existing misunderstandings about what HIPAA actually
> requires.
>
>
>
>
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
> Gropper
> *Sent:* Tuesday, August 02, 2016 5:01 PM
> *To:* Maxwell, Jeremy (OS/OCPO)
> *Cc:* Debbie Bucci; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Alice's health resource set
>
>
>
> Jeremy,
>
> Sorry, I should have said HIPAA TPO "consent".
>
> If access to the FHIR resources does not require Alice's authorization and
> the RS wants to keep Alice in the dark because HIPAA's accounting of
> disclosures is seldom implemented as well, then HEART is not involved. I
> would not call the TPO loophole consent except sarcastically.
>
> Adrian
>
>
>
> On Tue, Aug 2, 2016 at 2:22 PM, Maxwell, Jeremy (OS/OCPO) <
> Jeremy.Maxwell at hhs.gov> wrote:
>
> Also, want to clarify what “typical of HIPAA TPO consent” means?  TPO is a
> permitted use under HIPAA that does not require consent.
>
>
>
>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Debbie Bucci
> *Sent:* Tuesday, August 02, 2016 2:17 PM
> *To:* Adrian Gropper
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Alice's health resource set
>
>
>
> Lost me again Adrian -
>
>
>
> We should also not ignore the Client-to-AS first flow. This is the
> preferred flow from a privacy engineering perspective. (see other thread
> with Justin). In the majority of cases of HIE, the Client has a
> relationship with Alice already (this is typical of HIPAA TPO consent) or
> the Client has found Alice via a "Relationship Locator Service" which is a
> directory operated by the state or some private entity like CommonWell.
> When the Client matches with Alice in the RLS, does the RLS return a list
> of RSs or a pointer to Alice's AS?
>
>
>
> The most privacy-preserving thing would be for RLSs to return pointers to
> Alice's AS and in the future this is what Alice might insist on if she is
> still given a choice to opt-in or opt-out of HIE. Alice does have that
> choice today in the US. In other countries, not-so-much.
>
>
>
>  Are you suggesting the AS is some sort of proxy for all data - I don't
> think you were saying that.  At some point the Client would need a
> relationship with the RS as well - correct?   Is the Client to AS flow a
> separate spec?  Would you please provide the link?   Looking at UMA 1.01 -
> client needs a permission ticket first - that is generated from AS - to RS
> to client (?)
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
> 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/20160803/7dab4d95/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/20160803/7dab4d95/attachment.jpg>