[Openid-specs-heart] Identity Federation?

Fri Aug 14 17:15:35 UTC 2015

Hi Danny-- Identity federation is the process of a service or application,
such as a website (like an EHR portal) accepting the results of user
authentication having been performed by a different service (like a
government eID system or a bank or the AMA, or some other trustworthy
party). It's federated, vs. local, because even though the EHR portal has
an account for you, they don't have to perform the login duties for that
account themselves -- it comes from afar (like a federation of states or
planets :-) that work together).

When people say "*an* identity federation", they usually mean a group of
organizations that have agreed to work together under a standard agreement
that lays out the responsibilities and rights of the parties. Trusting
someone else to do authentication for you is a big step. If the person's
identity needs to have been proofed too (what we've been talking about
lately -- the mapping of someone's identity credential to a real-world
person), then the trustworthiness requirements on the "identity provider"
go way up. Facebook, for example, simply won't do.

*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 Fri, Aug 14, 2015 at 9:07 AM, Danny van Leeuwen <danny at health-hats.com>
wrote:

> What is Identity Federation?
>
> On Tuesday, August 11, 2015, <openid-specs-heart-request at lists.openid.net>
> wrote:
>
>> 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: Draft HEART Meeting Notes 2015-08-10 (Aaron Seib)
>>    2.  Draft HEART Meeting Notes 2015-08-10 (Adrian Gropper)
>>    3. Re: Draft HEART Meeting Notes 2015-08-10 (Aaron Seib)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 11 Aug 2015 09:34:58 -0400
>> From: "Aaron Seib" <aaron.seib at nate-trust.org>
>> To: "'Adrian Gropper'" <agropper at healthurl.com>, "'Kinsley, William'"
>>         <BKinsley at nextgen.com>
>> Cc: openid-specs-heart at lists.openid.net
>> Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-08-10
>> Message-ID: <05f601d0d43a$84d61a40$8e824ec0$@nate-trust.org>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I am confused or might have a friendly amendment for what you are trying
>> to communicate.
>>
>>
>>
>> Are you positing to the group that item (3) is out of scope because it is
>> an Identity Federation feature and by definition not part of the charter of
>> the HEART project?
>>
>>
>>
>> If that is what you are saying could you please tell me who is working on
>> enabling the inclusion of the PCP?s Identity Proofing of Alice in
>> determining the level of assurance associated with her accounts (in any
>> system ? PHR, EMR or the portals thereof)?
>>
>>
>>
>> This is what I am trying to discover.  When the PCP has a
>> patient-provider relationship established with Alice and he is provide with
>> Alice?s URL to her AS I am very interested in how we can reuse this ID
>> proofing event to increase the level of assurance associated with Alice?s
>> AS.  There are many ways to remote Identity proof Alice that have cost
>> associated with them.  If we can capture the ID Proofing event (I assume
>> that a URL and some unique Identifier related to Alice is required in the
>> HEART transactions when Alice has her privacy preferences configured in an
>> AS that has multiple users) from when the PCP trust the URL/GUID associated
>> with Alice for an AS it would create value too.
>>
>>
>>
>> In other words ? how do we make it possible for relying parties other
>> than Alice?s PCP to discover that her PCP has come to trust the binding of
>> Alice?s Identity to a specific URL/ID for her AS?
>>
>>
>>
>> Is that being discussed anywhere other than the HEART project?
>>
>>
>>
>>
>>
>> Aaron Seib, CEO
>>
>> @CaptBlueButton
>>
>>  (o) 301-540-2311
>>
>> (m) 301-326-6843
>>
>>
>>
>>
>>
>> From: Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
>> Sent: Monday, August 10, 2015 7:33 PM
>> To: Kinsley, William
>> Cc: openid-specs-heart at lists.openid.net
>> Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-08-10
>>
>>
>>
>> (Proposed) Problem Statement (for HEART EHR-PHR Use Case:
>>
>> This use-case is designed to (1) enable automated update of Alice's PHR
>> when new findings or orders are entered by the physician or practice staff
>> into the practice's EHR; (2) to enable messaging with attached documents
>> from the practice's EHR via Alice's PHR; and (3) to enable _________ by
>> allowing the practice to identity proof Alice's persona as authenticated by
>> Alice's PHR.
>>
>> Discussion of proposed problem statement:
>>
>> I think I understand the intent, but I'm having a difficult time coming
>> up with a transaction that would be enabled or even enhanced by (3). The
>> intent could be to enhance an un-tethered PHR like Microsoft HealthVault or
>> a health information exchange that don't have an in-person relationship
>> with Alice in case Alice loses her password and forgets her secret
>> questions. In that case, Alice could presumably go to her PCP's office or
>> any other practice that is federated with the PHR or HIE and present a
>> verified ID to reclaim control of her PHR account. As Sarah points out in
>> her comment, this is a federation use-case outside the scope of HEART.
>>
>> Another possible intent could be to enhance the ability for another
>> practice, for example the Quest Lab used by the PCP, to share results with
>> Alice or Alice's PHR through the lab's portal or FHIR interface. This is
>> another situation where the other practice, the Lab, has no in-person
>> relationship with Alice. It's another example of federation because the Lab
>> would have to be federated with the PHR host in order to trust that indeed,
>> the identity proofing was done. I'm not sure how this would work. There's
>> obviously trust between the PCP and the Lab because the PCP sent the order
>> to the Lab directly under the HIPAA TPO exemption but the PHR is another
>> matter.
>>
>> It would be nice if the PCP could send the order to the Lab via the PHR.
>> This would be even more valuable in the case of e-prescribing because Alice
>> would then have the opportunity to shop various pharmacies using, for
>> example GoodRX. With today's EHRs, Alice has lost this ability to shop
>> around except if the EHR prints a paper prescription or lab order. The
>> value of shopping around, in the case of orders for an expensive test such
>> as an MRI can be over $1,000. To enable this benefit, the EHR would have to
>> (a) digitally sign the order and optionally (b) in the case of a controlled
>> substance prescription, identity proof Alice so that the pharmacy can check
>> her ID when she comes to pick up her prescription. Digitally signing the
>> order or prescription (a) before sending it to the PHR under case (1) or
>> (2) above has nothing to do with HEART and may be considered a federation
>> or trust framework issue anyway.
>>
>> Although identity proofing could be valuable for giving Alice access to
>> the portals of labs, pharmacies, and health information exchanges this is
>> purely a matter of federation and doesn't have directly to do with FHIR,
>> OAuth, or UMA. I suggest there is no Problem (3).
>>
>> The relationship between FHIR and Problem (1) and Problem (2) is yet
>> another matter. I suggest we take that up as part of the scopes discussion
>> once we have finalized the Problem Statement.
>>
>>
>>
>> Adrian
>>
>>
>>
>>
>>
>> On Mon, Aug 10, 2015 at 5:21 PM, Sarah Squire <sarah at engageidentity.com>
>> wrote:
>>
>> Most of the discussion was captured in the use case document itself, but
>> I noted the discussion topics here as well just for future reference.
>>
>>
>>
>> Attending:
>>
>>
>>
>> Debbie Bucci
>>
>> Sarah Squire
>>
>> Danny van Leeuwen
>>
>> Andy Oram
>>
>> Robert Horn
>>
>> Mark Russell
>>
>> William Kinsley
>>
>> Eve Maler
>>
>> Adrian Gropper
>>
>> Glen Marshall
>>
>> Andrew Hughes
>>
>> Corey Spears
>>
>> Tom Sullivan
>>
>> Abbie Barbir
>>
>> Thomas Hardjono
>>
>> Justin Richer
>>
>> Edmund Jay
>>
>> Catherine Schulten
>>
>> Chad Evans
>>
>>
>>
>> Next steps:
>>
>>
>>
>> We will continue to address this use case next week.
>>
>>
>>
>> Notes:
>>
>>
>>
>> We worked on closing out issues on the enrollment use case document:
>>
>>
>>
>>  <
>> https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit>
>>
>> https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit
>>
>>
>>
>> Are registration and enrollment interchangeable?
>>
>>
>>
>> Registration is being used for Alice to enroll with both her doctor?s
>> practice and the practice?s patient portal. We could use registration to
>> mean practice registration and enrollment to mean EHR enrollment. When we
>> use the term ?known to the practice? it means that the practice has seen or
>> heard from the patient and the practice has checked for insurance
>> eligibility. A patient can be enrolled into an EHR by a staff member or
>> they can enroll themselves. We decided to use the term ?register? in the
>> title rather than enroll since we are referring to the practice.
>>
>>
>>
>> The PHR and EHR already have an established relationship in this use case
>> so that we do not have to address dynamic registration or service
>> discovery. We have made the decision not to address this problem so that we
>> can focus on other technical questions.
>>
>>
>>
>> Acknowledgement of receipt of privacy practices is peripheral.
>>
>>
>>
>> We have removed the waiting room step since it has been captured in
>> previous steps.
>>
>>
>>
>> We confirmed that the doctor does record the results of the physical
>> examination directly into the EHR without any sort of later transcription.
>>
>>
>>
>> We should not use the word ?results? with regard to a physical exam. We
>> should use the phrase ?clinical findings.?
>>
>>
>>
>> The lab results are peripheral but have been included so that we can come
>> back to them later.
>>
>>
>>
>> The lab results should also include patient instructions such as fasting
>> - this is also peripheral.
>>
>>
>>
>> The problem statement is to autoupdate through the PHR and message
>> through the PHR.
>>
>>
>>
>> Sarah Squire
>>
>> Engage Identity
>>
>>  <http://engageidentity.com/> http://engageidentity.com
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>>
>>
>> --
>>
>>
>>
>> Adrian Gropper MD
>>
>> RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE:  <http://patientprivacyrights.org/donate-2/>
>> http://patientprivacyrights.org/donate-2/
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150811/2087f72c/attachment-0001.html
>> >
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: image001.jpg
>> Type: image/jpeg
>> Size: 3142 bytes
>> Desc: not available
>> URL: <
>> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150811/2087f72c/attachment-0001.jpg
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 11 Aug 2015 13:38:32 -0400
>> From: Adrian Gropper <agropper at healthurl.com>
>> To: Aaron Seib <aaron.seib at nate-trust.org>
>> Cc: "openid-specs-heart at lists.openid.net"
>>         <openid-specs-heart at lists.openid.net>
>> Subject: [Openid-specs-heart]  Draft HEART Meeting Notes 2015-08-10
>> Message-ID:
>>         <
>> CANYRo8jKki8qpxx1QmT5CvQfoPzTskjHv2_wnRk++TNVQ6MPHw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Aaron,
>>
>> Digital identity is being worked on in IDESG. The verification of
>> attributes is one aspect of identity proofing. Privacy is the major issue
>> with identity proofing. In setting up IDESG, NIST tried to be careful to
>> make privacy a "supercommittee" in the governance process.
>>
>> If we wanted to get into this in HEART, we would probably need to start
>> with a use case.
>>
>> Adrian
>>
>> On Tuesday, August 11, 2015, Aaron Seib <aaron.seib at nate-trust.org>
>> wrote:
>>
>> > I am confused or might have a friendly amendment for what you are trying
>> > to communicate.
>> >
>> >
>> >
>> > Are you positing to the group that item (3) is out of scope because it
>> is
>> > an Identity Federation feature and by definition not part of the
>> charter of
>> > the HEART project?
>> >
>> >
>> >
>> > If that is what you are saying could you please tell me who is working
>> on
>> > enabling the inclusion of the PCP?s Identity Proofing of Alice in
>> > determining the level of assurance associated with her accounts (in any
>> > system ? PHR, EMR or the portals thereof)?
>> >
>> >
>> >
>> > This is what I am trying to discover.  When the PCP has a
>> patient-provider
>> > relationship established with Alice and he is provide with Alice?s URL
>> to
>> > her AS I am very interested in how we can reuse this ID proofing event
>> to
>> > increase the level of assurance associated with Alice?s AS.  There are
>> many
>> > ways to remote Identity proof Alice that have cost associated with them.
>> > If we can capture the ID Proofing event (I assume that a URL and some
>> > unique Identifier related to Alice is required in the HEART transactions
>> > when Alice has her privacy preferences configured in an AS that has
>> > multiple users) from when the PCP trust the URL/GUID associated with
>> Alice
>> > for an AS it would create value too.
>> >
>> >
>> >
>> > In other words ? how do we make it possible for relying parties other
>> than
>> > Alice?s PCP to discover that her PCP has come to trust the binding of
>> > Alice?s Identity to a specific URL/ID for her AS?
>> >
>> >
>> >
>> > Is that being discussed anywhere other than the HEART project?
>> >
>> >
>> >
>> >
>> >
>> > 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, August 10, 2015 7:33 PM
>> > *To:* Kinsley, William
>> > *Cc:* openid-specs-heart at lists.openid.net
>> > *Subject:* Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-08-10
>> >
>> >
>> >
>> > (Proposed) *Problem Statement* (for HEART EHR-PHR Use Case:
>> >
>> > This use-case is designed to (1) enable automated update of Alice's PHR
>> > when new findings or orders are entered by the physician or practice
>> staff
>> > into the practice's EHR; (2) to enable messaging with attached documents
>> > from the practice's EHR via Alice's PHR; and (3) to enable _________ by
>> > allowing the practice to identity proof Alice's persona as
>> authenticated by
>> > Alice's PHR.
>> >
>> > Discussion of proposed problem statement:
>> >
>> > I think I understand the intent, but I'm having a difficult time coming
>> up
>> > with a transaction that would be enabled or even enhanced by (3). The
>> > intent could be to enhance an un-tethered PHR like Microsoft
>> HealthVault or
>> > a health information exchange that don't have an in-person relationship
>> > with Alice in case Alice loses her password and forgets her secret
>> > questions. In that case, Alice could presumably go to her PCP's office
>> or
>> > any other practice that is federated with the PHR or HIE and present a
>> > verified ID to reclaim control of her PHR account. As Sarah points out
>> in
>> > her comment, this is a federation use-case outside the scope of HEART.
>> >
>> > Another possible intent could be to enhance the ability for another
>> > practice, for example the Quest Lab used by the PCP, to share results
>> with
>> > Alice or Alice's PHR through the lab's portal or FHIR interface. This is
>> > another situation where the other practice, the Lab, has no in-person
>> > relationship with Alice. It's another example of federation because the
>> Lab
>> > would have to be federated with the PHR host in order to trust that
>> indeed,
>> > the identity proofing was done. I'm not sure how this would work.
>> There's
>> > obviously trust between the PCP and the Lab because the PCP sent the
>> order
>> > to the Lab directly under the HIPAA TPO exemption but the PHR is another
>> > matter.
>> >
>> > It would be nice if the PCP could send the order to the Lab via the PHR.
>> > This would be even more valuable in the case of e-prescribing because
>> Alice
>> > would then have the opportunity to shop various pharmacies using, for
>> > example GoodRX. With today's EHRs, Alice has lost this ability to shop
>> > around except if the EHR prints a paper prescription or lab order. The
>> > value of shopping around, in the case of orders for an expensive test
>> such
>> > as an MRI can be over $1,000. To enable this benefit, the EHR would
>> have to
>> > (a) digitally sign the order and optionally (b) in the case of a
>> controlled
>> > substance prescription, identity proof Alice so that the pharmacy can
>> check
>> > her ID when she comes to pick up her prescription. Digitally signing the
>> > order or prescription (a) before sending it to the PHR under case (1) or
>> > (2) above has nothing to do with HEART and may be considered a
>> federation
>> > or trust framework issue anyway.
>> >
>> > Although identity proofing could be valuable for giving Alice access to
>> > the portals of labs, pharmacies, and health information exchanges this
>> is
>> > purely a matter of federation and doesn't have directly to do with FHIR,
>> > OAuth, or UMA. *I suggest there is no Problem (3).*
>> >
>> > The relationship between FHIR and Problem (1) and Problem (2) is yet
>> > another matter. I suggest we take that up as part of the scopes
>> discussion
>> > once we have finalized the Problem Statement.
>> >
>> >
>> >
>> > Adrian
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Aug 10, 2015 at 5:21 PM, Sarah Squire <sarah at engageidentity.com
>> >
>> > wrote:
>> >
>> > Most of the discussion was captured in the use case document itself,
>> but I
>> > noted the discussion topics here as well just for future reference.
>> >
>> >
>> >
>> > *Attending:*
>> >
>> >
>> >
>> > Debbie Bucci
>> >
>> > Sarah Squire
>> >
>> > Danny van Leeuwen
>> >
>> > Andy Oram
>> >
>> > Robert Horn
>> >
>> > Mark Russell
>> >
>> > William Kinsley
>> >
>> > Eve Maler
>> >
>> > Adrian Gropper
>> >
>> > Glen Marshall
>> >
>> > Andrew Hughes
>> >
>> > Corey Spears
>> >
>> > Tom Sullivan
>> >
>> > Abbie Barbir
>> >
>> > Thomas Hardjono
>> >
>> > Justin Richer
>> >
>> > Edmund Jay
>> >
>> > Catherine Schulten
>> >
>> > Chad Evans
>> >
>> >
>> >
>> > *Next steps:*
>> >
>> >
>> >
>> > We will continue to address this use case next week.
>> >
>> >
>> >
>> > *Notes:*
>> >
>> >
>> >
>> > We worked on closing out issues on the enrollment use case document:
>> >
>> >
>> >
>> >
>> >
>> https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit
>> >
>> >
>> >
>> > Are registration and enrollment interchangeable?
>> >
>> >
>> >
>> > Registration is being used for Alice to enroll with both her doctor?s
>> > practice and the practice?s patient portal. We could use registration to
>> > mean practice registration and enrollment to mean EHR enrollment. When
>> we
>> > use the term ?known to the practice? it means that the practice has
>> seen or
>> > heard from the patient and the practice has checked for insurance
>> > eligibility. A patient can be enrolled into an EHR by a staff member or
>> > they can enroll themselves. We decided to use the term ?register? in the
>> > title rather than enroll since we are referring to the practice.
>> >
>> >
>> >
>> > The PHR and EHR already have an established relationship in this use
>> case
>> > so that we do not have to address dynamic registration or service
>> > discovery. We have made the decision not to address this problem so
>> that we
>> > can focus on other technical questions.
>> >
>> >
>> >
>> > Acknowledgement of receipt of privacy practices is peripheral.
>> >
>> >
>> >
>> > We have removed the waiting room step since it has been captured in
>> > previous steps.
>> >
>> >
>> >
>> > We confirmed that the doctor does record the results of the physical
>> > examination directly into the EHR without any sort of later
>> transcription.
>> >
>> >
>> >
>> > We should not use the word ?results? with regard to a physical exam. We
>> > should use the phrase ?clinical findings.?
>> >
>> >
>> >
>> > The lab results are peripheral but have been included so that we can
>> come
>> > back to them later.
>> >
>> >
>> >
>> > The lab results should also include patient instructions such as
>> fasting -
>> > this is also peripheral.
>> >
>> >
>> >
>> > The problem statement is to autoupdate through the PHR and message
>> through
>> > the PHR.
>> >
>> >
>> >
>> > Sarah Squire
>> >
>> > Engage Identity
>> >
>> > http://engageidentity.com
>> >
>> >
>> > _______________________________________________
>> > Openid-specs-heart mailing list
>> > Openid-specs-heart at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-heart
>> >
>> >
>> >
>> >
>> > --
>> >
>> >
>> >
>> > Adrian Gropper MD
>> >
>> > RESTORE Health Privacy!
>> > HELP us fight for the right to control personal health data.
>> > DONATE: http://patientprivacyrights.org/donate-2/
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150811/dec7a79c/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 11 Aug 2015 14:30:47 -0400
>> From: "Aaron Seib" <aaron.seib at nate-trust.org>
>> To: "'Adrian Gropper'" <agropper at healthurl.com>
>> Cc: openid-specs-heart at lists.openid.net
>> Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-08-10
>> Message-ID: <002401d0d463$d7ae2770$870a7650$@nate-trust.org>
>> Content-Type: text/plain; charset="utf-8"
>>
>> IDESG has been working on this since the start of the Obama
>> administration, right?  Do we know if they have anything useful in this
>> regard so far?
>>
>>
>>
>> The use case that I am hearing ? whether it belongs in HEART or has
>> already been solved for by the funded work of the NSTIC pilots (I think
>> they have graduated some vendors from the program who address these issues
>> already, right?) is the following:
>>
>>
>>
>> ?        Alice is unknown to the PCP practice.  She becomes known by
>> providing the PCP with her AS URL and related identifier information.  The
>> PCP uses that AS to make disclosure decisions because he trust the binding
>> of her identity to the AS.
>>
>> ?        Another provider wants to communicate with Alice.  She remotely
>> sends him her AS URL and related identifier information.  Is there more
>> information in the universe that the new provider can use to increase his
>> level of assurance that Alice is who she says she is without a F2F meeting?
>>
>> ?        I.e., is there any way to discover that the PCP trust the
>> assertion that Alice is who she says she is and uses this AS and related
>> identifier improving confidence in reliance on this information shared
>> remotely by Alice?
>>
>>
>>
>> If the NSTIC projects already considered this and determined that it was
>> a dead end that would be informative.
>>
>>
>>
>> Aaron Seib, CEO
>>
>> @CaptBlueButton
>>
>>  (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, August 11, 2015 1:39 PM
>> To: Aaron Seib
>> Cc: Kinsley, William; openid-specs-heart at lists.openid.net
>> Subject: [Openid-specs-heart] Draft HEART Meeting Notes 2015-08-10
>>
>>
>>
>> Aaron,
>>
>>
>>
>> Digital identity is being worked on in IDESG. The verification of
>> attributes is one aspect of identity proofing. Privacy is the major issue
>> with identity proofing. In setting up IDESG, NIST tried to be careful to
>> make privacy a "supercommittee" in the governance process.
>>
>> If we wanted to get into this in HEART, we would probably need to start
>> with a use case.
>>
>>
>>
>> Adrian
>>
>>
>> On Tuesday, August 11, 2015, Aaron Seib <aaron.seib at nate-trust.org>
>> wrote:
>>
>> I am confused or might have a friendly amendment for what you are trying
>> to communicate.
>>
>>
>>
>> Are you positing to the group that item (3) is out of scope because it is
>> an Identity Federation feature and by definition not part of the charter of
>> the HEART project?
>>
>>
>>
>> If that is what you are saying could you please tell me who is working on
>> enabling the inclusion of the PCP?s Identity Proofing of Alice in
>> determining the level of assurance associated with her accounts (in any
>> system ? PHR, EMR or the portals thereof)?
>>
>>
>>
>> This is what I am trying to discover.  When the PCP has a
>> patient-provider relationship established with Alice and he is provide with
>> Alice?s URL to her AS I am very interested in how we can reuse this ID
>> proofing event to increase the level of assurance associated with Alice?s
>> AS.  There are many ways to remote Identity proof Alice that have cost
>> associated with them.  If we can capture the ID Proofing event (I assume
>> that a URL and some unique Identifier related to Alice is required in the
>> HEART transactions when Alice has her privacy preferences configured in an
>> AS that has multiple users) from when the PCP trust the URL/GUID associated
>> with Alice for an AS it would create value too.
>>
>>
>>
>> In other words ? how do we make it possible for relying parties other
>> than Alice?s PCP to discover that her PCP has come to trust the binding of
>> Alice?s Identity to a specific URL/ID for her AS?
>>
>>
>>
>> Is that being discussed anywhere other than the HEART project?
>>
>>
>>
>>
>>
>> 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, August 10, 2015 7:33 PM
>> To: Kinsley, William
>> Cc: openid-specs-heart at lists.openid.net
>> Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-08-10
>>
>>
>>
>> (Proposed) Problem Statement (for HEART EHR-PHR Use Case:
>>
>> This use-case is designed to (1) enable automated update of Alice's PHR
>> when new findings or orders are entered by the physician or practice staff
>> into the practice's EHR; (2) to enable messaging with attached documents
>> from the practice's EHR via Alice's PHR; and (3) to enable _________ by
>> allowing the practice to identity proof Alice's persona as authenticated by
>> Alice's PHR.
>>
>> Discussion of proposed problem statement:
>>
>> I think I understand the intent, but I'm having a difficult time coming
>> up with a transaction that would be enabled or even enhanced by (3). The
>> intent could be to enhance an un-tethered PHR like Microsoft HealthVault or
>> a health information exchange that don't have an in-person relationship
>> with Alice in case Alice loses her password and forgets her secret
>> questions. In that case, Alice could presumably go to her PCP's office or
>> any other practice that is federated with the PHR or HIE and present a
>> verified ID to reclaim control of her PHR account. As Sarah points out in
>> her comment, this is a federation use-case outside the scope of HEART.
>>
>> Another possible intent could be to enhance the ability for another
>> practice, for example the Quest Lab used by the PCP, to share results with
>> Alice or Alice's PHR through the lab's portal or FHIR interface. This is
>> another situation where the other practice, the Lab, has no in-person
>> relationship with Alice. It's another example of federation because the Lab
>> would have to be federated with the PHR host in order to trust that indeed,
>> the identity proofing was done. I'm not sure how this would work. There's
>> obviously trust between the PCP and the Lab because the PCP sent the order
>> to the Lab directly under the HIPAA TPO exemption but the PHR is another
>> matter.
>>
>> It would be nice if the PCP could send the order to the Lab via the PHR.
>> This would be even more valuable in the case of e-prescribing because Alice
>> would then have the opportunity to shop various pharmacies using, for
>> example GoodRX. With today's EHRs, Alice has lost this ability to shop
>> around except if the EHR prints a paper prescription or lab order. The
>> value of shopping around, in the case of orders for an expensive test such
>> as an MRI can be over $1,000. To enable this benefit, the EHR would have to
>> (a) digitally sign the order and optionally (b) in the case of a controlled
>> substance prescription, identity proof Alice so that the pharmacy can check
>> her ID when she comes to pick up her prescription. Digitally signing the
>> order or prescription (a) before sending it to the PHR under case (1) or
>> (2) above has nothing to do with HEART and may be considered a federation
>> or trust framework issue anyway.
>>
>> Although identity proofing could be valuable for giving Alice access to
>> the portals of labs, pharmacies, and health information exchanges this is
>> purely a matter of federation and doesn't have directly to do with FHIR,
>> OAuth, or UMA. I suggest there is no Problem (3).
>>
>> The relationship between FHIR and Problem (1) and Problem (2) is yet
>> another matter. I suggest we take that up as part of the scopes discussion
>> once we have finalized the Problem Statement.
>>
>>
>>
>> Adrian
>>
>>
>>
>>
>>
>> On Mon, Aug 10, 2015 at 5:21 PM, Sarah Squire <sarah at engageidentity.com>
>> wrote:
>>
>> Most of the discussion was captured in the use case document itself, but
>> I noted the discussion topics here as well just for future reference.
>>
>>
>>
>> Attending:
>>
>>
>>
>> Debbie Bucci
>>
>> Sarah Squire
>>
>> Danny van Leeuwen
>>
>> Andy Oram
>>
>> Robert Horn
>>
>> Mark Russell
>>
>> William Kinsley
>>
>> Eve Maler
>>
>> Adrian Gropper
>>
>> Glen Marshall
>>
>> Andrew Hughes
>>
>> Corey Spears
>>
>> Tom Sullivan
>>
>> Abbie Barbir
>>
>> Thomas Hardjono
>>
>> Justin Richer
>>
>> Edmund Jay
>>
>> Catherine Schulten
>>
>> Chad Evans
>>
>>
>>
>> Next steps:
>>
>>
>>
>> We will continue to address this use case next week.
>>
>>
>>
>> Notes:
>>
>>
>>
>> We worked on closing out issues on the enrollment use case document:
>>
>>
>>
>>  <
>> https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit>
>>
>> https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit
>>
>>
>>
>> Are registration and enrollment interchangeable?
>>
>>
>>
>> Registration is being used for Alice to enroll with both her doctor?s
>> practice and the practice?s patient portal. We could use registration to
>> mean practice registration and enrollment to mean EHR enrollment. When we
>> use the term ?known to the practice? it means that the practice has seen or
>> heard from the patient and the practice has checked for insurance
>> eligibility. A patient can be enrolled into an EHR by a staff member or
>> they can enroll themselves. We decided to use the term ?register? in the
>> title rather than enroll since we are referring to the practice.
>>
>>
>>
>> The PHR and EHR already have an established relationship in this use case
>> so that we do not have to address dynamic registration or service
>> discovery. We have made the decision not to address this problem so that we
>> can focus on other technical questions.
>>
>>
>>
>> Acknowledgement of receipt of privacy practices is peripheral.
>>
>>
>>
>> We have removed the waiting room step since it has been captured in
>> previous steps.
>>
>>
>>
>> We confirmed that the doctor does record the results of the physical
>> examination directly into the EHR without any sort of later transcription.
>>
>>
>>
>> We should not use the word ?results? with regard to a physical exam. We
>> should use the phrase ?clinical findings.?
>>
>>
>>
>> The lab results are peripheral but have been included so that we can come
>> back to them later.
>>
>>
>>
>> The lab results should also include patient instructions such as fasting
>> - this is also peripheral.
>>
>>
>>
>> The problem statement is to autoupdate through the PHR and message
>> through the PHR.
>>
>>
>>
>> Sarah Squire
>>
>> Engage Identity
>>
>>  <http://engageidentity.com/> http://engageidentity.com
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>>
>>
>> --
>>
>>
>>
>> Adrian Gropper MD
>>
>> RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE:  <http://patientprivacyrights.org/donate-2/>
>> http://patientprivacyrights.org/donate-2/
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150811/46581b7f/attachment.html
>> >
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: image001.jpg
>> Type: image/jpeg
>> Size: 3142 bytes
>> Desc: not available
>> URL: <
>> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150811/46581b7f/attachment.jpg
>> >
>>
>> ------------------------------
>>
>> 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 33, Issue 2
>> *************************************************
>>
>
>
> --
> Danny van Leeuwen
> 617-304-4681
>
> *Blog www.health-hats.com <http://www.health-hats.com/> discovering the
> magic levers of best health*
> *Twitter **@healthhats*
>
>
> _______________________________________________
> 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/20150814/287d08fc/attachment-0001.html>