[Openid-specs-heart] Sum it up

Thu Jan 7 14:56:11 UTC 2016

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 <mailto: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 <tel:301-540-2311>
> (m) 301-326-6843 <tel:301-326-6843>
> <image001.jpg> <http://nate-trust.org/>
>  
> 
> From: agropper at gmail.com <mailto:agropper at gmail.com> [mailto: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 <mailto: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 <mailto:aaron.seib at 23eleven.net>> wrote:
> 
> Thanks Adrian
> 
>  
> 
> Aaron Seib
> 
> Principal, 2311
> 
> (o) 301-540-2311 <tel:301-540-2311>
> (m) 301-326-6843 <tel:301-326-6843>
>  
> 
> From: agropper at gmail.com <mailto:agropper at gmail.com> [mailto: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 <mailto: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 <mailto:aaron.seib at nate-trust.org>> wrote:
> 
> In line below..
> 
>  
> 
> Aaron Seib, CEO
> 
> @CaptBlueButton
> 
>  (o) 301-540-2311 <tel:301-540-2311>
> (m) 301-326-6843 <tel:301-326-6843>
> <image004.jpg> <http://nate-trust.org/>
>  
> 
> From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net <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 <mailto: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 <mailto: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 <tel:301-540-2311>
> (m) 301-326-6843 <tel: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/ <http://patientprivacyrights.org/donate-2/>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://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/ <http://patientprivacyrights.org/donate-2/>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://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/ <http://patientprivacyrights.org/donate-2/>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://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 <mailto:Openid-specs-heart at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart <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/a7fce4e7/attachment.html>