On 27 Oct 2004, at 3:43 AM, Thomas Beale wrote:
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.
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,
yes as currently imagined our clinical messaging project is a queue where inbound lab, referral or other content resides pending informed review, whether by clinician or their designee. this queue may or may not be viewed directly by the participating sites depending upon the sophistication of their local workflows. in general, i see three options:
[1] manual/invisible: an all paper clinical site which requires inbound content in printed hard copy
[2] semi-automated/visible: a site with a browser connection to the internet, enabling secure inbound content to be viewed and managed electronically as appropriate (forward for referral, save to location, print, etc.)
[3] expert system/invisible: a fully automated ehr site with it's own workflow rules engine to sort and stage inbound clinical content, in which case the clinical messaging system is just another input
only sites at level #2 will interact as users with the queued content. from our initial survey we think two-thirds of the clinical sites will be level #2 users.
[wr]
- - - - - - - -
will ross phoenixpm.org project manager [voice] 707.272.7255 http://www.phoenixpm.org
- - - - - - - -
