[
Lists Home |
Date Index |
Thread Index
]
- From: Jonathan Borden <jborden@mediaone.net>
- To: KenNorth <KenNorth@email.msn.com>, xml-dev@lists.xml.org
- Date: Tue, 25 Jul 2000 18:24:03 -0400
Ken North wrote:
>
> Now let's say Federation East has to transfer the patient to Klingon West
> Hospital. How do we preserve authorities or privileges to access data if
> Klingon West manages database security by user instead of role, or stores
> records using a primitive file system.
The problem really is one of policy not implementation. Each organization is
responsable for implementing its own security policy. In the simplest of
cases, FE and KW have already agreed to use a common policy, no problem...
But the real question you ask is what if FE and KW don't agree on a common
policy.
Assuming we allow each entity to define its own policy, then each entity
will implement its own policy, file security based, kerberos based, DB based
... whatever. The problem isn't the actual bits of how to allow or disallow
access to bits of data, rather *deciding* who ought.
The reason I am implementing an RDF based medical records repository, is
that it is this very metadata that allows for these decisions to be made.
For example, "blood test" is a class, "sodium test" is a subclass and "HIV
test" is another class. One can create a policy that "HIV test" is
associated with an ACL but "sodium test" is freely available (whatever).
Similarly the schema defines classes for "healthcare providers" (e.g.
physicians, nurses), "admitting physician" (the individial in charge of this
particular hospitalization) and these have instances, so an ACL is composed
of a list of *resources* which encompass both "roles" and "users". Such a
system allows a healthcare entity to create either a user based, role based
or mixed access control system.
>
> At Federation East, the DBMS safeguards who has what rights to access
data.
> If Klingon West is running a DBMS, we can use the DBMS's data replication
> features to replicate security as well as the data. However, the picture
> changes if we're using a patient transfer application that writes an XML
> file or stream or serializes objects.
And don't expect for a minute that FE and KW will be using the same DB, even
if from the same vendor there are versioning issues.
> How do we guarantee Klingon
> West can provide the rich security model for persistent data that we saw
at
> East?
Klingon West will be able to use our opensource software, so they will have
no excuse for not providing a rich security model :-) They also have the
freedom to pay for another system. They don't have the right to not secure
patient data (in many cases by law). But unless we create a universal system
which works, people will continue to lock paper records in a file cabinet
and our tax and insurance dollars will continue to pay for the huge overhead
(while we continue to get the poor quality).
>
> In the schema or DTD, we can define access levels for the constituent
parts
> of a medical record, and code the data to the security levels enforced by
> our database. But how do we use that information at the receiving end if
we
> have a different DBMS or use a file system to store medical records?
>
> Don't we have to transfer some kind of metadata that describes the
> authorities required to access the data?
In our system, metadata is central, not just for transfer. The security
policy is defined in terms of the metadata and the implementation determines
how this policy gets specified in terms of an ACL attached to what using
which filesystem or database on whatever OS.
Jonathan Borden
http://www.openhealth.org
|