RE: [hrac resources]

["V. Juggy Jagannathan" <juggy@careflow.com>]

Thanx, John...you actually explained what I had in mind better than my
earlier post about the
tree organization. I will explain what John has said below, in terms of the
same example we looked
at earlier (and using the terminology which was posted):

RESOURCE SECURITY METADATA
      owner: Bhssf
      location: SMH
      patientID: patients/JohnSmith
      conceptCode: bloodtests
      date: August 2
      RESOURCE ID: test 3

Lets take some example policies (totally hypothetical - since currently
physicians can access
everything no questions asked :-)

1) Example 1: A physician can access resources if he is the attending
physician

Now this says nothing about owner or location. Of all the dimensions of the
metadata identified - the
policy definition impacts only patientID. And this is going to be true no
matter what hierarchy you
come up with for organizing the resources.

And if you go ahead and organize the resource hierarchically anyway, the
semantics are completely
different. The policy statement will have to be restated as: " A physician
can only access patient info
if the owner is "Bhssf" and location is "SMH" and he is the attending
physician. Which is the wrong
semantics in an enterprise - as it seems to imply that even if he were the
attending physician for this
patient, if the location of the resource happens to be Homestead (another
hospital in the Baptist
enterprise) he should be denied access.

2) Contrived Example 2: If someone tries to access HIV blood-test results -
simply deny it.
[this could reflect a policy of no electronic transmission such info and it
will be handled manually]

Now this impacts only one attribute above: conceptCode = "HIV blood test".
And it says nothing
about owner, location, or patientID.

Basically, I will echo what John has said elsewhere - a hierarchy tends to
imply a certain model -
even if it is left to individual enterprise to define it themselves - and
that can mean only trouble down
the road :-).

Having said all of this, guess I have not been constructive - i have no
particular suggestion for
how you would want to state policies with respect to RSM. :-(.

- regards
- juggy


> -----Original Message-----
> From: owner-hrac-rfp@cs.fiu.edu [mailto:owner-hrac-rfp@cs.fiu.edu]On
> Behalf Of John Sebes
> Sent: Tuesday, August 04, 1998 6:05 PM
> To: Konstantin Beznosov; hrac-rfp@cs.fiu.edu
> Subject: Re: [hrac resources]
>
>
> >Do I understand correctly your conclusion that tree-like organization of
> >resource security metadata is not sufficient for the healthcare domain?
> Although the question was addressed to Juggy, I'll chime in too.
> If by "not
> sufficient" you mean "we need it but it isn't enough so we need
> other stuff
> as well" then I disagree. If by "not sufficient" you mean not helpful,
> appropriate, useful, etc. then I do agree. Having hierarchical structures
> that encode hundreds of different data points for myriads of different
> instances, all without an explanation of what the hierarchy means (except
> perhaps an ordered list of elements that are not really strictly
> ordered in
> terms of semantics) is downright scary. Nobody is going to be able to
> manage any significant policy with that kind of policy model, IMNSHO.
>
> EJS
> ===
> ----------------
> Broadcast message to hrac-rfp from John Sebes <ejs@tis.com>.
> Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail
> list archive.
>

----------------
Broadcast message to hrac-rfp from "V. Juggy Jagannathan" <juggy@careflow.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.