<div dir="ltr"><div>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.<br><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 20, 2016 at 8:43 AM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div><br></div></blockquote><div class="gmail_quote"> </div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 19, 2016 at 4:44 PM, Catherine Schulten <span dir="ltr"><<a href="mailto:catherine.schulten@lifemedid.com" target="_blank">catherine.schulten@lifemedid.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
First names are also mildly dynamic with the use of nicknames and legal names.<br>
<br>
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.<br>
<br>
Catherine S.<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bou<wbr>nces@lists.openid.net</a>] On Behalf Of <a href="mailto:openid-specs-heart-request@lists.openid.net" target="_blank">openid-specs-heart-request@lis<wbr>ts.openid.net</a><br>
Sent: Thursday, August 18, 2016 12:23 PM<br>
To: <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openi<wbr>d.net</a><br>
Subject: Openid-specs-heart Digest, Vol 86, Issue 11<br>
<br>
Send Openid-specs-heart mailing list submissions to<br>
<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openi<wbr>d.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openid-specs-heart-request@lists.openid.net" target="_blank">openid-specs-heart-request@lis<wbr>ts.openid.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openid-specs-heart-owner@lists.openid.net" target="_blank">openid-specs-heart-owner@lists<wbr>.openid.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific than "Re: Contents of Openid-specs-heart digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Resource/Scope Proposal #2 (Danny van Leeuwen)<br>
2. Re: Resource/Scope Proposal #2 (Glen Marshall [SRS])<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Thu, 18 Aug 2016 11:11:18 -0400<br>
From: Danny van Leeuwen <<a href="mailto:danny@health-hats.com" target="_blank">danny@health-hats.com</a>><br>
Cc: HEART List <<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.open<wbr>id.net</a>><br>
Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2<br>
Message-ID:<br>
<<a href="mailto:CAP5tyWv9h1a3kDGvozNRgbN0yPY21sP58_H_ZgerrEbev7ZzMQ@mail.gmail.com" target="_blank">CAP5tyWv9h1a3kDGvozNRgbN0yPY2<wbr>1sP58_H_ZgerrEbev7ZzMQ@mail.gm<wbr>ail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
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.<br>
Medications and plan are quite fluid. What are the implications of this<br>
static->fluid continuum in this whole discussion?<br>
<br>
On Tue, Aug 16, 2016 at 5:15 PM, Nancy Lush <<a href="mailto:nlush@lgisoftware.com" target="_blank">nlush@lgisoftware.com</a>> wrote:<br>
<br>
> HEART proposal Example 2<br>
><br>
> (I apologize in advance for such a long email. Also, sorry for the<br>
> delay as I was away on vacation and catching up.)<br>
><br>
><br>
><br>
> Justin proposed that team members propose suggested resources, scopes<br>
> and what they mean. The objective is to suggest positive solutions.<br>
> None will be totally ?correct? but that is OK because together these<br>
> suggestions can be combined and adjusted to reach the ?correct?<br>
> solution. Based on that, I will create another stab as an alternative.<br>
><br>
> 1. First, since HEART is based on FHIR, we should not expect any<br>
> changes in FHIR, at least for the 1.0 version. The resources should<br>
> be the FHIR resources. I am stating this as a discrete point. I<br>
> think we all agree, but I would like to know that we do indeed concur.<br>
><br>
> 2. In an attempt to simplify, my original list of resources was the<br>
> list of FHIR resources that are implemented by the Argonaut group.<br>
> Since this is the set that most of the current servers have<br>
> implemented, we could expect them to be supported first. (I have no<br>
> objection to the list being the complete list of FHIR resources, if<br>
> that is preferred by the group.) This subset list also happens to<br>
> correspond to the Common Clinical Data set. (I am suggesting that we<br>
> start with this limited set in the assumption that we could implement<br>
> HEART as soon as it is specified.)<br>
><br>
> ? Patient demographics (Known as ?patient? per FHIR)<br>
><br>
> ? Allergies<br>
><br>
> ? Problems & Health concerns (Conditions)<br>
><br>
> ? Vital Signs (Category of Observations)<br>
><br>
> ? Labs<br>
><br>
> ? Smoking Status<br>
><br>
> ? Care Team (Some vendors have Care Plan of which Care Team is a<br>
> subset.)<br>
><br>
> ? Medications<br>
><br>
> ? Immunizations<br>
><br>
> ? Goals<br>
> ---- this next subset of resources could expand on the above list and<br>
> are a continuation of the Argonaut implementation list.<br>
><br>
> ? UDI (Device)<br>
><br>
> ? Procedures<br>
><br>
> ? Plan of Treatment<br>
><br>
> ? Assessment<br>
><br>
> 3. The chart below is simply to demonstrate to those less familiar<br>
> with FHIR how this might work. All of these results are per patient.<br>
><br>
> Common Name<br>
><br>
> FHIR Resource<br>
><br>
> Category if applies<br>
><br>
> Other filter<br>
><br>
><br>
><br>
> Patient demographics<br>
><br>
> Patient<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Allergies<br>
><br>
> AllergyIntolerance<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Problems and Health Concerns<br>
><br>
> Condition<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Vital Signs<br>
><br>
> Observation<br>
><br>
> Vital-signs<br>
><br>
><br>
><br>
><br>
><br>
> Lab Results<br>
><br>
> DiagnosticReport<br>
><br>
> Lab<br>
><br>
><br>
><br>
><br>
><br>
> Smoking Status<br>
><br>
> Observation<br>
><br>
><br>
><br>
> Code=72166-2<br>
><br>
><br>
><br>
> Care Team<br>
><br>
> CarePlan<br>
><br>
> CareTeam<br>
><br>
><br>
><br>
><br>
><br>
> Medications<br>
><br>
> MedicationStatement<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Medications<br>
><br>
> MedicationOrder<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Immunizations<br>
><br>
> Immunization<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Goals<br>
><br>
> Goal<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> UDI<br>
><br>
> Device<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Procedures<br>
><br>
> Procedure<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Plan of Treatment<br>
><br>
> (Still being defined in re-sprint)<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Assessment<br>
><br>
> (Still being defined in re-sprint)<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> There are different filters for each resource type. These should not<br>
> be addressed by HEART in terms of having our patient, Alice, provide<br>
> varying permissions at that level.<br>
><br>
> The reasons for limiting the resources to a list like this is because<br>
> they are already implemented and tested for many servers and because<br>
> they are a great first step. If we can do this in HEART for starters<br>
> we will have achieved a lot!<br>
><br>
> 4. Terminology: This group often uses different terminology which<br>
> causes confusion. Eve has suggested several times that we focus on<br>
> clarifying terminology and has begun that effort in her use case document.<br>
> One term that has bothered me in the past is the term ?Resource Set?.<br>
> At the HL7 conference, Josh clarified this for me. My current<br>
> understanding is that UMA uses ?Resource Set? for the same purpose as<br>
> FHIR uses ?Resource Type?, or as is often shortened in FHIR as<br>
> ?Resource?. So in FHIR, if we request medications for the patient<br>
> Alice, we refer to the resource ?Medications?, while UMA refers to<br>
> this as a ?Resource Set? for the patient Alice. (The result would be<br>
> a list of medications for Alice.) If this understanding is currently incorrect, can someone please correct it?<br>
><br>
> 5. Grouping of resources: Let?s assume that we have agreed on the<br>
> list of FHIR resources. I propose that we allow Alice to select which<br>
> of the list she desires to share, with the addition of choices ?all?<br>
> or ?none?. The requests for the resources by the client would still<br>
> be made individually for each resource. (To me the notion of ?resource set?<br>
> implied that we would define a set of individual resources ? say by<br>
> some category. I would advise against using such a notion as it only<br>
> complicates and does not add any benefits.)<br>
><br>
> 6. Scopes<br>
><br>
> a. Read/Write<br>
><br>
> i. In<br>
> last week?s meeting, Justin referenced the current scope stream:<br>
> individual, bulk, read, write. Since we are specifying HEART, I would<br>
> assume this is always what the patient is specifying. So for HEART,<br>
> the scope of ?bulk? is not relevant. Further we have scopes of Read,<br>
> Write, or *. I suggest that we allow Alice to specify Read, Write,<br>
> and have the ability to specify both. These settings can be set<br>
> either per resource or for all resources.<br>
><br>
> Two points should be noted:<br>
><br>
> ii. Current<br>
> implementations are supporting ?Read? and do not yet support ?Write?.<br>
> We may be fine with starting with just ?Read? for version 1.0.<br>
><br>
> iii. Since<br>
> Alice is defining what she is willing to share ? wouldn?t that be the<br>
> ?Read? case? I can imagine that we will see implementations where<br>
> Alice controls her RS and in that case could specify ?Write?<br>
> permissions. For the immediate future, I would be surprised if the<br>
> EMR would allow Alice to give permissions to Dr. Bob to write to an<br>
> EMR. There may be a case where Alice can give Dr. Bob permission to write to her PHR.<br>
><br>
> b. Dates<br>
><br>
> i. My<br>
> understanding from yesterday?s conversation was that we do not want to<br>
> include dates in the scopes on resources, per HEART. There are date<br>
> filters available for some resources, but that is within the FHIR<br>
> query specification, an outside of the HEART spec.<br>
><br>
> ii. Eve<br>
> raised the objective of having expiration dates associated with the<br>
> permissions granted, but that functionality does not apply to resource<br>
> date scopes<br>
><br>
> iii. So<br>
> ?dates? are not considered as a scope per this discussion.<br>
><br>
> c. Confidentiality codes: I was the culprit that initially raised<br>
> the case of Alice not wanting to share her HIV condition, but only<br>
> sharing her non-HIV condition. I believe most of us would like to<br>
> provide such a feature in HEART, but since that original discussion I<br>
> am now of the opinion that we should NOT include this feature in version 1.0.<br>
><br>
> i. Confidentiality<br>
> codes were suggested as a potential solution to this issue. It has<br>
> been stated that some additional ?magic? needs to occur to make this viable.<br>
> Since it is not currently supported in current FHIR implementation,<br>
> adding this to HEART in version 1.0 could derail the effort.<br>
><br>
> ii. Confidentiality<br>
> codes are defined in FHIR as tags.<br>
><br>
> iii. Confidentiality<br>
> codes are not implemented in most of the current servers. Even if<br>
> they were, there is not a consistent method to consistently code<br>
> values across servers. This could lead to inconsistent results and be<br>
> worse that not providing the feature at all.<br>
><br>
> iv. If<br>
> Alice desired to not share her ?HIV? condition, we would need to add a<br>
> scope to the resource request asking the server to withhold data that<br>
> matches the requested confidentiality settings. This scope is not<br>
> currently defined in FHIR and we should not be attempting to change<br>
> FHIR as part of our HEART 1.0 specification.<br>
><br>
> v. If I<br>
> were running a RS, I certainly would not be willing to send Alice?s<br>
> HIV condition to the client tagged as confidential and expect the<br>
> client to not share it ? instead I would want to not send the data at<br>
> all ? thus the requirement to add a new scope ? which we should definitely avoid.<br>
><br>
><br>
><br>
> This document is also added as an attachment.<br>
><br>
><br>
><br>
> -Nancy<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> *Nancy Lush *<br>
><br>
> <a href="mailto:nancy.lush@lgisoftware.com" target="_blank">nancy.lush@lgisoftware.com</a><br>
><br>
> *Lush Group, Inc*<br>
><br>
> Office: <a href="tel:%28401%29%20423-9111" value="+14014239111" target="_blank">(401) 423-9111</a><br>
><br>
> 28 Narragansett Ave<br>
><br>
> PO Box 651<br>
><br>
> <a href="http://www.lgisoftware.com" rel="noreferrer" target="_blank">www.lgisoftware.com</a><br>
><br>
> Cell:<a href="tel:%28401%29%20965-9347" value="+14019659347" target="_blank">(401) 965-9347</a><br>
><br>
> Jamestown, RI 02835<br>
><br>
><br>
><br>
> [image: LGI_logo_small]<br>
><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Openid-specs-heart mailing list<br>
> <a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
><br>
><br>
<br>
<br>
--<br>
Danny van Leeuwen<br>
<a href="tel:617-304-4681" value="+16173044681" target="_blank">617-304-4681</a><br>
<br>
*Blog <a href="http://www.health-hats.com" rel="noreferrer" target="_blank">www.health-hats.com</a> <<a href="http://www.health-hats.com/" rel="noreferrer" target="_blank">http://www.health-hats.com/</a>> discovering the magic levers of best health* Twitter <<a href="https://twitter.com/HealthHats" rel="noreferrer" target="_blank">https://twitter.com/HealthHat<wbr>s</a>> LinkedIn <<a href="https://www.linkedin.com/in/healthhatsdannyvl" rel="noreferrer" target="_blank">https://www.linkedin.com/in/h<wbr>ealthhatsdannyvl</a>><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160818/c294b546/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openid.net/piper<wbr>mail/openid-specs-heart/attach<wbr>ments/20160818/c294b546/attach<wbr>ment-0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: image001.gif<br>
Type: image/gif<br>
Size: 3006 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160818/c294b546/attachment-0001.gif" rel="noreferrer" target="_blank">http://lists.openid.net/piper<wbr>mail/openid-specs-heart/attach<wbr>ments/20160818/c294b546/attach<wbr>ment-0001.gif</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 18 Aug 2016 15:49:23 +0000<br>
From: "Glen Marshall [SRS]" <<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>><br>
To: Danny van Leeuwen <<a href="mailto:danny@health-hats.com" target="_blank">danny@health-hats.com</a>><br>
Cc: HEART List <<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.open<wbr>id.net</a>><br>
Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2<br>
Message-ID:<br>
<<a href="mailto:DM5PR05MB32441E897A8521CB19CBB7C3CE150@DM5PR05MB3244.namprd05.prod.outlook.com" target="_blank">DM5PR05MB32441E897A8521CB19CB<wbr>B7C3CE150@DM5PR05MB3244.namprd<wbr>05.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I depends on the use cases.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Glen F. Marshall<br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: <a href="tel:%28610%29%20644-2452" value="+16106442452" target="_blank">(610) 644-2452</a><br>
Mobile: <a href="tel:%28610%29%20613-3084" value="+16106133084" target="_blank">(610) 613-3084</a><br>
<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br>
<a href="http://www.SecurityRiskSolutions.com" rel="noreferrer" target="_blank">www.SecurityRiskSolutions.com</a><<a href="http://www.securityrisksolutions.com/" rel="noreferrer" target="_blank"><wbr>http://www.securityrisksolutio<wbr>ns.com/</a>><br>
<br>
From: Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bou<wbr>nces@lists.openid.net</a>] On Behalf Of Danny van Leeuwen<br>
Sent: Thursday, August 18, 2016 11:11<br>
Cc: HEART List <<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.open<wbr>id.net</a>><br>
Subject: Re: [Openid-specs-heart] Resource/Scope Proposal #2<br>
<br>
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?<br>
<br>
On Tue, Aug 16, 2016 at 5:15 PM, Nancy Lush <<a href="mailto:nlush@lgisoftware.com" target="_blank">nlush@lgisoftware.com</a><mailto:<a href="mailto:nlush@lgisoftware.com" target="_blank"><wbr>nlush@lgisoftware.com</a>>> wrote:<br>
HEART proposal Example 2<br>
(I apologize in advance for such a long email. Also, sorry for the delay as I was away on vacation and catching up.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
? Patient demographics (Known as ?patient? per FHIR)<br>
<br>
? Allergies<br>
<br>
? Problems & Health concerns (Conditions)<br>
<br>
? Vital Signs (Category of Observations)<br>
<br>
? Labs<br>
<br>
? Smoking Status<br>
<br>
? Care Team (Some vendors have Care Plan of which Care Team is a subset.)<br>
<br>
? Medications<br>
<br>
? Immunizations<br>
<br>
? Goals<br>
---- this next subset of resources could expand on the above list and are a continuation of the Argonaut implementation list.<br>
<br>
? UDI (Device)<br>
<br>
? Procedures<br>
<br>
? Plan of Treatment<br>
<br>
? Assessment<br>
<br>
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.<br>
Common Name<br>
<br>
FHIR Resource<br>
<br>
Category if applies<br>
<br>
Other filter<br>
<br>
<br>
<br>
Patient demographics<br>
<br>
Patient<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Allergies<br>
<br>
AllergyIntolerance<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Problems and Health Concerns<br>
<br>
Condition<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Vital Signs<br>
<br>
Observation<br>
<br>
Vital-signs<br>
<br>
<br>
<br>
<br>
<br>
Lab Results<br>
<br>
DiagnosticReport<br>
<br>
Lab<br>
<br>
<br>
<br>
<br>
<br>
Smoking Status<br>
<br>
Observation<br>
<br>
<br>
<br>
Code=72166-2<br>
<br>
<br>
<br>
Care Team<br>
<br>
CarePlan<br>
<br>
CareTeam<br>
<br>
<br>
<br>
<br>
<br>
Medications<br>
<br>
MedicationStatement<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Medications<br>
<br>
MedicationOrder<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Immunizations<br>
<br>
Immunization<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Goals<br>
<br>
Goal<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
UDI<br>
<br>
Device<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Procedures<br>
<br>
Procedure<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Plan of Treatment<br>
<br>
(Still being defined in re-sprint)<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Assessment<br>
<br>
(Still being defined in re-sprint)<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
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.<br>
<br>
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!<br>
<br>
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?<br>
<br>
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.)<br>
<br>
6. Scopes<br>
<br>
a. Read/Write<br>
<br>
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.<br>
<br>
Two points should be noted:<br>
<br>
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.<br>
<br>
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.<br>
<br>
b. Dates<br>
<br>
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.<br>
<br>
ii. Eve raised the objective of having expiration dates associated with the permissions granted, but that functionality does not apply to resource date scopes<br>
<br>
iii. So ?dates? are not considered as a scope per this discussion.<br>
<br>
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.<br>
<br>
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.<br>
<br>
ii. Confidentiality codes are defined in FHIR as tags.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
This document is also added as an attachment.<br>
<br>
-Nancy<br>
<br>
<br>
<br>
<br>
Nancy Lush<br>
<br>
<a href="mailto:nancy.lush@lgisoftware.com" target="_blank">nancy.lush@lgisoftware.com</a><mai<wbr>lto:<a href="mailto:nancy.lush@lgisoftware.com" target="_blank">nancy.lush@lgisoftware.com</a><wbr>><br>
<br>
Lush Group, Inc<br>
<br>
Office: <a href="tel:%28401%29%20423-9111" value="+14014239111" target="_blank">(401) 423-9111</a><tel:%28401%29%20423-<wbr>9111><br>
<br>
28 Narragansett Ave<br>
PO Box 651<br>
<br>
<a href="http://www.lgisoftware.com" rel="noreferrer" target="_blank">www.lgisoftware.com</a><<a href="http://www.lgisoftware.com" rel="noreferrer" target="_blank">http://www<wbr>.lgisoftware.com</a>><br>
Cell:<a href="tel:%28401%29%20965-9347" value="+14019659347" target="_blank">(401) 965-9347</a><tel:%28401%29%20965-9<wbr>347><br>
<br>
Jamestown, RI 02835<br>
<br>
<br>
<br>
<br>
[LGI_logo_small]<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><mailto:<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-<wbr>heart@lists.openid.net</a>><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
<br>
<br>
<br>
--<br>
Danny van Leeuwen<br>
<a href="tel:617-304-4681" value="+16173044681" target="_blank">617-304-4681</a><br>
<br>
Blog <a href="http://www.health-hats.com" rel="noreferrer" target="_blank">www.health-hats.com</a><<a href="http://www.health-hats.com/" rel="noreferrer" target="_blank">http://www<wbr>.health-hats.com/</a>> discovering the magic levers of best health Twitter<<a href="https://twitter.com/HealthHats" rel="noreferrer" target="_blank">https://twitter.com/He<wbr>althHats</a>><br>
LinkedIn<<a href="https://www.linkedin.com/in/healthhatsdannyvl" rel="noreferrer" target="_blank">https://www.linkedin.<wbr>com/in/healthhatsdannyvl</a>><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160818/f537d61f/attachment.html" rel="noreferrer" target="_blank">http://lists.openid.net/piper<wbr>mail/openid-specs-heart/attach<wbr>ments/20160818/f537d61f/attach<wbr>ment.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: image001.gif<br>
Type: image/gif<br>
Size: 3006 bytes<br>
Desc: image001.gif<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160818/f537d61f/attachment.gif" rel="noreferrer" target="_blank">http://lists.openid.net/piper<wbr>mail/openid-specs-heart/attach<wbr>ments/20160818/f537d61f/attach<wbr>ment.gif</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Openid-specs-heart Digest, Vol 86, Issue 11<br>
******************************<wbr>********************<br>
______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>