[Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP

[Eve Maler]

Given that this use case has a lot of "lines and boxes" drawn in words
instead of pictures, and I was about to pull out a pad of paper to make
real lines and boxes :-), would it be fair game for the use case document
itself to contain a real drawing? I'm not sure I will truly understand all
of its implications until I either go through that exercise or stare at an
already-completed drawing...


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Mon, Jun 15, 2015 at 2:18 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> This thread is already about 3 different things:
>
> 1 - How do we merge the desire to use the OpenID Connect standard as much
> as possible while also allowing any Resource Owner that is willing to
> register themselves in-person to benefit from "known to the practice" as a
> data minimization / privacy engineering feature.
>
> 2 - Mention of technical constraints in Use-Cases.
>
> 3 - I'm confused by the reference to two different Authorization Servers
> in 3f-g and 4. As I understand it, the AS is tied to the Resource Owner and
> has no mandatory relationship to the Resource Server.
>
> Can we split this thread accordingly?
>
> Adrian
>
>
>
> On Mon, Jun 15, 2015 at 5:11 PM, Justin Richer <jricher at mit.edu> wrote:
>
>> That’s a correct characterization, and these are not formal requirements
>> documents. Since these use case documents will not likely be published as
>> formal documents at all, but instead are meant to guide the development of
>> the standards and profiles, then it’s appropriate to talk about both
>> constraints and requirements within them.
>>
>>  — Justin
>>
>> On Jun 15, 2015, at 4:48 PM, Maxwell, Jeremy (OS/OCPO) <
>> Jeremy.Maxwell at hhs.gov> wrote:
>>
>>  The need to use FHIR is a technical constraint, not a requirement.
>> Technical constraints should be captured in a separate section from
>> requirements.  The requirement is that the data flow is “simple” and
>> “seamless” which need to be measurably defined so we know when “simple” and
>> “seamless” have been achieved.
>>
>>
>>
>>
>>
>>
>>
>> *From:* Justin Richer [mailto:jricher at mit.edu <jricher at mit.edu>]
>> *Sent:* Monday, June 15, 2015 4:37 PM
>> *To:* Maxwell, Jeremy (OS/OCPO)
>> *Cc:* Sarah Squire; openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] HEART Use Case: Alice Enrolls with
>> PCP
>>
>>
>>
>> I disagree that these use cases need to be technology agnostic. This
>> group is going to be working on FHIR-based APIs, let’s just call it out as
>> that instead of pretending that we’re building to some undefined API.
>>
>>
>>
>>  — Justin
>>
>>
>>
>> On Jun 15, 2015, at 4:11 PM, Maxwell, Jeremy (OS/OCPO) <
>> Jeremy.Maxwell at hhs.gov> wrote:
>>
>>
>>
>> Couple of suggestions:
>>
>> 1.      In step 3a, it’s not necessarily mandatory to store the driver’s
>> license and insurance card images in the EHR.  In particular, for the
>> driver’s license, if I was an EHR designer, I’d question why it needs to be
>> stored.  Data minimization is a great security technique—data cannot be
>> breached if it’s not stored.  The license is used to ID proof Alice.  Once
>> she’s been ID proofed and that’s been recorded (step 3b), the license is no
>> longer needed.
>>
>> 2.      Remove reference to FHIR in step 4.  Use cases are requirements
>> and they should be technology-agnostic.  If the real requirement is that
>> the “bidirectional information transfer is simple and seamless”, then say
>> this and define what “simple and seamless” mean.
>>
>>
>>
>> Thanks,
>>
>>
>>
>>
>>
>>
>>
>> *From:* Openid-specs-heart [
>> mailto:openid-specs-heart-bounces at lists.openid.net
>> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Sarah
>> Squire
>> *Sent:* Monday, June 15, 2015 3:55 PM
>> *To:* openid-specs-heart at lists.openid.net
>> *Subject:* [Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP
>>
>>
>>
>> Hello all,
>>
>>
>>
>> I've attached a write-up of the enrollment use case incorporating
>> feedback from the last three calls. Thanks everyone for your valuable
>> input. I think this is much more solid now. Please chime in if there's
>> anything else we can improve upon.
>>
>>
>>
>> Sarah
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20150615/efb7070c/attachment.html>