[Openid-specs-heart] HEART Stepping stones - Consent Use case

Debbie Bucci debbucci at gmail.com
Fri May 8 22:39:10 UTC 2015


Adrian,

Please do not change the focus to an entirely different set of use case.
If the current use case (schedule an initial visit)  is hard to follow
please ask questions.  Other may have the same ones that you do.   I will
copy these to the wiki and we can circle back around to them.

I do hope you will consider playing along.


Regards,

Deb


On Fri, May 8, 2015 at 5:19 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> I'm having a hard time following this use-case. If we're looking for the
> simplest possible cases, I can think of two:
>
> Case A:
>
>    - Alice visits Labcorp to get a blood test for HIV.
>    - She pays cash. She does not show ID.
>    - She wants to send the result to somewhere identified by an email
>    address that she gives to Lab Corp
>    - A Webfinger or equivalent lookup provides Labcorp with a pubic
>    encryption key
>    - Labcorp encrypts the result and exposes a protected resource with
>    the result.
>    - Labcorp transmits the URI of the protected resource to Alice
>    in-person or via email.
>
>
> Case B:
>
>    - Alice visits Labcorp to get a blood test for HIV that she will share
>    with her PCP.
>    - Both Labcorp and her PCP trust AppleIDs to belong to the same person
>    even though the same person can have multiple AppleIDs.
>    - She pays cash.
>    - She identifies herself by using her AppleID to sign-in to the
>    Labcorp kiosk. Labcorp does not see her AppleID.
>    - Labcorp gets a pairwise pseudonymous identifier for her HIV test
>    from Apple.
>    - Labcorp encrypts the result and exposes a protected resource with
>    the result.
>    - Labcorp transmits the URI of the protected resource to Alice
>    in-person or via email.
>    - Alice visits her PCP and uses the same AppleID she used at Labcorp
>    to sign-in to the PCP kiosk. The PCP does not see her AppleID.
>    - PCP gets a pairwise pseudonymous identifier for Alice's health
>    record from Apple.
>    - Alice use the kiosk she is signed into to point her PCP to Labcorp's
>    protected resource.
>    - The PCP accesses the protected resource and trusts Apple that it
>    belongs to Alice's health record and the HIV test was performed by Labcorp.
>
> Case A has no patient ID issue whatsoever. Neither does Case B. If Alice
> wants to make her HIV result endpoint discoverable, that's a different,
> more complicated use case - let's call that Case C.
>
> If we replace Labcorp / HIV with the state controlled substance database
> and the the resource is a list of Alice's opioid prescriptions, then that's
> a different use-case where Alice must present the PCP with a verified ID -
> let's call this Case D. However, this trust elevation form a voluntary ID
> in case B to a verified ID in Case D should not happen except if Alice asks
> for a controlled substance and she agrees to provide a verified ID. This is
> equivalent to the car dealer asking you for permission to run your Social
> Security Number if you ask for a car loan and only then do you sign the
> form with your SSN on it for a credit check.
>
> Can we start with just case A and B and add C and D later?
>
> Also, introducing a PHR into the conversation makes all of the cases more
> complicated because we then have to deal with provenance and with how we
> correct errors when data is accessed by copy instead of by reference, etc..
> I would consider a PHR just another protected resource, no different from
> any other.
>
> Adrian
>
>
>
> On Thu, May 7, 2015 at 10:30 PM, Debbie Bucci <debbucci at gmail.com> wrote:
>
>> First question
>>
>> What is the function of the UMA service in the practice?  Is it an
>> enterprise function to help the practice manage the its authorizations
>> and/or supports the patient portal ?
>> Given Alice has chosen her PHR to be her source of truth, my current
>> assumption is that she would manage her authorizations at the PHR UMA
>> service
>>
>>
>>
>>
>> On Thu, May 7, 2015 at 8:02 PM, Kinsley, William <BKinsley at nextgen.com>
>> wrote:
>>
>>>  Debbie, (and group)
>>>
>>>
>>>
>>> In the attached word document, I hopefully clarified this use case and
>>> answered your questions. Again, the point is to create the discussion of
>>> these very issues you bring up.
>>>
>>>
>>>
>>> Questions:
>>>
>>>             #1: “Trust between patient portal and cloud based PHR?” I am
>>> simplify this by removing the dynamic discovery process. See the attached
>>> documents.
>>>
>>>             #2: “The cloud PHR has established a base identity
>>> proofing/authentication level of trust?” Since the PHR is not a HIPAA
>>> covered entity (like most personal HIT devices and services), the PHR is
>>> using common internet  credentialing (e-mail or SMS codes). Two points here:
>>>
>>> 1)   There are no regulation requiring the PHR to use any credentialing
>>> standard such as NIST and there are different credentialing processes being
>>> used. (Do not be mistaken, this is not what I am advocating, it “just is”)
>>>
>>> 2)   Each system is offering different level of authentication controls.
>>>
>>>
>>>
>>>
>>>
>>> Again, this is a simple real world use case; but it has a lot of moving
>>> parts.
>>>
>>>
>>>
>>> Bill
>>>
>>>
>>>
>>>
>>>
>>> *From:* Openid-specs-heart [mailto:
>>> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Debbie Bucci
>>> *Sent:* Saturday, May 02, 2015 1:46 PM
>>> *To:* openid-specs-heart at lists.openid.net
>>> *Subject:* [Openid-specs-heart] HEART Stepping stones - Consent Use case
>>>
>>>
>>>
>>> Picking this back up again but removed the background leading to this
>>> and starting a different thread.  Bill says keep it simple but it's
>>> complex!  He has 2 scenarios but I focused on the most difficult -   I have
>>> posted the original text to Bill's question on the wiki:
>>>
>>> http://hg.openid.net/heart/wiki/PCP_First_Appointment
>>>
>>>
>>>
>>> Questions:
>>>
>>> Client one: If Alice has chosen a cloud based PHR that already has an
>>> established trust:
>>>
>>> *Please clarify what you mean by established trust:*
>>>
>>> *1.*     *Trust between patient portal and cloud based PHR:  the
>>> patient portal has establish an FHIR API server , is accepting client
>>> applications and the client PHR is has been registered with the Patient
>>> Portal?*
>>>
>>> *2.*     *The cloud PHR has established a base identity
>>> proofing/authentication level of trust?   *
>>>
>>> *3.*     *Both*
>>>
>>> What are the credentialing requirements to create Alice's account?
>>>
>>> *1.*     *Patient Portal*
>>>
>>> *2.*     *Cloud PHR *
>>>
>>> *3.*     *Both*
>>>
>>> Note that ONC"s Ten year interop roadmap refer's to NIST SP 800-63-2 and
>>> OMB M-040-04 and is implying level 2 or 3 levels of assurance (LOA). (see
>>> pp 59)
>>>
>>>
>>>
>>> *LOA2 is a single factor –that’s out.  The HITPC committee recommended
>>> more than username and password for patient portals – that implies
>>> multifactor.    Transaction will be more secure but what is the level of
>>> identity proofing needed – no real guidance issued for patients that I am
>>> aware of.    There is the notion that the patient is know to the practice –
>>> but at this point  - it’s an initial visit – not the case.*
>>>
>>>
>>>
>>>
>>>
>>> Are there two or three consent profiles?
>>>
>>> One for Alice's PHR defining what to share with the Practice?
>>>
>>> One for the Practice defining what is to be shared with Alice's PHR?
>>>
>>> One for Alice at the Practice portal defining what the Portal (or
>>> Practice?) is to be shared?
>>>
>>> *1.*     *Are there consent preferences stored /shared on the patient’s
>>> trusted UMA service? *
>>>
>>> *2.*     *Is there a Consent Directives Management Service trusted by
>>> the UMA service?*
>>>
>>> *3.*     *Is there a CDMS maintained by the provider*
>>>
>>> *4.*     *Does the PHR maintain it own CDMS?*
>>>
>>>
>>>
>>> How is the initial implied consent for TPO electronically presented,
>>> stored and accessed?
>>>
>>> *Generate a consent receipt reminding the patient they agreed   *
>>>
>>>
>>>
>>> *I wonder if this is the ruckus I've heard re: check the box for consent
>>> ... *
>>>
>>>
>>>
>>>  How is this consent profile used by the practice's internal HIT
>>> systems? (if at all)
>>>
>>> *Which profile?*
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
>
> --
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> *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/20150508/936c76d3/attachment-0001.html>


More information about the Openid-specs-heart mailing list