Re: [hrac resources]

[Wayne Wilson <wwilson@umich.edu>]

John Barkley wrote:
> 
> 
> Do you reproduce content which is needed for access decisions as metadata
> somewhere else? I should think probably not. Keeping a list of attending
> physicians and/or list of patients as metadata redundant to content
> has lots of problems.
> 
> What you likely have to do is to have an access control system that
> is able to access content as security metadata.
> 
I think I  understand what you are saying here, the 'content' of the
information system is the security metadata or at least a part of the
security metadata.  Can we imagine security metadata that is not part of
the 'content'?

Now, on to the complications of 'content' and metadata:
See comments in-line.

Juggy wrote:
> here is an example:
> 
>         patient-info
>            |
>            Labs
>                |    |
>                |     --- blood tests
>                |              |
>                |              alcohol level test
>                |              |
>            |              cholestrol tests
>                |
>                Discharge summaries
>                |
>                Outpatient Notes
>                |
>                .........
> 
> In COAS they are talking about associating a conceptCode with each
> observation (a resource in HRAC).
>
Yes, but doesn't the conceptCode itself now become part of the 'content'
and therefore also a resource for HRAC?
>
> This concept code can map to one or MORE leaf node in the above
> organization. This also suggests
> that one ties rules to nodes of the above tree. But as Konstantin pointed
> out, there are three types
> of information that is needed by policy rules:
> 
>         1. credentials of the person accessing the resource
>         2. what is being accessed on whose record
>         3. relationship of accessor to accessee (hope i have this right :-)
> 
> so that seems to imply that you cannot tie policy statements just to nodes
> of the above tree -
> as it does not have all the relevant information. One can potentially have
> another tree of relationships:
> 
>              Relationships
>                   |
>                  primary care provider
>                   |
>                  attending physician
>                   |
>                  consulting physician
>                   |
>                  care team for episode of care
>                                |
>                               ward nurse
>                                |
>                               attending physician
> 
Ah, yes.  Relationships.  This was what I was trying to say earlier
about the COAS model as discussed in Helsinki.  There are also
relationships among the observations themselves.  From the previous
example we have blood tests with two members: alcohol & cholesterol, and
then blood tests being a member a very generic    abstraction
patient_info, much like primary care provider and care team episode are
members of a very generic abstraction called relationships.  One of the
reasons we call this metadata is that it is usually not explicit in
current implementations, for example at our site, we have no explicit
list containing the names or id's of a care team's members.  So this is
the reason I have fallen onto the side of COAS viewpoints that suggests
this metadata needs to be captured and explicitly represented somewhere,
thus becoming 'content' and also thus becoming available for HRAC
access.

  In short, what I am saying is that the issue of 'security metadate' is
really just metadata (for example the relationship of primary care
physician or consulting physician is not just for security purposes). So
for HRAC this results in two sets of interlocking issues:

 1) Are there metadata that have no purpose outside of security?
   If yes, then HRAC must administer and access such metadata.
   If no, then fall to 2)

 2) IS content metadata stored explicitly in system?
    If yes, then HRAC can access it as system content and even security
only metadata could probably be represented here.
    if no, then someone must build metadata storage system as add-on to
system and then populate it, first with security relavant info (and
perhaps later for other applications to use?), said another way should
HRAC build metadata just for security purposes or should a generic
metadata system be built such that other applications could gain access
the primary care physican relationship?

As I stated earlier, the problem is that most current systems have no
explicit metadata, which means that to move in a gradual way to a
security model with policy based on 'relationship' metadata rquires that
an explicit metadata service be built.

Another case to consider is if COAS were to adopt the possibility that
an explicit metadata service is not available and metadata is 'coupled'
with the content explicitly, such as a serier of RDF statements along
with the content.  In that case, HRAC still has no problem as the
'embedded' metadata would appear to HRAC as another kind of content.

  Managing all this is probably another issue altogether.

Thanks for you consideration and I hope this is not too 'out of left
field'
----------------
Broadcast message to hrac-rfp from Wayne Wilson <wwilson@umich.edu>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.