OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml-demo-tech] Groups - XACML/RSA 2008 InterOp ConferenceCall TOMORROW - REMINDER!


Hi John,

Thanks for the feedback. This is great information.

The GIF was just something I found that could provide context, and
as you say, it is pretty complicated for a demo.

I also agree we want to show RBAC + Patient-Consent-Directive
in action. With that in mind, a few quick questions, so we can all
get an idea of the objectives in a little more detail in terms of how
the demo could be set up:

 1. Do you think we need a separate screen for each role? Or is
    there possibly one entry screen, and depending on role different
    options are shown to go to a 2nd screen?

  2. You mention "documents". I assume these are like reports that
    are generated when tests are done (or bills) and a ref to the doc is
    put in the patient record. And if the user accessing the patient record
    has the necessary priv to access the doc, then the link to the
    doc would be shown and if the user clicked on it they would
    see the whole doc.

  3. If the above is correct, then I could see a main entry screen, where
    the user would enter a patient identifier, and then a screen would come
    back with a list of docs for that patient plus some other general fields
    like an area to enter an appt for the reg desk. ex. the reg clerk would
    only get to see patient basic contact info and possibly associated doctors
    that they generally see. The billing clerk would see patient contact info
    plus current bills (which would be docs that could be viewed).
    A dietician could see contact info plus any docs that are tagged as
    diet-related, presumably tagged as such by a doctor, also they could
    see their own docs which they could add with dietary recommendations.
    The doctor (or list of partner doctors who stand in) would have access
    to all medical records and tests. Possibly we could have a screen section
    for each category of doc and all the docs in each category would be
    shown, but a user would only see the section(s) to which they have access.

  4. Given the backdrop above, we could then add privacy constraints
    along the lines you were suggesting.

Let me know if the above is along the lines you are thinking. If not, please
continue to make suggestions and we can hopefully iteratively converge
to the most effective demo. At this point I think the demo user screens
are completely open to suggestion and we should try to do anything
reasonable to capture the main concepts we want to demonstrate.
   
    Thanks,
    Rich

Moehrke, John (GE Healthcare) wrote:

I am not sure the GIF you pointed at is actually the best type of user-interface to mock up. This type of an interface is used by a doctor in the direct treatment of a patient. In these use-cases it is usually all-or-nothing.

 

The places where RBAC jump in is use-cases like the difference between the doctor, the Registration desk, the Billing Clerk, and the dietician.  To show this, we can worry less about a very complex user-interface, and more on broad visibility.

 

The stretch goal is to go beyond RBAC and to show where a Patient-Consent-Directive is going to further constrain the use of the data. There are a huge number of these use-cases, I would suggest some of the more simple are policies:

- Patient authorizes direct providers, but those not assigned to their case should not have access.

- Patient authorizes normal care, except for Dr. Bob Busybody (who is his nosy neighbor)

- Patient authorizes normal care, and further authorizes use of their data by cancer researchers

- Patient authorizes normal care, but requires a confidential S/MIME email sent describing each access.

- Patient authorizes each document published differently, thus document specific XACML language needs to be parsed in real-time.

*Then there is always the additional conditional in healthcare authorizing emergency-access (or forbidding it).

For more: http://wiki.ihe.net/index.php?title=BPPC#Possible_Privacy_Policies

 

I suggest we figure out one or more patient-consent-directive policies that we could also show. This doesn’t need to be complex, but needs to be something that people will see as something not in the domain of RBAC.

 

John

 


From: Rich Levinson [mailto:rich.levinson@oracle.com]
Sent: Thursday, December 06, 2007 11:14 AM
To: Dee Schur
Cc: xacml@lists.oasis-open.org; Xacml-demo-tech@lists.oasis-open.org; Xacml-demo-mktg@lists.oasis-open.org; Andrew.Rappaport@ca.com; Anil.Saldhana@redhat.com; brynn.mow@jerichosystems.com; CHARLES.J.NORWOOD@saic.com; christine.w.chan@oracle.com; denis.pilipchuk@bea.com; dgarriso@bea.com; Dilli.Dorai@Sun.COM; dpilipch@bea.com; dspalding@securent.net; gopi.bhavaraju@oracle.com; hting@securent.net; michael.dufel@jerichosystems.com; Seth.Proctor@Sun.COM; susie@symlabs.com; wlu@bea.com; cyang@redhat.com; Herbert.Mehlhorn@ca.com; llevitan@us.ibm.com; wdettelb@bea.com; william.dettelback@bea.com; Moehrke, John (GE Healthcare); mike.davis@va.gov; jane.harnad@oasis-open.org
Subject: Re: [xacml-demo-tech] Groups - XACML/RSA 2008 InterOp Conference Call TOMORROW - REMINDER!

 

Hello prospective RSA Interop participants, esp callers of today's conf call,

Also attached are the 2 documents associated with the emails copied below.
I am also attaching a glossary I dug up thru one of the links ref'd in the
emails below, which I found useful while looking thru the Use Case Models.pdf
document. Finally, I also dug up this link, which gives an example of one
of these health care records that is discussed in the use cases doc:

   http://www.infoway-inforoute.ca/en/img/work/AnimatedEHRwithCallouts_DH3.gif

Presumably, if we follow the Burton Catalyst Interop approach, we would need
some kind of sample appl that everyone could use that showed something like the
above link. But, based on the scenario description in the 1 page doc, what we
really need is the appl/xacml-client to interpret the xacml return data, presumably
some Obligations with vocabulary indicating the privacy directives that the appl
must enforce wrt to what data can actually be shown to the caller, which may
also involve a lookup on whether patient has any consent directives that pertain.

Based on my reading, the Use Case Models.pdf doc is primarily a mgmt system for
the patient data, in particular, for the patient's decisions about how their data must
be handled by the health care provider (as opposed to actual personal or medical
info about the patient - i.e. the doc talks about scenarios for managing the patient
"metadata"). In any event, the point I am trying to make is that the scenarios we
are probably going to implement are NOT the ones in the Use Case Models.pdf
doc, but the ones in the one page description which is about actors accessing
data that is controlled by the types of privacy preferences and consent directives
that had been put in place by the Use Case Models.pdf application.

To dig myself even a little deeper on this, my inference is that the scenarios
in the Use Case Models.pdf doc actually "result in" a set of XACML Policys
being created. Our focus will be to create policies similar to what such an
appl might create, but not write such an appl ourselves in anyway, except
possibly if we want to do the Policy Exchange type use case to see if vendors
can create interoperable policies of this nature.

What the main focus of the Interop should probably be, imo, is that given
a set of XACML Policys that we create, we will then have clients access
the test appl, which will have a xacml-client, which will make a request
that activates the aforementioned policies, and recieves a result which
will tell the appl/xacml-client what can and cannot be done wrt to the request.

The key work that I see in doing the core part of the scenario is:

    1. defining the XACML Policys that will be used.
    2. defining how the XACML Policys return the directives the xacml-client must comply with

My assumption and hope is that we will build around the XACML Obligations,
groundwork of which was already laid in the Burton Interop by returning
"display" Obligations and "approval" Obligations and focus on defining a
vocabulary for these Obligations that will allow for clean appl/xacml-client
interoperability.

Comments and suggestions welcome. The above is primarily intended to get discussion
going on the details of what would seem to be the critical path to get some scenarios
operable with minimal investment of resources starting from where the previous
Interop left off.

    Thanks,
    Rich



Message 1 re: the 1 page Interop overview proposal:

-------- Original Message --------

Subject:

[xacml-demo-tech] RSA 2008

Date:

Thu, 8 Nov 2007 09:26:15 -0500

From:

Dee Schur <dee.schur@oasis-open.org>

Organization:

OASIS

To:

<xacml@lists.oasis-open.org>, <xacml-demo-mktg@lists.oasis-open.org>, <xacml-demo-tech@lists.oasis-open.org>




Please review this scenario before the call today, so sorry for the delay.

Regards,

Dee

 


From: Staggs, David (SAIC) [mailto:David.Staggs@va.gov]
Sent: Monday, November 05, 2007 5:30 PM
To: Dee Schur; Anthony Nadalin
Cc: Davis, John M.
Subject: RE: RSA 2008

 

Dee

 

Attached is a DRAFT of the 2008 RSA demonstration....

Regards

David

 

 


<dee said>

Hi,
I spoke with Sampo and Symlabs is also interested in the InterOp Demo at RSA if we extend the scenerio. So, now it seems we have:

Oracle
Sun
Axiomatics
Securent
IBM

Red Hat

Veterans Health Admin.

Symlabs



I am getting a lot of pushback from RSA, so I think our window of opportunity is closing unless we come up with a compelling scenario today or tomorrow! Please, if we want to move forward, I need something to work with ASAP.

Tony,
Could you pull together some of the ideas we discussed in Barcelona for the group?

Thanks so much!

Best,
Dee



Message 2: re the Use Case Models.pdf :

-------- Original Message --------

Subject:

[xacml] RSA 2008

Date:

Fri, 9 Nov 2007 12:02:11 -0500

From:

Dee Schur <dee.schur@oasis-open.org>

Organization:

OASIS

To:

<xacml@lists.oasis-open.org>, <xacml-demo-tech@lists.oasis-open.org>, <xacml-demo-mktg@lists.oasis-open.org>

CC:

<Dilli.Dorai@Sun.COM>, "'Staggs, David \(SAIC\)'" <David.Staggs@va.gov>, "'Anil Saldhana'" <Anil.Saldhana@redhat.com>, "'Prateek Mishra'" <prateek.mishra@oracle.com>, <Andrew.Rappaport@ca.com>, <erik@axiomatics.com>, "'Anthony Nadalin'" <drsecure@us.ibm.com>, "'Howard Ting'" <hting@securent.com>, <sampo@symlabs.com>, <susie@symlabs.com>

 

Hi,
We had a very invigorating and useful conversation yesterday regarding the
RSA XACML demo.
 
David Staggs was kind enough to put forth a scenario but other members felt
as if it was too aggressive and possibly unachievable. 
 
We have set a call for next Tuesday, 13 Nov at 10 AM EST. We need to get
this sorted out, so I firmly hope that ALL potential participants set this
as a priority call.
 
David just sent an additional overview to the list titled 'Use Case Models'
(which I have attached) - let me know if you need more information. 
***I have also included David's follow-up email related to this document and
our meeting at the end of this message for your review. 
 
Here is the call-in info:
 
Coordinator Name: deeschur
 Email: dee.schur@oasis-open.org
 
 Free Conference Call 
 Conference Dial-in Number: (605) 772-3100
 Host Access Code: 505991*
 Participant Access Code: 505991#
 
 
 International Dial-in Numbers 
 Austria: 0820 4000 1552
 Belgium: 070 35 9974
 France: 0826 100 256
 Germany: 01805 00 76 09
 Ireland: 0818 270 021
 Italy: 848 390 156
 Netherlands: 9004 353 535
 Spain: 902 886025
 Switzerland: 0848 560 179
 UK: 0870 35 204 74
 
Please let me know your status if you are unable to attend.
 
Regards,
Dee
 
 
 
-----Original Message-----
From: Staggs, David (SAIC) [mailto:David.Staggs@va.gov] 
Sent: Friday, November 09, 2007 11:51 AM
To: Prateek Mishra; Anthony Nadalin
Cc: Dee Schur; xacml@lists.oasis-open.org;
xacml-demo-mktg@lists.oasis-open.org; xacml-demo-tech@lists.oasis-open.org
Subject: RE: [xacml] Re: [xacml-demo-tech] RE: [xacml] RSA 2008
 
Dear Colleagues,
 
Sorry for the long e-mail; here is a summary:
1. Proposal for a "focus" call next Tuesday, 11/13/07 for the RSA demo.
2. Explanation of HITSP's interest in an XACML "privacy" scenario.
3. Summary of were we are at.
4. Link to the document "Using XACML for Privacy Control."
5. Sources for use case ideas.
 
1.
----------
As stated in the 11/08 minutes, I suggest a focus call next Tue Nov 13
at 10 AM EST.
 
2.
----------
Anil requested a summary of the role the Healthcare Information
Technology Standards Panel (HITSP) plays (specifically concerning the
RSA demonstration):
 
HITSP has no direct role in the demonstration.  HITSP SPTC has
identified OASIS XACML as a necessary standard to meet DHHS ONC AHIC
healthcare use cases requirements for secure authorization for security
and privacy. The RSA demonstration is consistent with the HITSP Access
Control construct. 
 
HITSP's goal is develop a Security and Privacy Access Control profile in
support of the American Health Information Community (AHIC) access
control use case in a standards-based manner for the U.S. Department of
Health and Human Services. Selection of standards will drive government
agencies, like the Department of Veterans Affairs, in IT. HITSP is
administered by the American National Standards Institute (ANSI).  A gap
in standards has been uncovered by HITSP addressing the security and
privacy requirements for enforcing privacy and access control policies
between multiple healthcare information systems.  So the VHA, as a
participant in HITSP, is very interested in the proposed RSA
demonstration as a step forward in establishing consensus on how a
Security and Privacy Access Control profile.
 
Additional information at: www.ansi.org/hitsp/
 
3.
----------
It may be helpful to discuss the current status of the RSA opportunity.
Neither HITSP nor the VHA has a particular approach selected.  The VHA
wants to stimulate discussion in this area to support the future
(obvious) need to address privacy and access control in the VHA's
mission to supply healthcare to US veterans and dependants.  We suggest
the TC focus just on the XACML piece of the puzzle for the RSA
demonstration - which is only a part of the larger HITSP construct. 
 
I have discussed the opportunity to address privacy using XACML at
several TC meetings and with several TC members, including the co-chair
(Hal).  I think using the previous demonstration would be helpful if it
allows us to focus the effort on the goal of administering patient
privacy electives using XACML. That would mean switching the text from
stockbrokers to clinicians but may save us from reinventing the
infrastructure. The immediate task is to identify one or two use cases
and settle on the preferred XACML approach.
 
Finally, the description circulated at the last TC meeting was written
as a quick "placeholder" to meet Dee's deadline for maintaining our
opportunity to participate in the upcoming RSA conference.  The text is
very general and I believe whatever the TC comes up will agree with the
general wording. 
 
4.
----------
Here is a link to the document discussed briefly at the last XACML TC
call entitled "Using XACML for Privacy Control:"
http://www.nm.ifi.lmu.de/pub/Publikationen/homm05a/PDF-Version/homm05a.p
df
 
The paper was found on the cover pages hosted by OASIS:
http://xml.coverpages.org/xacml.html
 
The paper may be a useful starting point, or it may not.
 
5.
----------
I feel this is a great time to construct a use case using XACML to
support privacy enforcement.  The question is "how can access to patient
information be secured per a patient's privacy elections" after it has
been received by another institution or department.  Since I believe the
immediate task is to identify one or two use cases, I will attach a
document discussing some scenarios for discussion.  
 
The document is the entire Use Case Model document that was produced as
part the work that was funded last year by Canada Health Infoway on
Consent Management (courtesy of Patrick Pyette).  The "Create Consent
Directive to Disclose PHI" and the two "Override Consent to Disclose"
Use Cases may be useful as a starting point.  They are all oriented to
the Canadian experience, but with a bit of work I think could be
reworked to be applicable to any scenario.  I realize some may have
strongly held opinions on these use cases, they are merely suggestions,
we can make up own use case based on the decision of the TC.
 
Sorry for cross-posts.
 
Thanks
David
 
David Staggs, JD, CISSP (SAIC)
Veterans Health Administration
Chief Health Informatics Office
Emerging Health Technologies
 



Rich Levinson wrote:

As discussed at today's conf call: ref to Burton Catalyst interop doc:

   http://www.oasis-open.org/committees/download.php/24475/xacml-2.0-core-interop-draft-12-04.doc

 Thanks,
 Rich

Dee Schur wrote:

I will not be on the call but Jane will be.
Thanks,
Dee

-----Original Message-----
From: dee.schur@oasis-open.org [mailto:dee.schur@oasis-open.org] Sent: Friday, November 30, 2007 9:18 AM
To: xacml@lists.oasis-open.org
Cc: Xacml-demo-tech@lists.oasis-open.org;
Xacml-demo-mktg@lists.oasis-open.org; Andrew.Rappaport@ca.com;
Anil.Saldhana@redhat.com; brynn.mow@jerichosystems.com;
CHARLES.J.NORWOOD@saic.com; christine.w.chan@oracle.com;
denis.pilipchuk@bea.com; 'dgarriso@bea.com; Dilli.Dorai@Sun.COM;
dpilipch@bea.com; dspalding@securent.net; gopi.bhavaraju@oracle.com;
hting@securent.net; michael.dufel@jerichosystems.com; Seth.Proctor@Sun.COM;
susie@symlabs.com; wlu@bea.com; cyang@redhat.com; Herbert.Mehlhorn@ca.com;
llevitan@us.ibm.com; wdettelb@bea.com; william.dettelback@bea.com;
John.Moehrke@med.ge.com; mike.davis@va.gov; jane.harnad@oasis-open.org
Subject: [xacml] Groups - XACML/RSA 2008 InterOp Conference Calls added


XACML/RSA 2008 InterOp Conference Calls has been added by Mrs. Dee Schur

Date:  Thursday, 06 December 2007
Time:  11:00am - 12:00pm ET

Event Description:
Free Conference Call  Conference Dial-in Number: (605) 772-3100
 Host Access Code: 505991*
 Participant Access Code: 505991#

 International Dial-in Numbers  Austria: 0820 4000 1552
 Belgium: 070 35 9974
 France: 0826 100 256
 Germany: 01805 00 76 09
 Ireland: 0818 270 021
 Italy: 848 390 156
 Netherlands: 9004 353 535
 Spain: 902 886025
 Switzerland: 0848 560 179
 UK: 0870 35 204 74


Agenda:


Minutes:


This event is one in a list of recurring events.
Other event dates in this series:

Thursday, 13 December 2007, 11:00am to 12:00pm ET
Thursday, 20 December 2007, 11:00am to 12:00pm ET
Thursday, 27 December 2007, 11:00am to 12:00pm ET
Thursday, 03 January 2008, 11:00am to 12:00pm ET
Thursday, 10 January 2008, 11:00am to 12:00pm ET
Thursday, 17 January 2008, 11:00am to 12:00pm ET
Thursday, 24 January 2008, 11:00am to 12:00pm ET
Thursday, 31 January 2008, 11:00am to 12:00pm ET
Thursday, 07 February 2008, 11:00am to 12:00pm ET
Thursday, 14 February 2008, 11:00am to 12:00pm ET
Thursday, 21 February 2008, 11:00am to 12:00pm ET
Thursday, 28 February 2008, 11:00am to 12:00pm ET
Thursday, 06 March 2008, 11:00am to 12:00pm ET
Thursday, 13 March 2008, 11:00am to 12:00pm ET
Thursday, 20 March 2008, 11:00am to 12:00pm ET
Thursday, 27 March 2008, 11:00am to 12:00pm ET
Thursday, 03 April 2008, 11:00am to 12:00pm ET
Thursday, 10 April 2008, 11:00am to 12:00pm ET
Thursday, 17 April 2008, 11:00am to 12:00pm ET
Thursday, 24 April 2008, 11:00am to 12:00pm ET

View event details:
http://www.oasis-open.org/apps/org/workgroup/xacml/event.php?event_id=17104

PLEASE NOTE:  If the above link does not work for you, your email
application may be breaking the link into two pieces.  You may be able to
copy and paste the entire link address into the address field of your web
browser.



---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-demo-tech-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-demo-tech-help@lists.oasis-open.org

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]