Evidence of that cross communication can be found in the fact that HEART is starting with the Argonauts scope structure. Remember, this information needs to flow both ways, and it is. Smart is currently considering supporting HEART style client authenticating, for instance.
It doesn't mean that both of us will end where we've started, but it does mean that w e are not working in a vacuum on either side.
-- Justin
/ Sent from my phone /
-------- Original message --------
From: Debbie Bucci <debbucci at gmail.com>
Date: 10/6/2015 11:08 PM (GMT+01:00)
To: "Glen Marshall [SRS]" <gfm at securityrs.com>
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes
John Moerke
Josh Mandel
Bill Kinsley
All actively participate with HL7 and offered their time here at HEART and it's greatly appreciated. Certain I have missed others. A quick glance at the Listserv show others are quietly following along.
I have been trying to join the security and cbcc workgroups when I can.
There is cross communication occuring already if you look close enough.
On Oct 6, 2015 2:16 PM, "Glen Marshall [SRS]" <gfm at securityrs.com> wrote:
Who on this listserve is active in HL7? I used to be, but am not
now. But I am fairly certain that if we want to be influential on
HL7 and Argonaut's work, HEART must initiate and become actively
engaged with HL7.
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
On 10/6/15 11:26, Kinsley, William
wrote:
I
am more concerned with what I interpret as Argonaut’s hard
coding specific security roles and that they are not
representative of the OAuth and UMA approach. This is
serving as a wake call to us (the HEART WG) that without any
guidance from us, they are going to create a de facto
security/privacy standard that will be difficult to unwind
once it is adopted by other projects in the industry.
Bill
From:
agropper at gmail.com [mailto:agropper at gmail.com]
On Behalf Of Adrian Gropper
Sent: Tuesday, October 06, 2015 11:19 AM
To: Kinsley, William <BKinsley at nextgen.com>
Cc: Justin Richer <jricher at mit.edu>;
openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Health Relationship
Trust Profile for Fast Healthcare Interoperability Resources
(FHIR) OAuth 2.0 Scopes
To begin the discussion, I would suggest
three terms with healthcare / generic names:
Patient / Subject
The Subject of the resource when the resource refers to
only one person. The Subject is also the Principal when
they register their resource with the Authorization
Server.
Custodian / Principal
The person that registers a resource with an
Authorization Server. This is typically the Resource
Owner (RO).
When a Custodian is in control of multiple Subjects,
they are able to identify (name) the separate Subjects
any way they choose.
A Custodian can access resources for multiple Subjects
in a single transaction including, for example, a
Patient List.
User
Anyone or anything that is not a Subject or a Custodian.
A User can access resources for multiple Subjects in a
single transaction including, for example, a Patient
List.
I hope we can map this to FHIR:
Pseudonymous Subject Resource
A resource for a single Subject identified by an opaque
pseudonym as registered with the Authorization Server.
The resource may contain Subject identity information or
not.
When the resource does not contain Subject identity
information, the Authorization Server is responsible for
associating the pseudonyms with an identity.
Multi-Subject Resource
A resource for multiple Subjects registered with the
Authorization Server by a Custodian or a User.
Identified Subject Resource
A resource for a single Subject that includes Subject
identifying information in the resource URI as
registered with the Authorization Server.
An identified subject resource must be protected as
personally identified information (PII).
Adrian
On Tue, Oct 6, 2015 at 10:05 AM,
Kinsley, William <BKinsley at nextgen.com>
wrote:
This
is very informative detail of what the Argonaut
project is doing and I don’t want to deter the
information sharing process. I also think this is
a reminder that these groups are proceeding
without our guidance and that we need to discuss
what is our timeline to produce some type of
guidance to help them implement a process that is
aligned with the finial product the HEART
workgroup delivers.
Bill
From:
Justin Richer [mailto:jricher at mit.edu]
Sent: Tuesday, October 06, 2015 8:12 AM
To: Kinsley, William <BKinsley at nextgen.com>
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart]
Health Relationship Trust Profile for Fast
Healthcare Interoperability Resources (FHIR)
OAuth 2.0 Scopes
To
clarify the objective, we were presenting the first
draft of one of the outputs of this working group.
The
HEART working group exists specifically to create
these technical specifications. All of the
discussions on use cases are intended to drive
work on these specifications.
Also,
the group should note that the terms “patient” and
“user” were imported directly from the Argonauts
projects.
—
Justin
On
Oct 5, 2015, at 11:31 PM, Kinsley, William
<BKinsley at nextgen.com>
wrote:
This
document was presented quickly during
the last few minutes of our call and I
am not sure what the objective was.
However, it did raise some questions
that could not be addressed at the
time, specifically paragraph 2.1
“Permission type” raised some
questions which I broke out below:
1.
The
term “Patient” and “User” seem
misleading and the purpose is not clear.
a.
A
patient can have access to multiple
patient records. For example, a parent
who has five children at the same
pediatrician would be a patient that can
access multiple patient records.
b.
It
also sounds like we are hardcoding two
specific security roles, which would
seem to contradict what we are trying to
support in HEART (i.e. RBAC vs ABAC).
c.
There
can be resource that are not related to
specific patient or patients in general
such as “Organization”,
“HealthcareService”, “Practitioner”,
etc.
Bill
________________________________
William
Kinsley , CISSP
Enterprise Architect, Ambulatory
NEXTGEN HEALTHCARE
Solutions for: Ambulatory,
Inpatient and Community
Connectivity
795 Horsham Road, Horsham, PA
19044
(215) 657-7010
x21128
BKinsley at nextgen.com
Be
ready for MU and ICD-10 in 2015.
Start your EHR version 5.8 and
KBM version 8.3 upgrade today.
Get the resources you need at
www.nextgen.com/upgradecentral
This
message, and any documents
attached hereto, may contain
confidential or proprietary
information intended only for
the use of the addressee(s)
named above or may contain
information that is legally
privileged. If you are not the
intended addressee, or the
person responsible for
delivering it to the intended
addressee, you are hereby
notified that reading,
disseminating, distributing or
copying this message is strictly
prohibited. If you have received
this message by mistake, please
immediately notify us by
replying to the message and
delete the original message and
any copies immediately
thereafter. Thank you for your
cooperation.
_______________________________________________
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/
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151006/5b5513ff/attachment-0001.html>