[Openid-specs-heart] Sum it up

[Adrian Gropper]

Agreed as well. It's important to have a notice tech hook in order to stay
out of policy.

Adrian

On Thu, Jan 7, 2016 at 10:33 AM, Eve Maler <eve.maler at forgerock.com> wrote:

> Agreed, especially since we're supposed to stay out of policy. If we do
> this, it should have a technology "hook"...
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>
> On Thu, Jan 7, 2016 at 6:56 AM, Justin Richer <jricher at mit.edu> wrote:
>
>> I would be hesitant for HEART to require a notice to the patient or AS
>> without specifying a common mechanism for that notice.
>>
>>  — Justin
>>
>>
>> On Jan 5, 2016, at 9:47 PM, Eve Maler <eve.maler at forgerock.com> wrote:
>>
>> Hi guys-- I'm following along as best I can on a busy day/night, so I
>> hope my contribution for the moment will be additive and not missing the
>> point...
>>
>>    - Adrian's points about ensuring fairness to Alice around the
>>    hospital trying to block information access are very well taken.
>>
>>
>>    - I don't quite see why an individually controlled AS is strictly
>>    required, though I see how it can help at the margin. Certainly the RS has
>>    business reasons (risk mitigation and so on) why it favors more blocking;
>>    if the AS is in business to serve Alice it will already work in her favor,
>>    but more business-model pressure in that direction is good.
>>
>>
>>    - Note that the default way that UMA works doesn't involve the AS
>>    passing any of the requesting party's attributes along to the RS; it just
>>    passes calculated "permissions" in the access token for the RS to inspect
>>    before judging whether to let the requesting party and their client app in.
>>    (An alternate UMA token profile could arrange for passing attributes
>>    instead, but on balance I'd probably not advise that we go in that
>>    direction in our profiling...)
>>
>>
>>    - However, UMA does say
>>    <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#give-access>
>>    "The resource server MAY apply additional authorization controls when
>>    determining how to respond" when the access token contains sufficient
>>    permissions for the requesting party to get access. Obviously, this is
>>    where potentially pernicious behavior like delaying access for 72 hours
>>    could creep in.
>>
>>
>>    - The UMA group has been working on draft model clauses that could
>>    form the basis for legal agreements, consent receipts, etc. We've been
>>    discussing what to do about model clauses that ensure the RS *never*
>>    gives access when the access token contains insufficient permissions, and
>>    offering model clauses that say the RS *has to* notify the RO somehow
>>    whenever it blocks immediate access when the access token contains
>>    sufficient permissions. (Accounting of disclosures, anyone?)
>>
>>
>>    - This could be an interesting element for us to profile, *if* we
>>    consider this to be in scope -- iffy because it's in business model-land.
>>
>>
>>
>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>> Technology
>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>>
>> On Tue, Jan 5, 2016 at 7:50 PM, Aaron Seib <aaron.seib at nate-trust.org>
>> wrote:
>>
>>> I seriously spent 45 minutes trying to parse this and respond.  Then I
>>> walked away and came back and tried for another 45 minutes but I am still
>>> not sure I completely follow you.
>>>
>>>
>>>
>>> I think there is a difference in our understanding about how Direct is
>>> implemented which probably fogs the conversation further.
>>>
>>>
>>>
>>> I am going to try one more time tonight by just pulling out the things I
>>> understand and see if that clarifies what #3 is.
>>>
>>> ·        HEART simply needs to recognize that there can be legitimate
>>> reasons (within the scope of applicable law) for the Hospital to place
>>> additional restrictions on the decision to disclose content *even when
>>> the AS(C) would have them do the opposite(?) *.
>>>
>>>
>>>
>>> I do not agree that the nation is well served if there are two standards
>>> promoted to solve the same problem.
>>>
>>>
>>>
>>> Back in 2010 I argued that it should be possible to represent a
>>> computable rules engine with what I think I called an atomic expert
>>> grammar.  This atomic expert grammar could be used to represent HIPAA.  It
>>> could be used to represent the state specific laws where State Statute
>>> superseded HIPAA (at the time I think there were 26 states).  The theory
>>> was that we would work with states and the federal government to establish
>>> “Authoritative” representations of the laws.  These sets of atomic expert
>>> grammar could be published in such a way that they could be retrieved (this
>>> was pre-Cloud days) by software at points where disclosure decisions need
>>> to be tested for regulatory compliance and the local rules engine would
>>> apply these and any other local policy requirements of the Provider
>>> Organization that complied with applicable law.
>>>
>>>
>>>
>>> I don’t see any reason why the personal privacy preferences to be
>>> represented in an AS(C) wouldn’t be based on the same atomic expert grammar
>>> and would argue to have separate standards would be a dis-service to those
>>> poor schleps that have to make things work.
>>>
>>>
>>>
>>> I have spent a great deal of the last five (now going on six I guess ~
>>> Happy New Year) years working on policy side things and was excited to
>>> learn that what HEART was working on was a way to implement the Consumer’s
>>> desires in the form of an atomic expert grammar that any decision point
>>> could retrieve and apply.
>>>
>>>
>>>
>>> I would be really surprised if we solve the problem for the applicable
>>> law side of the problem that the same grammar wouldn’t suffice for the
>>> consumer side of the equation.
>>>
>>>
>>>
>>> I think that we cannot assume that we will wake up one morning and every
>>> American will have an AS(c) configured with their preferences so we have to
>>> figure out how to enable computable disclosure decisions in its absence.
>>> It would be very unfortunate if these two applications couldn’t rely on the
>>> same Atomic Expert Grammar.
>>>
>>>
>>>
>>> Are we saying the same thing?  If so then I think the only other gap we
>>> have to address is at what point in the life-cycle of clinical data do we
>>> expect the disclosure decision point to apply the AS(C), right?
>>>
>>>
>>>
>>> One thing that I want to tease apart is what we are really talking about
>>> with regards to the notion of a Validation Period.  If that is just a
>>> through away thought lets drop it.  I thought it was important but I was
>>> thinking of it in the sense that there is a real need to have a validation
>>> period between when the Doc initially captures clinical data during the
>>> encounter and when the data was made available to the Patient for sharing.
>>> Given my limited experience what I have seen is that once data is made
>>> viewable via the patient portal it has completed all the internal processes
>>> of the Hospital and is thus ready to be shared with the patient based on
>>> the preferences of the patient.
>>>
>>>
>>>
>>> What I think you are pointing out is that for certain scenarios
>>> involving actors other than the consumer the end-user of the EMR can
>>> disclose data to someone external to the system before it has been put into
>>> the quiescent state.
>>>
>>>
>>>
>>> I am struggling to envision when this actually happens in the real
>>> world.
>>>
>>>
>>>
>>> Maybe things have changed and it happens all the time but I struggle
>>> picturing an Hospital allowing an end-user to disclose anything outside the
>>> enterprise that isn’t in a quiescent state.  I can see there being paths
>>> where as soon as the doc saves it the record goes into a quiescent state
>>> and maybe this is where I am over simplifying when I made the tie into the
>>> Patient Portal.  Perhaps after a typical ambulatory encounter there is no
>>> QC that applies and it is saved directly to a quiescent status but isn’t
>>> viewable via the portal until after the some other process updates that
>>> status to be made viewable via the portal.
>>>
>>>
>>>
>>> Is there not a status associated with a clinical document that says it
>>> is “final” and ready to share externally?  I had assumed that this was
>>> being used by Portals but concede that may have been a foolish assumption
>>> and perhaps the better way to have put it would be in relation to that
>>> “Final” state (knowing full well that the data is subject to change – after
>>> all that is the point of the Open Notes initiative, right?  To get the
>>> patient to provide a second set of eyes to improve the accuracy of what is
>>> documented?).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Aaron Seib, CEO
>>>
>>> @CaptBlueButton
>>>
>>>  (o) 301-540-2311
>>>
>>> (m) 301-326-6843
>>>
>>> <image001.jpg> <http://nate-trust.org/>
>>>
>>>
>>>
>>> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
>>> Gropper
>>> *Sent:* Tuesday, January 05, 2016 6:29 PM
>>> *To:* Aaron Seib
>>>
>>> *Cc:* Aaron Seib; openid-specs-heart at lists.openid.net
>>> *Subject:* Re: [Openid-specs-heart] Sum it up
>>>
>>>
>>>
>>> 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
>>>
>>> <image004.jpg> <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/
>>> ------------------------------
>>>
>>> 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
>>>
>>> _______________________________________________
>>> Openid-specs-heart mailing list
>>> Openid-specs-heart at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>
>>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 

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/20160107/adb4b5e1/attachment.html>