[Openid-specs-heart] Identity Federation?

Danny van Leeuwen danny at health-hats.com
Fri Aug 14 16:07:34 UTC 2015 

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 <javascript:;>
>
> 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 <javascript:;>
>
> You can reach the person managing the list at
>         openid-specs-heart-owner at lists.openid.net <javascript:;>
>
> 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 <javascript:;>>
> To: "'Adrian Gropper'" <agropper at healthurl.com <javascript:;>>,
> "'Kinsley, William'"
>         <BKinsley at nextgen.com <javascript:;>>
> Cc: openid-specs-heart at lists.openid.net <javascript:;>
> 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 <javascript:;>] On Behalf Of
> Adrian Gropper
> Sent: Monday, August 10, 2015 7:33 PM
> To: Kinsley, William
> Cc: openid-specs-heart at lists.openid.net <javascript:;>
> 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
> <javascript:;>> 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 <javascript:;>
> 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 <javascript:;>>
> To: Aaron Seib <aaron.seib at nate-trust.org <javascript:;>>
> Cc: "openid-specs-heart at lists.openid.net <javascript:;>"
>         <openid-specs-heart at lists.openid.net <javascript:;>>
> Subject: [Openid-specs-heart]  Draft HEART Meeting Notes 2015-08-10
> Message-ID:
>         <
> CANYRo8jKki8qpxx1QmT5CvQfoPzTskjHv2_wnRk++TNVQ6MPHw at mail.gmail.com
> <javascript:;>>
> 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
> <javascript:;>> 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 <javascript:;>] *On Behalf
> Of *Adrian Gropper
> > *Sent:* Monday, August 10, 2015 7:33 PM
> > *To:* Kinsley, William
> > *Cc:* openid-specs-heart at lists.openid.net <javascript:;>
> > *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
> <javascript:;>>
> > 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 <javascript:;>
> > 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 <javascript:;>>
> To: "'Adrian Gropper'" <agropper at healthurl.com <javascript:;>>
> Cc: openid-specs-heart at lists.openid.net <javascript:;>
> 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 <javascript:;> [mailto:agropper at gmail.com
> <javascript:;>] 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 <javascript:;>
> 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
> <javascript:;>> 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 <javascript:;>] On Behalf Of
> Adrian Gropper
> Sent: Monday, August 10, 2015 7:33 PM
> To: Kinsley, William
> Cc: openid-specs-heart at lists.openid.net <javascript:;>
> 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
> <javascript:;>> 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 <javascript:;>
> 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 <javascript:;>
> 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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150814/3167d2d2/attachment.html>

More information about the Openid-specs-heart mailing list