will ross wrote:
We agree about shared access to the ultimate EHR repository, which is not like private access to an individual email box. That wasn't my point, which was poorly made, for which I apologise. I should have said that while the EHR repository itself is not like a private email account, the workflow queue of incoming EHR content (or action items) resembles a shared email inbox. I was speaking about the way an email *inbox* (as a gateway to a respository) organises inbound EHR content from various sources (both human and bot), not about the way an email account controls user access to the *content* of the inbox. It occurred to me because I'm working on a clinical messaging middleware project which uses an email paradigm to provide practice level access (as opposed to individual clinician access) to queued EHR content one step before it flows into the EHR, or in the case of some EHRs, as workflow events to be viewed from within the EHR.
Will,
your analogy makes more sense to me now. However I would still contend that an even better analogy is a configuration management system server receiving incoming flows from multiple simultaneous modifiers/creators (of its contents), and knows not only how to sort them chronologically, but how to merge the incoming new or changed items with the existing repository. And it can always tell you a) the current state of the repository, which is what any clinician has as his/her evidence basis at that moment, and b) any previous state of the repository, which any clinician (or a court) can use as proof of evidence used for some past decision (or a medical error).
In your project, are you saying that the email EHR Inbox is a place where practice physicians vet content before it goes in? I think this is a sound approach, and one which I would like to see implemented in systems which have as their repository architecture the aforementioned version/configuration management paradigm under the hood.
- thomas beale
