[Openid-specs-heart] Sum it up

[Adrian Gropper]

Yes.

My point was not just about data blocking but also about governance of
Authorization Servers. I made several points:

1 - Federal laws place constraints on Authorization Servers that are not
directly controlled by one patient. Therefore, many consent management
problems can be solved by simply allowing patients that care to specify and
control their own Authorization Server. This is easily handled by UMA and
OAuth as long as the (FHIR) Resource pertains to just one patient. It's
obviously impossible for bulk or other Resources that pertain to more than
one patient. I believe this consent management problem was the essence of
the use-case you raised and that the HEART profiles can easily solve it.

2 - HEART, UMA, and OAuth do not need to concern themselves with "other"
Authorization Servers operated by the Hospital. These are internal to the
institution. Since the institution also has the patient's data, the
institution always has the last word on its release. The Hospital can
always bypass the HEART Authorization Server and can always transfer
information by other means. For all HEART, UMA, and OAuth purposes a
Resource has only one Authorization Server.

3 - It's very important that HEART not constrain what John called the
"ethics" of health information blocking such as 72 hour delays for data
sharing. Policies regarding this kind of block are beyond our purview. What
HEART profiles need to do is to allow the Hospital to verify attributes of
the Requesting Party if they are inclined to do such verification. That
way, Alice's Authorization Server can say: Send One Data Object to Bob and
Bob claims he's a Licensed Practitioner in MA. The Hospital would have the
option of either verifying that Bob is a licensed MD or not (the 72 hour
block is nor required by law). If they chose to impose the block, the
Hospital would need to make a good faith effort to determine Bob's license
status. I think this kind of "trust elevation" may be out of band for UMA,
but I'm not sure.

So to summarize, HEART needs to (1) allow patients to specify a personal AS
to avoid blocks on sensitive information, (2) focus on resources that
pertain to a single patient to allow (1), and (3) enable direct transfer of
resources to Requesting Parties that are able to provide verified
attributes to the Resource Server to avoid blocking for "ethical" reasons
when such blocking would be unwarranted.

Adrian



On Mon, Jan 4, 2016 at 5:26 PM, Aaron Seib <aaron.seib at 23eleven.net> wrote:

> Adrian,
>
>
>
> You had a specific point that I wanted t make sure I could refine and
> restate accurately.
>
>
>
> I wish I had a handle on the jargon used but maybe you can help me get
> there.
>
>
>
> There is a Data Provider.  For illustrative purposes let’s say a Hospital
> (I am learning that in some scenarios the Consumer is a Data Provider where
> the data is PGHD so I am learning).
>
>
>
> Let’s keep it simple and say that there is One Data Object that this Data
> Provider wants to make sharing decisions about but there are two
> Authorization Servers one of which is controlled by the Consumer and the
> other is not.
>
>
>
> For arguments sake let’s say that the AS controlled by Alice is has been
> configured to properly convey that it is her preference that whenever
> Hospital is going to make a disclosure to another Provider for Treatment
> purposes that the Hospital share One Data Object.
>
>
>
> Let’s say that the Hospital also operates an AS that it uses to make
> disclosure decisions.  It is based on a Law that says “Thou shall not
> disclose One Data Object without consumer consent”.
>
>
>
> Is the bottom line that if the Hospital does not disclose One Data Object
> to another Provider in accordance with the consumers wishes that they are
> in fact knowingly participating in information blocking if they know that
> the Consumer has an AS of their own?
>
>
>
>
>
>
>
> Aaron Seib
>
> Principal, 2311
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
>
>



-- 

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/20160104/d5d29520/attachment.html>