[Openid-specs-heart] Sum it up

Tue Jan 5 23:28:47 UTC 2016

inline...

On Tue, Jan 5, 2016 at 10:29 AM, Aaron Seib <aaron.seib at 23eleven.net> wrote:

> Thanks Adrian
>
>
>
> Aaron Seib
>
> Principal, 2311
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
> Gropper
> *Sent:* Tuesday, January 05, 2016 12:14 AM
> *To:* Aaron Seib
> *Cc:* Aaron Seib; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Sum it up
>
>
>
> 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 (with the payor?  As in the payor would recommend someone to do the
> second opinion?  As the difference between  a Payor and a Provider dwindle
> this will be less trusted I suspect). 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. I remember those days too.
>

*[AG] The reason for access to the data is certainly beyond the scope of
HEART. I was only using the second opinion example to make the use-case
around #3 clear.*

> 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* *(within the scope of applicable law)* for the Hospital to
> place additional restrictions on the decision of the Authorization Server
> (which AS, the Hospitals or the Patients?). 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 – are you saying that they
> should do this within the 72 hours using their AS without reference to the
> Patients AS?). 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.
>
*[AG] The Patient's AS. We dealt with "which AS?" earlier in this thread.
>From the HEART perspective, each Resource has only one AS. This #3 issue is
about information blocking and Resources that use the Hospital AS are
irrelevant because there's no point to the hospital blocking information to
itself. The Hospital might, for consistency, adopt the same standards and
profiles as HEART. This issue of intramural vs. extramural AS standards is
right now under discussion by the FHIR bunch and I sent around the hopeful
document they created. It's up to HL7-FHIR to decide if they want separate
standards for their intramural vs. extramural APIs. The API Task Force
might try to influence Argonaut but in the end, it's still going to be up
to HL7. I hope we end up with just one FHIR.*

> So there seems to be a need for a policy to address this ambiguous area.
> It might help to come up with some short hand.  To start:
>
> AS(D) = Authorization Server of the Data Provider.  This would be the AS
> that is operated on behalf of the entity that provides care professionally
> (does the 72 hour apply to payors as well? Anyone else?) and creates the
> data in the EMR that is also operated on their behalf (the AS And the EMR
> could be outsourced to different vendors I am presuming but the contract is
> between the vendor and the Data Provider – and includes the T&Cs of a BA).
>
*[AG] So AS(D) is an Authorization Server that is NOT the subject and is
NOT the Data Provider / Resource Server. For example, AS(D) could be a
HIE.  The case where AS(D) is the RS was discussed above and is trivial
because the adoption of HEART intramural to the RS is transparent to HEART.*

> AS(C) = Authorization Server of the subject of the Content.  i.e., the
> patient a.k.a. the consumer or client (in the safety net setting).  Also
> known as a Beneficiary in the Payor sphere.  One thing that I think we need
> to acknowledge up front is that not all consumers will have an AS that the
> Data Provider can refer to so should we start with the assumption that in
> the absence of an AS(C) the Data Provider (or their BAA) can only follow
> the Disclosure Decisions of their AS(D) which creates the policy question
> of what is the obligation of the Data Provider to discover if a consumer
> has an AS(C) ?  What evidence should they retain of that search to ensure
> they are not held liable for not discovering the AS(C)  of a Patient?
>

*[AG] Yes.  The policy question you are posing is equivalent to whether an
HIE requires "consent" or not and what the nature of that consent should be
[opt-in, opt-out, managed by the Data Provider (RS), managed by the HIE].
These are pure policy issues that may or may not be the domain of the API
Task Force. I don't see what this has to do with HEART. As far as HEART is
concerned, Data Providers (RS) can choose to allow the patient to specify
the AS(C) or not. If they choose to offer the patient this option then
HEART profiles MUST support it. The issue of whether the RS MUST offer
patients this option is out of scope for HEART. Personally, I would love to
treat HEART like a trademark and say that "A Data Provider is not
patient-centered and does not get the HEART logo if they do not offer the
patient the option of specifying the AS(C)." How many in the workgroup
would support this position? *

> ∫ = the function (i.e., disclosure decision to share or not to share) of
> an AS
>
> T = the time at which the Consumer’s encounter is over.
>
> T+V = the time at which the maximum elapsed time from data creation to
> data availability to the consumer supported by the ‘Context verification’
> threshold established by who?  I don’t think we want to establish the
> threshold at 72 hours yet in the absence of law the normative practice will
> become the tolerated policy.  In my experience once the data is made
> viewable in the tethered patient portal of the Data Provider it is
> generally in a quiescent state and this may be within a day or a few days.
> I think we should anticipate that data still changes after T+V and think
> about the policy implications when it does.
>

*[AG] This has nothing to do with HEART and the portal visibility is
irrelevant. HEART enables the data to flow directly from the Data Provider
to the Requesting Party. This is equivalent to data flowing via a Direct
message under DirectTrust where the assumption is that the Requesting Party
is not subject to any delay. Any delay in the DirectTrust case might
clearly be considered information blocking. Portal visibility is more like
Direct messages under NATE, where the assumption is that patient safety
issues are more or less out of the control of the Data Provider.*

*In other words, HEART fixes the problem with DirectTrust and reduces data
blocking because it enables patient control without raising new patient
safety issues. This is the most important thing for the API Task Force to
consider. HEART is a pure win for data blocking because it avoids both the
governance issues with HIEs (as documented by the GAO report on
interoperability). HEART also a pure win because it avoids the patient
matching issue: the patient does the match when the approve the AS(C)
whether the AS(C) is owned by the patient or by an HIE. This is just
another byproduct of HEART staying focused on resources that pertain to
only one patient. It is another key patient safety benefit that the API
Task Force can recognize.*

> So with those terms maybe we can figure out what HEART has to support and
> define the policy questions to pose to the appropriate parties.
>
> Let’s make the assumption that the consumer has an AS(c) at time T.
>
> For any request between time T and T+72 what is the policy that the Data
> Provider follows with regards to data disclosure decisions?
>
*[AG] It's the right question, but it's not about policy. HEART probably
needs to allow for the Data Provider to verify the attribute of the
Requesting Party separately from the AS(C). If the Data Provider can do
that, and they choose to or are required to do that (per the API Task Force
outcome or other policy), then the time delay is not an issue.*

> I think everyone would agree that where the when ∫ AS(D) = ∫ AS(C) there
> is no policy question to be answered.  Similarly is there agreement that
> after the Context Verification Period (up to 72 hours?), in the presence of
> an AS(C), the Data Provider should do whatever ∫ AS(C) indicates?
>
*[AG] Yes.*

> Which leaves the question what should the Data Provider do within the
> Context Verification Period T+V, in the presence of a AS(C) when ∫ AS(D)
> <> ∫ AS(C)?
>
> It seems to me that if we had a way to tag the data being shared and ∫ AS
> (D) <> ∫ AS(C) where the when ∫ AS(C) is to share that it would be useful
> for the Data Provider to be able to tag anything before T+V with a value
> that says – this is the data before we have completed our Context
> Verification steps – probability of modification is high.  The policy
> should probably be informed by how likely it is that even patient safety is
> improved when the data has a relatively high probability to change within
> the T+V period.  It would help to know if what the professionals would do
> when given data that was tagged this way?  All data has a probability of
> being wrong and\or being corrected in the future.  Is the guy who is giving
> the second opinion willing to base that opinion on data that is subject to
> change?  Is the recommendation (with the caveats that are likely to be
> provided) meaningful to the consumer?
>
*[AG] All true and desirable in every case including the intramural case
where data in an EHR that covers inpatients and outpatients would benefit
from this kind of tag. The tagging issue might be of interest to the API
Task Force to the extent it or the industry or KLAS decide to develop
objective scores for data blocking behavior. This tagging issue has nothing
whatsoever to do with HEART. *

> Is that what the heart (no pun intended) of the matter comes down to?
>
> In the following paragraph you seem to be making the case that within the T+V
> if the data requestor is a Provider (that has a known relationship to the
> consumer I assume) and ∫ AS(D) <> ∫ AS(C) that the Data Provider be
> compelled to share with the licensed physician if the Data Provider can
> confirm the status of the requestors license (how does the Hospital confirm
> that my Doc in Springfield is licensed?).  Wouldn’t it be easier if the
> Provider making the request was required to provide a URI or something that
> demonstrated they are currently licensed?  After all which state is
> Springfield in?  :)
>

*[AG] There's a Springfield in every state. Yes, HEART can, and maybe
should, profile how the RS can get a verified attribute about the data
requestor / Requesting Party.  To repeat what I said above: "HEART probably
needs to allow for the Data Provider to verify the attribute of the
Requesting Party separately from the AS(C)." The API Task Force and others
can take it from there.*

*Adrian*

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