[Openid-specs-heart] Draft HEART Meeting Notes 2016-11-28

Tue Nov 29 14:06:20 UTC 2016

Here are some suggested answers (some partial), in green:

Q1 - do we need to profile standard friendly names for resources?
No.  This is a “may” pre-condition, i.e., that the UX may map friendly names to underlying data element names.  The use of the underlying data element names, e.g., those within FHIR resources, are mandated by standards outside the scope of HEART.

We should, though, note that mappings must provide appropriate values for data that are not exposed via the UX, e.g., code-system references for medications and problems.  This may include natural language processing to make good guesses, e.g., translating patient friendly terms for conditions to SNOMED or ICD10, converting LOINC to user-friendly terms, interpreting lab results to low-normal-high ranges, indicating authoritative vs. anecdotal data.

Q2 - [NSL] Do we want to profile a notification protocol to notify Dr. Erica?
No.  Provide a URI, which states the notification protocol, e.g., mailto:gfm at securityrs.com.  The detail for using the protocol is specified in standards outside of HEART’s scope.

Q3 - do we need to profile patient metadata obfuscation methods?
No.  There are existing guidelines for this.  See https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Handbook_De-Identification_Rev1.1_2014-06-06.pdf, also ISO/TS 25237:2008<http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=42807&commid=54960> standard. Do not re-invent this wheel.

Q4 - are there any ways to verify claims other than A, B, C? (A=AS verified, B=RS verified, C=federation verified)
Yes.  Reference standards-based work done by the HL7 Security Workgroup and others.  Creating another coding system value-set is not helpful and does not cover the semantic spectrum.  I think the details are outside HEART’s scope.

Q5 - [NSL] Can we elevate permissions through claims?
Maybe, but there are preconditions that need to be specified.  I think the details are outside HEART’s scope.

Q6 - do we need to profile the semantics for claims?
No.  Reference standards-based work done by the HL7 Security Workgroup and others.  I think the details are outside HEART’s scope.

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-bounces at lists.openid.net] On Behalf Of Nancy Lush
Sent: Monday, November 28, 2016 18:32
To: 'Adrian Gropper' <agropper at healthurl.com>; 'HEART List' <openid-specs-heart at lists.openid.net>; 'Sarah Squire' <sarah at engageidentity.com>
Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2016-11-28

Adrian, I added inline.
-Nancy

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
Sent: Monday, November 28, 2016 5:14 PM
To: HEART List <openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>>; Sarah Squire <sarah at engageidentity.com<mailto:sarah at engageidentity.com>>
Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2016-11-28

I wasn't taking notes but I found the structiring of the work in terms of Q1-6 very helpful.

Q1 - do we need to profile standard friendly names for resources?
Q2 - [NSL] Do we want to profile a notification protocol to notify Dr. Erica?
Q3 - do we need to profile patient metadata obfuscation methods?
Q4 - are there any ways to verify claims other than A, B, C? (A=AS verified, B=RS verified, C=federation verified)
Q5 - [NSL] Can we elevate permissions through claims?
Q6 - do we need to profile the semantics for claims?

Can anyone remember Q2 and Q5?

Adrian

On Mon, Nov 28, 2016 at 5:00 PM Sarah Squire <sarah at engageidentity.com<mailto:sarah at engageidentity.com>> wrote:

Light notes this week since we mostly walked through the use case that Eve and Nancy have been working on which will be sent out to the list shortly.

Attending:

Debbie Bucci

Adrian Gropper

Celestin Bitjonck

Edmund Jay

Eve Maler

Glen Marshall

Jim Kragh

Jin Wen

Luis Maas

Nancy Lush

Sarah Squire

Scott Shorter

Thomas Sullivan

Walter Kirk

Eve:

We’ve been winnowing down the resources we think people should focus on. We want to help people think with the lens of UMA. We might want to profile what normal people would say in natural English. So “medicines I take” might be friendlier than “current medications”

Adrian:

So we’re saying that our goal is that two RSs would describe the same words to describe a resource?

Eve:

We should decide whether or not to standardize that.

Glen:

Well, this might not be as straightforward as you might think to map these to FHIR resources.

Adrian:

Is it allowed for a server to list the FHIR resource itself? Rather than the friendly name?

Eve:

So we need to decide whether we want friendly names at all, and then whether we want to suggest or require them. We have a use case for proactive Alice sharing including notifications.

Nancy:

Is it okay to notify the client what Alice’s patient ID is? If the FHIR interface knows it and sends it over the wire, then the client should be able to know it and send it over the wire.

Adrian:

Why do we need a patient ID?

Eve:

All we really need is the resource endpoint, we don’t need Alice’s patient ID. You can notify Dr. Erica with knowledge of that endpoint. We probably want the client to pass all the trust elevation tests before it can see the URL with a patient ID in it. We don’t want a patient id in the clear.

Nancy:

We really tried to make this as simple as possible.

Eve:

We’re trying to replicate what Google has already done with document sharing in a loosely coupled protocol.

Sarah Squire
Engage Identity
http://engageidentity.com<http://engageidentity.com/>
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161129/ee820728/attachment.html>