Melvin I agree with you - but the EHR efforts are not doing this.
I think that your response is a 'paper-based' response - that we have to see all these things - because they are accessible. One great advantage of the EHR is that things can be presented to us as we require - we have a lot to learn about this. The reality is that in primary care I might need the 24hr Urinary Protein result done 2 years ago in Hospital - I might not. Why limit the access of people to information that is helpful at the design stage. Sure I only want to see it if I need it. We do need an audit trail that meets privacy, accountability and medicolegal requirements - everywhere. It should be completely behind the scenes. Cheers, Sam ____________________________________________ Dr Sam Heard The Good Electronic Health Record Ocean Informatics, openEHR 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.gehr.org www.openEHR.org __________________________________________ > -----Original Message----- > From: Melvin Reynolds [mailto:MelvinR at AMS-Consulting.co.uk] > Sent: Friday, 13 September 2002 6:47 AM > To: Thomas Beale > Cc: William E Hammond; Sam Heard; Gerard Freriks; Openehr-Technical > Subject: Re: Archetype ontology > > > Thomas, > > Somewhat to my surprise I find myself agreeing with most of your points > in the discussion below. > > However, the final statement "... As soon as one >starts thinking about > what has to happen to turn messages into EHR >content, it becomes > clearer and clearer that the EHR is nothing like a >compendium of > messages; for from it - it is a time-based accumulator of >EHR > information, some of which is sourced from messages, much of which >is > created by human users of GUI applications." seems like a gross > oversimplification of the reality. > > It is true a "readable" EHR is not likely to a compendium of messages. > But an EHR for use in a primary care context is not likely require to > present the same information (in full) as an acute secondary care EHR; > and neither are likely to require to present the full audit trail of all > messages, requests and reports that would be required of a > medico-legally complete (but clinically unhelpful) EHR. > > As well as a clarification of scope, it would seem to be important to > clarify at what level of context/granularity we are seeking to produce > the EHR. > > Sorry if I've missed anything - but the recent discussions would seem > to indicate that I'm not alone if I have. > > Regards, > > Melvin Reynolds. > > > In mail of Tue, 10 Sep 2002 17:10:14, Thomas Beale > <thomas at deepthought.com.au> wrote: > > > > > > >William E Hammond wrote: > > > >>What happens when messaging is used for query. I view messaging as any > >>interchange between two or more entities. I view pier to pier > >>communications as messages, and I have found nothing to > contradict that. I > >>would be interested in any references that suggest otherwise. > >> > >I don't want to get into any serious debate on the issue (since for > >many people it is an argument of whether 6 eggs is the same as > >"half-a-dozen" or not), but one differentiator is that people tend to > >use the word "message" more when the structure of the messages > >themselves have been defined - i.e. that is what is being standardised, > >and nothing is being said about the communicating systems. People > >talking about peer-peer or other configurations of distributed systems > >are usually thinking more along the lines of information/service model > >defintions of the systems, while the messages are not defined > >explicitly - they come out automatically from the tools, based on the > >service models, as happens in CORBA, COM, .net, OSF/DCE, XML/SOAP and > >other such technologies. > > > >Some people will call everything that goes between two nodes a > >"message", which is literally true, but not that useful for explaining > >what kind of message, or how it was put together, or what rules it > >obeys. So I tend to use the word to mean communications which have been > >specified by defining message contents, rather than the semantics of > >information or services available in systems. > > > >So in openEHRor CEN, if there were two nodes sending part of an EHR to > >each other, and XML/SOAP/WSLD (essentially the web version of Corba or > >RPC) was being used, I would not explain it to someone as being a > >message, since there is no need to specify the message, even though in > >literal terms, a "message" (= string of bytes) is being sent. However, > >if an EHR node was receiving a pathology result in HL7 form, I would > >call it a "message". > > > >>Why is the definition of messaging important? Messaging is > different from > >>syntax. Whether I use ER7, XML, SOAP or whatever, the trigger > events and > >>message content is what is important and what will be > persistent. strongly > >>agree that messages are different than the EHR. However, I > populate much > >>of my EHR from messages I receive from other components of the > health care > >>institution - lab, radiology, ADT, pharmacy, clinic, etc. > >> > >That's true, but it is more than likely that a) a lot of messages are > >of no interest to the EHR (e.g. they are destined for an orders > >management, prescription, or admin service) and b) messages which are > >of interest will not go into the EHR in their message form. They will > >be validated, sifted, filtered, reformatted into EHR form, have links > >back and forward to other EHR items added, be classified this way and > >that, during the process of being added to the EHR. As soon as one > >starts thinking about what has to happen to turn messages into EHR > >content, it becomes clearer and clearer that the EHR is nothing like a > >compendium of messages; for from it - it is a time-based accumulator of > >EHR information, some of which is sourced from messages, much of which > >is created by human users of GUI applications. > > > >- thomas beale > > > > > > > >- > >If you have any questions about using this list, > >please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
