On Sun, 2003-06-08 at 04:43, David Forslund wrote: > I don't do it so people "feel" better. I use it for ease of > deployment. RDBMS > have some useful performance optimizations and the object-relational > mapping can actually enhance those. If I had a good, high-performance, > scalable, open source ODBMS, I would use it. The ones I've used that > are good are not open source.
Alas, Dave is correct. ZODB is fine but its scalability is not that great (even using ZEO) and it doesn't implement any security or access control model at all, meaning that access control has to be handled entirely in the application - or at least in the middleware. Dave will argue that that is what the OMG HDTF corbaMED RAD (resource access decision) service specification is for - and he is right: we should be concentrating on building storage back-ends which adhere to a standard access control API or interface specification. Then it doesn't matter if the actual bytes of data are stored in an RDBMS, an OODBMS or an old shoebox - as long as it adheres to the interface specification. > I don't think it is a 'whiz-bang' solution. I think it is the only > possible solution > with the exception that a single vendor owns everything. There are easy > solutions for replication of databases, caching and related issues so that > an given server doesn't have to be up 24/365. Federation and everyone up > 24/365 are really orthogonal. Yup. Individual clinic systems should not be physically located in individual clinics - they should be hosted in large data centres designed to run 24x365. But that doesn't mean that the data stored in the hosted individual clinic systems can't be under the sole control of those individual clinics. Tim C > > > > >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. > > Records today aren't available when they are needed even within a given > hospital. I don't know how to consolidate across international boundaries > let alone between two hospitals across the street from one another. They > don't want to do it. Consolidation in a region doesn't rule out > federation on > a larger scale. I think consolidation in a region makes good sense with the > caveat given below. The consolidation may take the form of a secondary > caching server to ensure the data has high availability. > > > >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. > > But the data degrades as it is transmitted. This happens a lot in the US. > The change in an HMO which might occur every two years, results in significant > information being lost as the data is moved from one provider to > another. I have > first hand information of this happening. Also as a patient gets referred from > one provider to another, the information doesn't flow. It doesn't even flow > between two locations (offices) for the same physician. > > > > > 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! > > I know. :-( > > Dave > > > >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
