[Openid-specs-heart] Openid-specs-heart Digest, Vol 86, Issue 11

Adrian Gropper agropper at healthurl.com
Sat Aug 20 14:40:22 UTC 2016


I don't think this is relevant to HEART because patient matching is solved
by self-registration of the patient it does not consider either the name or
the DOB.

Adrian

On Sat, Aug 20, 2016 at 8:43 AM, Debbie Bucci <debbucci at gmail.com> wrote:

>
>>
> First off - apologies to Catherine & Chance *welcome!)  for the delayed
> approval.   If you use a different email than the one listed on the
> listserv  then flag needs to be reset.
>
> I don't want to derail the conversation but I was surprised to learn that
> in some populations birth dates are not readily known - a best guess or ...
> not accurately provided for an number of reasons.   So date too may be
> mildly dynamic as well.
>
> On Fri, Aug 19, 2016 at 4:44 PM, Catherine Schulten <
> catherine.schulten at lifemedid.com> wrote:
>
>> The data attribute "Name" is also mildly dynamic, especially for women
>> who may have a maiden Lname for a period of time, then a married Lname and
>> revert back to the maiden name after a divorce or she may maintain a maiden
>> Lname for a period of time after her marriage and then choose to hyphenate
>> later or some other combination of events.
>> First names are also mildly dynamic with the use of nicknames and legal
>> names.
>>
>> About the only static demographic attribute is DOB and when you consider
>> a possible pool of reasonable dates ranging from today to around 100 years
>> ago there is a finite set of 36,500 date possibilities.
>>
>> Catherine S.
>>
>>
>>
>> -----Original Message-----
>> From: Openid-specs-heart [mailto:openid-specs-heart-bou
>> nces at lists.openid.net] On Behalf Of openid-specs-heart-request at lis
>> ts.openid.net
>> Sent: Thursday, August 18, 2016 12:23 PM
>> To: openid-specs-heart at lists.openid.net
>> Subject: Openid-specs-heart Digest, Vol 86, Issue 11
>>
>> Send Openid-specs-heart mailing list submissions to
>>         openid-specs-heart at lists.openid.net
>>
>> 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
>>
>> You can reach the person managing the list at
>>         openid-specs-heart-owner at lists.openid.net
>>
>> 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: Resource/Scope Proposal #2 (Danny van Leeuwen)
>>    2. Re: Resource/Scope Proposal #2 (Glen Marshall [SRS])
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 18 Aug 2016 11:11:18 -0400
>> From: Danny van Leeuwen <danny at health-hats.com>
>> Cc: HEART List <openid-specs-heart at lists.openid.net>
>> Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2
>> Message-ID:
>>         <CAP5tyWv9h1a3kDGvozNRgbN0yPY21sP58_H_ZgerrEbev7ZzMQ at mail.gm
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> As I read the list of resources I wonder about static, mildly dynamic,
>> and greatly dynamic or fluid resources.  Name, DOB are examples of static
>> resources. Allergies, smoking status and procedures are mildly dynamic.
>> Medications and plan are quite fluid.  What are the implications of this
>> static->fluid continuum in this whole discussion?
>>
>> On Tue, Aug 16, 2016 at 5:15 PM, Nancy Lush <nlush at lgisoftware.com>
>> wrote:
>>
>> > HEART proposal Example 2
>> >
>> > (I apologize in advance for such a long email.  Also, sorry for the
>> > delay as I was away on vacation and catching up.)
>> >
>> >
>> >
>> > Justin proposed that team members propose suggested resources, scopes
>> > and what they mean.  The objective is to suggest positive solutions.
>> > None will be totally ?correct? but that is OK because together these
>> > suggestions can be combined and adjusted to reach the ?correct?
>> > solution.  Based on that, I will create another stab as an alternative.
>> >
>> > 1.       First, since HEART is based on FHIR, we should not expect any
>> > changes in FHIR, at least for the 1.0 version.  The resources should
>> > be the FHIR resources.  I am stating this as a discrete point.  I
>> > think we all agree, but I would like to know that we do indeed concur.
>> >
>> > 2.       In an attempt to simplify, my original list of resources was
>> the
>> > list of FHIR resources that are implemented by the Argonaut group.
>> > Since this is the set that most of the current servers have
>> > implemented, we could expect them to be supported first. (I have no
>> > objection to the list being the complete list of FHIR resources, if
>> > that is preferred by the group.) This subset list also happens to
>> > correspond to the Common Clinical Data set.  (I am suggesting that we
>> > start with this limited set in the assumption that we could implement
>> > HEART as soon as it is specified.)
>> >
>> > ?         Patient demographics (Known as ?patient? per FHIR)
>> >
>> > ?         Allergies
>> >
>> > ?         Problems & Health concerns (Conditions)
>> >
>> > ?         Vital Signs  (Category of Observations)
>> >
>> > ?         Labs
>> >
>> > ?         Smoking Status
>> >
>> > ?         Care Team  (Some vendors have Care Plan of which Care Team is
>> a
>> > subset.)
>> >
>> > ?         Medications
>> >
>> > ?         Immunizations
>> >
>> > ?         Goals
>> > ---- this next subset of resources could expand on the above list and
>> > are a continuation of the Argonaut implementation list.
>> >
>> > ?         UDI  (Device)
>> >
>> > ?         Procedures
>> >
>> > ?         Plan of Treatment
>> >
>> > ?         Assessment
>> >
>> > 3.       The chart below is simply to demonstrate to those less familiar
>> > with FHIR how this might work.  All of these results are per patient.
>> >
>> > Common Name
>> >
>> > FHIR Resource
>> >
>> > Category if applies
>> >
>> > Other filter
>> >
>> >
>> >
>> > Patient demographics
>> >
>> > Patient
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Allergies
>> >
>> > AllergyIntolerance
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Problems and Health Concerns
>> >
>> > Condition
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Vital Signs
>> >
>> > Observation
>> >
>> > Vital-signs
>> >
>> >
>> >
>> >
>> >
>> > Lab Results
>> >
>> > DiagnosticReport
>> >
>> > Lab
>> >
>> >
>> >
>> >
>> >
>> > Smoking Status
>> >
>> > Observation
>> >
>> >
>> >
>> > Code=72166-2
>> >
>> >
>> >
>> > Care Team
>> >
>> > CarePlan
>> >
>> > CareTeam
>> >
>> >
>> >
>> >
>> >
>> > Medications
>> >
>> > MedicationStatement
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Medications
>> >
>> > MedicationOrder
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Immunizations
>> >
>> > Immunization
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Goals
>> >
>> > Goal
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > UDI
>> >
>> > Device
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Procedures
>> >
>> > Procedure
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Plan of Treatment
>> >
>> > (Still being defined in re-sprint)
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Assessment
>> >
>> > (Still being defined in re-sprint)
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > There are different filters for each resource type.  These should not
>> > be addressed by HEART in terms of having our patient, Alice, provide
>> > varying permissions at that level.
>> >
>> > The reasons for limiting the resources to a list like this is because
>> > they are already implemented and tested for many servers and because
>> > they are a great first step.  If we can do this in HEART for starters
>> > we will have achieved a lot!
>> >
>> > 4.       Terminology:  This group often uses different terminology which
>> > causes confusion.  Eve has suggested several times that we focus on
>> > clarifying terminology and has begun that effort in her use case
>> document.
>> > One term that has bothered me in the past is the term ?Resource Set?.
>> > At the HL7 conference, Josh clarified this for me.  My current
>> > understanding is that UMA uses ?Resource Set? for the same purpose as
>> > FHIR uses ?Resource Type?, or as is often shortened in FHIR as
>> > ?Resource?.  So in FHIR, if we request medications for the patient
>> > Alice, we refer to the resource ?Medications?, while UMA refers to
>> > this as a ?Resource Set? for the patient Alice.  (The result would be
>> > a list of medications for Alice.)  If this understanding is currently
>> incorrect, can someone please correct it?
>> >
>> > 5.       Grouping of resources:  Let?s assume that we have agreed on the
>> > list of FHIR resources.  I propose that we allow Alice to select which
>> > of the list she desires to share, with the addition of choices ?all?
>> > or ?none?.  The requests for the resources by the client would still
>> > be made individually for each resource.  (To me the notion of ?resource
>> set?
>> > implied that we would define a set of individual resources ? say by
>> > some category.  I would advise against using such a notion as it only
>> > complicates and does not add any benefits.)
>> >
>> > 6.       Scopes
>> >
>> > a.       Read/Write
>> >
>> >                                                          i.
>> In
>> > last week?s meeting, Justin referenced the current scope stream:
>> > individual, bulk, read, write.  Since we are specifying HEART, I would
>> > assume this is always what the patient is specifying.  So for HEART,
>> > the scope of ?bulk? is not relevant.  Further we have scopes of Read,
>> > Write, or *.  I suggest that we allow Alice to specify Read, Write,
>> > and have the ability to specify both.  These settings can be set
>> > either per resource or for all resources.
>> >
>> > Two points should be noted:
>> >
>> >                                                        ii.
>> Current
>> > implementations are supporting ?Read? and do not yet support ?Write?.
>> > We may be fine with starting with just ?Read? for version 1.0.
>> >
>> >                                                      iii.
>> Since
>> > Alice is defining what she is willing to share ? wouldn?t that be the
>> > ?Read? case?  I can imagine that we will see implementations where
>> > Alice controls her RS and in that case could specify ?Write?
>> > permissions.  For the immediate future, I would be surprised if the
>> > EMR would allow Alice to give permissions to Dr. Bob to write to an
>> > EMR.  There may be a case where Alice can give Dr. Bob permission to
>> write to her PHR.
>> >
>> > b.       Dates
>> >
>> >                                                                i.
>> My
>> > understanding from yesterday?s conversation was that we do not want to
>> > include dates in the scopes on resources, per HEART.  There are date
>> > filters available for some resources, but that is within the FHIR
>> > query specification, an outside of the HEART spec.
>> >
>> >                                                              ii.
>> Eve
>> > raised the objective of having expiration dates associated with the
>> > permissions granted, but that functionality does not apply to resource
>> > date scopes
>> >
>> >                                                            iii.      So
>> > ?dates? are not considered as a scope per this discussion.
>> >
>> > c.       Confidentiality codes:  I was the culprit that initially raised
>> > the case of Alice not wanting to share her HIV condition, but only
>> > sharing her non-HIV condition.  I believe most of us would like to
>> > provide such a feature in HEART, but since that original discussion I
>> > am now of the opinion that we should NOT include this feature in
>> version 1.0.
>> >
>> >                                                          i.
>> Confidentiality
>> > codes were suggested as a potential solution to this issue.  It has
>> > been stated that some additional ?magic? needs to occur to make this
>> viable.
>> > Since it is not currently supported in current FHIR implementation,
>> > adding this to HEART in version 1.0 could derail the effort.
>> >
>> >                                                        ii.
>> Confidentiality
>> > codes are defined in FHIR as tags.
>> >
>> >                                                      iii.
>> Confidentiality
>> > codes are not implemented in most of the current servers.  Even if
>> > they were, there is not a consistent method to consistently code
>> > values across servers. This could lead to inconsistent results and be
>> > worse that not providing the feature at all.
>> >
>> >                                                      iv.            If
>> > Alice desired to not share her ?HIV? condition, we would need to add a
>> > scope to the resource request asking the server to withhold data that
>> > matches the requested confidentiality settings.  This scope is not
>> > currently defined in FHIR and we should not be attempting to change
>> > FHIR as part of our HEART 1.0 specification.
>> >
>> >                                                        v.            If
>> I
>> > were running a RS, I certainly would not be willing to send Alice?s
>> > HIV condition to the client tagged as confidential and expect the
>> > client to not share it ? instead I would want to not send the data at
>> > all ? thus the requirement to add a new scope ? which we should
>> definitely avoid.
>> >
>> >
>> >
>> > This document is also added as an attachment.
>> >
>> >
>> >
>> > -Nancy
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > *Nancy Lush          *
>> >
>> > nancy.lush at lgisoftware.com
>> >
>> > *Lush Group, Inc*
>> >
>> > Office: (401) 423-9111
>> >
>> > 28 Narragansett Ave
>> >
>> > PO Box 651
>> >
>> > www.lgisoftware.com
>> >
>> > Cell:(401) 965-9347
>> >
>> > Jamestown, RI 02835
>> >
>> >
>> >
>> > [image: LGI_logo_small]
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Openid-specs-heart mailing list
>> > Openid-specs-heart at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-heart
>> >
>> >
>>
>>
>> --
>> Danny van Leeuwen
>> 617-304-4681
>>
>> *Blog www.health-hats.com <http://www.health-hats.com/> discovering the
>> magic levers of best health* Twitter <https://twitter.com/HealthHats>
>> LinkedIn <https://www.linkedin.com/in/healthhatsdannyvl>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.openid.net/pipermail/openid-specs-heart/attach
>> ments/20160818/c294b546/attachment-0001.html>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: image001.gif
>> Type: image/gif
>> Size: 3006 bytes
>> Desc: not available
>> URL: <http://lists.openid.net/pipermail/openid-specs-heart/attach
>> ments/20160818/c294b546/attachment-0001.gif>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 18 Aug 2016 15:49:23 +0000
>> From: "Glen Marshall [SRS]" <gfm at securityrs.com>
>> To: Danny van Leeuwen <danny at health-hats.com>
>> Cc: HEART List <openid-specs-heart at lists.openid.net>
>> Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2
>> Message-ID:
>>         <DM5PR05MB32441E897A8521CB19CBB7C3CE150 at DM5PR05MB3244.namprd
>> 05.prod.outlook.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I depends on the use cases.
>>
>> However, if we are depending on some sort of metadata tagging for privacy
>> classification, more dynamic data has greater cost (no economy of scale)
>> and less value (diseconomy of scale) per metadata tag.  At some point we
>> reach a cross-over where the cost of privacy protection exceeds the risks
>> it mitigates.
>>
>> Yes, the business economic environment is out of scope for HEART.  But it
>> is not out of scope for implementers.  Our work-products need to
>> acknowledge the environment, its realities, and its limitations.
>>
>>
>> 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
>> www.SecurityRiskSolutions.com<http://www.securityrisksolutions.com/>
>>
>> From: Openid-specs-heart [mailto:openid-specs-heart-bou
>> nces at lists.openid.net] On Behalf Of Danny van Leeuwen
>> Sent: Thursday, August 18, 2016 11:11
>> Cc: HEART List <openid-specs-heart at lists.openid.net>
>> Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2
>>
>> As I read the list of resources I wonder about static, mildly dynamic,
>> and greatly dynamic or fluid resources.  Name, DOB are examples of static
>> resources. Allergies, smoking status and procedures are mildly dynamic.
>> Medications and plan are quite fluid.  What are the implications of this
>> static->fluid continuum in this whole discussion?
>>
>> On Tue, Aug 16, 2016 at 5:15 PM, Nancy Lush <nlush at lgisoftware.com
>> <mailto:nlush at lgisoftware.com>> wrote:
>> HEART proposal Example 2
>> (I apologize in advance for such a long email.  Also, sorry for the delay
>> as I was away on vacation and catching up.)
>>
>> Justin proposed that team members propose suggested resources, scopes and
>> what they mean.  The objective is to suggest positive solutions.  None will
>> be totally ?correct? but that is OK because together these suggestions can
>> be combined and adjusted to reach the ?correct? solution.  Based on that, I
>> will create another stab as an alternative.
>>
>> 1.       First, since HEART is based on FHIR, we should not expect any
>> changes in FHIR, at least for the 1.0 version.  The resources should be the
>> FHIR resources.  I am stating this as a discrete point.  I think we all
>> agree, but I would like to know that we do indeed concur.
>>
>> 2.       In an attempt to simplify, my original list of resources was the
>> list of FHIR resources that are implemented by the Argonaut group.  Since
>> this is the set that most of the current servers have implemented, we could
>> expect them to be supported first. (I have no objection to the list being
>> the complete list of FHIR resources, if that is preferred by the group.)
>> This subset list also happens to correspond to the Common Clinical Data
>> set.  (I am suggesting that we start with this limited set in the
>> assumption that we could implement HEART as soon as it is specified.)
>>
>> ?         Patient demographics (Known as ?patient? per FHIR)
>>
>> ?         Allergies
>>
>> ?         Problems & Health concerns (Conditions)
>>
>> ?         Vital Signs  (Category of Observations)
>>
>> ?         Labs
>>
>> ?         Smoking Status
>>
>> ?         Care Team  (Some vendors have Care Plan of which Care Team is a
>> subset.)
>>
>> ?         Medications
>>
>> ?         Immunizations
>>
>> ?         Goals
>> ---- this next subset of resources could expand on the above list and are
>> a continuation of the Argonaut implementation list.
>>
>> ?         UDI  (Device)
>>
>> ?         Procedures
>>
>> ?         Plan of Treatment
>>
>> ?         Assessment
>>
>> 3.       The chart below is simply to demonstrate to those less familiar
>> with FHIR how this might work.  All of these results are per patient.
>> Common Name
>>
>> FHIR Resource
>>
>> Category if applies
>>
>> Other filter
>>
>>
>>
>> Patient demographics
>>
>> Patient
>>
>>
>>
>>
>>
>>
>>
>> Allergies
>>
>> AllergyIntolerance
>>
>>
>>
>>
>>
>>
>>
>> Problems and Health Concerns
>>
>> Condition
>>
>>
>>
>>
>>
>>
>>
>> Vital Signs
>>
>> Observation
>>
>> Vital-signs
>>
>>
>>
>>
>>
>> Lab Results
>>
>> DiagnosticReport
>>
>> Lab
>>
>>
>>
>>
>>
>> Smoking Status
>>
>> Observation
>>
>>
>>
>> Code=72166-2
>>
>>
>>
>> Care Team
>>
>> CarePlan
>>
>> CareTeam
>>
>>
>>
>>
>>
>> Medications
>>
>> MedicationStatement
>>
>>
>>
>>
>>
>>
>>
>> Medications
>>
>> MedicationOrder
>>
>>
>>
>>
>>
>>
>>
>> Immunizations
>>
>> Immunization
>>
>>
>>
>>
>>
>>
>>
>> Goals
>>
>> Goal
>>
>>
>>
>>
>>
>>
>>
>> UDI
>>
>> Device
>>
>>
>>
>>
>>
>>
>>
>> Procedures
>>
>> Procedure
>>
>>
>>
>>
>>
>>
>>
>> Plan of Treatment
>>
>> (Still being defined in re-sprint)
>>
>>
>>
>>
>>
>>
>>
>> Assessment
>>
>> (Still being defined in re-sprint)
>>
>>
>>
>>
>>
>>
>>
>> There are different filters for each resource type.  These should not be
>> addressed by HEART in terms of having our patient, Alice, provide varying
>> permissions at that level.
>>
>> The reasons for limiting the resources to a list like this is because
>> they are already implemented and tested for many servers and because they
>> are a great first step.  If we can do this in HEART for starters we will
>> have achieved a lot!
>>
>> 4.       Terminology:  This group often uses different terminology which
>> causes confusion.  Eve has suggested several times that we focus on
>> clarifying terminology and has begun that effort in her use case document.
>> One term that has bothered me in the past is the term ?Resource Set?.  At
>> the HL7 conference, Josh clarified this for me.  My current understanding
>> is that UMA uses ?Resource Set? for the same purpose as FHIR uses ?Resource
>> Type?, or as is often shortened in FHIR as ?Resource?.  So in FHIR, if we
>> request medications for the patient Alice, we refer to the resource
>> ?Medications?, while UMA refers to this as a ?Resource Set? for the patient
>> Alice.  (The result would be a list of medications for Alice.)  If this
>> understanding is currently incorrect, can someone please correct it?
>>
>> 5.       Grouping of resources:  Let?s assume that we have agreed on the
>> list of FHIR resources.  I propose that we allow Alice to select which of
>> the list she desires to share, with the addition of choices ?all? or
>> ?none?.  The requests for the resources by the client would still be made
>> individually for each resource.  (To me the notion of ?resource set?
>> implied that we would define a set of individual resources ? say by some
>> category.  I would advise against using such a notion as it only
>> complicates and does not add any benefits.)
>>
>> 6.       Scopes
>>
>> a.       Read/Write
>>
>>                                                          i.            In
>> last week?s meeting, Justin referenced the current scope stream:
>> individual, bulk, read, write.  Since we are specifying HEART, I would
>> assume this is always what the patient is specifying.  So for HEART, the
>> scope of ?bulk? is not relevant.  Further we have scopes of Read, Write, or
>> *.  I suggest that we allow Alice to specify Read, Write, and have the
>> ability to specify both.  These settings can be set either per resource or
>> for all resources.
>>
>> Two points should be noted:
>>
>>                                                        ii.
>> Current implementations are supporting ?Read? and do not yet support
>> ?Write?.  We may be fine with starting with just ?Read? for version 1.0.
>>
>>                                                      iii.
>> Since Alice is defining what she is willing to share ? wouldn?t that be the
>> ?Read? case?  I can imagine that we will see implementations where Alice
>> controls her RS and in that case could specify ?Write? permissions.  For
>> the immediate future, I would be surprised if the EMR would allow Alice to
>> give permissions to Dr. Bob to write to an EMR.  There may be a case where
>> Alice can give Dr. Bob permission to write to her PHR.
>>
>> b.       Dates
>>
>>                                                                i.      My
>> understanding from yesterday?s conversation was that we do not want to
>> include dates in the scopes on resources, per HEART.  There are date
>> filters available for some resources, but that is within the FHIR query
>> specification, an outside of the HEART spec.
>>
>>                                                              ii.      Eve
>> raised the objective of having expiration dates associated with the
>> permissions granted, but that functionality does not apply to resource date
>> scopes
>>
>>                                                            iii.      So
>> ?dates? are not considered as a scope per this discussion.
>>
>> c.       Confidentiality codes:  I was the culprit that initially raised
>> the case of Alice not wanting to share her HIV condition, but only sharing
>> her non-HIV condition.  I believe most of us would like to provide such a
>> feature in HEART, but since that original discussion I am now of the
>> opinion that we should NOT include this feature in version 1.0.
>>
>>                                                          i.
>> Confidentiality codes were suggested as a potential solution to this
>> issue.  It has been stated that some additional ?magic? needs to occur to
>> make this viable.  Since it is not currently supported in current FHIR
>> implementation, adding this to HEART in version 1.0 could derail the effort.
>>
>>                                                        ii.
>> Confidentiality codes are defined in FHIR as tags.
>>
>>                                                      iii.
>> Confidentiality codes are not implemented in most of the current servers.
>> Even if they were, there is not a consistent method to consistently code
>> values across servers. This could lead to inconsistent results and be worse
>> that not providing the feature at all.
>>
>>                                                      iv.            If
>> Alice desired to not share her ?HIV? condition, we would need to add a
>> scope to the resource request asking the server to withhold data that
>> matches the requested confidentiality settings.  This scope is not
>> currently defined in FHIR and we should not be attempting to change FHIR as
>> part of our HEART 1.0 specification.
>>
>>                                                        v.            If I
>> were running a RS, I certainly would not be willing to send Alice?s HIV
>> condition to the client tagged as confidential and expect the client to not
>> share it ? instead I would want to not send the data at all ? thus the
>> requirement to add a new scope ? which we should definitely avoid.
>>
>> This document is also added as an attachment.
>>
>> -Nancy
>>
>>
>>
>>
>> Nancy Lush
>>
>> nancy.lush at lgisoftware.com<mailto:nancy.lush at lgisoftware.com>
>>
>> Lush Group, Inc
>>
>> Office: (401) 423-9111<tel:%28401%29%20423-9111>
>>
>> 28 Narragansett Ave
>> PO Box 651
>>
>> www.lgisoftware.com<http://www.lgisoftware.com>
>> Cell:(401) 965-9347<tel:%28401%29%20965-9347>
>>
>> Jamestown, RI 02835
>>
>>
>>
>>
>> [LGI_logo_small]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net<mailto:Openid-specs-
>> heart at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>>
>> --
>> Danny van Leeuwen
>> 617-304-4681
>>
>> Blog www.health-hats.com<http://www.health-hats.com/> discovering the
>> magic levers of best health Twitter<https://twitter.com/HealthHats>
>> LinkedIn<https://www.linkedin.com/in/healthhatsdannyvl>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.openid.net/pipermail/openid-specs-heart/attach
>> ments/20160818/f537d61f/attachment.html>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: image001.gif
>> Type: image/gif
>> Size: 3006 bytes
>> Desc: image001.gif
>> URL: <http://lists.openid.net/pipermail/openid-specs-heart/attach
>> ments/20160818/f537d61f/attachment.gif>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>> ------------------------------
>>
>> End of Openid-specs-heart Digest, Vol 86, Issue 11
>> **************************************************
>> _______________________________________________
>> 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

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160820/63cdb8e4/attachment.html>


More information about the Openid-specs-heart mailing list