[COAS-List] RE: [hrac resources]

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

some comments inline......

>   A RESOURCE is the kind of entity - which in HRAC is NOT a
> *CORBA* object - to which access must be controlled.  Examples
> of RESOURCEs would be: records in a specific database, drug
> prescriptions, medical professionals' credentials, and so on.
>
>   A RESOURCE INSTANCE is a specific example of the entity to
> which access must be controlled.  Examples of RESOURCE
> INSTANCEs would be: one record in a specific database, a drug
> prescription for a specific patient, and the medical
> credentials for a specific doctor.
>
>   A RESOURCE ID is the handle, or name, by which the HRAC is
> able to uniquely identify the resource it has been given and
> thereby determine which policies must be used to decide whether
> the supplied credentials indicate sufficient and necessary
> authorization to allow access to the resource instance(s)
> that it (the HRAC) is given to process.
>
>   RESOURCE SECURITY METADATA is the set of information, which
> is either externally associated with a RESOURCE (e.g., provided
> as a label on a file) or is a subset of the data that comprises
> the RESOURCE (e.g., the HIV-Result field of a blood-test record),
> that is used explicitly by one or more HRAC policies as the
> basis for an access decision.

Good set of definitions. in the example below, except for the last item
(resource) the
rest are metadata. I am glad you used the term and not me...:-) we had a
long discussion on
the loaded term "metadata".

In any case my earlier comment stands. If you have a million patients, and
hundres of items of
interests (individual prescriptions, lab results, discharge summaries) there
is a large amout of
metadata that needs to be managed, represented and referred to as part of
enforcing policies.
Further, most of the information is going to be associated with the resource
itself.

> >>      owner: Bhssf
> >>      location: SMH
> >>      patientID: patients/JohnSmith
> >>      conceptCode: bloodtests
> >>      date: August 2
> >>      instanceID: test 3

Now the question on the table is whether a tree or psuedo tree like
representation of metadata
is sufficient/usefull for enforcing policies. Given that the information
itself (metadata or not) is going to be stored in a completely different
form (attributes in tables or objects) - i am not sure how trees help.

>
>So, let's try to answer the following question: "What organization of
resource
>space will allow us to express reasonable authorization policies?"


this is indeed a good question to ask!!!!


>In the context of this question, I was thinking about how resource
space can be
>organized in the following situation:
>(it's just an example)
>
>Security labels are used to assign a sensitivity level to all patient
>information. The following sample set of sensitivity levels is used
{public,
>protected, confidential}.
>
>Then all public information can be associated with resource:
>/PID/public.  All confidential data can be associated with resource
>/PID/public/protected/confidential
>
>Where PID is PIDS-compliant patient ID.
>
>Do you think such a way of resource organization can satisfy most of
reasonable
>policies based on sensitivity level?

in the above case you are simply associating a "sensitivity" label with a
particular resource. this can
be done in one of many ways. For instance, in our discussion in COAS, i
believe we will be supporting
the notion of returning the contextual information (metadata) given a
resource ID (in COAS we were
calling it the observation ID or something like that). One can examine this
data, and depending on
a poilicy statement, determine the sensitivity level of that information.

hope all of this makes sense :-)

- regards
- juggy