OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Healthcare and Security/Privacy

[ Lists Home | Date Index | Thread Index ]
  • From: KenNorth <KenNorth@email.msn.com>
  • To: xml-dev@lists.xml.org
  • Date: Tue, 25 Jul 2000 01:43:25 -0700

> > It seems like we need a multi-level security model for medical records.

Andrew Layman said:
> SOAP .... provides serialization rules for entire objects ...

Len Bullard said:
> Usually, role-based security with flags for record types (eg, juvenile vs
adult in our apps) is adequate.

Matt Sergeant said:
> It would be interesting to be able to define security tokens in terms of
> XPath match expressions...

Jonathan Borden said:
> one might then create a DOM extension which would control access to parts
the document tree depending on the ACL metadata element.

Walter Perry said:
> -- identify various sources of documents with the standard transforms
must be performed first in the pipeline of processing them

All of these message threads touch on issues we have to address with respect
to multi-level security and privacy. The privacy and security challenges are
due in part to promoting XML as a technology for application-to-application
integration and data integration. We can transfer data across the wire, but
can we transfer the security model that's appropriate for that data ? across
heterogeneous systems?

Consider the scenario of transferring medical records. Assume at Federation
East Hospital, we have patient records managed by a powerful DBMS. The
database administrator uses role-based security, packages, views, stored
procedures and other techniques for managing who has access to what data.
Let's assume the patient record actually has a full map of a patient's DNA.
We can drill down to the gene and chromosome level. A surgeon planning an
operation who wants to check risk factors has full access. His or her role
enables the surgeon to execute a query that can get the DNA info -- retrieve
the locator, materialize a BLOB, and away we go. The clerk down the hall can
get admitting information, but his role does not enable him to access
diagnostic test results or DNA. All is well because Federation East Hospital
has an ace database administrator.

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.

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.

An application with the right authorities can retrieve data from the
database, map it into application objects, and then serialize the data
across the wire. If Federation East and Klingon West are running the same
Java classes for ADT (Admitting Discharge Transfer), the natural inclination
for doing a patient records transfer will be to have a Transfer class that
serializes Patient object(s) using SOAP or another vehicle. The application
at Klingon West is going to persist the data. How do we guarantee Klingon
West can provide the rich security model for persistent data that we saw at

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?

It seems we need a protocol that queries for the security model at the other
end and then performs standard transforms based on the recipient's security
capabilities. It should be granular enough to identify security requirements
to the attribute level. (We'll eventually have systems with enough
horsepower that we won't even think about the overhead this imposes.)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS