See below > ------------Original Message------------ > From: Thomas Beale <[EMAIL PROTECTED]> > To: "OpenHealth List" <[EMAIL PROTECTED]> > Date: Fri, Oct-22-2004 8:20 PM > Subject: Re: Medical Record Location(s) was: Virtual Privacy Machine - reprise > > David Forslund wrote: > > > > >The federated approach doesn't mean that all the data has to be > scattered. > >But rather, it can be scattered. There is nothing wrong with summary > data > >being available with pointers to where the full data is (as you > indicate above). > >Too much duplication of the data can be a big problem, too. > > > > > > > Agree. But this is where the right design paradigm for > federated/distributed EHRs comes in. Well, there are a number of > paradigms. But one of them is to treat the EHR as a versioned entity, > like a software base under CVS or a similar tool. Then dealing with > copies is the same as dealing with merging, and there are safe and > known > ways to handle this. BTW, the tool we use on openEHR for VC - BitKeeper
We do versioning in OpenEMed of essentially all data that comes in. This was extremely helpful in doing our medical surveillance work because multiple copies of each event typically came in over time. > > - provides a beautful demonstration peer - to - peer copying and > synchronisation in action (it's not single server-based like CVS). I > still haven't quite convinced myself that this tool couldn't actually > be > used for EHRs... > > Other design paradigms are of course needed, such as a model of > hierarchical federation, with logic for peer-peer exceptions to the > hierarchical communication toplogy; caching and a standardised data > model are also important elements, and reliable distributed patient > identification is of course crucial... Certainly, Dave > > - thomas > > >
