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

[COAS-List] [hrac resources]



The example that was used in the minutes was just for illustration purpose
only. It was not intended to show how a good organization of healthcare
information should be done in a tree-like resource space.

Also, I have to stress that even if we manage to come up with an ideal concept
of how to structure healthcare resource space, the concept itself would not be
able to prevent someone from abusing it and doing very unscalable and
in-efficient resource structures. It's like with programming languages: no
matter how good a language is, someone can still write very bad programs using
it.

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

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?

Konstantin

> 
> Comment on proposed resource management scheme from the meeting minutes:
> 
> > Access to the resource is granted if
> >  access is granted to every node in the path to the resource. For
> >  example, in order to have access to resource identified by
> >  /BHSSF/SMH/patients/JohnSmith/bloodtests/August-02/test-3 access
> >  should be given to /BHSSF, to /BHSSF/SMH, to /BHSSF/SMH/patients,
> >  ..., to /BHSSF/SMH/patients/JohnSmith/bloodtests/August-02/test-3.
> >  The described logic is the same as in access control model of Unix
> >  file system.
> 
> Agree this is a simple (Unix-file-system) model to manage access control.
> But this does
> have implications for COAS. The directory hierarchy example has the
> following types of
> contextual information about an observation (a resource in HRAC):
> 
>      owner: Bhssf
>      location: SMH
>      patientID: patients/JohnSmith
>      conceptCode: bloodtests
>      date: August 2
>      instanceID: test 3
> 
> obviously there is a mapping with the contextual information that one may
> record with an observation
> and the tree hierarchy for resource management being considerd in HRAC. the
> problem is that
> given the above set of dimensions, one may construct arbitrary trees. One
> can conceivably put the
> patienID at the top node - given a patient info can from multiple sites,
> one can put conceptCode at the
> top of the tree, etc.
> 
> Also, i have no clue how you would implement the management of this really
> bushy tree. As soon
> as you hit the patient node, you are going to have million leaves, with
> each one having potentially
> hundreds (if not thousands) of items hanging off it.
> 
> i need to think about this a bit more, and these are off-the-cuff
> remarks....but it appears it might
> be simpler to treat them as straight dimensions and we basically have an
> n-dimensional space -
> and policy statements can involve one or more dimensions.
> 
> - regards
> - juggy