I think I agree almost completely with your views expressed here. The protection is a big deal and is one good reason to have multiple databases for different kinds of data and on different machines. The Resource Access Decision Facility was designed to meet the needs you describe at a higher level. The OS certainly is a problem. Some people argue that a truly secure OS can't have single administrative access. I'm not sure about encrypting the database, because the data then may be to easily lost.
Dave At 08:09 AM 6/8/2003 +1000, Tim Churches wrote:
On Sun, 2003-06-08 at 04:04, Tim Cook wrote: > This is the point that we differ on. I originally liked the concept of > federated systems and it certainly helps solve the political battle over > who owns the data. It is also the 'coolest' most 'whiz-bang' solution. > > >From an implementation stand point it will never be a real world > solution. Some may point to the fact that the internet's DNS as an > example/model. The realistic view though is that each and every time a > patient is referred to another specialist that system now has to be > available 24/365 and it just isn't going to happen. The DNS servers are > hubs connected to hubs in the system. A healthcare provider is always > going to represent an end point and will almost always be the weakest > link. > > In a consolidated model where the patient record is owned by the patient > but maintained at one location (personal physician, community clinic > etc.) if the record isn't available to a remote emergency department > then you know it's not available and you aren't guessing if maybe just > some of the data isn't available. When results of a referral need to be > sent to the consolidated patient record the send can be repeated until > it is successful.
I agree that federated systems pose huge operational problems, but centralised or consolidated systems pose equally large security issues. Apart from the fact that they present a much larger point of failure (eg theft of data), there is the issue of who is allowed to see what. There are parts of my health record I may not want my family physician to see, but if s/he is responsible for storing my consolidated record in electronic form, how can I be sure that s/he can't peek at the forbidden parts of my record? Having a third party (including government bodies) host the record doesn't solve the problem either - because I don't want the third party to be able to see **any** part of my record.
Thus, in my view, consolidated EHR systems need to be built on a "trusted computing base" which provides mandatory access controls i.e. if I say that only my gynaecologist can see my gynaecological history, then only she can see it - and not the system administrator of the database in which it is stored.
The problem is that very few systems provide mandatory access control - some at the operating system level, none at the database management level that I know of, and some have been proposed at the application level using layered encryption.
The federated model largely avoids these problems. The operational problems are soluble, though - there is no reason why "federated" databases can't all be housed in one place, a 24x7 data centre, but each database separately (and remotely) administered, protected from local snooping and misappropriation by encryption.
I think it comes down to more precisely specifying what is meant by "federated" or "consolidated" - physical federation/consolidation or logical federation/consolidation?
Tim C
>
> The argument of keeping duplicate data (the consulting and primary
> physicians having a copy) is not an issue. It is exactly what happens
> now with paper. The advantage is that once the consultant receives an
> acknowledgement that the information was received into the primary
> record, they know they are no longer custodians of the primary document.
>
> > Interoperability is really the only way this can be achieved
> > efficiently. Efficient storage is an implementation issue that needs to be
> > paid attention to, but should be invisible to users
>
> Very true.
>
> > (and perhaps even some developers).
> LOL!
>
> Cheers,
> Tim
>
--
Tim C
PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
