[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:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]