[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [COAS-List] RE: [hrac resources]



Let's please also acknowledge that "sensitivity labels" and the like are
simplistic mechanisms.  There is a question in  my mind as to whether or
not this approach is overly simplistic.  When I ask customers for examples
of "policy rules" they come back with stuff like "HIV information requires
special access restrictions".  But what constitutes "HIV information" at
the clinical data level.  Certain blood antigen tests, certain combinations
of medications, even consultation with certain physicians can be strong
indicators of testing for HIV positive.  However, any particular item of
information here may be totally innocuous.  It is the combination of
certain items that requires a more restricted access.  I know this same
principle is true of DOD type of information, but I don't know how it is
handled in a "HRAC sense".  Dave -- as an expert in this area, can you shed
any light on this problem?

At 01:49 PM 8/4/98 -0400, V. Juggy Jagannathan wrote:
>
>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
>
>
>
>
_____________________________________
Bob Glicksman  
Director, MedGRiD Program 
Integrated Clinical Solutions
                   
bobg@medgrid.philips.com              Philips Medical Systems   
voice:  (650) 426-2551                2171 Landings Drive
fax:    (650) 426-2550                Mountain View, CA 94043-0837
Pager:  800-759-7243, PIN# 4856736