[Openid-specs-heart] HEART 2015-05-11 rough meeting notes

Mon May 11 22:56:00 UTC 2015

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150511/8faa7e97/attachment.html>