Dear colleagues, Below an e-mail from the HL7 list.
The problem is clear. Performing a query to several systems provides a lot of repetitive information. One query for all the medication about one patient provides for each prescription all the relevant data and all its contexts. So a lot of repetition data about the patient, the medication, pharmacy details, etc, etc. In the realm of HL7 messages this creates a lot overhead. How are things like these handled in OpenEHR space? Is there a query spec that makes the distinction between what info is asked and how it should be presented in what specific format? Gerard -- <private> -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 Begin forwarded message: > From: "Rene Spronk (Ringholm)" <rene.spronk at ringholm.com> > Date: 24 februari 2007 12:56:34 GMT+01:00 > To: Tom de Jong <tom at tdejong.demon.nl> > Cc: mnm at lists.hl7.org, inm at lists.hl7.org, 'Michael Tan' > <tan at nictiz.nl> > Subject: Re: discussion item: carrying repeating information from > query responses in the control act wrapper > Reply-To: "Rene Spronk (Ringholm)" <rene.spronk at ringholm.com> > > Tom, > > Good question - similar to ones raised by the NHS. > > Assuming no changes to the current query response mechanism: > a. one could create a query response model that only contains the > patient Id, or even omits it entirely [because the context is known > to both querying as well as responding system], this would remove > any duplication. > b. it has to be said though, that the simple fact that all > responses contain the same national patient ID doesn't mean that > all other demographics data as known in the various systems is the > same. As such generating a "joint" of that data (and convey it > outside of the payload: in a controlAct or even in an attachment) > will be problematic. > > > Each of these ?items? is messaged using a > > separate <subject> element in the query response. > > That's strictly take not necessary - one could have multiple > relationships within a single payload, a payload that has only one > Patient class. > > Note that the Dutch use-case includes the use of an orchestration > server which groups query-responses from various applications. This > is new territory for HL7 so it doesn't describe nor contain any > expected behaviour of such a server. > > The above doesn't really answer any of your questions, it just > describes options.. so please comment if you have other ideas.. > > TTYL, > > -Rene > > > Tom de Jong wrote: >> Dear all, >> I?d like to raise an issue for open discussion that comes up time >> and again when dealing with queries, especially when these queries >> have the potential for a large number of ?hits? in the query >> response. I?ll illustrate with an example: >> I query a central drug information database that contains data >> about medication dispenses performed at different pharmacies. My >> query parameter is a national patient identifier. The response >> message contains a full history of all dispenses for this patient, >> which is a list of hundreds of items. Each of these ?items? is >> messaged using a separate <subject> element in the query response. >> The message model for this payload contains an R_Patient CMET, so >> that full patient information can be associated with each >> dispense. But since my query parameter was a patient identifier, >> the patient information will in fact be identical in each of the >> hundreds of <subject> elements in the query response. This results >> in considerable overhead in the response message. >> Of course one could argue that *only the patient identifier* >> should suffice to confirm the fact that the dispense records match >> with the query parameter, but if the message model allows for the >> possibility of including full patient information, any query >> filler system can choose to send it anyway. Another option that >> has been suggested in implementations is to have *full patient >> information in the first dispense record* (i.e. the first repeat >> of the <subject> in the query response), but only a patient ID in >> all the others. This can also not be disallowed, but is clearly a >> quirky solution to a very practical issue. >> A more fundamental solution would be to move all the patient >> information up one level and message this as part of the control >> act wrapper (so outside of the repeating <subject> elements). >> Since there?s essentially nothing special about the patient >> information, this method could also apply to other situations >> where an *association with the focal class repeats identically in >> all records of a query response*. The key ingredient from a >> semantics viewpoint of course is that there would need to be >> *context conduction* through the control act wrapper into the >> payload(s) of the query response. >> I?m voicing this on behalf of many local implementers, knowing >> that it will be controversial from a modelling perspective. Any >> responses are welcomed. >> Best wishes, >> Tom de Jong >> HL7 Netherlands > > -- > ------------------------------------------------------------ > Rene Spronk Phone: +31(0)655 363 446 > Senior Consultant Fax: +31(0)30 695 6915 > Ringholm GmbH The Netherlands > http://www.ringholm.com mailto:Rene.Spronk at ringholm.nl > Ringholm is a German GmbH - registered in Essen as HRB 14743 > ------------------------------------------------------------ > Ringholm GmbH Integration Consulting - Making Standards Work > > > ************************************************ > To access the Archives of this or other lists or change your list > settings and information, go to: http: //www.hl7.org/listservice -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070225/5af96f53/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
