[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Fwd: Open Source Health Informatics
From: |
Luke Kenneth Casson Leighton |
Subject: |
[Gnumed-devel] Fwd: Open Source Health Informatics |
Date: |
Wed, 18 Aug 2010 18:07:41 +0100 |
---------- Forwarded message ----------
Date: Wed, Aug 18, 2010 at 5:26 PM
Subject: RE: Open Source Health Informatics
Hi Luke,
In answering your question, I'm using the following as a reference:
http://www.interfaceware.com/hl7-standard/hl7-message-ORUR01.html
What I see from this is the following:
The ORU^R01 message references the following segments that are
pertinent to this question:
* ORC - an optional generic order segment
* OBR - a mandatory laboratory specific segment
* OBX - an observation/result segment (of which there must be
at least 1) that is associated with the ORC/OBR pair
I'm not so sure that there are clinical reasons why the association is
present as much as workflow issues such as ensuring reconciliation
between the original order and the result. Although if the request is
on paper (and they aren't always) the entry of the order is performed
electronically at the lab there may well be a "Placer order number"
(part of ORC) on the paper request which permits the original
requestor to reconcile the result with the order.
Also bear in mind that the payload of the OBX is very general purpose,
it's just an observation and it's only by associated it with an order
segment that it can be made clear to the recipient whether this OBX is
in response to anything they have requested or has just been sent 'out
of the blue'. In fact (and this may get to the heart of what Carsten
wants to know), for comparison take a look at the use of OBR/ORC and
OBX in ORU^R30 which is designed for use when there isn't an order in
place. Inspection of ORU^R30 looks rather similar except that the OBR
and ORC are both optional.
I hope this helps.
Regards,
Paul
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnumed-devel] Fwd: Open Source Health Informatics,
Luke Kenneth Casson Leighton <=