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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to