[Openid-specs-heart] HEART 2015-05-11 rough meeting notes
Adrian Gropper
agropper at healthurl.com
Mon May 11 23:49:45 UTC 2015
I'm not sure how many common understandings we will end up with. I do think
it would be helpful for folks that propose a use case to make clear their
primary goal in proposing that particular use case. Doing so, enables all
of us to design based on modern technology rather than paving the cow path
of paper and parochial business practices.
Adrian
On Mon, May 11, 2015 at 6:56 PM, Debbie Bucci <debbucci at gmail.com> wrote:
> If we do not have a common understanding - how do we know when we are
> conflating the issues? I found it helpful to walk stepwise through the
> use case and understand the complexities. If we have bucket to sort them
> into - great.
> There are a lot different parts/issue to consider within each component -
> which was primarily registration today
>
> Does solving the patient portal = Alice’s PHR (or PCP portal or vendor
> health app) can be her single point of truth via the use of FHIR APIs ?
>
>
>
>
> On Mon, May 11, 2015 at 6:12 PM, Justin Richer <jricher at mit.edu> wrote:
>
>> I’m with Adrian in terms of decomposing the problem into its components.
>> There was a lot of conflation of authentication, authorization, trust,
>> assurance, and different actors in the discussion today. If we don’t keep
>> the parts clearly-defined we’ll never make progress.
>>
>> — Justin
>>
>>
>> On May 11, 2015, at 5:52 PM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>> I interpreted the principal goal of Bill's Use Case to be a desire to
>> solve the multiple portals problem. I'm aware of parents of seriously ill
>> children that have as many as 11 separate portals to deal with.
>>
>> Is this the principal goal of this conversation? If so, then we can begin
>> to decompose the goal of solving the multiple portals problem into
>> registration, authorization and authentication components for the various
>> actors. If there's another goal, please make it clear.
>>
>> Adrian
>>
>> On Mon, May 11, 2015 at 5:07 PM, Debbie Bucci <debbucci at gmail.com> wrote:
>>
>>> All
>>>
>>> Great idea from Justin to post now and great discussion ... If other
>>> post - I will try to merge before the weekend for next week.
>>>
>>>
>>> 1. Alice calls the practice and schedules her initial appointment.
>>>
>>> A. The Scheduler does not find an existing account for Alice and
>>> creates a new account.
>>>
>>> i. Local account – Alice may not
>>> know
>>>
>>> ii. Could bind an external
>>> account/identity to it – binding ceremony
>>>
>>> iii. Object at database/table –
>>> that point to Alice OIDC + Public key or other stuff
>>>
>>> B. The Scheduler creates an appointment with the PCP Alice has
>>> selected.
>>>
>>> 2. Alice arrives at the practice and registers with the front desk.
>>>
>>> A. Alice provides the Registrar with her driver’s license and insure
>>> card(s).
>>>
>>> i. – id proofing process
>>>
>>> ii. online eligibility checking –
>>> what is covered? payment
>>>
>>> iii. collect and scan – but how
>>> about verification ?
>>>
>>> B. The Registrar scan the cards and updates Alice’s account.
>>>
>>> i. Id proofing
>>>
>>> ii. Can this ID process be
>>> re-used “known to the practice?” How can we represent that within the
>>> protocols?
>>>
>>> iii. FITS into vectors of trust in
>>> IETF work
>>>
>>> 1.1.1.2.B.iii.1. Verify holder of claims/document with
>>> identity– high level of confidence
>>>
>>> 1.1.1.2.B.iii.2. Onboarding ceremony can bind and verify
>>> separately
>>>
>>> 1.1.1.2.B.iii.3. Quick photograph and imbed into record
>>> for evidence of practice.
>>>
>>> iv. How does the profiles
>>> represent the level of trusts – two levels of proofing - trust
>>> elevation -
>>>
>>> 1.1.1.2.B.iv.1. (bill concerns) Login to phr - portals
>>> will create login account – Alice has a choice – PCP or PHR -
>>> potential to use multiple accounts with different levels of trust – how
>>> does the levels of trust get described across relying parties/resource
>>> servers (?) How do we know Alice is Alice?
>>>
>>> 1.1.1.2.B.iv.2. Alice should have the choice to use
>>> whatever. Identity to bind external accounts with local accounts is powerful
>>>
>>> 1.1.1.2.B.iv.3. When alice goes to specialist – why would
>>> alice need an additional proofing? Specialist can always do their own
>>> binding process.
>>>
>>> 1.1.1.2.B.iv.4. Who is the system of record – not bound
>>> in OAUTH world. Alice could prove in multi- ways.
>>>
>>> 1.1.1.2.B.iv.5. FHIR Referral message – between provider
>>> – I am referring to alice –I know here as 1234 – she used cred
>>> (issuer/subject) – if you trust me - let her in – save binding
>>> ceremony. Who’s to trust bits of information –
>>>
>>> 1.1.1.2.B.iv.6. If FHIR API increases patient engagement
>>> going forward …once Alice has set up credential –next system –if level of
>>> trust – should be able to transfer /share information.
>>>
>>> v. More info – vectors of trust
>>> and binding … take advantage of capabilities that did not exist in paper
>>> world
>>>
>>> _______________________________________________
>>> 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/>
>>
>> _______________________________________________
>> 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/20150511/ac671edf/attachment-0001.html>
More information about the Openid-specs-heart
mailing list