[Openid-specs-heart] Sum it up

[Eve Maler]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160107/408f5d40/attachment-0001.html>