Re: [hrac resources]

[Konstantin Beznosov <beznosov@baptisthealth.net>]

Juggy,

Do I understand correctly your conclusion that tree-like organization of
resource security metadata is not sufficient for the healthcare domain?

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

----------------
Broadcast message to hrac-rfp from Konstantin Beznosov <beznosov@baptisthealth.net>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.