[Openid-specs-heart] Proposal for reworked use case AND use case template

Tue Aug 4 18:09:01 UTC 2015

I am going to go way back in the thread where Aaron stated "...  FHIR
avoids the patient identity problem".... NO ... patient mediated exchange
(not FHIR) avoids patient identity [matching]  problems.   There is an
established relationship between the patient and the data holder .  If
the patient is managing the exchange  - significantly diminishes the
impact.

Agree that  authentication, authorization, delegation, consent and
credential management... are not specific to any particular sector but
there will be policies/regulation that will collide and need to be resolved
across jurisdictions and sector.

Agreeing on common structure to express policy - in scope. How the policy
is resolved - think that's up to the data holder /RO/RS

On Tue, Aug 4, 2015 at 1:06 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> This is a superb discussion. Beyond the metaphors and similes, in terms of
> standards and best practices, we need to ask where does healthcare as a
> vertical end?
>
> I suggest that healthcare ends where HL7 and FHIR deal with
> health-specific data models, profiles, and a strictly policy-neutral
> security scheme based on tokens.
>
> I suggest that authentication, authorization, delegation, and credential
> management... are human-specific and not specific to any particular
> vertical. The OpenID Foundation and HEART are as good a place to deal with
> these standards and best practices as anywhere.
>
> Making this clear demarcation would harmonize Argonaut and HEART and make
> all of our work around FHIR much more productive.
>
> Adrian
>
> On Tue, Aug 4, 2015 at 12:15 PM, Moehrke, John (GE Healthcare) <
> John.Moehrke at med.ge.com> wrote:
>
>> I was happy with the decision we made during the call, that patient
>> identity matching is an out-of-scope thing that we presume is a
>> precondition to our efforts… and that identity proofing is a local
>> (healthcare providers each manage this to their own satisfaction) issue
>> that is presumed as a precondition to our efforts. Our efforts are then
>> more focused on the authorization workflow.   This makes it clear that they
>> are ISSUES, but that they are issues that we rely  upon being solved
>> elsewhere. For which, as was pointed out on the call, they are fundamental
>> parts of the practice of healthcare.
>>
>>
>>
>> John
>>
>>
>>
>> *From:* Eve Maler [mailto:eve.maler at forgerock.com]
>> *Sent:* Tuesday, August 04, 2015 11:10 AM
>>
>> *To:* Moehrke, John (GE Healthcare)
>> *Cc:* Adrian Gropper; openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
>> use case template
>>
>>
>>
>> I'm sorry, but that's not *entirely* true. Although in healthcare a
>> physical body is what receives the service, which puts a whole new
>> perspective on getting things wrong, there are regulations and standards in
>> finance about proofing and authentication as well. And there are different
>> parts of the financial sector in which liability is apportioned
>> differentially among consumers, banks, credit card issuers, and so on.
>> Looking at the US situation, the FCRA, FFIEC, and so on are obviously
>> different beasts from HIPAA, but they're not nothing.
>>
>>
>>
>> Again, my point was simply that an "offline person" must often be guessed
>> about heuristically when they show up for service (a la "patient matching"
>> or "credit score lookups"), which can lead to mismatches, but an "online
>> person" who has been proofed and authenticated to a sufficient level of
>> assurance has been through a process *designed* to try and eliminate
>> mismatches, and this can be leveraged throughout the rest of the online
>> system.
>>
>>
>>
>> *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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=fVjdF_sKSbXTSGPwi2xC54BK4HhqMwAONLMM2sM75WY&s=ndTibZO0poXdZF6E8_UTUAfWEC_xKdmZRLPz7THKH-I&e=>
>> community!
>>
>>
>>
>> On Tue, Aug 4, 2015 at 8:59 AM, Moehrke, John (GE Healthcare) <
>> John.Moehrke at med.ge.com> wrote:
>>
>> Eve,
>>
>>
>>
>> They do NOT have the same problem… The consumer who gave a BAD account
>> number is the one that bears all the responsibility that they just sent
>> their money to a blackhole.  The consumer is the one that loses everything.
>> The bank just matched garbage-in to garbage-out. The bank is not held to
>> Medical Records regulations. The bank is not held to HIPAA disclosure
>> requirements. The bank is not held to medical ethics legal action. The bank
>> is not held at fault for aiding drug-seeking behavior. The bank is not held
>> at fault for medical fraud. The bank likely made money in the transaction
>> through transaction fees.
>>
>>
>>
>> We can whitewash the problems away… but if we do, we will create a
>> solution that is purely academic exercise and will never see the light of
>> day. Unless we deal with these issues, our solution will be a waste of
>> time. Again, I am not against the goal… I am just against us ignoring
>> reality. I am participating because I want a solution that can be used.
>>
>>
>>
>> John
>>
>>
>>
>> *From:* Eve Maler [mailto:eve.maler at forgerock.com]
>> *Sent:* Tuesday, August 04, 2015 10:41 AM
>> *To:* Moehrke, John (GE Healthcare)
>> *Cc:* Adrian Gropper; openid-specs-heart at lists.openid.net
>>
>>
>> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
>> use case template
>>
>>
>>
>> Well, that didn't at all have the intended efffect. I'm sorry. Let me try
>> again.
>>
>>
>>
>> I'm *not at all* saying we should follow the financial industry's model!
>> I'm saying that when they transfer data "behind people's backs", they have
>> exactly the same trouble the healthcare industry has in identifying people.
>> When an industry actually invites people in to the process, and gathers
>> their consent, and learns more about them, then the "online person" is a
>> participant in the process and is the "head" of their own account. That
>> gives them the beginnings of control.
>>
>>
>>
>> (From this point, you have a technological fulcrum on which to place
>> individual control in future.)
>>
>>
>>
>> *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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=eoGc0essWt93lgEVpvhM01qXsZEaxz50ypubaTF8gqc&s=6v5Vm0pyt2VRpFuTuPeLiTF8Blz2AX9ZJ0QY3uANNnk&e=>
>> community!
>>
>>
>>
>> On Tue, Aug 4, 2015 at 8:17 AM, Moehrke, John (GE Healthcare) <
>> John.Moehrke at med.ge.com> wrote:
>>
>> I find it very troubling when the financial industry is brought up as an
>> example that healthcare should follow. From a user experience, I agree with
>> Adrian that it seems to be a well ‘consumer centric’ model. The reality is
>> that they are not consumer centric, they act only by force of consumer and
>> often with payment for transaction fee.
>>
>>
>>
>> But the financial industry are dealing with fungible assets that can
>> easily be insured and they have regulated maximum damages. Healthcare has
>> NOTHING close to this. Further the only reason that the financial industry
>> communicates is because they are moving your  money, an asset they get to
>> leverage far beyond the kind of analytics that the healthcare community is
>> often accused  of doing (some rightly so). The financial world does not
>> communicate in any way to your benefit, they are perfectly happy having
>> fragmented and non-aligned assets. Where as in healthcare there is an
>> expectation that your current treatment plan is chosen based on your full
>> medical history, without any piece of information misunderstood
>> (malpractice).
>>
>>
>>
>> This said, I am not against the goal that Adrian is promulgating. I am
>> just frustrated at the overbroad statements about how wonderful the
>> financial industry is.
>>
>>
>>
>> John
>>
>>
>>
>> *From:* Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Eve Maler
>> *Sent:* Tuesday, August 04, 2015 10:03 AM
>> *To:* Adrian Gropper
>>
>>
>> *Cc:* openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
>> use case template
>>
>>
>>
>> Adrian, your patient vs. banking identity explanation was really good --
>> I'm going to steal that one. :-) Warning, musings on identity and proofing
>> below. Hope they're marginally interesting/helpful.
>>
>>
>>
>> In the world of marketing data brokerage, they deal in heuristic data
>> about people all the time but don't have to (or, maybe, even want to)
>> precisely identify a unique human being. (If you ever want to be weirded
>> out, read about Acxiom Personicx
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oceanoutdoor.com_site_wp-2Dcontent_uploads_ORCGuideToPersonicx.pdf&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=QtcwptaLBxuQh2WeoBs1IhxRnZzLuQe2ljx-h2VKN4A&e=> psychographics
>> codes. I had someone in the field tell me she looked "herself" up in the
>> data warehouse. She said, "They knew my bra size.")
>>
>>
>>
>> In the world of credit data brokerage, they have much the same problem as
>> the "offline patient identity" world does, though with a somewhat different
>> regulatory environment. If you're in the US and you want to try and look up
>> the annual free credit scores that you're entitled to by law, think about
>> the trouble you have to go through to identify yourself with
>> multiple-choice questions about your past financial life. Outside the US,
>> it's even harder because privacy laws limit the sources of data. As
>> demographics shift and more and more people get comfortably online/mobile,
>> identification gets easier because an organization funneled someone through
>> the process once and now owns the "hygiene" of that credential over time --
>> *everyone* can amortize the investment. However, of course, data privacy
>> gets more challenging.
>>
>>
>>
>> *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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=4_28RyfGvM2JnAA2r2PC92ouszRmNenZ1TmMlmOhcg8&e=>
>> community!
>>
>>
>>
>> On Mon, Aug 3, 2015 at 7:52 PM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>> I'm paying $15K / year for health insurance with a $4K deductible through
>> my insurance exchange. I just saved $200 out-of pocket on ONE prescription
>> by looking it up in GoodRX. If I was living in any other rich country, my
>> insurance would be less than half that and the prescription hassles would
>> be much less.
>>
>> The information system is rigged against the consumer in every way they
>> can think of. Most of it involves sharing our information selectively
>> beyond our control. We are being farmed.
>>
>> Adrian
>>
>>
>>
>> On Mon, Aug 3, 2015 at 10:01 PM, Aaron Seib <aaron.seib at nate-trust.org>
>> wrote:
>>
>> I am serious – what is the performance requirements to operate an UMA
>> server for one patient?  I wasn’t giving you a hard time.
>>
>>
>>
>> If we assume that we want to make this work for 10 million people in the
>> population tomorrow what do we have to pay to make it work?  I am assuming
>> that there are hosting requirements for an UMA server and every consumer
>> needs to be trained on how to use it.
>>
>>
>>
>> What is trivial?  Is it $10 per person per year?  $0.10 per person per
>> year?  What is required to make it operational?  How much will they need to
>> get paid to establish it?
>>
>>
>>
>> Are there comparable deployments that are operating at that scale that we
>> can refer to from other consumer domains?
>>
>>
>>
>> I am making this point as I don’t want to inadvertently exclude options
>> that should be considered for some transactions if they are sufficient if
>> they have the same outcome at a lower cost per transaction for some
>> transactions.
>>
>>
>>
>> You ask who wouldn’t want to have every transaction verified against
>> their own UMA server?  The person who is paying a per transaction fee to
>> get it done for them.
>>
>>
>>
>>
>>
>> Aaron Seib, CEO
>>
>> @CaptBlueButton
>>
>>  (o) 301-540-2311
>>
>> (m) 301-326-6843
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=sCSOzpc0Dh4XfwS-oVrarXol9DJR1znq3FaRb45-Plg&e=>
>>
>>
>>
>> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
>> Gropper
>> *Sent:* Monday, August 03, 2015 9:07 PM
>>
>>
>> *To:* Aaron Seib
>> *Cc:* Id Coach; openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
>> use case template
>>
>>
>>
>> On Mon, Aug 3, 2015 at 6:31 PM, Aaron Seib <aaron.seib at nate-trust.org>
>> wrote:
>>
>> I don’t get the assertion that  FHIR avoids the patient identity
>> problem.  I don’t get this assertion.  Can you get the crayons out and
>> explain that to me?
>>
>>
>>
>> Why don't we have a banking identity problem? It's because people
>> self-identify to their bank and their merchant. When somebody moves our
>> money without that, we call it theft.
>>
>> Self-identification is core to OAuth. You don't even need UMA and the
>> patient ID problem disappears.
>>
>> What confuses the issue is discovery. In banking, we don't try to make
>> our banking or shopping activity open to discovery. In the case of some
>> purchases, we actually try to hide it. In general, to the extent our
>> purchasing habits are subject to surveillance, we consider it creepy and
>> opt for systems like cash or ApplePay where the merchants, at least, can't
>> sell our purchase data to the data brokers.
>>
>> For some reason, healthcare starts from the assumption that people's
>> private activity needs to be tracked whether they like it or not by dozens
>> of "exchanges" and data brokers that we don't even know about. We are
>> treating people the way we do cows in the feedlot. In banking we have three
>> credit bureaus that track some of your activity but they're regulated and
>> we have access to "free credit reports". Good luck trying to get the
>> equivalent for your health care. For example, in many states, we have the
>> equivalent of state credit bureaus in the form of All Payer Claims
>> Database. Not one of them lets the patient access, check for errors, or
>> benefit from this credit bureau behavior. Who wouldn't want a report from
>> their All Payer Claims Database at the end of the yer when it's time to
>> choose a Bronze, Silver, Gold or Platinum deductible form the health
>> insurance exchange?
>>
>>
>>
>> It sounds Miraculous and as far as assertions about software capabilities
>> are concerned I am an agnostic.
>>
>>
>>
>> What are the pre-conditions that allow for the patient identity problem
>> is addressed.  What problem is created by eliminating that one?
>>
>>
>>
>> Just so I am clear – the patient-centric approach essentially says that
>> each individual has an UMA server set up that captures their privacy
>> preference and subsequent changes through time.  Whenever data about the
>> consumer is to be exchanged the service is checked to determine if the
>> disclosure is permitted.
>>
>>
>>
>> Yes.
>>
>>
>>
>> I would like to have an understanding of the performance considerations
>> of such a system so we can start the procurement process now.
>>
>>
>>
>> We already have this understanding. Bulk transfer of patient data dates
>> back to the paper and mainframe days. It works just as well for hackers as
>> it does for the primary business. It seems to take 4-8 months to discover a
>> breach of millions of records. The system is certainly very efficient. It's
>> time to introduce technology on the part of the user. The friction you're
>> worried about is a good thing. It means the subject is aware of their data
>> being moved from one custodian to another and breaches would be reported in
>> minutes. The computing cost of this notice is now trivial. Think of the UMA
>> server as simply a convenient way for your "providers" to notify you of
>> data transfers out of your account. What patient or family caregiver would
>> say no to that?
>>
>> Adrian
>>
>>
>>
>> Aaron Seib, CEO
>>
>> @CaptBlueButton
>>
>>  (o) 301-540-2311
>>
>> (m) 301-326-6843
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=sCSOzpc0Dh4XfwS-oVrarXol9DJR1znq3FaRb45-Plg&e=>
>>
>>
>>
>> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
>> Gropper
>> *Sent:* Monday, August 03, 2015 11:22 AM
>> *To:* Aaron Seib
>> *Cc:* Id Coach; openid-specs-heart at lists.openid.net
>>
>>
>> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
>> use case template
>>
>>
>>
>> Aaron,
>>
>> My definition of "patient-centric" is what we use in The Society for
>> Participatory Medicine: "Nothing about me without me."
>>
>> This is not as hypothetical as it sounds. A number of us in HEART worked
>> on the "Privacy on FHIR" pilot for last HIMSS. We demoed a patient-centered
>> system that included private EHR, gov EHR, 42CFR Part 2 sensitive data,
>> PHR, phone apps, and wearable IoT devices all sharing data using FHIR.
>> http://wiki.siframework.org/file/view/HIMSS15_Privacy%20on%20FHIR%20FINAL.PDF/555755441/HIMSS15_Privacy%20on%20FHIR%20FINAL.PDF
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.siframework.org_file_view_HIMSS15-5FPrivacy-2520on-2520FHIR-2520FINAL.PDF_555755441_HIMSS15-5FPrivacy-2520on-2520FHIR-2520FINAL.PDF&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=raPiIPoJutNckiSpXupDug4l3yKctfT8REEI8MxBKbs&e=>
>> The use of a single UMA Authorization Server for Alice across all of these
>> FHIR resources is the embodiment of "Nothing about me without me."
>>
>> The patient-centered or patient-directed approach to FHIR solves, or at
>> least avoids, the very difficult patient ID problem. It buys us time while
>> cybersecurity initiatives like NSTIC/IDESG figure out how to implement
>> practical trust frameworks for identity and related verified attributes.
>> Human ID is not a healthcare-specific issue, because we don't license human
>> patients. While others work on Human ID, we can use the patient-directed
>> approach to match patients across institutions.
>>
>> The patient-directed approach also avoids the difficult problem of
>> delegation to a family caregiver or custodian. Instead of every FHIR
>> resource having to implement a delegation method and policy, that
>> responsibility shifts to the patient's AS and becomes mostly transparent to
>> the resource server.
>>
>> The patient-directed approach provides increased cybesecurity because the
>> AS is consulted for every new interface access. This means that breaches
>> can be discovered in minutes instead of months. This also fulfills the
>> much-delayed Accounting for Disclosures requirement in HIPAA.
>>
>> The patient-directed approach avoids most of the provenance issues
>> because information flows directly from one institution to another without
>> the opportunity for delay or corruption by intermediary PHRs or HIEs.
>>
>> The patient-directed approach solves the "multiple portals" problem. Once
>> registration is complete, the patient or custodian need not interact with
>> the patient portal at the Resource Server again. In some cases, it's
>> possible that the resource server can avoid running a patient portal
>> altogether by allowing a staff member to complete enrollment of the
>> patient's AS as part of registration.
>>
>>
>> The Russian Dolls metaphor doesn't work for me. What I see is a simple
>> bifurcation at the root of FHIR design: either you enable a
>> patient-specified Authorization Server as a third-party in server-client
>> FHIR exchange or you don't. If you start down the UMA branch, then all of
>> the benefits above accrue downstream. If you don't start down the UMA
>> branch, then complexity explodes as we try to invent accessory actors,
>> federations and governance mechanisms.
>>
>> Adrian
>>
>>
>>
>>
>>
>> On Mon, Aug 3, 2015 at 10:00 AM, Aaron Seib <aaron.seib at nate-trust.org>
>> wrote:
>>
>> Adrian,
>>
>>
>>
>> Hi – I agree with your assessment regarding the sufficiency of oAuth for
>> the use case as documented.  It is a good way and block and tackle the
>> problem space to get to consensus of what separate components are capable
>> of doing and resolving them from the basic to the complex.
>>
>>
>>
>> Does everyone agree with that starting point?
>>
>>
>>
>>
>>
>> For discussion purposes lets assume we have consensus on that.  For the
>> use case where the consumer has PGHD that the Provider wants oAuth is
>> sufficient.
>>
>>
>>
>> This sentence from your email:
>>
>>
>>
>> If the problem is to begin HEART with a patient-centricity as the
>> problem, then this particular use-case distorts the discussion by presuming
>> Alice wants a PHR and diminishes the patient-centered benefits of UMA as a
>> health information exchange technology.
>>
>>
>>
>> I want to parse that better so I understand – can you help edify me about
>> what is meant by “patient-centricity as the problem”?
>>
>>
>>
>> I don’t have the same feelings about the fact that part of the work HEART
>> is doing is inventorying what the different use cases are and their
>> sufficiency.  In fact I think this step may prove informative to the end
>> point that we are all pursuing.
>>
>>
>>
>> One use case that is important that doesn’t follow the “Consumer has PGHD
>> that the Provider Wants” that readily comes to mind is the pattern of
>> Provider A having PHI about Patient X that Provider B (whom has a
>> patient-provider relationship with Patient X) should have if and only iff
>> (IFF) it is aligned with the privacy preferences of Patient X for Provider
>> B to have said data.
>>
>>
>>
>> To close the loop – is that a statement of a patient-centricity use
>> case?  Does what we are learning with the first use case inform what needs
>> to be done to satisfy the second use case?
>>
>>
>>
>> From a laypersons perspective I see a Russian Dolls exposition of the use
>> cases one building on another until we solve the problems established by
>> this work groups charter.
>>
>>
>>
>> Thank you for letting me share.
>>
>>
>> Aaron
>>
>>
>>
>> Aaron Seib, CEO
>>
>> @CaptBlueButton
>>
>>  (o) 301-540-2311
>>
>> (m) 301-326-6843
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=sCSOzpc0Dh4XfwS-oVrarXol9DJR1znq3FaRb45-Plg&e=>
>>
>>
>>
>> *From:* Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Adrian
>> Gropper
>> *Sent:* Sunday, August 02, 2015 2:30 PM
>> *To:* Id Coach
>> *Cc:* openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
>> use case template
>>
>>
>>
>> Thank you Eve!! I hope we can reach consensus on something like the
>> format you present.
>>
>>
>>
>> Narratives are much easier to understand when they begin with a clear
>> statement of the problem. Shouldn't use cases be asked to clearly state the
>> problem they are trying to solve right up front?
>>
>> This particular use-case seems to be trying to solve some or all of three
>> problems: federated sign-in, eliminating the registration clipboard hassle,
>> and updating a PHR with encounter results. All of these can be solved by
>> OAuth alone.
>>
>> If the problem is to begin HEART with a patient-centricity as the
>> problem, then this particular use-case distorts the discussion by presuming
>> Alice wants a PHR and diminishes the patient-centered benefits of UMA as a
>> health information exchange technology.
>>
>> I've tried to clarify these fundamental issues in my comments on the
>> document and hope we can resolve this before we move on to semantic
>> profiling and scopes.
>>
>>
>>
>> Adrian
>>
>>
>>
>> On Sat, Aug 1, 2015 at 3:32 PM, Id Coach <coach at digitalidcoach.com>
>> wrote:
>>
>> Thanks Eve,
>>
>> This is wonderful. I questioned/commented on things only a newbie is
>> likely to ask/care about.
>>
>> It's also a useful template for other use cases. To your point about
>> explaining oAuth and other template terms, you're using a new language and
>> a new ecosystem to many, so I encourage those template terms to be
>> explained over and over again as needed and as appropriate.
>>
>> It will be helpful to me to illustrate or diagram this process. I'll take
>> a crack at that in the next few days (I hope).
>>
>>   judi
>>
>>
>>
>> On 8/1/15 11:20 AM, Eve Maler wrote:
>>
>> Completing my action item, you'll find our (well-worn :-) use case
>> document here
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1IvbdWerdvMuA1dQ-2DKQvVKqIBrAas7FoenNVUtgpqYrw_edit-3Fusp-3Dsharing&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=mFAukEQMozyggbR5vc6wYMWgsvuGIr11-W6P-mLm6Qo&e=>.
>> Following is my proposal. If we like what I've done here, I recommend that
>> we:
>>
>>    - Edit the doc title to match the use case title I've supplied (just
>>    below the horizontal line).
>>
>>
>>    - Resolve all the comments above my title (fear not, they're all
>>    accounted for in the comments I've inserted) and delete all the text above
>>    that point (I've retained all our existing text above the line, just in
>>    case).
>>
>>
>>    - Resolve all the comments I've inserted -- as quickly as possible!
>>    We don't have to take up call time to do the minor ones, if people take the
>>    initiative to review them offline and supply their feedback as responses to
>>    this note. Note that, in this new template, I have avoided the use of the
>>    comment mechanism for anything that should be a permanent part of the
>>    document.
>>
>>
>>    - Ask people to write their other use cases in GDoc using this style.
>>
>>
>>    - Obviously, if you have suggestions on how to improve the template,
>>    weigh in! If you want to make invasive suggestions, contact me and we can
>>    do a collaborative editing session together.
>>
>> I'm extremely glad I finally did this exercise, because it caused me to
>> understand more of what we need to consider profiling and more of the
>> "health SME" point of view. And, to be honest (perhaps forestalling a
>> comment from Justin ;-), I don't feel that it was wasteful to go to this
>> degree of mapping to the technologies because it flushed out some
>> mismatches that really didn't make sense to me all this time. I now feel we
>> can go straight to the heart (ahem) of the profiling matter with as many
>> future use cases as we want, and in fact, we can begin profiling and write
>> more use cases in parallel.
>>
>>
>>
>> Thanks to you all for letting me "get my OCD on".
>>
>>
>> *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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=4_28RyfGvM2JnAA2r2PC92ouszRmNenZ1TmMlmOhcg8&e=>
>> community!
>>
>>
>>
>> _______________________________________________
>>
>> Openid-specs-heart mailing list
>>
>> Openid-specs-heart at lists.openid.net
>>
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=geQ1ZsX_giIQGAL84fp3sIEs22LGa_0NPs1RWXN6Ez8&e=>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=geQ1ZsX_giIQGAL84fp3sIEs22LGa_0NPs1RWXN6Ez8&e=>
>>
>>
>>
>>
>> --
>>
>>
>>
>> Adrian Gropper MD
>>
>> RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE: http://patientprivacyrights.org/donate-2/
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=-4miLc7Egd2FzqscJ3w9BngaBnCpHmpDOGnBzRZ3d24&e=>
>>
>>
>>
>>
>> --
>>
>>
>>
>> Adrian Gropper MD
>>
>> RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE: http://patientprivacyrights.org/donate-2/
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=-4miLc7Egd2FzqscJ3w9BngaBnCpHmpDOGnBzRZ3d24&e=>
>>
>>
>>
>>
>> --
>>
>>
>>
>> Adrian Gropper MD
>>
>> RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE: http://patientprivacyrights.org/donate-2/
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=-4miLc7Egd2FzqscJ3w9BngaBnCpHmpDOGnBzRZ3d24&e=>
>>
>>
>>
>>
>> --
>>
>>
>>
>> Adrian Gropper MD
>>
>> RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE: http://patientprivacyrights.org/donate-2/
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=-4miLc7Egd2FzqscJ3w9BngaBnCpHmpDOGnBzRZ3d24&e=>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BjxAvFx8QWs4XC6iU1PL1lgMCP4YVzdBhh4vu2fWdeU&s=geQ1ZsX_giIQGAL84fp3sIEs22LGa_0NPs1RWXN6Ez8&e=>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: 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/20150804/45d8cf63/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3147 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150804/45d8cf63/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150804/45d8cf63/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150804/45d8cf63/attachment-0005.jpg>