[Openid-specs-heart] Draft HEART meeting notes 2015-05-18

[Sarah Squire]

I've included my meeting notes below as well. Debbie, would it be helpful
if I take notes in the future so you can be more active in facilitating the
discussion? Also, does anyone object to me rewriting this use-case to
incorporate the feedback from the last two weeks so we have a more
comprehensive document to work from at the next meeting?

Thanks,

Sarah

Sarah Squire
Engage Identity

Justin would like us to be careful not to conflate identity proofing,
identity lookup, authentication, and authorization. The working group at
large should make an effort to be pedantic and precise with wording so that
these things don’t get conflated.

“Identity verification” can be interpreted as “identity proofing,” i.e.
matching an account to a person in the real world.

“Identity validation” can be interpreted as “authentication,” i.e. the user
has presented a valid credential.

Adrian would also like us to be careful not to conflate privacy and
security. We should have privacy and security. No compromise is necessary
at this level. For example, current-day VA security policy requirements
should not be considered as part of the HEART standard.

Everyone agrees that the HEART standard should be geared toward current-day
technologies, but not toward current-day policies.

Alice’s acknowledgement of receipt of the Practice’s HIPAA privacy
statement could be integrated into the Kantara Initiative’s Consent Receipt
project. It’s important to emphasize that this is a contract of adhesion,
which is fundamentally different from consent. Patients do not have the
option to opt-out. https://kantarainitiative.org/groups/ciswg/

“Initial patient web portal information” is basically telling Alice what
her endpoint is in their EHR system. It could be paper or digital. This
step is superfluous if Alice gives an identity pointer at check-in.

Alice would at some point provide a pointer to her identity, verify her
ownership, and integrate her authorization server. Those steps can happen
at the front desk on patient check-in, or they can be separated and happen
later in the visit.

Adrian would like to add a specific step to the use case in which
authorization is delegated to another person, and that delegate accesses a
protected resource using their own credentials. Jin pointed out that
delegated access is a fundamentally different concept than having a power
of attorney.

Adrian would also like the patient to be able to delete the record.
However, providers are required to keep medical records, so right to be
forgotten is out of scope in a healthcare context.


On Mon, May 18, 2015 at 2:49 PM, Debbie Bucci <debbucci at gmail.com> wrote:

>
> Attendee 5/18:
>
>    - Deb Bucci         Thompson Boyd        Sarah Squire
>    - Greg Groves      Adrian Gropper        Jin Wen
>    - Tom Sullivan      Edmund Jay             Dustin Gage
>    - Justin Richer      Eric Friedman        Jeremy Maxwell
>    - Catherin Shulten   Sal D’Agostino    James Kraugh
>
>
>
> Regrets
>
>    - Bill Kinsley    Eve Maler
>
>
>
> Stats - 99 list serv - 31 IPR
>
>
>
> NO MEETING NEXT Monday
>
>
>
> Two take-aways from the meeting today:
>
>    - How to avoid conflation
>    - Delegation is in scope for HEART wg -
>
>
>
>
>
> How to avoid conflation?
>
>    - Identity Proofing
>    - Identity Lookup
>    - Authentication
>    - Authorization (consent?)
>    - Privacy
>    - Security
>    - Policy
>    - Validation (id proofing) /verification (during authentication
>    transaction – presentation of valid credential – verification of
>    driverlicense/bill for identity proofing)
>
>
>
>    -
>    - Notes and discussion may highlight issues that are out of scope for
>    the working group but good to acknowledge the issues are there.  Fine
>    art between acknowledgement and deep in the weeds.
>    - Focus on standard with mind toward what today’s policies are to
>    inform with how to catch up to what it may enable
>    - Keep these things in mind while we discuss.   Multiple perspectives
>    are sometimes at odds with each other.
>    - All have contextual definitions
>    - Example = public key?  What is it – is it attached to something a
>    user controls? How are we doing that?
>
>
> We did not get much further in the use case today.  Alice is still
> standing at the front desk
>
>    1.
>
>    Alice is given and acknowledges receipt the Practice’s HIPAA privacy
>    statement.
>    1.
>
>       Office/practice privacy statement – how I protect your data – OCR
>       enforced - generic agreeing to business with patient
>       2.
>
>       Consent not always gathered at this point
>       3.
>
>       In non-health does acknowledge = consent??
>       4.
>
>       Practice handles differently – often different doc – we are going
>       to share your PHI with …
>       5.
>
>       Do you want to opt in/opt-out to share your information with the
>       local exchange ACO?
>       6.
>
>       Clinical/administrative/financials consents may be gather at this
>       time
>
>
>
>    1.
>
>    Alice is given the initial patient web portal information to activate
>    her account.
>    1.
>
>       Service discovery step – Alice is given info to find service on her
>       phone (go to this url …) Discovery stuff (UI and API components)
>       2.
>
>       Possible to introduce Alice discovery too …
>
>
>
> 2.  While in the waiting room, Alice (using her smart phone) completes
> the patient portal account activation.   (Is Alice setting authorizations
> at this point?)
>
>    1.
>
>    Discovery to site
>    2.
>
>    Alice logs in with account (hers (facebook/google) or portal)
>    3.
>
>    Complete registration
>    4.
>
>    RFI scancode ?
>    5.
>
>    Personal authorization service?
>    6.
>
>    Delegation (person to person)?
>    1.
>
>       Parent to child (under 13)
>       2.
>
>       Child to parent (89 yr old)
>       3.
>
>       Heathcare  proxy
>       4.
>
>       Would delegate have to be digitally bound to account?
>       7.
>
>    Who is the owner
>    1.
>
>       The owner is the physician’s office – so these authorization are
>       used to help the practice
>       2.
>
>       Owner is the person that has the right to delete the account (right
>       to be forgotten)
>       3.
>
>       Perhaps shared ownership
>       4.
>
>       JASON report perspective evolved from patient owned to patient
>       controlled/mediated (?) changed from legal perspective
>       5.
>
>       Based on office Data retention requirement
>
>
>
>
>
>
> _______________________________________________
> 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/20150518/03b9030f/attachment-0001.html>