David Forslund wrote:
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 - 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...
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.
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...
- thomas
