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
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: