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
signature.asc
Description: This is a digitally signed message part
