[Openid-specs-heart] Sum it up

Eve Maler eve.maler at forgerock.com
Wed Jan 6 05:47:40 UTC 2016


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


More information about the Openid-specs-heart mailing list