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, 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
On 18/01/2011 20:30, Grahame Grieve wrote:
> Hi Peter, Tom
>
> thanks
>
>> Just take care to use FEEDER_AUDIT for ids generated in external systems,
>> rather than assigned within the openEHR system, including by users of apps
>> talking directly to the openEHR system.
> I'm not sure which way to parse that sentence
>
> Generally, about FEEDER_AUDIT, it's something I had missed, so I'll go
> and review it, but how does it manifest in the archetype editor?
>
> Ian:
>
>> Using FEEDER_AUDIT was actually discussed as part of deciding how best
>> to handle Placer and Filler Order numbers in lab tests etc . The
>> problem we have is that we also need to add these identifiers to
>> outgoing order /referral messages (and track those within the EHR),
>> and FEEDER_AUDIT was deemed unsuitable for this purpose.
> because the identifiers weren't explicitly identified? Can you say why it
> was deemed unsuitable?
>
> thanks
> Grahame
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
--
Ocean Informatics *Thomas Beale
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com/>*
Chair Architectural Review Board, /open/EHR Foundation
<http://www.openehr.org/>
Honorary Research Fellow, University College London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110118/e7e1b8f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110118/e7e1b8f1/attachment.jpg>
