[Openid-specs-heart] Openid-specs-heart Digest, Vol 82, Issue 5
Adrian Gropper
agropper at healthurl.com
Mon Jul 25 12:54:35 UTC 2016
Kathleen,
I'm having a hard time understanding what it is you are hoping to
accomplish with HEART.
For my part, I've tried to be clear that I hope:
(a) to ensure that Alice or her custodian can specify the UMA authorization
server in order to avoid the multiple portals problem,
(b) to ensure that the full range of FHIR patient-level resources is
accessible for authorization by the AS in order to make HEART as broadly
applicable to HIE as possible,
(c) to take advantage of HL7 confidentiality codes if they are available in
order to improve the user experience for Alice in setting up polices at the
AS, and
(d) to use the NYP ROI form as a test of whether the HEART protocols can
manage one of the most common use-cases.
I admit that my list is heavily patient-centered and therefore might not
satisfy other stakeholder needs. Can you or others that have additional
requirements or goals beyond the four above please state what those goals
are. Most important, if the four goals I've listed force a compromise of
some other goal, let's put that out for discussion ASAP.
Adrian
On Saturday, July 23, 2016, Kathleen Connor <kathleen_connor at comcast.net>
wrote:
> Hi - RE
> And based on one of our telecon conversations, we provided this list right
> in the use case, where the first item might possibly encompass some of the
> others by definition:
>
> 1. Virtual clipboard
> 2. Basic patient profile /Patient)
> 3. Medication history (/MedicationDispense, /MedicationAdministration)
> 4. Immunizations (/Immunization.vaccineCode , /Immunization.status)
> 5. Allergies (/AllergyIntolerance)
> 6. Problem list /Condition.code, /Condition.status)
> 7. Labs (/DiagnosticReport.code - LOINC
> /DiagnosticReport.codedDiagnostics - SNOMED)
> 8. Basic insurance info? EOB?
> 9. (what else? Keep it simple)
>
> Possible FHIR Resources for # 1 and # 9
>
> 1. Virtual Clipboard = FHIR Questionnaire
> [http://hl7-fhir.github.io/questionnaire.html] /Questionnaire Response
> [http://hl7-fhir.github.io/questionnaireresponse.html] where the clipboard
> questions and possible answers could be any of the following datatypes,
> including References to #2 - # 9
>
> . answer[x] I 0..1 Value question must have
> ...... answerBoolean boolean
> ...... answerDecimal decimal
> ...... answerInteger integer
> ...... answerDate date
> ...... answerDateTime dateTime
> ...... answerInstant instant
> ...... answerTime time
> ...... answerString string
> ...... answerUri uri
> ...... answerAttachment Attachment
> ...... answerCoding Coding
> ...... answerQuantity Quantity
> ...... answerReference Reference(Any)
>
> 2. #9 Should be FHIR Consent [could be additional Resources for #9s]
>
> Important to note!!!!
>
> As far as I know, Patient generated health data on a clipboard is NOT HIPAA
> governed PHI until the provider incorporates into patient paper record
> [then
> covered under HIPAA Privacy rule] and into an EHR [then covered under HIPAA
> Privacy, Security, and to extent used in a HIPAA governed electronic
> transaction, the HIPAA Transaction and Code Set, rules.
>
> That means that if the patient is referencing a FHIR Clinical or
> Administrative Resource [EOB] in the patient's
> Clipboard/QuestionnaireResponse, that the security labels, which may have
> been assigned to those Resources when they were in the "Covered Entity"
> systems no longer apply if the Resources referenced are stored outside of a
> Covered Entity's system.
>
> Specifically, if the patient is referencing Resources in a Covered Entity's
> system [e.g., provider's EHR or payer portal], then the HIPAA, 42 CFR Part
> 2
> [SAMHSA], Title 38 Section 7332 [VA] /other jurisdictional/organizational
> or
> a patient consent directive used by the Covered Entity's system to generate
> referenced FHIR Resource security labels [Confidentiality code] likely
> apply
> as long as the Clipboard/FHIR QuestionnaireResponse stays in a Covered
> entity's system.
>
> But if the patient is referencing Resources in a patient controlled system
> [PHR], then those security labels no longer apply.
>
> In order for the HEART/FHIR based Clipboard to specify the source of the
> security labels that should be applied to the Clipboard, the HEART/FHIR
> Clipboard Questionnaire should include a reference to the applicable FHIR
> Consent.
>
> Sorry - can't make this simple wrt to US privacy laws.
>
> Upside is that this Use Case illustrates how Confidentiality Codes in
> HEART/FHIR Clipboard will differ based on the policy domain in which it is
> used.
>
> -K
>
> -----Original Message-----
> From: Openid-specs-heart
> [mailto:openid-specs-heart-bounces at lists.openid.net <javascript:;>] On
> Behalf Of
> openid-specs-heart-request at lists.openid.net <javascript:;>
> Sent: Thursday, July 21, 2016 9:39 PM
> To: openid-specs-heart at lists.openid.net <javascript:;>
> Subject: Openid-specs-heart Digest, Vol 82, Issue 5
>
> Send Openid-specs-heart mailing list submissions to
> openid-specs-heart at lists.openid.net <javascript:;>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> or, via email, send a message with subject or body 'help' to
> openid-specs-heart-request at lists.openid.net <javascript:;>
>
> You can reach the person managing the list at
> openid-specs-heart-owner at lists.openid.net <javascript:;>
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Openid-specs-heart digest..."
>
>
> Today's Topics:
>
> 1. Re: New thread - What is in a clipboard resource set? (Eve Maler)
> 2. Re: New thread - What is in a clipboard resource set?
> (Debbie Bucci)
> 3. Re: New thread - What is in a clipboard resource set?
> (Nancy
> Lush)
> 4. Re: New thread - What is in a clipboard resource set?
> (Adrian Gropper)
> 5. Re: Dissecting the Release of information form (Adrian Gropper)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Jul 2016 08:39:32 -0700
> From: Eve Maler <eve.maler at forgerock.com <javascript:;>>
> To: Debbie Bucci <debbucci at gmail.com <javascript:;>>
> Cc: "openid-specs-heart at lists.openid.net <javascript:;>"
> <openid-specs-heart at lists.openid.net <javascript:;>>
> Subject: Re: [Openid-specs-heart] New thread - What is in a clipboard
> resource set?
> Message-ID:
> <
> CAMPbGmh5SAi1aUbJk2-F6H69oA_SwvjjmBzwW3SpqMHhOE2A8w at mail.gmail.com
> <javascript:;>>
> Content-Type: text/plain; charset="utf-8"
>
> Just to level-set, there are three links in the current use case to sources
> that describe potentially interesting data (though not directly how they
> map
> to FHIR, as far as I can see):
>
> - Use case
>
> <
> https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Ot
> hers_UMA_FHIR>
> - PGHD
>
> <
> https://www.healthit.gov/policy-researchers-implementers/patient-generated-
> health-data>
> - Common Clinical Data Set
>
> <
> https://www.healthit.gov/sites/default/files/commonclinicaldataset_ml_11-4-
> 15.pdf>
> - Virtual clipboard
>
> <
> https://www.wedi.org/home/virtual-clipboard-to-improve-patient-data-collect
> ion>
> (this link
>
> <
> http://www.wedi.org/docs/default-document-library/virtual-clipboard-definit
> ion-and-design-document.pdf?sfvrsn=0>
> is actually more helpful -- I've changed it in the use case)
>
> And based on one of our telecon conversations, we provided this list right
> in the use case, where the first item might possibly encompass some of the
> others by definition:
>
> 1. Virtual clipboard
> 2. Basic patient profile /Patient)
> 3. Medication history (/MedicationDispense, /MedicationAdministration)
> 4. Immunizations (/Immunization.vaccineCode , /Immunization.status)
> 5. Allergies (/AllergyIntolerance)
> 6. Problem list /Condition.code, /Condition.status)
> 7. Labs (/DiagnosticReport.code - LOINC
> /DiagnosticReport.codedDiagnostics - SNOMED)
> 8. Basic insurance info? EOB?
> 9. (what else? Keep it simple)
>
> Here was my guess about directions, given that a use-case-based definition
> of this resource set is meant to encompass baseline information before a
> first visit.
>
> First, we want to keep firmly in our minds that Alice's motivation to share
> this information at all is as a convenience vs. sharing it in a more
> onerous, brittle fashion (e.g., having to keep updating her meds list
> later,
> spending time printing forms, arriving early to the first appointment...).
> So we don't "win" if we don't hit that mark.
>
> Second, labs and EOBs look like the "odd items out" on that list for a
> first
> visit. Am I right? And what's missing? And what's the "FHIR concordance"
> for
> all this? Can one actually be done?
>
> Third, there would be some kind of a "matrix of requesting-side
> appropriateness" for what is to be shared:
>
> - *Payment info:* E.g., there's a particular type of insurance
> infrastructure in the US, but in Canada, it would look different. So the
> "insurance info" reference in #8 would need to vary or be missing per
> jurisdiction.
> - *Provider services:* There *may* be a fundamental mismatch between the
> nature of health information available and what the provider can even
> do.
> When it comes to, say, chiropractic, is there an appropriateness or
> privacy
> concern about providing meds/allergy information? It's a complex
> technical
> question to imagine leaving this info out per provider type (akin to the
> segmentation challenges discussed on the recent thread titled "Patient
> Consent", so perhaps we decide to put it out of scope in favor of time
> constraints on usage, notifications of what's missing, usage
> constraints,
> etc.), but I'm listing this for discussion completeness.
>
> Finally, I'm assuming that for interoperability and attractiveness of
> standardization, we'd want to say that (barring the above concerns if
> solved) if a data item is *available* in the record, and Alice chooses to
> share it as part of the "virtual clipboard" resource set context, then it
> *must* be included. In technical terms, this would equate to the resource
> server supporting an API call that extracts out a bunch of potentially
> disparate data fields and provides them, because it supports the use case
> (i.e., provides a lot of value). We could separately think about whether
> extensibility is okay or not in the context of HEART.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock
> Summits
> and UnSummits* are coming to <http://summits.forgerock.com/> *Sydney,
> London, and Paris!*
>
> On Tue, Jul 19, 2016 at 4:51 AM, Debbie Bucci <debbucci at gmail.com
> <javascript:;>> wrote:
>
> > Now that we agree the RPT is essentially an suthorization to release ...
> > changing thread to focus on resource set.
> >
> > >>Can you elaborate a little on what you're thinking in terms of
> > >>defining
> > a resource set? I imagine that the "clipboard" resource set would vary
> > quite a bit based on the provider and their specialty. Are you
> > suggesting that we attempt to define a universal set of fields that
> > everyone would need as a baseline?
> >
> > Really need someone that knows FHIR in great detail to weigh in but ....
> >
> > it seems to me that there are general classes to authorize (meds
> > allergies
> > etc) that could generally be placed in the resource set to allow
> > specific implementations to gather the info needed within those
> > classes throttled by the classification code.
> >
> > I was going to look at a few examples but as I recall - with
> > exceptions to specialty specific questions much of the paper form are
> > the exact same questions from provider to provider
> >
> > >>Or are you thinking that we should just acknowledge the existence of
> > something called a clipboard resource set, and let implementors decide
> > for themselves what that means?
> >
> > Believe there needs to be some consistency but ack need for extensions
> >
> > _______________________________________________
> > Openid-specs-heart mailing list
> > Openid-specs-heart at lists.openid.net <javascript:;>
> > 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/20160721/a
> a07c233/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Jul 2016 12:06:42 -0400
> From: Debbie Bucci <debbucci at gmail.com <javascript:;>>
> To: Eve Maler <eve.maler at forgerock.com <javascript:;>>
> Cc: "openid-specs-heart at lists.openid.net <javascript:;>"
> <openid-specs-heart at lists.openid.net <javascript:;>>
> Subject: Re: [Openid-specs-heart] New thread - What is in a clipboard
> resource set?
> Message-ID:
> <CAG6zQ1ZVAO7arnFjt253SeY6PDmQtUd0VPUY=pEpzuf=
> f+DzXg at mail.gmail.com <javascript:;>>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Jul 21, 2016 at 11:39 AM, Eve Maler <eve.maler at forgerock.com
> <javascript:;>> wrote:
>
> > Just to level-set, there are three links in the current use case to
> > sources that describe potentially interesting data (though not
> > directly how they map to FHIR, as far as I can see):
> >
> > - Use case
> >
> <
> https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Ot
> hers_UMA_FHIR>
> > - PGHD
> >
> <
> https://www.healthit.gov/policy-researchers-implementers/patient-generated-
> health-data>
> > - Common Clinical Data Set
> >
> <
> https://www.healthit.gov/sites/default/files/commonclinicaldataset_ml_11-4-
> 15.pdf>
> > - Virtual clipboard
> >
> <
> https://www.wedi.org/home/virtual-clipboard-to-improve-patient-data-collect
> ion>
> > (this link
> >
> <
> http://www.wedi.org/docs/default-document-library/virtual-clipboard-definit
> ion-and-design-document.pdf?sfvrsn=0>
> > is actually more helpful -- I've changed it in the use case)
> >
> > And based on one of our telecon conversations, we provided this list
> > right in the use case, where the first item might possibly encompass
> > some of the others by definition:
> >
> > 1. Virtual clipboard
> > 2. Basic patient profile /Patient)
> > 3. Medication history (/MedicationDispense, /MedicationAdministration)
> > 4. Immunizations (/Immunization.vaccineCode , /Immunization.status)
> > 5. Allergies (/AllergyIntolerance)
> > 6. Problem list /Condition.code, /Condition.status)
> > 7. Labs (/DiagnosticReport.code - LOINC
> > /DiagnosticReport.codedDiagnostics - SNOMED)
> > 8. Basic insurance info? EOB?
> > 9. (what else? Keep it simple)
> >
> > Here was my guess about directions, given that a use-case-based
> > definition of this resource set is meant to encompass baseline
> > information before a first visit.
> >
>
> Agree - basic info to start the conversation - vs. a clinical referral for
> specific illness - that may be a follow-on request.
>
>
> > First, we want to keep firmly in our minds that Alice's motivation to
> > share this information at all is as a convenience vs. sharing it in a
> > more onerous, brittle fashion (e.g., having to keep updating her meds
> > list later, spending time printing forms, arriving early to the first
> > appointment...). So we don't "win" if we don't hit that mark.
> >
>
> If we focus on convenience first - then other benefits may follow.
>
> >
> > Second, labs and EOBs look like the "odd items out" on that list for a
> > first visit. Am I right? And what's missing? And what's the "FHIR
> > concordance" for all this? Can one actually be done?
> >
>
> Agree no labs and EOB but in US basic insurance (payer as noted below) info
> will be needed. Is emergency contact part of demographics (need to
> look). How do capture both OTC meds, herbs ect? (some of that may be
> covered as well) Some information ex: - why are you making the
> appointment and other things of that nature would be out of scope - or
> perhaps an extension?
>
>
>
> >
> > Third, there would be some kind of a "matrix of requesting-side
> > appropriateness" for what is to be shared:
> >
> > - *Payment info:* E.g., there's a particular type of insurance
> > infrastructure in the US, but in Canada, it would look different. So
> the
> > "insurance info" reference in #8 would need to vary or be missing per
> > jurisdiction.
> >
> >
> > -
> > - *Provider services:* There *may* be a fundamental mismatch between
> > the nature of health information available and what the provider can
> even
> > do. When it comes to, say, chiropractic, is there an appropriateness
> or
> > privacy concern about providing meds/allergy information? It's a
> complex
> > technical question to imagine leaving this info out per provider type
> (akin
> > to the segmentation challenges discussed on the recent thread titled
> > "Patient Consent", so perhaps we decide to put it out of scope in
> favor
> of
> > time constraints on usage, notifications of what's missing, usage
> > constraints, etc.), but I'm listing this for discussion completeness.
> >
> > Finally, I'm assuming that for interoperability and attractiveness of
> > standardization, we'd want to say that (barring the above concerns if
> > solved) if a data item is *available* in the record, and Alice chooses
> > to share it as part of the "virtual clipboard" resource set context,
> > then it
> > *must* be included. In technical terms, this would equate to the
> > resource server supporting an API call that extracts out a bunch of
> > potentially disparate data fields and provides them, because it
> > supports the use case (i.e., provides a lot of value). We could
> > separately think about whether extensibility is okay or not in the
> context
> of HEART.
> >
>
> Agree
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <
> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160721/9
> 4c34ee2/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Jul 2016 17:15:22 -0400
> From: "Nancy Lush" <nlush at lgisoftware.com <javascript:;>>
> To: "'Debbie Bucci'" <debbucci at gmail.com <javascript:;>>, "'Eve Maler'"
> <eve.maler at forgerock.com <javascript:;>>
> Cc: openid-specs-heart at lists.openid.net <javascript:;>
> Subject: Re: [Openid-specs-heart] New thread - What is in a clipboard
> resource set?
> Message-ID: <0a2201d1e395$040da390$0c28eab0$@lgisoftware.com>
> Content-Type: text/plain; charset="utf-8"
>
> The Argonaut Group has implemented (or will soon complete) the following
> resources in FHIR:
>
> * Patient (demographics)
>
> * Allergies
>
> * Problems & Health concerns (Condition/Problem)
>
> * Vital Signs
>
> * Labs
>
> * Smoking Status
>
> * Care Team (Some vendors have Care Plan of which Care Team is a
> subset.)
>
> * Medications
>
> * Immunizations
>
> * Goals
>
> * UDI (Device)
>
> * Procedures
>
> * Plan of Treatment
>
> * Assessment
>
> These pretty much match the Common Clinical Data Set. Why don?t we start
> with that list?
>
> Yes, Eve, it does include labs.
>
>
>
> The virtual clipboard reference is a bit askew since the virtual clipboard
> initial pilot seems much smaller in scope. Perhaps it is just me, but I am
> confused by that reference added in.
>
>
>
> -Nancy
>
>
>
> From: Openid-specs-heart
> [mailto:openid-specs-heart-bounces at lists.openid.net <javascript:;>] On
> Behalf Of Debbie
> Bucci
> Sent: Thursday, July 21, 2016 12:07 PM
> To: Eve Maler <eve.maler at forgerock.com <javascript:;>>
> Cc: openid-specs-heart at lists.openid.net <javascript:;>
> Subject: Re: [Openid-specs-heart] New thread - What is in a clipboard
> resource set?
>
>
>
>
>
>
>
> On Thu, Jul 21, 2016 at 11:39 AM, Eve Maler <eve.maler at forgerock.com
> <javascript:;>
> <mailto:eve.maler at forgerock.com <javascript:;>> > wrote:
>
> Just to level-set, there are three links in the current use case to sources
> that describe potentially interesting data (though not directly how they
> map
> to FHIR, as far as I can see):
>
> * Use case
> <
> https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Ot
> hers_UMA_FHIR>
>
> * PGHD
> <
> https://www.healthit.gov/policy-researchers-implementers/patient-generated-
> health-data>
> * Common Clinical Data Set
> <
> https://www.healthit.gov/sites/default/files/commonclinicaldataset_ml_11-4-
> 15.pdf>
> * Virtual clipboard
> <
> https://www.wedi.org/home/virtual-clipboard-to-improve-patient-data-collect
> ion> (this link
> <
> http://www.wedi.org/docs/default-document-library/virtual-clipboard-definit
> ion-and-design-document.pdf?sfvrsn=0> is actually more helpful -- I've
> changed it in the use case)
>
> And based on one of our telecon conversations, we provided this list right
> in the use case, where the first item might possibly encompass some of the
> others by definition:
>
> 1. Virtual clipboard
> 2. Basic patient profile /Patient)
> 3. Medication history (/MedicationDispense, /MedicationAdministration)
> 4. Immunizations (/Immunization.vaccineCode , /Immunization.status)
> 5. Allergies (/AllergyIntolerance)
> 6. Problem list /Condition.code, /Condition.status)
> 7. Labs (/DiagnosticReport.code - LOINC
> /DiagnosticReport.codedDiagnostics - SNOMED)
> 8. Basic insurance info? EOB?
> 9. (what else? Keep it simple)
>
> Here was my guess about directions, given that a use-case-based definition
> of this resource set is meant to encompass baseline information before a
> first visit.
>
>
>
> Agree - basic info to start the conversation - vs. a clinical referral for
> specific illness - that may be a follow-on request.
>
>
>
>
>
> First, we want to keep firmly in our minds that Alice's motivation to share
> this information at all is as a convenience vs. sharing it in a more
> onerous, brittle fashion (e.g., having to keep updating her meds list
> later,
> spending time printing forms, arriving early to the first appointment...).
> So we don't "win" if we don't hit that mark.
>
>
>
> If we focus on convenience first - then other benefits may follow.
>
>
>
> Second, labs and EOBs look like the "odd items out" on that list for a
> first
> visit. Am I right? And what's missing? And what's the "FHIR concordance"
> for
> all this? Can one actually be done?
>
>
>
> Agree no labs and EOB but in US basic insurance (payer as noted below) info
> will be needed. Is emergency contact part of demographics (need to
> look).
> How do capture both OTC meds, herbs ect? (some of that may be covered as
> well) Some information ex: - why are you making the appointment and other
> things of that nature would be out of scope - or perhaps an extension?
>
>
>
>
>
>
>
> Third, there would be some kind of a "matrix of requesting-side
> appropriateness" for what is to be shared:
>
> * Payment info: E.g., there's a particular type of insurance
> infrastructure in the US, but in Canada, it would look different. So the
> "insurance info" reference in #8 would need to vary or be missing per
> jurisdiction.
>
> *
> * Provider services: There may be a fundamental mismatch between the
> nature of health information available and what the provider can even do.
> When it comes to, say, chiropractic, is there an appropriateness or privacy
> concern about providing meds/allergy information? It's a complex technical
> question to imagine leaving this info out per provider type (akin to the
> segmentation challenges discussed on the recent thread titled "Patient
> Consent", so perhaps we decide to put it out of scope in favor of time
> constraints on usage, notifications of what's missing, usage constraints,
> etc.), but I'm listing this for discussion completeness.
>
> Finally, I'm assuming that for interoperability and attractiveness of
> standardization, we'd want to say that (barring the above concerns if
> solved) if a data item is available in the record, and Alice chooses to
> share it as part of the "virtual clipboard" resource set context, then it
> must be included. In technical terms, this would equate to the resource
> server supporting an API call that extracts out a bunch of potentially
> disparate data fields and provides them, because it supports the use case
> (i.e., provides a lot of value). We could separately think about whether
> extensibility is okay or not in the context of HEART.
>
>
>
> Agree
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <
> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160721/0
> 97ef64b/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 21 Jul 2016 22:28:23 -0400
> From: Adrian Gropper <agropper at healthurl.com <javascript:;>>
> To: Nancy Lush <nlush at lgisoftware.com <javascript:;>>
> Cc: "openid-specs-heart at lists.openid.net <javascript:;>"
> <openid-specs-heart at lists.openid.net <javascript:;>>
> Subject: Re: [Openid-specs-heart] New thread - What is in a clipboard
> resource set?
> Message-ID:
> <
> CANYRo8gh6mPhQcTGAfbDfp94UUA5AN4UK0ecH-MsNxCeWEiWug at mail.gmail.com
> <javascript:;>>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks Eve for sending around the various links and for bringing the WEDI
> document
> <
> http://www.wedi.org/docs/default-document-library/virtual-clipboard-definit
> ion-and-design-document.pdf?sfvrsn=0>
> to our attention. It represents a good point of reference for how some of
> the industry will consider adoption of HEART. I will use the WEDI
> terminology for this comment.
>
> The WEDI document does not mention the reality that there is zero adoption
> of federated patient identity services in healthcare today. I think HEART
> needs to consider how to ease the path to broad adoption of OpenID Connect
> while also staying focused on our charter. I'm not sure how to interpret
> what WEDI calls "External Security Services" (figure on p13 - b).
> Presumably it's an OpenID Connect IDP? Since patient identity federations
> don't exist yet and it's not clear who would govern such a federation, we
> need to be careful about our IDP assumptions and federations in general.
>
> The rest of the diagram on p13 is much easier to understand if we treat the
> Application Services (purple) as just another instance of an External
> Application Partner (yellow). All four blocks have an Inter-application
> path
> (isn't this just FHIR?) and a Security Communication Path (isn't this just
> OAuth and UMA?).
>
> The Mobile App (green) is pretty clear. No matter what, we can assume that
> we need a mobile secure element under control of a mobile UI. Per the WEDI
> model, the Mobile App needs to be recognized by the (optional) IDP and what
> WEDI calls the Application Security Services (orange).
>
> The Application Security Services (orange) is the only one containing an
> Authorization Service so it presumably maps into HEART. Regardless of the
> fact that WEDI put a gray rectangle around this and the Application
> Services
> block, HEART does not benefit from adopting this combination.
> Doing so is unnecessary and might even violate our charter.
>
> We can conclude that WEDI would support an UMA AS as the manager of the
> Security Communication Path that controls FHIR-standard resource access.
>
> First and foremost, IMHO, HEART needs to consider how we can drive adoption
> of a patient-centered authorization service without forcing all of the
> External Application Partners, including the Application Services block, to
> worry about also federating with an IDP. In other words, HEART must be
> clear
> whether we are asking the FHIR endpoints (PHR, EHR, Payer,
> whatever...) to trust the AS regardless of whether an IDP is trusted as
> well.
>
> This post about WEDI might be a separate thread from whatever we mean by
> virtual clipboard but I put it here first because WEDI's is the only
> definition of a virtual clipboard that we've seen.
>
> Adrian
>
> On Thu, Jul 21, 2016 at 5:15 PM, Nancy Lush <nlush at lgisoftware.com
> <javascript:;>> wrote:
>
> > The Argonaut Group has implemented (or will soon complete) the
> > following resources in FHIR:
> >
> > ? Patient (demographics)
> >
> > ? Allergies
> >
> > ? Problems & Health concerns (Condition/Problem)
> >
> > ? Vital Signs
> >
> > ? Labs
> >
> > ? Smoking Status
> >
> > ? Care Team (Some vendors have Care Plan of which Care Team is a
> > subset.)
> >
> > ? Medications
> >
> > ? Immunizations
> >
> > ? Goals
> >
> > ? UDI (Device)
> >
> > ? Procedures
> >
> > ? Plan of Treatment
> >
> > ? Assessment
> >
> > These pretty much match the Common Clinical Data Set. Why don?t we
> > start with that list?
> >
> > Yes, Eve, it does include labs.
> >
> >
> >
> > The virtual clipboard reference is a bit askew since the virtual
> > clipboard initial pilot seems much smaller in scope. Perhaps it is
> > just me, but I am confused by that reference added in.
> >
> >
> >
> > -Nancy
> >
> >
> >
> > *From:* Openid-specs-heart [mailto:
> > openid-specs-heart-bounces at lists.openid.net <javascript:;>] *On Behalf
> Of *Debbie
> > Bucci
> > *Sent:* Thursday, July 21, 2016 12:07 PM
> > *To:* Eve Maler <eve.maler at forgerock.com <javascript:;>>
> > *Cc:* openid-specs-heart at lists.openid.net <javascript:;>
> > *Subject:* Re: [Openid-specs-heart] New thread - What is in a
> > clipboard resource set?
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jul 21, 2016 at 11:39 AM, Eve Maler <eve.maler at forgerock.com
> <javascript:;>>
> > wrote:
> >
> > Just to level-set, there are three links in the current use case to
> > sources that describe potentially interesting data (though not
> > directly how they map to FHIR, as far as I can see):
> >
> > - Use case
> >
> > <https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_
> > and_Others_UMA_FHIR>
> >
> >
> > - PGHD
> >
> <
> https://www.healthit.gov/policy-researchers-implementers/patient-generated-
> health-data>
> > - Common Clinical Data Set
> >
> <
> https://www.healthit.gov/sites/default/files/commonclinicaldataset_ml_11-4-
> 15.pdf>
> > - Virtual clipboard
> >
> <
> https://www.wedi.org/home/virtual-clipboard-to-improve-patient-data-collect
> ion>
> > (this link
> >
> <
> http://www.wedi.org/docs/default-document-library/virtual-clipboard-definit
> ion-and-design-document.pdf?sfvrsn=0>
> > is actually more helpful -- I've changed it in the use case)
> >
> > And based on one of our telecon conversations, we provided this list
> > right in the use case, where the first item might possibly encompass
> > some of the others by definition:
> >
> > 1. Virtual clipboard
> > 2. Basic patient profile /Patient)
> > 3. Medication history (/MedicationDispense, /MedicationAdministration)
> > 4. Immunizations (/Immunization.vaccineCode , /Immunization.status)
> > 5. Allergies (/AllergyIntolerance)
> > 6. Problem list /Condition.code, /Condition.status)
> > 7. Labs (/DiagnosticReport.code - LOINC
> > /DiagnosticReport.codedDiagnostics - SNOMED)
> > 8. Basic insurance info? EOB?
> > 9. (what else? Keep it simple)
> >
> > Here was my guess about directions, given that a use-case-based
> > definition of this resource set is meant to encompass baseline
> > information before a first visit.
> >
> >
> >
> > Agree - basic info to start the conversation - vs. a clinical referral
> > for specific illness - that may be a follow-on request.
> >
> >
> >
> >
> >
> > First, we want to keep firmly in our minds that Alice's motivation to
> > share this information at all is as a convenience vs. sharing it in a
> > more onerous, brittle fashion (e.g., having to keep updating her meds
> > list later, spending time printing forms, arriving early to the first
> > appointment...). So we don't "win" if we don't hit that mark.
> >
> >
> >
> > If we focus on convenience first - then other benefits may follow.
> >
> >
> >
> > Second, labs and EOBs look like the "odd items out" on that list for a
> > first visit. Am I right? And what's missing? And what's the "FHIR
> > concordance" for all this? Can one actually be done?
> >
> >
> >
> > Agree no labs and EOB but in US basic insurance (payer as
> > noted below) info will be needed. Is emergency contact part of
> > demographics (need to look). How do capture both OTC meds, herbs ect?
> > (some of that may be covered as well) Some information ex: - why are
> you
> > making the appointment and other things of that nature would be out of
> > scope - or perhaps an extension?
> >
> >
> >
> >
> >
> >
> >
> > Third, there would be some kind of a "matrix of requesting-side
> > appropriateness" for what is to be shared:
> >
> > - *Payment info:* E.g., there's a particular type of insurance
> > infrastructure in the US, but in Canada, it would look different. So
> the
> > "insurance info" reference in #8 would need to vary or be missing per
> > jurisdiction.
> >
> >
> > -
> > - *Provider services:* There *may* be a fundamental mismatch between
> > the nature of health information available and what the provider can
> even
> > do. When it comes to, say, chiropractic, is there an appropriateness
> or
> > privacy concern about providing meds/allergy information? It's a
> complex
> > technical question to imagine leaving this info out per provider type
> (akin
> > to the segmentation challenges discussed on the recent thread titled
> > "Patient Consent", so perhaps we decide to put it out of scope in
> favor
> of
> > time constraints on usage, notifications of what's missing, usage
> > constraints, etc.), but I'm listing this for discussion completeness.
> >
> > Finally, I'm assuming that for interoperability and attractiveness of
> > standardization, we'd want to say that (barring the above concerns if
> > solved) if a data item is *available* in the record, and Alice chooses
> > to share it as part of the "virtual clipboard" resource set context,
> > then it
> > *must* be included. In technical terms, this would equate to the
> > resource server supporting an API call that extracts out a bunch of
> > potentially disparate data fields and provides them, because it
> > supports the use case (i.e., provides a lot of value). We could
> > separately think about whether extensibility is okay or not in the
> context
> of HEART.
> >
> >
> >
> > Agree
> >
> > _______________________________________________
> > Openid-specs-heart mailing list
> > Openid-specs-heart at lists.openid.net <javascript:;>
> > 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/20160721/d
> b269165/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 22 Jul 2016 00:39:03 -0400
> From: Adrian Gropper <agropper at healthurl.com <javascript:;>>
> To: John Moehrke <johnmoehrke at gmail.com <javascript:;>>
> Cc: HEART List <openid-specs-heart at lists.openid.net <javascript:;>>
> Subject: Re: [Openid-specs-heart] Dissecting the Release of
> information form
> Message-ID:
> <CANYRo8h_v3PCouj=+WS4rDnbu2kiojNxjsfsdLkG7NY2Qd=
> KCw at mail.gmail.com <javascript:;>>
> Content-Type: text/plain; charset="utf-8"
>
> Debbie's comment suggests two things:
>
> First, whatever the HEART protocols are, the UMA AS (wherever it is) must
> be
> able to display a form that's functionally equivalent to the NYP ROI
> authorization _before_ an actual requesting party or client are on the
> scene. The actual authorization, equivalent to signing the ROI form once
> the
> client is filled in, must be able to happen automatically otherwise we
> might
> as well skip the UMA pieces.
>
> Second, the ROI form would be enhanced by adding a Confidentiality Code
> enabled feature. Let's put this enhancement aside for now because we can't
> count on all resources supporting the codes and we don't really know how to
> implement them to improve the user experience. Obviously support for the
> confidentiality codes would improve things for everyone but I don't think
> they solve any critical path problems.
>
> Back to the HEART approach to ROI form. Let's get clear on what is "prior
> consent" and what is "authorization" in a patient-centered approach that
> allows for an AS separate from any particular FHIR resource server. Since
> the "authorization" step is effectively automated through the AS, the
> patient (grantor, to be exact) interfaced "consent" actually involves two
> sub-steps I will call C1 and C2. C1 is where the patient specifies, or at
> least agrees to, a particular UMA AS as their proxy. C1 is clearly a form
> hosted by the FHIR resource server, typically an EHR. C2 is where the
> patient makes whatever selections (with or without benefit of
> confidentiality codes) on something that looks like the NYP ROI form. C2 is
> clearly a form hosted by the authorization server defined in C1.
>
> I believe this is the only way HEART can work. Whatever we do, prior
> consent
> will be split between an AS specification at the RS and a policy capture at
> the AS.
>
> The HEART profiles need to make this split of the prior consent process
> palatable to the FHIR resource servers and friendly to the patient. This
> could create a tension between RSs wanting to customize and compete on
> their
> user experience and the patient's potential interest in having all prior
> consent forms presented in a consistent way regardless of the RS.
> This is a classic problem in standards design. We need to address this
> reality first and provide input to UMA and maybe to FHIR to make sure they
> enable this combination of competition by RS to improve ROI form usability
> and consistency across resource registration user experience regardless of
> RS or jurisdictional constraints such as HIPAA or 42CFR Part2.
>
> Adrian
>
>
>
>
>
> On Wednesday, July 20, 2016, John Moehrke <johnmoehrke at gmail.com
> <javascript:;>> wrote:
>
> > Yeah
> >
> > On Jul 20, 2016 5:23 PM, "Debbie Bucci" <debbucci at gmail.com
> <javascript:;>
> > <javascript:_e(%7B%7D,'cvml','debbucci at gmail.com <javascript:;>');>>
> wrote:
> >
> >> Glen
> >>
> >> What struck me about the ROI is the potential to use as an example for
> >> general use. All along Adrian had been trying to point out the
> >> similarities and only until recently have I begun to understand the
> >> how parts of the UMA protocol could be used to effectively describe
> >> (and essentially is ) an authorization for release of info.
> >>
> >> I'd also like to propose that although the confidentiality codes may
> >> not be used in FHIR the vocabulary has been accepted by HL7 so why
> >> couldn't that be used as a scope that all would consume and
> >> understand? How the value iRS chooses to process out of scope.
> >> Would f my that be a baby step in the right direction?
> >>
> >>
> >> On July 19, 2016, at 12:34 PM, "Glen Marshall [SRS]"
> >> <gfm at securityrs.com <javascript:;> <javascript:_e(%7B%7D,'cvml','
> gfm at securityrs.com <javascript:;>');>>
> wrote:
> >>
> >>
> >> While I think that mapping a Release of Information form onto UMA
> >> protocol data would be useful as a proof of concept exercise, I am
> >> left
> >> wondering:
> >>
> >> ? The form itself is just an instance.
> >>
> >> o Has it been vetted for peer review at the policy level, i.e., can it
> >> be easily adapted for more general use?
> >>
> >> o Is there a compendium of federal and state requirements we can
> >> reference, or can we use a reasonable guess to start the analysis
> >> without extensive debate? We need to avoid the 42CFR quicksand, and
> >> similar well-bounded cases.
> >>
> >> o Is there some general user experience design guidance ? paper or
> >> on-screen ? for collecting Release of Information from patients or
> >> their authorized representatives?
> >>
> >> o How can we minimize the cognitive challenges that sick people have
> >> when presented with a sheaf of forms to sign when seeking treatment?
> >>
> >> o Is this work in-scope for HEART?
> >>
> >> ? Are we going to propose a standardized API for such mapping?
> >>
> >> o Is this work in-scope for HEART?
> >>
> >>
> >>
> >> I think the most useful outcome of this line if inquiry is proof that
> >> OAuth and UMA can be used for health care data access control,
> >> without extensions or with a small set of extensions.
> >>
> >>
> >>
> >> Glen
> >>
> >>
> >>
> >> Glen F. Marshall
> >>
> >> Consultant
> >>
> >> Security Risk Solutions, Inc.
> >>
> >> 698 Fishermans Bend
> >>
> >> Mount Pleasant, SC 29464
> >>
> >> Tel: (610) 644-2452
> >>
> >> Mobile: (610) 613-3084
> >>
> >> gfm at securityrs.com <javascript:;>
> >> <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com <javascript:;>');>
> >>
> >> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Openid-specs-heart mailing list
> >> Openid-specs-heart at lists.openid.net <javascript:;>
> >> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart at lists.openid.net
> <javascript:;>');>
> >> 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/20160722/3
> 5142895/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net <javascript:;>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
> ------------------------------
>
> End of Openid-specs-heart Digest, Vol 82, Issue 5
> *************************************************
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net <javascript:;>
> 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/20160725/393698d5/attachment-0001.html>
More information about the Openid-specs-heart
mailing list