OASIS eXtensible Access Control Markup Language (XACML) TC

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

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

    Posted 12-17-2007 20:05
    
    
      
    
    
    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:
    CAC273E169E86A4B8397D5766DAB46C006285A4A@ALPMLVEM07.e2k.ad.ge.com" type="cite">

    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: