[Openid-specs-heart] Proposal for reworked use case AND use case template
Glen Marshall [SRS]
gfm at securityrs.com
Tue Aug 4 18:48:40 UTC 2015
In addition to what John Moehrke said, nowhere in my online financial
records do I have the ability to say "Do not display transactions
regarding expenses for my <name your vice here> activities from my wife,
who otherwise has full access to our joint finances."
In healthcare, though, it would at least as difficult to have such
fine-grained selectivity for, say, treatment for treatment of the
medical consequences of said vice.
So healthcare and finances have a common inability to express a
consumer's fine-grained semantic policies. The motivation and solutions
to resolve those inabilities likely differ.
Glen Marshall
On 8/4/15 11:17, Moehrke, John (GE Healthcare) wrote:
>
> I find it very troubling when the financial industry is brought up as
> an example that healthcare should follow. From a user experience, I
> agree with Adrian that it seems to be a well ‘consumer centric’ model.
> The reality is that they are not consumer centric, they act only by
> force of consumer and often with payment for transaction fee.
>
> But the financial industry are dealing with fungible assets that can
> easily be insured and they have regulated maximum damages. Healthcare
> has NOTHING close to this. Further the only reason that the financial
> industry communicates is because they are moving your money, an asset
> they get to leverage far beyond the kind of analytics that the
> healthcare community is often accused of doing (some rightly so). The
> financial world does not communicate in any way to your benefit, they
> are perfectly happy having fragmented and non-aligned assets. Where as
> in healthcare there is an expectation that your current treatment plan
> is chosen based on your full medical history, without any piece of
> information misunderstood (malpractice).
>
> This said, I am not against the goal that Adrian is promulgating. I am
> just frustrated at the overbroad statements about how wonderful the
> financial industry is.
>
> John
>
> *From:*Openid-specs-heart
> [mailto:openid-specs-heart-bounces at lists.openid.net] *On Behalf Of
> *Eve Maler
> *Sent:* Tuesday, August 04, 2015 10:03 AM
> *To:* Adrian Gropper
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
> use case template
>
> Adrian, your patient vs. banking identity explanation was really good
> -- I'm going to steal that one. :-) Warning, musings on identity and
> proofing below. Hope they're marginally interesting/helpful.
>
> In the world of marketing data brokerage, they deal in heuristic data
> about people all the time but don't have to (or, maybe, even want to)
> precisely identify a unique human being. (If you ever want to be
> weirded out, read about Acxiom Personicx
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oceanoutdoor.com_site_wp-2Dcontent_uploads_ORCGuideToPersonicx.pdf&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=QtcwptaLBxuQh2WeoBs1IhxRnZzLuQe2ljx-h2VKN4A&e=> psychographics
> codes. I had someone in the field tell me she looked "herself" up in
> the data warehouse. She said, "They knew my bra size.")
>
> In the world of credit data brokerage, they have much the same problem
> as the "offline patient identity" world does, though with a somewhat
> different regulatory environment. If you're in the US and you want to
> try and look up the annual free credit scores that you're entitled to
> by law, think about the trouble you have to go through to identify
> yourself with multiple-choice questions about your past financial
> life. Outside the US, it's even harder because privacy laws limit the
> sources of data. As demographics shift and more and more people get
> comfortably online/mobile, identification gets easier because an
> organization funneled someone through the process once and now owns
> the "hygiene" of that credential over time -- /everyone/ can amortize
> the investment. However, of course, data privacy gets more challenging.
>
>
> *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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=4_28RyfGvM2JnAA2r2PC92ouszRmNenZ1TmMlmOhcg8&e=>
> community!
>
> On Mon, Aug 3, 2015 at 7:52 PM, Adrian Gropper <agropper at healthurl.com
> <mailto:agropper at healthurl.com>> wrote:
>
> I'm paying $15K / year for health insurance with a $4K deductible
> through my insurance exchange. I just saved $200 out-of pocket on ONE
> prescription by looking it up in GoodRX. If I was living in any other
> rich country, my insurance would be less than half that and the
> prescription hassles would be much less.
>
> The information system is rigged against the consumer in every way
> they can think of. Most of it involves sharing our information
> selectively beyond our control. We are being farmed.
>
> Adrian
>
> On Mon, Aug 3, 2015 at 10:01 PM, Aaron Seib <aaron.seib at nate-trust.org
> <mailto:aaron.seib at nate-trust.org>> wrote:
>
> I am serious – what is the performance requirements to operate an UMA
> server for one patient? I wasn’t giving you a hard time.
>
> If we assume that we want to make this work for 10 million people in
> the population tomorrow what do we have to pay to make it work? I am
> assuming that there are hosting requirements for an UMA server and
> every consumer needs to be trained on how to use it.
>
> What is trivial? Is it $10 per person per year? $0.10 per person per
> year? What is required to make it operational? How much will they
> need to get paid to establish it?
>
> Are there comparable deployments that are operating at that scale that
> we can refer to from other consumer domains?
>
> I am making this point as I don’t want to inadvertently exclude
> options that should be considered for some transactions if they are
> sufficient if they have the same outcome at a lower cost per
> transaction for some transactions.
>
> You ask who wouldn’t want to have every transaction verified against
> their own UMA server? The person who is paying a per transaction fee
> to get it done for them.
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311 <tel:301-540-2311>
>
> (m) 301-326-6843 <tel:301-326-6843>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=sCSOzpc0Dh4XfwS-oVrarXol9DJR1znq3FaRb45-Plg&e=>
>
> *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:* Monday, August 03, 2015 9:07 PM
>
>
> *To:* Aaron Seib
> *Cc:* Id Coach; openid-specs-heart at lists.openid.net
> <mailto:openid-specs-heart at lists.openid.net>
> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
> use case template
>
> On Mon, Aug 3, 2015 at 6:31 PM, Aaron Seib <aaron.seib at nate-trust.org
> <mailto:aaron.seib at nate-trust.org>> wrote:
>
> I don’t get the assertion that FHIR avoids the patient identity
> problem. I don’t get this assertion. Can you get the crayons out
> and explain that to me?
>
> Why don't we have a banking identity problem? It's because people
> self-identify to their bank and their merchant. When somebody moves
> our money without that, we call it theft.
>
> Self-identification is core to OAuth. You don't even need UMA and the
> patient ID problem disappears.
>
> What confuses the issue is discovery. In banking, we don't try to make
> our banking or shopping activity open to discovery. In the case of
> some purchases, we actually try to hide it. In general, to the extent
> our purchasing habits are subject to surveillance, we consider it
> creepy and opt for systems like cash or ApplePay where the merchants,
> at least, can't sell our purchase data to the data brokers.
>
> For some reason, healthcare starts from the assumption that people's
> private activity needs to be tracked whether they like it or not by
> dozens of "exchanges" and data brokers that we don't even know about.
> We are treating people the way we do cows in the feedlot. In banking
> we have three credit bureaus that track some of your activity but
> they're regulated and we have access to "free credit reports". Good
> luck trying to get the equivalent for your health care. For example,
> in many states, we have the equivalent of state credit bureaus in the
> form of All Payer Claims Database. Not one of them lets the patient
> access, check for errors, or benefit from this credit bureau behavior.
> Who wouldn't want a report from their All Payer Claims Database at the
> end of the yer when it's time to choose a Bronze, Silver, Gold or
> Platinum deductible form the health insurance exchange?
>
> It sounds Miraculous and as far as assertions about software
> capabilities are concerned I am an agnostic.
>
> What are the pre-conditions that allow for the patient identity
> problem is addressed. What problem is created by eliminating that
> one?
>
> Just so I am clear – the patient-centric approach essentially says
> that each individual has an UMA server set up that captures their
> privacy preference and subsequent changes through time. Whenever
> data about the consumer is to be exchanged the service is checked
> to determine if the disclosure is permitted.
>
> Yes.
>
> I would like to have an understanding of the performance
> considerations of such a system so we can start the procurement
> process now.
>
> We already have this understanding. Bulk transfer of patient data
> dates back to the paper and mainframe days. It works just as well for
> hackers as it does for the primary business. It seems to take 4-8
> months to discover a breach of millions of records. The system is
> certainly very efficient. It's time to introduce technology on the
> part of the user. The friction you're worried about is a good thing.
> It means the subject is aware of their data being moved from one
> custodian to another and breaches would be reported in minutes. The
> computing cost of this notice is now trivial. Think of the UMA server
> as simply a convenient way for your "providers" to notify you of data
> transfers out of your account. What patient or family caregiver would
> say no to that?
>
> Adrian
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311 <tel:301-540-2311>
>
> (m) 301-326-6843 <tel:301-326-6843>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=sCSOzpc0Dh4XfwS-oVrarXol9DJR1znq3FaRb45-Plg&e=>
>
> *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:* Monday, August 03, 2015 11:22 AM
> *To:* Aaron Seib
> *Cc:* Id Coach; openid-specs-heart at lists.openid.net
> <mailto:openid-specs-heart at lists.openid.net>
>
>
> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case
> AND use case template
>
> Aaron,
>
> My definition of "patient-centric" is what we use in The Society
> for Participatory Medicine: "Nothing about me without me."
>
> This is not as hypothetical as it sounds. A number of us in HEART
> worked on the "Privacy on FHIR" pilot for last HIMSS. We demoed a
> patient-centered system that included private EHR, gov EHR, 42CFR
> Part 2 sensitive data, PHR, phone apps, and wearable IoT devices
> all sharing data using FHIR.
> http://wiki.siframework.org/file/view/HIMSS15_Privacy%20on%20FHIR%20FINAL.PDF/555755441/HIMSS15_Privacy%20on%20FHIR%20FINAL.PDF
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.siframework.org_file_view_HIMSS15-5FPrivacy-2520on-2520FHIR-2520FINAL.PDF_555755441_HIMSS15-5FPrivacy-2520on-2520FHIR-2520FINAL.PDF&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=raPiIPoJutNckiSpXupDug4l3yKctfT8REEI8MxBKbs&e=>
> The use of a single UMA Authorization Server for Alice across all
> of these FHIR resources is the embodiment of "Nothing about me
> without me."
>
> The patient-centered or patient-directed approach to FHIR solves,
> or at least avoids, the very difficult patient ID problem. It buys
> us time while cybersecurity initiatives like NSTIC/IDESG figure
> out how to implement practical trust frameworks for identity and
> related verified attributes. Human ID is not a healthcare-specific
> issue, because we don't license human patients. While others work
> on Human ID, we can use the patient-directed approach to match
> patients across institutions.
>
> The patient-directed approach also avoids the difficult problem of
> delegation to a family caregiver or custodian. Instead of every
> FHIR resource having to implement a delegation method and policy,
> that responsibility shifts to the patient's AS and becomes mostly
> transparent to the resource server.
>
> The patient-directed approach provides increased cybesecurity
> because the AS is consulted for every new interface access. This
> means that breaches can be discovered in minutes instead of
> months. This also fulfills the much-delayed Accounting for
> Disclosures requirement in HIPAA.
>
> The patient-directed approach avoids most of the provenance issues
> because information flows directly from one institution to another
> without the opportunity for delay or corruption by intermediary
> PHRs or HIEs.
>
> The patient-directed approach solves the "multiple portals"
> problem. Once registration is complete, the patient or custodian
> need not interact with the patient portal at the Resource Server
> again. In some cases, it's possible that the resource server can
> avoid running a patient portal altogether by allowing a staff
> member to complete enrollment of the patient's AS as part of
> registration.
>
>
> The Russian Dolls metaphor doesn't work for me. What I see is a
> simple bifurcation at the root of FHIR design: either you enable a
> patient-specified Authorization Server as a third-party in
> server-client FHIR exchange or you don't. If you start down the
> UMA branch, then all of the benefits above accrue downstream. If
> you don't start down the UMA branch, then complexity explodes as
> we try to invent accessory actors, federations and governance
> mechanisms.
>
> Adrian
>
> On Mon, Aug 3, 2015 at 10:00 AM, Aaron Seib
> <aaron.seib at nate-trust.org <mailto:aaron.seib at nate-trust.org>> wrote:
>
> Adrian,
>
> Hi – I agree with your assessment regarding the sufficiency of
> oAuth for the use case as documented. It is a good way and block
> and tackle the problem space to get to consensus of what separate
> components are capable of doing and resolving them from the basic
> to the complex.
>
> Does everyone agree with that starting point?
>
> For discussion purposes lets assume we have consensus on that.
> For the use case where the consumer has PGHD that the Provider
> wants oAuth is sufficient.
>
> This sentence from your email:
>
> If the problem is to begin HEART with a patient-centricity as the
> problem, then this particular use-case distorts the discussion by
> presuming Alice wants a PHR and diminishes the patient-centered
> benefits of UMA as a health information exchange technology.
>
> I want to parse that better so I understand – can you help edify
> me about what is meant by “patient-centricity as the problem”?
>
> I don’t have the same feelings about the fact that part of the
> work HEART is doing is inventorying what the different use cases
> are and their sufficiency. In fact I think this step may prove
> informative to the end point that we are all pursuing.
>
> One use case that is important that doesn’t follow the “Consumer
> has PGHD that the Provider Wants” that readily comes to mind is
> the pattern of Provider A having PHI about Patient X that Provider
> B (whom has a patient-provider relationship with Patient X) should
> have if and only iff (IFF) it is aligned with the privacy
> preferences of Patient X for Provider B to have said data.
>
> To close the loop – is that a statement of a patient-centricity
> use case? Does what we are learning with the first use case
> inform what needs to be done to satisfy the second use case?
>
> From a laypersons perspective I see a Russian Dolls exposition of
> the use cases one building on another until we solve the problems
> established by this work groups charter.
>
> Thank you for letting me share.
>
>
> Aaron
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311 <tel:301-540-2311>
>
> (m) 301-326-6843 <tel:301-326-6843>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=sCSOzpc0Dh4XfwS-oVrarXol9DJR1znq3FaRb45-Plg&e=>
>
> *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:* Sunday, August 02, 2015 2:30 PM
> *To:* Id Coach
> *Cc:* openid-specs-heart at lists.openid.net
> <mailto:openid-specs-heart at lists.openid.net>
> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case
> AND use case template
>
> Thank you Eve!! I hope we can reach consensus on something like
> the format you present.
>
>
>
> Narratives are much easier to understand when they begin with a
> clear statement of the problem. Shouldn't use cases be asked to
> clearly state the problem they are trying to solve right up front?
>
> This particular use-case seems to be trying to solve some or all
> of three problems: federated sign-in, eliminating the registration
> clipboard hassle, and updating a PHR with encounter results. All
> of these can be solved by OAuth alone.
>
> If the problem is to begin HEART with a patient-centricity as the
> problem, then this particular use-case distorts the discussion by
> presuming Alice wants a PHR and diminishes the patient-centered
> benefits of UMA as a health information exchange technology.
>
> I've tried to clarify these fundamental issues in my comments on
> the document and hope we can resolve this before we move on to
> semantic profiling and scopes.
>
> Adrian
>
> On Sat, Aug 1, 2015 at 3:32 PM, Id Coach <coach at digitalidcoach.com
> <mailto:coach at digitalidcoach.com>> wrote:
>
> Thanks Eve,
>
> This is wonderful. I questioned/commented on things only a newbie
> is likely to ask/care about.
>
> It's also a useful template for other use cases. To your point
> about explaining oAuth and other template terms, you're using a
> new language and a new ecosystem to many, so I encourage those
> template terms to be explained over and over again as needed and
> as appropriate.
>
> It will be helpful to me to illustrate or diagram this process.
> I'll take a crack at that in the next few days (I hope).
>
> judi
>
> On 8/1/15 11:20 AM, Eve Maler wrote:
>
> Completing my action item, you'll find our (well-worn :-) use
> case document here
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1IvbdWerdvMuA1dQ-2DKQvVKqIBrAas7FoenNVUtgpqYrw_edit-3Fusp-3Dsharing&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=mFAukEQMozyggbR5vc6wYMWgsvuGIr11-W6P-mLm6Qo&e=>.
> Following is my proposal. If we like what I've done here, I
> recommend that we:
>
> * Edit the doc title to match the use case title I've
> supplied (just below the horizontal line).
>
> * Resolve all the comments above my title (fear not, they're
> all accounted for in the comments I've inserted) and
> delete all the text above that point (I've retained all
> our existing text above the line, just in case).
>
> * Resolve all the comments I've inserted -- as quickly as
> possible! We don't have to take up call time to do the
> minor ones, if people take the initiative to review them
> offline and supply their feedback as responses to this
> note. Note that, in this new template, I have avoided the
> use of the comment mechanism for anything that should be a
> permanent part of the document.
>
> * Ask people to write their other use cases in GDoc using
> this style.
>
> * Obviously, if you have suggestions on how to improve the
> template, weigh in! If you want to make invasive
> suggestions, contact me and we can do a collaborative
> editing session together.
>
> I'm extremely glad I finally did this exercise, because it
> caused me to understand more of what we need to consider
> profiling and more of the "health SME" point of view. And, to
> be honest (perhaps forestalling a comment from Justin ;-), I
> don't feel that it was wasteful to go to this degree of
> mapping to the technologies because it flushed out some
> mismatches that really didn't make sense to me all this time.
> I now feel we can go straight to the heart (ahem) of the
> profiling matter with as many future use cases as we want, and
> in fact, we can begin profiling and write more use cases in
> parallel.
>
> Thanks to you all for letting me "get my OCD on".
>
> *Eve Maler
> *ForgeRock Office of the CTO | VP Innovation & Emerging Technology
> Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype:
> xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=4_28RyfGvM2JnAA2r2PC92ouszRmNenZ1TmMlmOhcg8&e=>
> community!
>
> _______________________________________________
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=geQ1ZsX_giIQGAL84fp3sIEs22LGa_0NPs1RWXN6Ez8&e=>
>
>
> _______________________________________________
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=geQ1ZsX_giIQGAL84fp3sIEs22LGa_0NPs1RWXN6Ez8&e=>
>
>
>
>
> --
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=-4miLc7Egd2FzqscJ3w9BngaBnCpHmpDOGnBzRZ3d24&e=>
>
>
>
>
>
> --
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=-4miLc7Egd2FzqscJ3w9BngaBnCpHmpDOGnBzRZ3d24&e=>
>
>
>
>
>
> --
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=-4miLc7Egd2FzqscJ3w9BngaBnCpHmpDOGnBzRZ3d24&e=>
>
>
>
>
>
> --
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=-4miLc7Egd2FzqscJ3w9BngaBnCpHmpDOGnBzRZ3d24&e=>
>
>
>
> _______________________________________________
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=geQ1ZsX_giIQGAL84fp3sIEs22LGa_0NPs1RWXN6Ez8&e=>
>
>
>
> _______________________________________________
> 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/20150804/76d01d45/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150804/76d01d45/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150804/76d01d45/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3147 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150804/76d01d45/attachment-0005.jpe>
More information about the Openid-specs-heart
mailing list