[Openid-specs-heart] Draft HEART Meeting Notes 2015-08-10

[Adrian Gropper]

(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/20150810/58cb5ec4/attachment-0001.html>