<div dir="ltr"><div><div>Hi Gunther,<br><br></div>Substituting PHR for RS is possible but redundant. The point of patient-directed interoperability is to reduce the costs and to provide as large a practical network space as possible without the need to invent new governance models like Direct or CommonWell. The cost of PHR-mediated interoperability comes from loss of provenance, delay, and, most expensive, a physician getting incidental findings about tests they did not order. An API, like FHIR, that does supports query/retrieve allows the RqP to get whatever they want without the statutory delays imposed on PHRs, the loss of provenance when everything looks like patient-generated data, and the bundling of information into 76-page CCDAs.<br><br></div><div>The diagram is designed to illustrate a public API to be used by anyone that's authorized with control by BOTH the patient and the institution (RS). UMA allows this to manage both HIPAA and non-HIPPA transactions over the same API. In addition, our Privacy on FHIR demo with the VA this spring showed how UMA based patient-directed exchange can handle 42CFR Part 2 sensitive data. This is something current proprietary and state HIEs cannot do.<br><br></div><div>Alice authorizes Bob at the step "<span style="font-family:monospace,monospace">RqP->AS: Presents Claims\ne.g. <a href="mailto:bob@medicalsociety.org">bob@medicalsociety.org</a></span>" The beauty of UMA is that, depending on what Alice and the RS worked out in Phase 1, this authorization can be handled by Alice's AS as a matter of policy or the AS can actually connect with Alice in the traditional "invitation" dance. You can see a bit more discussion around patient-directed exchange in this post <a href="http://kantarainitiative.org/pipermail/wg-uma/2015-October/003934.html">http://kantarainitiative.org/pipermail/wg-uma/2015-October/003934.html</a><br><br></div><div>Adrian<br></div><div><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 4:43 PM, Meyer, Gunther <span dir="ltr"><<a href="mailto:Gunther.Meyer@allscripts.com" target="_blank">Gunther.Meyer@allscripts.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi Adrian!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I like the simplicity of the diagram, but I want to make sure I understand it.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If I mentally substitute PHR for RS, would that be ok? Just asking because in our last call we talked about Bob being part of the NPE (NYP), and I don’t think
this is the same.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Assuming the above assumption is correct, where in the diagram is the part where Alice authorizes Bob?<u></u><u></u></span></p><span class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Regards<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Gunther<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal" style="line-height:12.0pt"><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5b8f22">Gunther Meyer</span></b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#707176"> |
</span><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#616365">Architect<br>
</span></b><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5b8f22">Allscripts</span></b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#707176"> | 8529 Six Forks Road | Raleigh, NC |27615<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#616365"> <br>
<a href="tel:919.329.1466" value="+19193291466" target="_blank">919.329.1466</a></span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">|
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:green">P<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#616365"><a href="tel:919.457.4466" value="+19194574466" target="_blank">919.457.4466</a></span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">|
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:green">F<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#616365"><br>
</span><u><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5b8f22"><a href="mailto:gunther.meyer@allscripts.com" target="_blank">gunther.meyer@allscripts.com</a></span></u><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"> |
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="http://www.allscripts.com/" target="_blank"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5b8f22">www.allscripts.com</span></a></span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:green">
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#4d4f53">Corporate Headquarters l 222 Merchandise Mart Plaza l 20<sup>th</sup> Floor l Chicago, IL l 60654</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:green"><u></u><u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#76923c"><u></u> <u></u></span></b></p>
<p class="MsoNormal" style="margin-bottom:5.25pt;line-height:15.0pt"><u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#76923c"><u></u><span style="text-decoration:none"> </span><u></u></span></u></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Adrian Gropper<br>
<b>Sent:</b> Tuesday, October 20, 2015 5:52 PM<br>
<b>To:</b> Glen Marshall [SRS] <<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>><br>
<b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-heart] "Individual-to-NPE" sharing episodes in UMA use cases, and "design pattern" solution options<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Our goal is interoperability. I suggest we base our design pattern priorities on (a) the recent GAO report and (b) the doctors in my state medical society.
<br>
<br>
(a) <br>
Electronic Health Records: Nonfederal Efforts to Help Achieve Health Information Interoperability GAO-15-817: Published: Sep 16, 2015. Publicly Released: Sep 29, 2015.<a href="http://www.gao.gov/products/GAO-15-817" target="_blank"> http://www.gao.gov/products/GAO-15-817</a>
that says:<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">"Stakeholders and initiative representatives GAO interviewed described five key challenges to achieving EHR interoperability, which are consistent with challenges described in past GAO work. Specifically, the challenges they described are
(1) insufficiencies in health data standards, (2) variation in state privacy rules, (3) accurately matching patients' health records, (4) costs associated with interoperability, and (5) the need for governance and trust among entities, such as agreements to
facilitate the sharing of information among all participants in an initiative."<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">(b)<br>
Two MA medical society resolutions and our Task Force (which Dr. Sullivan chairs) have all concluded that physicians need to have control over information sharing for their patients without what ONC calls "blocking" by the institutions or EHR vendors that may
be involved. Our Task Force has actually suggested to the AMA that physicians should have a way to get access to the patient-controlled EHR interface. This approach is sometimes referred to as patient-directed exchange. Note that patient-directed exchange
does not mean that the patient gets to see her own data (as with a patient-mediated or PHR exchange). The FHIR resource goes directly from the NPE to the Requesting Party. In this way, and with appropriate FHIR cooperation, this helps solve difficult provenance,
cache consistency, and patient matching issues. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Of the 5 GAO "challenges" (2), (3), and (5) would be completely eliminated by a patient-directed design pattern. (1), the data standards, is a combination of FHIR and HEART outcome. (4), costs, should be equivalent
for any FHIR API design pattern, but even if costs were an issue, the patient-directed exchange allows for patient pay to remove that barrier.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Choosing to deliver a patient-directed design pattern as our HEART baseline does not preclude either FHIR or HEART from delivering other design patterns in the future but it will inform the work of FHIR and
align our efforts with the GAO and physician comments.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Therefore, I propose this <a href="http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQmFzZWxpbmUgSEVBUlQgU2VxdWVuY2UgRGlhZ3JhbQoKcGFydGljaXBhbnQgIkFsaWNlIHJlc291cmNlXG5vd25lciAoUk8pIiBhcyBSTwAhDk5QRQAiC3NlcnYAKQVTACcHUwBOD2dlbnQgYXV0aG9yaXphdGlvbgArCkEALgdBACYPQm9iIGNsaWVudFxuYXBwIChDAIEFBkMAFRJyZXF1ZXN0aW5nXG5wYXJ0eSAoUnFQAIEzB3FQCm5vdGUgb3ZlciBSTywgUlMsIEFTLCBDLAAYBU5QRSA9IE5vbi1QZXJzb24gRW50aXR5IC8gVGhpcyBpcyB0aGUgSW5kaXZpZHVhbC10by0ABAogRGVzaWduIFBhdHRlcm4KZW5kIG5vdGUKCgpSTy0-UlM6IFByZXNlbnRzIEluIABdBgpSUy0-Uk86IEdldHMgQ3JlZGVudGlhbAAqCVNpZ24gSW4gdG8gTlBFIFBvcnRhbAAtCURpc3BsYXkAFgVST0kgRm9ybQAxCnBlY2lmeSBBdXRoJ3ogUwCCXAoAgQgJVGV4dCBSAINkByBEZXNjcmlwdGlvbgCBLgVBAHIOAIM2BgB7BwCBNAVBUzogRkhJUgAtFkEAgVQHAEMiQ29uZmlybQCBJQUAhA8JIFBvbGljaWVzAEMGAB0KXG4AgSkJUmVnaXN0cgCEQwUAgQkJQ29uc2VudCBSZWNlaXB0CgCDYBUKIEVuZCBvZiBVTUEgUGhhc2UgMQCDKAsAhB0LAIQWDiBScVAgZGlzY292ZXIAhAsGAIYjCCB2aWEgbWVzc2FnZSBvciBkaXJlY3RvcnkgcXVlcnkAhAYLUnFQAIJYBgCECAlDbGFpbXNcbmUuZy4gYm9iQG1lZGljYWxzb2NpZXR5Lm9yZwCCSgZxUACEGRMARwgAgyEMUwBcCk1heSBuZWVkIHRvAIIrB2VyIEMAhkwFAIMgBUMAgiISQwCDeAZSAIZJBnMAgwwOAC0IR3JhbgALEQCCIBsAgmERMgCGGwogCkMAhh4GQWNjZXNzAIRJDgCEZAlBY2NvdW50aW5nIGZvciBEaXNjbG9zdXIAgxUdAINYETMAhxAMCg&s=mscgen" target="_blank">
Baseline HEART Sequence Diagram</a> based on the <b>Individual to Individual</b> design pattern (also supported by Justin's comment above).
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Here's the source code for anyone to improve or fork.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<span style="font-size:7.5pt;font-family:"Courier New"">title Baseline HEART Sequence Diagram<br>
<br>
participant "Alice resource\nowner (RO)" as RO<br>
participant "NPE resource\nserver (RS)" as RS<br>
participant "Agent authorization\nserver (AS)" as AS<br>
participant "Bob client\napp (C)" as C<br>
participant "Bob requesting\nparty (RqP)" as RqP<br>
note over RO, RS, AS, C, RqP<br>
NPE = Non-Person Entity / This is the Individual-to-Individual Design Pattern<br>
end note<br>
<br>
<br>
RO->RS: Presents In Person<br>
RS->RO: Gets Credential<br>
RO->RS: Sign In to NPE Portal<br>
RS->RO: Display NPE ROI Form<br>
RO->RS: Specify Auth'z Server (AS)<br>
RO->RS: Text Resource Description<br>
RO->AS: Sign In to Agent Portal<br>
<br>
RS->AS: FHIR Resource Description<br>
AS->RO: Text Resource Description<br>
RO->AS: Confirm Authorization Policies<br>
AS->RS: Confirm\nResource Registration<br>
RS->AS: Consent Receipt<br>
<br>
note over RO, RS, AS<br>
End of UMA Phase 1<br>
end note<br>
<br>
note over RS, AS, C, RqP<br>
RqP discovers the resource via message or directory query<br>
end note<br>
<br>
RqP->AS: Presents Claims\ne.g. <a href="mailto:bob@medicalsociety.org" target="_blank">bob@medicalsociety.org</a><br>
AS->RqP: Gets Credential<br>
RqP->AS: Sign In to AS<br>
RqP->AS: May need to Register Client<br>
AS->C: Consent Receipt<br>
C->AS: Requests Authorization<br>
AS->C: Grants Authorization<br>
<br>
note over RS, AS, C, RqP<br>
End of UMA Phase 2<br>
end note<br>
<br>
C->RS: Access FHIR Resource<br>
RS->AS: Accounting for Disclosure<br>
<br>
note over RS, AS, C, RqP<br>
End of UMA Phase 3<br>
end note</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Adrian<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br>
<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, Oct 20, 2015 at 11:30 AM, Glen Marshall [SRS] <<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">For the individual-to-role pattern, HL7 has a role based access control standard. It includes and extensive vocabulary of healthcare roles, and it is extensible. This can be used to share access control role semantics across authorization
services. <br>
<br>
The individual-to-NPE and individual-to-role patterns presents some interesting challenges. One of them is that the mapping of access permissions depends on the location and work assignments. For example, health care staff may be assigned to different care
locations and have legitimate access only to the patients' data for that location. Similarly, the role assigned to a person will vary. I do not know how amenable these cases are to technical solutions. Current practice is to assume compliance of the staff
to institutional policies.<br>
<br>
What identifying data needs to be shared among users to access Alice's [current] authorizations? What is its provenance?
<br>
<u></u><u></u></p>
<div>
<p><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: <a href="tel:%28610%29%20644-2452" target="_blank">(610) 644-2452</a><br>
Mobile: <a href="tel:%28610%29%20613-3084" target="_blank">(610) 613-3084</a><br>
<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br>
<a href="http://www.SecurityRiskSolutions.com" target="_blank">www.SecurityRiskSolutions.com</a><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On 10/19/15 16:00, Eve Maler wrote:<u></u><u></u></p>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">I promised to write this up, and hopefully I'll make it before the deadline of today's call.
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The subject line introduces what I hope will be useful consistent wording for discussing these sorts of topics. Some of our UMA use cases include episodes of party-to-party resource sharing that involve a resource owner who is an individual
(say, a patient or consumer), and a requesting party that <b>is, or is the agent of,</b> a "non-person entity" or NPE, such as a hospital, government agency, or company.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Staying entirely within the confines of the UMA protocol, a number of different "design patterns" could be chosen for deployment. Agreeing on which reasons to use which patterns, and locking down any areas of variability, could help make
systems interoperate with each other. The UMA protocol, in fact, expects such variability and recommends profiling to improve interoperability. Thus, it seems a good idea for us to figure out how much such types of interop are in scope for us, and likely <b>do
some profiling in these areas</b>.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Here are four patterns I can think of:<u></u><u></u></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal">
<b>Individual-to-agent-of-NPE</b>: Alice the individual RO shares with "the individual RqP who can prove they control the identifier 'Dr. Bob'" (possible also constraining the client in use as well -- we'll leave that part out for this analysis).<u></u><u></u></li><li class="MsoNormal">
<b>Individual-to-NPE</b>: Alice the individual RO shares with "the NPE RqP that can prove they control the identifier 'New York Presbyterian Hospital'". Some process yet to be determined, possibly involving "chained delegation", ensures that Dr. Bob and possibly
others who work for NYP get access thereafter.<u></u><u></u></li><li class="MsoNormal">
<b>Individual-to-role</b>: Alice the individual RO shares with "any RqP who can prove they have been assigned the role 'works for NYP'".<u></u><u></u></li><li class="MsoNormal">
<b>Individual-to-individual</b>: Alice the individual RO shares with "the individual RqP who can prove they control the identifier 'bob@gmail'" (whom she knows is her doctor because he provisioned her with that gmail handle). Bob might do "chained delegation"
to share the resource with himself as an employee of NYP.<u></u><u></u></li></ol>
</div>
<div>
<p class="MsoNormal">The reason interop questions arise is because the process of UMA trust elevation involves things like claims-gathering and possibly step-up authentication, and the policy-setting options presented to Alice (which are out of band of UMA,
but nonetheless...) need to be driven by these requirements. The ability of the requesting sides to respond appropriately will be triggered off of expectations about what they'll be asked to cough up for trust elevation.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Each pattern has pros and cons. Briefly:<u></u><u></u></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal">
The one I'm least enamored of is #3; enterprise access control has had so much trouble with RBAC, so can we expect adding UMA to help? :-)<u></u><u></u></li><li class="MsoNormal">
Chained delegation can be very powerful. In environments where everybody uses the same UMA authorization server, a number of nice value-add features can be supported, but they tend to break down (at least with UMA V1.0.x) when you add the ability for every
RO to choose their own AS.<u></u><u></u></li><li class="MsoNormal">
I worry about sharing with individual doctors. It's very expedient, so people will tend to do it as a path of least resistance (think Google Apps!). And sometimes maybe it's the right answer, particularly if "chained delegation" can allow Alice to track where
her resource has been shared further. But what if Dr. Bob leaves the hospital/practice/whatever? Is this always the right answer?<u></u><u></u></li><li class="MsoNormal">
Sharing with an NPE sounds elegant -- it's what a recent POC of my acquaintance did. But the "process yet to be determined" mentioned above wasn't actually determined yet, so there's that. :-) And you have the problem of a system administrator who has privileged
identity credentials to the NPE account -- as always -- having the key to a pretty valuable kingdom. Maybe a cool mitigation of this risk is to go with sharing with individuals and tracking sharing chains?<u></u><u></u></li></ul>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<p><b>Eve Maler<br>
</b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>
Cell <a href="tel:%2B1%20425.345.6756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>
Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
</div>
</div>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>Openid-specs-heart mailing list<u></u><u></u></pre>
<pre><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><u></u><u></u></pre>
<pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- <u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Adrian Gropper MD<br>
<br>
<span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
HELP us fight for the right to control personal health data.<br>
DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span>
<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>