visit the hl7 website The Demo site for our new HL7 Version 2+ (plus) Standard

18.4.119 ORU - Unsolicited Point-Of-Care Observation Message without Existing Order - Place an Order (Event R30) (7.3.4)

This event trigger instructs the receiving system to create a new order for the observation(s) contained in the message.

One example of this trigger's use case occurs when a Doctor verbally instructs a nurse to perform a test. Looking at this use case from an information management perspective, one might expect that, the nurse would enter an order into laboratory information or ordering system before performing the test. However, there usually isn't time for order entry in these use cases. In fact, it is highly desirable for the POC measurement process to become automated so that the only action a user needs to take is to make a measurement on the POC Device, with all other processes for generating an order and tying it in to the observation handled by the "machines."

In order to allow for the passing of specific information relating to the Patient, responsible Doctor, placing doctor, patient location, etc., there is a requirement for the inclusion of a PV1 and PD1 segment in the ORU message type. One example of this trigger's use case occurs when a Doctor at a remote site without a shared Patient index instructs a nurse to perform a test. The testing is carried out without prior entry of a request into the LIS. Once performed, the results, along with the patient information are transmitted to the LIS. In some circumstances, the LIS may add clinical interpretation to this and report it back to the placing system and/or another system. In order to allow for this to take place, the requester, location, etc., information is required.

To allow the sending system to correlate every result with its associated order, the receiving system will return the placer order number in the ORC segment of the ORA^R33 message. If the receiving system cannot place an order it must returning an application level error description in the Application Acknowledgement Message MSA Text Message field.

The sending system must return a commit-level acknowledgement in response to the ORA^R33 message.

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

Segment Cardinality Implement Status
ORU^R30^ORU_R30
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

 
UAC

User Authentication Credential Segment

[0..1]  
PID

Patient Identification

[1..1] SHALL
PD1

Patient Additional Demographic

[0..1]  
PRT

Participation Information

 
OH1

Person Employment Status

 
OH2

Past or Present Job

 
OH3

Usual Work

[0..1]  
OH4

Combat Zone Work

 
ARV

Access Restriction

  B
PATIENT_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
VISIT [0..1]  
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
PRT

Participation Information

 
ORC

Common Order

[1..1] SHALL
PRT

Participation Information

 
OBR

Observation Request

[1..1] SHALL
NTE

Notes and Comments

 
PRT

Participation Information

 
TIMING_QTY  
TQ1

Timing/Quantity

[1..1] SHALL
TQ2

Timing/Quantity Relationship

 
OBSERVATION [1..*] SHALL
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
DEVICE  
DEV

Device

[1..1] SHALL
OBX

Observation/Result

 

 

ORU_R30

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - ACK^R32^ACK
Blank Blank - ACK^R31^ACK
Blank Blank - ACK^R33^ACK or ORA^R33^ORA_R33
NE NE - -
NE NE - -
NE NE - -
NE AL, SU, ER - ACK^R32^ACK
NE AL, SU, ER - ACK^R31^ACK
NE AL, SU, ER - ACK^R33^ACK or ORA^R33^ORA_R33
AL, SU, ER AL, SU, ER ACK^R32^ACK ACK^R32^ACK
AL, SU, ER AL, SU, ER ACK^R31^ACK ACK^R31^ACK
AL, SU, ER AL, SU, ER ACK^R30^ACK ACK^R33^ACK or ORA^R33^ORA_R33
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
ACK^R30^ACK
MSH

Message Header

[1..1] SHALL
SFT

Software Segment

 
MSA

Message Acknowledgment

[1..1] SHALL
ERR

Error

 

 

ACK

We need some ER7 examples...
We need some XML examples...

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).