[Openid-specs-heart] Openid-specs-heart Digest, Vol 86, Issue 11
Debbie Bucci
debbucci at gmail.com
Sat Aug 20 12:43:54 UTC 2016
>
>
>
First off - apologies to Catherine & Chance *welcome!) for the delayed
approval. If you use a different email than the one listed on the
listserv then flag needs to be reset.
I don't want to derail the conversation but I was surprised to learn that
in some populations birth dates are not readily known - a best guess or ...
not accurately provided for an number of reasons. So date too may be
mildly dynamic as well.
On Fri, Aug 19, 2016 at 4:44 PM, Catherine Schulten <
catherine.schulten at lifemedid.com> wrote:
> The data attribute "Name" is also mildly dynamic, especially for women who
> may have a maiden Lname for a period of time, then a married Lname and
> revert back to the maiden name after a divorce or she may maintain a maiden
> Lname for a period of time after her marriage and then choose to hyphenate
> later or some other combination of events.
> First names are also mildly dynamic with the use of nicknames and legal
> names.
>
> About the only static demographic attribute is DOB and when you consider a
> possible pool of reasonable dates ranging from today to around 100 years
> ago there is a finite set of 36,500 date possibilities.
>
> Catherine S.
>
>
>
> -----Original Message-----
> From: Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] On Behalf Of openid-specs-heart-request@
> lists.openid.net
> Sent: Thursday, August 18, 2016 12:23 PM
> To: openid-specs-heart at lists.openid.net
> Subject: Openid-specs-heart Digest, Vol 86, Issue 11
>
> Send Openid-specs-heart mailing list submissions to
> openid-specs-heart at lists.openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> or, via email, send a message with subject or body 'help' to
> openid-specs-heart-request at lists.openid.net
>
> You can reach the person managing the list at
> openid-specs-heart-owner at lists.openid.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Openid-specs-heart digest..."
>
>
> Today's Topics:
>
> 1. Re: Resource/Scope Proposal #2 (Danny van Leeuwen)
> 2. Re: Resource/Scope Proposal #2 (Glen Marshall [SRS])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 18 Aug 2016 11:11:18 -0400
> From: Danny van Leeuwen <danny at health-hats.com>
> Cc: HEART List <openid-specs-heart at lists.openid.net>
> Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2
> Message-ID:
> <CAP5tyWv9h1a3kDGvozNRgbN0yPY21sP58_H_ZgerrEbev7ZzMQ at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> As I read the list of resources I wonder about static, mildly dynamic, and
> greatly dynamic or fluid resources. Name, DOB are examples of static
> resources. Allergies, smoking status and procedures are mildly dynamic.
> Medications and plan are quite fluid. What are the implications of this
> static->fluid continuum in this whole discussion?
>
> On Tue, Aug 16, 2016 at 5:15 PM, Nancy Lush <nlush at lgisoftware.com> wrote:
>
> > HEART proposal Example 2
> >
> > (I apologize in advance for such a long email. Also, sorry for the
> > delay as I was away on vacation and catching up.)
> >
> >
> >
> > Justin proposed that team members propose suggested resources, scopes
> > and what they mean. The objective is to suggest positive solutions.
> > None will be totally ?correct? but that is OK because together these
> > suggestions can be combined and adjusted to reach the ?correct?
> > solution. Based on that, I will create another stab as an alternative.
> >
> > 1. First, since HEART is based on FHIR, we should not expect any
> > changes in FHIR, at least for the 1.0 version. The resources should
> > be the FHIR resources. I am stating this as a discrete point. I
> > think we all agree, but I would like to know that we do indeed concur.
> >
> > 2. In an attempt to simplify, my original list of resources was the
> > list of FHIR resources that are implemented by the Argonaut group.
> > Since this is the set that most of the current servers have
> > implemented, we could expect them to be supported first. (I have no
> > objection to the list being the complete list of FHIR resources, if
> > that is preferred by the group.) This subset list also happens to
> > correspond to the Common Clinical Data set. (I am suggesting that we
> > start with this limited set in the assumption that we could implement
> > HEART as soon as it is specified.)
> >
> > ? Patient demographics (Known as ?patient? per FHIR)
> >
> > ? Allergies
> >
> > ? Problems & Health concerns (Conditions)
> >
> > ? Vital Signs (Category of Observations)
> >
> > ? Labs
> >
> > ? Smoking Status
> >
> > ? Care Team (Some vendors have Care Plan of which Care Team is a
> > subset.)
> >
> > ? Medications
> >
> > ? Immunizations
> >
> > ? Goals
> > ---- this next subset of resources could expand on the above list and
> > are a continuation of the Argonaut implementation list.
> >
> > ? UDI (Device)
> >
> > ? Procedures
> >
> > ? Plan of Treatment
> >
> > ? Assessment
> >
> > 3. The chart below is simply to demonstrate to those less familiar
> > with FHIR how this might work. All of these results are per patient.
> >
> > Common Name
> >
> > FHIR Resource
> >
> > Category if applies
> >
> > Other filter
> >
> >
> >
> > Patient demographics
> >
> > Patient
> >
> >
> >
> >
> >
> >
> >
> > Allergies
> >
> > AllergyIntolerance
> >
> >
> >
> >
> >
> >
> >
> > Problems and Health Concerns
> >
> > Condition
> >
> >
> >
> >
> >
> >
> >
> > Vital Signs
> >
> > Observation
> >
> > Vital-signs
> >
> >
> >
> >
> >
> > Lab Results
> >
> > DiagnosticReport
> >
> > Lab
> >
> >
> >
> >
> >
> > Smoking Status
> >
> > Observation
> >
> >
> >
> > Code=72166-2
> >
> >
> >
> > Care Team
> >
> > CarePlan
> >
> > CareTeam
> >
> >
> >
> >
> >
> > Medications
> >
> > MedicationStatement
> >
> >
> >
> >
> >
> >
> >
> > Medications
> >
> > MedicationOrder
> >
> >
> >
> >
> >
> >
> >
> > Immunizations
> >
> > Immunization
> >
> >
> >
> >
> >
> >
> >
> > Goals
> >
> > Goal
> >
> >
> >
> >
> >
> >
> >
> > UDI
> >
> > Device
> >
> >
> >
> >
> >
> >
> >
> > Procedures
> >
> > Procedure
> >
> >
> >
> >
> >
> >
> >
> > Plan of Treatment
> >
> > (Still being defined in re-sprint)
> >
> >
> >
> >
> >
> >
> >
> > Assessment
> >
> > (Still being defined in re-sprint)
> >
> >
> >
> >
> >
> >
> >
> > There are different filters for each resource type. These should not
> > be addressed by HEART in terms of having our patient, Alice, provide
> > varying permissions at that level.
> >
> > The reasons for limiting the resources to a list like this is because
> > they are already implemented and tested for many servers and because
> > they are a great first step. If we can do this in HEART for starters
> > we will have achieved a lot!
> >
> > 4. Terminology: This group often uses different terminology which
> > causes confusion. Eve has suggested several times that we focus on
> > clarifying terminology and has begun that effort in her use case
> document.
> > One term that has bothered me in the past is the term ?Resource Set?.
> > At the HL7 conference, Josh clarified this for me. My current
> > understanding is that UMA uses ?Resource Set? for the same purpose as
> > FHIR uses ?Resource Type?, or as is often shortened in FHIR as
> > ?Resource?. So in FHIR, if we request medications for the patient
> > Alice, we refer to the resource ?Medications?, while UMA refers to
> > this as a ?Resource Set? for the patient Alice. (The result would be
> > a list of medications for Alice.) If this understanding is currently
> incorrect, can someone please correct it?
> >
> > 5. Grouping of resources: Let?s assume that we have agreed on the
> > list of FHIR resources. I propose that we allow Alice to select which
> > of the list she desires to share, with the addition of choices ?all?
> > or ?none?. The requests for the resources by the client would still
> > be made individually for each resource. (To me the notion of ?resource
> set?
> > implied that we would define a set of individual resources ? say by
> > some category. I would advise against using such a notion as it only
> > complicates and does not add any benefits.)
> >
> > 6. Scopes
> >
> > a. Read/Write
> >
> > i. In
> > last week?s meeting, Justin referenced the current scope stream:
> > individual, bulk, read, write. Since we are specifying HEART, I would
> > assume this is always what the patient is specifying. So for HEART,
> > the scope of ?bulk? is not relevant. Further we have scopes of Read,
> > Write, or *. I suggest that we allow Alice to specify Read, Write,
> > and have the ability to specify both. These settings can be set
> > either per resource or for all resources.
> >
> > Two points should be noted:
> >
> > ii.
> Current
> > implementations are supporting ?Read? and do not yet support ?Write?.
> > We may be fine with starting with just ?Read? for version 1.0.
> >
> > iii.
> Since
> > Alice is defining what she is willing to share ? wouldn?t that be the
> > ?Read? case? I can imagine that we will see implementations where
> > Alice controls her RS and in that case could specify ?Write?
> > permissions. For the immediate future, I would be surprised if the
> > EMR would allow Alice to give permissions to Dr. Bob to write to an
> > EMR. There may be a case where Alice can give Dr. Bob permission to
> write to her PHR.
> >
> > b. Dates
> >
> > i. My
> > understanding from yesterday?s conversation was that we do not want to
> > include dates in the scopes on resources, per HEART. There are date
> > filters available for some resources, but that is within the FHIR
> > query specification, an outside of the HEART spec.
> >
> > ii. Eve
> > raised the objective of having expiration dates associated with the
> > permissions granted, but that functionality does not apply to resource
> > date scopes
> >
> > iii. So
> > ?dates? are not considered as a scope per this discussion.
> >
> > c. Confidentiality codes: I was the culprit that initially raised
> > the case of Alice not wanting to share her HIV condition, but only
> > sharing her non-HIV condition. I believe most of us would like to
> > provide such a feature in HEART, but since that original discussion I
> > am now of the opinion that we should NOT include this feature in version
> 1.0.
> >
> > i.
> Confidentiality
> > codes were suggested as a potential solution to this issue. It has
> > been stated that some additional ?magic? needs to occur to make this
> viable.
> > Since it is not currently supported in current FHIR implementation,
> > adding this to HEART in version 1.0 could derail the effort.
> >
> > ii.
> Confidentiality
> > codes are defined in FHIR as tags.
> >
> > iii.
> Confidentiality
> > codes are not implemented in most of the current servers. Even if
> > they were, there is not a consistent method to consistently code
> > values across servers. This could lead to inconsistent results and be
> > worse that not providing the feature at all.
> >
> > iv. If
> > Alice desired to not share her ?HIV? condition, we would need to add a
> > scope to the resource request asking the server to withhold data that
> > matches the requested confidentiality settings. This scope is not
> > currently defined in FHIR and we should not be attempting to change
> > FHIR as part of our HEART 1.0 specification.
> >
> > v. If I
> > were running a RS, I certainly would not be willing to send Alice?s
> > HIV condition to the client tagged as confidential and expect the
> > client to not share it ? instead I would want to not send the data at
> > all ? thus the requirement to add a new scope ? which we should
> definitely avoid.
> >
> >
> >
> > This document is also added as an attachment.
> >
> >
> >
> > -Nancy
> >
> >
> >
> >
> >
> >
> >
> > *Nancy Lush *
> >
> > nancy.lush at lgisoftware.com
> >
> > *Lush Group, Inc*
> >
> > Office: (401) 423-9111
> >
> > 28 Narragansett Ave
> >
> > PO Box 651
> >
> > www.lgisoftware.com
> >
> > Cell:(401) 965-9347
> >
> > Jamestown, RI 02835
> >
> >
> >
> > [image: LGI_logo_small]
> >
> >
> >
> >
> >
> > _______________________________________________
> > Openid-specs-heart mailing list
> > Openid-specs-heart at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-heart
> >
> >
>
>
> --
> Danny van Leeuwen
> 617-304-4681
>
> *Blog www.health-hats.com <http://www.health-hats.com/> discovering the
> magic levers of best health* Twitter <https://twitter.com/HealthHats>
> LinkedIn <https://www.linkedin.com/in/healthhatsdannyvl>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openid.net/pipermail/openid-specs-heart/
> attachments/20160818/c294b546/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image001.gif
> Type: image/gif
> Size: 3006 bytes
> Desc: not available
> URL: <http://lists.openid.net/pipermail/openid-specs-heart/
> attachments/20160818/c294b546/attachment-0001.gif>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 18 Aug 2016 15:49:23 +0000
> From: "Glen Marshall [SRS]" <gfm at securityrs.com>
> To: Danny van Leeuwen <danny at health-hats.com>
> Cc: HEART List <openid-specs-heart at lists.openid.net>
> Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2
> Message-ID:
> <DM5PR05MB32441E897A8521CB19CBB7C3CE150 at DM5PR05MB3244.
> namprd05.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> I depends on the use cases.
>
> However, if we are depending on some sort of metadata tagging for privacy
> classification, more dynamic data has greater cost (no economy of scale)
> and less value (diseconomy of scale) per metadata tag. At some point we
> reach a cross-over where the cost of privacy protection exceeds the risks
> it mitigates.
>
> Yes, the business economic environment is out of scope for HEART. But it
> is not out of scope for implementers. Our work-products need to
> acknowledge the environment, its realities, and its limitations.
>
>
> Glen F. Marshall
> Consultant
> Security Risk Solutions, Inc.
> 698 Fishermans Bend
> Mount Pleasant, SC 29464
> Tel: (610) 644-2452
> Mobile: (610) 613-3084
> gfm at securityrs.com
> www.SecurityRiskSolutions.com<http://www.securityrisksolutions.com/>
>
> From: Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] On Behalf Of Danny van Leeuwen
> Sent: Thursday, August 18, 2016 11:11
> Cc: HEART List <openid-specs-heart at lists.openid.net>
> Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2
>
> As I read the list of resources I wonder about static, mildly dynamic, and
> greatly dynamic or fluid resources. Name, DOB are examples of static
> resources. Allergies, smoking status and procedures are mildly dynamic.
> Medications and plan are quite fluid. What are the implications of this
> static->fluid continuum in this whole discussion?
>
> On Tue, Aug 16, 2016 at 5:15 PM, Nancy Lush <nlush at lgisoftware.com<mailto:
> nlush at lgisoftware.com>> wrote:
> HEART proposal Example 2
> (I apologize in advance for such a long email. Also, sorry for the delay
> as I was away on vacation and catching up.)
>
> Justin proposed that team members propose suggested resources, scopes and
> what they mean. The objective is to suggest positive solutions. None will
> be totally ?correct? but that is OK because together these suggestions can
> be combined and adjusted to reach the ?correct? solution. Based on that, I
> will create another stab as an alternative.
>
> 1. First, since HEART is based on FHIR, we should not expect any
> changes in FHIR, at least for the 1.0 version. The resources should be the
> FHIR resources. I am stating this as a discrete point. I think we all
> agree, but I would like to know that we do indeed concur.
>
> 2. In an attempt to simplify, my original list of resources was the
> list of FHIR resources that are implemented by the Argonaut group. Since
> this is the set that most of the current servers have implemented, we could
> expect them to be supported first. (I have no objection to the list being
> the complete list of FHIR resources, if that is preferred by the group.)
> This subset list also happens to correspond to the Common Clinical Data
> set. (I am suggesting that we start with this limited set in the
> assumption that we could implement HEART as soon as it is specified.)
>
> ? Patient demographics (Known as ?patient? per FHIR)
>
> ? Allergies
>
> ? Problems & Health concerns (Conditions)
>
> ? Vital Signs (Category of Observations)
>
> ? Labs
>
> ? Smoking Status
>
> ? Care Team (Some vendors have Care Plan of which Care Team is a
> subset.)
>
> ? Medications
>
> ? Immunizations
>
> ? Goals
> ---- this next subset of resources could expand on the above list and are
> a continuation of the Argonaut implementation list.
>
> ? UDI (Device)
>
> ? Procedures
>
> ? Plan of Treatment
>
> ? Assessment
>
> 3. The chart below is simply to demonstrate to those less familiar
> with FHIR how this might work. All of these results are per patient.
> Common Name
>
> FHIR Resource
>
> Category if applies
>
> Other filter
>
>
>
> Patient demographics
>
> Patient
>
>
>
>
>
>
>
> Allergies
>
> AllergyIntolerance
>
>
>
>
>
>
>
> Problems and Health Concerns
>
> Condition
>
>
>
>
>
>
>
> Vital Signs
>
> Observation
>
> Vital-signs
>
>
>
>
>
> Lab Results
>
> DiagnosticReport
>
> Lab
>
>
>
>
>
> Smoking Status
>
> Observation
>
>
>
> Code=72166-2
>
>
>
> Care Team
>
> CarePlan
>
> CareTeam
>
>
>
>
>
> Medications
>
> MedicationStatement
>
>
>
>
>
>
>
> Medications
>
> MedicationOrder
>
>
>
>
>
>
>
> Immunizations
>
> Immunization
>
>
>
>
>
>
>
> Goals
>
> Goal
>
>
>
>
>
>
>
> UDI
>
> Device
>
>
>
>
>
>
>
> Procedures
>
> Procedure
>
>
>
>
>
>
>
> Plan of Treatment
>
> (Still being defined in re-sprint)
>
>
>
>
>
>
>
> Assessment
>
> (Still being defined in re-sprint)
>
>
>
>
>
>
>
> There are different filters for each resource type. These should not be
> addressed by HEART in terms of having our patient, Alice, provide varying
> permissions at that level.
>
> The reasons for limiting the resources to a list like this is because they
> are already implemented and tested for many servers and because they are a
> great first step. If we can do this in HEART for starters we will have
> achieved a lot!
>
> 4. Terminology: This group often uses different terminology which
> causes confusion. Eve has suggested several times that we focus on
> clarifying terminology and has begun that effort in her use case document.
> One term that has bothered me in the past is the term ?Resource Set?. At
> the HL7 conference, Josh clarified this for me. My current understanding
> is that UMA uses ?Resource Set? for the same purpose as FHIR uses ?Resource
> Type?, or as is often shortened in FHIR as ?Resource?. So in FHIR, if we
> request medications for the patient Alice, we refer to the resource
> ?Medications?, while UMA refers to this as a ?Resource Set? for the patient
> Alice. (The result would be a list of medications for Alice.) If this
> understanding is currently incorrect, can someone please correct it?
>
> 5. Grouping of resources: Let?s assume that we have agreed on the
> list of FHIR resources. I propose that we allow Alice to select which of
> the list she desires to share, with the addition of choices ?all? or
> ?none?. The requests for the resources by the client would still be made
> individually for each resource. (To me the notion of ?resource set?
> implied that we would define a set of individual resources ? say by some
> category. I would advise against using such a notion as it only
> complicates and does not add any benefits.)
>
> 6. Scopes
>
> a. Read/Write
>
> i. In
> last week?s meeting, Justin referenced the current scope stream:
> individual, bulk, read, write. Since we are specifying HEART, I would
> assume this is always what the patient is specifying. So for HEART, the
> scope of ?bulk? is not relevant. Further we have scopes of Read, Write, or
> *. I suggest that we allow Alice to specify Read, Write, and have the
> ability to specify both. These settings can be set either per resource or
> for all resources.
>
> Two points should be noted:
>
> ii.
> Current implementations are supporting ?Read? and do not yet support
> ?Write?. We may be fine with starting with just ?Read? for version 1.0.
>
> iii. Since
> Alice is defining what she is willing to share ? wouldn?t that be the
> ?Read? case? I can imagine that we will see implementations where Alice
> controls her RS and in that case could specify ?Write? permissions. For
> the immediate future, I would be surprised if the EMR would allow Alice to
> give permissions to Dr. Bob to write to an EMR. There may be a case where
> Alice can give Dr. Bob permission to write to her PHR.
>
> b. Dates
>
> i. My
> understanding from yesterday?s conversation was that we do not want to
> include dates in the scopes on resources, per HEART. There are date
> filters available for some resources, but that is within the FHIR query
> specification, an outside of the HEART spec.
>
> ii. Eve
> raised the objective of having expiration dates associated with the
> permissions granted, but that functionality does not apply to resource date
> scopes
>
> iii. So
> ?dates? are not considered as a scope per this discussion.
>
> c. Confidentiality codes: I was the culprit that initially raised
> the case of Alice not wanting to share her HIV condition, but only sharing
> her non-HIV condition. I believe most of us would like to provide such a
> feature in HEART, but since that original discussion I am now of the
> opinion that we should NOT include this feature in version 1.0.
>
> i.
> Confidentiality codes were suggested as a potential solution to this
> issue. It has been stated that some additional ?magic? needs to occur to
> make this viable. Since it is not currently supported in current FHIR
> implementation, adding this to HEART in version 1.0 could derail the effort.
>
> ii.
> Confidentiality codes are defined in FHIR as tags.
>
> iii.
> Confidentiality codes are not implemented in most of the current servers.
> Even if they were, there is not a consistent method to consistently code
> values across servers. This could lead to inconsistent results and be worse
> that not providing the feature at all.
>
> iv. If
> Alice desired to not share her ?HIV? condition, we would need to add a
> scope to the resource request asking the server to withhold data that
> matches the requested confidentiality settings. This scope is not
> currently defined in FHIR and we should not be attempting to change FHIR as
> part of our HEART 1.0 specification.
>
> v. If I
> were running a RS, I certainly would not be willing to send Alice?s HIV
> condition to the client tagged as confidential and expect the client to not
> share it ? instead I would want to not send the data at all ? thus the
> requirement to add a new scope ? which we should definitely avoid.
>
> This document is also added as an attachment.
>
> -Nancy
>
>
>
>
> Nancy Lush
>
> nancy.lush at lgisoftware.com<mailto:nancy.lush at lgisoftware.com>
>
> Lush Group, Inc
>
> Office: (401) 423-9111<tel:%28401%29%20423-9111>
>
> 28 Narragansett Ave
> PO Box 651
>
> www.lgisoftware.com<http://www.lgisoftware.com>
> Cell:(401) 965-9347<tel:%28401%29%20965-9347>
>
> Jamestown, RI 02835
>
>
>
>
> [LGI_logo_small]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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
>
>
>
> --
> Danny van Leeuwen
> 617-304-4681
>
> Blog www.health-hats.com<http://www.health-hats.com/> discovering the
> magic levers of best health Twitter<https://twitter.com/HealthHats>
> LinkedIn<https://www.linkedin.com/in/healthhatsdannyvl>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openid.net/pipermail/openid-specs-heart/
> attachments/20160818/f537d61f/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image001.gif
> Type: image/gif
> Size: 3006 bytes
> Desc: image001.gif
> URL: <http://lists.openid.net/pipermail/openid-specs-heart/
> attachments/20160818/f537d61f/attachment.gif>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
> ------------------------------
>
> End of Openid-specs-heart Digest, Vol 86, Issue 11
> **************************************************
> _______________________________________________
> 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/20160820/818e3952/attachment-0001.html>
More information about the Openid-specs-heart
mailing list