On 18/01/2011 23:17, Thomas Beale wrote: > > Short brain dump on FEEDER_AUDIT: > > * main fact to know: FEEDER_AUDIT is an optional thing hanging off > any LOCATABLE (i.e. any node down to ELEMENT level) > * UML picture here > > <http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109318114715_211173_0Report.html> > * proper description here (PDF > <http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf>) > - see rm.common.archetyped package > > FEEDER_AUDIT was orginally conceived to carry ids over which the > target system has no control, that come in from external systems, e.g. > lab systems or whatever. Peter's point is that it would be nice if it > were symmetric, so that the openEHR system sending _out_ and order > used the same place to record e.g. order_id. > > Superficially this would appear to be so, however the FEEDER_AUDIT is > meant to carry the external system's idea of its ids, possibly > attached to ENTRYs or some lower level of data, not just COMPOSITIONs. > The openEHR system does need to record order ids in the outgoing order,
sorry, mistype; I meant if the openEHR system recorded the order_id of e.g. a COMPOSITION containing an INSTRUCTION, how would the receiver system read this? It will typically be expecting an HL7 message. > but this is nearly always an HL7 message or similar. Putting it in > openEHR FEEDER_AUDIT is not useful. > > Being able to record order_id on any CARE_ENTRY type has turned out to > be a useful thing to do (Grahame and others with long experience in > lab messages might be smiling, but we like evidence to support things > in openEHR;-) Anyway, it isn't there now, but will go in as a change > request for the next release. > > Note that there are all kinds of placer, filler, lab, session, who > knows what else ids in HL7 and IHE. Most of these will just be > archetyped fields. But the concept of an 'order' and therefore an > 'order_id' is a strong enough one to go in the RM. > > - thomas > * > * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110118/0360f78d/attachment.html>
