-- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands
T: +31 252 544896 M: +31 654 792800 On 17-sep-2005, at 16:40, Thomas Beale wrote: > Gerard Freriks wrote: > > >> Thomas, >> >> All the information in both the EHRsystem and the prescription on >> paper or electronicly is the same archetype/template. >> Only the intention is different. >> In the former it is about documentation. >> The latter is the prescription order that was documented. >> >> Can we agree that documentation is within the scope of OpenEHR >> (and EN136060) and that the electronic prescription as an order is >> not? >> And that the electronic prescription as an order is THE scope of >> HL7v2 and HL7v3 messages. >> > > from the openEHR point of view, the content of a prescription is in > the record. Correct to a degree. The record is there to document what has happened. eg a prescription was written. This has the status of an order TO BE fulfilled. The notification (in any form) has the same content as what is in the record, but is NOT the same. The notification must indicate (or contain) explicitly what is prescribed and has the status of an order to be fulfilled. > The 'order' corresponding to a prescription is simply a > notification from the prescriber to the filler. This notification > may be communicated in two ways: > a) by the patient turning up > b) by an electronic notification from EHR source to filler's system > asking for the prescription in the EHR to be acted upon > c) by an electronic message carrying the content (due to shared EHR > not being possible) of the prescription and the notification > > What kind of electronic notification is used in b) and c) depends > mostly on what receiver systems want to receive. At this stage it > could be similar to a v2 message. The problem with the HL7 message > though is that it is going to want to carry the content (translated > into HL7-speak, and back out of it at the other end) i.e. it will > always want to do c) above, so we have to be very careful about > that. It is clearly preferable if we are forced to work in mode c) > that an EN13606 message be used instead; then we are arguing for > the addition of some notification information in the EHR Extract, > which Gerard and Sam have already flagged earlier in this thread. I > agree: that should definitely be explored. Then the obvious way to > model b) is to define something that looks like the EN13606 Extract > (augmented with notification info), but allowing no content, but > rather a logical pointer to some content. > > I have to admit, I had not thought my way completely through this > line of reasoning before, but I think this is where Gerard and Sam > are coming from. I would go so far as to say that appropriate > change requests should be made to openEHR and to EN13606 to provide > the support for this. We are getting somewhere. In my mind, and on the basis of many years of a collective experience, we humans only trust a complete document handed to us, sent to us, that tells the whole story. This is what legal persons want to happen. Not a thing with a pointer to a place with content where you have no jurisdiction. Therefor I think that option C is what we are after when there is an order for an other in an other legal entity. Within the legal entity options a and b will be ok. > > The key point to remember is that the EHR and other related systems > are the sources or sinks of the information; Of events that have happened. They DOCUMENT. > messages should be able to carry whatever content they require, > with 0 semantic translation, and minimal syntactic translation. > This is not the case today with HL7 messages. I have just reviewed > in detail some HL7v2 interfaces in Queensland Health in Australia, > and it is clear that the messages are imposing semantic as well as > syntactic translations. HL7v3 messages will do the same. It is also > clear that this is an undesirable situation; it is like the postal > service forcing everyone to write letters in latin - and only using > the postal service's allowed lexicon of latin phrases, even though > the sender and receiver both want to speak english. Anyone who has > seen the Monty Python Hungarian phrase-book sketch will know what I > mean. > > This is why I say that service models (which are agnostic as to > content) are a preferable approach. EN13606 is pretty agnostic as > to content, and can easily fit into such a framework. You are correct about your metaphor. But many people want to write and read in Latin. In a services environment this will be up to the actors that will make use of the services. They will speak Latin when they want to or OpenEHR (EN13606) when this fits their needs. > > - thomas > > -- > ______________________________________________________________________ > _____________ > CTO Ocean Informatics (http://www.OceanInformatics.biz) > Research Fellow, University College London (http:// > www.chime.ucl.ac.uk) > Chair Architectural Review Board, openEHR (http://www.openEHR.org) > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20050918/6fae8980/attachment.html>
