[Openid-specs-heart] Sum it up

Tue Jan 5 05:13:46 UTC 2016

I'm glad we're in agreement on #1 and #2. It would be even better if we had
a documented consensus of the workgroup on these points.

I apologize for my tortured wording on #3. Let me try again...

There is no law that says Hospitals must delay release of patient data to
the patient for X hours. There is a law that says patients have a right to
their personal data after X hours. The reason patient are not given the
right for immediate access is based on the perception that data out of
context could have adverse effects on the patients and so the Hospital is
allowed X time to establish the context for "patient safety" reasons.

The problem is that Hospitals and other "providers" that provide a range of
services beyond data generation have an economic interest in being the
preferred provider for the therapy that follows from the data. Providing
access to the data immediately would enable the patient to get an instant
second opinion directly or through a more integrated interaction with the
payor. Providing an immediate or real-time data feed to the patient would
also inhibit the Hospital from manipulating the patient record to improve
reimbursement or, in a capitaited system, to increase the risk profile. In
the paper days, I remember the pink post-it notes added by "coders" to the
chart each evening so that doctors notes could be "enhanced"accordingly.

Therefore, #3 is about information blocking in this intermediate period
where the law tries to prevent harm to the patient and the hospital tries
to prevent harm to its business. HEART does not need to care about patient
vs. hospital. We simply need to recognize that there can be legitimate
reasons for the Hospital to place additional restrictions on the decision
of the Authorization Server. In cases where the Hospital wants to do that,
the Hospital's decision should be based on the attributes of the Requesting
Party (normally, the attributes of the Requesting Party are evaluated by
the Authorization Server). HEART profiles should allow the Hospital that
wants to verify Requesting Party attributes without adulteration by a
patient-controlled Authorization Server to do so. In cases where the
Hospital decides to override the decision of the Authorization Server, it
should be up to the Hospital to do the verification work and the Hospital
should be required to notify the patient or the patient's Authorization
Server that their decision was modified and why.

For example, in the 72 hour delay to avoid patient harm, the Authorization
Server can issue a token for an immediate transfer to the Requesting
Party's Client. The Hospital can attempt to verify that the RqP is a
licensed physician and if it can't, it can block access to the data for 72
hours. Since the Hospital modified the intent of the AS token, it should
report the block and the reason (failure to verify RqP license) to the AS
immediately. This would allow the patient to do other out-of-band things to
get the verification done. In the old day's this would be done by the
patient calling a doctor at the Hospital and asking for the info.
Unfortunately, most of today's EHRs do not allow individual physicians to
override institutional constraints the way they could in the days of phone
and fax. In my opinion, that's a "patient safety" issue in it's own right
and the domain of the API Task Force. HEART can help but we cannot solve
the problem.

Adrian

On Mon, Jan 4, 2016 at 8:38 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> In line below..
>
>
>
> 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:* Monday, January 04, 2016 6:26 PM
> *To:* Aaron Seib
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Sum it up
>
>
>
> 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 (Another way to put this might be to
> say that the Federal laws were written with the intent of protecting the
> patient who otherwise didn’t have a way of communicating their preferences
> – this approach resulted in a per force conservative set of laws that have
> had the unintended consequence that we are experiencing today - where
> patients may want to have their information shared but those who are
> regulated feeling like they are liable for something if they don’t follow
> the letter of the law). Therefore, many consent management problems can
> be solved by simply allowing patients that care to specify and control
> their own Authorization Server (Yes! This is what I have been saying but
> I wouldn’t have used the misnomer consent nor referenced a specific
> technology like Authorization servers). 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.
> Which brings us back to the debate in December.  Was that ever finalized?
> I think there are or at least may be intra-enterprise use cases where the
> Consumer’s AS is not involved and the Regulated entity could leverage a
> Bulk Permission Type.  I am thinking about the facility where the EMR has
> both specially protected data and other PHI.  For some of the internal
> users you may allow not them to access specially protected data but you
> have some internal users (from the behavioral health unit) that may be
> authorized to access the specially protected data to.  But as I think about
> the charter I am not so sure this case is in scope of HEART given no
> consumer is involved? is that accurate?
>
> 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.  By God – I think I am still
> in agreement with you.  You are essentially answer the question I had when
> I finished reading the last sentence, right?
>
> 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 (can anyone provide a reference for this topic?  I am not getting
> it from the fragments shared so far – there is an ethical argument to not
> disclose for three days?  We will serve no wine before its time?).
> Policies regarding this kind of block are beyond our purview (you can all
> share your inputs with the API TF of course!). 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 (I don’t follow – do you
> mean if they are inclined to do so before the 72 hours?  . 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.
>
>
>
> I am in agreement up to topic #3 – probably need to get a better
> understanding.
>
>
>
> 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/
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7294 / Virus Database: 4489/11319 - Release Date: 01/04/16
>

-- 

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/20160105/f360ed84/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3141 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160105/f360ed84/attachment.jpg>